IRC logs for #openttd on OFTC at 2018-12-09
⏴ go to previous day
00:31:39 *** snail_UES_ has joined #openttd
00:46:56 <glx> oh nice it seems WIN64 is not defined in MSVC even for x64 builds
00:47:22 <glx> I guesse one day MSVC won't define WIN32 too
00:48:01 <glx> as the doc only says _WIN32 and _WIN64
00:54:28 <glx> now the question is should we keep using WIN32 and define it if it's not, or should we replace all WIN32 with _WIN32
00:55:20 <nielsm> _WIN32 is the correct way to detect a compiler that's targeting win32 api
00:55:40 <nielsm> so changing to that across the board would be preferable imo
00:56:23 <glx> and I'll remove WIN64 (or replace them with _WIN64), because they are useless for now :)
01:00:25 <glx> yeah a conflict with mingw32 api
01:00:47 <glx> In file included from D:/developpement/GitHub/OpenTTD/src/os/windows/win32.cpp:23:
01:00:47 <glx> D:/developpement/GitHub/OpenTTD/src/fios.h:197:20: error: 'SORT_ASCENDING' conflicts with a previous declaration
01:00:47 <glx> In file included from H:/msys64/mingw64/x86_64-w64-mingw32/include/shlobj.h:124,
01:00:49 <glx> from D:/developpement/GitHub/OpenTTD/src/os/windows/win32.cpp:20:
01:00:49 <glx> H:/msys64/mingw64/x86_64-w64-mingw32/include/shobjidl.h:6411:5: note: previous declaration 'tagSORTDIRECTION SORT_ASCENDING'
01:01:09 <glx> and the same with SORT_DESCENDING
01:02:18 <LordAro> OTTD_SORT_ASCENDING ?
01:21:48 *** gnu_jj_ has joined #openttd
01:27:42 *** gnu_jj_ has joined #openttd
02:45:35 <DorpsGek_II> [OpenTTD/OpenTTD] glx22 opened pull request #6987: Fix: [Win32] WIN32 may not be defined, always prefer the compiler pre… https://git.io/fp9vd
02:55:53 <Eddi|zuHause> error: 'SORT_ASCENDING' conflicts with a previous declaration <- yay for namespaces? :p
02:56:45 <Eddi|zuHause> or just #undef it :p
07:57:28 *** sla_ro|master has joined #openttd
08:01:13 *** synchris has joined #openttd
08:53:56 *** andythenorth has joined #openttd
10:11:05 *** Progman has joined #openttd
10:41:53 *** gelignite has joined #openttd
11:21:15 *** chomwitt has joined #openttd
11:43:43 *** frosch123 has joined #openttd
12:13:31 *** Wacko1976 has joined #openttd
12:47:24 *** gnu_jj_ has joined #openttd
13:16:00 *** andythenorth has joined #openttd
13:30:42 *** Wolf01 is now known as Guest5148
13:33:50 *** Maarten has joined #openttd
13:34:43 <andythenorth> maybe Horse has too many trains?
13:34:55 <andythenorth> why does no-one ever make smaller newgrfs?
13:34:56 <Eddi|zuHause> too many, too few, everything?
13:35:22 <Eddi|zuHause> i don't think there's a "just the right amount"
13:36:45 *** HerzogDeXtEr has joined #openttd
13:44:04 <andythenorth> Horse is 'too big' for current game because town density is very low
13:44:23 <andythenorth> so pax trains that are small / high density are irrelevant :)
13:44:30 <andythenorth> meanwhile I wish I could figure out how to unbreak supplies
13:46:19 <planetmaker> <Eddi|zuHause> i don't think there's a "just the right amount" <-- yep, exactly
13:46:57 <planetmaker> "too big" is relative, though. People can filter vehicles... so... not sure it can be 'too big'. It's mostly the one-time effort to setup filters
13:47:40 <nielsm> ehh, there isn't real filters is there? as in "don't show me trains with less than 1000 hp" etc
13:48:11 <nielsm> just hiding individual models
13:48:20 <andythenorth> I've been wondering about filters
13:48:34 <andythenorth> I have grouped engines into classes, which I could expose to a property
13:48:45 <andythenorth> but then...other newgrfs :P
13:49:26 <nielsm> also I've mentioned this before, but having "introductory new technology premium" on (some) vehicle prices, e.g. when the first really fast passenger train is introduced it starts insanely expensive, but the price actually falls over time as the technology enters real mass manufacture
13:49:48 <nielsm> that could help make more variety more viable, I think
13:50:14 <andythenorth> fairly certain that can be done in newgrf
13:50:40 <andythenorth> it would be better to have some kind of tech tree
13:51:09 <andythenorth> so technology can be early stage / mature / legacy
13:51:23 *** Wacko1976 has joined #openttd
13:52:10 <nielsm> yes so maintenance costs of steam engines go through the roof as the world moves on
13:52:53 <andythenorth> that's modelled by reliability in current game
13:53:08 <andythenorth> but reliability is irrelevant because breakdowns have to be off
13:53:22 <nielsm> (it annoys me playing multiplayer where some insist on having "vehicles never expire" on, combined with no breakdowns, just so they can keep having steam running around everywhere in 2020)
13:53:30 <andythenorth> * accuracy: breakdowns have to be off if you use road vehicles
13:54:14 <andythenorth> one day I'll find a savegame which shows why breakdowns are broken :P
13:54:25 <andythenorth> also I'll figure out why cdist is broken
13:54:34 * andythenorth been saying that for years
13:54:41 <nielsm> breakdowns as implemented, both "normal" and "reduced", are unfun to play with
13:55:19 <andythenorth> for trains they're trivial to avoid, you just force servicing with signals
13:55:35 <andythenorth> for RVs they're stupid, because RVs can't find a depot without explicit orders
13:55:51 <andythenorth> and explicit orders for servicing is boring
13:56:21 <andythenorth> also trains can't find a depot if their PBS reservation takes them past it
13:56:35 <andythenorth> they don't trigger a re-route when service is needed (or forced by player)
13:57:41 <nielsm> afaik the problem is that the pathfinder doesn't have a way to search for a route while ignoring the train's own reservation, but taking every other reservation into account
13:57:53 <nielsm> haven't looked at it really, just imagining things
13:58:36 <andythenorth> so the 2020 thing, you'd rather there was no steam, or you'd rather there was a better way to scale vehicle dates? o_O
13:58:49 <nielsm> so you'd have to cancel the reservation to pathfind, but then things might change in front of the train during that
13:59:16 <nielsm> I'd rather that players were punished for using out of date vehicles even with breakdowns off
13:59:55 <nielsm> maybe even something simple like maintenance costs is scaled by the inverse of reliability
14:00:09 <nielsm> (for some appropriate inverse)
14:00:22 <andythenorth> pikka scaled running costs
14:03:07 * andythenorth still wonders about a parameter for scaling intro dates
14:03:24 <Eddi|zuHause> isn't that what inflation was meant to do?
14:03:30 <nielsm> also you know what, I've realised what part of my issue with the town passenger generation patch is
14:03:55 <nielsm> it's that passenger generation doesn't depend on how many places you can go
14:04:17 <nielsm> I should get more passengers if I can take them to more places
14:05:12 <nielsm> of course, that would mean passengers need to have a destination in mind before they pick a station to start at
14:05:34 <nielsm> completely destroying the premise of cdist
14:06:05 <nielsm> (that's how simutrans and transport fever work)
14:06:46 <nielsm> also, passengers should always pay per leg individually, instead of for the entire trip at the end
14:07:28 <andythenorth> michi_cc can explain why yacd failed on performance issues :)
14:07:32 <nielsm> I wasn't around when those were being tested
14:07:44 <andythenorth> I played yacd completely for about a year
14:07:45 <nielsm> so know nothing about them expect they existed
14:08:00 <andythenorth> everything had a destination
14:08:17 <andythenorth> and the destinations were really appropriately scaled
14:08:59 <andythenorth> cdist is ok, and fonso gave a lot of help and bug fixes for me
14:09:17 <andythenorth> but cdist I have to adapt play style a lot, just to get the benefit of automated transfers
14:09:21 <andythenorth> which is all cdist is
14:10:07 <nielsm> cdist models "something", it just doesn't model how things actually move
14:10:16 <nielsm> especially not passengers
14:11:27 * andythenorth wonders if 'no loading' could be made a default on orders :P
14:11:35 <andythenorth> it's tedious setting it for every destination station
14:11:57 <nielsm> hm I suppose the issue with having passengers paying per leg is intentionally setting up infinite loops generating money for moving passengers nowhere in particular
14:12:15 <nielsm> but then you'd just have to qualify those payments on playing with cdist and not using forced unload
14:14:20 *** Gameinsky has joined #openttd
14:15:22 <nielsm> if "manual" setting in cdist meant that you could actually manually specify a distribution scheme (e.g. a flag on timetable per cargo type, "this cargo type is unloadedd as much as possible as early as possible" or "this cargo type is evenly distributed among all accepting stations on the rest of the list")
14:15:25 <nielsm> that would also be nice
14:16:12 <nielsm> or maybe rather per station that receives the goods from production, you can choose per cargo produced whether it's arbitrary distribution or pre-determined destinations production
14:16:37 <nielsm> possibly even choose which destinations are allowed by an inclusion or exclusion list
14:17:50 <nielsm> I think that might actually be the sanest approach, add a button next to produced cargoes in the station window, where you can set distribution settings for that cargo from that station
14:19:29 <andythenorth> or on the shared order group?
14:29:14 <michi_cc> YACD is nice but needs lots of CPU power. Unfortunately, threading it is hard(tm), quite in contrast to the abstract cdist flow graph updates.
14:34:19 <andythenorth> YACD causes some awesome pax networks to get built
14:37:22 <nielsm> and maybe having an "eyedropper" tool for adding stations instead of typing in names ;)
14:37:30 <nielsm> (similar to building orders lists)
14:38:36 <andythenorth> I used to think this would be horrible micro-management
14:38:41 <andythenorth> but if the defaults are good...
14:39:14 <nielsm> like, if a grf could specify that certain cargo types prefer cdist...
14:39:22 <andythenorth> my objections to cdist are individually minor
14:39:32 <andythenorth> - have to use 'no loading' order to prevent backrouting
14:39:35 <nielsm> or maybe making "supplies" an actual separate cargo class
14:39:46 <andythenorth> - no incentive to connect pax or mail networks
14:40:05 <andythenorth> - have to use one station per destination as pickup from industries
14:40:33 <andythenorth> the automated transfer part is pretty good
14:42:57 <andythenorth> the last one is the worst, having to use one station per destination
14:44:15 <nielsm> not sure I understand what you mean
14:44:35 <nielsm> the destination is a station and not a building?
14:45:01 <nielsm> i.e. it should be able to route to any station that services the building, not just one particular station
14:48:21 <andythenorth> if a pickup station has one established route, and a second is added
14:48:31 <andythenorth> it takes 3-6 months for cargo to be allocated to the second route
14:48:59 <andythenorth> adding a third or fourth route often seems to fail completely
14:49:04 <nielsm> also not very related, I just felt like I had to share a picture of this thing I've had open for several days now: https://0x0.st/sD_e.png
14:49:25 <andythenorth> I've tried fonso's tips for forcing a re-calculation, e.g. running trains empty to the destination etc
14:50:08 <andythenorth> this can be avoided by simply building a new unconnected station
14:52:00 <andythenorth> means I end up with a lot of stations around some industries
14:52:02 *** Wacko1976 has joined #openttd
14:52:28 <andythenorth> spreadsheet has a lot of 0s nielsm o_O
14:52:54 <nielsm> it's a simulation of yet another potential way to generate town cargo
14:53:30 <nielsm> zeroes are when column A value < row 1 value
14:53:39 <nielsm> and otherwise it's the column B value
14:53:45 <andythenorth> what are the factors? o_O
14:54:00 <nielsm> the sum in row 2 is the sum of all the values below
14:54:57 <nielsm> column A and B are generated in python as:
14:54:57 <nielsm> collections.Counter((random.randrange(1,257)*random.randrange(1,257)//256 for i in range(1000000)))
14:56:15 <andythenorth> so is each subequent row a dice roll for pax generation?
15:01:20 <nielsm> I suppose it was just an experiment with a way to generate a sqrt() shaped distribution
15:01:29 <nielsm> which might or might not be a good idea
15:34:33 <andythenorth> would be really nice to finish nml industries
16:16:21 *** synchris_ has joined #openttd
16:23:38 *** Gustavo6046 has joined #openttd
16:24:39 *** Wormnest has joined #openttd
16:28:29 <glx> unless I build without freetype
16:38:59 <michi_cc> Seeing that libharfbuzz isn't linked by us, I'd guess there's some stuff-up on the lib side.
16:39:19 <glx> it comes with freetype package
16:40:14 <LordAro> glx: istr having the same issues last time i tried to compile on mingw
16:41:31 <LordAro> not that the error seems all that relevant here
16:55:36 <andythenorth> I am seeing white flashes / glitches on mac OS
16:55:45 <andythenorth> occasional, very short, not quite full screen
16:55:56 <andythenorth> on head of master
16:59:15 <glx> so should be in mingw package since jun 7 with 1.8.0
16:59:36 <glx> before it was still 1.7.5
17:00:38 <LordAro> i don't understand why they would define those functions like that
17:00:45 <LordAro> how would that ever work?
17:02:11 <LordAro> i'm not seeing any raised issues about it, weirdly
17:02:30 <glx> I think it works in shared lib, but it's completly wrong for a static one
17:02:33 <LordAro> is it because it's compiled statically, i wonder?
17:03:04 *** Eddi|zuHause has joined #openttd
17:03:46 <glx> even memory checkers don't do it that way IIRC
17:04:03 <glx> and they hijack all these calls
17:14:44 <glx> strange, yesterday I tried removing -lstdc++ or adding -Wl,--allow-multiple-definition, linking was ok but running crashed, today it works
17:17:41 <glx> but some characters look ugly compared to the msvc build
17:18:10 <glx> using the same openttd.cfg
17:28:14 *** ChanServ sets mode: +v tokai
17:28:37 <andythenorth> Eddi|zuHause: are you playing WoT Blitz?
17:28:49 <andythenorth> someone in my game had your nick :P
17:52:22 <glx> tried non static builds, compiles fine, same ugly characters
17:52:44 <glx> something is clearly wrong in mingw-w64 freetype build
18:10:26 *** gelignite has joined #openttd
18:38:35 <glx> with msvc I see no differences in drawing, waiting for mingw-w64 build (it's slow)
18:39:41 <glx> and of course I use --without-freetype ;)
19:02:58 *** Progman has joined #openttd
19:05:19 <glx> michi_cc: with your work mingw-w64 looks better
19:10:32 *** snail_UES_ has joined #openttd
19:16:37 *** Wacko1976 has joined #openttd
19:26:21 <Wolf01> <andythenorth> someone in my game had your nick :P <- and killed you with no mercy?
20:21:56 <Eddi|zuHause> andythenorth: wasn't me
20:44:11 <Wolf01> There's one frosch right now in destiny too :P
20:49:22 <Eddi|zuHause> but there must have been at least another 122 frosches before him
20:54:23 <Wolf01> Also wolves and Eddis :P
21:53:44 <andythenorth> how about flagging one train in a group as 'all other trains should match this'
21:54:17 <andythenorth> instead of having template trains, and how-to-build-trains-without-a-depot and newgrf cb madness and so on
21:55:08 <frosch123> anyway, everything breaks with refit orders :)
21:55:29 <frosch123> no idea, i have not touched simutrans in 13 years?
21:57:04 <nielsm> I'm guessing similar to transport fever too, you define a route and then assign trains to that route
21:57:23 <nielsm> and train replacement is also done on a route basis
21:57:25 <frosch123> what's the matching order term for "bridge over everything"
21:58:33 <frosch123> andythenorth: most games do 1. orders, 2. assign vehicles to orders
21:58:52 <andythenorth> that's very logical
21:58:56 <andythenorth> I like our way :P
21:59:01 <frosch123> ottd and factorio do the reverse: 1. vehicles, 2. assign orders, 3. try to sync orders between vehicles
21:59:33 <frosch123> (for factorio, 3. requires a mod)
21:59:37 <andythenorth> I think we're pretty good
21:59:56 <andythenorth> I only want templates when consist length needs to change
21:59:56 <frosch123> another "bug" factorio copied from ottd :)
21:59:58 <nielsm> railroad tycoon had per-train orders, transport tycoon did roughly the same, simutrans came along and fixed it
22:00:12 <andythenorth> RT3 dispensed with orders
22:00:19 <andythenorth> it had a mad dispatcher system that was amazing
22:00:25 <frosch123> railroad tycoon allowed only like 32 trains or something
22:00:40 <andythenorth> I can make consists shorter, but not longer with rules :P
22:00:40 <nielsm> yeah original RRT was land of limits :)
22:00:48 <andythenorth> 'remove vehicles' is really clever
22:01:01 * andythenorth wonders about silly rule-based auto-replace
22:01:06 <frosch123> oh, right,... there were sequels, never played them, only version 1
22:01:08 <andythenorth> 'replace with 3 of x'
22:01:23 <nielsm> andythenorth that's why I'm suggesting regex for trains
22:01:48 <andythenorth> python list comprehension
22:01:56 <andythenorth> actually that would be fine :P
22:02:21 <nielsm> nah actual solution is to merge the shunting patch, then use conditional orders to have trains rebuild themselves
22:02:23 <andythenorth> [b for x in train if x is aj
22:02:37 <andythenorth> nielsm: oof, that might be mornington crescent
22:03:06 <andythenorth> the most complex game to explain to non UK people :P
22:19:49 <DorpsGek_II> [OpenTTD/OpenTTD] michicc updated pull request #6980: GDI engine for font glyph rendering as a replacement for FreeType https://git.io/fpEtn
22:40:20 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #6986: Allow the center tile to always get a house when playing with 3x3/Better https://git.io/fp92Q
22:46:11 <nielsm> that pretty much shoots down that PR as it is
23:08:07 *** andythenorth has left #openttd
continue to next day ⏵
