IRC logs for #openttd on OFTC at 2025-11-21
⏴ go to previous day
00:52:22 <audigex> locosage: That seems worse, for the obvious reason that players almost always care far more about train length when it comes to signal placement
00:52:22 <audigex> It’s almost the entire point of signal placement with path signals
00:54:17 <audigex> Like I’d literally never place signals based on movement distance. I don’t think (as a player) that actually even means anything to me
00:54:17 <audigex> Whereas train length is a core part of gameplay
00:54:17 <audigex> … why was it changed?
02:35:46 *** Wormnest has quit IRC (Quit: Leaving)
03:41:12 <davidxn> Not bad for someone who's too stupid to understand pointers
03:41:12 <davidxn> I'm having trouble with DrawSpriteViewport for the cargo icon, though... `DrawSpriteViewport(sprite, PAL_NONE, cargoSign->top, cargoSign->center);` seems like the valid way to do it, but I never see sprites showing up. It doesn't seem to be a very common thing to ask the game to do, only happening in a couple of places - but I think the coordinates are right
03:47:54 *** gnu_jj_ has joined #openttd
03:51:10 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:54:58 *** Smedles has joined #openttd
03:56:33 <kaji_kaede> Would probably benefit from being able to take a look at more of the code.
03:58:21 <kaji_kaede> I've got some experience with the UI system, but not enough to know what these coordinates even quite refer to.
04:07:27 <kaji_kaede> Oh, I forgot to use the dang reply feature. davidxn
04:11:31 *** kaibaneddy has joined #openttd
04:11:31 <kaibaneddy> audigex: "Signal spacing = train length" is popular wisdom, but is it actually based on anything?
04:11:31 <kaibaneddy> I feel like the truth is that a signal every tile is optimal, and anything less is incrementally sacrificing efficiency for aesthetics.
04:12:18 <kaibaneddy> (Which I'm all for, obviously)
04:12:46 *** emperorjake has joined #openttd
04:12:46 <emperorjake> Signal every tile isn't optimal because your signal gap is only as small as your biggest gap. And you need to leave at least 1 tile free if you want to have any kind of junction
04:12:50 <audigex> A signal every time doesn’t work if you have any form of junctions
04:12:50 <audigex> If you have any junctions then you place a signal 1TL after the junction so that a train can cross the junction and safely wait without blocking it
04:12:50 <audigex> It’s just about the most fundamental rule of signalling
04:13:12 <emperorjake> audigex: Yeah, this change seems to be tailored to a minority of openttdcoop-style players, not the majority
04:13:30 <audigex> If you do fully grade separated junctions then you still need a signal every other tile
04:13:55 <audigex> emperorjake: Yeah it’s very cool-style “optimised for efficiency” rather than intuitive for the player
04:14:24 <audigex> Defaulting to train length with a toggle option for movement would be vaguely sensible, but not defaulting to movement - that’s absurdly counter intuitive
04:15:09 <kaji_kaede> kaibaneddy: I mean. Infrastructure maintenance is an important consideration.
04:15:48 *** Zathras_1 has joined #openttd
04:16:00 *** Zathras_11 has joined #openttd
04:19:20 *** Zathras has quit IRC (Ping timeout: 480 seconds)
04:19:25 *** Zathras_4 has quit IRC (Ping timeout: 480 seconds)
05:43:40 *** jinks has quit IRC (Remote host closed the connection)
06:21:24 *** Zathras_1 has quit IRC (Quit: Connection reset by beer!)
07:00:59 <locosage> emperorjake: I'm not coop player yet I fail to see any logic in length-based placement. If I have a train jam I've already screwed up somewhere, having a neat spacing between trains in a jam is worthless.
07:01:38 <locosage> besides, before the change placer wasn't even following length-based logic particularly well and nobody seemed to care besides the "minority"
07:07:34 <emperorjake> Not every jam is a jam, it might just be a temporary congestion. And I want the trains to use the space on the tracks efficiently, without large gaps between them, to reduce the chances of it forming an actual jam
07:08:13 <emperorjake> But yeah in that case it's better to place signals manually.
07:08:49 <emperorjake> In fact a useful tool would be to highlight a space of track at a signal so that you can see how much track a stopped train would use up
07:11:27 <andythenorth> newgrf signals *placer*
07:11:39 <andythenorth> just handle placement as a callback
07:11:47 <emperorjake> Example, if you place a signal with distance set to 5 tiles, it automatically highlights the tracks where trains could stop
07:11:56 <andythenorth> Nerd handbags solved by mods
07:41:10 <locosage> emperorjake: so you prefer signaling that increases the change of congestion to reduce the chance of secondary congestion? 🤭
07:41:31 <locosage> jk, I kinda understand what you mean I guess, I just don't build deadlocks so to me congestion and jam are the same thing
07:42:15 <locosage> so once I fix the issue the jam sorts itself out
07:43:23 <locosage> andythenorth: if only openttd had a modding framework 🤭
08:30:31 *** lobster has quit IRC (Read error: Connection reset by peer)
08:31:07 *** lobster has joined #openttd
09:34:28 <peter1138> 21:32 < locosage> stereo wav sound effects in newgrfs don't seem to work in master, is that a bug or a feature?
09:34:53 <peter1138> It was never supported.
09:47:47 *** zanooda2000 has joined #openttd
09:47:47 <zanooda2000> kaibaneddy: Signals every 1x train length _may_ save you from deadlocks on most of flat junctions. But still you need at least some knowledge to properly use flat junctions so that's not a big deal actually. On the other hand it could «look more realistic».
09:47:47 <zanooda2000> Signal every tile also _may_ work, unless you have something to break flow. And well… in this game anything will will do it, reducing actual throughput to «signal every 2nd tile», so it won't give you any practical benefits if used everywhere. Also it will cost a lot and will look extremely cluttered. But still it can be useful in some places as a supplementary solution.
09:47:47 <zanooda2000> Well, signal every 2nd tile is also not that useful for a regular player. You still need some knowledge to use it «properly». Even being old openttdcoop player, I'm still rarely use it.
09:47:47 <zanooda2000> Most universal signal distance is «signal every 5th tile». It not that sparce to greatly reduce your network capacity (and responsiveness) and it will «allow» you to use simple 4 tiles bridges, costs not that much and also looks not that bad.
09:59:29 <peter1138> (It was never supported and never worked, rather.)
10:04:11 <locosage> it does work in 14.1
10:13:28 <peter1138> It was prevented by an assert.
10:13:46 <peter1138> So if you're on a release-no-assert build, it would "play", but it would be playing very incorrectly.
10:14:13 <peter1138> The audio mixer has no ability to mixer stereo sounds, and isn't aware of the number of channels a sound has.
10:14:45 <peter1138> So if you get past the assert, it will play both channels interleaved as a mono sound.
10:15:06 <peter1138> The best case is it will play at half speed.
10:20:40 <locosage> hm, I guess it does play at half speed
10:31:26 <peter1138> Is that NewGRF on bananas?
10:31:43 <peter1138> Yeah, as a feature, adding downmixing, or adding stereo mixing, is not impossible.
10:32:05 <peter1138> Just shows that asserting on user-input is a bad idea :)
10:35:11 <belajalilija> peter1138: No, and since then the audio files have been made mono and shorter
10:39:19 <peter1138> Oh well. I added some extra debug messages and wanted to test them :)
10:44:50 <locosage> I can build stereo version for you
10:46:21 <locosage> here, not sure if it gets through to irc though
10:48:28 <locosage> this is the train with sounds
10:49:50 <peter1138> [2025-11-21 10:49:32] dbg: [misc:0] SoundLoader_Wav: Unsupported channels 2, expected 1.
10:49:54 <peter1138> [2025-11-21 10:49:32] dbg: [grf:0] LoadSound [the_international_train_set]: Failed to load sound 'my_whistle.wav' for slot 76[2025-11-21 10:49:32] dbg: [misc:0] SoundLoader_Wav: Unsupported channels 2, expected 1.
10:50:16 <peter1138> Excuse my past, this terminal froze.
10:50:22 <peter1138> Also excuse my paste :D
10:50:31 <peter1138> grf vs misc... ah well.
10:59:24 <belajalilija> I made this oopsie poopsie because when you mentioned needing to make audio files mono i thought you were talking about ogg specifically
11:23:45 <peter1138> The main issue with stereo is the game does positional panning, in a very basic way.
11:24:19 <peter1138> Stereo panning is quite complex and involves more maths.
11:33:56 <peter1138> Even downmixing stereo is not that simple, and depends on the source.
11:58:38 <peter1138> I had a patch once that added ambisonics.
11:59:26 <peter1138> Full-on 3D positional audio...
13:15:45 <LordAro> `Inconsistency detected by ld.so: dl-version.c: 204: _dl_check_map_versions: Assertion `needed != NULL' failed!`
13:18:21 <davidxn> kaji_kaede: Hah, thank you 🙂 I understand the concept of pointers, but keeping track of what's a pointer and what's a reference and when to dereference and what functions need one versus the other seems to be beyond me - I always think I understand it then VS complains that I'm using the wrong one
13:19:07 <kaji_kaede> Aaaah. Well shit, can make a lot of use of that explanation now I've thought of it, at least.
13:19:08 <davidxn> Although that's better than when I did my CS degree in 2002, where tools for that didn't exist and you'd just point off into the middle of invalid memory and crash
13:19:57 <kaji_kaede> davidxn: ~~that's just how it is for me anyway~~
13:20:14 * peter1138 is slightly worried by junior devs who don't know that you can indent by using tab.
13:20:33 <peter1138> I saw them adjusting each line by adding or removing spaces.
13:20:48 <peter1138> (This isn't about tabs vs spaces, but the way editors handle key presses.)
13:20:59 <LordAro> i do occasionally do that when i'm in an editor that isn't configured correctly
13:21:21 <LordAro> i really should sort out my vim configuration on windows...
13:30:19 *** tokai|noir has quit IRC (Quit: c('~' )o)
13:36:57 <xarick> should std::sort be changed to std::stable_sort
13:39:21 <xarick> because sync multiplayer etc...
13:39:36 <locosage> depends on the context
13:39:38 <LordAro> if it's needed, then yes
13:40:21 <LordAro> mostly, if you think the answer is yes, the answer is actually "the equality operator was broken"
13:43:41 <peter1138> And also read up what stable_sort actually does. It is unlikely to be helpful in cases of "sync".
13:47:59 <locosage> there was literally a desync in openttd at some point due to use of sort instead of stable_sort
13:48:03 <locosage> maybe even multiple times
13:48:20 <_glx_> the desync was because sorting of pointers
13:48:45 <locosage> one I remember wasn't pointers
13:54:28 <talltyler> An idea from another channel, moved here for those on IRC: There has been much debate over Andy's basic railtypes included in Iron Horse.
13:54:28 <talltyler> What if we added some basic railtypes, including sprites, to OpenTTD for any vehicle set to use? Similar to how we provide tram tracks, but no trams.
13:54:28 <talltyler> Let's not worry about the railtype label for now, but I think the basic list which makes sense for OpenTTD is:
13:54:28 <talltyler> * Third-rail (not specifically metro but probably used for it)
13:54:28 <talltyler> * Narrow gauge (actual gauge agnostic)
13:54:29 <talltyler> * Narrow gauge with overhead electrification
13:54:29 <talltyler> Open to discussion on broad gauge, but it would need sprites that look different than standard gauge.
13:54:31 <talltyler> Anyone who wants more can make a railtype GRF.
13:57:54 <xarick> could i apply any of these for lists
13:59:32 <_glx_> some might have use when comparing lists, but I don't think any are really needed
13:59:55 <peter1138> There's a stable_sort in MoveGoodsToStation, and that's a perfect example of the comparision being insufficient.
14:00:33 <peter1138> The other one is in GUI code so isn't relevant.
14:02:09 <peter1138> Funnily enough, guess who wrote that comparison :)
14:08:36 <talltyler> Peter, care to elaborate on your "no"? To me, it would neatly solve the issue of players needing a compatible railtype GRF for their train GRFs, and the issue of train GRF authors including railtypes and the conflicts that result. 🙂
14:09:15 <talltyler> (Sorry, Andy, I agree that train GRFs shouldn't provide their own railtypes, but I also think they shouldn't have to rely on a railtype GRF)
14:10:11 <talltyler> I think the Termite/Horse rail sprites are suitable for inclusion as a base set add-on, if we decide to go that route.
14:10:21 <_glx_> train GRFs should be fine with just RAIL and ELRL
14:10:28 <peter1138> They don't have to rely on a railtype GRF, they can fallback to just default railtypes.
14:10:49 *** ChanServ sets mode: +v tokai
14:11:42 <peter1138> We don't add extra things that can be added by mods, especially if those extra things are already apparently limited in resources which would end up being hit sooner.
14:19:10 <audigex> _glx_: Silly take, frankly
14:20:25 <_glx_> but they can support more if railtypes are provided by other newGRF
14:22:06 <emperorjake> Even JP+ will work with just RAIL and ELRL
14:22:17 <emperorjake> thanks to fallbacks
14:23:03 <audigex> Sure, and that "works" in the loosest possible sense.... except it gives us the shitshow we currently have regarding railtypes where nothing is compatible and we're working around it with NML fallbacks. And as a newGRF developer I end up spending half my time trying to debug issues with why my set isn't working correctly with one of 100 railtype newGRFs
14:23:03 <audigex> The entire conversation comes from the fact this is a MASSIVE pain point for newGRF developers.... why would we be talking about it this much if it wasn't an issue?
14:24:04 <Borg> audigex: maybe I dont get it.. but.. why rail types newgrfs are independed of vehicles? thats odd..
14:24:10 <talltyler> andythenorth: Are you still in need of a resolution for your railtypes issue with JP+? I have a few ideas:
14:24:10 <talltyler> * Split railtypes back into Termite, and have Horse throw a Warning if Termite isn't loaded
14:24:10 <talltyler> * Instead of disabling Horse if JP+ Tracks is loaded, disable your tracks if it's loaded
14:24:10 <talltyler> Apologies if you've tried these already, just things that came to mind while thinking of possible other ways to solve this. 🙂
14:25:27 <audigex> I think he's more-or-less fixed it specifically with JP+, but that's kinda the point. You have to go out of your way to match compatibility to each railtype newGRF (not too bad if the Railtype author is around to discuss with, less fun for older ones where there's not even any code knocking about).... and more importantly, why are we expecting that train newGRF authors do that kind of legwork and
14:26:44 <audigex> Borg: Because otherwise you end up with a situation where someone loading a handful of vehicle newGRFs ends up with a hundred railtypes because each vehicle set is defining their own. And/or that they clash and cause issues
14:28:40 <Borg> uhm. right. I kept forgeting people can load 10s of different vehicle sets..
14:28:52 <Borg> well, you need some standarization then [;
14:31:36 <reldred> talltyler: It’s largely fixed now
14:32:25 <audigex> I'd also be fine with a "My newGRF doesn't play nicely with others, force the user to pick what to load in a friendly way" toggle, personally. If we wanted to take a wildly different approach. If that was implemented then I'd happily include my own rail types and set "rottweiler mode" on my newGRF
14:33:45 <audigex> But for me Iron Horse's issue with JP+ is PRECISELY why we need some kind of change here. Train newGRF authors shouldn't be expected to explicitly handle every railtype newGRF in order to avoid compatibility issues with very normal, basic track types, that's silly. Fair enough if you're doing something wildly niche then you're on your own, but the basic set of Narrow/Standard/Broad,
14:33:45 <audigex> Unelectrified/OHLE/3rd/4th should be available to all sets IMO
14:34:50 <audigex> (I add 4th because it matters to me, but I'd take an argument for Unelectrified/OHLE/Metro). HSR would be a similar "many would like it, not absolutely mandatory", and an argument could be made to remove Broad too
14:35:10 <audigex> Something like this could make sense too
14:35:10 <audigex> Narrow/Standard. Rail/OHLE/Metro/HSR
14:35:27 <_glx_> for me it's the same as GS needing explicit support for industry GRF
14:36:44 <audigex> There are a handful of GS, there are a handful of industry GRF. Behaviour of the GS is much more dependent on the industries
14:36:44 <audigex> Kinda different IMO. Railtypes are much more fundamental
14:38:04 <kaibaneddy> audigex: maybe you should make a "basic railtypes" newgrf, and then train set authors who agree with your philosophy can use/require it?
14:38:37 <audigex> kaibaneddy: Great idea
14:40:02 <audigex> Considering I literally just said I consider the main issue here to be that we have to cross-support too many newGRFs, I really don't see how that helps. Plus "X newGRF requires/is not compatible with Y newGRF" is horribly unintuitive to the player in the current UI
14:40:17 <xarick> set_symmetric_difference has no equivalent function 🙁
14:40:25 <audigex> Fatal errors all over the place, no clear way to mark which newGRFs need to be removed etc. It's nasty
14:49:00 <andythenorth> talltyler: Horse is 100% compatible with JP+ now, with a slightly shitty UX
14:58:19 <andythenorth> audigex: they're not 🙂
14:58:31 <andythenorth> railtype authors handle the train grf 🙂
14:58:39 <andythenorth> I know I'm a broken record saying this 🙂
15:00:12 <audigex> I refer more to the fact you had to make explicit changes to Horse in order to be compatible with the railtype GRF's restrictions
15:03:02 <andythenorth> well no that's self-inflicted
15:03:14 <andythenorth> because to me there's an entirely logical conclusion
15:03:22 <andythenorth> if railtype authors handle the train grf
15:03:29 <andythenorth> then the train grf needs to include railtypes
15:03:43 <peter1138> My old second hand records play better than this.
15:03:43 <andythenorth> which I am the only person on planet earth who holds that position
15:04:49 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:06:26 <_jgr_> xarick: Is there any use case for this?
15:07:19 <peter1138> If it's added then he can start doing more performance tests against it.
15:07:33 <_jgr_> Also providing weird methods which look very expensive but don't charge anything is not a plus from my point of view
15:07:45 <audigex> If someone keeps putting your old second hand records on, maybe they care about them? I have a policy that if I dismiss a user's request but then it keeps coming up, I revisit it because clearly my users care about it even if I think they shouldn't
15:08:24 <andythenorth> the debate about railtypes isn't a debate that's relevant to the core client 🙂
15:08:55 <andythenorth> it's entirely down to separate camps in newgrf authors who refuse to agree, or are simply never going to agree, for possibly valid reasons
15:09:08 <andythenorth> but unfortunately they're supposed to agree 🙂
15:09:24 <andythenorth> there's no spec problem at all
15:10:30 <_jgr_> The spec problem is that rail types is all based around matching arbitrary 4 character labels
15:11:17 <andythenorth> even that would have been fine, without the standardised railtype spec
15:11:51 <audigex> But the more "stuff" we move into the core client, the less friction there is. If we no longer have to account for narrow/standard/broad, HSR, or unelectrified/OHLE/3rd/4th, then that massively frees up compatibility concerns. NewGRF authors then only have to focus on the actually-niche, not treat basic things like third rail as niche
15:13:11 <andythenorth> just do it in the vehicle grf
15:13:25 <andythenorth> spec supports it, some people will gripe, nothing else goes wrong
15:14:17 <andythenorth> this started as a discussion in the other channel, because we could just nml include basic railtypes into train grfs, with detection and disabling if railtype grfs are found
15:14:34 <andythenorth> but obvs that derailed into a discussion about ballast colour, and how essential it is
15:16:50 <talltyler> For what it's worth, I deal with railway simulation in my day job and setting track compatibility, ballast colour, electrification voltage, etc., is just as fiddly in a system created from scratch for it, so it's not just a OpenTTD railtype problem. 🙂
15:18:02 <talltyler> You can simulate a real railway with all its quirks, model it in a way that's convenient for those building said virtual railway, or have a clean and consistent technical implementation. Pick two. 😄
15:18:17 <xarick> i dont have a use case i can think of
15:19:30 <andythenorth> talltyler: yes I pick both of all 3
15:50:10 *** Wormnest has joined #openttd
15:57:08 <andythenorth> what do dependencies do?
15:58:05 <andythenorth> will that cause the dependency grfs to be added to the active grf list in a game?
15:58:11 <andythenorth> I didn't want to test it live 😛
15:58:43 <peter1138> No, they cause content to be automatically selected for download. Mainly intended for scripts with script libraries.
15:59:38 <rito12_51026> andythenorth: That would be a cool feature
16:00:09 <andythenorth> peter1138: thanks
16:01:42 <xarick> can't think of a use case for my own
16:04:13 <xarick> it would probably be better to come up with a new list rather than modifying "this" list
16:04:41 <peter1138> It would be better to identify things that are needed instead of writing unnecessary things.
16:04:49 <peter1138> Of course, nobody is forcing you, but also...
16:05:32 <xarick> 2 parameters, 2 lists with 1 list as output
16:18:31 <xarick> something that I could actually use is an equivalent for SetViewportCatchmentTown
16:21:07 <xarick> oh... this is ... not what I expected
16:22:02 <xarick> do towns have a member about where their houses are placed?
16:22:57 <xarick> I wouldn't like to do a for (entire map), find house belonging to town and add to a tile list
16:34:05 <xarick> maybe building counts could store the tileindex of their houses :
17:38:25 <locosage> level 0 for sound errors was quite helpful actually
17:39:17 <locosage> otherwise idk how long would've took me to think of enabling debug logging instead of going through all kinds of sound settings
17:50:27 *** gelignite has joined #openttd
18:15:25 <peter1138> If we made all such errors level 0 it'd proably get quite noisy :p
18:20:25 <xarick> this looks ugly given the guys above
18:44:08 <peter1138> So make them 0 or 1?
19:32:31 <xarick> oh, so values are necessary
19:36:53 <xarick> airport types are also `for (local i = -1; i < 10; i++) {`
19:39:02 <xarick> j is the aircraft type btw
19:39:20 <xarick> for (local j = 0; j < 4; j++) {
20:13:17 *** Borg has quit IRC (Quit: leaving)
20:41:42 *** kuka_lie has joined #openttd
21:11:15 <rito12_51026> Should rivers go upward?
22:04:38 <xarick> haven't yet skimmed at the swamp code
22:34:55 <xarick> awesome, just awesome, i really wanted something like this
22:56:20 <xarick> but that's a Viewport thing
22:57:02 <xarick> I also tried exploring Town::building_counts
22:58:28 <xarick> was hoping to add a list of TileIndexes for each HouseID but turned out too complicated for me
23:02:32 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
