IRC logs for #openttd on OFTC at 2023-12-28
00:26:14 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11634: Feature: Custom company colours.
00:27:13 <peter1138[d]> Only a draft.
00:33:40 <peter1138[d]> Way too many LOC currently ๐Ÿ˜ฎ
00:35:35 <reldred> man this town really doesn't want me to build this freight bypass ๐Ÿ˜
00:37:01 <reldred> peter1138[d]: Still, good work getting it to PR state ๐Ÿ˜„
00:38:17 <Eddi|zuHause> reldred: the NIMBYs are everywhere.
00:38:51 <reldred> the problem more is the amount of back yards I'm destroying entirely ๐Ÿ™‚
00:54:06 <Eddi|zuHause> "our cities will not be bulldozed for the car, they will be bulldozed for the train" :p
01:03:24 *** Extrems has quit IRC (Quit: ZNC 1.7.5 -
01:03:52 *** Extrems has joined #openttd
01:26:25 <reldred> I do need to start building highways soon, so a little of column A, a little of column B
01:36:01 *** Flygon has joined #openttd
01:42:24 *** Extrems has quit IRC (Quit: ZNC 1.7.5 -
01:42:33 *** Extrems has joined #openttd
01:55:54 *** Extrems has quit IRC (Quit: ZNC 1.7.5 -
01:56:03 *** Extrems has joined #openttd
02:52:17 <DorpsGek> [OpenTTD/OpenTTD] krysclarke commented on pull request #11632: Fix: Grammar corrections
02:58:00 <talltyler> Oof committing through
03:01:10 *** herms has quit IRC (Ping timeout: 480 seconds)
03:18:07 *** Wormnest has quit IRC (Quit: Leaving)
03:19:11 *** herms has joined #openttd
04:01:52 *** debdog has joined #openttd
04:05:11 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:44:58 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11632: Fix: Missing word in conditional order comparator
05:11:26 <locosage> jfs: well, I did say it at the beginning of its development :p
05:11:40 <locosage> my only hope is that it's still possible to get rid of it completely with a server patch
05:14:00 *** keikoz has joined #openttd
07:30:59 *** tokai has joined #openttd
07:31:00 *** ChanServ sets mode: +v tokai
07:37:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:53:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
08:22:47 <peter1138[d]> talltyler: don't worry, you'll get tons of sarky useless comments when it is done.
08:43:18 <andythenorth> Just blame FIRS
09:07:54 <truebrain> And there is always need for a Marvin, otherwise the story isn't complete
09:10:58 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11428: Feature: Setting for minutes per calendar year
09:12:38 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11428: Feature: Setting for minutes per calendar year
09:13:03 <truebrain> Stupid GitHub, folding files ..
09:13:11 <truebrain> That was confusing! ๐Ÿ˜„
09:14:03 <emperorjake> truebrain: Yep, it works
09:14:18 <emperorjake> (I was asleep by that time) ๐Ÿ˜‰
09:14:30 <truebrain> emperorjake: Sweet! Tnx for testing ๐Ÿ˜„
09:14:36 <truebrain> Pff, sleep is overrated!
09:16:18 <peter1138[d]> Well
09:20:02 <truebrain> now I just need to add signing to the MacOS binaries ... that will be "fun" ๐Ÿ˜›
09:20:50 <andythenorth> truebrain: "Without shade there can be no light" (or something)
09:23:56 <truebrain> pff, all that hippy talk
09:24:19 <andythenorth> think it's Taoism, ying-yang
09:24:26 <andythenorth>
09:38:13 <alfagamma7> Hmm
09:38:13 <alfagamma7> 2FA
09:39:23 <andythenorth>
09:39:23 <andythenorth> is there any way to tell how long a train is without sending it to depot?
09:39:32 <truebrain> counting?
09:39:37 <truebrain> 1, 2, 3, 4, ... ๐Ÿ˜„
09:39:38 <andythenorth> usually I do it by cloning one in depot, then deleting it
09:39:55 <andythenorth>
09:40:13 <andythenorth> now I delete train 93 ๐Ÿ˜›
09:40:17 <andythenorth> it's like a ruler
10:04:55 <georgevb> andythenorth: I see so much efforts on docks and ship movement, is there a chance to fix the main problem with ships - they can't go up and down the slopes on the rivers? It would be very nice to get a new way of transportation - by ships via rivers. Even some industries could have higher probability to be build near rivers, like forest and sawmills.
10:06:17 <locosage> there is a bit of downside that no one takes rivers seriously in mp
10:06:25 <locosage> at least with locks you can somewhat see it's used
10:09:49 <locosage> but that assumes that whoever wants to cross it actually bothers to check...
10:13:14 <locosage> it kind of needs to be establish whether rivers are for eyecandy or for transportation
10:13:17 <locosage> maybe do a setting
10:14:11 <andythenorth> georgevb: I agree, ships navigating rapids would make better gameplay, but consensus so far has been 'no'
10:14:20 <andythenorth> ๐Ÿ™‚
10:15:42 <andythenorth> locosage: rivers are for lolz, and we should start from that perspective ๐Ÿ˜›
10:16:23 <emperorjake> Nah, why would you want to skip the requirement for locks? It makes sense to have to do some infrastructure upgrades to make a river navigable
10:16:45 <locosage> eyecandy rivers:
10:16:45 <locosage> - ships can't use
10:16:45 <locosage> - slopes are rapids
10:16:45 <locosage> - maybe narrower than canals
10:16:45 <locosage> transport rivers:
10:16:46 <locosage> - ships can use
10:16:46 <locosage> - slope is just river so no locks
10:16:48 <locosage> - can't be destroyed
10:17:33 <locosage> eyecandy can even just be auto-removable like farm fields
10:19:11 <locosage> though if rivers need no locks what do to with canals and locks in general...
10:20:45 <emperorjake> eyecandy rivers already exist in the form of objects
10:21:18 <locosage> to me that is equivalent of not existing
10:21:21 <emperorjake> perhaps the spec for randomly generated map objects could include a pathfinder to generate object-rivers?
10:22:45 <locosage> that's just piling up hacks
10:24:54 <ahyangyi> I don't think we should change the default behavior of rivers, but why can't we add extra options?
10:25:20 <ahyangyi> (and grab that "construct river" option from jgrpp too)
10:25:36 <emperorjake> Yes, that's badly needed in vanilla
10:29:55 <andythenorth> so much water talk ๐Ÿ™‚
10:30:08 <truebrain> feeling wet yet?
10:49:46 *** keikoz has joined #openttd
10:53:51 <xarick> I found there's way more places in OpenTTD code that could benefit from #10548. I'm just not sure if it's too much work for too little benefit
10:54:16 <xarick> I searched for Vehicle::Iterate
10:54:37 <xarick> there's that many instances to investigate if it's worth switching to
10:55:43 <xarick> how should I undertake a change of this magnitude?
10:55:48 <xarick> what's the best approach?
11:00:23 <locosage> xarick: `Company::Get(c->index)` => `c`
11:02:46 <xarick> what?
11:03:50 <xarick> ah, I s ee
11:03:55 <xarick> improvements in the code
11:11:17 <xarick> I have a big dilema to solve, before I fully commit to this
11:11:25 <xarick> Vehicle vs VehicleID
11:13:02 <locosage> Vehicle is likely faster but any mistake can crash the game
11:13:25 <locosage> though as you use Get there isn't much a difference wrt crashes
11:13:43 <locosage> well, Vehicle * ofc
11:15:13 <locosage> VehicleID probably uses less memory though
11:15:35 <xarick> the "auto" feature is a curse... I can't exactly search the code for "VehicleID"
11:21:41 *** nielsm has joined #openttd
11:29:45 <xarick> I think I'm switching my auto's to what they really are, forgive me if that's anti-modern
11:30:10 <xarick> it at least allows me to search the entire project
11:30:11 <Rubidium> but do you really know what they really are?
11:30:36 <xarick> yes, for this yes
11:37:58 <LordAro> i tend to agree for "basic" types
12:07:49 <xarick> so many errors after thoroughy re-reviewing my own code ๐Ÿ˜ฎ
12:08:15 <xarick> not exactly game breaking errors, but some repetition
12:08:21 <xarick> could be avoided
12:10:10 <xarick> I keep forgetting that in a for loop
12:10:33 <xarick> using stuff like Company::Get(c->index) costs time
12:12:06 <xarick> also found another
12:13:49 <xarick> line 159 is better to define &stats = Group::Get(g->index)->statistics; before starting the loop that will use it
12:27:15 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
12:36:56 <LordAro> xarick: Group::Get(g->index) can also just be replaced by g
12:37:08 <LordAro> assuming it's a Group
12:57:13 <xarick> oh
12:57:40 <xarick> i fail at these obvious things
13:29:57 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
13:30:50 <peter1138[d]> auto is reasonable for iterators or long templates but... yeah.
13:34:27 <xarick> I just noticed there's a Aircraft::Iterate() and a RoadVehicle::Iterate()
13:34:44 <xarick> need to check how these work
13:39:08 *** Artea has joined #openttd
13:41:20 <peter1138[d]> Doop
13:41:27 <xarick> oh, it still goes through the big pool of vehicles... nothing special ๐Ÿ˜ฆ
13:42:26 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11428: Feature: Setting for minutes per calendar year
13:43:09 <truebrain> sorry talltyler , thought the update was from after the conversation ๐Ÿ˜„
13:44:58 <talltyler> Itโ€™s okay ๐Ÿ™‚
13:45:06 <talltyler> I will try to get to it this morning
13:48:05 <peter1138[d]> New setting... Bike shed level: 150%
13:54:31 <truebrain> dbg: [misc] [Social Plugin: discord/] Failed to initialize: Discord is not running
13:54:31 <truebrain> dbg: [misc] [Social Plugin: discord-social-v1.0.12-linux-amd64/] Another plugin for Discord is already loaded
13:54:41 <truebrain> nice ๐Ÿ™‚ That should prevent most of the horrible mistakes users can make ๐Ÿ˜›
13:56:50 <truebrain> ```(gdb) bt
13:56:50 <truebrain> #0 0x0000000000000000 in ?? ()
13:56:50 <truebrain> #1 0x0000000000000000 in ?? ()```
13:56:54 <truebrain> hmm ... that is ... hmmmmm
14:00:06 <Rubidium> ... less than ideal?
14:02:05 <LordAro> null deref?
14:02:49 <truebrain> but a null deref should trigger a crash ... and show the backtrace who was doing that ๐Ÿ˜›
14:03:15 <jfs> shouldn't have two stack frames with return address zero, that kind of smells like stack smashing
14:03:55 <jfs> of course a single frame with zero return address is bad enough
14:04:42 <truebrain> the worst part is, I wasn't aware I made any changes that could impact anything ๐Ÿ˜›
14:10:56 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
14:11:44 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
14:14:59 <_glx_> xarick: Iterate is declared at pool level, so of course it does the same thing everywhere, just each subclass auto apply filtering
14:15:50 <truebrain> unrelated, valgrind shows `LoadFromHighScore` has a `Conditional jump or move depends on uninitialised value(s)`
14:18:13 <peter1138[d]> Yeah, highscore.cpp:156 & 157 look fishy.
14:18:32 <peter1138[d]> Oh, limits. Hmm.
14:18:50 <peter1138[d]> Well, it's not initialised, but then it shouldn't be used if it failed to be loaded. hMM.
14:18:55 <truebrain> buffer is never initialized ๐Ÿ™‚
14:19:32 <peter1138[d]> It is "initialised" by fread.
14:21:09 <truebrain> okay, so I get a pointer from dlsym .. and for some reason it has become invalid or something .. hmm
14:22:12 <truebrain> ah, object is moved .. right
14:24:39 <truebrain> this happens if you want to be fancy, I guess
14:24:47 <truebrain> you get punished! ๐Ÿ˜„
14:25:25 <peter1138[d]> ๐Ÿ˜ฎ
14:30:02 <truebrain> well, this is odd .. a dtor is called on an object I did not expect to be destructed yet .. eeeuuhhhh ... what is going on? ๐Ÿ˜„
14:30:43 <xarick> Can I do this, or is it unacceptable? Redefine *v to a different type?
14:30:43 <xarick> ` for (const Vehicle *v : stats.vehicle_list) {
14:30:43 <xarick> Aircraft *v = Aircraft::From(v);`
14:30:59 <xarick> wow, discord is bad at quoting *
14:31:20 <peter1138[d]> Use triple back-ticks for block quoting.
14:31:53 <peter1138[d]> But no, you can't do that.
14:32:02 <xarick> ugly
14:32:48 <xarick> why im so bad at discord
14:33:21 <truebrain> okay, I think I am doing something silly wrong here ...
14:33:22 <truebrain> `static std::vector<SocialPresencePlugin> _plugins;`
14:33:27 <truebrain> `SocialPresencePlugin &plugin = _plugins.emplace_back(filename, basepath);`
14:33:38 <truebrain> for some reason the dtor is called on items still in the vector ..
14:35:16 <_jgr_> vector will call the destruct, construct, move, etc elements when the backing array is re-allocated
14:35:22 <talltyler> Widget text is now black by default (since #10051) so I wonder if we can get rid of most of the {BLACK} colour codes that start about 1400 strings in English.txt ๐Ÿค”
14:35:36 <truebrain> _jgr_: really? I thought it only reallocated the memory?
14:35:42 <peter1138[d]> talltyler: Yes, I just never got around to it.
14:36:09 <_jgr_> truebrain: It still has to get the elements from the old piece of memory to the new one
14:36:19 <truebrain> I assumed a memmove would do that
14:36:32 <_jgr_> Presumably your object isn't a POD
14:36:36 <truebrain> it is not
14:36:38 <talltyler> Weโ€™d have to do some good find and replace to avoid breaking translations
14:36:53 <talltyler> Meaning weโ€™d want to update translations too
14:37:48 <peter1138[d]> Is it enough to implement a move constructor?
14:38:15 <truebrain> I deleted the copy ctor, to be sure ๐Ÿ˜› I defaulted the move ctor
14:38:27 <truebrain> anyway, making it unique_ptr solves the issue too
14:38:40 <truebrain> tnx _jgr_ .. did not know a vector did something more with it than just a move
14:38:40 <peter1138[d]> That'll work ๐Ÿ™‚
14:39:19 <truebrain> `auto &plugin = _plugins.emplace_back(std::make_unique<SocialPresencePlugin>(filename, basepath));`
14:39:21 <truebrain> bit lengthy now ๐Ÿ˜›
14:42:41 <peter1138[d]> But correct.
14:43:21 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
14:43:26 <truebrain> let's see how much I broke Windows
14:44:33 <truebrain> answer: A LOT
14:45:30 <truebrain> ofc I picked a name that fully collides with Windows functions ๐Ÿ˜„ Haha
14:47:15 <xarick>
14:47:15 <xarick>
14:47:15 <xarick> Why can I do this with no errors using the same v, but not this, using a?
14:48:51 <_jgr_> You can't remove the constness in an assignment like that
14:48:52 <DorpsGek> [OpenTTD/OpenTTD] milsa commented on issue #9923: [Bug]: Property maitenance cost is very high for airport
14:50:25 <xarick> I can't? it could with v
14:51:32 <peter1138[d]> You need `const Aircraft *`
14:51:46 <_jgr_> You can't in the first one either, your editor may not have noticed because you've shadowed another variable
14:51:48 <DorpsGek> [OpenTTD/OpenTTD] milsa commented on issue #9923: [Bug]: Property maitenance cost is very high for airport
14:51:56 <xarick> I need to change orders from the aircraft, can't be const Aircraft *
14:52:08 <xarick> it let me build though
14:52:17 <xarick> let me confirm the aircraft get their orders changed
14:52:48 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on issue #9923: [Bug]: Property maitenance cost is very high for airport
14:52:56 <peter1138[d]> Then don't use `const Vehicle *v` in your for loop.
14:53:15 <peter1138[d]> (Assuming your vehicle_list is not `const Vehicle *` too.
14:53:23 <xarick> it is
14:53:24 <xarick> ๐Ÿ˜ฆ
14:54:07 <xarick> it's not really my list, it's how VehicleList was defined 15 years ago, was attempting to re-use it
14:54:41 <peter1138[d]> You can probably not use that.
14:55:12 <peter1138[d]> It's basically a left-over from when we didn't use vectors and such like.
14:56:24 <peter1138[d]> Or you can use Vehicle::Get(v->index) ๐Ÿ˜‰
14:57:57 <xarick> oh, you're right, it didn't work
14:57:59 <xarick>
14:58:10 * xarick jgr
14:59:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
15:01:10 <xarick> peter1138[d]: fantastic, that did it
15:01:42 <xarick> Aircraft *v = Aircraft::From(Vehicle::Get(a->index));
15:02:48 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11428: Feature: Setting for minutes per calendar year
15:03:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
15:05:36 <peter1138[d]> xarick: Of course, if you are ALWAYS using Vehicle::Get from your list, and never need the `const Vehicle *` because you always need it non-const, then you can use `std::vector<VehicleID>` instead. Or `std::vector<Vehicle *>`
15:07:22 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
15:07:25 <truebrain> one day I will make a big PR without any silly mistakes ... ๐Ÿ˜›
15:07:40 <truebrain> I am happy running CI aborts these days ๐Ÿ˜›
15:07:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
15:08:21 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #11428: Feature: Setting for minutes per calendar year
15:08:57 <talltyler> Okay truebrain , NOW itโ€™s updated ๐Ÿ˜‰
15:09:03 <truebrain> ๐Ÿ˜„
15:10:34 <truebrain> so now for a place in the UI .. I was thinking in Game Options, a new tab called "Socials"
15:10:52 <truebrain> would mean I need to widen the window a bit
15:11:18 <peter1138[d]> That's fine, it's only that narrow now because nothing forces it to be wider.
15:11:26 <truebrain> good
15:11:39 <peter1138[d]> If it's wider, than the baseset descriptions will take up less height ๐Ÿ™‚
15:11:41 <truebrain> guess I should list all the plugins detected, and their state .. and for now, I guess that is about it
15:11:51 <truebrain> or maybe a button to disable a specific plugin ..
15:12:02 <truebrain> but that requires me to write stuff in the config file ๐Ÿ˜›
15:13:35 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #11428: Feature: Setting for minutes per calendar year
15:17:24 *** greenmotivations has joined #openttd
15:17:24 <greenmotivations> 50 ะฑะฐะบัะพะฒ ะฝะฐ ัั‚ะธะผ
15:17:24 <greenmotivations> [](
15:18:19 <peter1138[d]> You know your monitors are a bit shit when the bootstrap chequer pattern has a green hue...
15:19:42 <peter1138[d]> (And it's also non-uniform)
15:20:02 <peter1138[d]> Hmm, unless it is actually green...
15:20:15 <peter1138[d]> Desktop Magnifier says no ๐Ÿ™‚
15:22:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
15:22:38 <truebrain> there, all OSes compile again, the plugins compile .. good. Now first food, then UI stuff ... "fun" ๐Ÿ˜„
15:22:44 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
15:26:49 <peter1138[d]>
15:27:07 <peter1138[d]> Well...
15:33:42 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:50:42 <LordAro> truebrain: woop
15:53:50 <peter1138[d]> Hmm, where did palette_key.png come from...
15:54:24 <peter1138[d]> The colours in it do not match table/palettes.h
15:55:48 <georgevb> A small question about NML specification
15:55:48 <georgevb> > Engine life cycle
15:55:48 <georgevb> > The life cycle of a vehicle model consists of three phases, as outlined in the following table. The length of each phase and the starting, peak, and final reliabilities are randomized for each engine when starting a new game. Also note that phase 2 (the vehicle's peak performance) is actually about 8 years shorter than the model_life parameter.
15:55:48 <georgevb> does it mean that minimal allowed value for model_life is 9 years?
15:56:53 <peter1138[d]> "peak performance" probably means "peak reliability"
15:58:11 <peter1138[d]> I guess that means it just won't really reach peak reliability if life length is short.
15:59:25 <georgevb> What would happen if I specify, for example, 1 year? When would such model disappear (when vehicles never expire is off)?
16:01:13 <georgevb>
16:01:45 <georgevb> As I can see, small values for model_life work strange
16:02:10 <georgevb> Vehicles do not disapper for ages
16:02:55 <georgevb> While retire_early is set to 0
16:04:39 <georgevb> When should such vehicles (with model_life = 1) disappear?
16:04:45 *** Wormnest has joined #openttd
16:07:09 <peter1138[d]> Well 1) it's randomised 2) I'm absolutely sure you have the ability to test it.
16:10:21 <georgevb> My tests shows some values about 10-20 years, so I'm expecting there is some bug. That's why I'm asking, because I think I might have misunderstood the specification
16:15:05 <georgevb> So I set model_life to 1 and get 20 years availability in game. That is not my intention about randomisation, but may be it is intended, but not described in the specification?
16:16:21 <georgevb>
16:16:26 *** gelignite has joined #openttd
16:16:32 <peter1138[d]> Values under 8 are likely to underflow.
16:16:58 <georgevb> So, minimal possible value is 9?
16:17:20 <peter1138[d]> base_life doesn't directly set how long the engine is available, it affects how long it is in phase 2 of reliability.
16:17:39 <peter1138[d]> 8 won't underflow, so I'd say the minimum is 8.
16:18:06 <peter1138[d]> It might not underflow with lower values, but you can't control that.
16:18:51 <peter1138[d]> I suppose we could clamp it to stop it underflowing.
16:19:24 <peter1138[d]> But probably some NewGRF intentially does it ๐Ÿ™‚
16:20:12 <georgevb> Should I make a bug report for this case?
16:21:20 <georgevb> So having model_life = 1 may cause 2-3 years because of randomisation, but not more
16:27:30 <peter1138[d]> Again, model_life does not directly correlate with the number of years a model will be available. Phase 1 is completely random, between 7 months and 38 months. Phase 2 can add another 15 months on top of (model_life-8) years. Phase 3 is at least 10 years, but could be 20 years and 7 months.
16:27:49 <peter1138[d]> I guess uUse retire_early if you really want a short life
16:28:31 <merni> What a mess
16:29:34 <georgevb> What values should I specify if I want to make a model be available about a year?
16:29:51 <peter1138[d]> I suggest not bothering to introduce a vehicle that only exists for 1 year.
16:31:02 <peter1138[d]> merni: only when you try to make a 'specification' out of a game mechanic that is intended to randomize things.
16:31:59 <merni> Arguably when you're allowing people to create new vehicles they should be able to specify things as they want. But of course, 25 year old stuff :p
16:32:09 <peter1138[d]> e.g. 15 = 4 bits of random data, 38-7 = 5 of random data, and 20 - 10 is 7 bits of random data.
16:32:56 <talltyler> thereโ€™s no way a NewGRF author would intend to underflow, I think we should absolutely clamp it
16:33:07 <peter1138[d]> It's only the realistic-railwayers that get caught up in trying to make things exist exactly as they did in real life.
16:33:42 <talltyler> Also, vehicles that only exist for one year are more viable when we slow down calendar time
16:34:08 <talltyler> (Not that I think itโ€™s good design)
16:34:41 <xarick> disaster vehicle targeting a random train, I'm about to change the rules a bit ... it's gonna be a different type of random, still random, but not the same result as the previous random
16:35:07 <peter1138[d]> If it exists only for a year, then either nobody will use it because it must have been a terrible design, or players will just turn on never expire so they can continue with it.
16:35:41 <peter1138[d]> As long as it's not InteractiveRandom...
16:53:49 <peter1138[d]> NewGRF reliability?
16:54:34 <peter1138[d]> Static values or callbacks...
16:55:26 <xarick> it's because I have to iterate the global train group for each company, I have to iterate companies... to count number of valid targets
16:56:30 <peter1138[d]> Not sure how you'd express the 6 values required for reliability...
16:56:49 <peter1138[d]> Or just give the NewGRF full control.
16:57:29 <georgevb> georgevb: peter1138[d] my question is still valid. What values should I specify to get the behaviour similar to intended as closed as possible?
17:04:49 <_glx_> xarick: this disaster affects only real players, not AIs
17:05:06 <xarick> yes, I see, I'm aware
17:05:40 <_glx_> and it's not very frequent (and in most case disasters are disabled)
17:15:10 <xarick> waiting for a disaster vehicle hit a road vehicle
17:15:24 <xarick> see if i get this codechange working
17:16:00 <xarick> I have to go through 100s Vehicle::Iterate... this is gonna take forever :9
17:19:24 <_glx_> I think you are going too deep
17:19:40 *** Wolf01 has joined #openttd
17:20:33 <xarick> I had a dream I wanted to see if there was a real gain in performance, other than just for AIs
17:21:14 <xarick> change most parts than iterate vehicles to use the cached lists
17:21:22 <_glx_> the game loops through all vehicles at least once per tick
17:22:45 <_glx_> I can understand a need to cache for AIs (because they might do silly expensive things), but for normal game loop stuff it's most likely not needed
17:26:20 <_glx_> and the cache would also be used for group related accesses in openttd, but it's probably not needed to use it everywhere
17:35:31 <xarick>
17:35:31 <xarick> size() is correct for vector lists?
17:36:28 <_glx_> I think in this case it's faster to use RoadVehicles::Iterate() and filter out AI companies
17:37:01 <xarick> no this one actually targets whoever's company
17:37:07 <xarick> the train one not
17:37:17 <_glx_> ah right it's non destructive
17:37:27 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
17:37:40 <xarick> it destroys the road vehicle
17:38:13 <_glx_> oh I hope AIs handle that ๐Ÿ™‚
17:39:11 <_glx_> but yeah the rail destruction for bug UFO is way harder from AI POV, that's why they are not targetted
17:41:39 <xarick> IsFrontEngine, I see it's not needed, I can ommit this check. The vehicles are only added to the cache if they pass IsPrimaryVehicle
17:41:55 <xarick> which is another alias for IsFrontEngine
17:42:06 <xarick> at least for road and trains
17:43:02 <_glx_> for me the cache should store VehicleID only, as what matters for ScriptVehicleList
17:43:21 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #11628: Feature: Social Presence to integrate with Steam, Discord, GOG, etc
17:44:01 <xarick> I was thinking dropping the const, but still use Vehicle *
17:44:08 <xarick> it would simplify the code so much
17:44:29 <_glx_> but you would just duplicate the pool
17:44:41 <xarick> oh, i see
17:44:53 <xarick> memory issues?
17:45:30 <_glx_> they would just be pointers, so not that much
17:46:58 <xarick> this line here
17:49:18 <_glx_> the const here is because you really don't want the data to be modified
17:50:15 <peter1138[d]> The pool itself is just pointers ๐Ÿ™‚
17:51:26 <_glx_> and a cache is usually only to get faster read so const is expected
17:52:14 <_glx_> if you want to modify the object you don't do it via the cache
17:58:29 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
18:04:45 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
18:05:12 <xarick> wow, this one is a tough one, change ownership of company
18:05:22 <xarick> might be doable
18:06:28 <locosage> _glx_: that's nonsense, caches/indexes are done to improve performance, const or not
18:06:35 <locosage> if cache duplicates pool drop pool
18:07:20 <peter1138[d]> If cache duplicates pool, drop cache.
18:08:42 <locosage> there is no use for a pool with inadequate performance
18:08:48 <locosage> call cache the new pool if you want
18:09:40 <_jgr_> Pools don't have any particular performance issues with lookups
18:10:16 <locosage> well, lookup clearly isn't the only operation needed here
18:11:11 <_glx_> the main issue here is ScriptVehicleList generation, not the pools performance
18:15:09 <peter1138[d]> Yeah, it's the act of having to make a list, instead of just filtering as you go.
18:27:00 <xarick> '+=': conversion from 'size_t' to 'uint', possible loss of data ๐Ÿ™‚
18:28:04 <xarick> n += (uint)stats.vehicle_list.size(); will this fix it?
18:33:45 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #10548: Feature: Groups cache vehicle lists
18:33:56 <peter1138[d]> `e->age = (aging_date - e->intro_date).base() >> 5;`
18:34:26 <peter1138[d]> That `>> 5` looks like `/ 32` , and a suspiciously wrong way to convert days to months...
18:34:54 <peter1138[d]> Hmm. Maybe one of talltyler's changes tackles that.
18:35:15 <xarick> wow, security bot found a serious issue...
18:35:22 <xarick> there are two v's there
18:35:37 <xarick> they're not the same
18:36:00 <talltyler> peter1138[d]: I no longer touch vehicle age, that stays calendar
18:36:14 <peter1138[d]> Makes sense, but /32 doesn't ๐Ÿ˜„
18:36:40 <peter1138[d]> I wonder if it's noticable though.
18:37:57 <talltyler> I used to touch aging code before you explained why it should stay calendarโ€ฆ itโ€™s a strange place
18:38:00 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
18:38:36 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master
18:38:37 <DorpsGek> - Update: Translations from eints (by translators)
18:39:01 <peter1138[d]> Huh.
18:39:41 <peter1138[d]> Yeah
18:40:12 <peter1138[d]> Trying to work out why these engines are permanently present ๐Ÿ™‚
18:42:08 <Rubidium> isn't `aging_date - e->intro_date` promoted to an int, and then becomes slight negative? After which bit shifting makes it about 2**27?
18:42:28 <xarick> I'm unsure about the IsEngineCountable part
18:42:43 <xarick> will this count wagons?
18:44:08 <xarick>
18:44:29 <peter1138[d]> Oh, it's by design... `_year_engine_aging_stops`
18:45:38 <talltyler> Classic โ€œintended behaviorโ€
18:45:46 <xarick> let's try build a wagon and see what IsEngineCountable tell
18:46:47 <peter1138[d]> Rubidium, they're int anyway, no promotion.
18:47:00 <peter1138[d]> Technically bit-shifting signed integers is wrong.
18:47:36 <talltyler> Right, does it shift the signed bit?
18:47:36 <xarick> yep, it counts wagons... ๐Ÿ˜
18:47:42 <peter1138[d]> I think it's okay if the value is positive.
18:47:58 <talltyler> Because the unsigned bit is off ๐Ÿ™‚
18:48:18 <peter1138[d]> But this `>> 5` might just be represented as `/ 32` or...
18:48:23 <talltyler> But if itโ€™s safe to shift because itโ€™s always positive, it should just be unsigned ๐Ÿ˜‰
18:48:31 <peter1138[d]> Do we have a better way of getting months from two absolute dates?
18:48:42 <peter1138[d]> unsigned is dangerous ๐Ÿ™‚
18:49:24 <talltyler> Getting months from the difference between two dates?
18:50:38 <peter1138[d]> Getting months between two dates.
18:51:16 <peter1138[d]> There's no particular need to get the difference first, here.
18:51:32 <peter1138[d]> I figured you'd know about it ๐Ÿ˜‰
18:51:53 <talltyler> I donโ€™t know of a simple way
18:52:26 <talltyler> Oh, maybe converting it to YMD first would be helpful
18:52:44 <peter1138[d]> Yeah, that's just where I was heading ๐Ÿ™‚
18:53:58 <xarick> v->InvalidateNewGRFCache(); is this for any kind of vehicle, or just primary vehicles? I keep seeing this
18:54:10 <peter1138[d]> Any.
18:54:38 <peter1138[d]> v->InvalidateNewGRFCacheOfChain() is the call for the head vehicle.
18:55:20 <xarick> oh, sheesh, can't give the group list treatment then
18:56:48 <Rubidium> I'd almost use std::chrono to get the number of months ;)
18:58:20 <jfs> std::chrono doesn't have any calendar functionality afaik
19:04:28 *** Artea has quit IRC (Quit: ZNC 1.6.2 -
19:05:10 <peter1138[d]>
19:05:15 <peter1138[d]> Seems to be a fairly big difference...
19:05:23 <Rubidium> jfs: I'm not saying it's good, but... The intrinsic point is more that you shouldn't try create your own calendar system ;)
19:06:10 *** Artea has joined #openttd
19:06:40 <peter1138[d]> As they are all January, easy to check too...
19:07:10 <peter1138[d]> `>> 5` seems to be wrong by quite a lot.
19:10:11 <peter1138[d]> I think it means if you start a game in the year 2000, the engines will stay around longer than if you started in 1950...
19:10:40 <jfs> Rubidium: you can't convert a number of days to a number of months without having a base date at one or the other end, since months differ in length. I would not call that calendar aware at all. besides, OpenTTD is not really implementing a real-world calendar, but rather the game time calendar that was present in Transport Tycoon (which just happens to be very similar to the gregorian)
19:11:05 <peter1138[d]> We already have our own calendar functions, I'm not making new ones.
19:11:30 <jfs> I thought so too
19:32:36 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11635: Fix: Base life under 8 years could underflow, leading to very long-lived engines.
19:39:20 <peter1138[d]> (Can probably take those static_asserts() out, I wanted to make sure some environment didn't come up with different values.)
19:49:03 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #11635: Fix: Base life under 8 years could underflow, leading to very long-lived engines.
19:49:40 <xarick> darned wagons...
20:01:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #11635: Fix: Base life under 8 years could underflow, leading to very long-lived engines.
20:04:13 <talltyler> What is %p ?
20:04:25 <jfs> percent points
20:04:37 <jfs> or at least that is my intention when I wrote that comment
20:05:41 <peter1138[d]> Should I write as percentage points?
20:06:18 <peter1138[d]> (25% on top of 25% is 31.25%)
20:07:03 <jfs> supposedly %pt. or pp are more common abbreviations
20:07:11 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
20:07:25 <peter1138[d]> Ah okay.
20:13:02 <xarick> how does the setting elrail works when combined with NewGRFs tracks and engines?
20:13:22 <xarick> enable the "disable electric rails"
20:13:53 <peter1138[d]> Only with the default electrified rails, I believe.
20:14:22 <peter1138[d]> It is mostly a compatibility setting, for loading older games before elrail existed.
20:15:22 <peter1138[d]> "Disable electric rails" should probably be removed from the settings window.
20:15:48 <peter1138[d]> (Given there are other more useful settings that are already hidden...)
20:16:29 <peter1138[d]> Of course that'll probably ruin somebody's specific way of playing the game...
20:16:43 <jfs> yeah it would more be a setting for OpenGFX+ Trains nowadays
20:16:50 <xarick>
20:17:13 <jfs> except that it's required to be compatible with loaded TTD savegames where electrified rail does not exist
20:18:31 <_glx_> or when they do they replace monorail or maglev
20:19:03 <_glx_> but that would be a TTDp save
20:21:17 <jfs> I don't remember if we even load ttdpatch saves? I don't think it stores the active settings in the savegame so it's not quite knowable what features are needed/used
20:22:44 <_glx_> I think we try to load them, but they use newgrf from the config, like very old OTTD saves
20:23:17 <_glx_> so not super reliable
20:30:59 *** jinks has quit IRC (Quit: ZNC -
20:31:02 *** jinks has joined #openttd
20:37:17 *** gelignite has quit IRC (Quit: Stay safe!)
20:48:29 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #11636: [Bug]: Various thread safety issues with use of libcurl for HTTP downloads
21:05:27 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #11637: Codechange: Simplify ConvertDateToYMD by returning YearMonthDay instead of outputting to a pointer.
21:05:42 <peter1138[d]> Ah threads
21:10:40 <xarick>
21:10:40 <xarick> kek
21:11:26 <peter1138[d]> And?
21:12:21 <DorpsGek> [OpenTTD/OpenTTD] flisk commented on issue #10083: [Bug]: Cheats menu doesn't work by default on macOS
21:12:31 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #11637: Codechange: Simplify ConvertDateToYMD by returning YearMonthDay instead of outputting to a pointer.
21:13:30 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11635: Fix: Base life under 8 years could underflow, leading to very long-lived engines.
21:14:51 <xarick>
21:14:51 <xarick> I am not impressed
21:15:17 <xarick> well, there were gains, but....
21:15:58 <xarick> pretty sure this workaround is nulling any advantage Train *t = Train::From(Vehicle::Get(v->index));
21:17:35 <_jgr_> Probably not, but you may find it useful to do some reading on const_cast
21:20:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11637: Codechange: Simplify ConvertDateToYMD by returning YearMonthDay instead of outputting to a pointer.
21:26:23 <xarick>
21:26:23 <xarick> I tried Train *t = Train::From(const_cast<Vehicle *>(v));
21:26:27 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11635: Fix: Base life under 8 years could underflow, leading to very long-lived engines.
21:26:55 <xarick> not much of a difference
21:27:30 <xarick> btw, the *'s are there, but discord eats them and casts itallic
21:29:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11631: Fix #11629: AirportGetNearestTown for rotated airports
21:33:12 <xarick> I still remember the goal for AirportGetNearestTown which was to improve AIs looking for places for an airport
21:33:36 <xarick> I wanted to keep it lean, but now there's asserts ๐Ÿ˜ฆ more code
21:34:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11637: Codechange: Simplify ConvertDateToYMD by returning YearMonthDay instead of outputting to a pointer.
21:34:32 <_glx_> I would not look too much into the cost of a setting callback, especially when it's a setting you won't change multiple times during a single game
21:35:33 <peter1138[d]> xarick: asserts are removed in releases.
21:36:40 <_glx_> oh and when comparing performance I hope you use release builds
21:36:43 <xarick> maybe the iterator clone might make up for it
21:37:22 <peter1138[d]> Those assert don't exist in releases, so there's nothing to "make up"
21:38:08 <xarick> how do I disable asserts?
21:38:14 <xarick> or do a release build
21:38:37 <xarick> RelWithDebInfo?
21:38:41 <_glx_> yes
21:39:03 <_glx_> if you did all your tests with debug build they are useless
21:39:28 <xarick> nop, it was release build, but they still have asserts
21:39:41 <peter1138[d]> Note I said releases, not release build ๐Ÿ™‚
21:40:33 <xarick>
21:40:48 <peter1138[d]> OPTION_USE_ASSERTS ON
21:41:20 <_glx_> stable releases yes, you can add `-DOPTION_USE_ASSERTS=OFF` to your cmake config
21:41:48 <peter1138[d]> Of course if you disable asserts, your code will probably break in horrible ways :p
21:42:24 <xarick> there should be a dropdown there with a choice for no asserts
21:43:06 <_glx_> you can add more config than MSVC provides by default
21:43:09 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11631: Fix #11629: AirportGetNearestTown for rotated airports
21:43:12 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #11629: [Crash]: Assertion triggered when getting nearest town of rotated airport
21:43:18 <_glx_>
21:43:54 <_glx_> I don't have a "no assert" one ๐Ÿ™‚
21:44:05 <peter1138[d]> There is no 'no assert' variant.
21:44:16 <_glx_> but I could
21:44:31 <peter1138[d]>
21:44:56 <peter1138[d]> Those are the things VS Code gives. Dunno why MSVC thinks you want to build for x86 and x64...
21:44:58 <_glx_> yeah that's the 4 cmake options
21:45:17 <xarick> I don't have more than 1 option for the Release variants
21:45:33 <_glx_> I have a customised CMakePresets.json
21:47:24 <_glx_>
21:47:24 <_glx_> the presets also has WSL
21:47:51 <_glx_> for grfcodec I added more options for linux
21:48:22 <_glx_> well just a clang option
21:48:59 <xarick> how do I make it list Debug, Release, MinSizeRel, RelWithDebInfo?
21:49:27 <_glx_> you really only need Debug and RelWithDebInfo
21:50:07 <xarick> did you manually input those in? I thought it was a preset, loaded from somewhere
21:50:16 <_glx_> but you can add config via "manage configurations..."
21:50:46 <_glx_> I added stuff to the basic preset file
21:53:06 <talltyler> Oh yay, more conflicts ๐Ÿ˜›
21:53:16 <peter1138[d]> \zo/
21:53:19 <_glx_> <>
21:53:28 <peter1138[d]> Sorry :p
21:53:34 <talltyler> Jk, the YMD improvement is good ๐Ÿ™‚
21:54:07 <_glx_> learn how to use the tools ๐Ÿ™‚
21:55:06 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #11633: Fix: Changing default livery did not propagate to group liveries.
22:05:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #11607: Fix: Compilation with DEBUG_DUMP_COMMANDS enabled
22:13:25 <xarick>
22:13:25 <xarick> can't make it work
22:20:50 <_glx_> you can't have more than 1 configurationType in open folder mode
22:21:48 <reldred> Are there any chicken scratchings anywhere about setting up VS Code to build OpenTTD? I've never had too many problems getting VS2022 to build but VS Code gives me the shits (but it's what I use for pretty much everything else...)
22:25:14 <xarick> I disable asserts, but it keeps enabling them on refresh
22:26:15 <_glx_> reldred: I think the first step is to install "cmake tools" extension
22:27:28 <reldred> _glx_: Yeah I installed the cmake and cmake tools extension plugins, over on VS2022 I'd just throw in my additional command line arg to load the VCPKG stuff but it never seems to work in vs code
22:30:31 <xarick>
22:30:31 <xarick> this doesn't save my changes for some reason
22:31:50 <_glx_>
22:31:50 <_glx_> I just tested opening my folder in vscode, then I selected one of my usual presets for configure
22:32:17 <_glx_> that's where you set vcpkg stuff
22:34:21 <_glx_> xarick: then open the json directly
22:34:40 <_glx_> it's simpler to edit the file than using the GUI
22:35:33 <_glx_> and btw the method you are using is being deprecated and replaced by presets
22:35:50 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:36:48 *** rau117 has quit IRC (Quit: User went offline on Discord a while ago)
22:39:27 <truebrain> oops @ thread issues .. I should have checked that ๐Ÿ˜„ Seems some locking is in order ... ๐Ÿ˜›
22:39:58 <peter1138[d]> Or a message buffer.
22:40:15 <truebrain> a thread-safe queue you mean?
22:40:17 <_glx_> hmm could that explain the hangs ?
22:41:24 <xarick>
22:41:24 <xarick> too noob for this vscode stuff
22:41:55 <_glx_> I didn't say to switch to vscode
22:42:10 <xarick> how do I do whatever the heck the notification says?
22:42:44 <xarick> ^- ^
22:44:20 <_glx_> VS does a lot of things automatically compared to VSCode
22:45:06 <xarick> oki
22:48:18 <reldred> _glx_: Thanks. Might ping you later today/tomorrow when Iโ€™m back at my windows PC, Iโ€™m infront of a Mac atm for the next eight hours..
22:52:17 <truebrain> yeah, okay, OnReceiveData is always called from the ottd:http thread ... that gives a bit nasty side-effects ๐Ÿ˜›
22:53:10 <truebrain> so indeed, a queue between there, and it should be fine ๐Ÿ™‚
22:53:55 <truebrain> and `isCancelled` needs to be an atomic boolean, I guess ๐Ÿ™‚
22:54:19 <truebrain> pretty likely this is also an issue on Windows ๐Ÿ™‚
22:55:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #11636: [Bug]: Various thread safety issues with use of libcurl for HTTP downloads
23:01:41 <xarick> ah, OPTION_USE_ASSERTS is a string, not a bool
23:01:59 <xarick> "OFF", "ON", this is detected incorrectly
23:02:19 <xarick> it's not true or false, it's "OFF", "ON"
23:03:41 <xarick> how do I make sure this really built with disabled asserts?
23:04:36 <xarick> hmm let's try assert(false); somewhere
23:05:58 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:06:13 <xarick> yeah! it works! it's not asserting!
23:09:10 <xarick>
23:11:36 <xarick>
23:11:36 <xarick> very nice
23:14:29 <xarick>
23:14:29 <xarick> interesting, the gains enlarged
23:16:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #11633: Fix: Changing default livery did not propagate to group liveries.
23:16:24 <_glx_> yeah asserts slow things
23:17:12 <xarick>
23:18:03 <xarick> the first image: Train *t = Train::From(const_cast<Vehicle *>(v));
23:18:03 <xarick> the third image: Train *t = Train::From(Vehicle::Get(v->index));
23:18:41 <_glx_> not surprising
23:19:32 <_glx_> Get needs to ask the pool, while the cast just change the pointer type
23:21:40 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:22:12 <peter1138> const_cast should be avoided.
23:24:18 <xarick> okay... I was about to use const_cast everywhere
23:24:21 <xarick> guess not
23:25:33 <_jgr_> Using Vehicle::Get to obfuscate the fact that it's really a const_cast is not something to do for the sake of it either
23:26:33 <peter1138[d]> Just make your list items non-const if it needs to be non-const.
23:26:46 <peter1138[d]> You are then not pretending it is something it is not.
23:27:41 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
23:27:53 <xarick> oh, I'll try that tomorrow
23:40:51 <xarick> oops, the include was supposed to be removed
23:46:42 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10548: Feature: Groups cache vehicle lists
23:47:16 <xarick> bed time, cyas goodnight