IRC logs for #openttd on OFTC at 2024-04-07
            
00:28:34 *** Ox7C5 has quit IRC ()
00:30:30 *** Smedles has quit IRC (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
00:33:01 *** Smedles has joined #openttd
02:02:21 *** herms has quit IRC (Quit: bye)
02:02:59 *** herms has joined #openttd
02:03:20 *** Wormnest has quit IRC (Quit: Leaving)
02:15:11 *** bertvvvs has quit IRC (Quit: You have a nice day.)
02:48:45 *** gnu_jj has joined #openttd
02:52:12 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:54:13 *** debdog has joined #openttd
02:57:37 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:27:30 <DorpsGek> [OpenTTD/OpenTTD] CI - Nightly workflow was not successful https://github.com/OpenTTD/OpenTTD/actions/runs/8585750035
03:44:31 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:53:10 *** keikoz has joined #openttd
04:20:16 *** keikoz has quit IRC (Ping timeout: 480 seconds)
04:24:18 *** keikoz has joined #openttd
04:41:26 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/0f6bf90731049777f5da67ffb4a639ef4d4c8156
04:41:27 <DorpsGek> - Update: Translations from eints (by translators)
05:26:44 <DorpsGek> [OpenTTD/OpenTTD] Release workflow was not successful https://github.com/OpenTTD/OpenTTD/actions/runs/8586358991
05:55:57 <peter1138> _glx_: What about GRM? Is that handled with something else in NML?
06:03:00 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12440: Codechange: replace most uses of lengthof with std::size https://github.com/OpenTTD/OpenTTD/pull/12440
06:04:27 *** keoz has joined #openttd
06:06:17 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:08:18 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12441: Codechange: Use std::initializer_list/array in framerate window. https://github.com/OpenTTD/OpenTTD/pull/12441#pullrequestreview-1984853209
06:11:49 *** keikoz has joined #openttd
06:13:31 *** keoz has quit IRC (Ping timeout: 480 seconds)
06:18:17 <peter1138> Hmm, or is GRM reservation not possible with NML.
06:25:03 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12440: Codechange: replace most uses of lengthof with std::size https://github.com/OpenTTD/OpenTTD/pull/12440
06:30:44 <DorpsGek> [OpenTTD/website] rubidium42 commented on pull request #313: Add: post about the XZ backdoor and the effect on us https://github.com/OpenTTD/website/pull/313#pullrequestreview-1984856848
06:33:04 *** keoz has joined #openttd
06:34:57 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:38:05 <DorpsGek> [OpenTTD/website] rubidium42 updated pull request #313: Add: post about the XZ backdoor and the effect on us https://github.com/OpenTTD/website/pull/313
06:44:56 *** nielsm has joined #openttd
07:09:06 *** keoz has quit IRC (Ping timeout: 480 seconds)
07:32:01 *** Ox7C5 has joined #openttd
07:46:08 <pickpacket> I'd like to try to implement this: https://www.tt-forums.net/viewtopic.php?p=1268840 but I have trouble finding where in the code autoservice is handled
07:46:16 <pickpacket> figuring that's a good starting point
07:50:15 *** Wolf01 has joined #openttd
07:52:07 <peter1138> There's some "obvious" places that deal with automatic servicing.
07:53:22 <peter1138> But there are reasons why autorenew/replace are dependent on either manual servicing, or automatic service interval.
07:54:44 <pickpacket> peter1138: I'd love to know those reasons :D
07:57:32 <pickpacket> Would help me decide whether it's worth trying this or not
07:57:48 *** keikoz has joined #openttd
07:58:46 <peter1138> If autorenew fails, then without the service interval limiting it, it would then want to immediately try to autorenew again.
08:01:53 *** gelignite has joined #openttd
08:04:50 *** keikoz has quit IRC (Remote host closed the connection)
08:05:01 *** keikoz has joined #openttd
08:06:41 <truebrain> wow, trying to understand what this `default-baseline` does in `vcpkg.json` seems to require a grade in rocket science
08:07:05 <truebrain> initially we thought it would mean that it sets just a minimum, but that when vcpkg updates libraries, we would get the latest too
08:07:16 <truebrain> but in that case, liblzma should have been bumped to 5.6.0 on March 11th
08:07:18 <truebrain> it didn't
08:07:38 <truebrain> so reading the documentation about `default-baseline` again, it doesn't actually make it more clear what it actually does
08:07:53 <truebrain> it "sets a baseline for versions" .. like .. yeah .. what the fuck did you now actually try to tell me?
08:08:16 <truebrain> it is an art to write documentation in such way that it has no practical use to anyone
08:08:45 <truebrain> `Baselines define a global version floor for what versions will be considered.` is on another page, as their explanation ...
08:13:49 <truebrain> either way, seems we do need to update this baseline from time to time to get the latest of the latest πŸ™‚ Good to know!
08:14:40 <truebrain> `vcpkg uses a minimal selection approach to versioning` ... `vcpkg will use the "oldest" possible versions of packages that can satisfy all the constraints`
08:15:41 <pickpacket> peter1138: oh! Hmm. I’ll have to mull that over a bit. How is that handled with autoreplace?
08:16:14 <peter1138> No differently.
08:17:38 <peter1138> Not insurmountable, but you need a cool down timer of some sort (who decides how long that should be), that is automatically provided by servicing interval.
08:19:06 <peter1138> Looking for places where we cast an array from one type to another...
08:19:45 <pickpacket> I mean, if I could handle it the same way as autoreplace then it would be fine
08:20:06 <peter1138> Guess when autoreplace happens?
08:21:58 <pickpacket> When triggered by player?
08:22:26 <peter1138> When do players trigger it?
08:22:40 <pickpacket> When new vehicles are available?
08:23:53 <pickpacket> But when an autoreplace fails, how is that handled?
08:24:35 <peter1138> So "when new vehicles are available" triggers autoreplace?
08:24:39 <peter1138> Nope.
08:24:59 <peter1138> I think you're confusing "setting up an autoreplace" with "triggers autoreplace"
08:25:18 <pickpacket> Yeah, I don’t quite understand the question
08:26:25 <peter1138> The question was, when does autoreplace happen?
08:26:38 <pickpacket> When the vehicle enters a depot
08:26:48 <peter1138> Right.
08:26:56 <peter1138> When does autorenew happen?
08:27:06 <pickpacket> When the vehicle enters a depot
08:27:23 <peter1138> > I mean, if I could handle it the same way as autoreplace then it would be fine
08:27:31 <peter1138> So...
08:28:29 <peter1138> Okay.
08:28:49 <peter1138> Basically, there is no difference in terms of when autorenew/autoreplace happen.
08:28:59 <peter1138> It happens when a vehicle goes to a depot.
08:29:20 <pickpacket> The difference -- as I understand it -- lies in how the action is set up. Autoreplace requires player interaction, but once that interaction has happened the trains will get an order to go to a depot regardless of service interval or autoservicing
08:29:22 <peter1138> And they go to a depot either when manually command (not really automatic so not an option here)
08:29:33 <peter1138> Or when it's in their order list (still not really automatic)
08:29:53 <peter1138> Or when the service interval is up and they need to be serviced. Automatic, but you've turned off servicing, so they don't do it.
08:31:20 <peter1138> Setting up autoreplace does not give vehicles orders to go to a depot.
08:31:47 <pickpacket> What does it do?
08:32:11 <peter1138> Setting up autoreplace tells the game to replace the vehicle when it enters a depot.
08:32:50 <pickpacket> Could autorenew do the same thing, but get set up when "Autorenew when vehicle is X maximum age" is reached?
08:33:05 <peter1138> Autorenew does exactly the same thing.
08:33:29 <pickpacket> well my point is that when I order my trains to autoreplace they will go to a depot and do that, even if autoservicing is disabled
08:33:59 <peter1138> Okay.
08:34:16 <pickpacket> so in one way or another an order to go to a depot is given to the vehicles
08:34:25 <peter1138> Setting up autoreplace is not the same as pressing the button to manually send vehicles to the depot to autoreplace now.
08:34:33 <peter1138> The latter is a manual action.
08:38:07 <peter1138> Actually, where is the button to tell them to autoreplace?
08:38:17 <pickpacket> I really need an explanation of the definitions here :D The actions I see are 1) I go to the vehicle list, 2) I choose "Replace vehicles", 3) I pick the replacements I want to happen, 4) I click "Start replacing vehicles", 5) the vehicles enter a depot when they can (if I have more money than the "Autorenew minimum needed money for renew" limit,
08:38:17 <pickpacket> which apparently also applies to replace) and become autoreplaced if possible
08:39:29 <pickpacket> What I'd like to happen in this case is 1b) The "Autorenew when vehicle is X maximum age" for a vehicle is reached, followed by 5 above
08:39:30 <Rubidium> so what pickpacket essentially needs is: 1) when autoreplace is configured for a vehicle, forbid it to be built as new vehicle, 2) when you click "Start replacing", also perform a mass "Send to depot for servicing"
08:39:59 <peter1138> Start Replacing, afaik, does not send vehicles to depots.
08:40:01 <locosage> autoreplace already sends vehicles to depots just fine, autorenew doesn't
08:40:36 <locosage> it doesn't send them all at once thankfully
08:41:01 <peter1138> When do you think they are "sent" to a depot?
08:41:04 <pickpacket> Rubidium: no, it's doesn't perform the same as "send to depot for servicing" because that action stops whatever it's doing atm and sends it to a depot. When vehicles are set to be replaced they do that when there is a path to a depot
08:41:16 <locosage> idk, probably same as servicing
08:41:26 <peter1138> Yes, exactly that.
08:41:53 <locosage> but it works with servicing disabled
08:41:58 <pickpacket> Rubidium: I don't know why it would be forbidden to be built as new vehicle? Not sure how that plays in
08:42:06 <pickpacket> locosage: exactly!
08:42:31 <peter1138> No it doesn't.
08:42:39 <pickpacket> peter1138: yes it does.
08:43:10 <pickpacket> I always play with servicing disabled but when I choose "start replacing" they find a depot and get replaced
08:43:31 <locosage> if it didn't work without servicing autoreplacing without breakdowns (and servicing) would've been a huge pita
08:43:32 <pickpacket> independent of any service interval or autoservicing
08:44:47 <peter1138> Fine.
08:45:00 <peter1138> I'm wrong πŸ˜„ But also right.
08:45:05 <pickpacket> lol
08:45:07 <peter1138> Autoreplace does not send vehicles to depot.
08:45:14 <pickpacket> ...but?
08:45:18 <peter1138> They go to the depot based on service interval.
08:45:51 <peter1138> The relevant function is Vehicle::NeedsServicing()
08:46:07 <peter1138> There's stuff to handle autoreplace in there and it mentions autorenewing too.
08:46:21 <pickpacket> nice! I'll have a look there!
08:47:52 <peter1138> It's probably deliberately done that way because if breakdowns are disabled then you don't need to worry about the reliability, so autorenewing isn't that important.
08:49:22 <Rubidium> pickpacket: never mind, I missed something when reading going off on a wrong tangent
08:49:38 <peter1138> Are you intending to autorenew a vehicle every year?
08:50:07 <peter1138> Keep the fleet fresh...
08:50:19 <peter1138> The autorenew limits don't really allow that as far as I know.
08:51:39 <peter1138> Vehicle age has to be less than 3 years, and it depends on the last vehicle that visited, not any average spread out over all vehicles that visit.
08:52:36 <Rubidium> peter1138: how low can you influence the maximum vehicle's age with a NewGRF?
08:53:32 <peter1138> Probably 0.
08:54:35 <peter1138> On the other hand.
08:55:15 <pickpacket> peter1138: the age of a vehicle impacts station rating
08:55:19 <peter1138> I guess autorenew is so infrequent that doing it even with servicing disabled wouldn't have much impact.
08:55:32 <peter1138> Yes, but only up to 3 years.
08:55:44 <peter1138> Autorenew will be doing it at the 15-20 year mark.
08:55:52 <pickpacket> hmm. That's true
08:56:15 <peter1138> (Or however many months you set before that)
08:57:07 <pickpacket> I guess replacing very frequently would eat up all the profit from a vehicle too
08:57:12 <pickpacket> *renewing
08:57:19 <peter1138> Given you can disable autorenew if you want, I see no harm in doing autorenew even with servicing disabled.
08:57:37 <peter1138> But I don't think it'll have much impact on station ratings πŸ™‚
08:57:47 <pickpacket> no harm, but is there a point? :)
08:57:47 <locosage> profit is not always the concern
08:57:57 <locosage> also it's probably more profitable to replace anyway
08:58:10 <pickpacket> locosage: replace or renew?
08:58:20 <locosage> yeah, renew, sry
08:58:47 <peter1138> If the point is to stop people complaining that autorenew doesn't happen when automatic servicing is disabled... then I guess so πŸ˜„
08:58:51 <pickpacket> oh yeah! Renew isn't as expensive as buying it all new, is it?
08:59:04 <pickpacket> peter1138: I don't know if anyone but me is complaining, though πŸ˜‚
08:59:06 <peter1138> Well, after 20 years you'll have lost quite a bit of value.
08:59:15 <peter1138> I don't think you're the first.
09:00:22 <locosage> iirc renew is the same as selling a buing new but for extra 13% of cargo it's likely worth it
09:00:37 <locosage> roi on trains is extremely fast
09:00:52 <Rubidium> renew is only cheaper by the time lost the vehicle is in depot when buying a new vehicle manually and selling the old vehicle
09:01:21 <pickpacket> If the point is (as it is for me) to keep station ratings as high as possible then setting the renewal interval to a fixed time instead of dependent on vehicle lifetime makes more sense
09:01:29 <Rubidium> but then, depending on the route, it might be cheaper to just buy new trains at the source and sell them at the destination as that saves you the "cost" of moving the train back
09:01:33 <xarick> hi
09:01:45 <pickpacket> I don't know how people playing with breakdowns enabled wants that setting
09:01:57 <pickpacket> Rubidium: haha, yeah
09:02:18 <pickpacket> Rubidium: there's usually a fair bit of "only makes profit one way" vehicles
09:02:25 <locosage> anyway, regeradless of profits, there certainly are situations in the game where updating the fleet is beneficial
09:02:53 <locosage> there is a number of cb tricks with delaying replacement or replacing back to older model to get that rating boost at the perfect time
09:03:14 <pickpacket> cb?
09:03:20 <locosage> city-builder
09:03:23 <pickpacket> ah
09:04:04 <locosage> but applies to many high-end competitive goals
09:04:39 <xarick> I like breakdowns
09:04:48 <peter1138> Sounds like you've entered a rabbit hole... "implement auto-renew based on age instead of model life"
09:04:58 <pickpacket> peter1138: yup
09:05:25 *** ahyangyi has joined #openttd
09:05:25 <ahyangyi> xarick: We need a breakdown emoticon
09:05:43 <pickpacket> conditional orders can be used, but then I'd have to choose a specific depot and if I forget that I have and destroy that depot...
09:05:49 <xarick> what i don't like about breakdowns is that they are temporary vehicles 😦
09:06:04 <pickpacket> xarick: how do you mean?
09:06:28 <xarick> they are added to the vehicle pool
09:06:29 <reldred> breakdowns good
09:06:45 <reldred> they could be better though
09:07:08 <peter1138> The visual effect of breakdowns is implemented by creating a new "effect vehicle"
09:07:17 <pickpacket> oh!
09:07:36 <pickpacket> so if you've reached the limit of allowed vehicles..?
09:07:47 <merni> I don't think effect vehicles count for those
09:07:49 <peter1138> When you are mad and run the game at its limits, that means Xarick's scripts that constantly list vehicles slow down πŸ˜‰
09:07:58 <merni> Heck even smoke is a "vehicle" I think
09:08:25 <locosage> yeah, smoke is the worst
09:08:28 <peter1138> Hmm, not run a full cppcheck for a while, Not since the C++20 change.
09:08:34 <locosage> at least breakdowns don't happen that often to matter
09:08:55 <xarick> oh depends on the AI and how they manage old stuff
09:09:13 <merni> locosage: smoke doesn't matter either unless you are running far too big map/too many vehicles :P
09:09:33 <ahyangyi> I'm doing both, now it matters
09:09:39 <merni> A train game with steam engines that don't emit smoke... would be ridiculous
09:09:49 <locosage> it doesn't matter for a player but it's a mess code-wise
09:10:12 <pickpacket> of course it matters
09:10:39 <pickpacket> vehicles emitting exhaust when running or smoke when broken is really charming
09:10:43 <merni> by "matter" I mean performance-wise
09:10:50 <merni> not looks-wise
09:10:54 <merni> looks-wise of course they matter
09:11:07 <locosage> performance-wise it actually may be noticeable, at least until some recent changes
09:11:29 <pickpacket> merni: yeah, I meant to correct locosage's claim that it doesn't matter for a player :)
09:11:44 <locosage> as there were some loops over all the vehicles that didn't need to iterate smoke
09:11:49 <locosage> not sure if any still left
09:12:06 <merni> this channel sadly has many people who don't play, or play far less than they code :P
09:12:06 <peter1138> Plenty of loops iterate all vehicles still.
09:12:48 <locosage> pickpacket, I'm not saying removing smoke, just not keeping in a separate pool from vehicles
09:13:16 <merni> well, if you find a better way, I'm sure PR would be appreciated :P
09:13:21 <locosage> so no visible effect for player except for some possible performance benefit
09:13:39 <peter1138> Then adding vehicles to the viewport would be interesting...
09:13:51 <pickpacket> locosage: oh, yeah
09:13:51 <locosage> *extra not snuck in, fixed in discord
09:14:10 <ahyangyi> merni: on the other hand, those (non-iron) horses breaking down and emitting smoke is slightly ridiculous...
09:14:23 <merni> It's farts
09:14:28 <pickpacket> ahyangyi: I especially love those! πŸ˜‚
09:14:35 <merni> F*rt is a bad word...?
09:14:43 <pickpacket> Of course a horse breaks if you set it on fire
09:15:29 <merni> Well, IRC saw what I said anyway
09:15:40 <pickpacket> IRC <3
09:22:31 <xarick> STR_JUST_STRING4 has happeared
09:22:42 <xarick> eh my english
09:23:28 <peter1138> sprite aligner needed it πŸ™‚
09:23:50 <pickpacket> https://www.tt-forums.net/viewtopic.php?p=1268841#p1268841
09:25:57 <peter1138> Hmm, I wonder if previous/next sprite buttons should work through the GRF sprite order instead of loaded sprite order.
09:26:22 <peter1138> Although not sure if that's feasible.
09:27:17 <pickpacket> peter1138: I don't think that'd make a big enough difference to be worth the effort, tbh
09:27:45 <peter1138> It sounded simple until I realised I'd have to search through the spritecache to find them.
09:28:45 <pickpacket> ugh. Yeah that doesn't sound very fun
10:17:21 <DorpsGek> [OpenTTD/eints] gh658804 opened issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
10:19:54 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1226476539856551986/2024-04-07_11-18-04.mp4?ex=6624e849&is=66127349&hm=153fcefc8ed8986f594c8f680d371729728e96da5e21a044e07f811961093f68&
10:19:54 <xarick> variable opcodes
10:20:03 <xarick> fine tuning
10:21:19 <xarick> can't seem to stabilize for AroAI
10:22:59 <xarick> NotPerfectAI also
10:29:49 <xarick> it's in a much better state though
10:29:59 <xarick> it used to go straight from 250k to 500 😦
10:33:07 *** keikoz has quit IRC (Ping timeout: 480 seconds)
10:38:31 <_zephyris> peter1138: Realistically local sprite order is preserved, so not worth worrying about
10:48:12 <DorpsGek> [OpenTTD/eints] frosch123 closed issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
10:48:15 <DorpsGek> [OpenTTD/eints] frosch123 commented on issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
11:01:36 *** keikoz has joined #openttd
11:23:51 <_glx_> peter1138: NML has `reserve()`
11:27:07 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1226493454469824614/image.png?ex=6624f80a&is=6612830a&hm=5cf47af3dbb647523a5d77b2763177b32e43ea6c57366141444f040ba982ab31&
11:27:07 <xarick> Path of Exile related πŸ™‚
11:28:08 <xarick> Templar/Witch OP
11:28:28 <xarick> Shadow/Ranger UP
11:55:39 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12444: Codechange: use std::size instead of lengthof for town names https://github.com/OpenTTD/OpenTTD/pull/12444
11:59:40 *** keikoz has quit IRC (Remote host closed the connection)
11:59:51 *** keikoz has joined #openttd
12:02:03 <DorpsGek> [OpenTTD/eints] gh658804 commented on issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
12:04:07 <DorpsGek> [OpenTTD/eints] merni-ns commented on issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
12:06:24 <DorpsGek> [OpenTTD/eints] gh658804 commented on issue #186: Minor cosmetic issue in Languages main screen https://github.com/OpenTTD/eints/issues/186
12:36:35 <xarick> is it intended that the framerate graph windows don't close when an AI bankrupts?
12:39:45 <xarick> I wonder what's the hardest tileset for AIs
12:41:29 *** keikoz has quit IRC (Remote host closed the connection)
12:41:41 *** keikoz has joined #openttd
12:56:06 *** keoz has joined #openttd
12:57:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
13:02:28 *** keikoz has joined #openttd
13:04:22 *** keoz has quit IRC (Ping timeout: 480 seconds)
13:09:30 <_glx_> non closing of framerate window is most likely not intended, just never handled
13:26:26 <truebrain> truebrain: _glx_ also for your information; vcpkg baseline is not what I thought it was πŸ™‚
13:27:02 <_glx_> I never really understood what it is πŸ™‚
13:36:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12445: Codechange: use single function returning std::span over two functions that return size and begin https://github.com/OpenTTD/OpenTTD/pull/12445
13:57:38 *** charlieatlas_ff03k64 has joined #openttd
13:57:38 <charlieatlas_ff03k64> I am curious how hard it would be to change the number of cargoes available. I assume if it was easy, it would probably be done. Is it something that is really complex and touches code everywhere? Or is it something in between that noone has had interest in doing?
14:01:51 <Rubidium> are you talking about more than 64?
14:03:48 <charlieatlas_ff03k64> Yeah
14:12:16 <Rubidium> since there are bitmasks of cargoes, you'd need to create some other manner to retain a bitmask-like thing for more than 64 values. Changing that throughout the game seems to be a massive task. And then I'm not sure what kinds of problems you're running into in the NewGRF specification
14:19:55 <_glx_> and working with more than 64 bits can affect performance
14:28:02 *** Flygon has joined #openttd
14:35:52 *** keikoz has quit IRC (Read error: Connection reset by peer)
14:57:23 <DorpsGek> [OpenTTD/nml] glx22 opened pull request #324: Add: Basic range check for replace() https://github.com/OpenTTD/nml/pull/324
15:07:55 *** keikoz has joined #openttd
15:18:02 <peter1138> Why though.
15:18:13 <peter1138> 64 was consider way more than anyone would ever need.
15:20:06 <peter1138> Hmnm, even with int32_t, scrollbars still break when using large counts πŸ˜„
15:20:47 <peter1138> Probably "don't do that" is sensible.
15:33:10 <andythenorth> 256 cargo refit lists, minimap cargoflow, cdist overlay, station cargo waiting lists, vehicle refit list, industry-cargo flow views
15:33:21 <andythenorth> 'super' our UI will be so great
15:33:43 <andythenorth> but at least there'll be a spare cargo for the subtype callback livery stuff
15:34:24 <_jgr_> Not every single industry flow needs its own cargo type
15:35:34 <andythenorth> I believe that limits are only found by exceeding them πŸ˜›
15:35:41 <andythenorth> and FIRS 5 has 63 cargos in Steeltown
15:35:45 <andythenorth> and it's "enough"
15:37:57 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1226556581341036604/image.png?ex=662532d5&is=6612bdd5&hm=dfd696dfd8d0eb32c85a0093aead93a3f54cd1a5792738dfe0dc4b435a1314aa&
15:37:57 <andythenorth> in my current game, the disabled cargos are not yet transported
15:38:41 <andythenorth> 14h of play by wallclock
15:39:32 <andythenorth> there is a layer of tertiary production which I rarely get to, I've played about 10 test games I think
15:41:45 <andythenorth> tempting to remove it πŸ˜›
15:46:25 <_jgr_> Transporting mail but not passengers seems a bit odd to me
15:47:13 <locosage> https://cdn.discordapp.com/attachments/1008473233844097104/1226558914779152414/Screenshot_from_2024-04-07_22-43-33.png?ex=66253501&is=6612c001&hm=010e81e3d87fb2b8b6bcced8f01dd450c52f2b910299e0572d920a5d39f6a23a&
15:47:13 <locosage> 15 year game on citymania xD
15:47:20 <locosage> numbers are one quarter
15:48:41 <andythenorth> _jgr_: oops, yes there is pax transport, but the mail links overlay it
15:48:46 <andythenorth> PEBKAC
15:49:14 <andythenorth> quite tempted to try and strip a layer out of Steeltown
15:49:37 <andythenorth> it's not bad to play at all, but I have to draw a *lot* of similar looking tertiary factories
15:49:47 <andythenorth> and I'm not getting round to it πŸ˜›
15:51:05 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1226559887413350470/image.png?ex=662535e9&is=6612c0e9&hm=148f6b72a01af5e9c689d973eac75401b8eba812cf9e2e583920e1b3afcdac98&
15:51:05 <andythenorth> well strictly it's 6 πŸ˜›
15:52:28 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12444: Codechange: use std::size instead of lengthof for town names https://github.com/OpenTTD/OpenTTD/pull/12444#pullrequestreview-1985121670
15:53:10 <_jgr_> I've been playing my current game since late 2020, using XIS, and there are several cargoes I still haven't bothered with
15:53:22 <andythenorth> it aids replayability somewhat
15:53:32 <andythenorth> but it's also overkill
15:57:36 *** keikoz has quit IRC ()
15:57:55 *** Wormnest has joined #openttd
16:18:48 *** keikoz has joined #openttd
16:28:46 <charlieatlas_ff03k64> locosage: How did you get this list?
16:33:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12444: Codechange: use std::size instead of lengthof for town names https://github.com/OpenTTD/OpenTTD/pull/12444
16:41:14 *** keoz has joined #openttd
16:42:52 *** keikoz has quit IRC (Ping timeout: 480 seconds)
16:43:00 <peter1138> Any of my comments are "don't do this", they're more "I don't understand this" πŸ™‚
16:43:04 <peter1138> ...
16:43:09 <peter1138> ARE NOT...
16:56:19 <locosage> charlieatlas_ff03k64: citymania patchpack
17:36:09 <andythenorth> not convinced FIRS Steeltown needs Wire Rope cargo chain
17:38:33 <andythenorth> hmm, can't remove it in my test game, as cargo order is significant
17:38:50 <andythenorth> silly cargo slot IDs πŸ™‚
18:16:49 *** keikoz has joined #openttd
18:18:41 *** keoz has quit IRC (Ping timeout: 480 seconds)
18:19:34 <andythenorth> Or did peterer fix those? πŸ˜›
18:26:37 *** dih has quit IRC (Ping timeout: 480 seconds)
18:27:51 *** Gadg8eer[m] has quit IRC (Quit: Client limit exceeded: 20000)
19:00:30 <kuhnovic> He probably has a patch for that
19:05:46 <andythenorth> think it fixed CargoType, but not grf-defined cargos
19:12:10 <peter1138> I have not done anything that would allow cargo labels to be moved around.
19:12:29 <peter1138> I could perhaps, but generally we stick with "don't change NewGRFs"
19:13:18 <peter1138> (Amusingly, for rail types there is a whole mapping system, which was never implemented for road types)
19:15:05 *** brickblock19280 has joined #openttd
19:15:05 <brickblock19280> ?
19:15:12 <andythenorth> moving cargos is quite a niche newgrf developer thing πŸ˜›
19:15:19 <peter1138> Cargo type storage is more problematic, as often it is position-based.
19:16:43 *** Ox7C5 has quit IRC ()
19:16:43 <peter1138> <https://github.com/libarchive/libarchive/pull/1609> looks like libarchive had some previous treatment too..
19:38:59 *** gelignite has quit IRC (Quit: Stay safe!)
19:40:00 *** keoz has joined #openttd
19:41:37 *** keikoz has quit IRC (Ping timeout: 480 seconds)
19:41:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12446: Codechange: use range-based for loop for debug levels and fix global variable naming https://github.com/OpenTTD/OpenTTD/pull/12446
19:44:47 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #12446: Codechange: use range-based for loop for debug levels and fix global variable naming https://github.com/OpenTTD/OpenTTD/pull/12446#pullrequestreview-1985178030
19:49:43 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #12447: Codechange: Use begin/end instead of endof for some industry arrays. https://github.com/OpenTTD/OpenTTD/pull/12447
19:49:53 <peter1138> These things eh.
19:51:54 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #12448: Codechange: Use dynamic_cast instead of C-cast after FindWindowById. https://github.com/OpenTTD/OpenTTD/pull/12448
19:54:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:56:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #12445: Codechange: use single function returning std::span over two functions that return size and begin https://github.com/OpenTTD/OpenTTD/pull/12445#pullrequestreview-1985179278
19:56:57 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12447: Codechange: Use begin/end instead of endof for some industry arrays. https://github.com/OpenTTD/OpenTTD/pull/12447#pullrequestreview-1985179398
19:57:28 <DorpsGek> [OpenTTD/nml] glx22 updated pull request #324: Add: Basic range check for replace() https://github.com/OpenTTD/nml/pull/324
20:00:44 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12449: Codechange: use range-based for loops and let count be correct count https://github.com/OpenTTD/OpenTTD/pull/12449
20:01:50 <silent_tempest> If the commit checker flags a commit.
20:02:17 <silent_tempest> I have to close the PR and try again with the ammend commit?
20:02:20 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #12445: Codechange: use single function returning std::span over two functions that return size and begin https://github.com/OpenTTD/OpenTTD/pull/12445
20:02:46 <peter1138> No.
20:02:49 <Rubidium> just fix the commit message and force push
20:03:35 <silent_tempest> Okay I'll give it a shot
20:05:45 <silent_tempest> Hmn I'm way out of date. It wants me to do a pull
20:08:53 <DorpsGek> [OpenTTD/OpenTTD] ladysadie updated pull request #12413: Codechange: Remove per font AA settings. https://github.com/OpenTTD/OpenTTD/pull/12413
20:09:57 <silent_tempest> Hmn okay it looks like that worked.
20:18:01 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #12446: Codechange: use range-based for loop for debug levels and fix global variable naming https://github.com/OpenTTD/OpenTTD/pull/12446
20:27:31 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12337: Change: replace company passwords with allowlist https://github.com/OpenTTD/OpenTTD/pull/12337
20:30:23 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12450: Codechange: replace for loops with endof with range-based for loops https://github.com/OpenTTD/OpenTTD/pull/12450
21:01:24 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12451: Endof remnants https://github.com/OpenTTD/OpenTTD/pull/12451
21:01:50 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #12447: Codechange: Use begin/end instead of endof for some industry arrays. https://github.com/OpenTTD/OpenTTD/pull/12447
21:03:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #12444: Codechange: use std::size instead of lengthof for town names https://github.com/OpenTTD/OpenTTD/pull/12444#pullrequestreview-1985252139
21:03:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12448: Codechange: Use dynamic_cast instead of C-cast after FindWindowById. https://github.com/OpenTTD/OpenTTD/pull/12448#pullrequestreview-1985252279
21:03:54 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #12449: Codechange: use range-based for loops and let count be correct count https://github.com/OpenTTD/OpenTTD/pull/12449#pullrequestreview-1985252285
21:04:12 <peter1138> So many of these are familiar... just lost in a sea of "other stuff" I've looked at πŸ™‚
21:04:21 <peter1138> "I've got a stash for that"
21:04:54 <truebrain> Does it make compile times better? πŸ˜›
21:05:33 <peter1138> Most of them suffer from "don't know when to stop-itis" so they get too big and than include other things.
21:05:57 <peter1138> Just get a faster CPU for better compile times πŸ˜„
21:06:37 <truebrain> Not many CPUs are better, that is the issue! πŸ˜›
21:06:44 <truebrain> EPYC? Hmmm
21:08:11 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #12444: Codechange: use std::size instead of lengthof for town names https://github.com/OpenTTD/OpenTTD/pull/12444
21:08:36 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #12449: Codechange: use range-based for loops and let count be correct count https://github.com/OpenTTD/OpenTTD/pull/12449
21:30:29 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1226645298701402152/image.png?ex=66258575&is=66131075&hm=b67095a07b416c311c59b8a6196ae5af132f7d16244b38f8a4a80c7b060794e5&
21:30:29 <xarick> Otvi is hard to handle
21:30:44 <xarick> sudden spike bursts
21:31:10 <xarick> but with good averages...
21:31:29 <peter1138> Compare with default 10,000 ops limit on a 256x256 map πŸ˜‰
21:36:21 *** keoz has quit IRC (Ping timeout: 480 seconds)
21:43:03 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #12450: Codechange: replace for loops with endof with range-based for loops https://github.com/OpenTTD/OpenTTD/pull/12450#pullrequestreview-1985257221
22:29:01 *** dihedral has joined #openttd
22:43:18 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:14:05 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)