Back to Home / #openttd / 2021 / 06 / Prev Day | Next Day
#openttd IRC Logs for 2021-06-12

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