IRC logs for #openttd on OFTC at 2023-04-08
⏴ go to previous day
00:08:35 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
01:08:30 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
02:15:38 *** Wormnest has quit IRC (Quit: Leaving)
02:58:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
07:03:22 <Rubidium_> The other question is answered in the last few paragraphs of https://wiki.openttd.org/en/Manual/Cargo, so the bits mentioning 1/8 and catchment areas. I think the numbers in your screenshot are for the whole HQ, so each tile has 1/4th the value
07:38:39 *** sla_ro|master has joined #openttd
08:03:16 <MnHebi> petern: If I recall correctly, that feature was not implemented cause it was basically a recording of done actions at a fixed resolution.
08:04:14 <MnHebi> It was less of a tutorial, more of a video recording where you watch the game do actions.
08:19:03 <andythenorth> lost my 50 year savegame
08:19:32 <andythenorth> stupidly reloaded the savegame
08:20:37 <andythenorth> I guess I have state drift between the GS and the grf
08:22:22 <andythenorth> my debugging tool is written in gs of course 😄
08:22:25 <andythenorth> so now I can't use it
08:22:38 *** HerzogDeXtEr has joined #openttd
08:24:09 <andythenorth> ha, what I _should_ do is fix my makefile
08:24:31 <andythenorth> so that it also installs the gs when it installs the grf 😛
08:26:47 <pickpacket> Rubidium_: thanks!
08:31:03 <andythenorth> hmm we'll never do train templates yes/no?
08:31:06 <pickpacket> Rubidium_: but any value above 8/8 in accepting cargo seems superfluous, doesn't it? If I understand correctly 8/8 means that a square on its own accepts cargo
08:59:33 <Rubidium_> pickpacket: yup, but the number on that page is for the whole HQ, so you get a quarter per tile and if only one tile is within the acceptance area it won't accept
09:03:58 *** gelignite has joined #openttd
09:45:15 <andythenorth> bulldozer RV, but the sprite is hidden when it's empty
09:45:30 <andythenorth> self-drive engineering supplies "delivery" to industries?
10:00:17 *** godbed is now known as debdog
10:04:45 <EmperorJake> Maybe? It should be faster when empty so that vehicles don't ahve to overtake an invisible vehicle
10:09:33 <andythenorth> how about max speed?
10:42:06 <Rubidium_> variant bulldozers?
11:22:51 <andythenorth> Variant Variants is needed
11:23:04 <andythenorth> Mode Switch in buy menu
11:42:49 * Rubidium_ wonders whether it's a bug that trains can go faster in and out depots where you see the back compared to those where you see the front?
11:45:25 <LordAro> that does sound like a bug
11:50:03 <TallTyler> andythenorth: Isn’t there an open PR for that?
11:55:56 <TrueBrain> Rubidium_: lol, how do we only find this out now? 😄
11:56:23 <TrueBrain> keeps surprising me, what kind of bugs we manage to find, even no, after .. almost 20 years 😛
11:57:48 <Rubidium_> because there are still a lot of magic numbers that are still (practically) unexplained
11:59:25 <Rubidium_> though this specifically now, because #10597 touches it and because of #10514 I'm way more aware of vehicle location off-by-one related issues
11:59:44 <JGR> The original patch as posted on the forums is full of bugs, so not worth turning into a PR directly
12:01:26 <petern> Yay the GS I had set up no longer throws an error 🙂
12:05:30 <petern> Hmm, it's Easter weekend, I've done my bike ride and it's the afternoon. Beer o'clock?
12:05:58 <EmperorJake> Is this a bug? When a town tries to grow along a road that doesn't allow houses, it builds a bunch of intersections to nowhere
12:08:47 <petern> Ah yes, there is bug that the flag that allows towns to build a road isn't checked when extending a road.
12:09:09 <petern> I had a PR for that, not sure if it was merged or not.
12:10:05 <dP> Rubidium_: It's quite a known issue that openttd movement logic is determined by pixels, not logic. So all curve lengths are wrong, reversing is wrong, movement is not continuous, etc. Depots having different entry is just one of the long string of issues caused by that.
12:12:05 <andythenorth> petern: Also lunch
12:13:04 <petern> I had lunch, and cake. :/
12:14:06 <petern> EmperorJake: Although that PR is to do with whether the town is allowed to build the road type, which is not directly the same as allowed to build houses alongside.
12:14:18 <dP> dP: changes like #10597 is just like throwing things at the wall in hope it sticks imo
12:14:46 <andythenorth> I had an idea for a new depot tool: click on a specific vehicle and another instance of it is purchased and inserted to the train immediately after the vehicle that was clicked on
12:15:24 <dP> andythenorth: you mean changing consist outside the depot?
12:15:36 <petern> #10598 has a little more basis considering the deltas are different depending on direction, but yes, #10597 is just random.
12:16:06 <JGR> It would make more sense to just add more checks to the train collision detection code
12:16:11 <dP> ah, or clicking in the depot... like clone wagon tool
12:17:17 <andythenorth> dP: No I mean extending train in depot without having to hunt in buy menu for which vehicle 🙂
12:17:19 <JGR> Crashes are so rare that you can add as many checks into the collision potentially detected path as required without any performance hit
12:18:00 <dP> andythenorth: kinda niche imo
12:18:09 <dP> you have to hunt through to buy the first one anyway
12:18:20 <dP> so more of it doesn't rly matter
12:18:40 <dP> unless you want to do it to an old train that you sent to the depot
12:18:48 <petern> When you set up 20 templates you'll have to hunt them too
12:18:51 <dP> but that rarely happens, at least in my game
12:18:58 <petern> And come up with names.
12:21:39 <andythenorth> dP: Yeah that’s the case. Upgrading trains to longer TL
12:22:25 <andythenorth> Can’t see how templates would ever work, so thinking of alternatives
12:23:07 <EmperorJake> petern: Yes but there's no reason to ever allow towns to build a roadtype that disallows houses
12:23:12 <dP> I guess it would be nice feature to have but hardly a game changer
12:23:35 <dP> upgrading anything more than just a few trains that way is still a royal pita
12:23:40 <EmperorJake> andythenorth: That would be useful, especially for when you have half a dozen different MU wagons and you have to find the right one
12:24:56 <EmperorJake> JGRPP template replacement works ok, but it could be streamlined a lot
12:24:56 <andythenorth> Templates will never work because playe base
12:27:53 <TallTyler> petern: There's an unresolved review comment blocking it, otherwise it looks good to me. The intersections to nowhere are annoying 🙂
12:34:11 <petern> I've probably been playing too much Doom instead of looking at PR comments 🙂
12:35:46 <petern> `Order *o = new (i) Order();` What is this syntax?
12:36:02 <petern> `i` is a size_t counter in this instance.
13:00:02 *** WormnestAndroid has quit IRC (Remote host closed the connection)
13:00:10 *** WormnestAndroid has joined #openttd
13:28:03 <glx[d]> petern: but debug log should be noisy 🙂
13:39:33 <andythenorth> was it coffee time?
13:42:00 <andythenorth> oh I have confused Variants somehow
13:42:34 <andythenorth> only one variant available right now, but it shows the disclosure widget
13:49:41 <EmperorJake> I thought that was intended, because you can make a variant available before the main vehicle
14:05:37 <TrueBrain> TallTyler: just glancing over it, isn't the issue that AILoadConfig is done after your patching?
14:06:40 <TrueBrain> btw, start_date is incredibly weird .. I fully regret how I (and Rb? Can I just blame him? :P) implemented it .. it is ridiculous ...
14:08:57 <TrueBrain> I am really tempted to follow up your PR by just removing the per-`ai_config` `start_date`, and making a single setting: Start AI NNN seconds after last
14:09:19 <TrueBrain> I am sure we debated that before, just not sure why we haven't done it yet .. as in, not sure if it was just: meh, it is there now, or if there was some actual reason 😛
14:09:41 <TrueBrain> glx[d]: what do you think? Should we just do away with the "per AI `start_date`" weirdness?
14:10:11 <glx[d]> just use a delay between start
14:10:18 <TrueBrain> (the idea, at least, what comes to my mind, was that this allows you to have 2 AIs start quickly, and another 2 AIs a long time after that .. it just .. it doesn't work :P)
14:11:27 <glx[d]> handling the special parameter just adds complexity for no real benefit
14:12:21 <glx[d]> I think samu opened a PR for that
14:13:57 <TrueBrain> good, so we agree; I will see if I can find some time to address that tomorrow, if you don't beat me to it 🙂
14:14:29 <glx[d]> your turn to touch internal script code 😉
14:15:08 <TrueBrain> and call myself names while doing so 🙂 Sounds fair 🙂
14:15:39 <glx[d]> I broke enough with the string validation
14:17:19 <glx[d]> I didn't expect so many GS to do weird things with strings
14:17:46 <glx[d]> most were just doing things after trial and error
14:18:12 <TrueBrain> yeah .. we didn't do the best work explaining how to use it 😄
14:18:26 <TallTyler> In that case I’ll drop that temporary commit and wait for one of you to add a global delay setting. If we could merge that at the same time as my PR we could even avoid having to do any conversion, since nobody would have a chance to generate a config file with the old values, right?
14:19:05 <TrueBrain> so that solves two problems 🙂
14:19:55 <glx[d]> and it might simpler to try to prevent starting more AIs than allowed after that
14:21:04 <TallTyler> I’ll still have to do setting conversion for linkgraph updates, so it doesn’t save any saveload or config versions though 🤷
14:21:29 <TrueBrain> remember, versions are cheap 🙂
14:21:40 <TrueBrain> you also suggested to combine multiple upgrades with a single version bump .. that really is not needed
14:21:47 <TrueBrain> those numbers can get REALLLLYYYYY big 😛
15:01:03 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:03:20 *** WormnestAndroid has joined #openttd
15:41:53 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:42:36 *** WormnestAndroid has joined #openttd
15:44:28 <andythenorth> ^ needs a grf var? 😛
15:46:38 <TallTyler> It's intended for the GRF author to use it for accurate helptext, though, not to negate the player's choice by doing its own scaling in the reverse
15:47:10 <andythenorth> string code for {ADJUSTED_TIME_INTERVAL} instead?
15:47:13 <andythenorth> with formatters? 😛
15:48:20 <andythenorth> I tell you how many cycles I have, you tell me how many game days / weeks / months that is?
15:49:07 <TallTyler> Hmm, could be helpful
15:52:49 <andythenorth> it's quite a narrow / niche case
15:53:04 <andythenorth> but actually "but grfs" has always been one of the objections to daylength
15:53:22 <andythenorth> and possibly handling some common cases in a separate PR might be helpful
15:56:13 <TallTyler> Can you make me a wishlist/problem list?
16:02:03 <nielsm> actually, NewGRF industries will also have odd text for realtime patch, right? "must deliver cargo within 3 months" in the status window (but it should be 3 minutes)
16:03:13 <TallTyler> Yes, they'll already be wrong, but they'll gain access to the {RTS} string code and maybe the unit conversion codes as well
16:03:25 <TallTyler> So the actual interval won't change
16:09:07 *** lobstarooo has joined #openttd
16:09:57 *** lobstarooo_ has joined #openttd
16:09:58 *** lobstarooo_ has quit IRC (autokilled: This host violated network policy. Mail support@oftc.net if you think this is in error. (2023-04-08 16:09:57))
16:12:15 <andythenorth> petern: wondering if GPT can do it
16:13:28 <andythenorth> I do not hope for much
16:14:01 <andythenorth> this is how LSA and LSI works
16:17:12 *** lobstarooo has quit IRC (Ping timeout: 480 seconds)
16:17:45 <TallTyler> TrueBrain: Since you offered to help, I found a side quest which needs solving before NotDaylength can be merged:
16:19:17 <nielsm> having autosave run in wall clock time regardless of pause state and game speed will also help with cases where the player has build-while-paused enabled and builds a ton of stuff and then loses power
16:20:31 <JGR> If a player pauses the game and then goes off to have lunch, they probably don't want all their existing autosaves to have been overwritten by the time they get back
16:23:34 <petern> Track if a command was issued (and processed) in pause since the last autosave.
16:25:14 <TrueBrain> TallTyler: sure; one of the things on my wishlist anyway. Similar for network timeouts .. they really all should be actual seconds
16:25:17 <TrueBrain> not those silly ticks
16:25:20 <TrueBrain> will give it a go tomorrow
16:25:41 <TrueBrain> and yes, what petern says is the easiest solution for that issue 🙂
16:26:44 <TallTyler> Merged that for you so I can fix all my PRs that use a saveload version and are now out of date 🙂
16:27:50 <TallTyler> Thanks for making unit conversion even more complex, for when I have to deal with `tiles/day -> tiles/sec` 😛
16:28:10 <TallTyler> Progress is so annoying 😛
16:29:40 <TrueBrain> For #10607, it really should be a constant. Not yet-another-setting-for-people-to-thinker-with-and-we-have-to-support-till-the-end-of-time
16:29:49 <TrueBrain> it also makes little sense to use that value to alter behaviour
16:31:28 <TrueBrain> so far the arguments against are emotional ones. Which is what we see often ofc, as people are afraid "their game(style)" will be altered (understandable). But I think in this case with the work you set in motion, that isn't an actual issue
16:33:17 <TrueBrain> as our community tends to be ... volatile is the right word I guess, it might be good that we write up some blog about what we are thinking about, and what way this is all heading. Just so people can read the bigger picture, instead of point to a local change and say: BAD 🙂
16:33:38 <TrueBrain> similar for the related PRs, ofc 🙂
16:34:01 <andythenorth> some community engagement? 🙂
16:34:05 <andythenorth> a little consultation ahead of time?
16:34:22 <andythenorth> if you make this too close to my day job, I might have to take a break 😛
16:34:34 <TallTyler> Agreed on all counts. I'm expecting to receive a lot more vitriol on this project as it moves forward, so maybe I'll write an explainer post to head off some of the hate
16:35:09 <TallTyler> Only once we're committed to taking the change seriously, though, we wouldn't want to promise a new feature and never deliver it 😛
16:35:36 <andythenorth> that was the advantage of having NRT in a weird branch for a very long time
16:35:39 <andythenorth> but with official builds
16:36:01 <TrueBrain> andythenorth: really? How did that work out in the end? 😛 😛 😛
16:36:05 <TrueBrain> sorry, that was an easy troll 😄
16:36:12 <JGR> As much as more settings are considered poor form, they're an easy way to make people stop moaning
16:36:37 <andythenorth> TrueBrain: why have you mentioned NRT? You should know we don't mention NRT.
16:36:54 <JGR> "Just turn on the spacebar heating setting" is much quicker than having to respond to endless comments
16:37:22 <TrueBrain> JGR: very true; but also often means a game loses its identity a bit 🙂
16:37:40 <TallTyler> Easier in the short term, I'd imagine harder in the long run
16:37:52 * TrueBrain looks at the YAPF settings ....
16:38:10 <TrueBrain> but yeah, there is a balance 🙂 It isn't left nor right 🙂
16:38:46 <TrueBrain> in that sense I envy JGR for having his own patchpack .. it makes an opinion a lot easier 🙂
16:39:40 <JGR> Not having to get anyone's approval to add stuff is nice, but of course I get to keep all the pieces when it breaks
16:41:12 <TrueBrain> What OpenTTD always reminds me of, is World of Warcraft, when it comes to these things
16:41:19 <TrueBrain> they dumbed down the game -a lot- over the years
16:41:24 <TrueBrain> which meant a lot more people started to play
16:41:29 <TrueBrain> but a core was always: IT IS TOO EASY
16:41:39 <TrueBrain> so they resold their old game AGAIN to those people, so they could have the "harder" game
16:41:51 <TrueBrain> to slowly update it again to "easier" variant
16:42:07 <TrueBrain> as the "hard mode" dies out after a while ..
16:42:29 <TrueBrain> they found such a weird circle to go around in ... and I still can't believe people actually buy the game AGAIN 😛
16:43:36 <TrueBrain> but yeah, in general I rather have that more people can play OpenTTD, with the risk of us losing the "hardcore" players, then going into the niche of only serving the "hardcore" players 🙂
16:44:20 <andythenorth> Eddi usually reminds me of the 10% 10% 10% rule
16:44:43 <TrueBrain> and if people strongly disagree .. they can make a "vanilla" version of OpenTTD, and start their own circle 😄 (just my opinion, mind you)
16:44:45 <andythenorth> in my day job, we found years ago that 10% of visitors register to post on a community site
16:44:58 <andythenorth> 10% of those return / post regularly
16:45:05 <andythenorth> 10% of those regular posters post obsessively
16:45:09 <andythenorth> and dominate the conversation
16:45:52 <andythenorth> and some fraction of that last group are a pain in the arse
16:45:59 <andythenorth> green ink brigade
16:56:12 <andythenorth> ok think I've just about achieved my FIRS dreams
16:56:34 <andythenorth> "I heard you like steel" -> 10 kinds
16:57:14 <andythenorth> first person to say I should be playing Factorio instead wins a prize
16:58:54 <TallTyler> Why is Food included?
16:59:29 <andythenorth> petern: I haven't decided yet, it will be contextual to who says it 😛
16:59:36 <andythenorth> and whether I respect their lolz, or no
16:59:46 <TallTyler> You can just disable the Food requirement for town growth, no?
16:59:57 <TallTyler> Or are you thinking compatibility with growth scripts?
17:00:11 <andythenorth> intent is for the FIRS GS to require town goods, yes
17:00:20 <andythenorth> and also there are farm supplies generated in the chain
17:00:47 <petern> In theory a cargo with a town effect of food should work, but whether it does is another matter.
17:00:58 <andythenorth> should I show the industry cargo chains view?
17:01:35 <andythenorth> it's a thing of beauty
17:01:59 <TallTyler> I think I've tried other cargos to require growth, but just decided a GS is better, since towns don't know or care how much you deliver. One truckload a month is better than a big train delivery every so often
17:02:05 <petern> Unchunky bevels there...
17:02:25 <TallTyler> Or just a huge window
17:02:35 <TallTyler> They look regular chunky to me
17:03:10 <petern> Ah not bevels, the lines.
17:03:27 <andythenorth> although it's also worser
17:03:35 <andythenorth> but we can rebuild him, there's a draft gist about it
17:03:40 <petern> Maybe I should try playing Elite again.
17:03:52 <andythenorth> should I ask GPT who wrote it?
17:04:00 <andythenorth> it might think it's Andrew Hutchings
17:04:37 <petern> Nah, everyone knows it's Chris Bell and Ian Braben.
17:05:26 <petern> Hmm, tomorrow might be a trike day. I've not ridden that for a while.
17:16:56 * andythenorth plays more OpenTTD
17:24:10 <TrueBrain> TallTyler: your motivations are getting a bit old 😛 😛 😛
17:24:17 <TrueBrain> But your description is mostly the motivation 😄
17:25:06 *** tokai|noir has joined #openttd
17:25:06 *** ChanServ sets mode: +v tokai|noir
17:29:07 <TallTyler> I don’t want to tag you each time “TrueBrain said”
17:29:28 <TallTyler> Copy and paste is easy
17:30:01 <TallTyler> And I’m going for “people can read this in the future” not “TB will read this in 10 minutes”
17:30:22 <TallTyler> No idea if people will read these little ones though
17:30:26 <TrueBrain> yeah, that is what triggers me about the motivation .. it is not useful in 1 year 😛
17:30:35 <TrueBrain> But I like the motivation: Magic numbers are bad!
17:30:38 <TrueBrain> that is good enough for me 🙂
17:30:58 <TrueBrain> on a more serious note, you really triggered my OCD with max/def/min 😛
17:31:31 <TallTyler> Yeah, I don’t know how that happened. I had to look to see that it wasn’t how they were originally ordered
17:31:53 *** tokai has quit IRC (Ping timeout: 480 seconds)
17:32:09 <glx[d]> accidental alt-click maybe
17:32:31 <glx[d]> or whichever special click in VS
17:32:43 <TrueBrain> it is also not sorted
17:32:47 <TrueBrain> so why would VS do that? 😛
17:33:00 <glx[d]> there's a click to invert 2 lines
17:33:10 <TrueBrain> but it is double inverted 😦
17:34:07 <glx[d]> though maybe it's not specifically to invert 2 lines, but that's the effect I get when I use the wrong combo
17:34:41 <glx[d]> or it is to drag lines without selecting them before
17:35:24 <TrueBrain> I like that you try to reason TallTyler 's weirdness 😛 (just joking, to be clear :D)
17:39:26 <TrueBrain> now that is an easy PR 😄 😄 😄
17:41:22 <andythenorth> do we have a NoDL branch and build?
17:41:50 <TrueBrain> most of the work is non-intrusive, so that should go to master for sure
17:49:53 <TrueBrain> haha, I see TallTyler 's OCD is worse than mine 😄
18:05:12 <TrueBrain> petern: something like a zombie? 😄
18:05:41 <petern> Am I talking about the game from 1992, or... comments about PRs?
18:06:12 <TrueBrain> "We will tell you, after these advertisements!"
18:06:35 <TrueBrain> it is funny to me that speedrunners still find ways to get faster in doom
18:06:42 <TrueBrain> like .. why are you ... still trying?
18:12:44 <petern> Oh. Accidental secret exit discovery
18:13:59 <TrueBrain> right, that PR needs a bit more attention than just looking at it while playing Path of Exile 😛
18:35:45 <TallTyler> ^^ that one is now just `Codechange: Add a property to graph windows for whether to draw dates` 🙂
18:36:04 <TallTyler> All broken up into separate PRs for TB 😄
18:36:05 <TrueBrain> michi_cc: as I haven't seen the other C++ knowledge base around the last few days, maybe you know: does the STL provide any form of thread-pool already in C++? Or does it require a custom implementation (I know there are a few header-only ones out there that seem decent)
18:36:25 <TrueBrain> TallTyler: it really is appreciated 🙂
18:36:53 <TallTyler> I'm glad you suggested it, it's much easier on my end too 🙂
18:38:44 <JGR> TrueBrain: It's not very much code on top of std::thread. The hard part is deciding what the policies should be, which is a requirement no matter which implementation you use.
18:38:51 <TrueBrain> LordAro: 3 years ago .. lot has changed 😄
18:39:10 <TrueBrain> hahaha, sorry, should have pinged you too JGR 😄
18:39:30 <TrueBrain> I remember there was some work in this area in STL, but couldn't really find how the implementation was doing
18:39:36 <LordAro> the amount of usable c++ we have hasn't changed :p
18:39:42 <TrueBrain> coroutines seem to not really use a pool in all compilers .. just some ..
18:40:27 <TrueBrain> I might "borrow" that JGR ; seems to do what I am looking for 🙂
18:43:54 <TrueBrain> I always hate when I cannot see (by reading) if a variable remains undefined or not 😛
18:44:01 <TrueBrain> too many ways in C++ to do things wrong ...
18:46:25 <DorpsGek> - Update: Translations from eints (by translators)
18:53:41 <TrueBrain> now that at least reads a lot more natural
18:53:47 <TrueBrain> still no clue what is going on with those other variables ..
18:54:12 <TrueBrain> feels like "Base" isn't as Base as it suggests it is 😛
18:54:18 <TallTyler> Call it out of scope and worry about it later? 😛
18:54:37 <TrueBrain> yeah, okay, if `draw_dates == false`, in those cases the other variables are read
18:54:59 <TrueBrain> that is just ... yeah, someone was either lazy, or something else is going on, but this is just weird OO 😛
18:55:24 <TrueBrain> basically the Base class has 2 draw modes
18:55:32 <TallTyler> The `this->month == 0xFF` sounds lazy to me, but what do I know? 🤷
18:55:43 <TrueBrain> but this isn't SOLID, to say the least 😛
18:56:23 <TrueBrain> but yeah, out of scope for your PR to fix the actual problem here 😄
18:58:06 <TrueBrain> a typical: open the door, look inside, slowly close the door, walk away!
19:01:36 <petern> To summarize, "a game which was too slow to be playable will be too slow to be playable". Got it.
19:04:03 <dP> it will become unplayable faster
19:04:42 <Eddi|zuHause> do we have a row of people complaining that the game isn't optimized... like certain other simulation games?
19:05:13 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:05:20 <andythenorth> to aid my small brain: why 27 better than 30?
19:06:17 <TallTyler> To match real time, so 1 day = 2 seconds, 1 month = 1 minute
19:06:22 *** michi_cc[d] has joined #openttd
19:06:22 <michi_cc[d]> TrueBrain: There was a plan to get Executors into C++23 (which is basically the thing that makes threads/tasks usable in the first place), but it doesn't look like it will be in C++23. Which means that most of the async and coroutine stuff will still need extra libs.
19:07:27 <TallTyler> jfs-: Is changing TICKS_PER_DAY a viable alternative to match real time, and would it be any better? I'm probably overlooking something obvious. 🤔
19:07:29 <TrueBrain> michi_cc[d]: meh; tnx 🙂 Couldn't find anything about it in the C++23 overviews, but that might explain it 😛
19:08:54 <dP> TallTyler: why do you even need to match real time, how is having 1800 ticks per minute significantly different than 1980?
19:10:11 <nielsm> TallTyler: IMO not really, no.
19:11:12 <andythenorth> because it makes neat maths?
19:11:50 <nielsm> the big issue with changing number of ticks per day is that you change how far vehicles can move in a day and how much is industries produce per month etc (because the production cycles run on 256 tick increments), but also how running costs etc are calculated, so you end up changing game balance with that
19:12:04 <petern> And it fixes a bug that OpenTTD uses the wrong value compared to TTD.
19:12:04 <TrueBrain> JGR: funny that viewport worker pool 🙂 Did you ever measure how much performance gain that gives for drawing the screen?
19:12:23 <Eddi|zuHause> there were people who wanted to match the 24h clock with the daylength, so 1 day clock time is 1 day calendar time
19:12:37 <TrueBrain> I have some early attempts of reworking how the viewport works, so it can run mostly outside the game-thread; but you seem to just scale it out. That is also a nice idea 🙂
19:12:39 <nielsm> 1998 ms per day is also basically the closest to 2000 you can get without changing everything wildly
19:12:40 <dP> petern: a bug that no player noticed :p
19:14:19 <petern> We fix lots of bugs that no player notices.
19:14:20 <andythenorth> anyone measured why FIRS kills the FPS? 😛
19:14:21 <TallTyler> dP: Because the real-time mode is the only way to use this implementation of calendar scaling
19:14:37 <TallTyler> FIRS actually makes a huge difference on my debug builds
19:15:18 <TallTyler> Fast-forward sometimes does nothing if I have vehicles in the world too
19:15:29 <JGR> andythenorth: Many of the industries have animated tiles which are not actually animated, some of the callbacks are a bit expensive
19:15:55 <JGR> I have some optimisations in my branch aimed at FIRS
19:16:24 <JGR> TallTyler: FIRS doesn't trigger that issue
19:17:33 <TallTyler> Was the Master Hellish game using FIRS?
19:17:49 <dP> not the one I'm talking about
19:19:02 <dP> and it ended in 1988 so vactrain is just for lolz
19:19:06 <andythenorth> TallTyler: JGR I could address that, tends to be that I try to minimise tile ID useage
19:19:13 <andythenorth> JGR: I could address that, tends to be that I try to minimise tile ID useage
19:19:33 <JGR> TrueBrain: It has the most effect when zoomed out (but not in the map rendering mode), doing a quick test with and without the threading, it shaves off about a quarter
19:19:40 <andythenorth> although I'm not close to running out yet, but splitting animated / non-animated tiles would potentially consume a lot
19:19:48 <TrueBrain> JGR: not bad; I like the approach 🙂
19:20:14 <andythenorth> yeah 183 tile IDs used, 70 remaining
19:21:44 <JGR> I'm turning off animation for the parts of the overall layout which are never animated
19:22:08 <andythenorth> have we looked at what nml is compiling?
19:22:22 <andythenorth> iirc, for animated tiles, it substitutes sprites for every animated step
19:22:28 <JGR> NML codegen is pretty dire, but that's not just an industry set problem 😛
19:22:39 <andythenorth> I have to give it a list of sprites for each animation frame
19:22:47 <andythenorth> so I presume it has a big varaction 2 stack somewhere
19:23:17 <andythenorth> I don't know if any sprites are cached, but that would probably destroy any caching
19:25:42 <JGR> It was a while since I looked at this, but I remember that unnecessarily marking the screen dirty all the time had a noticeable cost
19:28:30 <dP> nielsm: and why does the length of a day matter when there are no days anymore?
19:29:01 <LordAro> dP: on a related note, you realise your JGR rendering PR is completely unmergable? you've just squashed all the commits together
19:29:10 <dP> TallTyler: as I understand it you replace all the time units completely so why do you need to change the length of an old unit you don't use anymore?
19:29:10 <LordAro> i'm not quite sure what it was supposed to achieve
19:29:49 <dP> LordAro: so? they're mostly just fixes for the main comimt
19:30:27 <dP> it was supposed to achieve that cmclient now has better tracking
19:31:00 <nielsm> dP: the lengh of days in ticks matters because it affects the balance between income and running costs
19:33:40 <nielsm> if you make a day last fewer ticks then running costs will be drawn more frequently (months are fewer ticks) and there will be more days between cargo production too, that's two factors so my intuition says it's an exponential increase in difficulty
19:33:45 <dP> how? just keep their calculation at the same tick rate
19:33:59 <nielsm> then you haven't changed the day length in ticks
19:34:00 <dP> it's not like realtime has 365-366 days in a year anyway
19:34:48 <nielsm> then you're just doing exactly what Tyler's patch does, decouple the economy calendar from the logic calendar
19:35:22 <nielsm> but when you do that then you have the issue of having two different scales running in parallel, so you need units of measure for each of those scales
19:36:06 <nielsm> and that's where it makes sense to use real-time units for the scale that does not change, which is the economy scale of time
19:37:56 <nielsm> you cannot change the number of ticks in an "economy day", because that changes the game balance, but you can change the amount of time one tick takes, and by adjusting that you can get the value of 1998 ms per "economy day" which gives the very convenient 2 seconds = 1 economy day measure
19:39:10 <nielsm> the only negative I can see is what I wrote on github, that speeding up the passage of economy days will give a slight advantage in multiplayer to experienced players with fast reaction times and good intuition
19:40:03 <Eddi|zuHause> and which target audience is that?
19:45:20 <dP> I'm talking about Tyler's patch already. And still don't get what you say. If you want "economy day" to last 2 seconds, just make it whatever amount of ticks that takes, why change the tick rate?
19:45:48 <andythenorth> because tidy maths?
19:46:08 <dP> tidy maths is a bad reason to change tick rate :p
19:46:18 <petern> Changing the length of the economy day (74) changes way more things.
19:46:22 <dP> computers are strong, computers can into untidy math
19:46:46 <nielsm> because changing the number of ticks per economy day changes the game balance, but changing the number of milliseconds per tick does not change game balance
19:47:32 <nielsm> and here I mean game balance as how much profit a given transport system will provide
19:48:29 <dP> balance is determined by relative tick rate of the events
19:48:32 <andythenorth> I find it difficult to care enough about this
19:48:52 <dP> I wouldn't care if that could be disabled with no consequence
19:50:13 * andythenorth back to playing OpenTTD
19:50:18 <andythenorth> this is a dull debate
19:51:48 <dP> nielsm: with reltime units you have production/minute instead of per month, as well as running costs and train speed per minute or whatever. as long as ration between them is the same balance will be the same
19:52:09 <nielsm> dP: so you want to change the 256-tick-production for houses and industries to no longer happen every 256 ticks and change the monthly production changes for industries to no longer happen every 30 economy days but instead every 34 economy days?
19:52:24 <dP> doesn't Tyler already change that?
19:54:59 <nielsm> well the economy year is shortened from 365 days to 360 days = 1.4%, while if you changed the ticks per day to 67 you would have a 9.5% change in other factors
19:56:11 <nielsm> and normalising the economy months and year to 12 months of exactly 30 days if nothing else makes everything more regular
19:58:18 <dP> wait, just a quick sanity check, does January still have 31 days in Tyler's patch?
19:59:34 <nielsm> normalising the economy year like that is a much smaller overall change to the game balance than changing many more variables to shorten the number of ticks per day and try to keep everything else mostly the same
20:00:54 <dP> it's not about game balance, it's about sanity
20:01:15 <dP> January has 31 days, February 28 or 29, no game balance has any right to change that
20:02:25 <nielsm> january, february, march, april, may, june, july, august, september, october, november, december, they're all deleted and gone and replaced with minute 1 to 12 of each period
20:02:41 <nielsm> assuming you play with the real-time setting enabled
20:03:15 <nielsm> except they still exist on the calendar that the technology advancement of the world obeys
20:03:56 <nielsm> it's just that the way your company's finances are managed no longer run on the same calendar that the one the vehicle manufacturers use to decide when to introduce a new model
20:07:05 <nielsm> this chunk says that january has 31 days
20:08:25 <dP> I know it worked fine before
20:08:29 <andythenorth> hmm game passes too quickly, might have to use the date cheat
20:08:35 * andythenorth playing the game
20:12:05 *** bryjen has quit IRC (Quit: Leaving)
20:13:39 <TallTyler> Days per month depends on real-time mode. If you’re not using real-time mode, the only thing that changes is the milliseconds per tick. If you enable real-time mode, every month has 30 days.
20:14:23 <TallTyler> Because 30 days * 2 seconds per day = 1 month per minute
20:14:25 <dP> dP: I enabled real-time here and it still shows me normal calendar
20:15:18 <TallTyler> Normal calendar is used for most displays, because role play of vehicles and stuff. Real time units show up in finance sheet, town and industry windows, etc
20:15:58 <TallTyler> Yes, in real-time mode the calendar you see is still correct
20:16:45 <TallTyler> Economy date ticks along at the same speed (dates change at the same time) but won’t match day of the week, month, year, etc with the calendar date
20:17:55 <nielsm> is there anywhere to see the economy clock right now?
20:17:58 <TallTyler> I guess it changes game balance ever so slightly because payments happen slightly more often (360 days per year vs 365)
20:18:09 <TallTyler> No, the player can never see the economy date
20:19:17 <TallTyler> The places where economy date has a concrete date (timetable arrival/departure times and last service date) are now relative, e.g. “Last serviced: 5 minutes ago”
20:22:42 <TrueBrain> JGR: haven't really looked into it, but your worker-pool doesn't actually seem to pool for me. It only wakes up a single worker, instead of as many workers as possible. I think this is because you only seem to wake up a worker if the queue is empty. But if I fill it quick enough, it isn't empty, so not all workers are woken up
20:22:52 <TrueBrain> it might be purely my usecase, and that it works fine for you
20:22:56 <dP> anyway, did I understand it correctly that you want 1 month = 1 minute because you want to run monthly loop every minute?
20:22:59 <TrueBrain> just wanted to let you know, in case you notice similar issues 🙂
20:23:07 <dP> and daily loop 30 times in "month"
20:23:48 <dP> ok, now the question is what are these loops doing that they can't be run on different period
20:24:03 <TallTyler> Yearly loops happen every 12 minutes and the yearly bookkeeping periods for vehicle and group profits, company stats, etc, are called Periods
20:26:02 <dP> only potential issue I see is engine monthly loop. companies, towns, stations and industries seem to be doing nothing that would matter
20:26:07 <TallTyler> Changing the loop interval would change the game balance, primarily, but using easily describable amounts of time is crucial for players to understand things. If it’s not real-time we need to display two date systems simultaneously, which would be confusing. I tried that previously.
20:26:18 <TrueBrain> JGR: but in other news, I can now run a 4096x4096 rather smooth on my machine; finally my OpenTTD runs multiple threads constantly 😄
20:26:19 <nielsm> if you change only the number of ticks per day, to e.g. 67 ticks of 30 ms to get 2010 ms per day, then the result is that there are more days between cargo production, and fewer ticks between running cost and interest payments, making the game harder
20:26:56 <nielsm> and if you then change the periods of all those other things, they you end up with really weird numbers that are even more difficult to explain in the UI
20:27:14 <dP> nielsm, just calculate running cost on tick based rate, no?
20:28:32 <dP> or scale them to whatever interval needed
20:28:44 <nielsm> then you have "running costs per 33.1 days"? good luck making that understandable for the player in the UI
20:29:34 <nielsm> the goal of the real-time (NoCalendar) concept I described and Tyler implemented is to decouple things and run the economy on a fixed that that is _easy to describe in the user interface_
20:29:45 <nielsm> the user interface is absolutely critical to the entire concept
20:29:47 <dP> no, just cost per period, like they already are
20:30:23 <dP> though I've no idea what "period" in the interface is meant to represennt
20:30:58 <TallTyler> I absolutely welcome suggestions for that
20:31:01 <TrueBrain> lol, from 50 frames/s on FFWD, to 300 frames/s on 4kx4k .. curious when this is going to break ...
20:31:03 <glx[d]> 12 minutes if tick is 27ms long
20:31:15 <petern> Just a reminder that dP isn't our final approval officer 😉
20:32:19 <nielsm> dP: a time unit is still required that approximately is the same as a traditional year
20:32:27 <dP> just a reminder that peter1138 plays doom, not openttd :P
20:32:39 <petern> The frame rate is higher.
20:33:07 <petern> 28.5 milliseconds per tick for Doom.
20:33:10 <JGR> TrueBrain: Hmm, I will have to look into this more but I think you are right
20:33:30 <dP> multiply by 5 and you have hour
20:33:47 <TrueBrain> JGR: I just dropped the `if (notify)` part. means sometimes a worker wakes up to find no work for him, but I don't really care about that 😛
20:33:54 <nielsm> dP: length of subsidies, for example
20:34:16 <dP> or whatever equivalent of 5 in the normal tick rate is :p
20:34:25 <dP> what''s wrong with subsidies in minutes?
20:34:43 <TallTyler> Subsidies are in minutes actually
20:34:58 <TallTyler> The real issue is the company finance window. What do you call each period?
20:35:07 <TallTyler> Because they are labeled
20:35:09 <nielsm> hm what is the loan interest % in, isn't that per year?
20:35:30 <TallTyler> In real time mode they start at 1, like in Transport Fever 2
20:35:45 <TallTyler> Loan interest compounds quarterly, I think
20:36:16 <dP> TallTyler: well, you brought that on yourself :p
20:36:34 <dP> I'm mostly trying to understand how is it still related to old units that it replaced
20:37:08 <TallTyler> How did I bring that on myself? It was in years before I redesigned it too
20:37:22 <dP> by introducing realtime units
20:37:44 <dP> there is no good unit between minute and hour
20:37:56 <TallTyler> dP: That breaks if you have a vehicle that takes longer than a year on its route, it shouldn’t say it lost money for an entire hour
20:38:25 <dP> why? it's saying that if it takes longer than year currently
20:38:29 <TallTyler> Oh yeah, the lack of a 12-minute unit is by far the hardest conceptual problem about real-time
20:38:44 <TallTyler> No, it says it lost money last year. Not last real-world hour.
20:39:23 <dP> what place do you talk about?
20:39:23 <TallTyler> If we’re going to use hours that data from the past 5 years needs to be actually stored instead of assuming the last year was representative of the whole hour
20:39:46 <dP> I'm talking buy menu, it just says running costs per period
20:39:53 <dP> could easily be any period
20:40:18 <TallTyler> Oh I mean like the vehicle info window, or the group window, where it says profit this year and profit last year
20:40:30 <TallTyler> That can’t really just be multiplied by 5
20:40:55 <dP> it just calculates profit over whatever period
20:40:55 <TallTyler> And the buy menu should probably match units with that, so the player can compare new engines with their current vehicles
20:41:01 <dP> no need to multiply anything
20:41:55 <dP> well, yeah that just brings us back to having no good period between minute and hour
20:42:10 <dP> anyway, it's not related to old units and thus tick rate
20:43:12 <dP> hm, is "quarter" a thing in english?
20:43:29 <nielsm> although it can be confused for a quarter year
20:44:37 <TallTyler> Quarter year is the only usage I know? Unless you mean financial quarter
20:44:41 <nielsm> I kind of experimented with calling 12 minutes a "pento" or something like that (i.e. a fifth of an hour)
20:44:57 <TallTyler> Which is the same thing but doesn’t actually align with the year properly, at least in the US
20:46:42 <dP> still confusing but better than "period" imo
20:48:39 <dP> ok, I see no problem with monthly loops, engine loop needs to be called on calendar/techno year anyway
20:49:41 <TallTyler> I’ve never heard of a quarter referring to a quarter hour in US English
20:49:56 <TallTyler> But I suspect most people here would say that is an American problem 😛
20:50:19 <nielsm> "quarter past 11" not even?
20:50:31 <TallTyler> I’m open to calling them “penta”
20:51:08 <TallTyler> Oh sure, but I wouldn’t make that connection without the context. And that’s an old-timey way to say it
20:51:31 <dP> daily loops can be called every 74 ticks and yearly loops are financial
20:51:40 <dP> except for town which is techno I guess
20:52:07 <glx[d]> we use "quart d'heure" and "trimestre" for quarter (depending which one)
20:52:07 <nielsm> how about a basic "12m period"
20:52:17 <nielsm> although it's significantly longer than "year"
20:52:56 <dP> 12m is very arbitrary for a period
20:52:59 <nielsm> also consider translations, really... translators are going to have a terrible time with a "penta", I'd think
20:53:48 <nielsm> how about putting an explanatory line in the finances window when running real-time mode, "one period is 12 minutes"?
20:55:31 <TrueBrain> JGR: tnx again, you made it really easy to make that (draft) PR 🙂
20:56:59 <nielsm> also you know, maybe it's confirmation bias, but the game "feels cooler" when things move faster on screen, which 27 ms tick time helps with
20:57:15 <nielsm> especially early vehicles feel a bit less like a slog
20:58:01 <dP> imagine how cool would it be with 17ms tick ;)
20:58:22 <dP> vehicles can be smoothly drawn on any rate btw
20:59:07 <dP> just need to take subtile position into account
21:07:30 <dP> TallTyler: I checked all the loops and see nothing that would require a certain tick time. There are just things that need to be done on tick period, on economy period and on techno period. Each period can be whatever and only tick ones affect game balance.
21:14:50 <glx[d]> TrueBrain: compiled before push ?
21:15:31 <TrueBrain> fixing it for release now 😛
21:15:34 <TrueBrain> silly compilers being silly
21:15:38 <glx[d]> regression is debug build
21:16:55 <TrueBrain> different compiler? I dunno .. I was building a release build locally, which failed too, so that made me giggle
21:17:24 <glx[d]> full build vs partial build ?
21:17:29 <TrueBrain> weirdly enough, release build isn't much faster .. hmm
21:17:32 <andythenorth> petern: feel like I've seen you play OpenTTD though? 😛
21:17:36 <andythenorth> even on stream or something
21:17:36 <TrueBrain> glx[d]: does it really matter?
21:17:52 <glx[d]> sometimes it weirdly does
21:18:06 <TrueBrain> I mean: does it really matter why it fails?
21:18:09 <glx[d]> our includes deps are weird
21:19:04 <glx[d]> but usually it's the other way around, partial fails while full is fine
21:19:18 <TrueBrain> hmm, release-builds are a bit faster; not as much as I expected. Owh well .. good that they don't differ that much in TileLoop code 🙂
21:19:22 <glx[d]> especially when cmake touched things
21:20:10 <TrueBrain> that comment .. I just .. no, sometimes it is better to not reply 🙂
21:21:09 <TrueBrain> (comment in the PR, not you glx[d] , to be clear :P)
21:21:39 <TrueBrain> so weird that Discord doesn't track what I am actually done, to add context to a conversation 😛
21:22:17 <petern> Who even replies to issues via email.
21:24:14 <glx[d]> who wants to receive emails for issues you never interacted with ?
21:24:59 <TrueBrain> lol, my single-core CPU speed is too fast 😛
21:25:21 <TrueBrain> they make my PR less relevant with release-builds! 😄
21:25:52 <TrueBrain> we know 😄 We are all patch-hoarders 😛
21:25:58 <nielsm> probably needs a complete do-over tbh
21:26:27 <glx[d]> was splitting land, air and water vehicles ?
21:26:41 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:27:22 <TrueBrain> linking release binaries is so sloooowwwwwwww
21:27:35 <glx[d]> yeah, that's why CI uses debug 🙂
21:27:54 <nielsm> glx[d]: the basic idea is that the vehicle ticks processing needs to be split into two phases: a planning phase and an execution phase. the planning phase should contain the heavy parts but not be allowed to change the game state, but that allows it to be multithreaded. the execution phase can not be multithreaded but should be lightweight, but should also be able to fail and restart vehicle's
21:28:20 <glx[d]> ah right, I remember now
21:28:22 <nielsm> and this splitting out things is quite difficult
21:28:38 <TrueBrain> it is like this game wasn't designed to run threaded 😄
21:28:56 <glx[d]> everything want to access the map
21:29:00 <TrueBrain> I have a similar attempt to split out "game-state-influenced" stuff for viewports, and "draw-the-actual-stuff" for viewports
21:29:08 <TrueBrain> lot of gain for big maps with lot of NewGRF trains
21:29:11 <TrueBrain> but .. so hard to get right 😛
21:29:56 <nielsm> but like, you can probably run ship ticks in parallel with everything else, as long as you don't need to load at stations or consume random numbers
21:30:28 <glx[d]> remember the main loop pain in opendune to work with modern UI main loop
21:30:46 <TrueBrain> 3rd time that same bug is reported 😛
21:34:05 <glx[d]> added flatpak reference in #10232 title
21:34:19 <TrueBrain> okay, now the release-build is quicker
21:34:23 <TrueBrain> like a lot quicker .. 3 times quicker
21:34:30 <TrueBrain> from 5ms world tick to 1.5ms
21:34:46 <TrueBrain> why? I changed the amount of tiles the worker processes from 256 to 1024 🙂
21:35:06 <TrueBrain> with 256, it is done quickly enough, that the queuing takes longer 😛
21:35:17 <TrueBrain> I hate multithreading 🙂
21:35:32 <glx[d]> scale amount with map size ?
21:35:53 <TrueBrain> 543% CPU usage for OpenTTD 😛
21:36:17 <TrueBrain> I have never ever seen OpenTTD use so much CPU 😄 😄 😄
21:36:25 <TrueBrain> I might be having a tiny bit too much fun with this 🙂
21:36:50 <TrueBrain> 4kx4k map at game speed factor 20x ... so weird 🙂
21:37:05 <TrueBrain> glx[d]: no, that would be bad. It is about how fast a worker processes the job
21:37:10 <TrueBrain> that should be a reasonable amount of time
21:37:13 <TrueBrain> that is unrelated to map-size
21:38:18 <TrueBrain> do I have a weird savegame somewhere ..
21:42:41 <TrueBrain> now .... do I dare to run it under valgrind 😛
21:42:55 <TrueBrain> guess clangs thread-checker could also be fun 😄
21:43:08 <andythenorth> dare I compile it for M1? :
21:43:22 <TrueBrain> it currently limits itself to max 8 cores
21:43:26 <andythenorth> well maybe tomorrow 🙂
21:43:38 <TrueBrain> so on an EPYC it isn't as epic yet 🙂
21:43:41 <andythenorth> 8 is fine, I have 10, but I need a whole one just for anti-virus
21:43:47 <glx[d]> still using your weird modified fmt header andythenorth ?
21:43:59 <andythenorth> I didn't get vspkg configured
21:45:03 <TrueBrain> owh, valgrind reports no real issues .. shocking
21:52:48 <TrueBrain> sadly, it is a bit too late for me to answer that question 😄
21:53:00 <TrueBrain> head ... hurts .... tiles ..... annoying ....
21:54:56 <TrueBrain> okay, lot of "data race", which I expected ... dirty-blocks, makes sense ..
21:55:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:55:54 <TrueBrain> `PlantTreesOnTile` .. yeah, you can't do that in the TileLoop when it is threaded .. hihi. Guess we need to make some kind of queue for "actions taken", which are executed after the tileloop finishes, or something
21:57:32 *** WormnestAndroid has joined #openttd
22:00:46 *** WormnestAndroid has quit IRC (Read error: No route to host)
22:02:28 *** WormnestAndroid has joined #openttd
22:06:33 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:07:15 *** WormnestAndroid has joined #openttd
22:12:23 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:14:54 *** WormnestAndroid has joined #openttd
22:23:39 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:24:24 *** WormnestAndroid has joined #openttd
22:25:06 <glx[d]> something similar to the planning/execution idea for vehicles
22:29:52 *** Wormnest has joined #openttd
22:40:09 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:04:48 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:06:33 *** Wormnest has joined #openttd
continue to next day ⏵
