IRC logs for #openttd on OFTC at 2021-12-20
⏴ go to previous day
00:03:39 *** Tirili has quit IRC (Quit: Leaving)
02:59:42 *** Wormnest has quit IRC (Quit: Leaving)
03:05:40 *** _aD has quit IRC (Quit: leaving)
03:45:30 *** snail_UES_ has joined #openttd
04:06:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:59:27 *** snail_UES_ has quit IRC (Read error: Connection reset by peer)
06:37:20 *** Tirili has quit IRC (Remote host closed the connection)
07:22:33 *** sla_ro|master has joined #openttd
07:48:25 *** ChanServ sets mode: +v tokai
07:55:15 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:08:39 *** D-HUND is now known as debdog
08:24:36 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:37:59 *** andythenorth has joined #openttd
08:42:43 *** jottyfan has joined #openttd
08:58:56 *** tokai|noir has joined #openttd
08:58:56 *** ChanServ sets mode: +v tokai|noir
09:05:46 *** tokai has quit IRC (Ping timeout: 480 seconds)
09:15:02 *** Tirili has quit IRC (Quit: Leaving)
09:43:22 <andythenorth> might try dividing the map up into 'zones'
09:44:13 <andythenorth> rectangular, spaced along one axis of the map (the longest axis)
09:44:46 <andythenorth> so e.g. 512 x 256 would have 3 zones of about 170 x 256
09:45:15 *** jottyfan has quit IRC (Quit: jottyfan)
09:45:26 <andythenorth> eh the shorted axis would actually be irrelevant, unless square, in which case either random or a precedence rule
09:46:55 <peter1138> Use perlin to generate irregular zones.
09:47:18 <andythenorth> can we voroni partition something?
09:47:30 * andythenorth says words with only the vaguest understanding :P
09:48:00 <andythenorth> presumably if the boundaries were defined by an expression, calculating which zone any x,y is in is trivial?
09:48:02 <peter1138> Voroni is that one where you find a bit of javascript to generate a good looking terrain, but have no idea how to translate that to C++...
09:48:07 <michi_cc> Hmm, would it be a very bad idea to store the applied variety map for each area and expose a "biome" var to NewGRF? :p
09:48:25 <andythenorth> sometimes I think we need a bleeding edge branch to find out :P
09:48:32 <andythenorth> oh wait, we can PR :P
09:48:35 <peter1138> Yes because the variety stuff is bullshit
09:48:54 <andythenorth> hmm, what if there was also vertical partition :P
09:49:14 <andythenorth> so the tile z index is an offset into region A or B etc
09:49:27 <andythenorth> no, it wouldn't be that
09:49:36 <andythenorth> the tile Z would be an offset into different lists of regions
09:49:48 <andythenorth> so sea level might be farming vs. industrial
09:50:01 <andythenorth> mountain top might be sheep farms vs. mines vs. ski resorts
09:51:53 <andythenorth> anyway this is all great, but I try simple x,y rectangles and report back?
09:52:13 <andythenorth> so zone 1 might be hinterland / backcountry (forests, sheep farms, remote mines)
09:52:47 <andythenorth> zone 2 might be mixed
09:52:50 <andythenorth> zone 3 might be heavy industry
09:53:06 <andythenorth> problem is if zone 1 is entirely flat, and zone 3 is all mountains eh :D
10:07:15 <Eddi|zuHause> allocating "zones" like that sound like a task for map generator scripts
10:07:45 <Eddi|zuHause> like, say, common suggestions like "place more towns near water", or "name towns after the river"
10:09:26 <andythenorth> I wondered if trying to do it in grf is quite cart-before-horse
10:09:48 <andythenorth> all the pathological cases in industry grf arise because the map generated might be unsuitable
10:10:09 <andythenorth> seems like there might be a better way to solve that :P
10:10:20 <Eddi|zuHause> it's the old problem: do it in GRF, where you don't have the right tools or information available, or do it in script, and can't relay the right information to the grf
10:12:32 <andythenorth> or enable signalling to map gen to create some zones / biomes
10:12:44 <andythenorth> using relative weights or similar
10:13:21 <andythenorth> that could make for very boring maps if the grf always requests a specific configuration :P
10:15:47 *** WormnestAndroid has joined #openttd
10:22:56 <Eddi|zuHause> yes, the point of map generation is to have variation
10:23:58 <Eddi|zuHause> also, for larger maps, some people will want larger zones, and other people smaller zones, but more than one of each
10:24:37 <Eddi|zuHause> aanyway, maybe try assigning zones to towns, instead of map areas
10:25:06 <Eddi|zuHause> so "this is a mining town", "this is a farming town", "this is an industry town" etc.
10:31:10 <andythenorth> tried that already earlier this year :)
10:31:24 <andythenorth> the grf spec has a high friction for that idea
10:42:33 <Eddi|zuHause> not sure that is better in other directions :p
10:43:54 <nielsm> GRF doesn't have any way of knowing the absolute position of an entity on the map, right? you can examine neighboring tiles by relative offset but that's it
10:44:03 <andythenorth> I think I tried using mod(x) to define towns into 3 or 4 types
10:46:50 <andythenorth> iirc it fails when it runs up against other constraints
10:47:12 <andythenorth> like very low or very high town density
10:56:07 <dP> does openttd cache var 40+ and 60+ calls in the same action2?
10:59:13 <dP> also, it's amazing just how much logic can be shaved off in nfo with a bit of thinking vs naive nml implementation
11:48:45 *** jottyfan has joined #openttd
13:11:35 *** sla_ro|master has quit IRC ()
13:22:59 <glx> <dP> does openttd cache var 40+ and 60+ calls in the same action2? <-- only for vehicles and some variables
13:30:42 <DorpsGek> [OpenTTD/OpenTTD] FilmBoy84 opened issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
13:33:49 <DorpsGek> [OpenTTD/OpenTTD] FilmBoy84 commented on issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
13:40:41 <DorpsGek> [OpenTTD/OpenTTD] FilmBoy84 commented on issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
13:43:54 <dP> action3 seems to be able to map multiple action0 to one action2, but is there a way for action2 to know which action0 it's currently working with?
13:45:14 <glx> depends on variables available for a given feature I think
13:47:51 <dP> hm, I'd expect it to be some global variable
13:48:41 <dP> I guess feature vars can inspect the feature itself but that's kind of a roundabout way to get it
13:53:28 <glx> for vehicles there is varC6
13:56:32 <glx> objects seem to have var60 for that
13:58:57 <dP> yeah, but var60 looks awfully ineffecient for just getting id
13:59:13 <dP> I may as well just spam action2+3s for every set
13:59:51 <glx> in nml you could use a parameter for your action 2
14:00:41 <glx> in nfo a temp value can achieve the same
14:01:23 <dP> wdym? I'll have to make var60 call to populate that value, no?
14:01:57 <glx> I mean in the action 3, the called action 2 would be store_temp, then call the common action 2
14:02:26 <glx> and you manually store the id in temp value
14:02:28 <dP> what I mean is that I want to avoid using var60 at all
14:02:44 <dP> since it's a nearby bitstuffed thing
14:02:53 <glx> when writing the action 3 you know the id
14:03:43 <dP> yeah, but if I have one action 3 for multiple features I have not a single id but a list
14:04:05 <dP> if I do action2+action3 for each then, sure, I can do it
14:04:11 <dP> but question was about single action3
14:04:45 <dP> multiple features I mean multiple action0, same feature
14:05:56 <glx> oh I see, nml doesn't use this option it seems :)
14:06:54 <glx> but "This creates a generic feature-specific definition not associated with any particular item"
14:07:16 <glx> so yeah it's not supposed to select stuff based on id in action2
14:08:01 <glx> ah no that's when n-id is 0
14:13:27 <dP> looking at openttd code, var60 seems to be the only way
14:14:30 <glx> yup, and var66 for houses it seems
14:15:36 <glx> for industries it seems there's varA6
14:16:45 <dP> yeah, there are some other vars but I'm only interested in objects atm
14:17:59 <glx> while there is a nice GetDebugID() for all features
14:19:35 <dP> I don't see it being exposed to the newgrf itself
14:19:49 <glx> no, it's used only by the profiler
14:22:59 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
14:25:34 <glx> ok values that could be useful are optimised out, let's try to reproduce
15:03:05 <glx> I get the same assert when building a train
15:05:29 <dP> is opengfx+ trees source still available somewhere?
15:05:46 <glx> probably only on ottdcoop
15:07:07 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
15:07:34 <dP> glx, is that a yes or no? ;)
15:07:59 <glx> as ottdcoop is still down I'd say no
15:10:08 <dP> grfcodec it is then I guess
15:10:18 <dP> or I can just copy sprites binary, lol
15:16:21 <glx> I guess the issue is mismatching args for command callbacks, but it's a pain to follow with all the magic :)
15:23:26 <michi_cc> Silly error by me. I forgot to modify MakeUnpackNetworkCommandCallback in network_command.cpp when updateing some callback stuff.
15:24:43 <glx> yeah MakeUnpackNetworkCommandCallback seem to not do what it's supposed to do
15:26:59 <glx> like generating unneeded callbacks and skipping needed ones
15:33:06 *** Wormnest has joined #openttd
16:02:52 <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #9757: Fix #9756: Network command unpack proc was not generated in all cases. https://git.io/JDFZe
16:06:52 <michi_cc> Anyway, the assert I added was at least not useless :)
16:13:13 *** frosch123 has joined #openttd
16:23:42 *** supermop_work has joined #openttd
16:29:52 *** gelignite has joined #openttd
16:31:56 *** andythenorth has quit IRC (Quit: andythenorth)
16:32:25 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
16:35:27 <michi_cc> Is it just me or is msys CI getting slower and slower?
16:35:57 <glx> disk access are slow in msys
16:36:44 <michi_cc> glx: Okay, that is for you: network_command.cpp:(.pdata$_ZNSt11_Tuple_implILy6EJjEEC2IRjEEOT_+0x0): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against `.text$_ZNSt11_Tuple_implILy6EJjEEC2IRjEEOT_'
16:38:02 <michi_cc> Oh, and it is actually not something with this PR, #9577 and #8480 have the exact same failure.
16:40:50 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:40:59 <glx> maybe an update for the VMs
16:41:46 <michi_cc> Let's try by rerunning #9754.
16:43:42 <glx> hmm no, same virtual environment for #9755 and #9757
16:46:54 <michi_cc> There were two commits since #9755/9754, one is a pure doxygen comment one and the other is touching order_backup.cpp only.
16:51:10 <glx> ok switching from x64-debug to mingw64-debug, let's see what happens locally
17:03:29 *** Flygon has quit IRC (Remote host closed the connection)
17:10:39 <michi_cc> Hmm, #9754 still compiles fine.
17:11:41 <michi_cc> glx: I think this is some internal mingw64 limit that is reached. J0anJosep's PR add a new CcRemoveRailDepot, which causes more functions to be generated in network_command.cpp, just like my PR just now.
17:12:28 <glx> still waiting for linking to finish on master
17:12:44 <DorpsGek> [OpenTTD/OpenTTD] nchappe commented on pull request #9693: Fix travel times stored in the linkgraph https://git.io/JDFgo
17:21:32 *** Wormnest has joined #openttd
17:29:34 *** andythenorth has joined #openttd
17:35:00 <frosch123> mingw exceeded 2GB of static symbols?
17:40:47 <michi_cc> I don't think it needs to exceed 2GB of static symbols, but just place the table and the functions more than 2GB apart (which, if in different sections, don't need to be continuous).
17:47:32 <glx> hmm and I'm still with gcc 10.3, let's upgrade to 11.2 like CI
17:47:50 <glx> because master should build fine
17:54:06 <LordAro> could try switching the ci to clang
17:54:37 *** jottyfan has quit IRC (Quit: jottyfan)
17:55:30 <glx> anyway msys failure is not blocking
18:04:28 <michi_cc> Still need some PR approvals, though :)
18:11:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9754: Change: [Admin] Bump admin port protocol due to command changes. https://git.io/JDFXn
18:20:23 *** NGC3982 has quit IRC (Quit: byte av psu)
18:21:27 *** Etua has quit IRC (Quit: Etua)
18:22:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9755: Codechange: [Script] Prettify squirrel call helpers by using C++17. https://git.io/JDF17
18:25:15 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9755: Codechange: [Script] Prettify squirrel call helpers by using C++17. https://git.io/JDSEV
18:30:31 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9754: Change: [Admin] Bump admin port protocol due to command changes. https://git.io/JDS08
18:39:05 *** sla_ro|master has joined #openttd
18:53:11 *** NGC3982 has joined #openttd
19:13:21 * andythenorth wonders what the neatest way to partition the map is, in an nml switch
19:13:31 <andythenorth> probably not one switch :P
19:19:19 <supermop_work> had a lot of town zone ideas while in hnl last week
19:20:11 <supermop_work> also is it worse to have like 4 houses in a set, or one house with switches to pick 4 different sprites?
19:22:24 <supermop_work> also is it worse to have a house with a switch to composite various child sprites onto it, or a switch to pick various prebaked sprites?
19:24:24 <frosch123> andythenorth: did you try "every town only allows one type of industry, first industry stores it's type in town register, other industries check the register and fail"
19:25:52 <andythenorth> I did, but I forget why it didn't work
19:25:54 <andythenorth> there was a reason
19:26:40 <andythenorth> I had some classes of town
19:26:52 <andythenorth> the implementation was different but eh
19:27:26 <andythenorth> there were pathological cases with high and low town density
19:27:40 <andythenorth> and something was strange if all industries in a town closed
19:30:59 <andythenorth> maybe I solved Steeltown industry distribution without needing to force it to towns
19:31:27 <andythenorth> I think I tested it, and concluded for Steeltown that industry clustering by distance is far more important than distributing into biomes or industry regions
19:32:43 <supermop_work> "great lakes" is basically all one region anyway
19:33:10 <andythenorth> basically I just need x / 3
19:33:23 <andythenorth> for 3 bands of different industry types
19:33:35 <andythenorth> where x is map size
19:46:26 <frosch123> sounds unplayable on stupidly large maps, but maybe that's the intention
19:52:03 <andythenorth> well I'd scale by dividing over 512 or something
19:52:13 <andythenorth> I usually wait for someone else to tell me the maths :P
19:52:48 <andythenorth> the current clustering scales into quadrants of 256x256 I think
20:13:46 *** Kitrana has joined #openttd
20:15:05 <supermop_work> dividing the map could still be nice for making towns look different
20:15:17 *** WormnestAndroid has joined #openttd
20:19:15 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
21:10:28 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9757: Fix #9756: Network command unpack proc was not generated in all cases. https://git.io/JDbIK
21:13:41 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9700: [Fix]: supress vehicle age warnings if vehicle is stopped by player https://git.io/J134c
21:13:44 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9718: Change: Suppress vehicle age warnings for stopped vehicles https://git.io/JM3Th
21:53:08 <glx> ok after a very long upgrade of my msys2/mingw env, master builds fine with gcc 11.2
21:53:19 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9745: Fix #9720: Delay start of GS/AI to after loading of savegame https://git.io/JDbmF
22:10:20 *** andythenorth has quit IRC (Quit: andythenorth)
22:11:24 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:18:04 *** gelignite has quit IRC (Quit: Stay safe!)
22:32:27 <DorpsGek> [OpenTTD/OpenTTD] michicc closed issue #9756: [Bug]: Multiplayer Level Ground Tool - Assertion Failed Line 336, network command.cpp https://git.io/JDdr0
22:32:30 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9757: Fix #9756: Network command unpack proc was not generated in all cases. https://git.io/JDFZe
22:32:47 <michi_cc> glx: No idea if master is now broken or not :(
22:33:53 <glx> #9757 failed to link in my local test
22:34:14 *** sla_ro|master has quit IRC ()
22:35:47 <michi_cc> As it is/was only mingw-x64 and no other compiler or platform, I'm assuming the code itself is probably fine and mingw does something stupid.
22:36:51 <glx> we had a long time issue with apple clang and settings array
22:38:24 <glx> and it seems mingw gcc 11.2 worked where mingw gcc 10.3 didn't, and no it also fails
22:52:18 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
22:53:41 *** Kitrana has joined #openttd
23:05:21 *** nielsm has quit IRC (Remote host closed the connection)
23:06:45 <glx> as I understand, IMAGE_REL_AMD64_ADDR32NB is specific to PE
23:09:52 <michi_cc> Yeah, but MSVC seems to do something different to not have any problems with relocations.
23:10:24 <glx> I should check msvc clang
23:19:51 *** Etua has quit IRC (Quit: Etua)
23:22:50 <glx> ok it's fine for msvc clang
23:33:18 <glx> trying mingw with clang now
23:49:31 *** ChanServ sets mode: +v tokai
23:56:20 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵