IRC logs for #openttd on OFTC at 2023-04-14
⏴ go to previous day
01:04:29 *** nebulabc has quit IRC (Quit: No Ping reply in 180 seconds.)
01:05:50 *** nebulabc has joined #openttd
01:13:02 *** nebulabc has joined #openttd
01:20:55 <TallTyler> Wow, so upset on behalf of a fictional player
01:22:25 <TallTyler> And what does TrueBrain have to do with it? I approved the PR and michicc merged it. 🤔
01:22:39 *** nebulabc has quit IRC (Remote host closed the connection)
01:24:51 *** nebulabc has joined #openttd
01:39:30 *** nebulabc has quit IRC (Quit: No Ping reply in 180 seconds.)
01:39:43 *** Wormnest has quit IRC (Quit: Leaving)
01:40:41 *** nebulabc has joined #openttd
02:12:13 *** Smedles has joined #openttd
02:23:19 *** Flygon has quit IRC (Remote host closed the connection)
02:26:25 *** audigexJon has joined #openttd
02:26:25 <audigexJon> I mean, I can kinda see where they’re coming from in terms of it changing existing savegames - I can’t imagine that’s ideal even if it doesn’t affect many people
02:26:25 <audigexJon> But the idea that it’s enforcing the author’s gameplay style is a bit daft because the “distance has diminishing returns” thing has always existed in TTD but has been kinda broken by OTTD’s huge maps. This change is really just restoring that (intended) behaviour, if anything you could argue it’s a big fix for a bug introduced when larger maps were added without accounting for this
02:28:43 <Eddi|zuHause> we've had discussions like this when the acceleration physics were changed
02:28:46 *** esselfe has quit IRC (Remote host closed the connection)
02:33:53 *** esselfe has joined #openttd
02:42:46 *** NGC3982_ has quit IRC (Ping timeout: 480 seconds)
02:46:27 <EmperorJake> Am I correct in assuming that this change makes vehicles with very slow cargo decay rate more effective on long routes?
02:47:05 <Eddi|zuHause> that was the original intention of that property, yes
02:50:55 *** NGC3982 has joined #openttd
02:51:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:09:50 *** nebulabc has quit IRC (Remote host closed the connection)
05:11:06 *** nebulabc has joined #openttd
05:32:04 *** nebulabc has quit IRC (Quit: No Ping reply in 180 seconds.)
05:35:47 *** nebulabc has joined #openttd
06:22:15 *** FIREDR4GON has joined #openttd
06:22:15 <FIREDR4GON> Hey, I was trying to setup the development environment to work on a bug , I am using VS 2019 and getting a warning saying that
06:59:43 <TrueBrain> FIREDR4GON: Did you follow the guide? Installed vcpkg? Set the path correctly?
06:59:55 <iskazain> dP: From scratch? What this mean? About industries, is it hard to replace one in other? With same production lines.
07:00:08 <FIREDR4GON> TrueBrain: where is the guide available?
07:00:51 <TrueBrain> In the COMPILING.md file
07:02:28 <FIREDR4GON> TrueBrain: Thanks i'll go through it once and see what i missed
07:02:35 <TrueBrain> TallTyler: Haha, the one PR I stay far away from, and I still get blamed, w00p 😄
07:02:57 <TrueBrain> FIREDR4GON: Let us know if you still run into troubles 🙂
07:03:15 <FIREDR4GON> thanks for the help, i appreciate it.
07:45:08 <petern> Heh, I had already done that but not pushed, as I attempted (and failed) to compile under WSL instead.
07:46:10 <petern> Weirdly the commit in the push appears before LordAro's comment 🙂
07:52:31 *** sla_ro|master has joined #openttd
08:02:53 <petern> I am not convinced that Rubidium's suggest is not the best way.
08:05:05 <petern> Also widget nested tree is awkward, I might change the initialization.
08:56:58 <TrueBrain> double negative, nice 🙂
08:58:24 *** nebulabc has quit IRC (Remote host closed the connection)
08:58:41 <TrueBrain> FIREDR4GON: and, managed to get it compiling? 🙂
08:59:27 <TrueBrain> hmm .. so when build-on-pause is active, players can build, but AIs can't?
08:59:48 <TrueBrain> that hardly seems fair 😛
09:01:58 <TrueBrain> okay .. so when should AIs start .. "seconds of unpaused game", I guess?
09:05:15 *** nebulabc has joined #openttd
09:05:39 <TrueBrain> guess it doesn't actually have to be based on game-ticks? It can just be ... when-ever. As for multiplayer only the server starts the AIs, so no desync risk etc
09:12:09 <petern> Game time is also useful though.
09:12:39 <TrueBrain> you have an example of what you are thinking about?
09:13:46 <petern> "Start after x months of game time" or "Start after x seconds/minutes of real time", both seem useful.
09:14:04 <TrueBrain> yeah .. I guess. But having both feels weird
09:14:49 <petern> Game time is more deterministic, so some people with four letters names will "need" that for benchmarking...
09:15:40 <TrueBrain> that is fair, deterministic starting of AIs seems useful
09:15:58 <TrueBrain> so a compromise there: we present it in "minutes after start" and base it on game-ticks
09:16:23 <TrueBrain> a minute is about a game-month, so that lines up fine
09:16:38 <TrueBrain> but also means that if you speed up or slow down the calendar, it still happens after a minute
09:17:02 <TrueBrain> so it could be a month in-game time, or 15 days .. but that depends on how fast your calendar goes (with 2TallTyler's patches, ofc)
09:24:10 <petern> Coo, I got some "lego" to construct, but it comes in anti-static bags and requires solder.
09:24:54 <petern> It's definitely not a DIY synth kit because I don't need any more synths.
09:25:09 <TrueBrain> good; you were scaring us 😛
09:26:13 <TrueBrain> meh, guess I should make it possible to save/load timers ..
09:43:21 <TrueBrain> hmm .. can't we convert all of OpenTTD to be event-based? Decoupled code is so much easier to deal with 😛
09:45:23 <TrueBrain> or we could for example make the company "manager" into a class, and use that instead ..
09:45:34 <TrueBrain> but all these global functions are a bitch to deal with in terms of flow 🙂
09:45:54 <TrueBrain> in this case, I need to know when a new game is started
09:46:20 <TrueBrain> there is now this `StartupCompanies` .. took a long time to find that 😛
09:47:37 <dP> iskazain: I mean just make a new one. Unfortunately, there is no simple way to modify a newgrf when you have no source. And in this case there is probably no source at all as it was likely made with NFO which is basically raw binary.
09:50:34 <petern> TrueBrain: Basically rewrite it in a new language 😉
09:50:46 <TrueBrain> yeah, let's do Rust, with traits
09:51:34 <TrueBrain> but okay, my timer PR is a start of making things event-based .. so it isn't even that far fetched 😛
09:53:11 <petern> Timers are just events that get triggered at specific times instead of actions.
09:53:34 <petern> Is the "action" of the game tick reaching another month an event or a timer? 😄
10:04:22 <petern> So event handlers would be really useful for GUI stuff.
10:05:01 <iskazain> dP: Catch it, tnx for explaine. Dont u know on this discord someone can make this pyramide newgraf?
10:05:25 <petern> The current model of rigid class-based method handling is a pain.
10:08:43 <TrueBrain> too bad decorators don't exist in that sence for C++ .. I love making UIs in Python for that reason .. just easier
10:11:38 <petern> It's a problem "solved" by using one of the bulky ancient widget libraries...
10:11:49 <petern> That could never fit in with our code 😄
10:12:40 <petern> > struct GenerateLandscapeWindow : public Window {
10:12:40 <petern> > WidgetEvent<WID_GL_ARCTIC, OnClick> blah = (int x, int y) { this->climate = "arctic"; }
10:12:52 <petern> If something like that construct is possible maybe it's "a way"
10:13:04 <TrueBrain> that is what I am doing now for timers
10:13:32 <petern> Yes, that's why I "came up" with this syntax
10:13:42 <TrueBrain> it is not far-fetched in that sense
10:14:00 <petern> with templates you could maybe hide it as "OnClick<WID_GL_ARCTIC> ... = ...."
10:14:13 <TrueBrain> and I want `GameEvent<NEW_GAME> blah([]{});` now 😛
10:14:52 <TrueBrain> just trying to follow where we detect if we went to the main menu .. it is funny 😄
10:15:05 <petern> I was wondering about having each widget object handle its event, but then you need the state of the window normally, and you end up complicating construction with different objects flying around...
10:15:40 <petern> So an event system that binds events behind the scenes seems better anyway.
10:17:14 <petern> In my testing I've made a separate NWidget for dropdown buttons that has a handler for getting the dropdown list, and then it can do whatever it needs to with it.
10:18:34 <petern> But that's very specific, and it's a bit stuck because currently widgets don't handle any clicks.
10:19:35 <petern> And the build function binding is done badly...
10:19:50 <TrueBrain> replacing any of this is a massive amount of work ..
10:19:51 <petern> > this->GetWidget<NWidgetDropDown>(WID_GL_TOWNNAME_DROPDOWN)->GetDropDownList = BuildTownNameDropDown;
10:20:13 <petern> (It could be a lambda but that's an already existing function)
10:21:09 <petern> That binding method isn't anywhere near as elegant as your timers.
10:21:27 <TrueBrain> just throw enough templating against it till it looks pretty, right?
10:22:47 <TrueBrain> hmm .. I wanted to add the competitors interval value to the difficulty setting
10:22:50 <TrueBrain> but those settings scare me
10:23:52 <TrueBrain> okay, Tyler recently also added one .. so I can do it too!
10:24:02 <petern> Do we even have difficulty settings any more?
10:24:14 <TrueBrain> internally, they are called like that, yes
10:24:20 <petern> If they're split internally, it's just a left-over .
10:27:09 <TrueBrain> currently AI start dates are a bit randomized
10:27:12 <TrueBrain> do we still want that .. hmm
10:28:42 <TrueBrain> back then it felt "more random" to do it like that
10:28:44 <TrueBrain> now it feels .. weird
10:28:56 <petern> The old original AI would just start building iirc.
10:29:11 <petern> But with NoAI they do some planning I guess.
10:29:34 <TrueBrain> it was more: otherwise AIs start like: every 3 months
10:29:36 <TrueBrain> which feels unrealistic
10:29:46 <TrueBrain> by randomizing it a bit, it was like: in 4 months .. after a month .. etc
10:29:51 <TrueBrain> so it feels more natural
10:32:02 <glx[d]> It can also start before the minimal delay
10:32:06 *** gnu_jj has quit IRC (Remote host closed the connection)
10:36:07 <TrueBrain> okay ... next question, do we show this value in the settings dialog, or in the AI settings dialog .. the latter seems more clean, but also requires a bit more work .. as "0 is special" 😛
10:36:15 <TrueBrain> (the AI settings dialog already has how many AIs can start)
10:37:00 <glx[d]> 0 means no delay and no randomisation
10:37:29 <petern> How special is a delay of zero meaning no delay? 😉
10:37:58 <TrueBrain> I guess you are right
10:38:03 <TrueBrain> I just like the fancy "0-is-special"
10:39:04 <glx[d]> It's special only because randomisation disabling
10:40:32 <TrueBrain> well, not even that .. just that 10% of 0 is still 0
10:42:03 <TrueBrain> `Interval in seconds between starting of competitors` suggestions to improve the text?
10:42:24 <petern> TrueBrain: Might be one to do in stages, supporting both methods concurrently
10:42:40 <TrueBrain> I think it would make the GUI better, and easier to extend 🙂
10:42:59 <glx[d]> And simplify the huge switches
10:43:04 <TrueBrain> could we also move the GUI definition to an external format, which is converted to C++? So we can have decent tools to draw GUIs? 😛
10:43:18 <TrueBrain> I made a HTML mockup for that 😛
10:45:53 <petern> The definitions are a bit awkward, they are not naturally nested we just format them that way. They're just a list of building blocks to create instructions on how to create the widgets. Hmm.
10:46:27 <petern> So it's not impossible to move the instructions to a pre-processed format
10:46:35 <petern> Whether that improves it is another matter.
10:46:35 <TrueBrain> well, now first lunch ... except for save/load my AI start-date rewrite is done .. and I think it is pretty 😄
10:49:36 <petern> What's that config format that is hierarchical?
10:54:01 <petern> I wasn't referring to link, sorry 🙂
10:54:33 <glx[d]> But YAML is kinda similar
10:54:59 <dwfreed> JSON and YAML both have hierarchy
10:55:38 <dwfreed> (recent versions of the YAML spec allow JSON to be read by a YAML parser)
10:57:55 <glx[d]> petern: It can improve if hiding the layout stuff inside the description format
10:58:38 <glx[d]> Easier to visualise with indentation
10:59:34 <glx[d]> But as vertical/horizontal stuff still need to be specified
11:00:47 <petern> It helps with getting the hierarchy right, rather than helping with the layout itself.
11:01:13 <petern> WWT_PANEL always gets me, because it's also a container, so it needs EndContainer()
11:34:34 <TrueBrain> and I want reusable GUI parts ... ugh, you can't click on text in the AI Settings to modify the field ..
11:34:47 <TrueBrain> the settings window can!
11:41:16 <glx[d]> Double clic doesn't work ?
11:44:56 <glx[d]> Yeah reusable GUI parts so GameConfig can include AISetting instead of duplicating it
11:48:17 <TrueBrain> now let's see if I can fix save/load to work as I would expect ..... pam pam pammmm
11:50:21 *** nebulabc has quit IRC (Quit: No Ping reply in 180 seconds.)
11:53:25 *** nebulabc has joined #openttd
11:55:08 <TrueBrain> I still can't get used to `std::min` and `std::max` .. I always confuse the two 😛
11:59:04 *** nebulabc has quit IRC (Remote host closed the connection)
12:00:08 *** nebulabc has joined #openttd
12:11:12 <TrueBrain> impressive, I actually managed to lose files during rebase / working in multiple branches .. that doesn't happen often 😄
12:11:45 <TrueBrain> I guess I never actually added the files, so I can only blame myself 😄
12:31:54 <petern> Oh my force-push triggers the pipeline properly. I must have updated something and forgotten 🙂
12:33:52 <petern> Hmm, time for breakfast/lunch.
12:46:07 <LordAro> clearly we should reject #10647 now
12:46:08 <TrueBrain> always this one minor thing when looking over your own PR 😛
12:46:29 <TrueBrain> you are free to do so 🙂 Would cost me a bit more work, but don't let that hold you back 😄
12:46:58 <TrueBrain> ugh, the saveload could use some trait-like system too, to make it far easier to saveload custom structs ...
12:48:34 <TrueBrain> "well, actually" is such a fun game on TV 🙂 Well, YouTube .. but that is TV these days, not?
12:51:43 <petern> Is it about mansplaining?
12:52:12 <TrueBrain> no; it is someone telling a story or a fact, but makes one (minor) mistake. And 4 contestants need to figure out what that mistake is
12:52:18 <TrueBrain> and start their answer with: "well, actually ...."
12:52:30 <TrueBrain> it is really funny 🙂
13:04:48 <LordAro> sounds a bit like Would I Lie To You
13:04:54 <LordAro> or The Impossible Truth
13:08:47 <LordAro> shall i put the popcorn on?
13:10:02 <TrueBrain> I like that 10205 (which 10607 fixes) is by far the oldest bug I know 🙂
13:10:27 <TrueBrain> and I am so happy I finally understand where the 74 ticks are coming from 😄
13:11:09 <petern> "It's so old why bother fixing it"
13:11:52 <TrueBrain> but yeah, while working on the timer stuff, I realised how valuable it is to have 1 game-day very close to 2 seconds .. it makes talking to the user so much easier
13:14:05 <petern> I think the old time TTD mentions days is in vehicle service interval, and the cargo payment graph
13:17:15 <petern> It's a weird way over iterating the vehicle chain.
13:17:34 <TrueBrain> coding-wise it needs improving for sure; but the first question is: what is it fixing? 😄
13:17:56 <TrueBrain> sell it in test-mode to find the price of the whole train, I would say 🙂
13:18:47 <petern> If you iterate the chain in squirrel then it's possible it gets deleted under you.
13:19:09 <LordAro> TB in a friendly mood
13:19:35 <TrueBrain> I am finally coding again .. has been months
13:20:39 <TrueBrain> and I am actually excited for this time-dilation stuff TallTyler has been doing .. it looks like an awesome solution to a long outstanding issue 🙂
13:21:31 <petern> Maybe I should look at infrastructure sharing again, that was always fun...
13:21:42 <TrueBrain> One of those other things we never managed to actual solve 😄
13:22:01 <petern> I think there was another one called subsidiaries.
13:22:35 <TallTyler> Both of those sound like a game design problem more than a code problem, which tend to be the hardest problems to solve 🙂
13:22:56 <TallTyler> Not that I wouldn't be excited to see them and chat about how to solve them 😄
13:23:11 <petern> Yes, you can do nothing and then get griefing or add lots of and have way too many options and it's annoying.
13:23:23 <petern> Maybe it needs to be event timer based 😉
13:23:30 <TallTyler> Definitely a tightrope to walk
13:23:38 <TrueBrain> owh, lol, my AI start-date change, changes the regression 😄
13:23:58 <TrueBrain> makes sense .. as it starts slightly different
13:25:34 <TallTyler> Is anybody interested in clicking Merge on #10607 so it's not just TB and I imposing our iron wills on the game? More democracy and such?
13:26:46 <TrueBrain> we can always start our own fork and do it there; we call it Vanilla+ 🙂
13:27:48 <TallTyler> Maintaining a fork sounds like a lot of work 😛
13:28:02 <TrueBrain> upstream will be unmaintained instantly, so nothing actually changes 😛
13:28:49 <dP> TrueBrain: so mind explaining why is it so valuable in the pr?
13:28:53 <TrueBrain> hmm .. does it make sense the regression changes? I dunno .. bit weird ...
13:28:57 <dP> because as I see it's absolutely irrelevant
13:29:10 <LordAro> TallTyler: i'm not sure that will change anything, it'll then just be you, TB & whoever merges it :p
13:29:24 <LordAro> those evil devs breaking the game
13:29:34 <TallTyler> It would be 50% more democracy!
13:30:56 <TrueBrain> how to debug this regression issue .. hmmmmmmmm
13:32:06 <TrueBrain> `Debug(misc, 0, ..)` doesn't get recorded in the output .. oh-oh .. how did this work again .. been a while 😄
13:32:33 <TrueBrain> ah, okay .. `ScriptObject::GetRandomizer(OWNER_NONE)` is the issue
13:32:48 <TrueBrain> I assumed that it wouldn't influence game-state, I have to admit ..
13:32:54 <TrueBrain> as how does that work in multiplayer?
13:33:31 <TrueBrain> I guess they were applied before the game starts ...
13:34:14 <TrueBrain> Rubidium: you looked at this fairly recently, do you happen to know why AI parameters's deviation is using that randomizer?
13:34:52 <TrueBrain> for some reason I would have expected that to be done by the InteractiveRandom
13:37:53 *** godbed is now known as debdog
13:41:26 <TrueBrain> owh, okay, it all boils down back to `InitializeRandomizers`, which uses `_random`. I see what you did there, nevermind, tnx 🙂
13:52:19 * LordAro primes the fire extinguishers
13:54:19 <petern> Hmm, two releases in one day, this is getting lax :/
13:54:56 <TrueBrain> ugh, why did we ever add regression to the game? I hate it 😛
13:55:05 <TrueBrain> it is telling me I am doing something wrong, and I don't like it!
13:55:27 <LordAro> it would be nice if there was an easier way of actually getting the output out
13:55:40 <LordAro> it seems to be a problem every time someone changes something
13:55:59 <TrueBrain> yeah .. but it is hard to give a better output honestly
13:56:27 <TrueBrain> in my case what I run into, is that in the regression savegame, the AI is not active yet
13:56:37 <TrueBrain> so my "when does the AI start" influences the outcome
14:03:48 <TallTyler> I think I’m going to take a Discord break today. Last time I said that I released 13.1 but I’ll try to do better today 😛
14:04:07 <TrueBrain> enjoy the weather outside 🙂
14:04:46 <TallTyler> I will! Going to touch all the grass.
14:06:12 <petern> Grass... is that... outside?
14:06:26 <petern> Mind you the TTD grass does look lucious and green
14:07:28 <TrueBrain> owh .. current code has the default interval on 10 minutes
14:07:31 <TrueBrain> I was going for 30 seconds
14:07:39 <TrueBrain> yeah .. let's change the unit from seconds to minutes, that makes a lot more sense 😄
14:07:56 <TrueBrain> about one per game-year .. sounds fair
14:08:19 <petern> Oh shame, this slow game hasn't sped up at all. 😉
14:08:39 <TrueBrain> what is the bottleneck? 😄
14:08:51 <TrueBrain> especially .. why is your graphics rate so low? vsync?
14:10:18 <TrueBrain> `1 minutes` .. owh no ...
14:14:58 <TrueBrain> okay, regression now first has to run 10 minutes before the AI starts .. that is not good 😛
14:15:00 <petern> TrueBrain: Seems to be locked to game tick rate if it's running slow... Hmm.
14:15:22 <TrueBrain> petern: depends on what part is slow, but it is possible 🙂 Especially as the drawing part is slow 😄
14:15:36 <petern> Drawing is not slow, it's just game loop.
14:16:01 <TrueBrain> we need more decoupling!
14:17:02 <petern> I had hardcoded to 32bpp-simple which I've now removed, but that doesn't affect much.
14:17:15 <TrueBrain> owh, yes, ofc, the draw-thread has to wait for the game-thread to release the lock before it can render a frame .. your game-ticks take SO LONG that even the drawing hurts .. makes sense 🙂
14:17:47 <petern> Multithreading when? 😄
14:17:49 <TrueBrain> single-gamestate shit 😛
14:18:04 <TrueBrain> I do still wonder why pathfinding takes so long ...
14:18:07 <petern> Ooh, copy the gamestate every video tick!
14:18:21 <petern> In this case it's just shedloads of vehicles.
14:18:26 <TrueBrain> I mean, especially for trains ... it is not THAT big of a graph ..
14:18:42 <TrueBrain> but .. too many things to look into ... first I need to fix this AI start date bla 😛
14:18:42 <petern> Have you seen Wentbourne? 😄
14:19:11 <petern> It's not just pathfinding, it's the sheer number of vehicles to process every tick.
14:21:27 <petern> Even the frame rate counting slows it down a bit.
14:22:43 <TrueBrain> 🙂 Not surprising, I hope
14:25:00 <TrueBrain> hmm ... how to recover this regression stuff ... hmmmmm
14:25:02 <petern> No but suboptimal because we split the stats by vehicle type, and each vehicle type is intermixed with everything else, it has to keep switching around timers.
14:25:09 <petern> (That's not how it does it but still)
14:25:31 <petern> Update the settings in the regression save so the AI starts instantly?
14:26:00 <TrueBrain> that is the thing .. I changed what instantly means .. that is to say: AIs that start instantly, are created at map creation now
14:26:12 <TrueBrain> instead of one by one in the first few ticks
14:26:30 <petern> Sa.. was working on something like that. Blame him 😉
14:26:32 <TrueBrain> also ... the old `start_date` is out of reach 😛
14:26:46 <TrueBrain> so I don't actually know the setting the user had ..
14:26:54 <TrueBrain> and trying to reach the `start_date` is .... an interesting problem 😄
14:27:26 <TrueBrain> (it tries to resolve a nullptr)
14:28:39 <TrueBrain> `start_date` was such a hack ...
14:29:19 <petern> Okay, so... if it's "instantly" what happens if there are no AIs when it's loaded?
14:29:35 <petern> Or is it trying to start it straight away.
14:29:45 <TrueBrain> I don't follow, sorry?
14:30:39 <TrueBrain> the issue is, `start_date` was stored per AI, in a settings-table per AI
14:30:48 <TrueBrain> to ensure it always exists, it is hacked throughout the code to make it available
14:30:53 <TrueBrain> I threw away all that code, as .. wth
14:31:13 <TrueBrain> which is fine for 99.99% of the game .. but now for regression, I don't actually know that the AI should start as soon as possible
14:31:34 <petern> With your changes, when does the regression AI start?
14:31:43 <TrueBrain> 10 minutes after starting it 🙂
14:31:45 <petern> Instantly is fine, after 10 minutes less so 😄
14:31:53 <TrueBrain> because that is the default 😛
14:32:14 <petern> It's a savegame right?
14:32:25 <petern> Can it be updated somehow to have the AI already started?
14:32:38 <TrueBrain> I dunno .. possibly
14:32:43 <petern> Company is present, AI just fills the slot.
14:32:59 <petern> Then the regression testing is testing the AI, not testing the AI starts.
14:34:33 <petern> Hmm, maybe if I build without asserts it'll run that savegame quicker.
14:34:48 <petern> (No maybe, just how much)
14:39:16 <petern> It's fun how a modern ARM-based CPU will beat my 6-core beast that's "only" a few years old.
14:39:28 <petern> Stupid computers, you buy it and it's obsolete already 😦
14:44:28 <TrueBrain> this is weird ... it seems there aren't even settings stored in this savegame ..
14:44:47 <TrueBrain> so how does it know to start an AI? Hmmmmmm
14:46:37 <TrueBrain> owh, but there is ... so I am just not capable of writing code, nice 😄
14:52:48 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
14:52:52 <TrueBrain> so I see the `ai_sl.cpp` reading the start_date, but when I try to access it in afterload it tells me: nah, there are no settings bro
14:56:57 <TrueBrain> ah, ofc ... because I also dropped the registration of the fact `start_date` even exists .. lol
15:03:25 <LordAro> the UI for transfers is stupidly confusing, for sure
15:03:48 <LordAro> it's probably one of the most common questions i see
15:04:11 <TrueBrain> yeah, transfers are .. weird
15:06:23 <TrueBrain> okay, the stationlists does have the AI already loaded .. so I guess I just have to do it like that
15:06:36 <TrueBrain> the question becomes .. how to do that in a clever way 😛
15:07:39 *** WormnestAndroid has joined #openttd
15:13:55 <TrueBrain> so spawn the AI, save the game .. how quick can I do that?
15:15:15 <petern> Can you cheat and make it issue a pause just as it creates the AI company...?
15:15:19 <LordAro> TrueBrain: we've always resisted making changes to the regression saves because they're also good save upgrade tests :p
15:15:47 <TrueBrain> LordAro: what can I say ...... know a better way? 😄
15:16:02 <TrueBrain> petern: I think I can even make it autosave 😛
15:16:06 <LordAro> can you issue a command on load?
15:16:12 <LordAro> or are those scripts multiplayer only?
15:17:01 <TrueBrain> it is just annoying, stationlists does have the AI preloaded .. regression doesn't ..
15:17:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:17:03 *** WormnestAndroid has joined #openttd
15:17:33 <TrueBrain> the count-down "till next AI" wasn't even started yet
15:17:39 <LordAro> ah yeah, does seem to be network only
15:17:55 <TrueBrain> so not sure those kind of solutions actually make regression easier .. or just add to the complication
15:18:07 <TrueBrain> I rather have we finish that project to load all kind of old savegames to see if they are still functional 😄
15:18:29 <LordAro> find the relevant bit in the save? :p
15:18:46 <TrueBrain> I can't even find the delay the AI needs to start 😛
15:18:48 <LordAro> (then we could just load a specific seed...)
15:19:39 <TrueBrain> the seed idea was considered not practical, as any changes to the map generation would make the regression invalid
15:19:56 <LordAro> but how often does that happen? :p
15:20:21 <TrueBrain> remember that the regression was designed to validate the AI API
15:20:23 <TrueBrain> not anything else 🙂
15:22:20 <TrueBrain> hmm .... okay, creating this save is annoying 😄
15:22:46 <TrueBrain> the AI instantly starts to build
15:22:49 <TrueBrain> which ... is not what you want 😛
15:22:56 <TrueBrain> so I need to preload it with an empty AI with the same name or something
15:23:16 <Eddi|zuHause> that sounds wrong on so many levels
15:24:06 <TrueBrain> pausing it did the trick
15:25:07 <TrueBrain> forgot to unpause it
15:25:49 <TrueBrain> not how I wanted to spend over an hour on .. eeuuhh .. how to resolve this ..
15:26:27 <LordAro> just blame (probably) you from 2007
15:26:30 <TrueBrain> LordAro: I guess, if we REALLY want to, we could use an older OpenTTD version to change the savegame with .. but the title-game also already helps for REALLY old games 😛
15:26:40 <TrueBrain> owh yes, I hate my own past self for this 😛
15:33:24 <TrueBrain> I just don't ....... so I changed `misc_sl.cpp` to make sure the savegame always acts like the game is paused
15:33:30 <TrueBrain> but when I load the game .. it is paused
15:34:53 <petern> Hmm, having difficulty determining what is a "reasonable" size for a width...
15:35:16 <petern> Widget width, that is.
15:37:06 <Eddi|zuHause> about this |< –––––––––––>|
15:40:27 <TrueBrain> how does it know to pause the game 😢
15:42:54 <Eddi|zuHause> afair there's a "pause on load" setting?
15:43:09 <TrueBrain> only pause-on-newgame, and it is not that, as normally when I save/load it doesn't pause
15:43:23 <TrueBrain> but I also changed `misc_sl.cpp` to always write `PM_UNPAUSED` in the location for `pause_mode`
15:46:26 <Eddi|zuHause> i loaded a random savegame i have, which isn't even mine, and game speed is 0.30x
15:47:47 <TrueBrain> I ... am just ... lost for words. What the hell is going on here .. lol ..
15:48:03 <Eddi|zuHause> (is apparently a 4kx4k britain map)
15:49:53 <TrueBrain> okay .... seemly there was something wrong with my global or what-ever .. I guess an optimization that went a bit greedy ..
15:50:03 <petern> Well if you saved it paused then it will load paused... but I guess you'll dealing with something else.
15:50:41 <TrueBrain> again, in `misc_sl.cpp` I changed the variable to something that was always `PM_UNPAUSED`
15:50:50 <TrueBrain> so it shouldn't have saved it paused
15:51:05 <petern> Can you not just change the regression configuration to start the AI immediately or does the savegame override that?
15:51:32 <petern> Sometimes I should think things through before pressing enter 😄
15:51:56 <TrueBrain> okay, FINALLY I managed to save a savegame that is never paused
15:52:15 *** ChanServ sets mode: +v tokai
15:52:33 <TrueBrain> petern: sadly, it is a setting stored in the savegame 😦
15:54:05 <TrueBrain> right, finally I am getting somewhere .. stupid saveload system, I hate you :p
15:57:35 <Eddi|zuHause> maybe it's 0pfffffffff? (whatever format p would be)
15:59:12 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
16:00:39 <TrueBrain> a whole day, just to fix a weird choice I made back in 2007 ..
16:01:19 <LordAro> was it previously uncompressed or something?
16:01:47 <TrueBrain> it went from 96KB to 95KB
16:02:10 <TrueBrain> yeah, the UI is not all that clear 😛
16:02:25 <TrueBrain> that would been impressive, to get 99% reduction with 1KB
16:02:29 <TrueBrain> savegames of ... a few bytes? 🙂
16:04:16 <petern> Oh I forgot how annoying it is to do reporting for a website :/
16:05:29 <Eddi|zuHause> just make a compression method that saves 1 byte, and repeat that any number of times!!!! :p
16:24:29 <Eddi|zuHause> LordAro: "just optimize the test cases/benchmarks" is a well-established method
16:37:04 <petern> So yeah... "about yay big"
16:37:15 <petern> Maybe we need an AI to determine good widget widths...
16:40:29 <petern> Hmm, for variants that have different introduction dates, maybe we could have a flag that makes a new engine automatically become the current "preferred variant"
16:43:59 <petern> More things nobody is asking for 😄
16:44:34 <glx[d]> LordAro: There is an easy way, it's stored in /build/regression_<test_name>_output.txt
17:27:47 *** gelignite has joined #openttd
17:55:47 <TrueBrain> hahaha, lol @ Zorg .. does they mean: we haven't asked him personally? Or how did he check his claim? 🙂
17:56:45 <glx[d]> shorted tick doesn't change anything in game events
18:06:20 <Rubidium_> TrueBrain: it uses the "owner none" randomizer, so the starting of AIs is reproducible if you want/need to fix some bug in your AI. Similarly it just makes the game run reproducibly with the AI as well
18:07:40 *** gnu_jj_ has joined #openttd
18:07:42 *** gnu_jj has quit IRC (Read error: Connection reset by peer)
18:13:31 <TrueBrain> Rubidium_: yeah, as I managed, I figured out what it did in the end. The thing that worries me, is the `_random` in the initialization of the timers in afterload
18:13:50 <TrueBrain> now if you save/load the game, the `_random` is in a slightly different state then when you don't do that
18:14:20 <TrueBrain> it might be better to store the ScriptRandom entries in the savegame too, to avoid that
18:15:31 <TrueBrain> managed? Mentioned .. ugh ... sleep ... I need that! 😛
18:15:46 <TrueBrain> timers? randomizer ..
18:15:51 <TrueBrain> really, I should give up writing ..
18:16:22 <TrueBrain> let me try again, sorry about that Rb: Afterload calls InitializeWindowsAndCaches calls ScriptObject::InitializeRandomizers which uses `_random` to initialize the randomizer
18:16:30 <TrueBrain> this means they are different before a save/load than after
18:16:36 <TrueBrain> this was slightly unexpected to me
18:17:12 <TrueBrain> I either expected `_interactive_random` there or those `random_states` to be saved
18:17:15 <TrueBrain> that is what I tried to say 😄
18:23:24 <Rubidium_> TrueBrain: InitializeRandomizers copies _random, and uses that copy of random to initialize them
18:23:56 <TrueBrain> yes; but `_random` changed between the start of the game, and when you save/load
18:24:02 <TrueBrain> so it has a different value in those moments in time
18:24:31 <TrueBrain> so `random_states` is different just before save/load than just after, if I understand this correctly
18:25:02 <TrueBrain> not saying it is wrong, to be clear; it was just unexpected 🙂
18:27:10 <Rubidium_> I think it's an "optimisation". I doubt there are any AIs that will return to the exact state as when they got saved. After all, we do not save their stack. So restoring their exact random state is kinda pointless. However, this way loading the game still yields reproducable AI results without having to save the AI's random state
18:27:43 <TrueBrain> Yeah, I ran into it as two things are different after save/load: the time till the next AI starts, and what AI starts
18:27:54 <TrueBrain> so when I ran the game, AI A started, but the save I made in between, caused AI B to start
18:28:09 <TrueBrain> again, just unexpected
18:29:08 <TrueBrain> the fact the AIs themselves do something different .. that is unavoidable either way 🙂 But there are these small things observable from just outside that 🙂
18:29:32 <Rubidium_> if you would use InteractiveRandom you'll have the same "problem"
18:29:45 <TrueBrain> no, that is not what I said (or tried to say :P)
18:29:52 <TrueBrain> I expected it to be either Interactive, or states stored
18:29:58 <TrueBrain> I get why you didn't go for the Interactive
18:30:05 <TrueBrain> but both my assumptions failed 😛
18:30:17 <Rubidium_> yeah, it's a bit of a hybrid
18:30:39 <TrueBrain> and it is completely fine for everything except `ScriptObject::GetRandomizer(OWNER_NONE)`
18:30:57 <TrueBrain> that is the only one you can observe from outside
18:31:13 <Kuhnovic> Is there something wrong with the github CI? I did a commit three hours ago but only 1 / 10 jobs actually ran...
18:31:29 <TrueBrain> I guess only storing that one in the savegame would solve my "issue". But really, again, just mentioning it was unexpected 🙂 If it happens more often, we might want to deal with it 🙂
18:32:11 <TrueBrain> Kuhnovic: seems you pushed a conflict
18:32:22 <TrueBrain> the CI runs on a merge from the PR content and master; but it can't create that commit
18:32:42 <Kuhnovic> Ah that makes sense, I didn't know it actually did a merge
18:32:55 <Kuhnovic> Alright, then I know what to do 😉
18:33:14 <TrueBrain> GitHub does that for all PRs on all repositories (unless you very explicitly avoid it), FYI 🙂
18:33:42 <Rubidium_> I've not looked at your PR, but is the next AI to run (and start date) stored in the savegame? Or do you expect that if the random state gets stored you will get the same?
18:34:15 <TrueBrain> Rubidium_: the time till a new attempt is made to start an AI, is stored in the savegame. Was already the case, remains the case
18:35:16 <TrueBrain> so before your PR, which AI started was random. Could differ with every load. After your PR, it is the same on every load, BUT it might be different from a savegame earlier (despite the AI starting at the same moment in time)
18:35:26 <TrueBrain> my PR doesn't change any of this behaviour 🙂
18:37:15 <TrueBrain> but wow, I have a hard time expressing myself so after dinner .. I blame the stupid regression-test issue I had 😄 😄 Anyway, I don't think it is an issue Rubidium_; I just wanted to let you know why I prompted you with questions about it 🙂
18:38:30 <Rubidium_> and at that time it will use the OWNER_NONE random to choose a new AI and a new start date for a next AI? Then on one hand it would indeed make sense to save it, but on the other hand... saving it for this precise reason seems a bit pointless because the AIs will have a different state and behave differently anyway. If scripts would be using the global random you'd probably have the same issue
18:39:52 <Rubidium_> though in the "there is not AI yet" case it could make some sense, but then again... cost vs benefit
18:39:59 <DorpsGek> - Update: Translations from eints (by translators)
18:40:08 <TrueBrain> it is a very niche problem to solve
18:40:21 <TrueBrain> like 0.0001% of the people will ever notice
18:40:40 <TrueBrain> with that I mean a 4 letter username starting with an S 😛
18:43:39 <Eddi|zuHause> they made a song about that guy :)
18:52:27 <TrueBrain> owh, right, autosave is an Option, not a Setting
18:55:18 <petern> Not an advanced setting, or a patch?
19:03:06 <glx[d]> Anyway the idea was to have reproducible AI start and decisions, a minor change between 2 openttd versions doesn't really break it
19:09:14 *** HerzogDeXtEr has joined #openttd
19:12:03 <TrueBrain> I really want to have access to more events .. had to look for a good place to reset the autosave counter .. think I found one 😛
19:14:12 <TrueBrain> okay, I think the autosave now happens every 10 minutes, how ever slow / fast your game might be
19:14:18 <TrueBrain> no longer under the influence of fast-forward 🙂
19:14:28 <TrueBrain> now ... to still save when paused, but not always 😛
19:14:39 <TrueBrain> I was thinking .. when any command is executed when paused, continue to count
19:16:58 <petern> What if you want it to be under the influence of fast-forward?
19:17:03 <petern> (Not that that is reliable any more)
19:17:22 <TrueBrain> why .. would you want that? 😛
19:17:48 <TrueBrain> There are a lot more complaints about it being under the influence of fast-forward, than people applauding the fact 😛
19:19:56 <TrueBrain> but here too, looking at the work of Tyler, doing it on a calendar time makes no sense (as you can freeze that :P)
19:20:28 <glx[d]> if paused wait for a command to reset the timer
19:21:19 <glx[d]> as the world won't change by itself
19:22:26 <TrueBrain> argh, here too, I want an event when pause changes 😛 Okay, I will shut up 🙂
19:24:12 <glx[d]> pause is a command too
19:24:45 <TrueBrain> glx[d]: not always used, however 😛
19:24:46 <glx[d]> so unpause or any other command will have the same effect, reset counter
19:25:20 <petern> Anyway, commands are basically events triggered from the command queue 😉
19:25:33 <TrueBrain> petern: and I want to subscribe to them!!! 😄
19:26:38 <glx[d]> ah yes CmdPause is only used for normal pause
19:27:38 <glx[d]> oh no it can handle all pause actions
19:28:09 <TrueBrain> I think I found a nice way to track if there was a command during pause 🙂
19:28:49 <TrueBrain> now to wait 10 minutes to see if an autosave happens .. euhm ...
19:31:00 <glx[d]> hmm I see manual _pause_mode changes only in afterload
19:35:08 <michi_cc[d]> Ah, today is another day of "destroying" the game, as it seems.
19:35:38 <TrueBrain> Reading up, I see? 🙂
19:36:41 <michi_cc[d]> Well, one needs to stay current to know what things one could get blamed for :p
19:37:04 <TrueBrain> given I got blamed for something I didn't touch with a stick, be sure you get blamed for today 😄
19:37:59 <TrueBrain> the command to pause causes the system to say: there was a command during pause! Darn it .. eeuuuhhhh
19:38:49 <glx[d]> at the end of CmdPause disable counter if still paused ?
19:43:21 <glx[d]> hmm but pause commands when already paused could mess up with the reenabling caused by other commands
19:43:49 <TrueBrain> awh, I can't access CommandType in the Post of commands .. hmm
19:46:35 <TrueBrain> okay, bit lost in the command handler .. there are two places that do `SubtractMoneyFromCompany`, and I don't really understand which one is called when 😄
19:47:24 <michi_cc[d]> `CommandTraits<Tcmd>::type`?
19:47:56 <TrueBrain> owh, right .. `Do` vs `Execute` .. what is the difference ..
19:48:36 <michi_cc[d]> Do: "This function is to be called from the StateGameLoop or from within the execution of a Command"
19:49:27 <michi_cc[d]> Execute: Worker for Post, which is for "player" commands to be queued (to network).
19:49:39 <TrueBrain> sorry, but that didn't help me at all 😄
19:49:45 <michi_cc[d]> I.e. Do = no network, Post/Execute network.
19:50:11 <TrueBrain> every time I look at this, it confuses me ...
19:50:14 <TrueBrain> why are there two flows?
19:50:26 <TrueBrain> (and this is a "me" problem, to be clear)
19:50:49 <michi_cc[d]> Because some commands internally use other commands, and they should not make a server round-trip for execution.
19:51:20 <TrueBrain> okay, so a check question: how you describe it, a player action in single player uses Do, not Post/Execute
19:51:24 <TrueBrain> do I get that right?
19:51:49 <michi_cc[d]> Better distinction: Post/Execute: synced via the server command queue; Do: local only, not network-synced.
19:52:07 <michi_cc[d]> Do: "This function must not be called from the context of a "player" (real person, AI, game script)."
19:52:10 <TrueBrain> so that is what I don't get .. why single player also doesn't go via Post/Execute 😛
19:52:31 <TrueBrain> see why this is confusing? 😄
19:52:44 *** MarkoMarko has quit IRC (Quit: User went offline on Discord a while ago)
19:52:51 <michi_cc[d]> The distinction isn't single/multi-player. It is player action or internally generated by other commands.
19:53:06 <TrueBrain> you keep bringing up "network-synced" 😄 😄 🙂
19:53:14 <TrueBrain> okay, so a player action always enters via Post/Execute
19:53:19 <TrueBrain> Do is just some internal blabla
19:53:24 <michi_cc[d]> Do may only ever be called from code that is lock-step desync safe basically.
19:54:17 <glx[d]> DoCommand vs DoCommandP in the lod time ?
19:54:18 <michi_cc[d]> Which most of the time are recursive commands triggered by a top-level command (which in turn has to go via Post).
19:54:40 <michi_cc[d]> Yes, Do is the old DoCommand and Post the DoCommandP.
19:55:20 <TrueBrain> Tnx michi_cc[d] ; I wouldn't have understood that from the comments, but this was enlightining 🙂
19:55:48 <TrueBrain> now let's test if it also actually works how I expect, having read all this 😄 Pam pam pammmmm
19:56:44 <TrueBrain> the painful part is waiting for 10s, and than 10s extra, as I cannot trust I can count to 10s 😛
19:57:51 <TrueBrain> finally autosaves when paused when you are building 🙂
19:59:07 <petern> Does it overwrite the last autosave because the date is the same?
19:59:21 <TrueBrain> glx[d]: solved that a while ago 🙂
19:59:40 <petern> Oh, they're numbered aren't they.
20:00:04 <glx[d]> numbered, and the start number is read on openttd startup
20:01:10 <glx[d]> used to always start at 0 on launch
20:01:56 <glx[d]> now it starts from the most recent autosave
20:02:55 <glx[d]> of course running more than 1 instances at the same time still causes mess
20:04:24 <TrueBrain> okay, this way of autosaving actually feels modern .. scary shit 😛
20:04:31 <TrueBrain> need to do two full rebuilds, but PR incoming 🙂
20:06:36 <TrueBrain> hmm, some more work I can backport into 10647, but okay .. I can't keep doing that 😛
20:13:36 <TrueBrain> much smaller change than I expected 🙂
20:14:06 <petern> Would be nice if you could do PR-dependencies
20:14:23 <TrueBrain> yeah ... and you can, if you make branches in the upstream repository
20:14:26 <TrueBrain> but you can't if you use a fork
20:14:44 <michi_cc[d]> We used to have Feture(ette) before we got proper PR checks 🙂
20:14:47 <TrueBrain> (with local branches, if you merge one PR, the other PRs automatically change from that branch to `master`)
20:15:18 <TrueBrain> but, another solution petern is to review 10647 😛
20:17:27 <TrueBrain> to me it is still an open question if we want OpenTTD to go this more event-driven direction for things like timers
20:17:33 <petern> That fact it is going to end the world is a bonus
20:18:01 <petern> GUITimers was my bad effort at decoupling things.
20:18:10 <TrueBrain> it made my work possible 🙂
20:18:23 <petern> GUITimers are dead, long live GUITimers.
20:19:31 <TrueBrain> LordAro: no, I didn't do any profiling. Can't imagine it having an impact, but I can give it a go
20:19:40 <TrueBrain> what would be the more fair approach .. an empty map would have the most impact I guess
20:20:29 <petern> It's only the gameloop timers that really matter I think.
20:20:57 <TrueBrain> yeah, and the highest resolution is once every game-day .. doubt we can measure the effect 😄 But I am going to try!
20:21:16 <TrueBrain> I keep mixing up lowest vs highest .. let me fix that in the comments ..
20:21:21 <TrueBrain> highest resolution is 1ms, not lowest ..
20:23:08 <LordAro> TrueBrain: one empty one "full" (title game?) seems appropriate
20:23:32 <LordAro> (one of the release title games, that is)
20:24:26 <petern> It is weird to see daily timers to set random windows dirty ... inside the window itself.
20:24:38 <petern> Because otherwise you'd not easily know that they get refreshed
20:24:53 <petern> Now it's obvious, though not entirely clear why they do get refresh.
20:26:17 <petern> I like that "OnHundredthTick" is going, because "Hundredth" is totally bollocks at this point
20:26:41 <TrueBrain> I really love locality of information; and that is what this PR actually does 🙂
20:26:57 <TrueBrain> instead of having to look in 20 files, you can just trust you have all information right there in that one little file 🙂
20:30:11 <TrueBrain> performance-wise I cannot detect any difference; so that looks good. One more test to see what the thread-sanitizer things of it ..
20:30:44 <petern> Wentbourne ... already slow as heck so you wouldn't notice 😄
20:35:33 *** Wormnest has joined #openttd
20:36:34 <TrueBrain> and ... another full rebuild
20:36:41 <TrueBrain> lol. But that hopefully is the last one 🙂
20:37:06 <TrueBrain> sneakily merging the last few changes from the other PRs into this one 😛
20:43:46 <TrueBrain> I looked at that diff so many times, I can't even tell if things are correct anymore; lol
20:49:53 <TrueBrain> auto-merge still scares me 😛
20:50:22 <TrueBrain> guess next job on the list is to fix a bunch more settings to be in actual seconds, instead of these weird ones ...
20:52:26 <Kuhnovic> Can somebody tell me what Check Annotations does? The output is... not helpful 😛
20:52:43 <TrueBrain> if you click on the summary of the CI, it will tell you all the annotations
20:52:47 <TrueBrain> basically, compiler warnings
20:52:56 <TrueBrain> TallTyler: I see you typing .. that is not not being on Discord ..
20:53:14 <TallTyler> TrueBrain: How do you know I wasn’t watching the PR with an itchy trigger finger on the merge button? 😛
20:53:28 <TrueBrain> TallTyler: I assume you have a life 😛
20:53:37 <TallTyler> That’s a bold assumption 😛
20:54:09 <TrueBrain> basically, that job failing tells us to look in the summary, as GitHub hides that pretty well 🙂
20:55:22 <petern> If you look at "files changes" from the PR, you'll usually see the annotations mixed in with the changes too.
20:56:10 <TallTyler> I went outside to catch a train downtown and meet my partner for milkshakes after she got off work, but while waiting had a phone call rejecting me for a dream job that I thought I had in the bag. So I’m back to Discord to distract myself. 😦
20:56:54 <petern> You mean being an OpenTTD volunteer isn't your dream job?
20:56:56 <TallTyler> I’ve been unemployed since December when my employer cancelled the project I was leading and laid me off. It just isn’t getting better
20:57:12 <TallTyler> If I could get paid to work on OpenTTD…
20:57:21 <TrueBrain> you could, but at what cost 😛
20:57:48 <TrueBrain> and I know the pain of being rejected .. had 3 jobs now that rejected without even so much as a call .. that you are like: really? REALLY? 😛
21:02:24 <TallTyler> I have plan B, C, and D jobs, of which C and D are pretty much guaranteed, so I’ll be fine. In order, they’re a software developer position, a job training track maintenance employees, and working at a science museum summer camp. But my plan A was a transit planner and scheduler, developing bus schedules and making my new home a better place. I’m perfectly qualified with my experience in railroad operations, and truly faile
21:03:35 <TallTyler> Oh well. Looks like maybe I can keep busy working on NoDL once the new timers get merged, or maybe start upstreaming automatic timetable separation — if I’m willing to juggle two projects and all the knowledge about how they work simultaneously 😛
21:06:56 <TrueBrain> here, some work for you 😛
21:12:33 <TallTyler> Good review, as always. I love having a senior dev to help me learn 🙂
21:13:10 <TrueBrain> hmm .. `_game_speed` has a data race .. oops 😛 Owh well, not a problem for now 😄
21:13:46 <TrueBrain> TallTyler: yeah, but it would be helpful if I had an actual opinion about the functionality 😛
21:13:55 <TrueBrain> I never really cared about the economy model of OpenTTD .. we have other developers for that
21:13:58 <TrueBrain> where is Celestar? 😄
21:17:42 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:42:49 <TrueBrain> Oof, const correctness .. I suck balls in that 😄 will fix that tomorrow 🙂
21:44:29 <petern> It is weird to see some game logic moved to timer_game_calendar.cpp
21:46:07 <TrueBrain> Only code to track the date I moved, not?
21:46:23 <TrueBrain> To decide whether it is a new day or not
21:46:45 <Kuhnovic> Hmm, this is odd. I'm doing some performance profiling in Visual Studio 2022. Some time is spent in the contains function of the tile area. But this a RelWithDebInfo build, so asserts shouldn't be compiled at all...
21:47:16 <TrueBrain> Asserts are always enabled, unless you explicit disable them
21:47:23 <TrueBrain> Doubtful you did that 😄
21:47:34 <TrueBrain> Check Options.cmake
21:47:38 <petern> There's a specific option to turn them off in the cmake config 🙂
21:48:22 <TrueBrain> We only disable them for non-beta releases btw
21:49:13 <Kuhnovic> Ah I knew there was something funky going on!
21:50:28 <Kuhnovic> I have to say that I have developed a new appreciation for asserts since I started developing for openttd
21:52:34 <TrueBrain> You love triggering them? 😄
21:56:45 <Kuhnovic> TrueBrain: Love is not the right term... but I seem to be good at triggering them! Especially YAPF has some real nasty ones
21:58:29 <Kuhnovic> petern: I guess that the philosophy of openttd has been "we don't have unit tests but at least we have a heck of a lot of asserts to keep stuff in check". I did see your unit testing PR, that is going to be good stuff.
22:09:51 <Eddi|zuHause> Kuhnovic: i think the philosophy was "we have regression tests, but defining "units" is maybe too time consuming
22:11:42 <Kuhnovic> Well it's a lot better than nothing!
22:14:14 <petern> > [E:/src/OpenTTD/src/timer/timer_game_calendar.cpp:95] (style) Condition 'IsLeapYear(_cur_year)' is always true [knownConditionTrueFalse]
22:14:20 <petern> I think that might be a lie...
22:14:36 <TrueBrain> Every year is a leap year!
22:17:11 <Eddi|zuHause> sounds like a good optimisation
22:20:04 <Kuhnovic> I added some truly random behavior when a ship is lost. It looks like a swarm of bees.
22:20:47 <petern> Did you fix the desync issues?
22:23:42 <Kuhnovic> The trick was to store the is-the-region-initialized-state to the savegame. That's all the information that is needed to rebuild the cache.
22:27:32 *** gelignite has quit IRC (Quit: Stay safe!)
22:50:47 *** sla_ro|master has quit IRC ()
23:38:13 *** Flygon has quit IRC (Read error: Connection reset by peer)
continue to next day ⏵
