Log for #openttd on 6th June 2021:
Times are UTC Toggle Colours
00:08:06  *** Gustavo6046 has joined #openttd
00:10:29  *** Smedles_ has joined #openttd
00:10:35  *** Smedles has quit IRC
00:28:10  *** HerzogDeXtEr1 has quit IRC
00:37:58  *** Progman has quit IRC
02:05:38  *** Wormnest has quit IRC
02:28:19  *** Flygon has joined #openttd
02:36:31  *** glx has quit IRC
02:59:49  *** Smedles_ has quit IRC
03:04:06  *** Smedles has joined #openttd
03:49:21  *** tokai has joined #openttd
03:49:21  *** ChanServ sets mode: +v tokai
03:59:43  *** nielsm has joined #openttd
05:50:15  *** tokai|noir has joined #openttd
05:50:15  *** ChanServ sets mode: +v tokai|noir
05:57:04  *** tokai has quit IRC
07:15:24  *** gelignite has joined #openttd
07:16:56  *** andythenorth has joined #openttd
07:17:57  <andythenorth> yo
07:18:30  <andythenorth> if I have 255 permanent register available to me
07:18:43  <andythenorth> and a set of flags, covering maybe 16 different bool values
07:18:58  <andythenorth> do I 'waste' a register on each flag?
07:19:07  <andythenorth> or do I piss around with bitmasks?
07:20:36  *** Progman has joined #openttd
07:21:32  <peter1138> Is it like memory where having free memory is the real waste?
07:22:09  <andythenorth> [shrug macro]
07:22:50  <andythenorth> I guess I just use a register per flag
07:23:03  <andythenorth> bitmasks require me to be a better programmer than I am
07:26:43  <andythenorth> if the number of flags exceeds the first bitmask size, I'd have to start managing which flag is in which register
07:27:48  <DorpsGek> [OpenTTD/nml] andythenorth updated pull request #211: Feature: support for vehicle var 4E, date_of_last_station_departure
07:39:54  <TrueBrain> premature optimizations is the worst kind of optimization
07:42:17  <andythenorth> T-shirt time
07:42:28  <TrueBrain> they already exist
07:42:29  <TrueBrain> for years
07:42:30  <TrueBrain> :P
07:42:43  <andythenorth> also meh
07:42:58  <andythenorth> I had a nice idea to try and make some towns have a type, e.g. 'farm town', 'mine town'
07:43:11  <andythenorth> and then prevent some other industries locating in those towns
07:43:17  <andythenorth> so the map has nice flavour
07:43:39  <andythenorth> but it will deadlock if player has town count < number of my town types
07:43:49  <andythenorth> preventing deadlocks in newgrf is a cluster fuck :D
07:44:20  <andythenorth> lots of ideas have to be discarded due to 'but player might set some really corner case settings'
07:44:39  <andythenorth> or I could just stop reading any of the social sites for this game, which would 'solve' the problem for me
07:44:46  <andythenorth> no more reddit, steam or forums
07:45:32  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9333: Codechange: merge guiflags and flags in settings .ini files
07:45:57  <andythenorth> I could try and add a var for number of towns
07:46:01  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9335: Codechange: make [Save|Load]Settings() behave more like other Save/Load code
07:46:03  <andythenorth> maybe it's just length of towns array or something
07:46:17  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
07:46:18  <TrueBrain> sorry for the spam, had to rebase the lot :)
07:46:26  <andythenorth> such rebase spammer
07:46:30  <andythenorth> goes it temp kban?
07:46:39  <TrueBrain> poor DorpsGek
07:55:11  *** tokai has joined #openttd
07:55:11  *** ChanServ sets mode: +v tokai
07:56:15  * andythenorth wonders if grf design would be improved by never ever ever reading the OpenTTD internet :D
07:56:17  <andythenorth> hmm
07:58:34  <andythenorth> ha maybe I just found an interesting exploit
07:58:56  <andythenorth> industries can read parent town vars in CB 28, even though industry doesn't exist
07:59:05  * andythenorth wonders if town registers can be written/read in CB 28
07:59:22  <TrueBrain> owh boy
08:01:00  * andythenorth tests it
08:01:09  <andythenorth> 'wondering' achieves pretty much FA
08:02:00  *** tokai|noir has quit IRC
08:05:49  <andythenorth> boo
08:06:06  <andythenorth> can't seem to write to town register in CB 28
08:06:25  <andythenorth> I guess certain specific vars have been exposed to that CB
08:11:10  <andythenorth> oh the town register display doesn't update when written to
08:11:12  <andythenorth> hmm
08:11:50  <andythenorth> have to use windowshade to get the display to update
08:20:17  * andythenorth still trying to circumvent grf industry having no global storage, and limited view of the map / game state
08:27:50  <andythenorth> are town indexes [random | somewhat random | predictable] with respect to map position
08:28:06  <TrueBrain> random
08:28:13  <andythenorth> so lower indexed towns are not more likely to be in north, or some similar pattern?
08:28:25  * andythenorth has ideas
08:28:44  <andythenorth> town index never changes, even if more towns are built?
08:28:59  <TrueBrain>
08:29:01  <TrueBrain> random
08:29:21  <TrueBrain> in general, an index doesn't change ... as otherwise .. it wouldn't be an index :P
08:29:28  <andythenorth> these are things I hoped
08:29:35  <andythenorth> my dreams aren't shattered
08:36:15  *** iSoSyS has joined #openttd
08:36:40  <peter1138> Why would that be an exploit? It should be the nearest town of the industry... if it did exist.
08:37:53  *** iSoSyS has quit IRC
08:38:21  <peter1138> Blooddy gate springs.
08:38:44  <peter1138> I guess there's a reason they cost about 50p.
08:38:52  <peter1138> Okay, £2.79.
08:41:16  <andythenorth> it broke?
08:41:24  <andythenorth> or the mounting to the post broke?
08:42:21  <peter1138>
08:42:42  <peter1138> One of these type things. The little dowels at the top and bottom that make it work just fall out, cos stupid design.
08:43:18  <andythenorth> yeah we have one, it breaks every few years iirc
08:43:33  <peter1138> It needs tension to keep the dowels in, but if you give it enough tension the spring itself buckles.
08:44:05  <andythenorth> exploit is doing something in grf that I'm supposed to do in GS
08:44:13  <andythenorth> but it's moot because the exploit doesn't exist
08:44:35  <peter1138>
08:44:43  <peter1138> Might work better but... unavailable. Hmm.
08:45:39  *** tokai|noir has joined #openttd
08:45:39  *** ChanServ sets mode: +v tokai|noir
08:48:54  *** nielsm has quit IRC
08:52:31  *** tokai has quit IRC
08:53:04  <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #9289: Change: Shortcut varaction chains for callbacks.
09:01:20  *** jottyfan has joined #openttd
09:22:27  <peter1138> "hmm"
09:23:56  <peter1138> My vacuum cleaner is sucking at suckinbg.
09:30:00  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9338: Several code refactors of the SaveLoad code
09:32:44  <TrueBrain> oops, forgot to drag in the dependency ..
09:33:21  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
09:33:42  <andythenorth> I thought I had a nice idea to use town registers to set a town as 'coal mining' or whatever
09:33:48  <andythenorth> and co-locate other industries
09:34:05  <andythenorth> but it's same as industry_town_count
09:34:09  <andythenorth> le oof
09:36:52  *** Wolf01 has joined #openttd
09:36:58  <peter1138> Hmm, there's a bench mark thing isn't there...
09:37:21  <TrueBrain> for a vacuum cleaner?
09:37:28  <peter1138> Probably.
09:37:34  <peter1138> But also for sprite resolvers.
09:39:18  <peter1138> Ah but it's per grf. Hmm.
09:44:55  <TrueBrain> saveload/saveload.cpp:1392:42: error: template template argument has different template parameters than its corresponding template template parameter
09:44:56  <TrueBrain> LOL
09:45:25  <TrueBrain> and MSVC / GCC are fine with it, just clang that is being a little bitch
09:51:11  *** Samu has joined #openttd
09:57:17  <TrueBrain>
09:57:22  <TrueBrain> anyone any clue why clang doesn't like that?
10:03:41  *** WormnestAndroid has quit IRC
10:03:54  *** WormnestAndroid has joined #openttd
10:13:46  <Rubidium> because std::list has two template parameters?
10:14:39  <TrueBrain> well, an "allocator", which is assigned a default value
10:14:46  <TrueBrain> its weird that only clang doesn't appreciate this ..
10:15:28  <Rubidium> maybe you need to pass the type of element in the list too?
10:15:58  <Rubidium> return SlStorageHelper<std::list<void *>, void*>::SlCalcLen(...)
10:16:34  <TrueBrain> that requires some more changes than just that, but it is just weird that clang doesn't accept something that both GCC and MSVC do
10:16:38  <TrueBrain> that is a rather unusual combination
10:24:32  <TrueBrain> okay, it is the allocator being an issue
10:24:34  <TrueBrain> funny ..
10:24:39  <TrueBrain> even latest clang doesn't work
10:26:36  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
10:44:11  <andythenorth> hmm, can't write town storage in CB 28, can I read it?
10:44:20  *** sla_ro|master has joined #openttd
10:44:54  *** Progman has quit IRC
10:45:11  *** sla_ro|master has quit IRC
10:49:38  *** sla_ro|master has joined #openttd
10:52:36  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
10:53:12  <TrueBrain> I need to change 2 RIFFs into ARRAYs, and 6 (+2) ARRAYs into TABLEs
10:53:16  <TrueBrain> out of the 79
10:53:22  <TrueBrain> so .. 90% of the work is done :P
10:54:15  <michi_cc> andythenorth: IndustriesResolverObject::GetTown() seems to read to me that reading should be possible, while writing can only be done for existing industries.
10:55:12  <andythenorth> thanks
10:55:22  <andythenorth> that helps :)
10:55:47  * andythenorth going to test having 'farming towns' and 'heavy industry towns'
10:56:04  <andythenorth> strictly I can do it without town registers by counting industries
10:56:20  <andythenorth> but this will be an interesting test of town registers
10:56:31  <michi_cc> During CB 28, the related town should be whatever town is closest to the proposed tile index.
10:56:39  <andythenorth> good :)
10:56:50  * andythenorth is hoping we might extend 'town' to 'region' also, if a use case is presented
10:57:07  <andythenorth> 'region' could just be a town designated as regional capital
11:13:34  *** andythenorth has quit IRC
11:50:02  *** Speedyn has joined #openttd
11:54:45  *** Speedy` has quit IRC
12:01:06  *** frosch123 has joined #openttd
12:07:30  <Samu> wow, you created about 1100 commits in such a small amount of time
12:16:34  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
12:16:35  <TrueBrain> okay, cheat-chunk done .. that was a special one :P
12:16:52  <TrueBrain> now it is a lot easier to see what cheats were used in a savegame, without loading it in :)
12:17:02  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #7918: Fix 3c047b1: AIGroup.GetProfitLastYear could get values different than those displayed in gui
12:18:06  <TrueBrain> .env/bin/python -m savegame_reader Unnamed,\ 2nd\ Jan\ 1950.sav --export-json | jq .CHTS
12:18:08  <TrueBrain> to be exact :P
12:19:48  *** Progman has joined #openttd
12:23:19  *** andythenorth has joined #openttd
12:30:31  <frosch123> nice, i did not know jq
12:30:52  <TrueBrain> it has passed by this channel many times before ;)
12:31:06  <TrueBrain> too bad it only does JSON and not YAML .. the YAML variant is not pre-installed on most OSes :)
12:31:39  <TrueBrain> you can do crazy complex shit with jq btw .. it is really powerful
12:33:46  <TrueBrain> who wrote linkgraph SaveLoad .. hmm
12:33:58  <TrueBrain> it is so different from everything else
12:35:11  <TrueBrain> it is worse than stations :P
12:36:29  <TrueBrain> right, lets tackle it .. first, I need a savegame with linkgraphs .. lets see if I have one :)
12:37:52  <TrueBrain> yeah, I do, w00p
12:42:28  <frosch123> i guess you have plenty of tools to look for certain chunks in savegames now :)
12:52:04  *** sla_ro|master has quit IRC
12:56:03  <andythenorth> am about to learn how little I know about set theory
12:56:17  <andythenorth> experimenting with 'farming towns' and 'heavy industry towns'
12:56:32  <andythenorth> where industries of one type can't co-locate in the same town with industries of the other type
13:06:06  *** tokai has joined #openttd
13:06:06  *** ChanServ sets mode: +v tokai
13:12:00  <andythenorth> any possibility reading a town register clears it?
13:12:09  * andythenorth has an odd result
13:12:59  *** tokai|noir has quit IRC
13:13:40  <TrueBrain> frosch123: only after conversion, which is the issue :P :P
13:14:26  * andythenorth finds local error
13:15:23  <TrueBrain> the human?
13:15:23  <TrueBrain> :D
13:16:12  <andythenorth> human
13:19:44  <frosch123> it's always the mammals
13:24:39  <andythenorth> I see
13:24:44  <andythenorth> never the slugs?
13:27:42  <andythenorth> hmm
13:27:54  <andythenorth> in which andythenorth tries to learn how to write bitmasks from nml + python
13:28:06  *** Progman has quit IRC
13:30:29  <andythenorth> I can use hasbit() to read them
13:30:40  <andythenorth> but how do I set bits?
13:30:41  <andythenorth> hmm
13:33:59  <andythenorth> nvm, there's a better way
13:34:33  <TrueBrain> there always is :D
13:38:48  <Samu> #7918 autoreplace group statistics copying is so confusing
13:45:52  <Samu> From the proposed 2 methods, I still prefer the first
13:46:00  <Samu> doesn't touch autoreplace code
13:47:09  <Samu> there's a misconception on what "profit_last_year" actually means
13:47:42  <Samu> the comment describing it is not clear enough
13:54:02  <Samu> hey peter1138, #7918 is actually about your code
13:54:08  <Samu> wanna review?
14:06:44  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
14:07:01  *** Progman has joined #openttd
14:08:46  <TrueBrain> right .. now to find a way to have a struct in a struct ... hmmm
14:09:09  <TrueBrain> not difficult how to store it in the savegame .. difficult part is figuring out how to neatly deal with the variables in the code itself :D
14:13:25  <andythenorth> town registers are quite neat
14:13:33  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8390: Add: [AI/GS] Missing water related functions and objects
14:13:37  <andythenorth> I'm using them for things I could do with industry count and distance checks
14:14:02  <andythenorth> but I'm assuming reading a register once is much faster than recursively checking distance and counts to a list of n industry types
14:14:14  <TrueBrain> are you a wizzard? :D
14:14:29  <andythenorth> double z?
14:14:38  <TrueBrain> wizzzzzzard
14:14:52  <Samu> testing regression ai is giving me some unrelated output comparisons
14:15:48  <frosch123> yeah, i see some parallels between andy and rincewind
14:15:57  <TrueBrain> who?
14:15:59  <andythenorth> visually?
14:16:13  <andythenorth> I don't have any luggage
14:16:35  <frosch123> TrueBrain: discworld stuff
14:16:42  <TrueBrain> ah
14:16:44  <andythenorth> is it the way I can _nearly_ program, but not quite?
14:16:52  <andythenorth> like RW can nearly do magic?
14:17:01  <TrueBrain> oh-oh, CI is ratting out that I didn't run it locally
14:17:16  <frosch123> TrueBrain: there are many wizards in discworld, but only one wizzard
14:17:55  <frosch123> andythenorth: rincewind knows that he is faster than horses on short distances
14:18:08  <andythenorth> hmm
14:18:11  <andythenorth> Horse
14:19:04  <andythenorth> anyway I now have towns being 'claimed' as farming, extractive, or heavy industry
14:19:13  <andythenorth> or unclaimed
14:19:22  <andythenorth> and I have industries which will refuse to locate in some of those
14:19:34  <andythenorth> and some which are happy to locate anywhere
14:19:55  <andythenorth> but I haven't tried on small maps
14:19:57  <andythenorth> low town maps
14:20:04  <andythenorth> low industry or hight industry map
14:20:10  <andythenorth> mountainous maps
14:20:16  <andythenorth> high water % maps
14:20:28  <andythenorth> high desert %
14:20:34  <andythenorth> or low snowline
14:20:44  <andythenorth> nor for performance on very large maps
14:21:16  <andythenorth> writing industry placement rules is lol
14:21:23  <andythenorth> did we go through something related to that recently? :P
14:22:36  <Samu> my regression run comparison
14:22:44  <Samu> seems weird
14:28:06  <Samu> well, it passed over there, so i guess it's fine
14:28:41  <andythenorth> hmm town types
14:28:48  <andythenorth> so .... town subtypes also? o_O
14:39:19  <TrueBrain> sure
14:39:28  <TrueBrain> hmm .. that moment some savegames load fine, others crash and burn
14:39:29  <TrueBrain> annoying :D
14:40:27  <TrueBrain> ah .. lol
14:41:26  <TrueBrain> it helps to fix pointers correctly after loading :P
14:41:27  <TrueBrain> no clue why :D
14:42:07  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
14:45:05  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
14:46:20  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8398: Change: Distribute left over cargo to stations according to the highest remainder
14:47:28  *** glx has joined #openttd
14:47:29  *** ChanServ sets mode: +v glx
14:48:49  <glx> Samu: you need to manually delete notperfectai-1.3 because it has same internal version as 1.5
14:50:08  <glx> same for silicon_valley-35944, you have it in global content_download and in a local folder too
14:50:29  <glx> probably in bin
14:52:56  <Samu> i see
14:57:55  <DorpsGek> [OpenTTD/team] ilyabakhlin opened issue #226: [es_ES] Translator access request
15:02:41  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8492: Fix: Don't allow towns to terraform certain floodable tiles
15:09:00  *** virtualrandomnumber has joined #openttd
15:09:21  *** virtualrandomnumber has quit IRC
15:09:59  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8514: Change: Allow to build dock on clearable watered object tiles
15:20:53  <andythenorth> hmm I really should use a bitmask
15:20:59  <andythenorth> I have NFI how to write one in code
15:21:17  <andythenorth> I need to set a specific bit in a town register, without over-writing any existing bits
15:21:41  <andythenorth> looks like nml bitmask() might be for that case?
15:21:50  <andythenorth>
15:22:47  <andythenorth> isn't this just AND of a specific bit with the existing value?
15:24:33  <FLHerne> Yes
15:24:45  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8517: Codechange: Make void tiles flood edge tiles, instead of edge tiles flooding themselves
15:25:12  <FLHerne> You just want `old_value & (1 << n)`
15:25:21  <FLHerne> Or just precalculate 1 << n and use that
15:25:37  <FLHerne> `old_value & bitmask(n)` would work too
15:26:07  <FLHerne> Er
15:26:08  <FLHerne> Should be OR, so |
15:26:53  <FLHerne> `old_value | (1 << n)`
15:28:02  <glx> yeah & is for testing :)
15:29:07  <glx> and unseting in combination with ~
15:32:03  <andythenorth> and n is the bit number I want to set yes?
15:32:15  <andythenorth> and if I wanted to unset it, (0 << n)?
15:32:53  <glx> to unset it's old & ~(1<<n)
15:33:09  <andythenorth> ooh
15:33:09  <andythenorth> hmm
15:33:51  <andythenorth> thanks :)
15:34:12  * andythenorth wonders how many bits are in a town register :P
15:34:12  <andythenorth> can probably google that
15:34:26  <andythenorth> 32 bit registers
15:53:46  <andythenorth> old_value | bitmask(n) would work also?
15:57:06  <FLHerne> Yes
15:57:36  <glx> only to set
15:58:51  <andythenorth> thanks
15:58:58  * andythenorth needs a bitmask for up to 64 cargos, but registers only support 32 bit :P
15:59:19  <andythenorth> oops
15:59:19  <glx> 2 registers
15:59:49  <andythenorth> yeah, not sure how I'd split across them yet
15:59:49  <andythenorth> I guess I know the bit number
15:59:49  <andythenorth> so I just split on that
16:00:11  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8609: Fix: Equalise the number of frames needed for road vehicles to traverse different radius curves
16:02:13  <andythenorth> oh
16:02:29  * andythenorth is setting some flags in town registers when industry is constructed
16:02:33  <andythenorth> but industries can also be removed :P
16:02:41  <andythenorth> there's no callback I can use to cleanup
16:02:44  <andythenorth> oof
16:02:47  <andythenorth> lol also
16:03:28  <andythenorth> these are the problems that cause GS to be the recommended solution
16:04:06  <andythenorth> except for the small issue that's it not recommended to make a GS for a specific industry grf
16:04:07  <andythenorth> oof
16:04:46  <andythenorth> no way to unset flags
16:04:51  <andythenorth> kills this idea stone dead :)
16:04:54  <andythenorth> oh dear
16:06:19  <glx> it's possible to make a GS for a specific industry grf, but there's no way to ensure the correct industry grf is loaded
16:06:40  <glx> (well you can always check industry names)
16:07:04  <_dp_> there is a waya
16:07:21  <_dp_> run a server :p
16:07:21  <andythenorth> it's a route
16:07:40  <andythenorth> but no
16:07:40  <_dp_> xD
16:08:21  <andythenorth> if I set a flag for 'is farming town'
16:08:30  <andythenorth> and the player magic bulldozes all the farms
16:08:38  <andythenorth> there's no way to unset the flag
16:09:25  <andythenorth> there's no town callback than can run e.g. monthly and run a census of industry types and ask them what flags to set
16:09:27  <andythenorth> I can't use the industry monthly cb to clean up because it won't run if the industry is deleted
16:10:27  <andythenorth> I could have one industry do the clean up for all the others, but if the town has no industry...
16:10:27  *** tokai|noir has joined #openttd
16:10:27  *** ChanServ sets mode: +v tokai|noir
16:10:27  <andythenorth> GS can't do it, because GS is blind to industry town registers, and that seems to be non-negotiable
16:11:30  <andythenorth> I could not use a bitmask, and instead use a register for each flag
16:11:42  <andythenorth> I could store the date last set, and update that monthly
16:12:07  <andythenorth> then if the date > 1 month ago when reading it, assume the flag is unset
16:12:17  <andythenorth> that breaks if date cheat is used
16:12:41  <andythenorth> and I don't know what daylength will do with it
16:12:41  <andythenorth> and it leaves a 1 month window where an industry might have been deleted
16:14:07  <andythenorth> OpenTTD modding: 'lol'
16:17:24  *** tokai has quit IRC
16:19:59  <andythenorth> well...some of this I can do without using town registers
16:20:20  <andythenorth> I can pre-compose a set of checks in python, and rely on var for industry counts per town
16:20:39  <andythenorth> and create nml procedures for each check
16:21:12  <andythenorth> just town registers holding flags would be a neat solution, where the 'check' is just read a bit
16:21:35  <andythenorth> and I wanted to try out town registers also :P
16:30:05  <michi_cc> Why does magic bulldozer needs to reset any flags? Somebody who bulldozers and manually places everything doesn't seem like target audience for this.
16:31:06  <michi_cc> If you'd want to be somewhat nice, you could ignore any flag checks if an industry is manually built by the player and use this to potentially reset the flags.
16:34:29  <andythenorth> it's more that industry removal might need to unset flags
16:34:37  <andythenorth> I suspect it's a sign that the idea is generally bad :)
16:35:42  <andythenorth> some industries I only want to build in a town where there is another industry producing or accepting cargo x
16:35:58  <andythenorth> that would have been nice to have in a flag
16:36:08  <andythenorth> but I can work it all out in the python compile instead
16:36:20  <andythenorth> and just use the industry counts by id
16:37:15  <andythenorth> I was hoping to use town flags because I'm hoping we can do regions
16:37:24  <andythenorth> and there's no var for industry counts by region
16:37:26  <andythenorth> only by town
16:44:51  <peter1138> Add one
16:54:44  *** nielsm has joined #openttd
17:06:44  *** Webster has joined #openttd
17:17:12  *** Wormnest has joined #openttd
17:25:48  <TrueBrain> frosch123: <- I was thinking of doing something like this for "lists of structs" .. at top, a diff (that doesn't compile) and at the bottom the important bits of town_sl.cpp
17:25:51  <TrueBrain> opinions? :D
17:30:18  *** sla_ro|master has joined #openttd
17:31:03  <TrueBrain> ugh, we should change chunk-handlers into classes .. so you can just overload the function you implement
17:31:10  <TrueBrain> removes all the weird table-stuff we now have
17:32:52  <TrueBrain> hmm, would allow per-chunk-storage which I kinda need for the step after this .. so it is not even a terrible idea ..
17:34:00  *** tokai has joined #openttd
17:34:00  *** ChanServ sets mode: +v tokai
17:34:10  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9180: Codechange: Remove FOR_ALL_CHUNK_HANDLERS
17:35:10  <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #9180: Codechange: Remove FOR_ALL_CHUNK_HANDLERS
17:35:19  <glx> have fun with rebase :)
17:35:33  <TrueBrain> tnx :D
17:36:21  <glx> and yeah a ChunkHandler class could be a good idea
17:37:17  <glx> well there's already one :)
17:37:29  <glx> but it's basic
17:38:04  <michi_cc> It is a class. I mean a struct is just a class that defaults to public.
17:38:04  <glx> yeah I know
17:39:04  <andythenorth> hmm
17:39:04  <TrueBrain> michi_cc: okay mister-nitpicking, I meant a class with overloadable functions instead of function-pointer-variables :)
17:39:04  <andythenorth> wtf is a region anyway
17:40:51  *** tokai|noir has quit IRC
17:41:48  <frosch123> TrueBrain: i don't know enough of the saveload code to follow your example. but did you consider using template specialisation to map structures to saveload descs, instead of all the enums?
17:42:29  <TrueBrain> frosch123: I do not understand what you are showing me there :D
17:42:34  <TrueBrain> so let me first explain a bit what my diff is about
17:42:36  <TrueBrain> then you can explain yours ;)
17:42:41  <TrueBrain> my diff, the bottom part mostly
17:42:44  <TrueBrain> (the town_sl.cpp)
17:42:53  <TrueBrain> I need a way that the sub-list can be in the _desc[]
17:42:54  <glx> I like the idea of replacing pointers with virtual functions
17:42:59  <TrueBrain> but has all the freedoms of implementing it
17:43:14  <TrueBrain> so I made a small callback system for each sub-list
17:43:19  <TrueBrain> that calls a function with the object and enum value
17:43:24  <TrueBrain> so you can do what-ever-the-fuck-you-want with it
17:43:36  <TrueBrain> static void Load_TOWN_sub(TownSubChunk id, Town *t) <- that one
17:43:53  <frosch123> yes, but instead of using a callback with an enum, you could put the callback functions directly into the SaveLoad desc?
17:44:21  <TrueBrain> not easily, as there is not much
17:44:32  <TrueBrain> the only way to do that, is to abuse the pointer that is in there
17:44:36  <TrueBrain> which is meant for "destination object"
17:44:59  <glx> I may try to do the conversion
17:45:01  <TrueBrain> the other issue is that save and load have different code
17:45:08  <TrueBrain> glx: already working on it, sorry :P
17:45:22  <michi_cc> Has the destination object the proper type?
17:45:27  <TrueBrain> void *
17:45:40  <frosch123> TrueBrain: currently there is "address_proc" in SaveLoad. couldn't there be a "load_proc" and "save_proc" instead?
17:45:40  <TrueBrain> but that doesn't fit 2 pointers, basically :D
17:45:56  *** Speedyn has quit IRC
17:46:12  <TrueBrain> frosch123: that proc returns the offset of the variable in the object
17:46:42  <TrueBrain> I could always just add 2 pointers, ofc
17:46:46  <TrueBrain> not the worst and most difficult
17:47:25  <frosch123> yes, and then someone takes that pointer, casts it to some integer types matching the SLE_... and then reads or writes that adress
17:47:43  <TrueBrain> frosch123: don't follow, sorry
17:49:50  <frosch123> so, currently there are ReadValue and WriteValue in saveload.cpp, which support a number of trivial types
17:50:54  *** Flygon has quit IRC
17:51:04  <frosch123> for list of structs you essentially want these two functions to support structs in addition to the trivial types, right?
17:51:04  <TrueBrain> was not the route I was on ;)
17:51:48  <TrueBrain> SaveLoad is just stuff on stuff on stuff, basically
17:51:48  <TrueBrain> Read/Write Value only works for SL_VAR
17:51:48  <TrueBrain> not for any other type
17:52:51  <TrueBrain> for examples, it cannot write strings
17:53:00  <TrueBrain> for that SL_STR exists
17:55:17  <frosch123> SlArray and Deque also use Read/WriteValue for each item
17:55:17  <frosch123> so, imagine for a second that Read/WriteValue could handle all types
17:55:17  <frosch123> also strings and structs
17:55:17  <TrueBrain> the thing is .. I have to find the depth I am willing to let this rabbit hole go :D
17:55:17  <TrueBrain> what you propose is possibly a good idea, but is a rather large refactor
17:55:17  <frosch123> it could do that, if the SLE_VAR_ things were not enums, but rather function pointers to read/write methods
17:56:07  <TrueBrain> but lets first draw what happens if we put the functions in the table
17:56:08  <frosch123> TrueBrain: fine, do you have an idea how to store the substructs on disk in the schema?
17:56:10  <TrueBrain> yeah, that is easy
17:56:10  <TrueBrain> ironically, of all the problems I have, that is not one of them :D
17:57:10  <frosch123> i think that would make it easier for me to understand your diff
17:57:10  <TrueBrain> having readable code is my struggle :(
17:57:10  <TrueBrain> and this words-only stuff is also not helping
17:57:10  <TrueBrain> let me draft some text
17:57:48  <TrueBrain> ps, glx, if you still like to, go for it :)
17:57:48  <TrueBrain> seems I am taking a detour here :P
17:57:52  <frosch123> TrueBrain: i don't consider my function pointers that different to your enums. you put an enum into SaveLoad that tells you which function to call for reading writing. i suggest to skip the enum, and directly put the function pointers into SaveLoad
17:58:24  <TrueBrain> yeah, I am drafting that now
17:58:24  <TrueBrain> give me a sec
17:58:41  <TrueBrain> I am fast, just not that fast :)
17:59:40  <TrueBrain>
17:59:44  <TrueBrain> very function-heavy
18:02:03  <andythenorth> should I be concerned about performance of var 67 (when used as town industry count)?
18:02:16  <andythenorth> I am about to start calling it repeatedly for different industry types
18:02:38  <frosch123> no, the var does not count them
18:02:48  <frosch123> there is a persistent statistic of present industries
18:04:14  <frosch123> hmm, actually, for towns it does recount them
18:04:34  <frosch123> well, measure it :)
18:07:07  <andythenorth> this sounds like 'do not be concerned' to me :P
18:07:25  <frosch123> TrueBrain: i would have expected SLEG_SUBLST(Town, received, Save_TOWN_RECEIVED, Load_TOWN_RECEIVED), i.e. some "name" to identify the field in the savegame, and Save/Load_TOWN_RECEIVED would get  a TransportedCargoStat* instead of a Town*
18:07:55  <TrueBrain> frosch123: this is pre-header patch
18:08:05  <TrueBrain> owh, wait, I misread you
18:08:08  <TrueBrain> that doesn't work, sadly
18:08:12  <TrueBrain> as Town is a "positive" example for this
18:08:20  <TrueBrain> most others are not part of the main struct
18:08:38  <TrueBrain> take Station for example, it recreates Flow on-the-fly
18:09:02  <TrueBrain> so I kinda want to have a generic thing, where possible
18:09:46  <TrueBrain> acceptance-matrix in Town is an example of this
18:09:50  <TrueBrain> it goes to nowhere
18:13:23  <TrueBrain> so it is "easier" in that sense to send the main-object again, and let the function pick the right thing from there
18:13:59  <TrueBrain> similar why it has to send the length
18:14:31  <frosch123> didn't the cargoflow also have list of list of struct?
18:15:10  <TrueBrain> basically, the issue here is that those "lists" are not really lists, in some cases
18:15:10  <TrueBrain> if they were all iteratable, it would be easier ..
18:15:10  <frosch123> if you always pass the top-level struct, you cannot nest your functions
18:15:25  <TrueBrain> well, "top-level" is not the right word
18:15:46  <TrueBrain> it is what-ever object was called with SlObject
18:15:47  <TrueBrain> so you can still nest :)
18:15:58  <TrueBrain> if _town_received_desc would have another SL_SUBLST, it would be called with "t->received[i]"
18:16:24  <frosch123> maybe i lost sight of the rabbit hole entry, but isn't the point of list of structs to have a single schema for the whole object?
18:16:40  <TrueBrain> yes it is!
18:16:50  <TrueBrain> updated the gist btw with something that actually compiles
18:16:53  <frosch123> so in the end you would only have a single SlObject with the main object
18:17:22  <TrueBrain> there are two things happening:
18:17:27  <TrueBrain> 1)  a scan for the headers
18:17:31  <TrueBrain> 2) the translation to items
18:17:41  <TrueBrain> for the first, I only need the main desc
18:17:54  <TrueBrain> well, the first SlObject, but who is counting
18:18:03  <TrueBrain> SaveLoad is created as such that you can walk the full tree and gather all info
18:18:16  <TrueBrain> just a lot of bookkeeping
18:18:53  <TrueBrain> not sure that made any sense :D
18:19:30  <TrueBrain> ideally, the line would read something like: SLE_SUBLST(Town, supplied, _town_supplied_desc)
18:19:35  <TrueBrain> but that only works for a handful of instances
18:19:50  <TrueBrain> sometimes the "Town, supplied" pair is not a const
18:19:54  <TrueBrain> sometimes the _desc is not a const
18:21:53  <frosch123> i think i like your gist better than the current code in master/main. it moves the logic out of the Load_TOWN into the _desc, which i consider better. but i have no idea how this helps you with the schema-in-file stuff :)
18:22:04  <TrueBrain>
18:22:07  <TrueBrain> or reload
18:22:10  <TrueBrain> that would work for me
18:22:18  <TrueBrain> I just added another proc, called Header_NNN
18:23:17  <frosch123> ok, that works
18:23:35  <TrueBrain> just a bit of code
18:23:42  <TrueBrain> I can put those 3 functions in a class
18:23:42  <frosch123> kind of tempted to put the 3 functions Header/Load/Save into a shared namespace/lcass :p
18:23:46  <TrueBrain> :D
18:23:47  <frosch123> ':p
18:23:59  <TrueBrain> so what was your dpaste about?
18:24:23  <TrueBrain> owh, you wanted to abstract it even further away
18:25:10  <frosch123> i am not sure whether my paste is flexible enough
18:25:11  <frosch123> in particular with the CONDNULL stuff, it may hurt
18:25:11  <TrueBrain> we have no more CONDNULL after my work :D
18:25:18  <TrueBrain> as you can just remove any field freely :P
18:25:54  <frosch123> i was hoping we could deduce the SLE_VAR_xxx from the storage variable's type at some point, but that falls flat for CONDNULL
18:26:03  <TrueBrain> so that is no longer an issue :)
18:27:12  <TrueBrain> but yeah, if we start using classes for chunks, we can do some more magic to make things easier to read and maintain
18:27:36  <TrueBrain> most chunks are now:
18:27:36  <TrueBrain> SlTableHeader()
18:27:42  <TrueBrain> for () { SlSetArrayIndex(i); SlObject(<object>, desc) }
18:27:48  <TrueBrain> really dull
18:27:58  <frosch123> then the main difference is that in your gist, you have one save/header/load function per struct instance (received + supplied). in my paste there is a save/header/load function per struct class
18:28:16  <frosch123> so they would be shared if the same struct is used in different places
18:28:26  <TrueBrain> which is never :(
18:28:32  <frosch123> but, it also makes it more restrictive :)
18:28:50  <frosch123> TrueBrain: if you consider std::string, std::vector as structs, it becomes "all of the time" suddenly
18:29:23  <TrueBrain> owh, you are there with your head
18:29:38  <TrueBrain> you want to save/load proc those things too
18:29:50  <frosch123> and "supplied" and "received" are only different "by accident"?
18:29:56  <frosch123> both could have been <uint32>
18:29:59  <TrueBrain> well, if we do that, we add the procs for those default things via SLE macros honestly :P
18:30:17  <TrueBrain> supplied is a total of 64 bites
18:30:24  <TrueBrain> not sure I completely follow :)
18:30:40  <TrueBrain> owh, one is 32bit
18:30:43  <TrueBrain> other is 16bit
18:30:43  <TrueBrain> per entry
18:30:44  <TrueBrain> lol
18:30:49  <TrueBrain> that is .. subtle
18:31:05  <frosch123> Save_TOWN_SUPPLIED and Save_TOWN_RECEIVED are 90% identical code :)
18:31:33  <TrueBrain> yeah .. but there are many more odd things I have found :D
18:32:07  <TrueBrain> I also wonder if there is a way to get ride of the macros
18:32:12  <TrueBrain> but the address_proc is tricky
18:36:13  <TrueBrain> <- class-based variant
18:39:37  <TrueBrain> okay, now to wire it in to check if it can actually work .. won't be fully trivial ..
18:48:37  *** Yexo has quit IRC
18:49:48  *** V453000 has quit IRC
18:49:48  *** ^Spike^ has quit IRC
18:49:48  *** Ammler has quit IRC
18:49:48  *** Hirundo has quit IRC
18:49:49  *** tneo has quit IRC
18:49:49  *** avdg has quit IRC
18:49:49  *** planetmaker has quit IRC
18:49:49  *** Hazzard has quit IRC
18:52:03  *** XeryusTC has quit IRC
18:52:03  *** Osai has quit IRC
18:52:13  <frosch123> <- it's possible to get rid of the address_proc by using member pointers
18:52:28  *** Terkhen has quit IRC
18:52:28  *** fonsinchen has quit IRC
18:52:29  *** SmatZ has quit IRC
18:54:27  <TrueBrain> how to read that ...
18:55:24  <TrueBrain> does that also work for struct in struct members, like Town.location.x etc?
18:57:39  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
18:57:42  <TrueBrain> right, rebased my work .. now lets tackle sublst ..
18:57:42  <frosch123> hmm, current code already uses lambas for the address_proc
18:57:48  <TrueBrain> yup
18:58:18  <frosch123> why do we still need the SLE_VAR_xyz then :p
18:58:41  <TrueBrain> well, I would like to get rid of the macros
18:58:48  <TrueBrain> SLE_VAR_xxx is pretty useful
18:58:59  <TrueBrain> as the code validates that the storage is of equal size
18:59:05  <TrueBrain> this prevents stupid mistakes :)
18:59:15  <TrueBrain> (like someone changing the size of a member in the savegame without realising he did that :P)
18:59:35  <frosch123> why do you want to get rid of the macros? except for getting rid of macros in general?
18:59:45  <TrueBrain> because we keep on increasing it with new fields
18:59:52  <TrueBrain> which basically means many are now {}, 0, nullptr, etc
18:59:58  <TrueBrain> it is getting slightly out of hand, and is rather unreadable
19:00:02  <TrueBrain> but mostly
19:00:04  <TrueBrain> I want optional fields
19:00:14  <TrueBrain> deducing the name based on the variable is MOSTLY okay
19:00:16  <TrueBrain> just sometimes it is not
19:00:32  <frosch123> there are varidatic macros :)
19:00:39  <frosch123> variadic
19:00:47  <TrueBrain> yeah ... and I want to keep my sanity, thank you very much :)
19:00:56  <TrueBrain> we now also have SLE_VAR and SLE_CONDVAR
19:01:03  <TrueBrain> which solves the "optional" param issue for those
19:01:12  <TrueBrain> but you see a lot of SL_MAX_VERSION because of that
19:01:16  <TrueBrain> which is .. not useful :P
19:01:27  <TrueBrain> but yeah, I only want it for code hygiene :)
19:01:51  <frosch123> there are designated initializers for structs: SaveLoad{ .length=5, .version_to=7 }
19:02:08  <frosch123> they are supported by gcc/clang for years inofficially, and officially in msvc with c++20
19:02:19  <TrueBrain> and .. we are back to C++20 :P
19:02:20  <TrueBrain> :D
19:02:23  <frosch123> they allow something like optional parameters
19:02:52  <frosch123> you probably also can turn some of the macros into different SaveLoad constructors
19:03:05  <frosch123> but to create those fancy lambas, you have to use macros :)
19:03:22  <TrueBrain> well, I guess that can stay a macro
19:03:44  <TrueBrain> up to 15 commits over 4 PRs :D
19:04:06  <TrueBrain> right, focus TrueBrain , lets do SUBLST
19:10:05  *** tneo has joined #openttd
19:12:13  *** Ammler has joined #openttd
19:12:13  *** Osai has joined #openttd
19:12:49  *** SmatZ has joined #openttd
19:13:04  *** ^Spike^ has joined #openttd
19:13:23  *** Terkhen has joined #openttd
19:13:23  *** ChanServ sets mode: +o Terkhen
19:13:57  *** V453000 has joined #openttd
19:13:57  *** XeryusTC has joined #openttd
19:14:30  *** Yexo has joined #openttd
19:15:01  *** avdg has joined #openttd
19:15:36  *** fonsinchen has joined #openttd
19:15:55  <TrueBrain> <- "description" variable is the most used form of this, but sometimes GetDescription() is used
19:16:07  <TrueBrain> is there an easy way to have the parent implement the default "return description"?
19:16:13  *** planetmaker has joined #openttd
19:16:13  *** ChanServ sets mode: +o planetmaker
19:18:23  *** Hirundo has joined #openttd
19:21:27  *** Hazzard has joined #openttd
19:22:49  <nielsm> TrueBrain: make the description variable protected, and a simple pointer, the children then have to assign that pointer in their constructor
19:23:25  <TrueBrain> means the child still needs to assign something, meh
19:23:31  <TrueBrain> sorry, trying to reduce the lines of code you need :P
19:23:43  <TrueBrain> sometimes a bit silly thing to do, I know :D
19:24:00  <nielsm> another one is perhaps the curiously recurring template pattern
19:24:38  <nielsm> probably via an intermediate base class
19:24:54  <nielsm> (ref: )
19:25:16  <TrueBrain> hmm
19:25:19  <TrueBrain> that might work
19:26:29  <TrueBrain> looks a lot nicer, tnx
19:27:25  <TrueBrain> glx: if you are working on making the Chunks a class, our work might collide at some point :P But we will figure that out when that happens :)
19:28:11  <nielsm> remember you might want to make it SaveLoadHandler  <-  DefaultSaveLoadHandler<SpecificSaveLoadHandler>  <-  SpecificSaveLoadHandler
19:28:15  <glx> I'm just starting, will first use a wrapper around the current pointers
19:28:22  <nielsm> to allow for SaveLoadHandler to be a true polymorphic superclass
19:28:34  <TrueBrain> does that matter .. hmm
19:29:18  <nielsm> you can't have a vector of SaveLoadHandler<T> with different T for each element, unless you make it a vector of void*
19:29:38  <nielsm> and you wouldn't be able to use those for anything then
19:29:42  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9314: Codechange: let the setting name be std::string
19:29:47  <TrueBrain> there is currently no storage in those classes
19:30:22  <TrueBrain> well, a vtable
19:30:33  <TrueBrain> so I am wondering if we ever want to iterate them or anythnig .. I guess we do
19:30:33  <TrueBrain> k
19:32:35  <TrueBrain> glx: <- my current SaveLoadHandler .. if anything remotely like that would be possible for all chunks, would be nice
19:33:08  <glx> yeah that's the intention
19:34:11  <TrueBrain> small update
19:34:38  <TrueBrain> Ptrs need a better name :D
19:34:39  <TrueBrain> but okay :)
19:34:58  <TrueBrain> tnx nielsm !
19:35:02  <nielsm> TrueBrain: the idea is that the DefaultSaveLoadHandler can avoid declaring the description member variable entirely, and implement GetDescription() as return static_cast<T *>(this)->description
19:35:10  <glx> oh I named it Pointers
19:35:27  <TrueBrain> nielsm: hmm .. sure, why not
19:35:31  <TrueBrain> I initially had it =0
19:35:34  <TrueBrain> but that is not useful
19:35:37  <glx> Save, Load, Pointers, LoadCheck
19:35:39  <TrueBrain> glx: FixPointers?
19:36:09  <glx> but yeah naming can be improved :)
19:36:17  <nielsm> that's the entire point of the CRT pattern, that you have a base class that knows the identity of the derived class and can access members of the derived class without vtable polymorphism
19:36:22  <TrueBrain> well, lets figure it out now, to avoid having to rename N things later :P
19:36:56  <TrueBrain> nielsm: the page you linked showed a nice example of "= 0" on the variable :D
19:37:18  <TrueBrain> which has as advantage, that if you use the DefaultSaveLoadHandler, you have to define it
19:37:23  <TrueBrain> but I guess now it just fails compiling too
19:37:24  <TrueBrain> :P
19:38:05  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
19:38:06  <DorpsGek>   - Update: Translations from eints (by translators)
19:38:27  <TrueBrain> error: ‘const SaveLoad SlTownSupplied::description [4]’ is protected within this context
19:38:28  <TrueBrain> meh
19:38:45  <nielsm> yeah the specific handlers will have to make it public
19:38:54  <TrueBrain> which is ... not ideal ;)
19:39:14  <TrueBrain> the whole point is to keep it private :P
19:39:17  <nielsm> if it's static const data I don't see the issue
19:39:33  <TrueBrain> protected/public has little to do with the type
19:39:39  <TrueBrain> but everything with the human behind the keyboard :D
19:39:52  <nielsm> that's why we have code reviews isn't it?
19:40:00  <TrueBrain> like they are going to spot those things
19:40:22  <TrueBrain> I have now seen what people did with the SaveLoad stuff
19:41:18  <TrueBrain> a good portion was people not understanding how it works :P
19:41:39  <Rubidium> maybe something along the lines of might work?
19:42:34  <frosch123> that looks like a dangling pointer
19:42:51  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9333: Codechange: merge guiflags and flags in settings .ini files
19:42:55  <frosch123> the table has to be static to make the span work
19:43:07  <TrueBrain> yup
19:44:35  <TrueBrain> nobody is now the owner of that list, I think
19:44:54  <nielsm> more like it disappears after the constructor returns
19:45:04  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9333: Codechange: merge guiflags and flags in settings .ini files
19:45:09  <nielsm> and now you have an invalid pointer stored in the member
19:45:14  <nielsm> invalid span
19:45:22  <TrueBrain> well, I would guess the data is in .data
19:45:28  <TrueBrain> so I would guess "it just works" :P
19:45:36  <TrueBrain> not saying it is the right thing, btw
19:45:59  <nielsm> anyone got a language lawyer on standby? need to check it for UB
19:46:15  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9335: Codechange: make [Save|Load]Settings() behave more like other Save/Load code
19:46:26  <TrueBrain> nielsm: lol
19:48:28  <TrueBrain> that would be so awesome, if you could call a hotline
19:48:28  <TrueBrain> we have this code
19:48:28  <TrueBrain> and he just rants at you for 5 minutes straight
19:48:28  <TrueBrain> no matter what code it is
19:49:51  <Rubidium> nielsm: it's not that UB is the biggest problem for OpenTTD ;) It's that it makes assumptions that simply do not hold, or that the defined behaviour is different from what OpenTTD's code expects
19:50:01  <TrueBrain> <- will have to do for now
19:52:35  <TrueBrain> euh, that "static inline" shouldn't be there ofc
19:53:11  *** gelignite has quit IRC
20:01:05  <glx> <-- first step (at least it still builds)
20:01:37  <TrueBrain> :D
20:02:13  *** jottyfan has quit IRC
20:02:28  <TrueBrain> shall we rename "Pointers" to "FixPointers" while we still can with little effort? :D
20:02:43  <TrueBrain> at least, that is the internal name in SaveLoad
20:03:48  <glx> hmm yes FixPointers seems better
20:05:21  <nielsm> does that mean "repair the pointers" or "fixate the pointers so they don't move again"?
20:08:32  <Rubidium> mostly "convert pool indices to pointers" (IIRC)
20:08:32  <TrueBrain> int -> void*
20:08:32  <TrueBrain> it is a bit odd, but on Load() it puts an (int32) in the (void *) of the destination
20:08:32  <TrueBrain> FixPointers then picks up those values, and makes it into the real (void *)
20:08:32  <TrueBrain> ugly hacks being ugly :)
20:08:43  <nielsm> uh yeah that sounds like actual UB, storing random integer values that are probably not valid as pointers to objects into void*
20:08:58  <TrueBrain> void* is at least 32bits
20:08:58  <nielsm> even if you never dereference them I don't think that's defined
20:08:59  <TrueBrain> so it works :P
20:09:18  <TrueBrain> and sanitizers don't pick up on it yet
20:09:19  <TrueBrain> so sssttttt
20:11:12  <glx> SlXxxChunk functions are annoying, they check for nullptr
20:12:08  <nielsm> I think there might be CPU architectures where storing a pointer value in a register is different from storing an integer value in a register (or pointers even have separate registers), and loading an unaligned or otherwise invalid pointer might cause a trap... I really have no idea but I think I recall reading about such a thing before
20:12:31  <TrueBrain> nielsm: on the other side, this code has been running on the weirdest machines for 17 years ..
20:12:39  <TrueBrain> clearly it works for many many architectures just fine :D
20:12:57  <TrueBrain> not saying it is weird and we shouldn't be doing it, btw
20:13:12  <Rubidium> nielsm: if you want to go that way, then also consider both int and char being 16 bits ;)
20:13:41  <TrueBrain> *(void **)ptr = IntToReference(*(size_t *)ptr, (SLRefType)conv); <- it is so beautiful
20:13:53  <michi_cc> nielsm: point 3) seems to say we are good.
20:14:18  <michi_cc> Technically, we'd have to use reinterpret_cast instead of a c-style cast, tough :)
20:15:07  <frosch123> let's make a strawpoll whether it has to be size_t, intptr_t or uintptr_t :p
20:15:22  <TrueBrain> can I just opt-out?
20:15:36  <michi_cc> "A pointer can be converted to any integral type large enough to hold all values of its type (e.g. to std::uintptr_t)"
20:15:58  *** Hirundo has quit IRC
20:18:15  *** XeryusTC has quit IRC
20:18:40  *** V453000 has quit IRC
20:19:09  *** ^Spike^ has quit IRC
20:19:09  *** planetmaker has quit IRC
20:19:09  *** Osai has quit IRC
20:19:09  *** Ammler has quit IRC
20:19:09  *** Hazzard has quit IRC
20:19:09  *** avdg has quit IRC
20:19:09  *** Yexo has quit IRC
20:19:09  <TrueBrain> owh, hmm .. C++ isn't Python .. I cannot store the class itself .. only instances ..
20:19:09  <TrueBrain> owh well, "new handler()" it is in SLEG_SUBLST :P
20:19:09  <Rubidium> frosch123: practically it shouldn't be size_t ;)
20:19:09  <Rubidium> *technically*
20:19:21  *** Hazzard has joined #openttd
20:22:44  <TrueBrain> 		/* Don't run when savegame version lower than 161. */
20:22:45  <TrueBrain> 		if (IsSavegameVersionBefore(SLV_161)) return;
20:22:52  <TrueBrain> I am always happy with comments that ... explain ... the code?!
20:22:54  <TrueBrain> lol
20:26:25  <frosch123> i think the language lawyer would say, all three options are wrong :p
20:26:36  <frosch123> (u)intptr_t make guarantees about pointers fitting into integers
20:26:46  <frosch123> but we acutally need the reverse: integers fitting into pointers
20:26:53  <frosch123> i don't think there is such thing :p
20:26:58  *** Terkhen has quit IRC
20:26:58  *** SmatZ has quit IRC
20:26:58  *** tneo has quit IRC
20:26:59  *** fonsinchen has quit IRC
20:28:55  <glx> <-- will need a huge rewrite, function pointers are deep in the code
20:29:29  <TrueBrain> what needs a rewrite, sorry?
20:29:57  <glx> most functions test the pointers for nullptr and do different stuff
20:30:25  <glx> like SlSaveChunk() has an early return
20:31:12  <TrueBrain> yeah, but what I was thinking about, make a class per type, so a ChunkRiff, etc
20:31:13  <glx> SlLoadCheckChunk() skips data if no load_check function
20:32:03  <TrueBrain> Broken savegame - Invalid chunk size
20:32:09  <TrueBrain> that is still the most pointless error it can throw
20:32:14  <TrueBrain> no indication what-so-ever what goes wrong :D
20:34:23  <TrueBrain> vs
20:34:24  <TrueBrain> sometimes our code makes me laugh :)
20:35:32  <andythenorth> sometimes our chat makes me laugh :)
20:36:05  <Samu> one says TE_END the other says NUM_TE
20:36:57  <glx> lucky NUM_TE = TE_END :)
20:37:00  <frosch123> TrueBrain: nice :)
20:37:06  <TrueBrain> glx: well, that is no luck ofc
20:37:08  <TrueBrain> but .. yeah :)
20:37:33  <glx> anyway loops should use END, not NUM
20:37:43  <TrueBrain> no, if you use BEGIN you should use END :P
20:38:02  <Samu> NUM_TE = TE_END, guess it doesn't matter
20:38:32  <glx> it works, but it's bad ;)
20:40:11  <TrueBrain> yippie, my code works :D
20:40:40  <TrueBrain>
20:40:56  <TrueBrain> the ugliest part is the "new handler()" hidden in a macro :P
20:41:16  <TrueBrain> and the "list" doesn't write its size yet, that is to come :)
20:48:34  <nielsm> I don't have any reference or anything, but there is some argument that you should strive for formats that don't use size/length fields but instead terminator markers
20:48:56  <andythenorth> lol FIRS max coastal distance parameter doesn't work
20:49:00  <andythenorth> probably hasn't for years
20:49:01  <andythenorth> delete?
20:49:07  <TrueBrain> nielsm: that only works if you have something to do a terminator
20:49:11  <TrueBrain> in this case it is a random struct
20:49:30  <TrueBrain> even a full-zero wouldn't be a good marker
20:49:33  <nielsm> because that makes classes of invalid data forms impossible, and forces you to handle allocations for the incoming data correctly
20:49:40  <TrueBrain> so what you end up with is adding a byte just for the marker, to every entry in the list :)
20:50:07  <nielsm> yeah you'd have to use tagged entries of some kind then
20:50:22  <TrueBrain> and how much people would like to, I am not going to rewrite our SaveLoad completely :)
20:50:34  <TrueBrain> there are limits to my willfulness :)
20:52:40  *** Terkhen has joined #openttd
20:52:40  *** ChanServ sets mode: +o Terkhen
20:59:48  *** Hazzard has quit IRC
21:00:25  <frosch123> c++ is going in the opposite direction :)
21:00:48  <frosch123> c has terminators everywhere, in strings, in arrays, ...
21:01:02  <frosch123> c++ has all these start+length things
21:01:48  <nielsm> that rule of thumb is specifically for transfer formats where data might come from an untrusted third party
21:02:23  *** Terkhen has quit IRC
21:13:26  *** Samu has quit IRC
21:20:06  <TrueBrain> it is weird, on-save, the chunk-size is not validated (as in: a check that what you indicate is actual what you wrote)
21:20:09  <TrueBrain> but on load it is
21:20:17  <TrueBrain> on-save can do it just fine .. it just doesn't :P
21:20:18  <TrueBrain> more things to fix
21:21:28  <frosch123> hmm, that would mean, if the save code is broken, you cannot save at all :p
21:21:29  *** tneo has joined #openttd
21:21:35  <TrueBrain> yes
21:21:38  <TrueBrain> indeed
21:21:42  <TrueBrain> now you can save, and nobody can ever load it again
21:21:44  <TrueBrain> not sure what is worse :P
21:21:54  <frosch123> the latter may allow debugging
21:22:06  <TrueBrain> I can tell you, it is frustrating
21:22:17  <TrueBrain> as "debugging" ... not .... easy
21:22:21  <TrueBrain> well, with my PRs it becomes easy
21:22:27  <TrueBrain> as than you have headers :)
21:25:35  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code
21:25:47  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
21:25:53  <TrueBrain> okay ... tomorrow I fiddle with how to store the headers on disk
21:25:57  <TrueBrain> but mainly: how to load them from disk
21:26:10  <TrueBrain> I need some nice way to tell the SubHandlers about the order the fields are in
21:27:11  <TrueBrain> pretty content with the sublists solution like this frosch123 ; it feels smooth
21:27:25  <TrueBrain> will see if I can translate all chunks into this, but I think it won't be a problem
21:27:27  <frosch123> yay :)
21:28:01  <TrueBrain> if it works, it solves 5 more chunks
21:28:13  <TrueBrain> leaving .. 5 more to look into
21:28:16  <TrueBrain> of which 3 are linkgraph
21:28:34  <TrueBrain> (the other two gamescript and gamelog)
21:28:56  <TrueBrain> but I think .. with the exception of the MAP chunks .. this will give us a header for all chunks :D
21:32:00  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
21:32:20  <glx> Oh a nice comment " * Do something of which I have no idea what it is :P"
21:32:45  <frosch123> haha, i think tb posted that one 2 days ago :p
21:32:47  <TrueBrain> :D
21:33:12  <TrueBrain> btw, frosch123 , this also means a migration to SQLite is absolutely possible, given we can solve the MAP-chunks :D
21:33:57  <frosch123> is it? the substructlists would need some normalisation :p
21:34:05  <frosch123> so it requires more magic
21:34:21  <TrueBrain> owh, it is not 2 minutes work
21:34:24  <TrueBrain> but the structure is there
21:34:45  <TrueBrain> well, more magic .. I think it would require more strict rules
21:35:05  <TrueBrain> when you use a `CH_TABLE`, you are now free to use SlSetArrayIndex() or not, as example
21:35:15  <TrueBrain> you would have to take that control away
21:36:25  <TrueBrain> well, that "freedom"
21:37:10  *** V453000 has joined #openttd
21:37:10  *** XeryusTC has joined #openttd
21:37:11  <TrueBrain> as if the sublst would also do that, as example, normalisation is trivial from that point
21:37:31  <TrueBrain> not going to do that for now btw :P
21:38:57  <TrueBrain> right, enough for today. Night!
21:44:53  *** fonsinchen has joined #openttd
21:44:55  *** frosch123 has quit IRC
21:47:11  *** andythenorth has quit IRC
21:48:23  *** Hazzard has joined #openttd
21:49:15  *** Wolf01 has quit IRC
21:50:18  *** planetmaker has joined #openttd
21:50:18  *** Hirundo has joined #openttd
21:50:18  *** ChanServ sets mode: +o planetmaker
21:52:05  *** ^Spike^ has joined #openttd
21:52:21  *** Ammler has joined #openttd
21:52:21  *** Osai has joined #openttd
21:52:21  *** SmatZ has joined #openttd
21:52:44  *** sla_ro|master has quit IRC
22:01:39  *** Yexo has joined #openttd
22:03:59  <glx> oups full water
22:04:15  *** Terkhen has joined #openttd
22:04:15  *** avdg has joined #openttd
22:04:15  *** ChanServ sets mode: +o Terkhen
22:06:12  <_dp_> and I thought zstd has bad docs...
22:06:24  <_dp_> liblzma just links to zlib docs xD
22:14:47  *** iSoSyS has joined #openttd
22:16:36  *** iSoSyS has quit IRC
22:26:52  <TrueBrain> glx: I have seen so much water lately ... so muuuucccchhhhhh :D
22:27:12  <glx> for some reason it doesn't use override
22:27:12  <TrueBrain> I am relieved every time I see the titlegame :p
22:32:19  <TrueBrain> Not overriding a static function I hope :D
22:32:32  <TrueBrain> I might have tried that earlier today :p
22:32:40  <glx> no they are virtual
22:32:50  <glx> and not static
22:33:23  <TrueBrain> :D
22:33:51  <glx> but it's probably because it's in a ChunkHandler[]
22:38:09  *** XeryusTC has quit IRC
22:42:50  *** XeryusTC has joined #openttd
22:48:33  *** avdg has quit IRC
22:48:33  *** V453000 has quit IRC
22:48:33  *** tneo has quit IRC
22:48:34  *** Yexo has quit IRC
22:48:34  *** Hirundo has quit IRC
22:48:34  *** Osai has quit IRC
22:48:34  *** Ammler has quit IRC
22:53:12  *** Progman has quit IRC
22:56:49  *** planetmaker has quit IRC
22:56:49  *** Hazzard has quit IRC
22:56:49  *** ^Spike^ has quit IRC
23:03:15  *** nielsm has quit IRC
23:03:16  *** Ammler has joined #openttd
23:04:11  *** ^Spike^ has joined #openttd
23:04:34  *** V453000 has joined #openttd
23:07:20  *** tneo has joined #openttd
23:11:44  *** Osai has joined #openttd
23:11:44  *** Yexo has joined #openttd
23:18:10  *** Hazzard has joined #openttd
23:27:13  *** tneo has quit IRC
23:27:13  *** Ammler has quit IRC
23:27:13  *** V453000 has quit IRC
23:27:13  *** XeryusTC has quit IRC
23:27:13  *** Osai has quit IRC
23:27:14  *** ^Spike^ has quit IRC
23:27:14  *** Yexo has quit IRC
23:27:19  *** SmatZ has quit IRC
23:27:23  *** Terkhen has quit IRC
23:27:23  *** fonsinchen has quit IRC
23:30:19  *** Hazzard has quit IRC
23:43:23  *** tneo has joined #openttd
23:50:39  *** Osai has joined #openttd
23:50:39  *** SmatZ has joined #openttd
23:58:13  *** avdg has joined #openttd
23:58:13  *** fonsinchen has joined #openttd

Powered by YARRSTE version: svn-trunk