IRC logs for #openttd on OFTC at 2026-03-11
⏴ go to previous day
00:26:31 <LordAro> well that was a fun waste of time
00:29:18 <peter1138> There's no stdafx type header to include it all by default ;)
00:30:13 <LordAro> it's got a load of stuff in it that isn't just types, that's for sure
01:57:24 *** Wormnest has quit IRC (Quit: Leaving)
04:53:13 *** Zathras_4 has joined #openttd
04:53:30 *** Zathras_7 has joined #openttd
04:56:39 *** Zathras_1 has quit IRC (Ping timeout: 480 seconds)
04:56:49 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
05:01:44 <DorpsGek> - Update: Translations from eints (by translators)
06:45:19 *** andythenorth has joined #openttd
07:27:05 *** SigHunter has quit IRC (Remote host closed the connection)
07:29:14 *** SigHunter has joined #openttd
09:02:02 <peter1138> LordAro, that last push fails on Windows btw.
09:13:06 <peter1138> Oh, whoops, didn't notice :o
09:29:38 *** Flygon has quit IRC (Remote host closed the connection)
10:12:37 *** Alkel_U3 has joined #openttd
10:18:30 <peter1138> Reading changes when it's Dalestan's codestyle is a pain.
10:22:24 *** Alkel_U3 has quit IRC (Quit: maintenance)
10:22:32 *** Alkel_U3 has joined #openttd
10:55:02 *** andythenorth has quit IRC (Quit: Connection closed for inactivity)
11:42:03 <LordAro> peter1138: mm. i tried to "improve" everything i touched
11:42:13 <LordAro> but clang-format wouldn't be a bad shout
11:43:30 <peter1138> Looking at the last PR, it's a bit hit & miss at the moment.
11:44:08 <peter1138> With codium I did selection formatting, to avoid reformatting the whole file and to avoid doing the formatting manually. (Mostly.)
11:46:15 <peter1138> Mind you, part of the reason why I was getting rid of the macros was to allow auto-formatting to work properly. macros tend to break things.
11:46:31 <LordAro> though you can specify some things in the clang-format config
11:47:06 <peter1138> Syntax highlighting really doesn't like things like `case'd'` with no space after case.
11:47:25 <LordAro> i can't say i can blame it
11:48:33 <peter1138> I'm not using clang-format directly, just auto reformat in codium. Which I believe is doing stuff based on clangd anyway, but.
12:05:09 <peter1138> Written by DaleStan 20 years ago. Nobody cares :)
12:06:31 <peter1138> I do wonder if he's, uh... you know.
12:07:12 <peter1138> > Last active: 2014-04-25 05:06:16
12:07:57 <__abigail> peter1138: I care 💔
12:11:59 <peter1138> __abigail, nobody cared enough to 1) notice 2) make a PR. You could change that. I'm not sure what uses this data.
12:12:19 <peter1138> Oh, it does. It's input, not output.
12:13:34 <peter1138> It would need to keep the current spelling to work with existing files, if it ever mattered.
12:20:48 <peter1138> Aw crap, circular dependency in dependency injection :/
13:11:47 <LordAro> peter1138: you should highlight DaleStan in an issue and ask him :p
13:12:38 <LordAro> also what on earth is that font? () look like []
13:14:18 <peter1138> B612 Mono, apparently.
13:27:33 <rito12_51026> Is api.bananas.openttd.org:443 still valid?
13:29:04 *** Wormnest has joined #openttd
13:41:43 <peter1138> Now I'm going to spend ages fiddling with fonts and stuff :o
13:44:24 *** Zathras_7 has quit IRC (Quit: Initiating getting-the-hell-out-of-here maneuver!)
14:04:00 <LordAro> `lDAP_PASSWORD='...'`
14:18:45 <LordAro> i don't want to say how long it took me to work that out
14:19:16 <LordAro> but it involved setting LDAP_OPT_DEBUG_LEVEL
15:14:14 <talltyler> Whadda mean I have to update all the docs I touch? Sheesh, it's like we care about code quality 😛
15:14:27 <emperorjake> Is true push-pull really happening? 👀
15:15:03 <LordAro> >Real trains lack this ability
15:17:43 <talltyler> I've tried, they're too heavy to pick up and reshuffle the order by hand 🥲
15:20:18 <talltyler> Can you expand on that, Peter? Are you thinking about code or gameplay?
15:20:44 <talltyler> I know you have a branch to allow wagons to lead trains. I have no problem with that, but I am trying to keep this as simple as possible. 🙂
15:21:41 <peter1138> "Yes". Trains don't really require an engine on either end to operate in reverse.
15:22:21 <peter1138> Like, it's an odd restriction to add.
15:23:17 <dwfreed> see the part where this is PR 1 of 3?
15:23:35 <belajalilija> This is very sexy
15:25:32 <belajalilija> I’m gonna make sure to make good use of this feature
15:26:07 <LordAro> peter1138: perhaps not in absolutely all cases, but the majority, surely
15:26:41 <talltyler> It's not a new restriction. It keeps the existing requirement that the first vehicle must be an engine, and the restriction on the back vehicle also being an engine will be resolved in Step 3 (an order flag to tell a train to back up at reduced speed)
15:27:02 <dwfreed> in practice, they need either an engine or a cab car (the latter usually seen in passenger service) to run in full speed reverse, so that the engineer is facing the direction of travel
15:27:44 <talltyler> Right, Step 2 will add a GRF flag to mark a wagon as a cab car.
15:28:55 <talltyler> The one limitation of my current plan is that a train with a cab car at each end, and loco in the middle, won't be allowed unless the front cab car is technically a loco.
15:29:15 <will_marshall_> I think about it and instantly see PeterN's point, which strikes at the core of the PR - the objective of the PR should be to smooth over all the various edge cases resulting from trains running in reverse, and then you can worry about the rules and conditions where they may run in reverse as a seperate concern.
15:29:34 <talltyler> (GWR Autocoach, some silly consists in the US during PTC implementation, I'm sure there are others)
15:30:08 <dwfreed> talltyler: huh, I've never seen a consist in the US without a loco at one end, wild
15:30:13 <talltyler> Peter, does your "wagons leading" patch simplify movement code?
15:30:34 <will_marshall_> The classic way I'd look at this (sorry to apply job-brain) is that the engine needs the capability of running a train in either direction, irrespective of where the "power" in the train comes from and where the "driving commands" come from, and the game (yes I know we don't have a distinction here, stick with me) should decide which of those conditions are allowable overall.
15:31:30 <will_marshall_> The rules ("must have cab leading" vs "must have a vehicle with a 'cab' at all") are really where the matter of taste comes in.
15:32:16 <peter1138> Right, matter of taste vs technical limits.
15:33:07 <LordAro> that's the sort of edgecase i was imagining, but i'm not sure it's enough to worry about gameplay-wise
15:33:30 <talltyler> I absolutely agree that we should allow non-locomotives to lead trains. It's just a question of in which order do we remove that limitation, to simplify code and allow sane review of the PRs?
15:33:46 <peter1138> If it doesn't cater for everything the foamers would like to do, because some train operating company did it for a week in 1952...
15:33:49 <talltyler> How finished is your patch, Peter? 😛
15:34:03 <peter1138> I will add I'm not against this by the way.
15:34:24 <peter1138> But it's my natural tendancy to look at things and wonder why there are limits, or what problems there are, etc.
15:34:26 <will_marshall_> PR #1 should remove the technical limits, and crucially bypass as many assumptions that are in the existing code as possible ("the front vehicle of the train is a powered locomotive", for example) and then let your future PR delegate configuration of those rules to Newgrf/configuration/whatever. Anyway, I'm not just all talk I would be willing to help with this.
15:34:54 <belajalilija> peter1138: Nono, let 2tt cook
15:35:13 <peter1138> I hate that phrase.
15:35:15 <dwfreed> of course it would be some east coast transit company
15:35:21 <belajalilija> Even with only step 1 this is great
15:35:34 <belajalilija> I don’t mind making my dvts powered
15:36:01 <will_marshall_> Loco in the middle and wagons at either end is an edge case that I've already battled with at work (and let me just say, nobody cares what the Clinchfield Railroad did in 1964 or whatever)
15:36:06 <peter1138> talltyler, it's a very old patch and I'm not sure if I can find it any more. It did not touch movement code, it basically modified the GUI interface (and commands) to allow a non-engine leading vehicle.
15:36:22 <will_marshall_> Making DVTs powered is busted in vanilla because you need to pick if your DVT is diesel or electric up front.
15:36:31 <peter1138> IIRC, once a train is out of a depot, none of the code actually cares that the front part is an engine or a wagon.
15:36:49 <peter1138> (Not even out of the depot.)
15:36:50 <talltyler> Ah, so the front wagon still stores all the orders and cached data?
15:36:53 <rito12_51026> does preview saves crash log somewhere?
15:37:08 <belajalilija> will_marshall_: Or just use waypoints
15:37:45 <will_marshall_> Waypoints suck! I did something much worse!
15:38:07 <peter1138> Once you have that, you can then allow trains to reverse based on... well, 1) what the player wants 2) want NewGRF says.
15:39:06 <peter1138> From the brief look, your code allows trains to move backwards? And that's cool, I didn't do anything like that.
15:40:35 <will_marshall_> The "something worse" by the way is that I exclude vehicles with a very low Power/Weight ratio from the compatible_railtypes computation in this->compatible_railtypes, since set authors give their DVTs a power to weight ratio of like, 1 horspower/tonne.
15:41:18 <will_marshall_> So my electric trains don't spear off down non-electrified branches/tracks just because there's a "diesel" DVT in the formation.
15:41:38 <will_marshall_> Sorry, in Train::ConsistChanged, not in `this->compatible_railtypes`
15:42:31 <will_marshall_> Not at all to suggest that this is a good idea, but it does work for me and allow me to enjoy the game without worrying about where I put waypoints.
15:45:10 <peter1138> Suspect my patch is lost to time.
15:46:26 <talltyler> (no new features, just trying to fix docs warnings)
15:47:43 <belajalilija> This is probably the most hyped I’ve ever been for something in this game
15:49:39 <will_marshall_> So... audit all uses of `Vehicle::Last()` and see what other things are likely to need adjusting, right?
15:50:11 <belajalilija> I do have a question though
15:50:44 <belajalilija> Are there plans/will it be so that when a vehicle reverses the sprite changes?
15:51:04 <talltyler> For headlights? You can use the existing is_reversed flag.
15:51:09 <LordAro> oh god the scope creep
15:51:32 <brickblock19280> talltyler: You could but it's not a good idea
15:52:15 <brickblock19280> The behavior works when driving backwards but not when reversed normally since it would then use incorrect ligts
15:52:15 <belajalilija> Brickblock1viaGitHub: Lmao we had the same idea
15:52:41 <talltyler> I mean, there's an internal flag for "vehicle is backing up," I can just expose that to GRF.
15:53:18 <brickblock19280> That's all that would be necessary
15:53:34 <peter1138> There's already at least 2 bits (flipped / reversed)
15:53:45 <peter1138> There "train is reversing" on is temporary though.
15:53:54 <belajalilija> This is such a great thing
15:54:02 <peter1138> (That's yet another separate bi t)
15:54:41 <belajalilija> I’ve been drawing sprites with layers for flipped vehicles from the beginning
15:54:43 <peter1138> > Reversing = 0, ///< Train is slowing down to reverse.
15:54:47 <will_marshall_> We discussed this yesterday on discord, it's going to be a bit of a pain in the ass for NewGRF devs - expect some kind of switch (is_reversing << 2 | is_flipped << 1 | is_backing_up) monstrosity?
15:54:49 <belajalilija> I’m so fucking prepared for this
15:55:09 *** su1phur has joined #openttd
15:55:09 <su1phur> Brickblock1viaGitHub: Is this a problem? Of course breaking every other GRF out there is not ideal, but can we update this, and then disable the behaviour unless the GRF is sure to work?
15:55:18 <su1phur> My brain is kind of all over the place rn so that prob doesn't make sense
15:55:32 <will_marshall_> su1phur: newgrf authors being perverts should not stop the development of openttd 🙂
15:55:41 <brickblock19280> You could but it's imo not the best way
15:55:43 <will_marshall_> (i can say it folks, I've published a newgrf now)
15:57:15 <talltyler> I love having to write docs for ancient movement code with confusingly-named parameters 🥲
15:58:49 <talltyler> I don't know if there's a way to avoid breaking fake push-pull of existing NewGRFs that don't know about the new flag.
15:59:22 <brickblock19280> xoring that var and the new flag and exposing that instead should work
15:59:23 <su1phur> talltyler: What are existing newGRFs that do fake push-pull?
15:59:29 <will_marshall_> su1phur: UKRS2
15:59:40 <belajalilija> su1phur: Danish trains and sbb
15:59:42 <su1phur> BRETS, BRTrains, GETS, JP+ are the ones off my head
15:59:43 <will_marshall_> Uhhhh, probably a lot of other stuff too.
16:00:20 <su1phur> is UKRS2 or RUKTS the one that's real livery? I am getting confused
16:00:45 <talltyler> brickblock19280: Okay, I can't wrap my brain around this, can other GRF authors confirm if this is true? Can we just xor these internally within OpenTTD and output the value as the existing flag?
16:01:04 <will_marshall_> My instinct says no.
16:01:07 <belajalilija> Ukrs2 can be real via params though, i think rukts can 2cc via params too
16:01:40 <will_marshall_> But it might be valid, need to do a worked example.
16:01:51 <will_marshall_> (might be faster to just... test it)
16:01:56 <belajalilija> Real grfs let you switch between real and 2cc liveries without params though
16:04:42 <will_marshall_> Orthogonal question because I'm not super familiar with the state of OpenTTD internals - is it just c-style casts everywhere or is static_cast<T> allowed?
16:05:06 <talltyler> All new code should use static casts, we are slowly converting c-style casts 🙂
16:05:30 <peter1138> (But also if you can write it in a way that avoids a cast at all, that's better.)
16:05:45 <will_marshall_> so ` inline T *GetMovingFront() const { return (T *)this->Vehicle::GetMovingFront(); }` 🙂
16:08:17 <will_marshall_> On that note, GetMovingNext() and GetMovingPrev() are not clear - "next" is "towards the back of the formation relative to the current movement direction"?
16:08:21 <will_marshall_> But I bikeshed away.
16:15:41 <brickblock19280> moving the map with the mouse is reversed for me on the web build
16:15:53 <talltyler> There's a setting for that
16:16:27 <brickblock19280> I could not find it
16:16:51 <talltyler> `Viewport scroll behaviour`
16:17:35 <talltyler> will_marshall_: Yes, as opposed to `Next()` and `Prev()` which are relative to the formation's actual direction (as shown in the depot)
16:17:44 <brickblock19280> I see it's still different on the web build tho because it sends my flying when locket
16:17:57 <talltyler> I absolutely welcome suggestions for better names, better code, etc. 🙂
16:18:48 <talltyler> XORing the Reversed and DrivingBackwards flags does not seem to have any effect on Danish Trains.
16:19:24 <brickblock19280> I could be wrong but that
16:20:50 <talltyler> Actually, it might be something else gone wrong elsewhere...
16:21:32 <talltyler> When I comment out the line entirely, making the GRF variable always false, it is still drawn wrong
16:21:56 <talltyler> I should check 15.2 to make sure I'm not missing something 🙂
16:23:32 <brickblock19280> They're articulated right
16:24:09 <talltyler> Yes, but composed out of a string of the same engines, that just change sprites based on their position
16:25:59 <talltyler> Oh I see what's happening 😄
16:32:19 *** Artea has quit IRC (Read error: Connection reset by peer)
16:32:29 *** gelignite has joined #openttd
16:39:05 <talltyler> OK, articulated trains don't back up, not sure why not
16:51:04 <talltyler> brickblock19280: Fixed articulated trains, and XOR does work to avoid flipping the train sprites, although headlight layers are still wrong.
16:51:36 <brickblock19280> headlights are wrong for everything no?
16:52:01 <talltyler> If the GRF has fake push-pull, headlights are wrong
16:52:23 <talltyler> Actually, maybe even if the GRF has headlights at all...?
16:52:46 <brickblock19280> that's what I would expect, I'll look at my grf code
16:53:15 <jfkuayue> Something interesting happening 👀
16:53:49 <talltyler> I'm not sure XOR is the best way to handle it
16:54:19 <peter1138> Fake push-pull can probably be ignored, we've been saying for ages don't do it ;)
16:54:32 <peter1138> Well, s/we've/I've/g
16:54:33 <talltyler> Because modern GRFs won't be able to do headlights at all
16:54:55 <brickblock19280> yeah you'd need a new variable
16:56:01 <talltyler> I'm going to focus on fixing this crash, homework for anyone who chooses to accept it is to make a list of GRFs which use fake push-pull, and figure out which ones are unmaintained 🙂
16:56:10 <brickblock19280> there isn't a single set coded to change headlights based on reversed as it would make the lights wrong with main behavior
16:56:24 <talltyler> If it's maintained or can be updated, I am not worried about breaking it 🙂
16:56:51 <brickblock19280> I would not be able to implement lights with the current variable
16:57:48 <brickblock19280> not xoring the current one is silly since it fixes the behavior and aligns with the spec
16:58:45 <brickblock19280> brickblock19280: I can't know if the vehicle is magically flipping or not without a new var and I need to know that to make the right choice, the old var is changed regardless so off no use
16:58:54 <talltyler> If we don't XOR the current variable, doesn't it tell you if the train is reversing? Just turn on the rear headlights, instead of flipping the whole sprite?
16:59:11 <talltyler> Oh, I see what you mean
16:59:21 <talltyler> You don't know if the train magic-flipped or is backing up
17:00:53 <talltyler> What if we change the existing variable to contain only whether the train is currently backing up? It would break existing push-pull implementations but give you the info you need for headlights/taillights, I think
17:01:45 <brickblock19280> why would that be better than xoring?
17:02:39 <talltyler> With XOR, if the train is backing up the variable is false 🙂
17:02:47 <talltyler> So you never know if it's backing up
17:02:58 <talltyler> We might just need a new variable...
17:03:03 <brickblock19280> so you add a new var
17:03:41 <talltyler> Once we add manual backing up, the existing variable won't make much sense
17:05:01 <belajalilija> talltyler: Would a spiritual successor suffice?
17:06:04 <brickblock19280> as long as my grf can be loaded in earlier versions we can't reuse the same var
17:11:28 <jfkuayue> What about Multiple units?
17:13:10 *** audigex has joined #openttd
17:13:10 <audigex> jfkuayue: Presumably you could check `vehicle_is_reversed` and just switch sprites based on that?
17:13:37 <audigex> But yeah it depends how it's gonna work with articulated locomotives
17:13:41 <brickblock19280> you could but that risks loosing correct lights
17:13:58 <brickblock19280> currently it doesn't work for articulated
17:14:49 <brickblock19280> audigex: also quite silly given the game could now do that for you
17:16:04 <audigex> The game currently doesn't actually handle articulated MU sprites for you... it just happens to work because the rear vehicle is always at the rear
17:16:04 <audigex> As long as the newGRF is given enough information (`vehicle_is_reversed` and `vehicle_is_faaaancy_pushpull` together) , though, then I don't see why it would be an issue. As long as I can detect the situation I can decide what sprites to show
17:16:22 <audigex> The issue would be if the newGRF can't detect what's going on
17:17:37 <brickblock19280> it would with this PR so implementing it yourself would be unnecesary in this case
17:17:52 <brickblock19280> it would also break when towed
17:17:57 <audigex> 1. A value I can check to know if this is currently happening
17:17:57 <audigex> 2. A callback I can use to tell the game whether I want it to happen for this specific unit
17:17:57 <audigex> If both of those are present, though, then I figure I can handle whatever needs to be handled
17:19:08 <audigex> Without them the lots of stuff could break
17:19:37 <brickblock19280> the lack of the var would break nothing but we want it for lights
17:21:17 <mmtunligit> in that if it isnt strictly nessecary for this PR to work it should be left out for a seperate PR that adds that functionality
17:22:49 <brickblock19280> imo vehicle_is_reversed should be an xor as described above + a new variable that can be used for lights or i guess speed backing up (which only makes sense when 3 is added)
17:23:30 <talltyler> Backing up speed restrictions will be handled by step 3 of my roadmap. Cabooses/brake vans should not be coded as engines, since they are not.
17:24:47 <brickblock19280> you can try it in the linked web build
17:29:56 <talltyler> MU cars won't work yet, since they're not engines. They will need the GRF flag planned for Step 2 of my roadmap.
17:45:46 <talltyler> Station crash fixed. 🙂
17:50:20 *** Borg has quit IRC (Quit: leaving)
17:56:41 *** gelignite is now known as Guest4860
17:56:45 *** gelignite has joined #openttd
17:57:56 *** Guest4860 has quit IRC (Ping timeout: 480 seconds)
18:09:49 *** andythenorth has joined #openttd
18:55:13 <audigex> brickblock19280: Changing the existing variables could throw things off for existing newGRFs quite badly, surely?
19:15:51 <brickblock19280> Kinda, the messages above should explain my reasoning
19:16:41 <brickblock19280> But we need to xor it to make the grf not use its own method when using the game one
19:17:07 <brickblock19280> And changing it makes it align with the spec as defined right now
19:17:40 <brickblock19280> Since the vehicle no longer flips once it turns around
19:23:52 <michi_cc[d]> talltyler: Is train reversing in your mind purely a visual thing or something to have gameplay impact?
19:26:14 <talltyler> Step 3 will allow trains without a cab on the back (freight trains, many passenger trains) to back up at reduced speed.
19:26:14 <talltyler> Other than that, purely visual, although I suspect improved visuals will change how some players design their networks. 🙂
19:26:29 <talltyler> I am open to ideas, if you have them 🙂
19:27:23 <belajalilija> Shhh no one bother him, just let him do it xddd
19:27:24 <michi_cc[d]> I would actually attach a gameplay impact, especially given that the original TTD features several dual-headed engines and players can manually add engines to the end.
19:28:24 <talltyler> I want the behaviour to be opt-in, OpenTTD is hard enough for new players as-is 🙂
19:28:35 <talltyler> Some people have suggested a global setting to disable magic flip
19:28:43 <talltyler> But you know, more settings 🙂
19:29:52 <mmtunligit> what would a gameplay aspect even look like? the train is driving backwards, this doesnt really change how it works other than a need to go slower if theres no cab
19:29:53 <talltyler> Since we can't uncouple and run a locomotive around a train, I will likely use some magic flip in my own networks to do this without having to build a wye/triangle or loop big enough to turn a long freight train
19:30:16 <michi_cc[d]> My idea here would be to apply a *minimal* loading time to any train that has to flip because it can't reverse.
19:30:16 <michi_cc[d]> The minimal time should be a flat time and not depend on e.g. train length or other things. This way, there is actual incentive to use reversing trains for services with short stops (like metro or local pax trains, which aligns with the dual-headed MUs in the original vehicles), but stuff like a long freight train doing full load won't be affected.
19:31:14 <brickblock19280> How would that work when flipping outside a station?
19:31:26 <michi_cc[d]> The exact time would have to be defined of course, and there might be some advantage to allow NewGRFs to affect it (needs care for the mixing NewGRF situation of course).
19:31:43 <mmtunligit> i smell pitchforks :P
19:32:14 <michi_cc[d]> brickblock19280: I would ignore end-of-line flipping here, as the pathfinder will not do that if any other route exists.
19:32:55 <belajalilija> This sounds like it would alter vanilla gameplay a lot
19:34:12 <michi_cc[d]> Also, the point isn't to punish players, so the minimal loading time would IMHO not be that big. Just big enough to give incentive for short(er) local/metro services.
19:34:46 <talltyler> I'm not opposed to that idea. I wonder if there's a bonus you can apply to trains which don't have to flip, instead of a penalty to those which do.
19:35:18 <mmtunligit> speeding up cargo loading seems like the only option there
19:35:22 <michi_cc[d]> Make the Manley-Morel DMU great again 🤣
19:35:23 <talltyler> Like faster loading speeds, in this case, or maybe some reduction to running cost?
19:35:24 <belajalilija> talltyler: That’d be preferable
19:36:26 <michi_cc[d]> Running costs are mostly irrelevant IMHO.
19:36:29 <_jgr_> Applying a bonus to trains which are permitted to flip is largely the same thing as applying a penalty to trains which can't
19:36:33 <talltyler> Or you could get really crazy and boost station/local authority rating 😛
19:37:06 <talltyler> "Flefingbridge doesn't like you shunting in the station"
19:37:07 <mmtunligit> _jgr_: one penalizes how existing saves work and the other doesnt
19:37:18 <belajalilija> _jgr_: In vanilla most trains aren’t dual headed unless built to be
19:37:46 <mmtunligit> talltyler: YESSSSSS
19:38:22 <michi_cc[d]> Faster loading wouldn't exactly be the same though. A flat minimum time will mostly only affect trains that arrive and instantly depart full. Anything that loads longer because of full load/cargo trickle with gradual loading/timetable waits would not be affected anyway.
19:39:05 <michi_cc[d]> While a bonus makes any reversing train better, no matter the situation. Basically telling players to double head everything, no mattter what or where.
19:39:41 <talltyler> Ah, you're trying to incentivise passenger trains
19:40:22 <michi_cc[d]> Or short cargo trains, like for e.g. supplies.
19:40:24 <_jgr_> It seems odd to me to apply a bonus for trains which are allowed to reverse even in the case where they never actually do so
19:41:54 <belajalilija> What about if it just didn’t impact gameplay ?
19:42:06 <brickblock19280> Figuring out the exit direction ahead of time seems non trivial
19:42:15 <michi_cc[d]> Kinda mirroring IRL, if turnaround time matters, MUs, DVT are used very often, but if you are there waiting 10 hours for the ship to finish unloading, there's plenty of time to run an engine around during loading.
19:42:34 <_jgr_> That said, the PR is to me technically worthwhile even if there isn't consensus on the user-facing bikeshedding details
19:43:00 <michi_cc[d]> Oh yeah, the minimal loading time is just my idea, nothing more and nothing less 🙂
19:43:41 <talltyler> I like the penalty idea, for what it's worth, and have no issue doing "game design" despite players objective to the game ever changing 🙂
19:44:10 <michi_cc[d]> Never doing any actual gameplay changes just because someone somewhere can't accept "just don't update" gets boring.
19:44:10 <talltyler> What sort of "short duration" were you thinking? 5 seconds?
19:44:45 <brickblock19280> 5s feels like a lot
19:45:13 <belajalilija> Yeah 5 would be a lot
19:45:38 <talltyler> I mean, it needs to have some impact 🙂
19:46:45 <michi_cc[d]> A bit longer than what a vanilla pax trains need to fully load on a station with more than enough cargo (and no timetable or other delays).
19:52:43 <michi_cc[d]> If I read the code right, a vanilla train loads 5 units per 40 ticks. A manly morel DMU has 2*38 capacity, so should load in 320 ticks if I math'd it right. Ergo a minimum of maybe 450 ticks or so?
19:53:23 <michi_cc[d]> (I might have missed some conversion factor somewhere, but nothing a quick debug session can't surface 🙂 )
19:55:46 <talltyler> You should be able to set your timetable mode to Ticks, then autofill a timetable and see exactly how long it takes 🙂
20:02:52 <michi_cc[d]> Anyway, the points to pick a time that is just slightly longer than a straight full load. So the penalty should only affect trains that only load partially or are where loading is not delayed by e.g. more cargo trickling during gradual loading.
20:03:42 <michi_cc[d]> Hmm, given that for 320 ticks loading, the minimum time should maybe just be ~350-370, just a tick more.
20:05:38 <_jgr_> How is this going to be communicated to players?
20:06:22 <michi_cc[d]> That's step 2 of the 3-step plan for profi 🤣
20:06:43 <_jgr_> Unexplained slowness unless the player makes a double-ended consist when there isn't otherwise any reason to do so is the sort of thing which generates a lot of user-support traffic
20:07:24 *** tokai has quit IRC (Read error: Connection reset by peer)
20:08:03 *** ChanServ sets mode: +v tokai
20:12:06 <audigex> Yeah just let newGRF authors handle the extra cost maybe?
20:12:06 <audigex> I can adjust loading speed and running cost myself for my realistic newGRF if I want that kind of gameplay feature, but it lets vanilla and stockalike sets not change
20:13:12 <audigex> I’m happy to just give MUs and DVTs a lower running cost and set a higher loading speed for MUs and coaches if there’s a DVT badge in the consist, that’s the sort of nonsense us realistic-set authors do anyway
20:16:24 <audigex> It leaves the burden with those of us who care about it and are already messing around with those things anyway
20:16:39 *** andythenorth has quit IRC (Quit: Connection closed for inactivity)
20:16:54 <michi_cc[d]> So new/beginner players are not allowed to get any gameplay changes ever? (slight hyperbole of course).
20:18:02 *** andythenorth has joined #openttd
20:18:09 <audigex> michi_cc[d]: If that was in reply to me then I couldn’t care less anyway
20:18:09 <audigex> I just figure changing it for players who won’t care about it and creating yet another “why does this happen?” support burden seems unnecessary when the people who care about that kind of micro-realism are already using the kind of set that will be happy to incorporate it
20:18:42 <talltyler> If anyone is motivated to take a poke at the code, I'm getting a crash when reversing vehicles inside a depot at just the right moment. I can't figure out exactly how to reproduce it, or why it's crashing.
20:18:42 <talltyler> Trains reversing in depots have been modified by this PR so I suspect the problem is there, but haven't spotted it yet.
20:19:52 <talltyler> Re: Communicating reversing delays to players, you could just add a new string to the vehicle status bar `Waiting to reverse` or something, like how we have `Waiting to unbunch`.
20:20:51 <_jgr_> Yes, it makes sense to add a delay for the magic flip case
20:21:01 <talltyler> Although of course that doesn't explain how to avoid said delay 🙂
20:21:16 <_jgr_> However adding a delay for the normal case where there is no reversing seems difficult to explain away
20:21:20 <talltyler> `Waiting to magic flip` is maybe a bit too on the nose 😄
20:21:24 <andythenorth> did we implement push pull?
20:21:37 <andythenorth> I was working, and irccloud doesn't have full log :P
20:22:01 <michi_cc[d]> Modern game UI logic probably says we need (nested) hover tooltips on all this stuff
20:23:00 <audigex> Put pushpull on hold until we can re-write the codebase to introduce a full tutorial of every feature and nuance
20:28:29 <talltyler> Preview seems to be broken 🙁
20:28:52 <talltyler> The action itself, not the preview of this specific PR
20:40:44 <andythenorth> do red trains pushpull faster?
20:47:18 <squirejames> purple ones are invisible
20:51:14 <eed_edward> What about allowing to modify newgrf params in multi mode?
20:57:49 <mmtunligit> what on earth do you mean by multi mode
20:59:13 <eed_edward> single player vs multi player
20:59:57 <mmtunligit> only the server admin would be able to do that
21:00:09 <mmtunligit> probably requires restarting the server
21:00:43 <andythenorth> can't you just patch it?
21:00:52 <_jgr_> It would create too many desync-related problems to be worth the bother
21:01:22 <eed_edward> only one desync so all non-host players are kicked 🙂
21:02:02 <mmtunligit> we dont do intentional desyncs here
21:02:14 <mmtunligit> plus at that point you may as well jsut be taking down the server anyway
21:03:19 <eed_edward> and feature like that is not in current roadmap?
21:03:47 <mmtunligit> no, as JGR said it would cause way too many desyncs to be worth the effort
21:04:02 <mmtunligit> you can take the server down, change whatever you need to change, and then put it back up
21:04:22 <mmtunligit> it's not a hard thing to do if youve already figured out how to run a server
21:04:55 <eed_edward> but it takes many seconds! better would be to just change parameter in running server
21:05:21 <mmtunligit> we aren't causing intentional desyncs
21:08:10 <rito12_51026> eed_edward: Do it when no one is around, so players won't be bothered?
21:08:47 <andythenorth> lol 'roadmap' :)
21:11:28 <mmtunligit> 2TT put one out today :P
21:11:39 <talltyler> Yeah, but only for me 🙂
21:12:18 <talltyler> And I’m taking the risk that if I don’t accomplish my roadmap, I don’t get paid for any of this
21:13:21 <mmtunligit> oh no! that sounds like a really unfair contract. you and the other devs should really do something about that
21:16:56 <talltyler> I’m going on strike
21:17:26 <talltyler> From the train game collective
21:21:19 <belajalilija> andythenorth: A wild andy has appeared!
21:22:12 <audigex> talltyler: Honestly if you don’t finish it I think we should all get a refund
21:22:47 <audigex> A full refund too, none of this “gesture of goodwill” partial refund nonsense
21:22:56 <_glx_> a user was asking about a way to toggle "city" flag on existing towns in scenario editor but I don't see what would be the best way to add the feature in the window
21:23:30 <audigex> Third button next to Delete and Coverage?
21:23:41 <_glx_> maybe a small button next to town name with the "city" icon
21:24:44 <mmtunligit> _glx_: put it in the rename options, like i how i did for the station name move button?
21:25:55 <talltyler> That’s only for the sign. I’d put it as a new button near Expand.
21:28:40 <talltyler> Maybe between Delete and Coverage 🙂
21:39:30 <reldred> A town authority action to do it in a game (and cost a shitload of cash) to do it would be cool
21:40:05 <reldred> Maybe a min pop and a shitload of cash to do it so you’re encouraged to grow it first.
21:43:10 *** keimfrei has quit IRC (Quit: User went offline on Discord a while ago)
22:18:32 <peter1138> 2https://www.adriankrebs.ch/blog/dead-internet/
22:20:52 <reldred> People at work keep telling me to use ai and I refuse lmao
22:21:35 <andythenorth> when you need a dice rolling word soup machine, an LLM is the best tool for the job
22:21:56 <andythenorth> not everything is a nail though
22:22:32 <andythenorth> wasn't it already naptime?
22:30:47 <__abigail> reldred: Noooooo you have to generate slop
22:30:47 <__abigail> It will make you so much more efficient! Who cares if you have no idea what it's doing
22:52:33 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:49:27 <peter1138> Damn I wish I could code.
23:54:34 *** MinchinWeb[m] has joined #openttd
continue to next day ⏵
