Log for #openttd on 12th June 2021:
Times are UTC Toggle Colours
00:15:44  *** Progman has quit IRC
00:28:33  *** Gustavo6046 has joined #openttd
00:42:30  *** Gustavo6046 has quit IRC
01:00:37  *** Gustavo6046 has joined #openttd
01:34:11  *** Wormnest has quit IRC
02:54:08  *** D-HUND has joined #openttd
02:57:35  *** debdog has quit IRC
03:09:43  *** glx has quit IRC
04:31:22  *** WormnestAndroid has quit IRC
04:33:17  *** WormnestAndroid has joined #openttd
05:05:38  *** Flygon has joined #openttd
05:31:44  *** Flygon has quit IRC
06:21:27  *** Flygon has joined #openttd
06:30:33  *** WormnestAndroid has quit IRC
06:33:07  *** WormnestAndroid has joined #openttd
06:39:51  *** sla_ro|master has joined #openttd
06:40:08  *** paulus[m] has quit IRC
06:41:11  *** WormnestAndroid has quit IRC
06:41:54  *** WormnestAndroid has joined #openttd
06:47:01  *** tokai has joined #openttd
06:47:01  *** ChanServ sets mode: +v tokai
06:54:04  *** tokai|noir has quit IRC
06:57:39  *** andythenorth has joined #openttd
07:06:02  <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #9344: Change: Reduce real sprite groups if possible.
07:06:14  *** nielsm has joined #openttd
07:07:00  <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #9289: Change: Shortcut varaction chains for callbacks.
07:45:39  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
07:54:38  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
08:03:50  *** outtatime is now known as whatsthetime
08:06:31  *** jottyfan has joined #openttd
08:15:25  <andythenorth> today I will mostly be watching slow CI jobs :P
08:15:32  * andythenorth works the weekend
08:15:35  <andythenorth> 22 mins for each run
08:15:46  <andythenorth> atomic commits
08:15:55  <TrueBrain> sounds like fun!
08:16:00  <TrueBrain> wait, no
08:16:02  <TrueBrain> that is the wrong word
08:16:03  <TrueBrain> eeuuhhh
08:16:05  <TrueBrain> :P
08:20:40  *** HerzogDeXtEr has joined #openttd
08:42:52  <TrueBrain> Broken savegame: list exceeds storage size
08:42:53  <TrueBrain> oops :D
08:44:34  <andythenorth> 'tried to read beyond bounds of image' is my frequent equivalent :P
08:57:03  *** Wolf01 has joined #openttd
08:57:10  *** Progman has joined #openttd
09:01:13  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
09:01:14  <TrueBrain> now companies are exportable as JSON too :D
09:01:58  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
09:15:25  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
09:16:48  <nielsm>   some of this is actually not a bad idea... put down buoys and then when you make a ship go to a dock or depot in the orders, do full pathfinding from previous to selected destination but try to incorporate buoys... it would probably be heavy to do, but it can be done clientside and just send a series of "add order" commands
09:18:00  <TrueBrain> "but you ruin the game, you make it too easy!!!!" :P
09:18:03  <TrueBrain> sorry, someone had to say it
09:19:05  <TrueBrain> but yeah, we have no lack of "good ideas" for this game :)
09:19:27  <Rubidium> just a lack of good developers doing the work
09:22:57  <_dp_> how about just fixing ship pf so it doesn't need bouys at all? :p
09:23:13  <nielsm> nah that would be too sensible
09:36:16  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
09:39:21  *** Samu has joined #openttd
09:45:15  *** Progman has quit IRC
09:52:33  *** tokai|noir has joined #openttd
09:52:33  *** ChanServ sets mode: +v tokai|noir
09:58:42  <Samu> are subsidies disabled when cargodist is in place?
09:59:33  *** tokai has quit IRC
09:59:49  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
09:59:49  <Samu> damn, that was it!
10:00:13  <Samu> there is no mention of it anywhere :(
10:02:41  <Rubidium> there definitely is in the logs of this channel
10:05:17  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
10:14:23  *** outtatime has joined #openttd
10:14:27  *** whatsthetime has quit IRC
10:19:14  *** frosch123 has joined #openttd
10:23:21  * andythenorth oof 100% diff to read
10:23:27  <andythenorth> that's almost same as 0%?
10:25:01  <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9289: Change: Shortcut varaction chains for callbacks.
10:27:46  <Samu> just got a 1.11.2 crash
10:29:53  <DorpsGek> [OpenTTD/team] frosch123 commented on issue #228: [pt_BR] Translator access request
10:32:51  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened issue #9353: Crash Report
10:33:52  *** virtualrandomnumber has joined #openttd
10:34:23  *** virtualrandomnumber has quit IRC
10:43:43  <Wolf01> I got lured again into a treasure hunt in google earth
10:59:42  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on issue #9353: Crash Report
11:02:27  <Samu> i think garbage collector was running
11:02:50  <Samu> but i dunno what could go wrong
11:07:10  *** andythenorth has quit IRC
11:15:58  *** WormnestAndroid has quit IRC
11:17:23  *** WormnestAndroid has joined #openttd
11:43:25  <TrueBrain> 	_animated_tiles.clear();
11:43:25  <TrueBrain> 	_animated_tiles.resize(_animated_tiles.size() + count);
11:43:29  <TrueBrain> how is that size() useful? :P
11:45:23  <michi_cc> That's discrimination against known constants :P
11:46:54  *** HerzogDeXtEr has quit IRC
11:50:06  <TrueBrain> :D
11:56:50  <frosch123> maybe add an assert(_animated_tiles.size() == 0), just to be on the safe side
11:57:10  <TrueBrain> dunno, means saving can maybe fail :P
11:57:12  <frosch123> hmm, do we have gsl now? then ensures(...) ofc
11:57:19  <TrueBrain> we do not
11:57:38  *** andythenorth has joined #openttd
11:59:22  *** tokai has joined #openttd
11:59:22  *** ChanServ sets mode: +v tokai
12:06:23  *** tokai|noir has quit IRC
12:19:49  <TrueBrain> SLE_ARR(LoggedChange, revision.text,     SLE_UINT8,  GAMELOG_REVISION_LENGTH),
12:19:53  <TrueBrain> I wonder why that is not a SLE_STR ..
12:22:26  <frosch123> there was a similar thing in the ai saveload stuff
12:22:36  <frosch123> i wondered whether SLE_STR is somehow newer
12:22:48  <TrueBrain> another GameLog thing does use SLE_STR
12:22:57  <frosch123> ok :p
12:23:04  <TrueBrain> but the file got moved
12:23:08  <TrueBrain> so hard to see if they are introduced at the same moment
12:34:28  <TrueBrain> debugging SaveLoad stuff remains really really difficult
12:43:17  <TrueBrain> SLE_CONDNULL(4, SLV_6, SL_MAX_VERSION)
12:43:21  <TrueBrain> I forgot we still had these gems
12:48:29  <frosch123> is that for inserting stuff in stable releases without savegame bump?
12:48:42  <TrueBrain> we used to have those in all structs, so indeed we could add fields freely
12:48:44  <TrueBrain> most have been removed
12:48:47  <TrueBrain> but a few have remained
12:57:42  *** glx has joined #openttd
12:57:42  *** ChanServ sets mode: +v glx
13:04:39  <TrueBrain> @base 10 16 26
13:04:39  <DorpsGek> TrueBrain: 1A
13:04:47  <TrueBrain> shit, I should hav elooked at my DHCP settings, sooorrryyyy
13:04:49  <TrueBrain> not a real nerd :(
13:05:01  <frosch123> just wanted to write that :)
13:05:10  <TrueBrain> :D
13:05:26  <glx> oh you were in gamelog area
13:05:28  <TrueBrain> it still cracks me up
13:06:18  <glx> it's so C stuff
13:06:29  <TrueBrain> its really weird
13:06:35  <TrueBrain> but I am going to make it a bit more pretty :)
13:07:46  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
13:08:05  <TrueBrain> right, fixed that all lists now have a gamma before the list
13:08:13  <TrueBrain> 10000x easier to read now for external tools :P
13:13:47  <glx> Samu: your crash is weird as ScriptObject::GetActiveInstance() is never supposed to return nullptr, there's even an assert ensuring that in non stable release builds
13:14:48  <Samu> i think it's related to garbage collector being run on non active instances
13:15:29  <Samu> trying to figure out where instances get active and deactivated
13:15:30  <_dp_> TrueBrain, does it allow unknown chunk types btw?
13:15:44  <glx> but the instance is active when it's started, it's if (Company::IsValidAiID(cid)) Company::Get(cid)->ai_instance->CollectGarbage();
13:17:16  <TrueBrain> _dp_: let me find my mind-reading device again ... nope, still broken, sorry!
13:17:48  <Samu> in debug mode, the assert happens somewhere else
13:17:57  <Xaroth> I think you left your crystal ball at the bar, TrueBrain.
13:18:27  <Samu> line 53 of script_object.cpp assert(ScriptObject::ActiveInstance::active != nullptr);
13:18:31  <TrueBrain> error: cannot convert ‘std::_Bit_reference*’ to ‘bool*’ <- lol @ error :)
13:18:58  <_dp_> TrueBrain, you ignore unknown fields in chunks but what happens if chunk type itself is not known?
13:19:00  <glx> Samu: yes, because asserts are disabled for non beta releases
13:19:40  <TrueBrain> _dp_: invalid chunk types is in any sense unrecoverable
13:20:19  <Samu> I reproduced the issue in current master
13:20:23  <Samu> still happens
13:20:32  <_dp_> there is nothing to recover, it just shouldn't be the fatal error by the same logic
13:20:43  <TrueBrain> that makes 0 sense
13:20:54  <TrueBrain> here you have a blob of data you know NOTHING about, not the length, not the content, nothing
13:21:02  <_dp_> yes, skip it
13:21:03  <TrueBrain> but ... "read" it anyway?
13:21:12  <TrueBrain> if you don't know the type, you don't know the length
13:21:16  <_dp_> and you know length
13:21:17  <TrueBrain> so .. magic?
13:21:36  <glx> Samu: is it easy to reproduce ?
13:22:19  <Samu> hmm, yes, and no. Seems to happen during garbage collection
13:22:32  <Samu> when the AI finishes a pathfind run
13:22:38  <Samu> which is not that often
13:23:16  <Samu> basically, just run several Ludiai afterfixes v18
13:23:25  <Samu> and wait for it to trigger
13:24:21  <_dp_> TrueBrain, basically if patches add fields to existing objects it's mostly fine and will be ignored
13:24:35  <_dp_> but if there is no suitable object to put stuff in it can't just add another chunk
13:25:29  <Samu> i've been lucky maybe, with 3 Ai's in the first 2 years, i got a crash
13:25:46  <Samu> could take longer though
13:26:13  <TrueBrain> _dp_: you seem to heavily confuse chunk-type with chunk-ids
13:26:23  <TrueBrain> but no, OpenTTD is backwards compatible, not forwards compatible
13:26:27  <Rubidium> Samu: do you have more of the stack trace somewhere?
13:26:29  <TrueBrain> my changes will not change that
13:27:17  <_dp_> TrueBrain, neither did they change backward-compatibility :p
13:28:13  <_dp_> at least, hopefully xD
13:28:29  <Samu> nop, i posted a crash though
13:29:27  <Samu> im trying to have it crash again, will make a better trace
13:32:03  *** jottyfan has quit IRC
13:32:10  *** Progman has joined #openttd
13:34:26  <_dp_> TrueBrain, and pr even has no motivation besides the settings chunk so it's unclear why you did it at all when it hardly changes anything for the game itself :p
13:34:37  <glx> my best guess is some ScriptObject deletion happening earlier as that will modify ScriptObject::active
13:34:51  <TrueBrain> @kick _dp_ stop the endless gatekeeping
13:34:51  *** _dp_ was kicked by DorpsGek (stop the endless gatekeeping)
13:34:51  *** _dp_ has joined #openttd
13:35:16  <_dp_> and for settings same could be achieved with other ways like adding explicit id
13:35:31  <_dp_> wtf? you're pr is lacking motivation and I'm gatekeeping?
13:35:45  <TrueBrain> you can ASK for things, but you are not ASKING
13:36:01  <_dp_> it's a good to make format better but it's mostly useful for external tools not the game itself
13:36:03  <TrueBrain> I am done with having to "defend" my stuff
13:36:10  <TrueBrain> ask questions if you are curious
13:36:18  <TrueBrain> stop assuming random stuff and making it a truth and forcing me to defend it
13:36:29  <TrueBrain> it is stupid, unproductive and not constructive in any way
13:37:13  <_dp_> TrueBrain, and I'm ASKING, what's the motivation of your pr
13:37:30  <TrueBrain> you were not ASKING anything. You stated a lot of things
13:37:32  <_dp_> because to me it goes way beyond what it declares
13:38:00  <_dp_> but when I ask about possible uses you ignore them
13:38:50  <TrueBrain> just read back how you talk lately .. it rarely is in any form of a question
13:38:54  <TrueBrain> you judge, claim things
13:38:56  <TrueBrain> and demand an answer
13:38:58  <TrueBrain> it is not fun
13:39:00  <Rubidium> to me it reads like: "As I was messing about with the settings, to make things easier I wanted to make the settings chunk self-declarative. But then figured out making the whole savegame self-declarative would be better in the long run"
13:39:01  <TrueBrain> not in the slightest
13:39:24  *** norri has joined #openttd
13:39:30  <_dp_> TrueBrain, ffs, you even build a full savegame explorer using pr that only pretends to ease up managing settings
13:41:10  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
13:41:13  <TrueBrain> right, animated-tiles done ... now for gamelog blob ... oof ..
13:41:59  <Rubidium> _dp_: you're wrong... he's doing it to add STUN and TURN... ;)
13:42:11  <_dp_> oh xD
13:43:18  *** jottyfan has joined #openttd
13:43:26  <TrueBrain> do we have any tooling that reads the gamelog currently?
13:44:33  <TrueBrain> I guess crash.log is our main way of reading it :D
13:44:37  <Rubidium> maybe some crashlog decoder thing?
13:45:37  <glx> there are console commands IIRC
13:48:02  <_dp_> TrueBrain, btw, speaking of fun, I have a lot of code that works with current savegame format. and while new format in theory can make managing it easier it can also just break things completely if those possibilities are not realised
13:48:18  <_dp_> and it's not fun when someone breaks a lot of your stuff for no good reason
13:52:28  *** Tirili has joined #openttd
13:54:16  <nielsm> regardless of making a new, easier to parse format, the parser for the old format needs to remain too
13:55:32  <_dp_> nielsm, depends on what you're talking about. game needs compatibility for sure, but, for example savegame diff tool for desync debugging can go with complete switch
13:57:47  <Rubidium> is that diff "intelligent" in that it can say which vehicle ID has the difference, or is it for the human to figure that out based on a hex dump?
13:59:03  <Rubidium> as with the self-descriptive chunk definition the information what the bits mean would get added to the savegame and implementing it once in the diff tool means that (barring and significant format changes), you do not need to update the diff tool when a field gets added, changed or removed
13:59:30  <Rubidium> you might even be able to start diffing between different savegame versions, if you ignore the fields that are not in common between both
14:00:38  <_dp_> well, I was talking some tool in general, but mine for example does stuff like this:
14:02:20  <_dp_> and I fully agree that self-descriptive format can make this tool much simpler
14:02:32  <_dp_> but it's hard to tell for sure with intentions of format change being unclear
14:02:46  <_dp_> and my tool already works fine with existing format
14:09:54  <Samu> im not being lucky this time, still waiting for a crash
14:11:07  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9352: Codechange: use the fmt library for simpler debug formats
14:11:57  <glx> I can see how it could crash, but not exactly why
14:12:03  <glx> and I can't reproduce
14:12:33  <Samu> try a small map
14:12:38  <Samu> 256x256
14:12:48  <glx> that's the size I'm using
14:13:03  <glx> but it's running at less than 1.0x
14:13:11  <peter1138> That's a normal size map, not small :p
14:13:13  <Samu> running 3 AIs, disable aircraft
14:13:56  <Samu> max loan is 300k, not sure if it matters
14:14:25  <Samu> im unsure how garbage collector works
14:14:49  <Samu> sometimes I'm out of money, but the AI doesn't cancel the pathfinding, so the priority queue remains alive
14:15:02  <Samu> it waits for money before resuming pathfind
14:15:20  <TrueBrain> lol @ peter1138 :)
14:21:49  <Samu> glx, try the crash.sav and type restart, it just crashed for me 2 years in
14:22:53  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on issue #9353: Crash Report
14:26:57  <glx> the trace doesn't show the cause, only the consequence
14:27:13  <Samu> i don't have anything else
14:27:27  <glx> I know
14:30:00  <glx> and with FFWD having no effect it's hard to debug
14:30:22  <TrueBrain> game not fast enough? :)
14:30:52  <glx> running at less than 1x
14:31:02  <TrueBrain> off
14:31:03  <TrueBrain> oof
14:31:06  <TrueBrain> typing, hard
14:32:37  <Samu> my ai randomizes some settings on load, makes it even harder to reproduce
14:32:56  <TrueBrain> frosch123: ah, indeed, SLE_STR reads/writes a "char *" .. and I do not think we have anything else to store char[] with :)
14:33:08  <TrueBrain> so it does make sense .. somewhat :P
14:33:09  <Samu> a long standing bug that you didn't fix :(
14:33:55  <Samu> got a crash again! 24th nov 1952
14:35:44  <Rubidium> yeah, the ActiveInstance does not get set when collecting the garbage there
14:36:05  <glx> yes, but sometimes it seems to work
14:36:31  <frosch123> TrueBrain: didn't rb add std::string for everything?
14:36:35  <glx> probably using the worng instance then
14:36:37  <TrueBrain> frosch123: support, yes
14:36:38  <Rubidium> so probably the priority queue was used somewhere in a set of structures that has a loop, so it would not be freed "normally". Only the garbage collector could solve that
14:36:55  <TrueBrain> we just have places to change :)
14:37:35  <Rubidium> so the normal "goes out of scope" collection would usually take care of releasing/freeing the priority queue. Only in this situation / for this AI the location where it is stored differs and boom
14:37:46  <DorpsGek> [OpenTTD/OpenTTD] Turtle-PL started discussion #9354: /Discord screenshot channel (not competition)/
14:38:40  <peter1138> Discord bugs now, what.
14:39:45  <Rubidium> the biggest problem with solving the "active instance" issue is figuring out where to change the const(s)
14:40:03  <_dp_> you made it "official", deal with it! :p
14:40:25  <_dp_> also looks like someone missed #trainboard
14:43:00  <Rubidium> Samu/glx: <- a potential solution for that issue
14:44:24  <Samu>  will try, but... i still don't have a sure method to replicate
14:44:26  <glx> makes sense yes
14:46:09  <glx> the issue is it's hard to reproduce the crash, so testing a fix won't be easy
14:51:24  <TrueBrain> meh ... back to battles SaveLoad errors :P
14:52:01  *** Wormnest has joined #openttd
14:52:02  <Rubidium> the trick is to make something with an internal circular reference that also references the priority queue, and then releasing the "stack" reference to that. So it could probably be implemented as a regression quite easily... if only one could trigger the garbage collection at the right time (tm)
14:52:25  <glx> at least with this change CollectGarbage() is similar to other members calling this->engine functions
14:54:13  <glx> and seems more sane
14:54:18  <glx> (and safe)
14:55:02  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on discussion #9354: Discord request: screenshot channel (not competition)
14:55:06  <Samu> no crash so far, 1954
14:55:16  <Samu> will restart again
14:56:58  <TrueBrain> 			SlObject(la, _glog_action_desc); // has to be saved after 'DATE'!
14:57:02  <TrueBrain> during loading ..
14:57:06  <TrueBrain> some comments are weird
14:57:10  <glx> AI caused crashes are the worst to trace, because it's often random
14:57:37  <glx> TrueBrain: it's clearly not saved after DATE as GLOG is the first chunk ;)
14:57:56  <TrueBrain> exactly :)
14:58:22  <glx> I think originally it was, then we moved the chunk
14:59:29  <TrueBrain> I am staring at this gamelog chunk code .. maybe I should just add debug lines instead ..
14:59:55  <glx> all the ReallocT
15:00:09  <TrueBrain> it reads too few or too many bytes in my new code
15:00:10  <TrueBrain> so annoying
15:00:14  <TrueBrain> as you have 0 info to go on
15:00:14  <glx> when a vector should be easier to understand
15:00:52  *** tokai|noir has joined #openttd
15:00:52  *** ChanServ sets mode: +v tokai|noir
15:01:25  <glx> but when you save a game you can load it back ?
15:01:37  <TrueBrain> no, that part fails :P
15:02:00  <glx> ha so it fails for all saves, even the old ones
15:02:06  <TrueBrain> nope
15:02:15  <TrueBrain> only my new save code fails
15:02:38  <glx> oh weird, usually it's the opposite
15:03:03  <TrueBrain> I have a pretty good handle on the old stuff now :P
15:03:18  <glx> code is visible somewhere, or not pushed yet ?
15:04:28  <TrueBrain> not till I fixed it :)
15:05:08  <TrueBrain> haha, it reads an optional struct as "103" (instead of 0/1)
15:05:10  <TrueBrain> that .. is not right :D
15:06:32  <glx> so much magic in length calculation (well not magic, but still)
15:06:47  <TrueBrain> yeah ... and after your and mine change, we can remove a lot of that weirdness
15:06:56  <TrueBrain> as most of it is completely unneeded complex
15:07:01  <TrueBrain> to support weird scenarios I now removed :P
15:07:44  *** tokai has quit IRC
15:08:34  <glx> like +=4 in the loop (for action type, desc, and final none change), then a +1 for final none action
15:10:34  <TrueBrain> okay, that was just stupid what I did .. lol
15:10:56  <glx> inserted your stuff in the right place ?
15:11:12  <TrueBrain> very hard to explain whatI fucked up, but it was a brainfart :P
15:12:01  <glx> GLOG saveload code looks complex, but the format itself is quite simple
15:13:36  <glx> and the complexity is mostly because Gamelog structs are weird :)
15:13:59  <TrueBrain> okay, now I have to add headers ... then I can normally view GLOG too .. that should be simple
15:15:35  <glx> because it's C stuff it uses unions and dynamic C array when vector and subclasses would be simpler I think (but refactoring is not easy)
15:15:47  <Rubidium> GLOG should be similar in functionality/layout as stations/vehicles, but due to the union it's not. Though practically each of the logged change types could be its own class. Are you going into that direction? Though I guess... maybe not in scope?
15:15:51  <TrueBrain> refactoring is mostly just time
15:16:08  <TrueBrain> I changed the saveload code to be like vehicles
15:16:24  <TrueBrain> changing the rest in a similar way I leave as exercise to the reader :P
15:22:28  *** Tirili has quit IRC
15:26:03  <Samu> not getting any crash so far, i restarted 3 times already
15:30:49  <TrueBrain> haha, SL_STR are now a list of bytes in my reader :D
15:30:51  <TrueBrain> that looks funny :D
15:32:29  <TrueBrain> euh, no, it was an SL_ARR from SLE_UINT8s
15:32:31  <TrueBrain> so it is not wrong
15:32:34  <TrueBrain> just looks really weird :P
15:32:45  <TrueBrain> I think it is the only field doing this
15:33:17  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
15:33:17  <TrueBrain> okay, gamelog done ..
15:34:07  <TrueBrain> that leaves ... gamescript translations and linkgraph
15:34:14  <TrueBrain> well, and map-chunks, ofc
15:34:41  <TrueBrain> like really close now .. and then some splitting up over more than 2 PRs :D
15:42:23  <TrueBrain> "Broken savegame - Invalid gamelog action type" <- at least 1 bug .. it is funny that 100+ savegames loaded fine
15:42:23  <TrueBrain> but 1 failed
15:44:45  <frosch123> is there a bounty for "find a savegame that loads in master, but fails in tb's branch"?
15:46:03  <TrueBrain> yes
15:46:10  <TrueBrain> I found one
15:46:13  <TrueBrain> can I collect the bounty now?
15:46:17  *** AmaNet has joined #openttd
15:46:25  <AmaNet> So this is IRC
15:47:11  <frosch123> yes, 5 people talking, 153 people idling
15:47:41  <AmaNet> Cool
15:47:52  <AmaNet> Never used something like this before
15:47:57  <glx> frosch123: in which group are you placing DorpsGek ?
15:48:12  <frosch123> dorpsgek is best boy
15:48:31  <TrueBrain> so sad there is no more @say :P
15:49:06  <AmaNet> what is +glx
15:52:06  *** AmaNet has quit IRC
15:57:31  <TrueBrain> funny, only an emergency save fails loading :D
15:57:35  <TrueBrain> well, who needs to load those anyway?
15:59:08  *** iSoSyS has joined #openttd
16:01:06  <_dp_> indeed, who needs to debug desyncs? >:-)
16:01:08  <Samu> hmm, 24th Nov 1952 this is semi-reproducible
16:01:15  <Samu> got a crash on this day again
16:04:33  <Samu> 17th Apr 1952, nop, not reproducible
16:05:47  <Samu> with rubidium fix, it has yet to crash
16:06:04  <Samu> im now testing without it, trying to make it reproduceable
16:08:48  <norri> is there something else that should be submitted together with NewGRF feature PR? I've got a NML patch ready, but I'm thinking that's better to do only after the PR is merged?
16:09:30  <TrueBrain> I see no reason not to create it already; just mark it that it depends on merging of another PR :)
16:12:43  <glx> it's even better that way, as it allows testing :)
16:12:55  <TrueBrain> and shows you mean business :D
16:13:01  <TrueBrain> not just a drive-by-commit :P
16:13:11  <norri> alright, brb then!
16:13:50  <TrueBrain> right, lets see if I fixed the emergency savegame load issue ... pam pam pammmmmm
16:13:59  <TrueBrain> seems so :) Now to test the other 500 savegames :P
16:14:13  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
16:17:06  *** sla_ro|master has quit IRC
16:17:08  *** iSoSyS has quit IRC
16:20:20  <TrueBrain> hmm .. how to use jq with a dot in the name ..
16:21:32  <DorpsGek> [OpenTTD/nml] vituscze opened pull request #222: Feature: Support for rail vehicle property 0x2E, curve_speed_mod
16:22:19  <glx> \. ?
16:23:09  <TrueBrain> <- quickly find what versions a savegame is saved in over the years :P
16:24:42  <TrueBrain> I do have to make the Python code faster :P
16:24:47  <TrueBrain> some savegames take for-ever
16:26:24  <frosch123> how big are the json files? writing 200mib of json is not fast
16:26:57  <TrueBrain> well, without JSON export it is very slow too :P
16:27:10  <TrueBrain> and only 30MB of JSON, that is not too bad
16:27:42  <TrueBrain> can't measure the time it takes to JSON dump that
16:27:42  <frosch123> really? we had savegames with 10mb compressed. so 30mb sounds very little
16:27:46  <TrueBrain> it is below the noise :P
16:27:59  <TrueBrain> Sorry, I didn't test all savegames in existence :P
16:28:02  <TrueBrain> lol
16:28:22  <TrueBrain> and do remember the map-chunks are not in the JSON (yet? Dunno)
16:28:46  <TrueBrain> this savegame is 1MB on disk btw
16:29:04  <_dp_> a lot of savegame size is map array, if json skips that it mostly depends on amount of stuff in the game
16:29:20  <TrueBrain> frosch123: but the slowest part seems to be the binreader I "borrowed" from you
16:29:26  <TrueBrain> it is recreated every entry
16:29:31  <TrueBrain> and Python doesn't seem to fancy that too much
16:29:54  <TrueBrain> I didn't really try to optimize it either :D
16:30:13  <TrueBrain> pretty sure if I use a bytesview it becomes significantly faster :)
16:30:25  <TrueBrain> s/bytesview/memoryview/, whatever :P
16:33:07  <TrueBrain> not completely sure why you were thinking I was testing with a 10MB savegame frosch123 :)
16:33:38  <frosch123> hmm, never heard of memoryview, but apparently it's ancient
16:34:03  <frosch123> TrueBrain: i forgot that you used coop savegames, they mostly use sane map sizes
16:34:13  <Samu> queue.stack got 20317 items in it :p
16:34:22  <TrueBrain> in general, testing with extremes isn't fun :P
16:34:50  <TrueBrain> but biggest savegame I have is 3MB
16:35:00  <TrueBrain> called "biggest town ever"
16:35:09  <glx> high number of trains ?
16:35:18  <TrueBrain> I never loaded it in graphically :P
16:35:39  <glx> you can count vehicules with jq ;)
16:35:51  <TrueBrain> but I would guess it is a savegame with a really big town
16:36:30  <TrueBrain> 52M
16:36:31  <TrueBrain> lol
16:36:34  <glx> town size itself doesn't impact savegame as it's all in the map
16:36:35  <frosch123> towns are only maparray though
16:37:03  <TrueBrain> lets see how much the JSON is :P
16:37:26  <TrueBrain> just 175KB
16:37:27  <TrueBrain> owh yeah
16:38:01  <TrueBrain> I wonder if we should export map-chunks as JSON
16:38:08  <TrueBrain> not sure it is useful
16:38:26  <frosch123> for the savegame-diff you need everything
16:38:34  <frosch123> but for maparray i can only think of hexdump :p
16:38:36  <TrueBrain> can do a CRC only, or what-ever
16:39:04  <TrueBrain> well, in an ideal world, you can see what is on a certain tile
16:39:12  <TrueBrain> but .. we don't store things like that in the savegame :D
16:39:13  <glx> decoded map could be nice but it's not that easy
16:39:18  <frosch123> does python impose any sizelimit on strings in json?
16:39:24  <TrueBrain> not that I know
16:39:26  <dwfreed> no
16:39:26  <TrueBrain> and I did some crazy shit
16:39:34  <TrueBrain> there has to be some limit somewhere
16:39:40  <TrueBrain> but .. yeah .. memory runs out before that time :P
16:39:42  <dwfreed> the only limit is your RAM
16:39:43  <frosch123> a single string with 32MB :p
16:39:59  <TrueBrain> 32MB?
16:40:23  <dwfreed> technically you probably couldn't have a string larger than 2^64-1, but good luck reaching that
16:40:40  <TrueBrain> dwfreed: lot of virtual ram :P
16:40:42  <TrueBrain> SSDs
16:40:43  <TrueBrain> lots of them
16:41:10  <dwfreed> Linux isn't even able to address that much
16:41:24  <dwfreed> your page tables probably wouldn't even fit in RAM
16:41:38  <TrueBrain> anyway, ideally I would like to add a header to the map-chunks too, but I just don't see a sensible way of doing that atm
16:41:41  <TrueBrain> ideas are welcome
16:41:47  *** andythenorth has quit IRC
16:42:01  <TrueBrain> otherwise I can just make my reader combine the map-chunks and output per tile the total value in hex or what-ever
16:44:08  <glx> maybe binary output matching landscape_grid.html order
16:44:29  <TrueBrain> that would be a REALLY large JSON output :P
16:44:50  <glx> so it can give a partial detail of the content
16:45:11  <TrueBrain> we also have to balance practicality :)
16:45:35  <TrueBrain> @calc 256 * 256 * (64 + 3)
16:45:35  <DorpsGek> TrueBrain: 4390912
16:45:48  <glx> well that's a display job, not a json job I guess
16:45:54  <TrueBrain> for normal maps it is fine :P
16:45:59  <TrueBrain> if the JSON is 10GB
16:46:05  <TrueBrain> ... ;)
16:46:13  <TrueBrain> @calc 2048 * 2048 * (64 + 3)
16:46:13  <DorpsGek> TrueBrain: 281018368
16:46:28  <TrueBrain> 281MB for 2kx2k if we do the bare minimum JSON
16:46:39  <TrueBrain> so I do not think binary representation is a good idea :)
16:47:05  <_dp_> there's already quite good map array viewer
16:47:09  <_dp_> ? tool in the game :P
16:47:25  <TrueBrain> glx: I think it is a bit the other way around .. JSON needs to output it, a display should show it in a useful format :)
16:47:49  <TrueBrain> owh, we are 96 bits long
16:47:50  <glx> yeah json can output in hek
16:47:50  <TrueBrain> oof
16:47:57  <glx> *hex
16:48:09  <TrueBrain> 24 nibbles long that would be
16:48:18  <TrueBrain> needs 0x and "", as otherwise JSON will do it as integer
16:49:11  <TrueBrain> but anyway, I was more thinking if we should add a header to the map-chunks :)
16:49:26  <TrueBrain> needs any of the newmap branches merged I guess :P
16:49:45  <glx> in current map array, header is useless
16:50:27  <TrueBrain> for diffing, ideal it is {"1": <tile-1-in-hex>, "2": <tile-2-in-hdex>, ...}
16:50:34  <TrueBrain> or maybe per row
16:51:29  <glx> and an option to skip map from json output ;)
16:52:35  <_dp_> for diffing it's somewhat useful to diff map array layers separately
16:52:49  <_dp_> coz some are just noise
16:54:19  <TrueBrain> glx: haha, yes, without doubt :)
16:54:24  <TrueBrain> off by default even
16:54:48  <_dp_> ideal would probaly diff on tile type first and then on fields
16:55:03  <_dp_> filtering out noise somehow
16:56:16  <glx> for that you need output like an array of tiles then
16:57:22  *** jottyfan has quit IRC
16:58:11  <glx> {id, m1, m2, ...} for each tile, then you can filter based on fields
17:02:17  *** snail_UES_ has joined #openttd
17:03:46  *** gelignite has joined #openttd
17:05:54  <Samu> who's michael lutz
17:06:36  <Samu> he created ScriptInstance "in_shutdown"
17:06:48  <Samu> seems to be only used for PriorityQueue
17:08:04  <TrueBrain> Want a pitchfork with that? :D
17:08:38  <Xaroth> How about a torch? we're running specials on torches
17:08:40  <glx> it's to prevent double destruction of stuff
17:08:43  <Xaroth> buy 2 pay for 3.
17:09:45  <glx> anyway it's not the issue, it just triggers it
17:15:17  <Samu> during garbage collection, active instance is always null
17:15:36  *** HerzogDeXtEr has joined #openttd
17:16:20  <Samu> wondering if there's an alternative
17:16:25  <Samu> without relying on instance
17:17:34  <Samu> seems kind of the wrong way to fix to activate the instance for garbage collection just so it won't crash on deleting priorityqueue items
17:18:07  <Samu> how are the items deleted for other things than priority que
17:18:07  *** snail_UES_ has quit IRC
17:18:27  <glx> no it's the right fix
17:20:21  <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #9355: Codechange: Use dynamic string list for contents of land info window.
17:22:58  <michi_cc> Samu: The associated e-mail in the commit might give a hint :)
17:30:51  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9356: Fix #9353: [Script] Garbage collecting on priority queues could crash the game
17:32:40  <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #9356: Fix #9353: [Script] Garbage collecting on priority queues could crash the game
17:38:21  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9322: Add: store table header for each chunk in savegame
17:38:36  <TrueBrain> right, time to check if we can make the reader a bit faster :D
17:41:25  *** andythenorth has joined #openttd
17:41:48  *** Flygon has quit IRC
17:43:12  <Samu> thx for the fix :)
17:43:43  <Samu> I think my AI is still the only one using AIPriorityQueue yet
17:45:32  <Samu>
17:58:18  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9353: Crash Report
17:58:21  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9356: Fix #9353: [Script] Garbage collecting on priority queues could crash the game
18:18:47  <TrueBrain> from 3s to 1.5s already .. getting there
18:33:11  * Rubidium wonders what the conceptual difference between an error and a warning is in console_cmds. In one place being in the menu is an error and nothing gets done, in another it's a warning (and again nothing is done)
18:33:48  <TrueBrain> I have the same with debug levels :D
18:34:01  <TrueBrain> imo, an error doesn't continue, a warning corrects and continues
18:34:05  <Rubidium> and interestingly you can configure it in such a manner that warnings are not shown, so doing something stupid in a command that does warnings shows you no feedback you did something wrong
18:39:11  <TrueBrain> LZMA doesn't like small reads
18:39:12  <TrueBrain> interesting :)
18:39:20  <DorpsGek> [OpenTTD/OpenTTD] Rsmid opened issue #9357: Crash Report of AI
18:52:06  *** D-HUND has quit IRC
18:54:52  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9357: Crash Report of AI
18:54:55  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #9357: Crash Report of AI
18:56:11  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:56:13  <DorpsGek>   - Update: Translations from eints (by translators)
18:56:25  <TrueBrain> wait, eints before 2100? Wowwww
18:57:29  <frosch123> it was also on time yesterday
18:57:42  <TrueBrain> "one time" is still a stretch
18:57:43  <frosch123> probably the dutch announcement to ban bitcoin
18:57:45  <TrueBrain> but yeah :P
18:58:38  <TrueBrain> hmm .. I have nothing anymore to change really ... it is now just slow because it is doing a lot
18:58:45  <TrueBrain>    803576    0.271    0.000    0.563    0.000
18:58:52  <TrueBrain> almost a million uint8 calls :P
18:59:18  <TrueBrain> I could in theory make one huge struct.unpack per header, but .. meh
19:04:15  <Samu> just happened to reproduce the crash scenario, it no longer crashes!
19:10:38  <Samu> - went through to 25th Nov 1952
19:14:18  <Samu> ScriptAllocatorScope is called twice now, is that a problem?
19:25:46  *** jottyfan has joined #openttd
19:28:02  <andythenorth> enough working
19:28:08  * andythenorth wonders what to do now :P
19:31:55  <Samu> I reported something 2 days ago or so, I forgot what it was, lol
19:33:06  <Samu> ah, i remember, the Mungo AI thing with empty files in a .tar archive
19:33:19  <Samu> should I open an issue for it?
19:36:12  <glx> and I told you fileio.cpp:545 can probably be removed without issue
19:44:21  <DorpsGek> [OpenTTD/OpenTTD] SamuXarick opened issue #9358: Bug Report
19:44:29  <Samu> ew, the title is ugly
19:51:51  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9359: Consolidate IConsolePrint functions and improve some of the messages
19:52:24  *** sla_ro|master has joined #openttd
19:57:23  <glx> Rubidium: you may want to link #8894 in your PR
19:58:35  <glx> and #8853
20:00:03  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9355: Codechange: Use dynamic string list for contents of land info window.
20:00:19  <glx> and nice clang warnings :)
20:09:12  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9355: Codechange: Use dynamic string list for contents of land info window.
20:13:10  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9359: Consolidate IConsolePrint functions and improve some of the messages
20:16:13  <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #9355: Codechange: Use dynamic string list for contents of land info window.
20:17:05  <Rubidium> glx: yeah, I thought about linking them though technically those do more or less the opposite of what I attempt to accomplish ;)
20:17:46  <glx> but they can be auto closed by your PR
20:19:24  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9355: Codechange: Use dynamic string list for contents of land info window.
20:26:55  *** J0anJosep has joined #openttd
20:30:41  <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9355: Codechange: Use dynamic string list for contents of land info window.
20:34:50  <TrueBrain> right, 1s .. that is 3 times as fast
20:34:51  <TrueBrain> guess I take it
20:44:01  *** Speeder has joined #openttd
20:53:17  <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9360: Codechange: [Actions] Improve MSYS2 setup time
20:55:23  <TrueBrain> urwid doesn't like a lot of fields in a single entry
20:55:24  <TrueBrain> shocker :P
20:55:37  *** Samu has quit IRC
20:56:32  <TrueBrain> ottdc games have way too many trains :P
20:56:41  <TrueBrain> 15300, by the looks, in this one game
20:56:45  <TrueBrain> well, vehicles
20:56:47  <TrueBrain> not trains
20:56:47  <TrueBrain> ofc
20:57:06  <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #8480: Feature: Multitile depots
20:57:09  <frosch123> sounds like no newgrf
20:57:22  <TrueBrain> huh?
20:57:48  <frosch123> take the early 4/8 vehicles, and you need twice as many wagons for the same train length
20:58:35  <TrueBrain> well, plenty of NewGRFs in the game :P But .. I think ottdc always tries to find some limit :)
20:58:46  <frosch123> also, the steam smoke counts as vehicles
20:59:37  <TrueBrain> how ever you flip the cookie, 15300 vehicles
20:59:40  <frosch123> we increased the vehicle id to 24bit somewhen, because people hit the old 64k limit
20:59:42  <TrueBrain> and urwid has a hard time rendering that :)
21:00:43  <TrueBrain> okay, gave the reader some improvements
21:00:48  <TrueBrain> not only in speed, but also how things render
21:00:53  <frosch123>  <- "enable unicode graphics" xD
21:01:23  <TrueBrain> mainly as I really didn't want to look into the linkgraph saveload code :D
21:02:12  <TrueBrain> there is also blobs of data after each (running) AI and GS, but that is not for this PR :)
21:02:20  <frosch123> i guess when you are done with converting all chunks, you should add some code to prevent people creating new custom chunks :p
21:02:28  <TrueBrain> yeah
21:02:32  <TrueBrain> a lot of things can also be deduplicated
21:02:40  <TrueBrain> and with classes made more understandable
21:02:45  <TrueBrain> read: less room to fuck up
21:02:52  <_dp_> btw, visual effects being vehicles is quite a wtf
21:03:19  <TrueBrain> most chunks are a list of things, and each item is a "pre-filter", that can reject the item, and a "post-load-filter" to fix stuff up
21:03:29  <TrueBrain> so I kinda only want chunks to define the pre and post stuff
21:03:34  <TrueBrain> so the rest is forced to be correct :)
21:03:41  <TrueBrain> but ... lets first get this done :)
21:05:20  <frosch123> poor gog. the number of reviews is depressing, when comparing with steam
21:05:39  <TrueBrain> you expected another 500k users? :P
21:06:24  <frosch123> i did not expect steam to be more active after 9 weeks, than gog at launch
21:07:03  <TrueBrain> Steam is seriously popular :P
21:07:20  <TrueBrain> I would be curious what Epic would do, popularity-wise
21:07:24  *** nielsm has quit IRC
21:08:47  <TrueBrain> Steam Community page did finally die down a bit
21:09:03  <frosch123> i heard about origin and uplay, but never about the epic client
21:09:19  <TrueBrain> you completely missed the Epic Launcher? :D
21:09:28  <TrueBrain> they pushed in some serious money to make it work
21:09:32  <TrueBrain> lot of free games
21:09:43  <TrueBrain> games only on their platform for a year (like Satisfactory)
21:10:02  <frosch123> hey, i have bought 3 games in the past 15 years
21:10:02  <TrueBrain> Origin and Uplay are like the Blizzard launcher
21:10:05  <TrueBrain> "cute", at best
21:10:09  <TrueBrain> hahaha :D
21:10:14  <TrueBrain> okay, I have a tiny bit more games :P
21:11:57  <frosch123> also, did anyone push kamnet to signup at gog forums, or did he do that on his own? :p
21:12:09  <TrueBrain> he even asked if there was anything to moderate
21:12:19  <TrueBrain> he really picked up being the community manager of Steam and GOG
21:12:29  <TrueBrain> which I really appreciate :D
21:13:02  <TrueBrain> okay, JSON diff is always different, because of GLOG chunk :D
21:13:06  <frosch123> i liked that guy who prefered playing ttd in dosbox, because ottd has no ai
21:16:25  <TrueBrain> seeing the old AI is also fun :D
21:16:28  <TrueBrain> terrible, but fun :P
21:16:36  <TrueBrain> hmm .. jq is nice
21:16:40  *** sla_ro|master has quit IRC
21:16:43  <TrueBrain> jq 'del(.chunks.GLOG)
21:16:45  <TrueBrain> works :P
21:16:53  <TrueBrain> well, with closing ' ofc
21:20:43  <TrueBrain> weird, jsondiff is slow with 5MB JSON diffs :P
21:24:02  *** J0anJosep has quit IRC
21:25:18  <TrueBrain> I am still amazed that loading a savegame, saving it, loading both the old and new savegame, running it for 256, gives exactly the same JSON (minus GLOG) .. for most games at least :D
21:25:20  <TrueBrain> pretty sweet
21:27:29  <TrueBrain> lol, I have 1 game that has a different date .. lol, how? :P
21:28:29  *** andythenorth has quit IRC
21:33:30  <TrueBrain> well, I will let this run for ~2 hours, just to see if we really can still load old games .. but it sure does look that way :D Amazing :)
21:34:47  <TrueBrain> @calc 10 * 20 / 60
21:34:47  <DorpsGek> TrueBrain: 3.3333333333333335
21:34:52  <TrueBrain> make that ~3.5 hours
21:35:00  <TrueBrain> ha, I want to see a DHCP server do that!
21:35:16  <frosch123> add ais, they may do different thigns
21:35:28  <TrueBrain> jq 'del(.chunks.GLOG) | del(.chunks.AIPL) | del(.[] | select(. == {}))'
21:35:30  <TrueBrain> :D
21:35:38  <TrueBrain> (remove GLOG, remove AIPL, remove chunks if empty)
21:37:13  <_dp_> ha, AIPL, if AI really does something differently your whole diff is gonna explode :p
21:39:36  <TrueBrain> boy, this is slow ...
21:39:46  <TrueBrain> mainly jsondiff takes a long time
21:41:04  <TrueBrain> again a savegame where both savegames didn't run for the same amount of ticks
21:41:06  <TrueBrain> really odd
21:41:16  <TrueBrain> (as the null-drivers does exactly N ticks :P)
21:45:16  <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #9361: Off by one error in Packet::CanWriteToPacket
21:45:58  <frosch123> hmm, there were many changes to realtime, gametime and other ticks
21:46:07  <frosch123> maybe null driver broke along that
21:46:15  <TrueBrain> good point
21:48:08  <TrueBrain> ah, found a faster jsondiff
21:48:10  <TrueBrain> that is much better
21:50:14  <TrueBrain> it is funny to see a whole game stored in JSON :D
21:50:29  <TrueBrain> lot of zeros :D
21:50:49  <glx> <TrueBrain> lot of free games <-- one every week
21:51:03  <glx> thursday it will be overcooked 2
21:51:49  <glx> but epic is windows only, even for games available on linux
21:51:50  <TrueBrain> btw frosch123 , struct in struct with SQLite really is now rather easy, it just needs to make a table for each struct. As everything is a CH_TABLE, everything has an index, en every SL_STRUCT is forced into a SL_STRUCTLIST, which also has an index
21:52:33  <TrueBrain> I now use this information too in the savegame-reader, to make struct in structs look a lot better
21:53:58  <frosch123> so a bunch of index columns :)
21:54:01  <TrueBrain> yes
21:54:10  <TrueBrain> one for each depth :)
21:54:23  <TrueBrain> not pretty, but should work
21:54:54  <frosch123> i assume the index in the substructs restarts at 0 for every poolitem? so the substruct table would have two columns: pool index + local index?
21:55:10  <frosch123> hmm, though that breaks if a poolitem ever has the same struct in different places
21:55:40  <TrueBrain> well, substructs don't have an index as such, but they have a length and are in the order of 0 .. N
21:55:47  <TrueBrain> so they have a "virtual" index? :P
21:56:06  <TrueBrain> what do you mean: "same struct in different places"?
21:56:46  <frosch123> towns had "delivered" and "produced" cargo or something
21:57:22  <frosch123> both used the same struct, though i guess you treat them as "different" structs in your format
21:57:34  <frosch123> yeah, i guess i overthought that :p
21:57:40  <TrueBrain> yeah, there are 2 things there: SaveLoad deals with names
21:57:52  <TrueBrain> and you cannot have 2 fields with the same name in a single SaveLoad description
21:57:58  <frosch123> it's not necessary to use the same table just because two fields have the same table structure
21:58:01  <TrueBrain> and indeed, each entry gets its own instance of that Handler
21:58:07  <TrueBrain> no :)
21:58:18  <TrueBrain> if you want that, you end up somewhere weird and scary :P
21:58:43  <frosch123> nah, i don't think i want it anymore :p
21:58:50  <TrueBrain> :D
21:58:53  <frosch123> it was just my c++ template mind
21:59:07  <TrueBrain> but I have to make an instance of each handler every time they are used anyway
21:59:08  *** jottyfan has quit IRC
21:59:11  <TrueBrain> as I need to load the header per entry
21:59:15  <TrueBrain> and they might be the same class now
21:59:21  <TrueBrain> but they might not have been the same when saving
21:59:30  <TrueBrain> (and it stores the table in the instance)
22:00:00  <frosch123> i probably told you about that c programmer who was too lazy to define structs, so he stored everything in uint32 arrays, and casted everything (including pointers), in every access to the array
22:00:15  <frosch123> the equivalent in c++ is to use std::tuple for everything
22:00:23  <glx> looks like some part of openttd
22:00:37  <glx> (but not intentionally)
22:01:09  <TrueBrain> frosch123: yeah ... no :P
22:01:31  <glx> hey using array is cast is more work than defining structs
22:01:41  <glx> s/is/cast/
22:01:50  <glx> and
22:01:55  <TrueBrain> we already have some really tricky parts in the SaveLoad code
22:01:55  <glx> I can't type
22:02:07  <TrueBrain> I also found out today that std::vector<bool> does tricks :)
22:02:25  <frosch123> yeah, that one is pretty unpopular :p
22:02:27  <glx> it's a special case
22:02:31  <glx> IIRC
22:02:36  <TrueBrain> I blacklisted it from the SaveLoad system
22:02:45  <TrueBrain> you cannot have a std::vector<bool> :P
22:02:56  <frosch123> people use std::vector<uint8> or std::basic_string<bool> instead
22:03:04  <TrueBrain> basic_string, lolz
22:03:06  <_dp_> bitset! :p
22:03:11  <frosch123> bitset is fixed size
22:03:28  <TrueBrain> but yeah, a lot of our SaveLoad code first casts stuff to void*
22:03:35  <TrueBrain> in the hope it had enough information to cast it back to what-ever it was properly
22:03:42  <TrueBrain> with.. surprisingly little type-checking
22:03:55  <TrueBrain> so you can easily try to store a std::deque via std::vector
22:04:03  <glx> oh don't look in the dll magic thing I added then ;)
22:04:10  <frosch123> TrueBrain: std::basic_string<T> is similary to std::vector<T>, but it features small-vector optimisation and operator+ :)
22:04:29  <TrueBrain> I don't even ....
22:07:07  <glx> usually a void* cast is used to prevent warning for the "real" cast
22:07:29  <TrueBrain> it could really use classes and not casting :)
22:08:13  <glx> but saveload use generic pointers, because macros
22:10:17  <TrueBrain> nothing that has to last :D
22:13:07  <TrueBrain> hmm .. here a savegame that is on the same date, but is slightly different
22:13:46  <TrueBrain> they are around the same version of which I also have variants that fail to load
22:13:47  <TrueBrain> might be related
22:14:26  <TrueBrain> so I load&save the game, which I call original
22:14:40  <TrueBrain> euh, no
22:14:45  <TrueBrain> I call the old savegame original
22:14:53  <TrueBrain> I load&save&load it, and I call that main
22:15:01  <TrueBrain> original "max_train_length" == 100
22:15:04  <TrueBrain> main "max_train_length" == 64
22:15:17  <TrueBrain> in other words: loading of an old game and saving it, seems to give 100
22:15:22  <TrueBrain> load + save + load + save gives 64
22:15:28  <TrueBrain> I think we miss a clamp somewhere :P
22:15:55  <TrueBrain> (as the hard-coded max really is 64)
22:19:39  <TrueBrain> for (Train *t : Train::Iterate()) _settings_game.vehicle.max_" target="_blank">game.vehicle.max_train_length = std::max<uint8>(_settings_game.vehicle.max_" target="_blank">game.vehicle.max_train_length, CeilDiv(t->gcache.cached_total_length, TILE_SIZE));
22:19:43  <TrueBrain> might be related :P
22:20:18  <TrueBrain> so very nice that the afterload.cpp makes the value so your current trains are valid
22:20:24  <TrueBrain> but the next save/load it clamps to 64 again
22:20:28  <TrueBrain> "temporary" solution? :D
22:21:29  <frosch123> haha, so you have a testgame with a train longer than 64 tiles? :p
22:21:41  <TrueBrain> I would guess so, yes :)
22:21:54  <TrueBrain> bit funny, 80% of the games that fail are supplied by Aro :P
22:22:06  <frosch123> typical developer
22:22:08  <TrueBrain> clearly his games are weird :P
22:22:29  <TrueBrain> (which is a really good thing :D)
22:22:57  <TrueBrain> and I have 1 game where a few road vehicles made other choices
22:23:58  <TrueBrain> even supplied stations differently
22:25:36  <TrueBrain> and one game that will 100% desync if the server loaded the old savegame and had someone else join it
22:25:43  <TrueBrain> no clue what it is doing, but it is two totally different things :P
22:27:07  <TrueBrain> remove: /chunks/VEHS/98/effect/0 / add: /chunks/VEHS/98/roadveh/0
22:27:39  <TrueBrain> bit confused by the same index .. as that suggests that roadveh is created after the effect stopped?
22:28:31  <frosch123> autoreplace/renew?
22:28:37  <TrueBrain> possibly
22:29:19  <TrueBrain> so far all the savegames that show a real diff, seem to be roadveh related
22:31:20  <TrueBrain> guess the next step is making it save a savegame every tick :P
22:33:19  <_dp_> if seed changed vehicle diff may not mean anything
22:33:37  <_dp_> especially stuff like busses that instantly desyncs because of house production
22:37:40  <TrueBrain> <- one of the weirdest diff I have so far
22:37:59  <TrueBrain> in the load/save/loaded game, some vehicles no longer exist after 256 ticks :P
22:38:27  <glx> effects ?
22:38:46  <TrueBrain> it says roadveh
22:38:51  <TrueBrain> I haven't verified any of it btw
22:39:34  <TrueBrain> owh, it is not the vehicles that are not there, just the path that is different
22:40:44  <TrueBrain> path-finder cache
22:41:07  <TrueBrain> so the state is not different enough to say boom, but is getting close to that point, I would guess :P
22:41:53  <TrueBrain> given by the other diffs, if I would have to guess, something around the roadveh pathfinder cache is not completely okiedokie
22:43:04  <frosch123> aw, replace only shows the new value, not the old one
22:43:37  <TrueBrain> "": [], "path.tile": [] vs  "": [1], "path.tile": [32208] for vehicle 3011 :)
22:43:56  <frosch123> well, "frame" is different, so the rv already drove differently
22:44:36  <frosch123> oh, motion_counter is different
22:44:41  <TrueBrain> yeah, seems 2477 did something different for sure
22:44:45  <frosch123> that's incremented everytime the vehicle moves
22:44:45  <glx> any crossed junction will change path cache
22:44:59  <glx> s/will/may/
22:45:03  <TrueBrain> glx: these are 2 savegames that are suppose to be identical from start :)
22:45:17  <TrueBrain> only difference is afterload yes/no :P
22:46:06  <TrueBrain> it is funny, most of these games are different but in multiplayer won't have desync'd yet :)
22:46:45  <_dp_> yeah, it takes quite some time to desync sometimes
22:47:30  <TrueBrain> in good news, what-ever this is, it is deterministic :)
22:48:30  <_dp_> I've see vehicle go across the map desynced and only fail when it started loading/unloading
22:49:54  <TrueBrain> okay, all real diffs I have so far have at least 1 roadveh with a now-empty
22:51:34  <TrueBrain> still running, but so fart only 11 out of the 450 games it did :P
22:51:52  <frosch123> coop is not known for rv :p
22:52:01  <TrueBrain> they had a few games, but indeed
22:52:07  <TrueBrain> owh, and a diff on aricraft cargo age
22:52:11  <TrueBrain> that is also interesting :)
22:53:40  <TrueBrain> but okay, before really investigating, I first need to validate that the savegames are what I think they are :)
23:00:22  <TrueBrain> lol, it even happens on a TTDp savegame :P
23:01:11  <TrueBrain> cool, 1.9 titlegame fails too :D
23:01:36  <TrueBrain> 18 failures in ~500 savegames
23:01:49  <TrueBrain> so in general our afterload stuff seems rather solid :)
23:01:59  *** WormnestAndroid has quit IRC
23:02:12  *** WormnestAndroid has joined #openttd
23:02:38  <glx> when done correctly
23:02:55  <glx> I think there was a case of broken conversion
23:03:04  <TrueBrain> multiple :P
23:03:21  <TrueBrain> but I am surprised it still works .. I wouldn't be surprised if loading a 0.4 savegame didn't work, for example
23:03:25  <TrueBrain> as who tries that in 2021 :P
23:04:06  <TrueBrain> okay, I fixed the date issue .. disabled threading for savegames
23:05:23  <TrueBrain> takes btw 1 hour to run this test-suite :)
23:09:09  *** Wolf01 has quit IRC
23:14:09  <frosch123> lol, so null driver actually now does different amount of ticks :)
23:14:43  <TrueBrain> code-wise it shouldn't
23:16:32  <TrueBrain> the other possibility is that "game_start.scr" isn't always doing the same thing
23:18:02  <TrueBrain> lol, I now have a diff where on one of the two games the pause was never removed
23:18:07  <TrueBrain> in the "game_start.scr" is "unpause"
23:18:52  <TrueBrain> (the roadveh issue remains btw, and seems to have nothing to do with this)
23:19:33  <TrueBrain> PM_PAUSED_LINK_GRAPH
23:20:06  <TrueBrain> so it does unpause
23:20:11  <TrueBrain> but one of the two is paused because of linkgraph
23:23:03  <TrueBrain> guess for this kind of testing I should compile completely without threads
23:25:02  *** outtatime has quit IRC
23:25:12  *** outtatime has joined #openttd
23:27:09  <frosch123> night
23:27:11  *** frosch123 has quit IRC
23:29:31  <TrueBrain> okay, linkgraph was indeed the one giving the date differences
23:29:32  <TrueBrain> makes sense
23:29:54  <TrueBrain> I mean, it does indeed indicate one of the two games did a tick more or what-ever :P
23:49:23  *** norri has quit IRC

Powered by YARRSTE version: svn-trunk