IRC logs for #openttd on OFTC at 2021-06-06
⏴ go to previous day
00:08:05 *** Gustavo6046 has joined #openttd
00:10:29 *** Smedles_ has joined #openttd
00:10:35 *** Smedles has quit IRC (Read error: Connection reset by peer)
00:28:10 *** HerzogDeXtEr1 has quit IRC (Read error: Connection reset by peer)
00:37:58 *** Progman has quit IRC (Remote host closed the connection)
02:05:38 *** Wormnest has quit IRC (Quit: Leaving)
03:04:06 *** Smedles has joined #openttd
03:49:21 *** ChanServ sets mode: +v tokai
05:50:15 *** tokai|noir has joined #openttd
05:50:15 *** ChanServ sets mode: +v tokai|noir
05:57:04 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:15:24 *** gelignite has joined #openttd
07:16:56 *** andythenorth has joined #openttd
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:35 *** Progman has joined #openttd
07:21:32 <peter1138> Is it like memory where having free memory is the real waste?
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 https://git.io/JOSBr
07:39:54 <TrueBrain> premature optimizations is the worst kind of optimization
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 https://git.io/JGKeH
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 https://git.io/JGKBm
07:46:04 <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 https://git.io/JGlmd
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: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: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
08:01:09 <andythenorth> 'wondering' achieves pretty much FA
08:02:00 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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: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:13 <andythenorth> so lower indexed towns are not more likely to be in north, or some similar pattern?
08:28:44 <andythenorth> town index never changes, even if more towns are built?
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:40 <peter1138> Why would that be an exploit? It should be the nearest town of the industry... if it did exist.
08:38:21 <peter1138> Blooddy gate springs.
08:38:44 <peter1138> I guess there's a reason they cost about 50p.
08:41:24 <andythenorth> or the mounting to the post broke?
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: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 (Ping timeout: 480 seconds)
08:52:31 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:53:04 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #9289: Change: Shortcut varaction chains for callbacks. https://git.io/JsHuK
09:01:20 *** jottyfan has joined #openttd
09:23:56 <peter1138> My vacuum cleaner is sucking at suckinbg.
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 https://git.io/JGhXd
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:36:58 <peter1138> Hmm, there's a bench mark thing isn't there...
09:37:21 <TrueBrain> for a vacuum cleaner?
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:45:25 <TrueBrain> and MSVC / GCC are fine with it, just clang that is being a little bitch
09:57:22 <TrueBrain> anyone any clue why clang doesn't like that?
10:03:41 *** WormnestAndroid has quit IRC (Remote host closed the connection)
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: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 https://git.io/JGhXd
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 (Remote host closed the connection)
10:45:11 *** sla_ro|master has quit IRC ()
10:49:38 *** sla_ro|master has joined #openttd
10:52:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame https://git.io/JGlmd
10:53:12 <TrueBrain> I need to change 2 RIFFs into ARRAYs, and 6 (+2) ARRAYs into TABLEs
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: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: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 (Quit: andythenorth)
11:50:02 *** Speedyn has joined #openttd
11:54:45 *** Speedy` has quit IRC (Ping timeout: 480 seconds)
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 https://git.io/JGlmd
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 https://git.io/Jvek6
12:18:17 <TrueBrain> .env/bin/python -m savegame_reader Unnamed,\ 2nd\ Jan\ 1950.sav --export-json | jq .CHTS
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: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 *** 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 (Ping timeout: 480 seconds)
13:13:40 <TrueBrain> frosch123: only after conversion, which is the issue :P :P
13:14:26 * andythenorth finds local error
13:19:44 <frosch123> it's always the mammals
13:24:44 <andythenorth> never the slugs?
13:27:54 <andythenorth> in which andythenorth tries to learn how to write bitmasks from nml + python
13:28:06 *** Progman has quit IRC (Remote host closed the connection)
13:30:29 <andythenorth> I can use hasbit() to read them
13:30:40 <andythenorth> but how do I set bits?
13:33:59 <andythenorth> nvm, there's a better way
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
14:06:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code https://git.io/JGhXd
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 https://git.io/JLnqJ
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: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:16:13 <andythenorth> I don't have any luggage
14:16:35 <frosch123> TrueBrain: discworld stuff
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:19:04 <andythenorth> anyway I now have towns being 'claimed' as farming, extractive, or heavy industry
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:20:04 <andythenorth> low industry or hight industry map
14:20:10 <andythenorth> mountainous maps
14:20:17 <andythenorth> high water % maps
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:28:48 <andythenorth> so .... town subtypes also? o_O
14:39:28 <TrueBrain> hmm .. that moment some savegames load fine, others crash and burn
14:41:26 <TrueBrain> it helps to fix pointers correctly after loading :P
14:42:07 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code https://git.io/JGhXd
14:45:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code https://git.io/JGhXd
14:46:20 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8398: Change: Distribute left over cargo to stations according to the highest remainder https://git.io/JLuoN
14:48:48 <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
15:02:41 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8492: Fix: Don't allow towns to terraform certain floodable tiles https://git.io/JLdA0
15:09:00 *** virtualrandomnumber has joined #openttd
15:09:21 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
15:09:59 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8514: Change: Allow to build dock on clearable watered object tiles https://git.io/JLxsA
15:20:43 <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:22:47 <andythenorth> isn't this just AND of a specific bit with the existing value?
15:24:44 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8517: Codechange: Make void tiles flood edge tiles, instead of edge tiles flooding themselves https://git.io/JLxCt
15:25:01 <FLHerne> You just want `old_value & (1 << n)`
15:25:14 <FLHerne> Or just precalculate 1 << n and use that
15:25:32 <FLHerne> `old_value & bitmask(n)` would work too
15:26:36 <FLHerne> `old_value | (1 << n)`
15:29:03 <glx> and unseting in combination with ~
15:32:01 <andythenorth> and n is the bit number I want to set yes?
15:32:12 <andythenorth> and if I wanted to unset it, (0 << n)?
15:32:48 <glx> to unset it's old & ~(1<<n)
15:34:09 * andythenorth wonders how many bits are in a town register :P
15:34:12 <andythenorth> can probably google that
15:34:25 <andythenorth> 32 bit registers
15:53:45 <andythenorth> old_value | bitmask(n) would work also?
15:58:53 * andythenorth needs a bitmask for up to 64 cargos, but registers only support 32 bit :P
15:59:25 <andythenorth> yeah, not sure how I'd split across them yet
15:59:41 <andythenorth> I guess I know the bit number
15:59:46 <andythenorth> so I just split on that
15:59:55 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8609: Fix: Equalise the number of frames needed for road vehicles to traverse different radius curves https://git.io/JtnEF
16:02:28 * 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:03:28 <andythenorth> these are the problems that cause GS to be the recommended solution
16:03:48 <andythenorth> except for the small issue that's it not recommended to make a GS for a specific industry grf
16:04:46 <andythenorth> no way to unset flags
16:04:51 <andythenorth> kills this idea stone dead :)
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: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:37 <andythenorth> there's no way to unset the flag
16:08:59 <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:00 <andythenorth> I could have one industry do the clean up for all the others, but if the town has no industry...
16:10:03 *** tokai|noir has joined #openttd
16:10:03 *** ChanServ sets mode: +v tokai|noir
16:10:23 <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:27 <andythenorth> and I don't know what daylength will do with it
16:12:38 <andythenorth> and it leaves a 1 month window where an industry might have been deleted
16:14:07 <andythenorth> OpenTTD modding: 'lol'
16:17:20 *** tokai has quit IRC (Ping timeout: 480 seconds)
16:19:58 <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:09 <andythenorth> just town registers holding flags would be a neat solution, where the 'check' is just read a bit
16:21:33 <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
17:05:02 *** Webster has quit IRC (Read error: Connection reset by peer)
17:06:44 *** Webster has joined #openttd
17:17:05 *** Wormnest has joined #openttd
17:30:17 *** 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 *** ChanServ sets mode: +v tokai
17:36:17 <glx> and yeah a ChunkHandler class could be a good idea
17:37:08 <glx> well there's already one :)
17:37:44 <michi_cc> It is a class. I mean a struct is just a class that defaults to public.
17:38:55 <TrueBrain> michi_cc: okay mister-nitpicking, I meant a class with overloadable functions instead of function-pointer-variables :)
17:38:57 <andythenorth> wtf is a region anyway
17:40:51 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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? https://dpaste.org/2Xxp
17:42:29 <TrueBrain> frosch123: I do not understand what you are showing me there :D
17:42:33 <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: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: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 (Read error: Connection reset by peer)
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:07 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:50:20 <frosch123> for list of structs you essentially want these two functions to support structs in addition to the trivial types, right?
17:50:54 <TrueBrain> was not the route I was on ;)
17:51:38 <TrueBrain> SaveLoad is just stuff on stuff on stuff, basically
17:51:44 <TrueBrain> Read/Write Value only works for SL_VAR
17:51:46 <TrueBrain> not for any other type
17:52:44 <TrueBrain> for examples, it cannot write strings
17:52:55 <TrueBrain> for that SL_STR exists
17:54:05 <frosch123> SlArray and Deque also use Read/WriteValue for each item
17:54:18 <frosch123> so, imagine for a second that Read/WriteValue could handle all types
17:54:22 <frosch123> also strings and structs
17:54:38 <TrueBrain> the thing is .. I have to find the depth I am willing to let this rabbit hole go :D
17:54:51 <TrueBrain> what you propose is possibly a good idea, but is a rather large refactor
17:55:05 <frosch123> it could do that, if the SLE_VAR_ things were not enums, but rather function pointers to read/write methods
17:55:35 <TrueBrain> but lets first draw what happens if we put the functions in the table
17:55:51 <frosch123> TrueBrain: fine, do you have an idea how to store the substructs on disk in the schema?
17:56:07 <TrueBrain> ironically, of all the problems I have, that is not one of them :D
17:56:08 <frosch123> i think that would make it easier for me to understand your diff
17:56:12 <TrueBrain> having readable code is my struggle :(
17:56:49 <TrueBrain> and this words-only stuff is also not helping
17:56:51 <TrueBrain> let me draft some text
17:57:11 <TrueBrain> ps, glx, if you still like to, go for it :)
17:57:15 <TrueBrain> seems I am taking a detour here :P
17:57:49 <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:01 <TrueBrain> yeah, I am drafting that now
17:58:41 <TrueBrain> I am fast, just not that fast :)
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:37 <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:24 <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:13:20 <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:37 <TrueBrain> similar why it has to send the length
18:14:27 <frosch123> didn't the cargoflow also have list of list of struct?
18:14:47 <TrueBrain> basically, the issue here is that those "lists" are not really lists, in some cases
18:14:56 <TrueBrain> if they were all iteratable, it would be easier ..
18:14:58 <frosch123> if you always pass the top-level struct, you cannot nest your functions
18:15:23 <TrueBrain> well, "top-level" is not the right word
18:15:28 <TrueBrain> it is what-ever object was called with SlObject
18:15:30 <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: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:30 <TrueBrain> 2) the translation to items
18:17:40 <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:10 <TrueBrain> that would work for me
18:22:18 <TrueBrain> I just added another proc, called Header_NNN
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:59 <TrueBrain> so what was your dpaste about?
18:24:22 <TrueBrain> owh, you wanted to abstract it even further away
18:24:45 <frosch123> i am not sure whether my paste is flexible enough
18:24:55 <frosch123> in particular with the CONDNULL stuff, it may hurt
18:25:09 <TrueBrain> we have no more CONDNULL after my work :D
18:25:17 <TrueBrain> as you can just remove any field freely :P
18:25:50 <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:11 <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:23 <TrueBrain> most chunks are now:
18:27:39 <TrueBrain> for () { SlSetArrayIndex(i); SlObject(<object>, desc) }
18:27:56 <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: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:37 <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: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:39:37 <TrueBrain> okay, now to wire it in to check if it can actually work .. won't be fully trivial ..
18:48:34 *** Yexo has quit IRC (Ping timeout: 480 seconds)
18:49:48 *** V453000 has quit IRC (Ping timeout: 480 seconds)
18:49:48 *** ^Spike^ has quit IRC (Ping timeout: 480 seconds)
18:49:48 *** Ammler has quit IRC (Ping timeout: 480 seconds)
18:49:48 *** Hirundo has quit IRC (Ping timeout: 480 seconds)
18:49:49 *** tneo has quit IRC (Ping timeout: 480 seconds)
18:49:49 *** avdg has quit IRC (Ping timeout: 480 seconds)
18:49:49 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
18:49:49 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
18:52:03 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
18:52:03 *** Osai has quit IRC (Ping timeout: 480 seconds)
18:52:28 *** Terkhen has quit IRC (Ping timeout: 480 seconds)
18:52:28 *** fonsinchen has quit IRC (Ping timeout: 480 seconds)
18:52:29 *** SmatZ has quit IRC (Ping timeout: 480 seconds)
18:54:27 <TrueBrain> how to read that ...
18:55:20 <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 https://git.io/JGlmd
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:58:18 <frosch123> why do we still need the SLE_VAR_xyz then :p
18:58:42 <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:04 <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:34 <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:59 <TrueBrain> it is getting slightly out of hand, and is rather unreadable
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:47 <TrueBrain> yeah ... and I want to keep my sanity, thank you very much :)
19:00:55 <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: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:00 <TrueBrain> right, focus TrueBrain , lets do SUBLST
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:15:36 *** fonsinchen has joined #openttd
19:16:07 <TrueBrain> is there an easy way to have the parent implement the default "return description"?
19:16:12 *** planetmaker has joined #openttd
19:16:13 *** ChanServ sets mode: +o planetmaker
19:17:41 *** 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:26:29 <TrueBrain> looks a lot nicer, tnx
19:27:24 <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:10 <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:17 <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:41 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9314: Codechange: let the setting name be std::string https://git.io/JGCaz
19:29:47 <TrueBrain> there is currently no storage in those classes
19:30:25 <TrueBrain> so I am wondering if we ever want to iterate them or anythnig .. I guess we do
19:33:06 <glx> yeah that's the intention
19:34:37 <TrueBrain> Ptrs need a better name :D
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:28 <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: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: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: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:40:32 <TrueBrain> a good portion was people not understanding how it works :P
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 https://git.io/JZJJS
19:42:55 <frosch123> the table has to be static to make the span work
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 https://git.io/JGKeH
19:45:09 <nielsm> and now you have an invalid pointer stored in the member
19:45:22 <TrueBrain> well, I would guess the data is in .data
19:45:27 <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 https://git.io/JGKBm
19:47:50 <TrueBrain> that would be so awesome, if you could call a hotline
19:47:57 <TrueBrain> and he just rants at you for 5 minutes straight
19:47:59 <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:52:35 <TrueBrain> euh, that "static inline" shouldn't be there ofc
19:53:11 *** gelignite has quit IRC (Quit: Stay safe!)
20:02:12 *** jottyfan has quit IRC (Quit: jottyfan)
20:02:29 <TrueBrain> shall we rename "Pointers" to "FixPointers" while we still can with little effort? :D
20:02:41 <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:06:26 <Rubidium> mostly "convert pool indices to pointers" (IIRC)
20:07:18 <TrueBrain> it is a bit odd, but on Load() it puts an (int32) in the (void *) of the destination
20:07:28 <TrueBrain> FixPointers then picks up those values, and makes it into the real (void *)
20:07:50 <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:09:18 <TrueBrain> and sanitizers don't pick up on it yet
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:11 <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: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 (Ping timeout: 480 seconds)
20:15:58 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
20:15:58 *** V453000 has quit IRC (Ping timeout: 480 seconds)
20:15:58 *** ^Spike^ has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** Osai has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** Ammler has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** avdg has quit IRC (Ping timeout: 480 seconds)
20:15:59 *** Yexo has quit IRC (Ping timeout: 480 seconds)
20:16:02 <TrueBrain> owh, hmm .. C++ isn't Python .. I cannot store the class itself .. only instances ..
20:16:13 <TrueBrain> owh well, "new handler()" it is in SLEG_SUBLST :P
20:16:16 <Rubidium> frosch123: practically it shouldn't be size_t ;)
20:19:20 *** Hazzard has joined #openttd
20:22:44 <TrueBrain> /* Don't run when savegame version lower than 161. */
20:22:44 <TrueBrain> if (IsSavegameVersionBefore(SLV_161)) return;
20:22:52 <TrueBrain> I am always happy with comments that ... explain ... the code?!
20:26:21 <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 (Ping timeout: 480 seconds)
20:26:58 *** SmatZ has quit IRC (Ping timeout: 480 seconds)
20:26:58 *** tneo has quit IRC (Ping timeout: 480 seconds)
20:26:59 *** fonsinchen has quit IRC (Ping timeout: 480 seconds)
20:29:28 <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:17 <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:37:06 <TrueBrain> glx: well, that is no luck ofc
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: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: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:39 <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:09 *** Terkhen has joined #openttd
20:52:09 *** ChanServ sets mode: +o Terkhen
20:59:48 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
21:00:25 <frosch123> c++ is going in the opposite direction :)
21:00:47 <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 (Ping timeout: 480 seconds)
21:13:25 *** Samu has quit IRC (Quit: Leaving)
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:16 <TrueBrain> on-save can do it just fine .. it just doesn't :P
21:21:27 <frosch123> hmm, that would mean, if the save code is broken, you cannot save at all :p
21:21:41 <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:26 <TrueBrain> as than you have headers :)
21:25:34 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9338: Several code refactors of the SaveLoad code https://git.io/JGhXd
21:25:46 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame https://git.io/JGlmd
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:28:00 <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 https://git.io/JGlmd
21:32:12 <glx> Oh a nice comment " * Do something of which I have no idea what it is :P"
21:32:43 <frosch123> haha, i think tb posted that one 2 days ago :p
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:51 <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:10 <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:52 *** fonsinchen has joined #openttd
21:44:54 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
21:47:11 *** andythenorth has quit IRC (Quit: andythenorth)
21:48:23 *** Hazzard has joined #openttd
21:49:15 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:50:17 *** planetmaker has joined #openttd
21:50:17 *** Hirundo has joined #openttd
21:50:17 *** ChanServ sets mode: +o planetmaker
21:52:05 *** ^Spike^ has joined #openttd
21:52:43 *** sla_ro|master has quit IRC ()
22:04:15 *** Terkhen has joined #openttd
22:04:15 *** ChanServ sets mode: +o Terkhen
22:06:11 <_dp_> and I thought zstd has bad docs...
22:06:24 <_dp_> liblzma just links to zlib docs xD
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:33:51 <glx> but it's probably because it's in a ChunkHandler[]
22:37:13 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
22:42:50 *** XeryusTC has joined #openttd
22:48:33 *** avdg has quit IRC (Ping timeout: 480 seconds)
22:48:33 *** V453000 has quit IRC (Ping timeout: 480 seconds)
22:48:33 *** tneo has quit IRC (Ping timeout: 480 seconds)
22:48:34 *** Yexo has quit IRC (Ping timeout: 480 seconds)
22:48:34 *** Hirundo has quit IRC (Ping timeout: 480 seconds)
22:48:34 *** Osai has quit IRC (Ping timeout: 480 seconds)
22:48:34 *** Ammler has quit IRC (Ping timeout: 480 seconds)
22:53:12 *** Progman has quit IRC (Remote host closed the connection)
22:56:49 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
22:56:49 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
22:56:49 *** ^Spike^ has quit IRC (Ping timeout: 480 seconds)
23:03:15 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:04:11 *** ^Spike^ has joined #openttd
23:04:33 *** V453000 has joined #openttd
23:18:10 *** Hazzard has joined #openttd
23:25:24 *** tneo has quit IRC (Ping timeout: 480 seconds)
23:25:49 *** Ammler has quit IRC (Ping timeout: 480 seconds)
23:25:49 *** V453000 has quit IRC (Ping timeout: 480 seconds)
23:25:49 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
23:25:58 *** Osai has quit IRC (Ping timeout: 480 seconds)
23:25:59 *** ^Spike^ has quit IRC (Ping timeout: 480 seconds)
23:26:03 *** Yexo has quit IRC (Ping timeout: 480 seconds)
23:27:19 *** SmatZ has quit IRC (Ping timeout: 480 seconds)
23:27:23 *** Terkhen has quit IRC (Ping timeout: 480 seconds)
23:27:23 *** fonsinchen has quit IRC (Ping timeout: 480 seconds)
23:30:19 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
23:58:13 *** fonsinchen has joined #openttd
continue to next day ⏵
