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 https://git.io/JOSBr 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 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: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 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: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> https://github.com/OpenTTD/OpenTTD/blob/master/src/town_cmd.cpp#L2162 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> https://www.fhbrundle.co.uk/files/image/co1/product%20details/Gate%20closer/Gate%20Return%20Spring%20edit.jpg 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> https://www.amazon.co.uk/Gate-Shut-Closer-closing-adjustable/dp/B06X91KLDB 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. https://git.io/JsHuK 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 https://git.io/JGhXd 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: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> https://github.com/OpenTTD/OpenTTD/pull/9338/commits/6550c0ded912b84ff0a2f49ef0379d2d2838bfcd#diff-87c3e5407b6eca886e12e04dd4eeab4c813556d4939ed0d2cfb30c46e8e175c5R1217 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 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 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 https://git.io/JGlmd 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 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: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 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: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 https://pastebin.com/raw/rmn8cHF6 14:22:44 <Samu> seems weird 14:28:06 <Samu> well, it passed over there, so i guess it's fine https://github.com/OpenTTD/OpenTTD/actions/runs/911884271 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 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: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 https://git.io/JZvUR 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 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: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> https://newgrf-specs.tt-wiki.net/wiki/NML:Builtin_functions 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 https://git.io/JLxCt 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 https://git.io/JtnEF 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: https://gist.github.com/TrueBrain/f13f1aefa636b768e8be2b5c9d1d9d29 <- 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 https://git.io/JZfOQ 17:35:10 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #9180: Codechange: Remove FOR_ALL_CHUNK_HANDLERS https://git.io/J3B9h 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? https://dpaste.org/2Xxp 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> https://gist.github.com/TrueBrain/f13f1aefa636b768e8be2b5c9d1d9d29 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> https://gist.github.com/TrueBrain/f13f1aefa636b768e8be2b5c9d1d9d29 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> https://gist.github.com/TrueBrain/f13f1aefa636b768e8be2b5c9d1d9d29 <- 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> https://godbolt.org/z/rGexo8rEe <- 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 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: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> https://godbolt.org/z/7P4rx41nr <- "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: https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern ) 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 https://git.io/JGCaz 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: https://gist.github.com/TrueBrain/5e347225a887cb907ed4146112d2a9e1 <- 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 https://git.io/JZJvN 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 https://godbolt.org/z/6EE4vsPEj 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 https://git.io/JZJJS 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 https://git.io/JGKeH 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 https://git.io/JGKBm 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> https://gist.github.com/TrueBrain/5e347225a887cb907ed4146112d2a9e1 <- 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> https://gist.github.com/glx22/02493484b52570a10b360d5dcd92fc65 <-- 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: https://en.cppreference.com/w/cpp/language/reinterpret_cast 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> https://github.com/OpenTTD/OpenTTD/compare/master...glx22:saveload <-- 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> https://github.com/OpenTTD/OpenTTD/blob/master/src/saveload/town_sl.cpp#L242 vs https://github.com/OpenTTD/OpenTTD/blob/master/src/saveload/town_sl.cpp#L267 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> https://github.com/OpenTTD/OpenTTD/commit/756431263b612e5064ab2369608149c0fd2193e8 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 https://git.io/JGhXd 21:25:47 <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: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 https://git.io/JGlmd 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