IRC logs for #openttd on OFTC at 2023-04-13
⏴ go to previous day
00:31:38 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:36:58 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:38:52 *** WormnestAndroid has joined #openttd
00:51:34 *** Flygon has quit IRC (Read error: Connection reset by peer)
00:59:08 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
01:08:39 *** Wormnest has joined #openttd
01:14:09 *** WormnestAndroid has joined #openttd
01:17:52 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:18:00 *** WormnestAndroid has joined #openttd
01:34:13 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
02:00:53 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:18:39 <TallTyler> Hmm I don’t feel like answering that
02:38:47 *** Wormnest has joined #openttd
02:46:21 *** WormnestAndroid has joined #openttd
02:52:36 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:14:59 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:15:29 *** WormnestAndroid has joined #openttd
03:28:04 *** Wormnest has quit IRC (Quit: Leaving)
04:51:09 *** D-HUND is now known as debdog
05:59:46 <petern> I managed to crash VS Code several times last night due to searching and replacing across all files 🙂
06:00:17 <petern> Although I guess it's probably due to a 3rd party extension.
06:45:07 *** sla_ro|master has joined #openttd
07:05:57 *** HerzogDeXtEr has joined #openttd
07:43:03 <TrueBrain> impressive .. I never had VSCode crash on me 😛
07:45:40 <petern> Ah ha, I also had to restart VSCode for the tests in #10636 to appear.
07:46:07 <petern> But what is "regression_Testing"? It's always been there and never works...
07:46:34 <petern> "regression_regression" is also failing 😄
07:46:51 <petern> Coffee for me, I'm letting my tummy rumble until midday still.
07:49:28 <petern> Hmm, maybe it's a random directory from trying to run it wrong in the past.
07:52:02 <Rubidium_> maybe the "regression_Testing" are the AI API regression tests, as those are discovered in a similar way. Running ctest will run the new unit tests and the AI regression tests
07:54:37 <petern> I have regression_regression and regression_stationlist which are the GS/AI API tests, afaik.
07:56:12 <petern> Okay... Testing has gone now, I had to delete some directories, recompile, restart VS Code, and then also refresh the test list (which I had done before restarting...) and finally it's gone.
07:56:47 <petern> regression_regression fails for me, but not on the CI.
07:58:35 <petern> Interestingly it looks like signed/unsigned issues...
07:58:56 <petern> > 42: 91: - Rand(): -2062310602
07:58:56 <petern> > 42: 91: + Rand(): 2232656694'
07:58:56 <petern> > 42: 92: - Rand(): -1780331126
07:58:56 <petern> > 42: 92: + Rand(): 2514636170'
08:00:08 <TrueBrain> Please don't summon people ..... 😛
08:00:38 <andythenorth> oof I still didn't coffee
08:00:41 <andythenorth> failure of adulting
08:01:25 <petern> I didn't @ at least ;p
08:03:01 <petern> Also I tried to do stuff with cmake, vcpkg and android... didn't get very far 🙂
08:13:55 <andythenorth> so....town GetNormalGrowthRate
08:14:01 <andythenorth> guess I'll need to read that 😛
08:14:51 <andythenorth> oof I really don't want to directly `_settings_game.economy.town_growth_rate` from GS
08:15:03 <andythenorth> for a start, JGRPP has additional values for it
08:15:16 <andythenorth> so I'll have a non-JGRPP GS out the gate
08:17:13 <andythenorth> could have a growth rate parameter for the GS I guess
08:17:26 <andythenorth> duplicating game settings into GS params seems wrong
08:19:33 <petern> Reusing settings to control the game definitely seems more wrong.
08:20:20 <andythenorth> in that case....
08:20:25 <andythenorth> ....goes it GS parameter
08:31:27 <andythenorth> 50 game years later, still didn't need a 256x512 map 😛
08:32:58 <TrueBrain> for that one line you did!
08:34:11 <andythenorth> that was my first line 😛
08:34:18 <andythenorth> was going to develop the North first
08:34:39 <andythenorth> maybe we should play multiplayer 😛
08:34:46 <andythenorth> is anybody here working today? 😛
08:35:02 <TrueBrain> what is this concept of holiday?
08:35:08 <andythenorth> it's like not having a job
08:35:12 <andythenorth> but you still do
08:37:02 <TrueBrain> sometimes you find piece of our code that are so weird
08:37:06 <TrueBrain> but ... yeah, let's not fix everything at once
08:37:11 <TrueBrain> otherwise we will be here till christmas
08:37:32 <andythenorth> I am here till christmas
08:37:47 <andythenorth> also playing OpenTTD
08:37:52 <andythenorth> developing the North 😛
08:41:10 <TrueBrain> lol @ framerate graphs ... both scales keep jumping up and down
08:41:17 <TrueBrain> sometimes it is 1s on the x-axis .. sometimes 2s
08:41:23 <TrueBrain> it can't seem to make up it's mind
08:52:30 <petern> andythenorth: That's why they don't call him andythesouth.
08:53:20 <petern> TrueBrain: Yeah, it's a bit mad as it depends on how long it takes to get the data.
08:54:22 <TrueBrain> I was changing these times over, and I was like: did I do this? I didn't ... so I will leave it as broken as I found it 😛
08:55:27 <petern> I believe the buckets are ticks, and they have a time. For a stable x-scale I think you'd want buckets that cover time and count the number of ticks.
08:55:42 <petern> Or just add way more data and crop if it's too much 😄
08:55:57 <petern> Finally, I found a regression_regression that passes!
09:06:33 <petern> And yes, it is #10443 that fails for me.
09:15:51 <petern> It looks like it's using the wrong result.txt
09:16:18 <TrueBrain> And w00p, I have OneShot working .. so you can do an actual timeout now 🙂
09:16:34 <TrueBrain> is OneShot a good name? WHO KNOWS!
09:16:43 <TrueBrain> timeout might be better 😛
09:19:33 <petern> Okay. After all that... now I know.
09:20:20 <petern> building and running the regression tests does rebuild openttd if necessary, but doesn't update the regression tests.
09:31:49 <andythenorth> TrueBrain: what if you need TwoShots?
09:31:52 <andythenorth> can you just increment?
09:34:12 <TrueBrain> replacing any duration I come across that is "uint" with "std::chrono", for my sanity ..
09:38:19 <TrueBrain> errmsg_duration turns out to be in jumps of 3 seconds
09:38:27 <TrueBrain> `_settings_client.gui.errmsg_duration` to be exact
09:41:57 <TrueBrain> the tooltip say the value is in 1 second interval .. but the code says in 3 seconds interval
09:42:43 <TrueBrain> clearly the tooltip, ofc
09:43:42 <TrueBrain> it is not just me, right?
09:45:59 <TrueBrain> if I am right, guess the bigger question is: how to resolve it .. do we assume the value the user entered is right? Or did they compensate for the tooltip bug? 🙂
09:50:26 <TrueBrain> now I come to think of it, I think I ran into this a few months / years ago already .. owh well 😛
09:54:42 <TrueBrain> did you know you could hover over an industry type in the smallmap window, and that it starts to blink those industries?
09:57:41 <dP> steeltown in unplayable without hovering 😆
10:07:37 <Rubidium_> TrueBrain: that does indeed look fishy, as I doubt the error UI is going about 0.94c compared to the rest of the game :)
10:08:55 *** menelaos[m] has quit IRC ()
10:08:55 *** patricia[m] has quit IRC ()
10:08:55 *** fiddeldibu[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** leward[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** vista_narvas[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** Guest7844 has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** gdown has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** JamesRoss[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** gretel[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** citronbleuv[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** CornsMcGowan[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** wormnest[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** andythenorth[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** blikjeham[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** giords[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** thelonelyellipsis[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** zzy2357[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** Farrokh[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** NekomimiGunner18[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** rudolfs[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** amal[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** philip[m]123 has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** yubvin[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** igor[m]12 has quit IRC (Write error: connection closed)
10:08:55 *** calbasi[m] has quit IRC (Write error: connection closed)
10:08:55 *** emilyd[m] has quit IRC (Write error: connection closed)
10:08:55 *** Heiki[m] has quit IRC (Write error: connection closed)
10:08:55 *** EmeraldSnorlax[m] has quit IRC (Write error: connection closed)
10:08:55 *** cebopp1[m] has quit IRC (Write error: connection closed)
10:08:55 *** magdalena[m] has quit IRC (Write error: connection closed)
10:08:55 *** luk3Z[m] has quit IRC (Write error: connection closed)
10:08:55 *** karoline[m] has quit IRC (Write error: connection closed)
10:08:55 *** hamstonkid[m] has quit IRC (Write error: connection closed)
10:08:55 *** einar[m] has quit IRC (Write error: connection closed)
10:08:55 *** elliot[m] has quit IRC (Write error: connection closed)
10:08:55 *** karl[m]123 has quit IRC (Write error: connection closed)
10:08:55 *** thomas[m]12345 has quit IRC (Write error: connection closed)
10:08:55 *** cjmonagle[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** jeremy[m] has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** joey[m]1 has quit IRC (Quit: Bridge terminating on SIGTERM)
10:08:55 *** shedidthedog[m] has quit IRC (Write error: connection closed)
10:10:09 <TrueBrain> `MILLISECONDS_PER_TICK` is used in many places it shouldn't be used in 😄
10:10:23 <TrueBrain> Rubidium_: tnx .. will write it down to fix some other time 🙂
10:11:27 <Rubidium_> the commit that "adds" the line of code just moved from duration = number of OnHundredthTick calls to duration = 3000 ms
10:11:50 <TrueBrain> yeah, that is correct
10:12:09 <TrueBrain> I think the tooltip was always wrong
10:12:14 <TrueBrain> 5 seconds (the default) is also REALLY short
10:12:18 <TrueBrain> 15 seconds makes much more sense
10:14:50 <Rubidium_> though I wouldn't change the value description, but just change the default/min/max/timer accordingly
10:15:12 <TrueBrain> yeah, multiply the current value by 3, and change it into actual seconds
10:16:00 <Rubidium_> though maybe first review the other timer related settings, and convert them all in one go
10:16:19 <TrueBrain> just happy I am not going insane 😛
10:17:18 <dP> average time any experienced player looks at that window is probably measured in fraction of second though :P
10:17:45 <Rubidium_> depends on your reference frame ;)
10:22:18 *** wallabra[m] has joined #openttd
10:26:57 *** Smedles_ has joined #openttd
10:27:08 *** Smedles has quit IRC (Ping timeout: 480 seconds)
10:36:42 <petern> That's a shame, catch2 has SECTION() so you could theoretically make a hierarchy of tests, but it doesn't output that information in any useful way 😦
10:37:53 <petern> Having a flat list of tests is a bit awkward, and that's with only 43 of them.
10:38:22 <Rubidium_> maybe there's some parameter that can be passed? Does openttd_test --help give any hint?
10:41:49 <petern> Hmm, the xml output kinda shows it but I think it's buggy.
10:42:25 <petern> Ah no my scrollback was buggy 😄
10:42:56 *** Smedles has joined #openttd
10:43:14 <petern> junit and xml both have the info. I'm not sure what ctest does but it's not there.
10:46:46 <petern> ctest also appears to reexecute openttd_test for each test_case
10:48:07 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
10:56:41 *** Smedles_ has joined #openttd
10:57:10 <TrueBrain> sorry for the size of the PR ... I was debating if I should make it smaller
10:57:20 <TrueBrain> (and put things in follow-up PRs)
10:57:29 <TrueBrain> but this made more sense .. I just hate these big PRs, so: sorry 🙂
10:57:43 <TrueBrain> (also, this made sure I changed 42 files; makes Rubidium happy)
10:57:45 <LordAro> only +800 ? positively small :p
10:59:13 <TrueBrain> now time for lunch; long overdue
11:02:50 <TrueBrain> They are better now 😄
11:03:03 <petern> Yes, much more C++-style 😄
11:03:08 *** Smedles has quit IRC (Ping timeout: 480 seconds)
11:04:21 <petern> The only benchmark that matters.
11:04:59 <petern> You should just remove comments, it'll be a lot smaller!
11:09:50 <TrueBrain> Yes, documented a lot more than there was before ...
11:13:18 *** Smedles has joined #openttd
11:14:16 *** helmsdeepstate has joined #openttd
11:14:51 *** helmsdeepstate has quit IRC ()
11:18:13 <petern> Would actually be nice if that would count comments separately 🙂
11:18:27 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
11:19:52 <petern> [[nodiscard]] on a constructor apparently causing gcc some issues...
11:21:25 *** gnu_jj has quit IRC (Remote host closed the connection)
11:24:04 <TrueBrain> petern: 5 years ago .. seems fine now 🙂
11:24:48 <petern> GitHub Actions disagrees
11:25:04 <TrueBrain> Owh ... it was locally (using gcc myself)
11:25:31 *** Brickblock1 has joined #openttd
11:25:31 <Brickblock1> andythenorth: this isn't firs being broken but rather how the game behaves
11:25:59 <Brickblock1> jgrpp has a setting to fix this maybe that could be added to vanilla
11:26:26 <LordAro> i think there's a Samu PR about that somewhere
11:26:33 <LordAro> or possibly that's only for drop-off
11:27:02 <TrueBrain> petern: works in GCC 11, but clearly not in GCC 9 ... guess either we make it optional for GCC 9, or ... upgrade to GCC 11? 😄
11:27:59 <TrueBrain> hmm, we still build on ubuntu 20.04 ..
11:28:03 <TrueBrain> we should upgrade that to 22.04 anyway
11:29:20 *** Smedles_ has joined #openttd
11:29:42 <TrueBrain> we also only do NOACCESS for GCC11+
11:31:56 <TrueBrain> works since clang 10 and GCC 10.1
11:32:31 <petern> The YouTube algorithm has decided I need to see 12-15 year old locomotive cold-start videos
11:33:33 *** Smedles has quit IRC (Ping timeout: 480 seconds)
11:34:09 <petern> I suppose the fact I left it playing listening to the sound means the algorithm might be correct.
11:35:16 <TrueBrain> petern: so you say, remove all enum references to std::chrono instead? I am not against that .. at least more consistent
11:35:22 <TrueBrain> and an extra line of comments doesn't actually help
11:36:38 <petern> Most of the time in the old code (before even guitimers, although still reasonable with that), the timer was a magic number that wasn't related to milliseconds, so it made sense to document what it meant.
11:36:55 <petern> It was all intertwined too.
11:37:12 <TrueBrain> so, let's remove them! 🙂
11:37:34 <petern> If it's something fairly common and spread all over then keep it, of course.
11:37:50 <petern> The one for 2100 probably needs to stay documented too 🙂
11:37:53 <TrueBrain> although I replaced a few MILLISECONDS_PER_TICK for 30 already 😛
11:38:01 <TrueBrain> but that was because it had nothing to do with ticks ......
11:38:26 <petern> Originally it would've been "that's when the window is updated"
11:41:57 *** Smedles has joined #openttd
11:45:15 <TrueBrain> right, that should make the compilers happy again
11:46:37 <TrueBrain> next up, game-related timers 🙂
11:48:43 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
11:53:12 <petern> Is this doing to make 2TallTyler's life easier or harder? 😄
11:54:47 <dP> btw, it's funny to see the attention to how network lag counts seconds while still it counts them to the wrong interval 😜
11:56:06 <TallTyler> I am so happy to see that PR. Definitely makes my my life easier. 😄
11:56:42 <TrueBrain> It will look something like this throughout the code; at least, I think that helps 🙂
11:58:15 <TrueBrain> owh, guess I shouldn't be using `WC_STATUS_BAR` .. I can now just access it locally 😄
11:58:55 *** Smedles_ has joined #openttd
11:59:21 <petern> Missing TimerGameCalendar::WEEK, just for that one NetworkAdminUpdate call 😉
11:59:50 <dP> TrueBrain: Because `static IntervalTimer<TimerGameCalendar> _disaster_daily(TimerGameCalendar::DAY, [](auto)` is clearly better than `void DisasterDailyLoop()`? 😜
12:02:08 <TrueBrain> why is there now fluid coming out of my nose 😛
12:03:48 *** Smedles has quit IRC (Ping timeout: 480 seconds)
12:11:56 *** Smedles has joined #openttd
12:12:54 <TrueBrain> `Because the _date wraps here, and text-messages expire by game-days`
12:13:01 <TrueBrain> hmm .. isn't that no longer true?
12:13:20 <TrueBrain> it no longer is true 🙂
12:16:48 <petern> I guess date cheat would also affect it though.
12:18:01 <TrueBrain> `if (_cur_year == _settings_game.game_creation.ending_year + 1) ShowEndGameChart();`
12:18:46 <TrueBrain> ah, yeah, okay, so in 2050, you do see the whole of 2050
12:19:18 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
12:28:55 <TrueBrain> hmm, I guess for deterministic behaviour it is needed
12:29:20 <TrueBrain> as now I am doubting if between compilers the order will be the same
12:30:05 *** Smedles_ has joined #openttd
12:30:10 <TrueBrain> not so much for the PR, but for the commit I showed earlier .. order there does matter for the randomizer
12:31:49 <TrueBrain> so we are in agreement 😄
12:34:18 *** Smedles has quit IRC (Ping timeout: 480 seconds)
12:34:24 <petern> If it will be used for game-loop ever, then it may be worth designing it so that it's not possible accidentally end up with non-deterministic behaviour.
12:35:48 <dP> like, you, know, function calls :p
12:36:07 <dP> such a wonderful way to introduce issues where were none :p
12:38:44 <TrueBrain> petern: tempted to use slots, and if you assign yourself to a slot that is already in use, just `assert`
12:42:21 *** Smedles has joined #openttd
12:43:02 <petern> Well you could have single enum for named slots, then you can see a specific order just from that list.
12:43:13 <TrueBrain> was doing just that 😉
12:43:14 <petern> Change the order by reordering the enum.
12:43:23 <TrueBrain> but also want to prevent assigning the same slot twice on the same priority
12:43:36 <TrueBrain> so you can't accidentally do two dailies on "vehicles"
12:44:01 <petern> WindowTimer probably doesn't need such a mechanism
12:44:06 <TrueBrain> also ton of places that don't care about the order btw
12:44:13 <TrueBrain> (for game-timer even)
12:44:38 <TrueBrain> lot of those game-timer hook into the Window system 🙂
12:45:16 <petern> "mark the finance window dirty again because you earned some money" 1,000 times every second...
12:46:01 <petern> I think we don't actually do that, which is why those windows can look odd if they only partially update.
12:46:03 <TrueBrain> how to call the priority where it doesn't matter .... `IRRELEVANT`?
12:46:20 <TrueBrain> once in a while we check if the width needs to be adjusted
12:46:28 <TrueBrain> so just when you earn a zero more, in width, it acts weird
12:46:31 <TrueBrain> to fix itself moments later
12:47:40 <petern> At one point I had one thought on just "caching" the information, then it can be updated periodically instead.
12:48:01 <petern> But that could be a lot of data so I didn't proceed.
12:49:02 <petern> For individual text widgets there's a window function to set parameters, the results of that could easily be stored in the widget for later, but... most of the issue is not though things anyway.
12:49:28 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
12:50:09 <TrueBrain> ghehe; yeah, might be a bit much data 😛
12:55:44 <petern> Probably 'easier' and better to implement double-buffering for windows.
12:57:48 <TrueBrain> `static IntervalTimer<TimerGameCalendar> _check_reset_signal({TimerGameCalendar::YEAR, TimerGameCalendar::P_NONE}, [](auto)`
12:58:18 *** Smedles_ has joined #openttd
12:59:22 <petern> I dunno I just dropped a knife on my foot and it hurts somewhat.
12:59:30 <TrueBrain> 😮 😮 please be careful
12:59:42 <petern> Fortunately it was the handle that landed on my toes, but it's a heavy handle...
13:01:03 <petern> Hmm, is that the same enum as the interval type?
13:01:15 <TrueBrain> no, 2 different enums
13:01:24 <TrueBrain> so you can no mention them 😛
13:01:37 <TrueBrain> `static IntervalTimer<TimerGameCalendar> _check_reset_signal({TimerGameCalendar::Trigger::YEAR, TimerGameCalendar::Priority::P_NONE}, [](auto)`
13:01:41 <TrueBrain> would be the version without that cheat
13:02:28 <TrueBrain> `static IntervalTimer<TimerGameCalendar> _check_reset_signal({TimerGameCalendar::YEAR, TimerGameCalendar::Priority::NONE}, [](auto)` would be the sweetspot in between 😄
13:03:26 <petern> The other thing is when you have things that should run every tick, and some timed events should happen before that, and other events should happen after.
13:03:47 <TrueBrain> that is handled by the moment the timer is updated
13:04:29 <TrueBrain> otherwise we getting rather close to resolving a directional graph 😄
13:04:53 *** Smedles has quit IRC (Ping timeout: 480 seconds)
13:05:40 <petern> Ah so even the "main loop that runs every tick" part of the gameloop should be a prioritized timer that just runs every tick.
13:06:15 <TrueBrain> I don't think we should use the timer for "every tick" 🙂
13:06:22 <TrueBrain> at least ... not yet 😄
13:06:35 <petern> So how do you ensure order?
13:06:45 <TrueBrain> the GameLoop is still the game-loop
13:06:50 <TrueBrain> this is about events like "daily" and "monthly"
13:07:02 <TrueBrain> those events have a priority with them
13:13:04 *** Smedles has joined #openttd
13:19:58 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
13:21:02 <TrueBrain> I might be enjoying the power of C++ a tiny bit too much, but let's see if this works ..
13:29:10 *** Smedles_ has joined #openttd
13:30:35 <TrueBrain> sometimes I am just shocked things compile 😛
13:30:51 <Eddi|zuHause> if it compiles, ship it
13:34:58 *** Smedles has quit IRC (Ping timeout: 480 seconds)
13:38:17 <TrueBrain> nah, it crashes 😛 For some reason I managed to make a jump-to-nullptr in C++
13:42:20 <TrueBrain> owh, right, they fixed that in C++20 ... we use C++17 ... oops
13:43:29 <Eddi|zuHause> "why would a 30 year old game need modern compiler features" :p
13:43:43 *** Smedles has joined #openttd
13:45:55 <petern> We're just slowing the game down 😉
13:46:12 <petern> (That's absolutely nothing to do with increasing limits to stupid bounds)
13:46:55 <TrueBrain> now ... how do I resolve the issue that class A wants to see what is in class B, and class B what is in class A
13:49:02 <Kuhnovic> Abstracting everything into interfaces might do the trick. But it might be overkill.
13:49:16 <TrueBrain> always the wonder, with how little effort can I get this done 😄
13:49:35 <TrueBrain> guess I do need a `.cpp` file after all
13:49:54 <Kuhnovic> Are you running into visibility issues (friend classes can help) or just compilation problems because of circular dependencies at the class level?
13:50:02 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
13:50:38 <TrueBrain> I am running into laziness 🙂
13:52:58 <Kuhnovic> I solved a similar issue at work a while ago, let me try to reproduce it in a small example
13:52:59 <TrueBrain> there, added a source file .. now everything is happy again ... pffff
13:53:10 <Kuhnovic> A source file is prrobably the easiest way 😛
13:55:48 <TrueBrain> owh, but I can't even .. lol .. templates! 😄
13:55:57 <TrueBrain> okay, more drastic measures are required ... fiinnnneeeee
13:59:27 *** Smedles_ has joined #openttd
14:03:37 <Kuhnovic> ```//============= file A.h =============
14:03:37 <Kuhnovic> // Make sure A is fully declared but no implementations are defined yet
14:03:43 <Kuhnovic> A::createB() { return B{}; } // Implementations MUST come after header include
14:03:43 <Kuhnovic> //============= file B.h =============
14:03:45 <TrueBrain> please use pastebins 🙂
14:03:51 <Kuhnovic> B::createA() { return A{}; }
14:04:33 <TrueBrain> hmm .. in an attempt to sort timers, I kinda killed them altogether 😄
14:05:34 *** Smedles has quit IRC (Ping timeout: 480 seconds)
14:10:10 <Kuhnovic> We used something similar at work for a auto-generated header only API where we had similar issues with circular dependencies. Header includes essentially just copy paste the contents of a file. The "delayed" header include results in all class declarations to be at the top of the file and all the definitions at the bottom once the preprocessor has done its thing.
14:11:48 <Kuhnovic> It adds quite a bit of bulk to the code but it does work well. In a way it's like a .h and .cpp file combined into a single .h file.
14:14:11 *** Smedles has joined #openttd
14:20:18 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
14:31:09 <TrueBrain> lol, turns out, I am not capable of making a `std::set` with a custom sorter 😄
14:31:40 <Kuhnovic> Stack overflow to the rescue!
14:31:55 <TrueBrain> yeah, or to your demise ..
14:37:23 <TrueBrain> okay, using a lambda is just .. I don't know. But without a lambda it works fine. Whatever 🙂
14:38:01 <TrueBrain> lol @ 10649 .. so you read, decided to ignore it, and continue anyway? Lol
14:39:55 <petern> Is that a dedicated server on Windows?
14:41:10 <TrueBrain> petern: seems so; no clue what the Windows alternatives are for the Linux commands he is giving
14:41:43 <petern> £350 for a DEC VT420 terminal... no, I don't need it...
14:42:26 <TrueBrain> yippie, finally I have sorted timers 🙂
14:42:31 <TrueBrain> okay, that will help for debugging etc 😄
14:43:00 <TrueBrain> it also actually works
14:43:04 <TrueBrain> now that is shocking 😄
14:44:08 <petern> "128MB" huh... why would a serial terminal have 128MB memory. Odd.
14:46:14 <TrueBrain> wauw, entitled much? Sorry, but .. people seem to misunderstand what "free" means ...
14:49:34 <petern> Ah that's probably the memory of the thing it's plugged into.
14:50:16 <petern> KA49-A, so some kind of VAXstation
14:50:35 <TrueBrain> what on earth are you doing? 🙂
14:50:51 <petern> Looking at random eBay listings 😄
14:53:36 <TrueBrain> now do I merge that commit in the other PR
14:53:39 <TrueBrain> or do I make that another PR
14:53:45 <TrueBrain> guess it isn't that big ..
14:57:28 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:03:10 <petern> So have you considered splitting it ?P
15:03:54 *** gelignite has joined #openttd
15:04:49 <TrueBrain> I can never make up my mind about these things 😛
15:05:14 <LordAro> you don't *have* to have a PR per commit :p
15:05:34 *** WormnestAndroid has joined #openttd
15:06:15 <TrueBrain> LordAro: just say the word, and I will merge them 🙂 I was just missing a place for a nice description 😛
15:08:01 <petern> I do think it might be nice to (keep it in 1 PR but) split the timer interface/implementation off from the changes that switch to it.
15:08:05 *** sla_ro|master has quit IRC ()
15:08:21 <TrueBrain> 3 commits you mean?
15:12:09 <petern> Something like that. Anything which is in the gameloop separate from gui timer changes?
15:12:40 <petern> If it's not possible then don't mind me. Nobody will ever look bad I guess :p
15:12:59 <TrueBrain> it is not a problem; splitting stuff is easy 🙂
15:13:09 <TrueBrain> I just want to keep it as easy as possible for you guys, as I don't have to review it 😛
15:13:29 <petern> Well we can just press the button without reviewing, but...
15:13:44 <petern> Hmm, do we run on any system that doesn't have cstdint? I'm assuming not...
15:13:56 <petern> I have a patch for it.
15:14:40 <LordAro> are you trying to s/uint/uint32_t/ ?
15:15:03 <petern> No, just change the definition of uint*
15:15:25 <petern> Changing all the code is guaranteed to break every single branch/fork everywhere...
15:16:12 <LordAro> never stopped you before
15:17:16 <petern> GUI stuff was quite breaking I admit 😄
15:20:19 <TrueBrain> changing stdafx.h .. is .. expensive 😛
15:21:01 <TrueBrain> petern: talking about that ..... how much will people hate me if I change all header protections to `#pragma once`
15:21:16 <TrueBrain> so easy to mess up the current `#idef` construction 😛
15:27:31 <TrueBrain> as requested, all in a single PR, in 3 commits 🙂
15:27:42 <TrueBrain> easy-peazy-lemon-squishy, or something 😛
15:29:18 <TrueBrain> I decide you don't hate me; how is that for a good day? 🙂
15:30:48 <TrueBrain> still some weird quirks in the Window system .. mainly OnGameTick
15:30:52 <TrueBrain> but that is for another time
15:31:27 <TrueBrain> petern: I always love those: Asked, 13 years ago 🙂
15:32:15 <petern> 3rd comment seems to be "if your compiler is buggy shit it won't work"
15:32:28 <TrueBrain> most bla is about using the same name in 2 folders
15:32:30 <petern> (but blaming pragma once itself)
15:32:32 <TrueBrain> something we aren't allowed anyway
15:32:56 <TrueBrain> `I suggest you use it AND use guards`
15:33:03 <TrueBrain> lol ... now that is what I call overkill 😄
15:33:13 <petern> Is that still an issue in Visual Studio? Pretty sure VSCode doesn't care.
15:33:23 <TrueBrain> hasn't been for years
15:33:28 <TrueBrain> but OpenTTD doesn't update its policies! 😄
15:33:49 <TrueBrain> the influence of America or something, I just read 😛
15:34:29 <TrueBrain> oof, I can spend way too much time on the Window-system .. let's not. Let's address the things TallTyler requested instead 😄
15:36:14 <petern> # I'm afraid of Americans
15:37:07 <TrueBrain> right, linkgraph interval .. that is an odd ball
15:37:25 <TrueBrain> when at 50% of the interval it isn't done yet, it joins the threads to force it will be done 😛
15:41:39 <TrueBrain> okay, you really have to sit down to understand when linkgraphs are updated 🙂 Several code-flows .. hmm
15:46:18 <TrueBrain> it hooks into the game-loop directly, but also into an OnTick hook via Landscape
15:47:06 <TrueBrain> guess that is where your questions come from peter ... having an interval timer "on-every-tick" would untangle that mess too 😛
15:51:48 *** tokai|noir has joined #openttd
15:51:48 *** ChanServ sets mode: +v tokai|noir
15:56:12 *** tokai has quit IRC (Ping timeout: 480 seconds)
15:59:56 <petern> That split looks good, easier to see what's what.
16:01:10 <petern> Although some of the window timer stuff is changed in the first commit.
16:14:05 <TrueBrain> Yeah, both have a few changes in the first commit. Could avoid that, but that was more work 😄
16:21:40 <jfs-> and I'm trying to find some library implementing a parser etc. for the XDG base dirs and user dirs, and it just doesn't seem to exist? outside a package of commandline tools to set things up
16:22:27 <jfs-> it just seems like such an obvious things that ought to exist
16:23:33 <jfs-> yes I remember removing that dependency
16:24:19 <jfs-> the XDG user dirs are a bit more involved since it potentially involves locating and parsing a config file (or running a shell process to execute it and then read the variables out of it somehow)
16:24:40 <jfs-> that is, the user Desktop and Documents directories etc
16:56:23 <TrueBrain> so link-graph does work on the 21th tick after each day .. not sure why .. but it seems important
16:56:59 <LordAro> determined to be the quietest tick for other updates? :p
16:57:15 <TrueBrain> 21 ... I doubt that. Pretty sure it is 42 / 2 😛
16:58:04 <TrueBrain> how important is it when the link-graph recalculates?
17:01:52 <Rubidium_> it's probably not that important, but I reckon pushing more actions to happen on the same tick is not good for the game remaining non-jittery
17:02:25 <TrueBrain> yeah, I plan to just start it based on real-time honestly
17:02:42 <TrueBrain> so unlinked completely from game-time
17:03:05 <Rubidium_> I'd actually wonder whether most of the 'daily' stuff needs to run at the same tick, or whether it's fine to just spread it over the whole day
17:03:27 <dP> aren't linkgraph recalcs affecting the game state?
17:03:28 <TrueBrain> Rubidium_: with my PR you have the framework to figure that out 🙂
17:05:06 <TrueBrain> would be another definition of "priority", I guess 😄
17:06:14 <Rubidium_> but as dP said, linkgraph join/spawn needs to happen at the same tick on all clients
17:07:28 <dP> TrueBrain: and without your pr it's simple to follow all daily functions and see that no, there is nothing particularly "daily" about them and most can be run whenever
17:09:12 <TrueBrain> wauw, my english is crap today .. had to reword that reply 3 times for it to make sense 😄
17:09:53 <TrueBrain> Rubidium_: hmm, yes, the join (the moment it copies the calculated linkgraph into the game) has to be on a known moment .. blegh .. this code is so impossible to read 😛
17:13:15 <frosch> iirc there is a setting for how long the linkgraph is allowed to run. when that time expires the thread will be joined, i.e. it will wait for unfinished computations and copy the result
17:13:39 <TrueBrain> just the code is not easy to read, as it seems it got added on top of each other
17:14:01 <TrueBrain> so it hooks in the game-loop in two different ways, it has 2 different places to store the different settings .. there is some abstraction going on there ..
17:14:04 <TrueBrain> not wrong, just hard to understand
17:24:43 <TrueBrain> `Assertion 'timer->period.priority != period.priority' failed.`
17:34:38 *** esselfe has quit IRC (Ping timeout: 480 seconds)
17:43:32 *** esselfe has joined #openttd
17:43:42 <TrueBrain> right, removed the network timer for now; it wasn't doing anything yet, and we can add it when it actually does something 😛
17:43:57 <petern> Huh, multiple inheritance is weird.
17:45:19 <petern> BaseSettingEntry defines some virtual functions, SettingsContainer also defines those functions (but not virtual) and SettingsPage inherits from both BaseSettingEntry and SettingsContainer, and overrides the functions.
17:45:55 <petern> SettingsPage::Init() explicitly calls BaseSettingEntry::Init() and SettingsContainer::Init() but...
17:49:29 *** amal[m] has joined #openttd
17:49:32 *** andythenorth[m] has joined #openttd
17:49:32 *** calbasi[m] has joined #openttd
17:49:35 *** blikjeham[m] has joined #openttd
17:49:37 *** cebopp1[m] has joined #openttd
17:49:40 *** citronbleuv[m] has joined #openttd
17:49:42 *** cjmonagle[m] has joined #openttd
17:49:45 *** CornsMcGowan[m] has joined #openttd
17:49:48 *** einar[m] has joined #openttd
17:49:48 *** elliot[m] has joined #openttd
17:49:50 *** EmeraldSnorlax[m] has joined #openttd
17:49:53 *** emilyd[m] has joined #openttd
17:49:54 *** fiddeldibu[m] has joined #openttd
17:49:56 *** freu[m] has joined #openttd
17:49:58 *** giords[m] has joined #openttd
17:49:59 *** grag[m] has joined #openttd
17:50:01 *** gretel[m] has joined #openttd
17:50:04 *** hamstonkid[m] has joined #openttd
17:50:06 *** Heiki[m] has joined #openttd
17:50:06 *** igor[m]1 has joined #openttd
17:50:07 *** jact[m] has joined #openttd
17:50:07 *** jeeg[m] has joined #openttd
17:50:09 *** jeremy[m] has joined #openttd
17:50:11 *** joey[m]1 has joined #openttd
17:50:11 *** karl[m]123 has joined #openttd
17:50:13 *** karoline[m] has joined #openttd
17:50:13 *** kstar892[m] has joined #openttd
17:50:15 *** leward[m] has joined #openttd
17:50:15 *** linda[m]1 has joined #openttd
17:50:17 *** luk3Z[m] has joined #openttd
17:50:20 *** magdalena[m] has joined #openttd
17:50:20 *** menelaos[m] has joined #openttd
17:50:22 *** NekomimiGunner18[m] has joined #openttd
17:50:22 *** nolep[m] has joined #openttd
17:50:23 *** osvaldo[m] has joined #openttd
17:50:23 *** patricia[m] has joined #openttd
17:50:23 *** patrick[m] has joined #openttd
17:50:23 *** paulus[m] has joined #openttd
17:50:24 *** phil[m] has joined #openttd
17:50:27 *** philip[m]123 has joined #openttd
17:50:28 *** playback2396[m] has joined #openttd
17:50:28 *** royills[m] has joined #openttd
17:50:31 *** rudolfs[m] has joined #openttd
17:50:34 *** shedidthedog[m] has joined #openttd
17:50:37 *** Farrokh[m] has joined #openttd
17:50:38 *** thelonelyellipsis[m] has joined #openttd
17:50:42 *** thomas[m]12345 has joined #openttd
17:50:42 *** tonyfinn has joined #openttd
17:50:45 *** JamesRoss[m] has joined #openttd
17:50:47 *** vista_narvas[m] has joined #openttd
17:50:47 *** Elysianthekitsunesheher[m] has joined #openttd
17:50:47 *** wormnest[m] has joined #openttd
17:50:49 *** YourOnlyOne has joined #openttd
17:50:50 *** yubvin[m] has joined #openttd
17:50:53 *** zzy2357[m] has joined #openttd
17:51:21 *** YourOnlyOne is now known as Guest10895
17:55:43 <petern> > # error "Only MSVC 2005 or higher are supported. MSVC 2003 and earlier are not! Upgrade your compiler."
17:55:50 <petern> I wonder if MSVC 2005 would actually work...
17:56:02 <TrueBrain> down the rabbithole he goes! 😄
17:57:44 <TrueBrain> okay ... so the linkgraph jobs are spawned, but only on their destructor are they actually merged in the game
17:58:30 <TrueBrain> so the job is created on the 21th tick of every recalc_interval day, and is actually merged on the 21th tick of every recalc_interval + recalc_interval / 2 day
17:58:52 <TrueBrain> and if 2 ticks before that time the job isn't done, the game pauses till it is
18:11:14 <petern> Is Haiku still a thing?
18:12:52 <petern> Oh probably something like this... # define __int64 long long
18:16:28 <TrueBrain> okay, I gave up on linkgraph. That requires more attention than I can muster 😄
18:19:57 <TallTyler> Thanks for the review. Your OCD is probably healthy for me, and I should stop being afraid to change things slightly (like doubling the max setting instead of simply rounding up to 10,000) 🙂
18:20:20 <TrueBrain> and it already made me giggle that someone was like: 4096 days, that is a good max value
18:20:24 <TrueBrain> a human would appreciate that value!
18:21:40 <TrueBrain> but I am almost tempted to suggest to leave link-graph alone for now, and just let it run on the calendar timer in days .. it is hard to explain a user what it does either way
18:24:15 <TallTyler> That wouldn’t make any sense, if you set the calendar speed to 0 it would never update 🙂
18:24:36 <TrueBrain> true ... it needs its own timer, but .. it is difficult 😛
18:24:53 <TallTyler> I do wonder if the entire setting is like the pathfinder settings, and could just be eliminated entirely
18:25:15 <TrueBrain> on big games people tend to increase the delay, to keep it playable
18:25:57 <TrueBrain> I will give it some more thought tomorrow, see if I can find another way to decouple it a bit more
18:26:03 <JGR> If you made it self-tuning you could get rid of the setting
18:26:53 <TrueBrain> it is a bit tricky because of multiplayer, I guess
18:27:12 <JGR> In general the scheduling is not ideal as soon as you have more then one link graph
18:27:17 <TrueBrain> I guess currently if clients can't keep up but the server can, the clients constantly lag?
18:27:55 <JGR> If clients can't keep up they will eventually get booted off the server
18:28:03 *** sla_ro|master has joined #openttd
18:28:06 <TrueBrain> yeah, but I mean, if the server can't keep up, it pauses
18:28:22 <TrueBrain> do clients also have that luxary?
18:28:45 <JGR> No, but if the scheduling is too tight likely the server will also be paused
18:30:01 <JGR> In vanilla the scheduling interval is a constant, but the actual time to execute a job can vary by several orders of magnitude, so you need to twiddle the setting a fair bit
18:30:55 <JGR> If you have many small graphs you can end up waiting forever for them to update because of the round robin behaviour
18:32:24 <TallTyler> Oops, forgot to rebase for the merge conflict
18:32:50 <TrueBrain> okay .. I will have to check out what JGRPP does exactly .. and basically we just need something that runs "once in a while", but deterministic .. I have some ideas .. just requires some rewriting of how the scheduling happens ..
18:33:10 <TrueBrain> tomorrow I first fix autosave and AI start-date .. then we can check back how this is suppose to work 😄
18:35:41 <JGR> The link graph job cost/time is very roughly O(N^2 log N) in the number of nodes
18:36:18 <JGR> So I'm adjusting the period of time for each job or how many jobs to dispatch at once based on that estimate
18:40:23 <DorpsGek> - Update: Translations from eints (by translators)
18:41:43 <TrueBrain> JGR: makes sense. I have no clue what the linkgraph actually is .. game-play wise I have an idea, but never actually looked into how it is done 😄
18:41:59 <TrueBrain> lot of lines of code without actually explaining what it does .. so you have to read up a lot to get an understanding
18:42:43 <TrueBrain> I still don't actually understand what happens there 😛 Need more sleep first 🙂
18:45:59 <JGR> TrueBrain: This just moves the first node in the list to the end of the list
18:46:29 <JGR> As it's a linked list this avoids an unnecessary free then malloc
18:59:56 <petern> I should do cycling instead.
19:02:52 <petern> Great so on Linux uint64_t is "unsigned long" and on Windows uint64_t is "unsigned long long"
19:03:32 <TrueBrain> makes total sense, doesn't it? 😛
19:04:01 <JGR> The only time this really matters is for printf and friends
19:04:16 <JGR> There are standard macros to get around the issue
19:04:16 <dP> I remember it mattering in python at some point xD
19:04:52 <petern> And on Linux we do define OTTD_PRINTF64U "%llu", which is long long unsigned? But it's really only an unsigned long. Hmm.
19:04:55 <dP> because it was switching to bignum earlier on windows xD
19:05:10 <petern> JGR, also matters for std::max apparently, as 1ULL matches uint64 on Windows but not Linux.
19:05:23 <michi_cc[d]> `DWORD_PTR` is even better. After all, why wouldn't a DWORD be 8 bytes on a 64bit system?
19:06:12 <dP> petern: it may even be me messing with it at some point to shut up mingv
19:06:28 <petern> mingw is a separate one.
19:06:42 <JGR> petern: I ended up defining it in terms of PRIu64 if that's available
19:07:15 <petern> Yes, if we include <cinttypes> that should do it.
19:07:18 <dP> mingw is a shitshow of i64 formatting
19:07:28 <dP> they managed to do something incompatible with everything iirc
19:08:04 <JGR> Trying to be Windowsy and POSIXy will lead to some contradictions
19:16:44 <petern> Hmm, if I compile with "Debian" running under Windows, is that going to be the same as native Linux?
19:18:24 <JGR> Should be, if it's WSL/WSL2
19:19:11 <petern> Hmm, cmake looks for ZLIB twice.
19:19:53 <petern> If it can't find it once, anyway. Hmm.
19:21:39 <glx[d]> zlib then png and png needs zlib too
19:22:40 <Rubidium_> just move from printf to fmt and get rid of the printf problems
19:58:39 <petern> I guess the WSL build is not working 😦
20:05:14 <petern> > Scanning dependencies of target openttd
20:05:19 <petern> Sits on that "forever"
20:05:51 <glx[d]> ah might be using the old method
20:06:49 <glx[d]> there are 2 wsl ways, one is using files from windows filesystem, the other is rsync into wsl filesystem
20:07:03 <glx[d]> accessing windows filesystem is dead slow
20:07:30 <petern> Ah, I'm using windows filesystem.
20:07:36 <glx[d]> but I didn't test how it's done with vscode, only with VS
20:07:46 <glx[d]> rsync stuff is all automated
20:08:01 <petern> Oh, I'm not even using VS Code, I just ran Debian and cd /mnt/...
20:09:46 <glx[d]> vscode should be able to build on "remote" debian
20:23:01 *** tonyfinn has quit IRC (Quit: Client limit exceeded: 20000)
20:26:22 *** gelignite has quit IRC (Quit: Stay safe!)
20:33:57 *** wallabra[m] has quit IRC ()
20:36:52 <LordAro> so what have we learned from this?
20:38:28 <LordAro> dP: andythenorth: if we coukd try to avoid unnecessary passive agressive bullshit and drama, that'd be great
20:40:17 *** lobstarooo_ has joined #openttd
20:43:36 <petern> Oh that reminds me I've run out of salad.
21:12:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:29:32 *** Eddi|zuHause has quit IRC (Remote host closed the connection)
21:31:00 *** Eddi|zuHause has joined #openttd
21:31:15 <TrueBrain> What a strange day ..
21:34:47 <TrueBrain> Initial it read sarcastic, but I guess it isn't
21:35:22 *** iskazain has joined #openttd
21:35:22 <iskazain> Hello everyone. There is a qustion - i have GRF that made in the game pyramide chain. It works excellent, but i dont really like industries that autor choose for this grf. Is it possible to change industries but keep this chai?
21:35:24 *** lobstarooo_ has quit IRC (Read error: Connection reset by peer)
21:35:49 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:47:40 <dP> iskazain: it's possible but will be easier to just write the grf from scratch
21:47:54 <dP> hardest part is making industries, defining cargo flow is trivial
22:30:50 *** Wormnest has joined #openttd
22:32:16 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:40:19 *** sla_ro|master has quit IRC ()
22:54:20 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
