IRC logs for #openttd on OFTC at 2024-04-11
⏴ go to previous day
00:01:53 <_glx_> the non OTTD2FS works for me, but my paths are ascii compatible
00:03:11 *** tokai|noir has joined #openttd
00:03:11 *** ChanServ sets mode: +v tokai|noir
00:07:05 *** tokai has quit IRC (Ping timeout: 480 seconds)
00:21:41 <peter1138> std::filesystem::path should take care of that, when filename is std::u8string or char8_t. Which it's not.
00:23:30 <peter1138> Wonder if that is still relevant...
00:23:55 <_glx_> that's what I was about to check, but I'm updating my mingw
00:27:41 <peter1138> u8path exists in C++17, but is deprecated for C++20, so that's not ideal.
00:29:39 <_glx_> probably better to keep utf8 in std::string and OTTD2FS
00:30:24 <_glx_> as std::wstring should be fine then
00:30:43 <_glx_> (well except maybe for mingw, but it's still updating)
00:31:31 <_glx_> checking available diskspace is slow
00:32:10 <_glx_> and I have 12GB free on the drive where mingw is
00:36:30 <peter1138> If you think it's worth caring about 😉
00:36:56 <_glx_> we have a nightly CI run testing mingw
00:50:36 <peter1138> I reckon there's more to go.
00:54:31 <peter1138> > Windows 10 added support for UTF-8 in its narrow-string API, which can be enabled through a manifest.
00:54:41 <peter1138> Drop support for pre-Windows 10 when? 😄
02:43:54 *** gnu_jj_ has joined #openttd
02:47:00 *** Wormnest has quit IRC (Quit: Leaving)
02:47:27 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:53:00 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:30:57 *** keikoz has quit IRC (Ping timeout: 480 seconds)
04:42:04 <DorpsGek> - Update: Translations from eints (by translators)
05:59:20 *** keoz has quit IRC (Ping timeout: 480 seconds)
06:05:50 <kuhnovic> truebrain: I can still do that 😉
06:13:56 <truebrain> kuhnovic: Please do 🙂
06:34:41 <truebrain> owh great, Microsoft/Google found a new way to annoy me .. I no longer receive notification when I get a message when I run Teams in Chrome. Only when I click the tab, it updates. That is just briliant. So useful, etc.
06:37:00 <dwfreed> keep the tab in its own window?
06:37:16 <dwfreed> oh, then that's fucked
06:37:23 <truebrain> and this worked-ish last week .. but this week it is like: nah, you talked with too many people already, enough is enough
06:37:32 <truebrain> as that is what chat applications do .. not allow you to connect to other people
07:09:41 *** HerzogDeXtEr has joined #openttd
07:46:24 *** georgevb has joined #openttd
07:46:24 <georgevb> A question about stations
07:46:24 <georgevb> Is it possible to get the class of the nearby station?
07:46:26 <georgevb> I want the high platform station to have a fence if nearby tile is not a high platform, but I can't find a way to do it.
07:46:26 <georgevb> I can't check for section, because nearby tile can be other time of high platform, and there should be no fence
07:53:57 <_glx_> Should be doable with `PLATFORM_SAME_STATION`
07:54:28 <_glx_> You can check nearby tile is a station, then the class
07:54:50 <georgevb> How can I check the class?
07:57:34 <_glx_> Oh the class is only for the window, it's not available to grf
07:58:20 <georgevb> Could someone add it? Would it be hard?
08:00:14 <_glx_> But you can test same_grf and station_id
08:00:29 <georgevb> And how would it help?
08:01:43 <georgevb> station_id is station name?
08:01:51 <andythenorth> it's all one grf?
08:02:15 <andythenorth> yeah, just check IDs
08:02:45 <_glx_> You can check grfid and id
08:02:56 <georgevb> I need to look all the IDd in the class?
08:03:29 <andythenorth> I would be using nearby_tile_station_id or so
08:03:35 <andythenorth> and yes, check all IDs
08:03:50 <georgevb> I see. Thank you, I'll try
08:04:06 <_glx_> Class are shared between all grr
08:04:32 <andythenorth> if you have a templater, it's just a loop
08:05:14 <_glx_> And you can't assume a the class of a given time is from yours
08:12:51 <peter1138> Well he could start all classes with 4D656FXX and then claim they're reserved 🙂
08:22:59 <georgevb> In case checking IDs helps that would not be necessary 😉
08:35:24 <andythenorth> peter1138: they are reserved no?
08:35:34 <andythenorth> I reserved them in a page somewhere
08:50:05 <_glx_> Just put everything in DFLT
09:02:32 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
10:09:38 *** keikoz has quit IRC (Ping timeout: 480 seconds)
10:33:57 *** tokai|noir has quit IRC (Quit: c('~' )o)
10:49:26 *** keoz has quit IRC (Ping timeout: 480 seconds)
11:22:48 *** keikoz has quit IRC (Ping timeout: 480 seconds)
11:25:05 *** asymptotically2 has quit IRC (Remote host closed the connection)
11:25:09 *** asymptotically2 has joined #openttd
11:26:22 *** asymptotically2 has quit IRC (Remote host closed the connection)
11:28:03 *** asymptotically2 has joined #openttd
12:23:18 <peter1138> > 37 files changed, 220 insertions(+), 340 deletions(-)
12:23:37 <peter1138> I did a refactor that is actually smaller.
12:23:47 <peter1138> Normally I do a deduplication that ends up larger :p
12:43:13 *** keoz has quit IRC (Ping timeout: 480 seconds)
12:48:12 *** Xaroth92328 has joined #openttd
12:48:35 <truebrain> okay ... now I finally have some numbers from the performance benching on GitHub Runners, I can validate if we can actually correlate the numbers
12:48:45 <truebrain> and it seems, within a margin of like 1 or 2 %, we actually can
12:48:47 <truebrain> so that is something
12:51:13 <LordAro> genericise it and call it TrueBench ?
12:52:54 <truebrain> no tnx 😄 This is painful enough 😛
12:54:01 <truebrain> peter1138: "bigger refactor" as something that will remain somewhere in your stash, or something that will actually become a PR? 😄
12:54:22 <peter1138> It can become a PR, but it touches 37 files 🙂
12:54:25 <truebrain> and I know our FioF usage is a total mess 😛
12:54:47 <peter1138> But #12479 is easily backportable instead 🙂
12:54:56 <truebrain> which is appreciated 🙂
12:55:23 *** Xaroth9232 has quit IRC (Ping timeout: 480 seconds)
13:02:28 <peter1138> Want me to fix all the others that use fclose?
13:02:49 <truebrain> I assume that is part of your bigger refactor 😛 😛
13:03:15 <truebrain> I checked a few fclose; at least a subset of them are actually opened by fopen 😛
13:03:41 <truebrain> (read: the 10-ish I checked)
13:04:07 <truebrain> but it is just really weird ... you use FioF functions to open/close, but fread/fwrite to read/write from them
13:04:10 <truebrain> like .. make up your mind
13:04:16 <truebrain> what parts do we wrap, and what parts don't we wrap
13:05:12 <peter1138> FioFOpenFile is now basically to handle the file path system, along with positioning to the correct place in a Tar file.
13:06:07 <truebrain> the ones I like the most, are these: `FioCheckFileExists` and `FileExists`
13:07:36 <truebrain> owh, `FileCloser` exists .. did not know about that
13:07:39 <peter1138> Yeah, one is basic and one checks inside a path.
13:07:45 <peter1138> FileCloser exists... for now 😉
13:08:32 <truebrain> right .. back to checking out if these numbers correlate sufficiently to publish
13:08:54 <peter1138> The refactor is based on the alternative, FileDeleter.
13:09:52 <peter1138> Although a proper refactor is perhaps std::ifstream/std::ofstream,
13:10:24 <truebrain> I tried touching FioF a few times
13:10:26 <truebrain> I always regretted it
13:10:33 <truebrain> so many things depend on such weird nuances in that code
13:11:33 <LordAro> there's a decent argument that fstreams should be avoided as well
13:11:48 <LordAro> a basic RAII FILE* wrapper is probably sufficient
13:13:25 <peter1138> Okay. That's basically what my refactor is.
13:14:47 <LordAro> oh yes, i didn't read anything except the std::* line :p
13:15:45 <peter1138> Why should fstreams be avoided?
13:17:44 <_jgr_> The I/O stream API (shift operator overloading, etc) is just terrible in general, full of footguns
13:18:10 <LordAro> i've seen it cause compilation issues on a few platforms too
13:18:23 <LordAro> can't remember why, but i had to remove the fstreams include for some reason
13:18:41 <peter1138> You were probably using a compiler from 1997.
13:18:55 <truebrain> or Ada. Or Perl. 😛 😛
13:19:01 <truebrain> (sorry, this was just too easy 😄 )
13:19:11 <LordAro> gcc 12ish, some sort of interaction with llvm/clang headers
13:20:53 <ahyangyi> iostream has a bad reputation in general. I do hear it's more or less appropriate for logging though. (`glog` also uses the stream-style API)
13:25:52 <_jgr_> Logging works just fine with normal IO APIs
13:26:00 <truebrain> lol, the performance suite suggests we had a regression on the 7th this month, which for a few games meant a 3% CPU increase which got corrected the day after 😛
13:26:06 <truebrain> I don't even want to know if that is true 🙂
13:26:10 <truebrain> but correlations are fun to spot 🙂
13:27:48 <truebrain> and also, some savegames are just weird. They behave very ... well, yes, weird
13:27:59 <xarick> is it possible for AIs to know
13:28:35 <peter1138> Which version do you use for each day?
13:28:51 <peter1138> Previously I assumed the nightly, but then that got changed to a different time...
13:29:03 <truebrain> I use the last commit of the day, in UTC
13:29:11 <truebrain> so it isn't a nightly
13:29:22 <truebrain> well, it might, or might not be 😛
13:29:36 <peter1138> Sure, unrelated to it 🙂
13:29:57 <truebrain> what I do every benchmark, is download the 12.0 stable from our CDN, and compile the same code. And I compare these results, to see the stability of the benchmark
13:30:20 <truebrain> so for this one savegame, on day X it is 5500 / 5650. On day X + 1 it is 6500 / 6100
13:30:21 <peter1138> I don't see anything that would account for a regression and deregression.
13:30:23 <truebrain> that makes zero sense at all 😛
13:30:52 <truebrain> so clearly there are some measurement issues from time to time, that my scripting does not pick up
13:30:54 <peter1138> Bug with the SDL drivers, but you won't be testing SDL, I assume.
13:31:29 <Eddi|zuHause> are we sure we're not testing jitter in the test system?
13:32:50 <truebrain> peter1138: bit odd. I see the 7th an increase of 3% on most title games, and a decrase of 3% the day after. They correlate too much to be incidental.
13:33:22 <truebrain> Eddi|zuHause: who knows! That is why I correlate information, and use multiple systems over multiple savegames 🙂
13:36:06 <truebrain> it remains funny to me, I expected OpenTTD to be more deterministic in terms of CPU time spend. But a computer is too complex to expect that 😄
13:39:51 <truebrain> right, okay, let's not focus on a small difference. Let's first see what the bigger picture is showing 🙂
13:50:54 <xarick> isn't that because the simulation speed is now faster?
13:58:45 <_glx_> Should not affect only one day
14:09:25 *** keikoz has quit IRC (Remote host closed the connection)
14:19:38 *** keikoz has quit IRC (Remote host closed the connection)
14:49:20 <peter1138> Hmm, what does 12.2 look like these days...
14:49:24 *** APTX has quit IRC (Quit: Farewell)
14:49:48 <peter1138> Ah yes... terrible.
14:50:21 <truebrain> you just needed to remind yourself of that? 😄
14:50:24 <truebrain> feel the progress? 😛
14:51:14 <truebrain> to all their opinion, ofc 🙂
14:57:31 *** matusguy has joined #openttd
14:58:16 <talltyler> Liking the old finance GUI is such a strange hill to die on. I am biased but it was awful before I redid it.
14:58:44 <truebrain> if there is one thing I learnt from OpenTTD ... there is someone that always like that one thing that got changed 🙂
14:58:47 <truebrain> no matter how big or small ..
14:59:38 <peter1138> But also, isn't the old finance layout toggleable?
15:00:16 <peter1138> I mean toggleable between old & new.
15:00:22 <peter1138> But looks like it is not.
15:00:32 <talltyler> The functionality I removed was the ungrouped layout
15:00:41 <talltyler> The miniature version still exists
15:00:48 <peter1138> Yeah I didn't meant that toggle.
15:01:34 <peter1138> We only remove features 🙂
15:01:34 <talltyler> That’s the nice thing about having old versions available, people can choose the version they like best 🙂
15:16:05 <LordAro> "I am using windows 7"
15:16:09 <peter1138> It does really look terrible though. How did we ship that?! 😄
15:20:21 <truebrain> I am trying different visualizations to show better what correlates in regards to performance
15:20:41 <truebrain> the long boxes are because I don't have data, but you can see here that at the end of april we did something that caused a lot of them to go PANIC
15:21:03 <truebrain> (this is with taking 2024-01-01 build as "normal")
15:21:22 <truebrain> green is improvement, red is regression
15:21:58 <truebrain> the big red bar at the bottom is at the day the region-based ship PF got merged, in case you were wondering 🙂
15:23:22 <peter1138> Hmm, so we did a bad?
15:23:43 <truebrain> need to validate if this data is actually correct
15:25:01 <peter1138> Is it 500ms of xz backdoor?
15:29:45 <truebrain> so at 2024-01-09, opntitle.sav was running at 86% of 12.0 (which is good). Currently it is at 100% (which means it regressed)
15:30:00 <truebrain> but the visualisation is misleading into when that happened
15:30:25 <xarick> can you check if there are ships in those saves? exclude saves without ships
15:31:37 <xarick> just wondering if there's a correlation with the ship pf
15:32:36 <xarick> remember that even with NPF, the nearest ship depot still runs WaterRegion code
15:32:48 <truebrain> ah, the sorting in time is wrong
15:35:36 <truebrain> now it is matching the raw data, as of the moment it happened
15:35:44 <truebrain> so somwhere before 2024-04-01 🙂
15:36:33 <truebrain> you now also clearly see the games that were crashing this week 😛
15:42:36 <truebrain> all the data I have currently. Still need to validate if I measured the same with my old way of measuring 🙂
15:44:25 <truebrain> memory consumption 🙂 I am pretty sure this one is correct 😉
15:45:25 <truebrain> the difference is huge btw 😄 But we already knew that 😉
15:47:39 <truebrain> here, with [110, 40] (110 = red, 40 = green)
15:47:44 <truebrain> the numbers are in percentages against 12.0
15:47:52 <truebrain> so 100% is the same memory usage as 12.0 had
15:48:18 <truebrain> and memory measurements are pretty accurate, so that is a relatively easy picture
15:48:21 <truebrain> CPU is much harder 😄
15:51:50 <truebrain> main problem with these kind of visualisation, what is "zero" .. always using the 12.0 stable is not ideal, as that doesn't show changes on a smaller scale all that well
15:56:02 <peter1138> Maybe my news std::list change killed things (even once fixed)
15:56:18 <truebrain> I will need to run more benchmarks to find out where abouts this happened
15:57:53 <truebrain> but at least the method of benchmarking seems to work. Now I just need to find a good way to visualise it 🙂
15:59:43 <truebrain> this graph compares the build of that date with the build of the day before. But very quickly you see here that the noise is higher than the actual result. Bracket here is [110, 90]
16:00:35 <Eddi|zuHause> truebrain: like the railways, a cancelled train doesn't count as late :p
16:01:01 <peter1138> The industry cargo accepted/produced change (array to vector) happened recently too.
16:01:28 <truebrain> I started some builds between 2024-01 and 2024-04 .. gives a more detailed insight in where abouts it was 🙂
16:01:40 <truebrain> in the end, this will give the exact date it was introduced, but getting there takes a bit of time 😛
16:01:54 <truebrain> (takes about 50 minutes to run a single day)
16:03:26 <peter1138> Apparently it's 20°C, does not feel that warm.
16:13:07 <LordAro> feeling decidedly 18C here
16:50:15 <kuhnovic> So the ship pathfinder made things slow? It was meant to speed things up 😛
16:54:48 *** alfagamma7 has joined #openttd
16:54:48 <alfagamma7> Would be great if OTTD could simulate depth of water
16:54:58 <kuhnovic> Actually it was more about making longs paths possible, it didn't do much for existing paths with buoys
17:42:39 <LordAro> might be tricky to merge water levels and water regions
17:42:47 <LordAro> without making the pathfinding super wonky
17:59:39 <truebrain> more data and more tweaking to the representation
17:59:57 <truebrain> 2024-01-01 is 100%; rest is reletive to that
18:00:34 <truebrain> moar data needed! 😄
18:06:52 <alfagamma7> talltyler: Extremely complex
18:07:06 <alfagamma7> Better not needed ( now )
18:12:23 <alfagamma7> LordAro: Moreover it would change how bridges and tunnels can be constructed
18:12:49 <alfagamma7> OpenTTD would then more or less become a civil engineering sim
18:49:50 <Eddi|zuHause> well... bridges need an overhaul anyway :p
18:55:45 <truebrain> different draw library ... not sure it is an improvement 😛 It also doesn't support datetime on the x-axis for heatmaps, for some reason
18:56:00 <truebrain> but it does come with an interactive legend, which is nice
19:40:33 <LordAro> alfagamma7: sure, but from a technical point of view that's not difficult
19:53:26 <truebrain> at least I found the date a few savegames regressed 🙂
19:53:56 <peter1138> Except the chart doesn't show us the date?
19:54:14 <truebrain> 2024-01-24 is the first date 6 of them change colour
19:57:02 <truebrain> euh, typo of mine: 2024-01-14
19:57:06 <_glx_> hmm I have an idea to try to reproduce the crash
19:57:09 <truebrain> I will publish this graph interactively soon (tm) 🙂
19:57:37 <peter1138> Scalable truetype font by default 🙂
19:57:44 <truebrain> ah, yes, I was warned for that
19:57:47 <truebrain> didn't I disable that?
19:58:14 <truebrain> ah, indeed, I forgot to change that, so it follows default
19:58:28 <truebrain> well, that is not a bad thing, as that is also the experience users have 🙂
19:59:32 <truebrain> right, next one is the 18th that same month
20:00:03 <truebrain> I made the 14th the "100%", and the rest is coloured based on that
20:00:11 <truebrain> kinda happy how easy that makes it to spot hotspots
20:05:53 <_glx_> so using google drive doesn't trigger the crash, I'll have to try with dropbox
20:09:23 <truebrain> haha, memory usage of OpenTTD:
20:09:26 <truebrain> that is also the 14th 😄
20:09:44 <truebrain> but we already fixed that 🙂
20:15:39 <_glx_> victory, I can reproduce with dropbox
20:17:06 <_glx_> it's better to be able to test the "broken" version
20:21:14 <_glx_> no crash with the draft
20:21:50 <peter1138> Nice. Does it actually save the settings though? 😄
20:23:34 <_glx_> based on date and time with ls it seems so 🙂
20:34:27 <LordAro> _glx_: write what you needed to do in the issue for historical porpoises?
20:43:54 <peter1138> So that works around it. Not entirely sure how to make WndProcGdi re-entrant.
20:44:48 <truebrain> Just a simple counter? `if (counter > 0) return; counter++ ...... counter--` ?
20:44:55 <truebrain> I mean, do we really want to process anything in the second call? 🙂
20:46:47 <peter1138> I think I should leave that to a dev who runs on Windows 🙂
20:47:16 <_glx_> we use a single window, and the other window we may open is crash window and it uses it's own proc
20:47:38 <_glx_> so indeed we are not supposed to be reentrant
20:48:24 <_glx_> the issue here was SHFileOperation() sending messages to our window I think
20:48:40 <_glx_> even if we told it to not to
20:50:25 <_glx_> I could try to confirm the flow with breakpoints
20:51:52 <peter1138> Well we saw the flow in the stack trace 🙂
20:55:07 <_glx_> indeed we first receive a WM_CANCELMODE
20:56:35 <_glx_> hmm then WM_CAPTURECHANGED (but that might be an effect of the breakpoint)
20:59:04 <_glx_> then WM_NCACTIVATE, then WM_ACTIVATE, then WM_ACTIVATEAPP, then WM_KILLFOCUS, ...
20:59:15 <_glx_> I should put debug message, would be cleaner
20:59:28 <_glx_> breakpoints makes it noisy
21:12:33 <_glx_> without breakpoint I just see WM_LBUTTONDOWN then WM_LBUTTONUP
21:22:10 *** SigHunter has joined #openttd
21:26:24 <peter1138> The particular event isn't really the point though.
21:26:33 <peter1138> It could be any event.
21:31:06 <_glx_> yeah I can get button down then move the mouse
21:31:29 <LordAro> docker is irritating me
21:31:58 <LordAro> it's making 4 copies of the 35GB container before finally pushing it
21:32:02 <peter1138> That is Docker's purpose.
21:32:18 <_glx_> but there's no mesages between the mouse down which triggers SHFileOperation and the next message while it's still doing SHFileOperation it seems
21:32:22 <LordAro> i imagine normally that's not a huge issue, but it's a bit of a pain for this one
21:44:37 <peter1138> Yeah, it's rare enough that 20 years of being wrong hasn't really affected much 🙂
21:50:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:55:07 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:03:48 <Eddi|zuHause> that's why you shouldn't trust anyone whose only argument is that they've been doing it for 20 years
22:07:21 *** matusguy has quit IRC (Remote host closed the connection)
22:16:41 <yiffgirl> at the risk of looking like an openttd addict: what's left to do before the release?
22:16:41 <yiffgirl> *and how can i help it get done faster*
22:25:39 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:28:25 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:01:56 <FLHerne> still waiting for the xz drama to shake out upstream, I think
23:11:59 <_glx_> oh xz is no longer an issue 🙂
23:12:53 <_glx_> it's just a matter of backporting what needs to be backported, updating changelog and pressing a button
23:52:37 <reldred> in other words it's done when it's done 🙂
continue to next day ⏵
