IRC logs for #openttd on OFTC at 2023-08-14
00:22:59 *** sittinbythefire has quit IRC (Quit: User went offline on Discord a while ago)
01:51:28 *** Tirili has joined #openttd
01:55:22 *** Wormnest has quit IRC (Quit: Leaving)
01:59:44 *** Tirili has quit IRC (Quit: Leaving)
02:52:37 *** D-HUND has joined #openttd
02:56:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:10:39 *** D-HUND is now known as debdog
04:02:27 *** keikoz has joined #openttd
05:59:14 <Bouke> truebrain: At least for wentbourne this PR improved CPU quite a bit: All saves with a substantial amount of wagons would benefit from this.
06:03:32 <truebrain> Are you now sticking a feather up your own ass? ๐Ÿ˜„ ๐Ÿ˜› (sorry, couldn't resist ๐Ÿ˜„ )
06:10:32 <truebrain> bit weird ... westbourne memory dropped by 30% on 2023-03-01, where it wasn't the case on 2023-02-26 .. but no commit around that time actually stands out where I am like: yeah, that would explain it
06:12:03 <truebrain> ah, no, the commit it picked up from 2023-02-26 is a bit weird, but okay .. so this is most likely the rework of how linkgraph is stored
06:12:19 <truebrain> `Only store present link graph edges and not all possible edges`
06:12:22 <truebrain> that sounds reasonable
06:12:26 <Bouke> truebrain: Yes ๐Ÿ˜›
06:12:33 <truebrain> yeah, just checking ๐Ÿ˜›
06:13:26 <Bouke> However it doesn't feel nice (the feather that is...)
06:13:39 <truebrain> sounds like a "you" problem
06:13:40 <truebrain> ๐Ÿ˜„
06:14:41 <Bouke> In you strip out assertions, but how does that work for the regular release, assuming that would be a github action?
06:15:26 <truebrain> no, for `release/` branches that is a change made in the actual code
06:15:32 <Bouke> truebrain: If you really want to know, a git bisect would narrow it down.
06:16:35 <truebrain> I am more surprised by how `--before` works in git .. it feels somewhat random whether it includes the day itself or not
06:18:10 <Bouke> truebrain: Like a global search and replace (remove)?
06:18:41 <truebrain> no, just check the `release/` commit history, you will find a commit that changes the assert option from off to on (or the other way around)
06:20:37 <Bouke> Ah yes, found it:
06:24:19 <truebrain> I am trying to understand why my scripting picked a certain hash on a certain date .... and I can't reproduce the result
06:24:19 <truebrain> lol
06:28:48 <truebrain> as if something changed between yesterday and today ... this is so odd
06:30:20 <truebrain> yesterday, the fucking same script, picked `20230226--ma18182e24b` for that date .. today it picks `20230226--m6fcc8727f5`
06:30:25 <truebrain> but the result of yesterday makes NO sense ..
06:32:17 <Bouke> truebrain: Could I use the regular nightly build script for it, or would I need a build without assertions? I guess the nightly suffices, however that means adding assertions are considered a penalty then.
06:33:26 <truebrain> nightlies are build with asserts on
06:33:28 <truebrain> so they are slower
06:33:39 <truebrain> does it matter for relative comparison? No clue
06:34:04 <truebrain> I don't even know if running this on GitHub runners is stable .. or worded differently: how much noise it would introduce
06:34:12 <truebrain> that is for you to find out I guess ๐Ÿ˜„
06:36:39 <truebrain> hmm .... that this `--before` in git now returns different results is very annoying, as that means all the binaries I have been building are now not always the ones it will use on a next run .. which is not what the idea was behind it, ofc ๐Ÿ˜„
06:38:27 *** Wolf01 has joined #openttd
06:43:37 <truebrain> the only thing that makes sense if is the timezone changed on this machine .. which can't be the case .. but that would be the only thing that makes sense
06:47:52 <pickpacket> according to nml I have 6 orphaned sprites. Is there an easy way to find them?
06:48:49 <Bouke> truebrain: Different terminal with different environment variables having a different timezone?
06:50:02 <truebrain> about 10% of the binaries I produced are of the wrong commit in that day .. still in that day, but a lot harder to find back what commit that would make ๐Ÿ˜„
06:50:26 <truebrain> Bouke: not from what I can tell .. freshly installed VM configured on UTC
06:50:53 <truebrain> and I don't mind as much that it might be wrong, but I do mind I have no clue why, so fixing it is hard ๐Ÿ˜›
06:55:12 <truebrain> okay, so one picked the wrong date like 15 minutes ago, in the same shell, re-executing the command, gives me the right one
06:55:18 <truebrain> wth is going on here ๐Ÿ˜„
06:56:09 <peter1138> Does it depend on the current time for some reason...
06:56:41 <truebrain> owh, there you might have something ..
06:56:48 <truebrain> that it takes the date I ask him, and the time of the current clock
06:56:55 <truebrain> would that be the case? That would be a really stupid implementation
06:57:01 <truebrain> but that might just make sense ..
06:57:02 <peter1138> I mean, that would be stupid, but...
06:57:58 <truebrain> how to test that hypothesis ..
07:02:30 *** Extrems has quit IRC (Ping timeout: 480 seconds)
07:08:20 *** Extrems has joined #openttd
07:22:58 <truebrain> no, that doesn't seem to be it .. at least, another day with a commit that passed the current time didn't change in the returning value
07:26:06 <truebrain> okay, I now have one I can actually reproduce (for now at least) on my local machine
07:27:09 <truebrain> `git log --pretty=format:"%C(auto)%h %ci %cn %s" --date=iso --before "2022-10-25"` returns one commit on the 25th (but not the other), where it should return no commits on the 25th
07:28:10 <truebrain> so it does seem to add some arbitrary time .. just not sure which time ๐Ÿ˜›
07:28:38 <truebrain> okay, I can fix it by adding a time too
07:28:41 <truebrain> but that is just weird
07:40:07 <Bouke> What is the author/commit date time of that commit?
07:40:38 *** Flygon has joined #openttd
07:49:44 <truebrain> check for yourself! But clearly some imaginary time is added to the date .. I just can't figure out which ๐Ÿ˜›
07:49:55 <truebrain> but adding 23:59:59 fixes two problems I had, so it is fine now, I think ๐Ÿ™‚
07:50:17 <truebrain> now time to redo the whole shebang, as I wanted to make some configuration changes too ๐Ÿ™‚
07:50:33 <truebrain> the 1.4 titlegame now seems a lot more stable .. let's hope it remains that way ๐Ÿ˜„
07:52:51 <truebrain> okay, also time to add a few more savegames I guess .. let's see, where is my archive ..
07:58:53 <peter1138> Bah, hungry is striking again.
07:59:17 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed pull request #7895: Savegame regression testing
07:59:19 <truebrain> a bit sad that the good openttdcoop games need GRFs that I cannot publish ๐Ÿ˜ฆ
07:59:35 <truebrain> LordAro: nooooooooooo
07:59:46 <LordAro> here it is :p
08:00:02 <LordAro> the progames are vanilla, iirc?
08:00:06 <truebrain> except that doesn't really do anything ๐Ÿ˜›
08:00:12 <truebrain> yeah, progames are good; but there are better ones
08:00:16 <LordAro> not really :p
08:00:28 <truebrain> we really should collect some good savegames in that repo tbh
08:00:56 <LordAro> to the forum!
08:01:58 <truebrain> but by closing that PR, you kinda force someone to add GitHub workflows to every night test if the savegames in that repo still run against the nightly ๐Ÿ˜›
08:02:07 <truebrain> guess that also means we should move it into OpenTTD space ๐Ÿ˜„
08:02:13 <truebrain> your had a holiday right LordAro? ๐Ÿ˜„ ๐Ÿ˜„
08:02:32 <LordAro> nope!
08:02:40 <truebrain> was worth a try ๐Ÿ™‚
08:03:22 <truebrain> I still think it is a good idea to run a set of savegames in predefined intervals .. as one can see, the 1.4 title game failed for over a month ๐Ÿ˜›
08:05:58 <truebrain> owh right, I also once wrote scripting that runs a savegame for N ticks in both master and older builds, create a savegame after those N ticks, and compares those two
08:06:17 <peter1138> Failed to run?
08:06:27 <truebrain> we found bugs because of it!
08:06:47 <truebrain> I just never finished it and pushed it
08:06:50 <truebrain> as with many things ๐Ÿ™‚
08:07:09 <truebrain> it did leave me with an archive of many many different games ๐Ÿ™‚
08:09:19 <truebrain> LordAro: it was the other way around btw .. public games had no NewGRFs .. the pro-games had this whole pack, with GRFs that I still can't recover till this day ๐Ÿ˜›
08:09:35 <truebrain> (and I have the mercurial repo of that pack .. but I am still missing the exact match of a few)
08:11:33 <andythenorth> Ok breakfast time
08:12:14 <truebrain>
08:12:14 <truebrain> on a game without NewGRFs ๐Ÿ˜„
08:13:52 <peter1138> NewGRFs removed at some point?>
08:14:01 <Eddi|zuHause> is that like saying "the fire on the ship probably started with electric cars, because they are so dangerous",,, and then finding that the electric cars were actually least affected by the fire?
08:16:31 <truebrain> LordAro: why do I have a savegame contributed to you named "biggest-town-ever"? ๐Ÿ˜„
08:17:24 <Eddi|zuHause> i think it should be either "contributed by" or "attributed to"
08:35:37 <truebrain> right, added 8 games with random interesting properties .. still without AIs, as that kinda kills performance too much ๐Ÿ˜„
08:35:49 <truebrain> this already takes a good amount of time to do a single version ๐Ÿ˜›
08:36:28 <truebrain> the only thing I didn't have, was an aircraft game, it seems .. I do have trains, ships, and RVs ๐Ÿ™‚
08:38:01 <peter1138> Aircraft are basically free ๐Ÿ˜‰
08:38:30 <peter1138> They are Eddi's ultimate transport... just a simple state machine to follow.
08:39:05 <Eddi|zuHause> sure. i let you believe that :p
08:39:17 <truebrain>
08:39:17 <truebrain> Stats in the most extreme form ๐Ÿ˜›
08:39:36 <truebrain> all those that go up in CPU are title games .. so although 15% sounds like a lot, those games do absolutely nothing ๐Ÿ˜›
08:40:28 <truebrain> biggest-town-ever game increase 3% in memory footprint ๐Ÿ˜›
08:40:53 <truebrain> the only interesting one is a timberwolf game, with a 9% increase in CPU over 2 years
08:41:16 <truebrain> so there seems to be at least some regression in terms of performance ๐Ÿ˜„
08:42:13 <Eddi|zuHause> are you comparing game versions? not very clear from the picture
08:43:19 <peter1138> Game version is the date along the X-axis.
08:44:51 <Eddi|zuHause> yeah. but release? nightly? the graph seems to only compare two versions on either end of the "scale"
08:45:00 <truebrain> okay, I will let this do its thing for a while .. maybe it shows something interesting
08:46:20 <Eddi|zuHause> i was trying to think if i have some interesting save game to contribute, but i think almost all games are with some kind of patchpack
08:46:40 <Eddi|zuHause> or experimental newgrfs
08:47:47 <Eddi|zuHause> like a custom dbsetxl-adapter for firs
08:48:10 <truebrain>
08:48:10 <truebrain> and slowly more data tripples in .. I still like how memory was heavily reduced for most games in the last few months ๐Ÿ˜„
08:48:27 <truebrain> the CPU graph however becomes less and less clear to read .. as that goes ๐Ÿ˜›
08:48:53 <peter1138> Linkgraph changes, right?
08:49:00 <truebrain> yeah, pretty sure linkgraph was a big one
08:49:03 <truebrain> but there are several other ones
08:50:23 <truebrain> and I see I need to improve the crash detection .. that drop in 2023-02 is in fact a crash ๐Ÿ˜›
08:52:05 <truebrain> it takes about 3 minutes per datapoint
08:52:13 <truebrain> it has 500 datapoints to make
08:52:21 <truebrain> ~25 hours
08:52:22 <truebrain> fine
08:52:42 <Eddi|zuHause> ideally you'd store those so you don't have to rerun them to update the graph :p
08:53:15 <peter1138> Urgh, PC hard-locked ๐Ÿ˜ฆ
08:54:07 <Eddi|zuHause> i hate when that happens. usually for me it's "oom doesn't trigger until it's way too late"... or a graphics driver issue
08:55:24 <truebrain> I wonder if I can run multiple simulations at once, or if that would influence the results too much of each other ...
08:56:40 <peter1138> "fatal: your current branch appears to be broken"
08:56:40 <peter1138> Well
08:56:49 <truebrain> useful info ๐Ÿ˜ฆ
08:58:05 <peter1138> git fsck...
08:59:20 <peter1138> So it froze while I was cherry-picking, and now my git repo is corrupted. Hmm.
09:03:57 <LordAro> truebrain: is it the save with the single town covering the whole map?
09:09:03 <truebrain> It is!
09:09:54 <LordAro> that came from the forum iirc
09:13:42 <locosage> what's the map size?
09:19:22 <locosage> I had some performance testings saves somewhere...
09:20:53 <locosage>
09:23:57 <alfagamma_0007> That looks awful
09:24:55 <locosage> it doesn't need to look good xD
09:25:14 <locosage> it was created to test performance of cargo catchment changes
09:26:00 <locosage> also, makes openttd use 1.5Gb of memory xD
09:26:36 <alfagamma_0007> Oof
09:27:00 <alfagamma_0007> The max ottd took I think was 800 megs?
09:27:24 <locosage> oh, 1.1gb actually on fresh run
09:27:33 <locosage> it was over 2gb on older versions
09:27:39 <locosage> stations use a lot of memory
09:27:46 <locosage> even if they do nothing
09:29:03 <alfagamma_0007> Also big maps
09:30:37 <truebrain>
09:30:37 <truebrain> seems the savegames all behave different at different points in time, which is good ๐Ÿ˜„
09:31:10 <alfagamma_0007> How did you benchmark this?
09:31:29 <truebrain> If only there was text in the screenshot explaining it ๐Ÿ™‚
09:32:21 <locosage> truebrain: title games are just cluttering the chart at this point
09:32:59 <peter1138> Hmm, this one doesn't show the same CPU reduction as before...
09:34:14 <truebrain> it does? Depends on what you refer to as "before" ๐Ÿ˜„
09:34:34 <truebrain> it is less clear now, as they move at different points, if you compare it with the one with just 2 points ๐Ÿ™‚
09:35:20 <locosage> truebrain: it's weird that some have a drastic change on a second point, you sure that's not an error?
09:36:38 <truebrain>
09:36:38 <truebrain> I am still unsure what the 1.4 title game is doing .. I disabled autosave and linkgraph recalc, which made it more stable, but something in this game behaves unexpected, but just sometimes. Will be fun to look into ๐Ÿ˜„
09:37:14 <truebrain> (the last dip is because of a bug in OpenTTD; but the other two are not there if I would redo that point in time .. it is the only savegame behaving like this)
09:45:09 <Bouke> Is there a way to generate/modify a savegame/scenario programmatically? Say I'd like to fill one side of the map with a single industry, and wouldn't like spending a long time of clicking 'build industry'.
09:45:30 <truebrain> in theory, you can do that, yes, but it is very very tricky
09:45:43 <truebrain> some objects reference other objects etc
09:45:47 <_jgr_> You can write a gamescript to do it
09:46:04 <truebrain> there are also attempts to make heightmaps contain metadata for these kind of things
09:50:39 <locosage> _jgr_: can just patch the openttd quickly
09:50:46 <locosage> at least, that's how I did minee
10:06:57 <andythenorth> Ok back on my MBP, shall I install MAMP stack so we can move the infra to it?
10:07:18 <truebrain> orrrrr, more useful, I pinged you in one of these PRs, if you can test it out ๐Ÿ™‚
10:10:22 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on issue #11193: [Crash]: nightly crashes after running wentbourne for ~10s
10:10:25 <DorpsGek> [OpenTTD/OpenTTD] Bouke closed issue #11193: [Crash]: nightly crashes after running wentbourne for ~10s
10:10:37 <truebrain> it magically fixed itself? ๐Ÿ˜ฎ
10:12:10 <truebrain> well, we did fix a crash, but if that was the cause of that backtrace, MacOS needs to learn to produce better backtraces ๐Ÿ˜›
10:12:43 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #11193: [Crash]: nightly crashes after running wentbourne for ~10s
10:14:23 <DorpsGek> [OpenTTD/OpenTTD] Bouke updated pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:14:51 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:15:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:15:43 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:17:15 <truebrain> annoying our CI doesn't pick up on it
10:18:29 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:19:21 <Bouke> truebrain: Pick up what?
10:19:30 <truebrain> the build failure you are having
10:19:44 <truebrain> so now it is easy for someone to add another file with the same name .. CI says: everything is fine!
10:19:50 <truebrain> I rather have CIs fail on stuff that goes wrong ๐Ÿ˜›
10:19:55 <truebrain> prevent is better than cure etc etc
10:20:11 <peter1138> Not going to lie, those files having the same name tripped me up a few times when opening the wrong file...
10:20:38 <truebrain> haha ๐Ÿ˜„ So MacOS is just protecting peter1138 sanity .. I can live with that ๐Ÿ˜„
10:20:39 <Bouke> You'd have to actually build through Xcode to catch this issue; the CI build simply uses CMake directly (not going through Xcode).
10:20:53 <truebrain> it uses xcode in the backend ๐Ÿ™‚
10:20:55 <truebrain> just not the GUI part ๐Ÿ˜„
10:20:59 <peter1138> The MSVS issue is why the sound drivers end in _s, music wtih _m and video with _v...
10:21:45 <truebrain> either way, a failing CI on these mistakes would be nice, but it is what it is
10:21:46 <Bouke> It uses the build tools from Xcode. The problematic part here is the Xcode project file, which is only needed when working in the GUI. That part isn't used when building through CMake.
10:22:09 <Bouke> Well we could have a simple script that starts yelling when there are duplicate file names.
10:22:31 <truebrain> we have more scripts that yell when people make a mistake that isn't noticed that easily ๐Ÿ˜›
10:22:34 <truebrain> PRs are welcome ๐Ÿ™‚
10:33:41 *** _aD has joined #openttd
10:53:35 <peter1138> In fact, if you make a PR, we can run it against the current code base, then once #11186 is merged, run it again... to make sure it works.
10:54:27 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11186: Workaround CMake/Xcode duplicate file name issue
10:55:19 <truebrain> Smart
10:57:48 <DorpsGek> [OpenTTD/OpenTTD] Bouke opened pull request #11198: Add: ensure no duplicate filenames
10:59:02 <peter1138> Hehe, it fails the CI itself ๐Ÿ˜„
11:00:24 <_glx_> truebrain: Should be quite easy to check that inside cmake
11:00:39 <_glx_> We use a nice function to add files
11:03:03 <_glx_>
11:03:10 <truebrain> CMake would be preferred, as then you get the issue locally too
11:03:52 <DorpsGek> [OpenTTD/OpenTTD] Bouke updated pull request #11198: Add: ensure no duplicate filenames
11:06:18 <DorpsGek> [OpenTTD/OpenTTD] Bouke updated pull request #11198: Add: ensure no duplicate filenames
11:06:32 <peter1138> Doing it in CMake means you need to test all configurations
11:07:22 <peter1138> So, potentially useful to do both ways.
11:07:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11198: Add: ensure no duplicate filenames
11:07:50 <DorpsGek> [OpenTTD/OpenTTD] Bouke updated pull request #11198: Add: ensure no duplicate filenames
11:08:58 <peter1138> Also, do CI checks have dependencies? So e.g. it could skip actually trying to compile if a prerequisite (duplicate files, bad commit messages...) fails...
11:09:33 <truebrain> it could; but do we really want to? ๐Ÿ™‚
11:09:57 <truebrain> especially bad commit messages, we can fix during squash; some fly-by committers just don't understand git enough to fix that properly ๐Ÿ™‚
11:10:14 <Bouke> Well I know not enough CMake-foo to get that to work.
11:11:29 <DorpsGek> [OpenTTD/OpenTTD] Bouke updated pull request #11198: Add: ensure no duplicate filenames
11:37:18 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11198: Add: ensure no duplicate filenames
11:49:08 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on pull request #11198: Add: ensure no duplicate filenames
12:29:39 <Bouke> It looks like hardware counters are not available inside the (github actions) VM:
12:29:39 <Bouke> 2023-08-14T12:21:29.9142050Z Performance counter stats for 'ls /':
12:29:39 <Bouke> 2023-08-14T12:21:29.9142381Z
12:29:39 <Bouke> 2023-08-14T12:21:29.9143029Z 1.40 msec task-clock # 0.654 CPUs utilized
12:29:39 <Bouke> 2023-08-14T12:21:29.9143794Z 0 context-switches # 0.000 /sec
12:29:40 <Bouke> 2023-08-14T12:21:29.9144530Z 0 cpu-migrations # 0.000 /sec
12:29:40 <Bouke> 2023-08-14T12:21:29.9145652Z 115 page-faults # 82.420 K/sec
12:29:42 <Bouke> 2023-08-14T12:21:29.9146591Z <not supported> cycles
12:29:42 <Bouke> 2023-08-14T12:21:29.9147117Z <not supported> instructions
12:29:44 <Bouke> 2023-08-14T12:21:29.9147715Z <not supported> branches
12:29:44 <Bouke> 2023-08-14T12:21:29.9148487Z <not supported> branch-misses
12:29:46 <Bouke> 2023-08-14T12:21:29.9149231Z <not supported> L1-dcache-loads
12:29:46 <Bouke> 2023-08-14T12:21:29.9149999Z <not supported> L1-dcache-load-misses
12:29:48 <Bouke> 2023-08-14T12:21:29.9150679Z <not supported> LLC-loads
12:29:48 <Bouke> 2023-08-14T12:21:29.9151400Z <not supported> LLC-load-misses
12:29:50 <Bouke> 2023-08-14T12:21:29.9152296Z
12:29:50 <Bouke> 2023-08-14T12:21:29.9152527Z 0.002133719 seconds time elapsed
12:29:52 <Bouke> 2023-08-14T12:21:29.9152859Z
12:29:52 <Bouke> 2023-08-14T12:21:29.9152997Z 0.002251000 seconds user
12:29:54 <Bouke> 2023-08-14T12:21:29.9153426Z 0.000000000 seconds sys
12:41:04 <LordAro> that's a lot of text
12:42:52 <Bouke> Yeah sorry, not used to IRC bridge ๐Ÿ™‚ (I've shortened in discord)
12:52:45 <Bouke> _jgr_: I'd want the savegame to be playable without any dependencies.
12:54:02 <_glx_> you can use <> for text pasting ๐Ÿ™‚
12:58:30 <_jgr_> Bouke: You can remove the script afterwards once its done whatever needs doing. Otherwise you'll need to make a custom build to do it as suggested above
13:05:36 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on issue #11193: [Crash]: nightly crashes after running wentbourne for ~10s
13:22:50 *** nielsm has joined #openttd
13:30:45 <Bouke> OTTD doesn't seem to pick up my GS. I have a file `~/OpenTTD/game/coalcity/info.nut` calling `RegisterGS(CoalCity());`. From the (sparse) docs I suppose that should create a menu item for this GS? It only lists GS I've downloaded.
13:30:52 *** nielsm has quit IRC (Ping timeout: 480 seconds)
13:35:03 <LordAro> ~/OpenTTD ?
13:35:17 <LordAro> that's not one of the locations it looks in
13:35:24 <Bouke> Sorry I meant `~/Documents/OpenTTD`
13:35:49 <Bouke> (in the same OpenTTD root my save games are in)
13:36:52 *** _aD has quit IRC (Ping timeout: 480 seconds)
13:38:12 <Bouke> Right... it requires specific file names. And running with `-d script=1` gives some info. At least my entry is listed now.
13:59:31 <Bouke> Colour me confused. I've installed, but the script is not showing up in the script selection menu.
14:00:44 <Bouke> In order to learn from other gamescripts on bananas, I'd have to download them ingame and then unpack?
14:01:10 *** _aD has joined #openttd
14:12:42 <_glx_> no need to unpack
14:13:00 <_glx_> when you download ingame they are in a tar
14:20:15 <_glx_> but this script might be hidden (depending on some settings)
14:26:55 <_glx_> and it seems the list is not updated when gui.ai_developer_tools changes
14:38:05 *** nielsm has joined #openttd
15:09:19 *** gelignite has joined #openttd
15:11:28 *** _aD has quit IRC (Ping timeout: 480 seconds)
15:40:44 <DorpsGek> [OpenTTD/OpenTTD] Bouke commented on issue #10083: [Bug]: Cheats menu doesn't work by default on macOS
15:50:26 *** Wormnest has joined #openttd
16:04:32 *** _aD has joined #openttd
16:40:50 *** HerzogDeXtEr has joined #openttd
17:18:34 <_glx_> ```1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/core.h
17:18:34 <_glx_> 1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/game_info.cpp
17:18:34 <_glx_> 1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h
17:19:38 <_glx_> paths are just for me to see where
18:35:45 <truebrain>
18:35:45 <truebrain> seems there is another savegame that behaves a bit weird. But otherwise data is getting more and more accurate. The yellow line is when a linkgraph change landed that heavily reduced memory usage. The CPU graph feels "messy", but it really isn't. Just a few savegames that I didn't run for long enough to be accureate. Now I just have to let it gather some more data to see what commit actually
18:35:45 <truebrain> caused a positive or negative change ๐Ÿ™‚
18:37:14 <truebrain>
18:37:14 <truebrain> a bit cleaned up CPU graph, where you can see arond 2021-12 there was a regression, and around 2022-10 there was a good change ๐Ÿ™‚
18:37:25 <truebrain> now I just want to know what caused the regression there ๐Ÿ˜›
18:37:44 <truebrain> (there is also a regression around 2022-07, but it is a bit harder to spot
18:38:26 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:38:27 <DorpsGek> - Update: Translations from eints (by translators)
18:38:40 <peter1138> Does the CPU graph include starting up OpenTTD itself?
18:38:46 <truebrain> yes
18:39:37 <truebrain> that among other things is what makes the smaller runs a lot more noisy
18:45:47 <truebrain> so the increase in CPU from 2021-12, was at 2021-12-16, when the command system was changed to be more template-magic .. I just fail to see how that impacts performance for this kind of performance testing ๐Ÿ˜„
18:45:55 <truebrain> There are no AIs or GSes, so .. no commands?
18:49:26 <michi_cc[d]> Commands are used locally, too, for example CMD_LANDSCAPE_CLEAR can be called from tile loop things as well.
18:49:38 <truebrain> ah .. did not know ๐Ÿ˜„
18:49:52 <truebrain> so yeah, that was a 5% impact on some games
18:50:43 <michi_cc[d]> It not the main use of commands, but stuff like planting fields, (tropical) lumber mill or flooding use commands to get all the proper checks "for free).
18:54:29 <truebrain> the drop around 2022-10 is because of the framerate change for trains
18:56:08 <truebrain> is a ~2% penalty on big-train maps .. I did not expect that, honestly
18:58:20 <truebrain> so let me check if the stats are actually correct ๐Ÿ˜„
18:59:14 <truebrain> yup, it actually is that commit .. very odd
19:05:57 <truebrain> 2 more interesting points in 2023, but I need more data first to pinpoint those .. but that is all the commits with significant CPU impact
19:06:01 <truebrain> I am kinda shocked there are so few ๐Ÿ˜›
19:07:24 <_jgr_> The CMD_ALL_TILES test should be cheaper than the IsValidTile test, so you could perhaps get a small saving by doing them in the other order
19:07:53 <truebrain> that is worth trying
19:08:03 <truebrain> what surprises me more, is that the commit reads as if it only impacts networking games
19:08:11 <truebrain> so I am a bit puzzled how it impacts this performance test ๐Ÿ˜„
19:11:35 <peter1138> "received from a client"... in a single player performance test... Hmm.
19:14:04 <peter1138> Surprising if IsValidTile() is a performance issue, it doesn't do much, except for accessing the map.
19:18:28 <truebrain> yeah, need to confirm it is actually that commit, but everything suggests it is
19:18:28 <truebrain> odd
19:18:40 <pickpacket> The topic still says 13.3
19:21:01 *** glx has joined #openttd
19:21:01 *** ChanServ sets mode: +v glx
19:21:23 <glx> @topic set 1 13.4
19:21:23 *** DorpsGek changes topic to "13.4 | Website: * (source: github, translator: translator, server list: servers, wiki: wiki) | Don't ask to ask, just ask | 'Latest' is not a valid version, 'Most recent' neither | English only"
19:21:37 *** glx has quit IRC ()
19:21:46 <_glx_> fixed ๐Ÿ™‚
19:55:36 <truebrain> michi_cc[d]: would it be difficult to not use the command system for those calls? Just wondering out loud, more than anything
20:07:59 <FLHerne> truebrain: do any of the savegames you're testing use grfs?
20:08:05 <truebrain> yes
20:08:36 <_glx_> ```1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/core.h filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/3rdparty/fmt/core.h
20:08:36 <_glx_> 1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/game_info.cpp filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/game/game_info.cpp
20:08:36 <_glx_> 1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h
20:08:42 <FLHerne> I find by far the biggest perf hit for me is sprite action evaluation for stuff like FIRS industries
20:08:53 <_glx_> the last one is funny ๐Ÿ™‚
20:09:15 <truebrain> I am not measuring what takes time; I am measuring if we have regressions ๐Ÿ™‚
20:09:28 <truebrain> and if so, what we can learn from them, if anything
20:09:37 <FLHerne> truebrain: ok, thanks, just didn't see any in the screenshot Wentbourne + titlescreens
20:09:52 <truebrain> you can see in one of the others what maps are loaded
20:09:53 <FLHerne> truebrain: yeah, but regressions in grf action evaluation would be bad
20:09:54 <truebrain> but there are many ๐Ÿ˜„
20:10:06 <FLHerne> (or gains would be good, like that improvement in sprite caching)
20:10:34 <peter1138> TrueBrain is measuring changes that happened, not potential changes.
20:10:35 <truebrain> regressions in grf handling will be picked up ๐Ÿ™‚ Or should ..
20:13:51 <FLHerne> peter1138: There was a real commit that significantly improved caching of some industry-tile actions, I was just trying to find it
20:13:56 <FLHerne> unless I hallucinated it again
20:14:52 <FLHerne> this definitely exists for vehicles
20:15:43 <FLHerne> yeah, I think this was the one I remembered and I dreamed the bit about industry tiles :p
20:16:08 <peter1138> Okay, so I cna get remote xterm to display, but remote OpenTTD is eluding me ๐Ÿ˜ฆ
20:17:30 <truebrain> FLHerne: that PR is from before my measurements, so it will not show up ๐Ÿ˜ฆ
20:17:39 <truebrain> I took 2 year back as reference, as .. why not ๐Ÿ™‚
20:17:55 <peter1138> Go back to 2004 ๐Ÿ˜„
20:17:59 <FLHerne> oh well
20:18:33 <truebrain> peter1138: no
20:18:34 <truebrain> ๐Ÿ˜›
20:18:55 <FLHerne> I don't think it matters in isolation, was just curious if your testing set picked up that kind of large-effect-on-niche-cases performance change
20:19:10 <truebrain> it should
20:19:14 <truebrain> otherwise we need to add a test case
20:19:40 <truebrain> but I try to keep the savegames realistic user played maps
20:19:48 <truebrain> as that is the important thing to me ๐Ÿ™‚
20:20:01 <truebrain> (and it consumes a lot of time to evaluate a savegame
20:22:13 <peter1138>
20:22:13 <peter1138> Come on SDL, this should work...
20:23:25 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #11198: Add: ensure no duplicate filenames
20:29:36 <truebrain> FLHerne: btw, this means if you have a game that is representing an actual game and has these kind of things, please do let me know ๐Ÿ™‚
20:29:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:30:32 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #11199: Cleanup: [CMake] don't add strgen.h twice
20:31:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #11199: Cleanup: [CMake] don't add strgen.h twice
20:33:11 <truebrain> Bouke: awh, that is sad ๐Ÿ˜ฆ Tnx for checking .. but that is sad. What I can do, is offer my home server as GitHub Runner, so we can still do these performance things, but then it can't be part of the regular CI .. as my home server is not a guarantee ๐Ÿ˜›
20:33:25 <truebrain> and I don't think it is worth the money to run an EC2 instance on AWS for this ๐Ÿ™‚
20:36:02 <truebrain>
20:36:02 <truebrain> my wiki cache technique actually works (and still works) ๐Ÿ˜„
20:36:11 <truebrain> saving money and serving pages faster, w00p!
20:36:17 <peter1138> Etag instead of last modified?
20:36:25 <truebrain> that, and multi-tier caching
20:36:40 <truebrain> so local (at a POP location) cache, if that fails, R2 bucket cache, if that fails, call to AWS
20:36:46 <peter1138> Probably andy's MBP wouldn't struggle with 8GB.
20:37:05 <truebrain> is in 3 days, so a total of ~100GB a month, so yeah .. he should be fine
20:37:52 <truebrain> the rendered wiki so far (what is cached in the R2 bucket) is 350MB in size
20:37:59 <truebrain> people really went apeshit on the wiki ๐Ÿ™‚
20:39:50 <truebrain> talltyler: how is the economy going?
20:40:26 <truebrain> `47,202,030,198 instructions:u # 1.32 insn per cycle ( +- 0.00% )` I am still surprised how stable this method of measuring is .. a difference of 0.00% over 5 runs ..
20:41:10 <_glx_> openttd is very deterministic ๐Ÿ™‚
20:41:10 <talltyler> Done with work for the day, time to see if I have enough brain left to make TimerGameCommon and figure out inheritance in C++
20:41:20 <truebrain> _glx_: except the title game of 1.4 ๐Ÿ˜›
20:41:30 <truebrain> talltyler: good luck ๐Ÿ™‚
20:41:48 <truebrain> _glx_: I pay good money if someone can point to what makes 1.4 so not-deterministic ๐Ÿ˜„
20:42:36 <talltyler> Thanks ๐Ÿ™‚
20:43:11 <_glx_> yeah this 1.4 save has to be very special
20:43:26 <truebrain> I found another savegame that shows similar issues .. so I will compare their settings soon
20:43:29 <truebrain> but it is odd
20:43:38 <truebrain> disabling autosave helped
20:43:41 <truebrain> but still
20:44:56 <peter1138> Cargo dist involved?
20:45:12 <truebrain> I don't know cargodist enough, but the settings in 1.4 were off
20:45:19 <_glx_> AI ?
20:45:21 <truebrain> but I might have been looking wrong there
20:45:24 <truebrain> AIs and GSs are not loaded
20:45:52 <talltyler> Off to a good start by hanging Visual Studio entirely just adding a file ๐Ÿ˜ฒ
20:46:00 <truebrain> ๐Ÿ˜ฎ
20:46:10 <_glx_> well it's a title game, it should not have AI or GS
20:46:26 <_glx_> ah yes it hanged at me on start
20:46:47 <_glx_> updating status for version control
20:47:13 <Eddi|zuHause> wasn't there a rule that the title game submissions can have AI, because they will be purged anyway?
20:47:32 <_glx_> it seems each new VS version is worse than the previous one
20:47:50 <Eddi|zuHause> that's true about many things
20:47:52 <talltyler> Good thing I only need to add two files, it hung again for the second!
20:48:44 <_glx_> and I uninstalled then reinstalled it to get rid of annoying errors at startup
20:49:07 <talltyler> I didn't upgrade from VS2019 properly so I can't run in debug mode anymore, the option is greyed out ๐Ÿ˜ฆ
20:49:20 <talltyler> I have to build and then run from explorer
20:49:25 <_glx_> that's how I learned newer versions (since 17.6) come with there own vcpg
20:50:04 <_glx_> breaking my build setup because it was using its vcpkg and not mine
20:52:58 <_glx_>
20:52:58 <_glx_> good job QA ๐Ÿ™‚
20:54:01 <truebrain> lol, I thought you composed an image
20:54:06 <truebrain> but .. yeah .. good job QA ๐Ÿ˜›
20:54:11 <_glx_>
20:54:30 <_glx_> it depends on which tab you visited before this one ๐Ÿ™‚
20:54:48 <_glx_> somebody forgot a widget in background
20:56:39 *** gelignite has quit IRC (Quit: Stay safe!)
20:57:50 <truebrain> oof, command_func.h changes is basically a recompile ... ssslllloooowwwwww ๐Ÿ˜„
21:03:12 <talltyler> `a member of type "const uint16_t[]" cannot have an in-class initializer` ๐Ÿค”
21:03:19 <talltyler> Where am I supposed to initialize it?
21:04:04 <talltyler> (trying to move this crap into the class definition in the common header file)
21:05:23 <peter1138> static inline
21:05:39 <talltyler> Ah, constexpr seems to work too
21:05:42 <peter1138> (perhaps)_
21:05:54 <talltyler> (according to stackoverflow and the lack of error now ๐Ÿ™‚ )
21:05:58 <truebrain> class members that a "const" should be "constexpr" ๐Ÿ™‚
21:06:20 <truebrain> it has its reasons, but .. yeah, constexpr to the rescue ๐Ÿ™‚
21:08:19 <talltyler> What would the naming pattern be for `_month_date_from_year_day[]` once it's inside a class? Keep it the same, or change it?
21:08:39 <truebrain> I think it doesn't have to be part of the class
21:08:44 <truebrain> I think you can just define it static at top
21:08:53 <truebrain> but that whole array is just ... old
21:08:57 <truebrain> but you have been through that before ๐Ÿ˜„
21:09:18 <talltyler> It was outside the class, but then it won't be inherited, right?
21:09:45 <truebrain> okay, I looked into It indeed causes the slowdown. But, in master it no longer makes any difference. So a problem that got resolved over time ๐Ÿ™‚
21:09:50 <talltyler> I guess that could still work, but it sounds...ugly
21:11:15 <talltyler> The array is only used within the same file, but the function that uses it gets inherited by two subclasses, so they would reference the parent static array
21:11:26 <truebrain> which is totally fine
21:11:34 <talltyler> If you say so ๐Ÿ™‚
21:15:06 <peter1138> You don't need to go all-or-nothing with OO.
21:15:15 <peter1138> C++ is not C# ๐Ÿ™‚
21:16:20 <talltyler> C# is the only other OO language I know ๐Ÿ™‚
21:20:45 <LordAro> truebrain: could the nondeterminism be cpu cache based?
21:21:04 <truebrain> in theory, yes, but none of the other savegames show that behaviour
21:21:10 <truebrain> I would also not expect it to be that much of a difference
21:21:24 <truebrain> I will just have to run a few calgrind profiles, and compare them
21:21:25 <LordAro> maybe it's right at some sort of boundary
21:21:30 <truebrain> it is possible
21:21:59 <_glx_> I decided to be nice and report the options visual artifacts to microsoft ๐Ÿ™‚
21:22:11 <truebrain> nice ๐Ÿ˜„
21:22:15 <_glx_> will see if it takes a year to fix it ๐Ÿ™‚
21:22:19 <truebrain> also applied for a position as QA? ๐Ÿ˜„
21:24:43 <_glx_> <> the report also includes a repro video, but it's private
21:25:06 <truebrain> it is such a stupid bug, as you know someone was just being lazy
21:25:48 <_glx_> yeah it's most likely a missing panel under the groups
21:26:12 <truebrain> you just know if you can touch their code you can fix it in minutes ๐Ÿ˜›
21:27:01 <truebrain> meh; we made too many changes in the last few months .. 1 day can have like 10 commits .. hard to find out which commit caused a performance gain ๐Ÿ˜„
21:27:51 <_glx_> all the std::string changes ๐Ÿ™‚
21:27:57 <truebrain> those too
21:28:19 <_glx_> nice rabbit hole commits ๐Ÿ˜‰
21:29:02 <truebrain> I am still surprised by that add-tile-check-in-command-system commit .. why it has an impact, and why it no longer has any ๐Ÿ˜›
21:29:07 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #11199: Cleanup: [CMake] don't add strgen.h twice
21:33:40 <talltyler> truebrain: All the timer handlers are not currently part of the class, can/should they be moved inside so they can be inherited, or stay outside and get duplicated? (::Elapsed is different for each, so it would get overridden)
21:33:40 <talltyler>
21:34:10 <truebrain> I am sure you want to make them different for economy over time ๐Ÿ™‚
21:34:39 <truebrain> but that is not an actual question I can answer without doing the work ๐Ÿ™‚
21:42:24 <talltyler> Fair enough ๐Ÿ™‚
21:43:42 <Bouke> truebrain: Not having it on a PR is a pity, as immediate feedback is better than a daily aggregate.
21:44:18 <truebrain> we do have to be careful that it doesn't become: THOU SHALL NOT DECREASE PERFORMANCE ๐Ÿ˜›
21:48:08 <Bouke> Easy enough to blame it on variance ๐Ÿ˜‰
21:50:23 <truebrain> and .... another recompile. lol
21:53:00 <Bouke> Bouke: Or have it on the PR anyway, and ๐Ÿคท๐Ÿผโ€โ™‚๏ธ when your server is unavailable. We could even have Andyโ€™s MBP as fallback.
21:56:43 <truebrain> I really do not understand what causes the performance drop with .. InternalPost is called once, and PostFromNet zero times .. lolz .. I must be missing something here ๐Ÿ™‚
21:59:52 <_jgr_> It could be due to InternalExecutePrepTest not rejecting things which it previously did?
22:00:06 <_jgr_> Which then go on to consume cycles
22:00:07 <truebrain> oeh, good questions; let's test
22:00:30 *** keikoz has quit IRC (Read error: No route to host)
22:02:26 *** keikoz has joined #openttd
22:05:10 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
22:06:28 <talltyler> truebrain: No rush, but I pushed a commit splitting the timers for you to look at. I get a "no instance of constructor matching the argument list" error everywhere I try to create a new timer...and I can't even find the constructor! ๐Ÿ˜„
22:06:45 <talltyler> No rush, but maybe you can point me to what I'm missing... ๐Ÿ™‚
22:06:47 *** keikoz has quit IRC ()
22:06:56 <talltyler> It's time to make dinner so I'm taking a break anyway
22:07:52 <truebrain> I think you also moved too much ๐Ÿ™‚ You need to remember that in the end you want Economy to come in two forms, with slightly different behaviour
22:08:01 <truebrain> so some duplication is to be expected
22:08:06 <truebrain> but that is easy to say from a distance, so *shrug*
22:09:03 <truebrain> anyway, way to tired to actually process what you did in a useful way ๐Ÿ˜› So maybe someone else can help you out here ๐Ÿ™‚
22:12:02 <talltyler> Ah moving `struct TPeriod` back into the child classes seemed to fix it ๐Ÿ™‚
22:19:24 <truebrain> _jgr_: I liked the idea, but that function is also only called once .. I must be doing something else wrong here ๐Ÿ˜›
22:32:49 <truebrain> small changes take ~10 minutes before it is compiled again .. LTO is killing me ๐Ÿ˜„
22:36:20 <talltyler> Ah heck, I got it to compile, then rebased, and now I have 316 unresolved external symbols... ๐Ÿ˜ฌ
22:36:39 <truebrain> you forgot your cmakelists.txt changes? ๐Ÿ™‚
22:43:38 <truebrain> this commit ..... for sure it is the change in InternalPost, but it is called once, and it passes ...
22:43:52 <truebrain> I can't find a normal explanation ๐Ÿ˜›
22:49:21 <truebrain> the `tile >= MapSize() || ` is btw cute; `IsValidTile` also does that ๐Ÿ˜›
22:51:58 <_jgr_> tile >= MapSize() still needs to be checked even for the CMD_ALL_TILES case
22:52:12 <truebrain> yeah, so reordering the if-statement would be more efficient
22:52:19 <truebrain> but still, from what I can tell it is called once .. so ...
22:52:25 <truebrain> why is it having such trouble with it?
22:54:05 <truebrain> it could be some weird command that is prevented by this check, but it doesn't even return ๐Ÿ˜›
22:59:03 <truebrain> if I make the if-statement a bit smaller, it doesn't slow down as much .. lol
22:59:24 <_jgr_> Is it all the saves that see a change on that commit or just some of them?
22:59:32 <truebrain> just some of them
23:00:01 <truebrain> they are the ones that run relatively shorter, so it might be some savegame loading overhead
23:00:09 <truebrain> but still, I wouldn't expect that if-statement to influence it ๐Ÿ˜›
23:01:36 <truebrain> also weird that in master this behaviour doesn't exist, but I don't see anywhere where the performance is regained .. and as it is pretty visible, I would have expected that
23:01:55 <truebrain> although ofc it could be during another change
23:02:07 <truebrain> just weird ๐Ÿ˜› I don't like weird ๐Ÿ˜„
23:03:01 <truebrain> I can understand if that if-statement makes the function too big so compilers don't inline it or something .. but that would require more than one call ๐Ÿ˜›
23:09:18 <truebrain> if I force-inline it, I get my performance back
23:09:19 <truebrain> lol
23:09:29 <truebrain> so that if-statement pushed it over the threshold of this compiler I am using
23:09:31 <truebrain> FML ๐Ÿ˜›
23:10:24 <truebrain> let's see what it does on master
23:10:37 *** debdog has quit IRC (Ping timeout: 480 seconds)
23:13:50 <talltyler> truebrain: Nope ๐Ÿ˜ฆ
23:14:18 <talltyler> Trying to compare before and after the rebase but my git skills aren't quite good enough
23:14:54 <truebrain> ๐Ÿ˜ฆ
23:19:52 <truebrain> force inlining it in master doesn't make a real difference. Owh well, I guess at least that somewhat explains it ๐Ÿ˜›
23:19:59 <truebrain> super weird
23:20:11 <talltyler> Somehow git diff keeps showing me code from...master?
23:20:24 <talltyler> Even when I give it commit hashes from reflog
23:21:51 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
23:22:27 <talltyler> Maybe it's easier to see what I missed when I can view commits online
23:22:38 *** debdog has joined #openttd
23:24:44 <truebrain> ah, I didn't actually disable linkgraph as I hoped; the settings can't be large enough to make that happen
23:26:13 <talltyler> Aha, that might be it
23:26:26 <truebrain> all 4 distribution modes are on manual
23:26:31 <truebrain> guess that means linkgraph is also not doing anything?
23:27:41 <truebrain> why is Autosave both in settings and in game options? Weird
23:31:30 <_glx_> talltyler: maybe you should try "github desktop"
23:34:35 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:35:35 <_jgr_> truebrain: The settings for these are stored in the savegame, so changing it in the config won't have any effect
23:36:00 <truebrain> did not know!
23:36:04 <_jgr_> If the savegame had any pending jobs they'll be started straight away on load as well
23:36:19 <truebrain> but when everything is on manual, they don't restart, right?
23:36:48 <truebrain> tomorrow I will check if any jobs are pending in that savegame .. would explain a thing or two ๐Ÿ™‚
23:37:20 <_jgr_> If it's manual it shouldn't start any jobs
23:37:57 <truebrain> Tnx!
23:38:05 <truebrain> Now: zzz time ๐Ÿ™‚
23:38:24 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
23:39:12 *** _aD has quit IRC (Ping timeout: 480 seconds)
23:45:39 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
23:45:44 <talltyler> Okay, fixed it! That's enough for today. ๐Ÿ™‚
23:51:05 *** tokai has joined #openttd
23:51:05 *** ChanServ sets mode: +v tokai
23:57:52 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:58:04 <_jgr_> truebrain: Actually, looking at the code, it seems the jobs are run anyway, they just don't have as much work to do