IRC logs for #openttd on OFTC at 2026-04-29
⏴ go to previous day
00:00:07 <squirejames> Its the "I like this game, but, if I could just change this one thing...." and before you know it you're 20 years into a total conversion
00:00:18 <peter1138> And there's no indication that it's actually necessary or desirable.
00:00:35 <peter1138> More for the sake of it.
00:00:44 <roadworx> oh, it's not, the only person who wants it is me and only me
00:02:41 <roadworx> combining more cargos into one is the easier (and better) option
00:15:26 <will_marshall_> You can at me if I'm wrong.
00:15:39 <will_marshall_> also wait that's a nice number
00:45:09 <will_marshall_> I'm not sure how the sound check in Vehicle.cpp:1058 is *supposed* to work to be honest with you.
00:48:59 <will_marshall_> I know I need to do something with it but it seems like it fires the running sounds incredibly often for nearly all vehicles I've looked at.
01:15:35 <peter1138> It's a shit system to be honest.
01:15:51 <peter1138> Audio requires way more timing precision than pixels moving about on screens.
01:19:24 <peter1138> People have complained that it worked great in TTDPatch but not in OpenTTD, but never managed to explain what was wrong.
01:24:52 <peter1138> > Running sound, called once per engine tick, but no more than once per vehicle motion
01:25:52 <peter1138> So tbh I'm not sure that check is correct anyway, but would need to check with TTDPatch :/
01:26:12 <peter1138> (Not that it matters too much what TTDPatch does any more)
01:34:19 <peter1138> Though it seems correct reading how the spec says it should behave.
01:45:03 <reldred> I don’t think too many sets ever implemented running sounds but I do have an inclination to bully ragin_ into implementing them at *some* point. Really need a road vehicle set to implement them as well at some point, I would like to play ottd with sounds on at some point but it always feels a bit weird with only trains having running sounds.
01:51:50 *** Wormnest has quit IRC (Quit: Leaving)
02:04:35 <ragin_> reldred: My sets do have the code for it, they're just disabled
02:04:50 <ragin_> I found the sounds just repeated too much and it became annoying
02:05:16 <ragin_> Also there seems to be a limit on the amount of sounds which can cause it to be weird if you have many trains in a single area
02:05:22 <ragin_> But I'm also no opposed to the idea
02:05:33 <ragin_> Especially since I have places I can get good engine sounds from
02:06:53 <peter1138> Hmm, well, that test doesn't take into account that the train handler runs twice per tick.
02:07:41 <peter1138> So 256 is actually 2 movement steps.
02:13:58 <audigex> reldred: One big problem is that they're just kinda a ballache to source, especially if you want them to be somewhat coherent across the set
02:13:58 <audigex> I can write code from scratch, I can draw sprites from scratch - but making audio is very different. There are free sounds out there where people have made their recordings available, but they tend to be pretty inconsistent
02:13:58 <audigex> It's a LOT of work to source them, curate them, edit them to make them kinda fit etc
03:48:15 *** Philemon has joined #openttd
03:51:44 *** Phileman has quit IRC (Ping timeout: 480 seconds)
05:15:58 *** Flygon has quit IRC (Read error: Connection reset by peer)
05:37:54 <DorpsGek> - Update: Translations from eints (by translators)
07:35:05 <peter1138> Okay, what sets add animated steam engines?
07:55:53 <mnhebi> Old Nars, I think Finnish trainset does..
08:03:49 <peter1138> Updating v->motion_counter with first->cur_speed once per tick does appear to be a bit wrong.
08:05:14 <peter1138> Trains actually have two goes per tick, so theoretically the motion counter should be updated for each step, and cur_speed may not be the same for both steps.
08:05:50 <peter1138> But then changing it has implications for existing stuff (might be better or worse)
08:08:22 <peter1138> The other thing is that the 256 internal units per movement step (currently 128 for trains because of above) part is only correct for diagonal (X / Y) rails, N, E, S or W directions are less, so the train movement and animation frames are out of sync.
08:09:04 <peter1138> The old speeding-up-around-corners trick bites again.
08:38:48 <will_marshall_> It's very suspicious that running sounds would need to be extremely extremely short to not be a total cacophony given how frequently they're triggered.
08:39:01 <will_marshall_> They probably do need breaking out of that loop and handled seperately.
08:39:20 <mnhebi> I liked the old NARS and UKRS sounds..
08:39:32 <will_marshall_> I liked them when I was playing with them (OpenTTD 0.6.0?)
08:39:44 <will_marshall_> I actually wonder if running sounds have regressed because I don't remember it being this bad.
08:44:13 <peter1138> will_marshall_, the NewGRF spec addresses that.
08:44:16 <peter1138> > For the running sounds, it is advisable to check the motion counter and to only return a successful sound effect number every so many vehicle motion ticks. This way, the sounds will be played more frequently the faster the train is. Alternatively, you can check the tick counter variable and play the sound effect every so many engine ticks, so that it is played at a constant rate, or, of course,
08:44:22 <peter1138> switch between both modes depending on vehicle speed.
08:44:39 <peter1138> So they should not necessarily be producing a sound every tick.
08:45:04 <peter1138> But on the other hand, evaluating that every tick no doubt has some cost.
08:45:49 <will_marshall_> Okay so it seems like I loop back around to suggesting a new motion counter variable that is actually direction-of-travel dependent to avoid breaking the hell out of audio.
08:46:59 <will_marshall_> If the spec suggests that set authors use this variable for that, it's not fair to change the assumptions (it increases monotonically and then loops around eventually)
08:50:36 <peter1138> For steam engines UKRS seems to emit two different sounds, in a seqence of 1, 2, 2, 2, 1, 2, 2, 2.
08:51:00 <peter1138> And it does that for what would be every movement step, except for the double step thing.
08:51:27 <will_marshall_> Chuggas and Choo-Choos.
08:52:27 <peter1138> I changed MILLISECONDS_PER_TICK to be 1000 to slow it right down so split everything up. Using the fast forward speed limit to run at a specific number of ticks per second instead.
08:54:06 <peter1138> For an 80mph train the sounds all merge together.
08:54:20 <will_marshall_> At 80mph cur_speed is about 128 right?
08:55:45 <peter1138> From when I remember, this might be intentional. At 80mph the engine parts are moving pretty quickly.
09:15:57 <will_marshall_> These videos are a bit quiet but there's definitely been a regression that affected UKRS running sounds at some point in the last 10 years.
09:16:47 <will_marshall_> Vs a steam build of 15.3
09:18:02 <peter1138> A bit quiet? There's no sound I can hear.
09:18:20 <will_marshall_> Sounds are playing fine in the discord embedded viewer for me.
09:18:35 <will_marshall_> I'll rerecord a side-by-side with boosted levels.
09:19:44 <peter1138> I guess my external player doesn't care.
09:19:49 <peter1138> Neither sound right.
09:20:20 <peter1138> There is the 33 ms per tick to 27 ms per tick change.
09:20:49 <peter1138> But that corresponds with things moving faster too.
09:34:08 <reldred> that's suuuuuuuper quiet
09:35:52 <will_marshall_> I imported it into Audacity and I can't see the waveform what the hell is wrong with computers.
09:37:01 <will_marshall_> Clearly I'm not an audio professional here.
09:37:30 <reldred> computers, not even once.
09:37:37 <will_marshall_> I think we're playing twice as many sound events for moving vehicles as we were before.
09:58:21 <peter1138> The motion counter update code, apart from minor refactor changes surrounding it, looks the same in 1.2.3 and master.
09:59:39 <peter1138> Minor difference is that the motion counter is updated for all parts, not just the lead engine.
09:59:56 <peter1138> (But sounds are only played for engines)
10:34:39 <will_marshall_> I'm not going crazy and I can prove it, I might need to go on a bisect journey to find out what's wrong.
10:34:51 *** kaibaneddy has joined #openttd
10:34:51 <kaibaneddy> There was definitely a bug with how those sounds were played in earlier versions of openttd, I remember troubleshooting it.
10:34:51 <kaibaneddy> It's been a while since I've heard those sounds, but the 15.3 version sounds correct to me. The definitive check would be to compare how they sound in TTDPatch.
10:36:23 <peter1138> I have never been able to get TTDPatch running with NewGRFs.
10:40:07 <will_marshall_> Is TTDPatch really relevant for a 2010s Grf? I'm comparing 1.2.3 because that's the contemporary release for UKRS2 1.05 (which won't load on older versions. I tried 0.6.0 first!).
10:41:03 <peter1138> If the author says it's wrong I believe them :)
10:43:27 <will_marshall_> I'm not the author of anything I'm just squinting suspiciously at code. Top is 1.2.3, bottom is 15.3 - there's 2 'extra' beats in the space where we previously had one, that's not explained by a 20% change in tickrate?
10:48:44 <kaibaneddy> will_marshall_: UKRS2 is an OpenTTD grf, yes. But the sfx go back to UKRS1 and NARS.
10:49:31 <kaibaneddy> Same code same wavs
10:49:31 <will_marshall_> Fair, let me go grab UKRS1 and load it up in 0.6.0 and compare.
10:52:33 <peter1138> kaibaneddy, so is there meant to be a consistent beat pattern of 1,2 or 1,2,2,2?
10:53:30 <kaibaneddy> 1,2,2,2, I'm pretty sure.
10:53:30 <kaibaneddy> Let me turn the other computer on and I'll check the code...
10:54:20 <peter1138> (In videos of real steam engines there is often a 1,2,3,4,1,2,3,4 pattern, of course they're not all the same :)
10:54:48 <peter1138> (And sometimes you get extras)
10:56:18 <kaibaneddy> Yes, that was what I was trying to replicate I think, a 4 beat pattern. Some locos may vary...
10:56:43 <talltyler> Extra chuffs is usually a bad thing, unless you have a weird engine with extra cylinders 🙂
10:58:32 <peter1138> Of course, acceleration/deceleration in OpenTTD is not entirely realstic.
11:00:35 <kaibaneddy> >>>// SFX ======================================================================
11:00:35 <kaibaneddy> // wheelslipping if speed is less than 5 mph
11:00:35 <kaibaneddy> 7236 * 28 02 00 02 81 09 80 FF 00 04 04 5B 80 00 00 5A 80 01 01 59 80 02 02 58 80 03 03 00 FF
11:00:35 <kaibaneddy> 7237 * 14 02 00 03 82 B4 00 FF 01 02 00 00 05 11 00
11:00:37 <kaibaneddy> 7238 * 26 02 00 24 82 46 08 03 04 53 80 00 00 52 80 01 01 51 80 02 02 50 80 03 03 11 00
11:00:37 <kaibaneddy> 7239 * 26 02 00 04 82 46 08 03 04 5B 80 00 00 5A 80 01 01 59 80 02 02 58 80 03 03 11 00
11:00:39 <kaibaneddy> 7240 * 18 02 00 14 82 46 08 03 02 56 80 00 02 55 80 03 03 11 00
11:00:41 <kaibaneddy> // chuff when under power, drift at full speed
11:00:41 <kaibaneddy> 7241 * 22 02 00 05 82 4C 20 FF 01 B4 00 FF 02 14 00 00 08 24 00 09 28 04 00 // power steamer
11:00:43 <kaibaneddy> 7242 * 22 02 00 06 82 98 20 FF 01 B4 00 FF 02 14 00 00 08 24 00 09 28 04 00 // power steamer
11:00:43 <kaibaneddy> 7243 * 17 02 00 05 85 21 00 FF FF 01 06 00 \w0 \w24830 05 00 // OpenTTD version check ##
11:01:20 <peter1138> I like the clarity of NFO :)
11:01:24 <kaibaneddy> the power/accelerating sounds are "1 2 3 4", and the drifting sounds are "1 2 2 2"
11:02:01 <kaibaneddy> peter1138: makes perfect sense to me 💀
11:02:22 <peter1138> It's definitely a need to keep doing it to remember it thing for me.
11:03:06 <will_marshall_> Reading it is fine, I've not ever tried to bend my brain into being able to write it though.
11:03:15 <kaibaneddy> this is also really old, I tend to format stuff more readably (more line breaks / comments / strategic escape codes) these days...
11:07:36 <kaibaneddy> the openttd version check was the move from using the basegame max speed variable to 4C Current max speed including e.g track or timetable speed limits, introduced in OpenTTD 1.3.
11:27:02 <jfkuayue> Is coding NFO like mastering how a steam locomotive works?
11:27:22 <will_marshall_> Steam locomotives are easier except for the bit of them that requires you to understand supersonic aerodynamics.
11:31:04 <ahyangyi> I guess steam locomotives are also harder to forget once one masters it
11:45:33 <brickblock19280> I don't think my PR would fix that issue
11:46:08 <brickblock19280> It's about the reversing var whilst this was about flipping and driving backwards
11:46:49 <brickblock19280> Including flipping makes some sense but I don't feel like it's necessary to offload from the grf
11:48:14 <will_marshall_> There's already a way for NewGRF authors to fix this for themselves that won't have major consequences, and I get to stop thinking about unsigned wrap around instantly.
11:49:27 <peter1138> I suppose that in PikkaBird's comment "every NewGRF" might not be right :)
11:49:53 <peter1138> But for those that do, this would get messy.
11:50:15 <will_marshall_> Yeah, there's no way to solve it here without breaking content and I'm not gonna be that guy.
11:50:15 <brickblock19280> I would assume most sets don't bother for articulated vehicles since they can't flip properly anyway
11:51:11 <will_marshall_> No sets bother for articulated vehicles, I'll go back to making articulated vehicles flippable and then the set authors can worry about fixing that before they set a new articulated_yet_flippable type bit for those engineIDs.
11:54:43 <will_marshall_> Thanks for all the help though, Peter and Pikka in particular. Do appreciate it.
11:57:00 <brickblock19280> will_marshall_: Better not to have a flag tbh since you can't control if regular stuff is flippable or not
11:57:13 <brickblock19280> So it would be no different
11:58:34 <will_marshall_> You can control if regular stuff is flippable... by giving it an articulated callback that always returns no extra parts, right?
11:58:43 <will_marshall_> I don't know if people DO, but they might have.
11:58:51 <audigex> Is NeddyK Pikka? Never made that connection somehow 😂 not that we've interacted a huge amount on here
11:59:08 <will_marshall_> audigex: I have now inferred this information for the first time also.
12:02:31 <will_marshall_> brickblock19280: Also wait - TRAIN_FLAG_FLIP got killed in OpenTTD 13 (EngineMiscFlag::RailFlips), because it was pointless?
12:09:23 <brickblock19280> It used to be that all vehicles could be flipped but the offsets were wonky so that flag got added to enable flipping but then the offset issue was fixed so now that flag just restores the old behavior
12:10:07 <will_marshall_> Yeah, the flag is "I am handling the sprite offsets for myself in the grf" rather than "oh sure it's fine to flip me"
12:10:33 <will_marshall_> But it was a flip permission flag before that point.
12:11:19 <peter1138> It's fine, we probably somebody's workflow with that one.
12:11:25 <peter1138> ... s/probably/broke/
12:12:28 <will_marshall_> I'm happy to say "articulated vehicles are flippable now, adapt to it" and not bother adding a flag*.
12:12:28 <will_marshall_> \* Except double-ended vehicles which remain weird.
12:14:41 <audigex> This is a question rather than a statement, but could that potentially mess up some extralength vehicle sets?
12:15:04 <audigex> I know they do some weird/counter-intuitive stuff with articulated vehicles
12:16:24 <will_marshall_> That was my thought when I was suggesting adding a flag, but then I remembered the "you control the buttons you press" tweet.
12:18:56 <will_marshall_> I'll try out BRETS and continue doing bad things to my own sets after I've walked the dog.
12:26:47 <audigex> "Doctor it hurts when I do this"
12:27:25 <LordAro> audigex: me & cycling for the last... 18 months?
12:27:45 <peter1138> Simple, just don't realise any NewGRFs you make. It works for at least one author...
12:28:43 <peter1138> At this time of day...?
12:29:33 <LordAro> looks like it got stuck on apt?
12:29:42 <peter1138> Where's the github uptime chart again...
12:48:48 *** Wormnest has joined #openttd
12:49:21 <ahyangyi> if we compare it against what it will be in the future
12:51:25 <audigex> I might start using that at work
12:55:46 <andythenorth> don't flag articulated flipping
12:56:17 <andythenorth> every flag has multiple cost 😛
12:58:02 <will_marshall_> you're the boss, boss
13:10:19 <peter1138> (Is it really a regression?)
13:10:32 <will_marshall_> peter1138: Am I having some kind of health episode? I can't make sense of that post either. The CanRail set author made it so that if you flipped a vehicle manually the set would scold you somehow?
13:11:30 <peter1138> will_marshall_, you aren't allowed to flip vehicles, so to "fix" it, the author doubles up sprites so that if the player does decide to flip them, it doesn't appear to be flipped.
13:12:09 <peter1138> (However, afaik those NewGRFs are not available for mere mortals to use)
13:14:37 <will_marshall_> Okay, so we're all in favor of letting the game handle flipped articulated vehicles on the set author's behalf and if you have a paywalled (?) set that doesn't like that you can go fork OpenTTD yourself.
13:37:27 <andythenorth> game does attract grf authors with personality disorders
13:37:41 <will_marshall_> I don't know what you're talking about I'm normal.
13:38:47 <audigex> I can kinda see their point, to be fair
13:38:47 <audigex> They had a working set using a flag. The flag was disabled and it broke their set in a way they didn't feel they could fix in a reasonable amount of effort
13:40:17 <audigex> People put a LOT of work into things, I do think we should try to minimize pain points where possible and allow them to opt-out of features within reason
13:40:17 <audigex> Like, was that flag actually doing any real harm? I'm not sure what the rationale for removing it was.
13:40:17 <audigex> If it was causing a problem with something else then "You can't make an omelette without breaking a few eggs", but if it was just "Not needed, let's remove it", then... well, there was an argument to be made that it was perhaps removed when people were still using it
13:40:51 <audigex> To be clear, I couldn't give a shit that it was removed - I don't use it, don't care. But I think it's a bit harsh to laugh at someone who's found the removal of something they use to be an issue for them
13:47:07 <will_marshall_> There's two perspectives to this: One is that OpenTTD will evolve and that it'll bring all content along with it, and that content can carry on working the same way forever (even if it was broken)
13:47:26 <will_marshall_> And the other is that you kind of accept that the content you make is a moment in time and you have to accept that in future it may be left behind.
13:47:41 <audigex> brickblock19280: I appreciate this is almost certainly a bug in my own templates, but "fixed" doesn't necessarily actually mean "fixed" if it exposes an issue elsewhere
13:48:14 <audigex> My view on this has, indeed, been "just don't flip it" but I can see why an author who doesn't understand the problem might be confused and fed up with it
13:48:48 <audigex> Again, I'm not saying we can't change stuff, just that maybe we should be kinder to people trying their best with limited time. They're volunteers too
13:50:27 <will_marshall_> If you're making a set that is not generally released (and is I guess only for your personal use) then my patience for complaining when the base game leaves you behind is much much lower.
13:50:51 <will_marshall_> And that's my understanding of what the CanRail situation is.
13:50:54 <peter1138[d]> audigex: Hmm, that might happen if the GRF sets the flag but doesn't provide its own flipped sprites, or if it doesn't set the flag but DOES provide unnecessary flipped sprites.
13:51:48 <will_marshall_> And actually, my patience for complaining when JGRPP leaves you behind might be zero, because that's two layers of volunteer.
13:52:23 <will_marshall_> I'm not trying to be flippant, I swear 🙂
13:52:58 <peter1138> Anyway, I wasn't laughing, just providing a contrapoint to "[players] control the buttons you press"
13:53:01 <audigex> peter1138[d]: I definitely don't set the flag
13:53:01 <audigex> I don't believe I provide unnecesary flags
13:53:01 <audigex> My guess of the issue was that my templates have mis-aligned 7th views, so they're internally consistent but offset (4?) pixels to the left
13:53:29 <will_marshall_> My condolences because that does sound like a total PITA to fix.
13:53:34 <audigex> So they look fine within an un-flipped consist travelling "east", but misalign when flipped, and would presumably misalign if coupled to another set
13:54:11 <audigex> In this case I have no actual complaint to make, this is just an old set I acquired with old kinda terrible templates. I've slowly cleaned them up but often in a "make it look okay in game when just using this set"
13:55:05 <peter1138> Okay, what set is it?
13:55:12 <peter1138> (And what vehicles)
13:56:01 <peter1138> (Online Content gets quite slow when you limit the milliseconds per tick...)
13:56:54 <audigex> BRTrains, any recent v2.x
13:59:13 <audigex> I'd put my money on just needing to re-align the 7th view of each template a few px to the left, I think the templates are generally "aligned to each other and to the track, but not properly to the bounding boxes"
13:59:13 <audigex> Eg I think two vehicles facing E will align with each other, as will two facing W but a vehicle facing E and a vehicle facing W will not align, nor will they align properly with eg a signal
13:59:13 <audigex> It's all "close enough" visually when in eg stations, and the parts of a train align with each other, hence why I've not put much time into resolving it
13:59:38 <belajalilija> I can see why the flipping stuff would be annoying
14:00:02 <belajalilija> But i planned ahead, so
14:00:36 <belajalilija> will_marshall_: This is much my opinion
14:01:33 <audigex> It's easy to plan ahead when you start later, too - I doubt much of your work is more than a few years old? So you've probably not got much "technical debt" lying around from older techniques, bodges to "temporarily" fix things that have been change etc
14:01:54 <peter1138> Yeah, your templates/offsets must be wrong, even the 8/8 wagons don't flip properly, and they never had any special treatment.
14:02:00 <audigex> will_marshall_: If they don't release it then I genuinely don't care :p
14:02:40 <will_marshall_> We're talking about the "you won't give me all the GRFID namespace I want" guy, right?
14:02:48 <will_marshall_> Takes ball, goes home type situation?
14:03:21 *** Webster has quit IRC (Ping timeout: 480 seconds)
14:03:23 <belajalilija> audigex: Yeah, maybe around 2022 or 2023? We’ve changed a lot of how things work, it didn’t used to be 2cc etc, but we planned for push pull since like 2022/3
14:03:30 <audigex> peter1138: That would make sense, the 8/8 will be aligned with the 7/8 for internal consistency, so if one is wrong then both (and the rest) will be wrong
14:03:30 <audigex> I did a HUGE tidy up of templates (throwing away literally dozens of templates and re-drawing spritesheets to fix some more "standard" ones) but I burned out on it so hard that I got to a point of "that'll do" and left it alone for the last couple of years until I canbear to face it again
14:03:56 <mnhebi> will_marshall_: Lets just call him "He who will not release"
14:04:21 <peter1138> The offset for W and E views should be exactly the same, but in that set it moves.
14:04:40 <audigex> belajalilija: Yeah so that's a major distinction... my set started in 2004-06 in some respects, and even the "new" parts of it start from 2013-2017 ish
14:04:48 <peter1138> So this is definitely a bug in the NewGRF, nothing to do with shorter wagons or flip handling.
14:05:17 <will_marshall_> I think it was acknowledged as a bug in the NewGRF up front 😛
14:06:35 <peter1138> will_marshall_, the wording was suggesting that allowing flipping of shorter wagons exposed the bug, therefore it would be better to not allow it.
14:07:10 <audigex> Yeah, as I expected - I was just using it as an example to show how removing the flag could "break" something
14:07:10 <audigex> Even if what it was actually doing is just exposing something that was already broken, the result is still the same that it's something they need to fix because of the change. "It's your bug not our bug" doesn't change the functional result that they have to fix something that was working fine, through a change made outside their control
14:07:10 <audigex> My point is mostly just that for someone who's bumbling along not quite understanding what they're doing and without deep understanding, I can see how that would be frustrating
14:07:37 <audigex> peter1138: More of a "they didn't use the flip flag so their bug was never really a bug in any sense that mattered to them"
14:08:04 <belajalilija> audigex: Yeah i gotta say, i intentionally went with a clean slate, partially to do something new but also just because i knew anything I’d inherit would be changed later anyway
14:08:04 <belajalilija> I’m mostly just being a dick because funny
14:08:05 *** SigHunter has quit IRC (Remote host closed the connection)
14:08:10 <audigex> (In my case, my bug is a bug I'm sorta aware is there but isn't a high enough priority to fix because it looks okay unless you flip stuff and I burned out on templates for this set years ago fixing some MUCH worse bugs)
14:08:37 <peter1138> The flip flag never had any effect on 8/8 wagons, and the issue is still present there.
14:09:32 <audigex> I think you're slightly missing what I'm trying to say, Peter - I wasn't intending for that to be a direct analogy
14:10:03 *** SigHunter has joined #openttd
14:10:19 <belajalilija> For a short time i did plan to draw to the rukts scale
14:10:40 <belajalilija> My first hand drawn trains were
14:12:59 <peter1138> (I think I did a mock up with some of those logos, probably didn't keep them though)
14:17:29 <audigex> Badges will come to BRTrains... eventually
14:17:29 <audigex> I've got a new build process in the works that ditches all or almost all on-build-sprite "badging", it's just a huge project to migrate and won't happen any time soon
14:17:29 <audigex> My current plan is to split some parts of the set out, so it'll happen incrementally as eg Metro and then Departmental/Eyecandy vehicles get pulled out into separate sets
14:17:29 <audigex> Editing 800 units at once for that kinda stuff is a bit daunting - we had a baby just around the time the badge conversations started, so it's not been an ideal time for me throwing tons of time into my work here :p
14:18:36 <will_marshall_> Speaking of badges... For stations, any objection to a way to check badges on adjacent station tiles? Bitpacked like rail_continuation is, parameterized the same as has_badge?
14:19:23 <audigex> It's a slow moving set because it's Fucking Huge (tm)
14:20:15 <peter1138> Although it's entirely generic, not specific to station tiles at all.
14:20:22 <will_marshall_> My apologies Peter I was not familiar with your game.
14:20:40 <will_marshall_> I was thinking of something a little less... big 😛
14:21:17 <peter1138> Heh, just a bit of cruft to handle different tile types.
14:21:26 <will_marshall_> I was only really thinking about direct adjacency.
14:22:15 <peter1138> It could actually be less lines of code if it was a giant switch block instead of separate per-tile-type functions, but then it's a giant switch block.
14:22:46 <peter1138> So I did wonder about adding a radius option.
14:23:44 <peter1138> Which would let you check multiple tiles with one call, but actually that's sort of a bad idea because it's allows for using a very complex variable without understanding the cost, whereas manually checking each position is at least not hidden.
14:25:31 <will_marshall_> Walking all 8 directions just to check one bit would be pretty wasteful but the NML would be significantly less nightmarish than two temp stores.
14:27:55 <peter1138> Parameter stack when? :o
14:28:11 <peter1138> (Not all that helpful)
14:36:10 <will_marshall_> Need an expert in language design to come up with some syntactic sugar I guess.
14:38:16 <_jgr_> NML in general makes it difficult for GRF authors to predict what the performance impact of what they're doing might be
14:40:47 <_glx_> yeah nml can call an expensive variable multiple times it author asked for it, even if the result will be the same on every call
14:42:14 <will_marshall_> I don't have a good intuition on how frequently some callbacks are evaluated so I'm never sure if I'm being too aggressive with things in those chains.
14:42:48 <_glx_> it's even worse when the NFO variable is "hidden" in 4 different nml variables
14:43:16 <will_marshall_> there's a time and a place for var[...] eh.
14:43:39 <audigex> Completely agree as a newGRF author, very few of us have much real understanding of what's going on behind the scenes when we use NML
14:43:39 <audigex> Andy understands more than most, but I'd venture the majority of the rest of us have a smattering of knowledge about specific quirks rather than any real understanding of what it's *really* doing
14:44:02 <audigex> "We know just enough to get ourselves in trouble" is probably pretty accurate
14:44:33 <will_marshall_> Also I've probably never played an OpenTTD game seriously enough or on shaky enough hardware to even understand that it can run sub-realtime.
14:44:54 <will_marshall_> Wheras I've spent many many months of my life staring at Unreal Engine running at 12 fps.
14:45:34 <audigex> Yeah that's a good point too - even my old gaming PC is an 8700K 4.7Ghz, it's plenty quick enough to run a 1000 train 4k x 4k map at full speed. I just don't test my stuff for performance
14:46:13 <will_marshall_> Exactly. I'm on my work PC with a 5950x, which is an old chip by game developer standards but it's wicked fast by OpenTTD standards.
14:48:22 <_jgr_> Unfortunately I've had to spend a fair amount of time looking at NML's (at times terrible) codegen and the resulting performance issues 😛
14:53:26 <peter1138> Things like bitstuffing results into one variable don't exactly help.
14:53:44 <peter1138> If you end up calling a variable multiple times just to get different parts of it.
14:54:32 <will_marshall_> To fix that you'd need a much more substantial virtual machine to interpret things, right?
14:55:00 <audigex> It's just the nature of NML, I guess, it's low level code in a high level trenchcoat
14:56:29 <_jgr_> Stuff like multiplexing variables together is mostly because the ID spaces are too small
14:57:45 <_jgr_> That can also be partially mitigated without changing the format, but in the long run a less bad bitstream format would be good
14:59:18 <will_marshall_> Extending the variable space to 16 bits?
15:00:12 <audigex> Do we think there's a world where grf/NFO is deprecated as a "It'll still work but won't be touched" format with a replacement? Or is it too entrenched to be worth the effort when it does the job regardless of its quirks?
15:01:10 <will_marshall_> I doubt you'd ever leave behind the current grf spec entirely, there'd always be features in the future where bringing them to nfo would be trivial.
15:02:47 <peter1138> Implementing something else would result in needing to maintain two different systems.
15:04:14 <peter1138> It is possible to extend the the binary format to allow things like e.g. 16 bit variables without duplicating it all. The initial loader just has to put an 8 bit value into a 16 bit variable.
15:04:50 <peter1138> 16 bit varaction 2 ids...
15:05:13 <LordAro> just implement the old system in the new system!
15:05:19 <LordAro> like a squirrel parser in lua
15:05:38 <peter1138> I welcome your branch :D
15:05:41 <LordAro> or a grf parser in lua
15:05:58 <LordAro> hey ChatGPT, write a ...
15:24:38 <ahyangyi> Hey ChatGPT, write a JIT for OpenTTD expressions
15:33:16 <_jgr_> A JIT is fairly overkill, you can get a fairly long way just doing simple peephole optimisations and the like
16:38:58 <_zephyris> How did you you pick those cases out for optimisation?
16:39:18 <_zephyris> Are they typical NML oddities, or from profiling?
16:47:27 <_jgr_> Some of it is common NML patterns/inefficiencies, some of it is expensive patterns used by common/popular NewGRFs, and some is just low-hanging fruit which is easy to do
16:50:17 <_jgr_> NML ternaries are probably the single biggest offender
17:03:21 <_zephyris> Catching the some in NML compilation, particularly the ternaries, would make sense.
17:04:50 *** f_ has quit IRC (Ping timeout: 480 seconds)
17:05:25 <_jgr_> Unfortunately replacing ternaries with switches makes the simultaneous ID problem worse. Stuff like the abs() function using a ternary is fixed already though.
17:05:53 <_glx_> ternaries use switches if really required
17:06:15 <_glx_> (side effect detection)
17:07:31 <andythenorth> ternaries have this weird effect, where it seems to be a contest to stack as many of them as possible
17:07:45 <andythenorth> javascript has the same problem, sometimes 😛
17:19:18 <_jgr_> This is a bit of an old example now, but stuff like on the left is a key motivator. It can be boiled down the version on the right.
17:20:20 <_jgr_> Which manifested as notably poor performance when opening the train list window
18:12:44 <peter1138> I did look at backporting it once but figured it would be a never ending task
18:14:34 *** michi_cc[d] has joined #openttd
18:14:34 <michi_cc[d]> Won't help for old GRFs, but one could add Abs and a ternary as first class operators to VarAct2.
18:17:17 *** locosage has joined #openttd
18:17:17 <locosage> also all kinds of comparison operators would be nice
18:17:47 <locosage> and ternary is gonna be tricky to add
18:20:14 <locosage> also hasbit/!has bit operators
18:27:52 <peter1138> michi_cc[d], I had a patch to add operators, I can't remember what happened with it.
18:29:54 <_jgr_> Abs is not such a problem now as more recent NML versions use a better sequence
18:33:38 <audigex> andythenorth: I feel like the problem of terneries is that they're so good and so concise, it's easy to get a bit badly behaved with them
18:34:40 <peter1138> Wasn't there something about both sides being evaluated even though you only need one?
18:38:09 <audigex> Is that why they were removed?
18:38:09 <audigex> I wonder if the solution for NML terneries would be to have it as pure syntatic sugar and it just gets turned into a switch chain under the hood?
18:38:35 <audigex> Presumably that's what happens by the time it gets to NFO anyway?
18:41:02 <_jgr_> It's turned into a sequence where one expression is multiplied by 1, the other multiplied by 0, and then they're added together
18:41:42 <_jgr_> Though if both expressions are integers it can use a simpler sequence
18:47:04 <andythenorth> “Why ternary when you can OR boolean results from procedures?” 😛
19:22:00 <_zephyris> Why not add ternary as an operator? Because the ActionD syntax(?) doesn't work with it?
19:56:00 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
19:56:34 *** MinchinWeb[m] has joined #openttd
20:04:43 *** Flygon has quit IRC (Remote host closed the connection)
20:05:21 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
20:05:37 *** MinchinWeb[m] has joined #openttd
20:29:08 <audigex> I feel like I'd just resolve it as
20:29:08 <audigex> switch(FEAT_WHATEVER, SELF, autoswitch_123, A == B){
20:29:54 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:30:01 *** WormnestAndroid has joined #openttd
20:30:05 *** WormnestAndroid has quit IRC (Remote host closed the connection)
20:30:06 *** WormnestAndroid has joined #openttd
20:30:57 <michi_cc[d]> Sure, unless you already use too many concurrent action 2s.
20:31:17 <audigex> Solution: More action 2s
20:31:26 <audigex> (I happen to need more anyway so this is self-serving, admittedly)
20:34:45 <peter1138> Well, grfv9 didn't start well.
20:36:05 <_glx_> the conversion to switch already happens if X or Y is not read only
20:37:44 <_glx_> (was needed because somebody used a STORE_TEMP in a ternary)
20:43:37 <alien_bunny_ninja> May I make a suggestion that standard role badges be split into coach and non-coach.
20:43:37 <alien_bunny_ninja> E.g. I know there is `role/passenger` and `role/mail` but in my mind that refers to the whole of the train set or the engine or EMU and thus there should be `role/coach__commuter_`, `role/coach__express_`, `role/coach__hs_`,
20:43:37 <alien_bunny_ninja> `role/coach__mail_`, `role/coach__regional_`
20:45:05 <alien_bunny_ninja> Also `role/shunting` is a verb whereas everything else is a noun so rather -> `role/shunter` ?
20:51:56 <audigex> Walk me through the logic of separating `role/passenger_train` and `role/passenger_coach` (naming scheme for clarity)?
20:51:56 <audigex> I feel like they're mostly there for the player to filter on anyway, I'm struggling to think what I'd use `passenger_train` for that isn't already handled by `passenger_coach`
20:52:11 <audigex> Not saying you're wrong, I'm just not visualising your point
20:53:40 <alien_bunny_ninja> From a filtering perspective. I think the main benefit of badges is that they enable filtering vehicles in the game. Thus having a generic passenger filter would include things like xMUs and coaches, which methinks is not beneficial.
20:55:35 <alien_bunny_ninja> My current list
20:55:35 <alien_bunny_ninja> Coach (Commuter)
20:55:35 <alien_bunny_ninja> Coach (Express)
20:55:35 <alien_bunny_ninja> Coach (Mail)
20:55:36 <alien_bunny_ninja> Coach (Regional)
20:55:36 <alien_bunny_ninja> Commuter/Urban
20:55:38 <alien_bunny_ninja> Express Passenger
20:55:40 <alien_bunny_ninja> Heavy Freight
20:55:42 <alien_bunny_ninja> Light Freight
20:55:44 <alien_bunny_ninja> Powered/Unpowered Sundry
20:55:44 <alien_bunny_ninja> Regional Passenger
20:55:46 <alien_bunny_ninja> Ultra-High-Speed (Pax)
20:55:48 <alien_bunny_ninja> Ultra-High-Speed (Universal)
20:55:50 <alien_bunny_ninja> I think the coach thing and perhaps the powered/unpowered should be considered for standardisation. Or at least discussion 😉
20:56:00 <peter1138> The passenger badge is mainly meant for engines, to indicate the engine's role.
20:56:17 <peter1138> A passenger wagon doesn't need any such badge, because it's a passenger wagon so of course it's for passengers.
20:57:10 <alien_bunny_ninja> peter1138: Yes except we have say 800 vehicles available for purchase in a single window. So *what* a wagon/coach is espc for pax or any other thing is not filterable with the standard roles atm.
20:57:17 <peter1138> nor are badges for "the whole of the train"
20:58:01 <audigex> I feel like the `Coach (Commuter)` is entirely superfluous with `Commuter`, personally, I think I just don't get the idea there - it would just clog the filter menu up
20:58:01 <audigex> I do think JGRPP's Engine/Wagon buy menu should come into vanilla, though - it always surprises me that hasn't been included, it's GREAT
20:58:27 <alien_bunny_ninja> I use the JGRPP split too, but not everyone does 😉
20:58:38 <peter1138> Yes, "Commuter" is the way.
21:00:37 <alien_bunny_ninja> Noted, though I'll be a renegade in that case.
21:00:37 <alien_bunny_ninja> Shunting vs shunter? I don't mind changing that on my side, just bugs my OCD.
21:14:28 <tabytac> audigex: (it is defailt true in jgrpp tho)
21:22:24 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
21:25:23 <audigex> I really think it should be the default for vanilla, personally
21:39:25 *** SigHunter has joined #openttd
21:46:52 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:57:54 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
