IRC logs for #openttd on OFTC at 2024-04-07
β΄ go to previous day
00:33:01 *** Smedles has joined #openttd
02:02:21 *** herms has quit IRC (Quit: bye)
02:03:20 *** Wormnest has quit IRC (Quit: Leaving)
02:15:11 *** bertvvvs has quit IRC (Quit: You have a nice day.)
02:52:12 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:57:37 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:44:31 *** Flygon has quit IRC (Read error: Connection reset by peer)
04:20:16 *** keikoz has quit IRC (Ping timeout: 480 seconds)
04:41:27 <DorpsGek> - Update: Translations from eints (by translators)
05:55:57 <peter1138> _glx_: What about GRM? Is that handled with something else in NML?
06:06:17 *** keikoz has quit IRC (Ping timeout: 480 seconds)
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:34:57 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:09:06 *** keoz has quit IRC (Ping timeout: 480 seconds)
07:46:16 <pickpacket> figuring that's a good starting point
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: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: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: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: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: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: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: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: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: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: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: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:45:00 <peter1138> I'm wrong π But also right.
08:45:07 <peter1138> Autoreplace does not send vehicles to depot.
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: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: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: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: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: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:04:04 <locosage> but applies to many high-end competitive goals
09:04:48 <peter1138> Sounds like you've entered a rabbit hole... "implement auto-renew based on age instead of model life"
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: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: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: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:28 <pickpacket> ahyangyi: I especially love those! π
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:22:31 <xarick> STR_JUST_STRING4 has happeared
09:23:28 <peter1138> sprite aligner needed it π
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:21:19 <xarick> can't seem to stabilize for AroAI
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
11:23:51 <_glx_> peter1138: NML has `reserve()`
11:27:07 <xarick> Path of Exile related π
11:59:40 *** keikoz has quit IRC (Remote host closed the connection)
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:57:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
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: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: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:35:52 *** keikoz has quit IRC (Read error: Connection reset by peer)
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> 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> 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: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> well strictly it's 6 π
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:55 *** Wormnest has joined #openttd
16:28:46 <charlieatlas_ff03k64> locosage: How did you get this list?
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: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: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: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:38:59 *** gelignite has quit IRC (Quit: Stay safe!)
19:41:37 *** keikoz has quit IRC (Ping timeout: 480 seconds)
19:54:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
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: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:09:57 <silent_tempest> Hmn okay it looks like that worked.
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:30:29 <xarick> Otvi is hard to handle
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)
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)
continue to next day β΅