IRC logs for #openttd on OFTC at 2025-08-28
⏴ go to previous day
01:55:13 *** tokai|noir has joined #openttd
01:55:13 *** ChanServ sets mode: +v tokai|noir
02:00:48 *** Wormnest has quit IRC (Quit: Leaving)
02:02:11 *** tokai has quit IRC (Ping timeout: 480 seconds)
03:09:48 *** nemesis has joined #openttd
03:10:24 *** nemesis is now known as Guest25214
03:11:10 <Guest25214> why was my name changed?
03:14:41 *** Zathras has joined #openttd
03:15:29 *** Guest25214 has left #openttd
03:15:40 *** nemesis_ has joined #openttd
03:18:06 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
03:26:47 *** WormnestAndroid has quit IRC (Remote host closed the connection)
03:26:49 *** WormnestAndroid has joined #openttd
03:26:59 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:27:01 *** WormnestAndroid has joined #openttd
03:27:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:27:15 *** WormnestAndroid has joined #openttd
04:12:58 *** SigHunter has quit IRC (Remote host closed the connection)
04:14:00 *** SigHunter has joined #openttd
04:52:56 *** dh1 has quit IRC (Ping timeout: 480 seconds)
06:24:16 *** dh1 has quit IRC (Ping timeout: 480 seconds)
07:03:45 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
07:06:21 *** dh1 has quit IRC (Ping timeout: 480 seconds)
07:08:19 <andythenorth> does the nml railtype fallback approach possibly cause unpredictable results with the railtypetable?
07:08:49 <andythenorth> Horse has both trains and railtypes in the same grf, and cross-compatibility to other grfs appears to be broken
07:16:31 <LordAro> maybe we should rename all the lang files to be IETF codes
07:47:21 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
07:48:54 <peter1138> It's kinda weird that for TTO/TTD savegames we use something from inside the file as the title, but OpenTTD savegames just use the filename.
08:12:57 <andythenorth> how do railtype grfs resolve the labels without a railtype translation table?
08:13:08 <andythenorth> I thought the 4 char strings were just indexes into an RTT?
08:13:17 <andythenorth> seems that railtype grfs have string resolution directly?
08:14:18 *** orudge` has joined #openttd
08:14:18 *** ChanServ sets mode: +o orudge`
08:31:24 <peter1138> There are no strings, only DWord ids.
08:32:48 <andythenorth> but railtype grfs don't need to declare RTTs?
08:32:52 <andythenorth> so how does that work?
08:34:16 <andythenorth> but JP+ Tracks doesn't have one?
08:35:02 <andythenorth> it's a massively popular, extremely tested railtype grf
08:35:15 <andythenorth> I'm trying to make Iron Horse compatible with it, as Iron Horse breaks it
08:36:37 <peter1138> If there it doesn't refer to a railtype by index, only by label, then it doesn't need a translation table.
08:37:16 <andythenorth> I wonder how it works
08:37:33 <andythenorth> `MTRO` is in the compatible and powered list for lots of JP+ railtypes
08:37:41 <andythenorth> but `MTRO` is not a railtype in JP+
08:38:10 <andythenorth> does OpenTTD build some table of labels at game start?
08:38:46 <peter1138> Those properties use labels, not index.
08:39:45 <peter1138> If MTRO has been defined, then it has an index. The game can lookup that index from the label. It does not need a translation table for that.
08:40:27 <peter1138> If a property takes labels directly, then no translation table is involved.
08:41:35 <andythenorth> how does MTRO become defined?
08:44:47 <peter1138> By a railtype grf defining it?
08:46:55 <andythenorth> but JP+ can't define it
08:47:00 <andythenorth> because it needs all 64 slots afaik
08:54:51 <andythenorth> I _think_ that explains one of the confusing behaviours
08:56:46 <peter1138> If it needs all 64 slots and another GRF uses some first, that will cause some of the railtypes defined later to be dropped.
08:57:44 <andythenorth> specifically JP+ makes 3rd rail compatible with `MTRO` but doesn't define `MTRO`
08:58:46 <andythenorth> as far as I can tell, MTRO trains aren't buildable in JP+ 3rd rail depots
08:58:48 <peter1138> If it exists, it becomes compatible. If it doesn't exist, it's ignored.
08:59:09 <andythenorth> adding Metro Track Set 2.1.2 to the grf list causes `MTRO`trains to become buildable in JP+ 3rd rail depots
08:59:43 <peter1138> If MTRO doesn't exist, then there are no MTRO trains.
09:00:34 <andythenorth> ok this will seem circular, but what causes MTRO to exist? Defining a train for it, or defining a railtype for it?
09:04:46 <peter1138> It can only exist if it is defined as a railtype.
09:04:58 <peter1138> Just refering to a label doesn't make it exist.
09:05:32 <peter1138> (Badges are the only thing that behaves differently to that)
09:10:18 <andythenorth> so if I change a JP+ railtype to define `MTRO`
09:10:35 <andythenorth> then Horse MTRO trains appear in the depot for that type
09:12:35 <andythenorth> if MTRO is not defined in the game, then the JP+ compatible declaration of MTRO seems to have no effect
09:12:45 <andythenorth> I don't know how to fix this in Horse
09:13:13 <fairyflossy> make MTRO fallback onto SAA3 in horse?
09:13:31 <peter1138> Yeah, isn't this what the NML railtype fallback mechanism is for?
09:13:52 <peter1138> (Whether that's a good idea or not, I can't say.)
09:14:23 <fairyflossy> That also doesn't solve the problem Andy is talking about
09:14:33 <fairyflossy> Yes it makes horse stuff appear on JP+ Third Rail
09:14:39 <andythenorth> the NML fallback is a distraction
09:14:40 <fairyflossy> but that doesn't mean that JP+ MTRO Declaration works
09:14:49 <andythenorth> compatibility is determined by **railtype** grfs
09:15:24 <andythenorth> that NML has unwisely plastered a stupid pseudo compatibility layer over it, and confused apparently *all* active grf authors
09:15:29 <andythenorth> is not relevant 🙂
09:16:29 <fairyflossy> I do think it might be a JP+ thing because on my fork of JP+ I am getting your new Horse Metros on the 3rd Rail track
09:17:56 <andythenorth> does your fork of JP+ change anything?
09:18:05 <fairyflossy> yes, and I think I know what's happening
09:18:21 <fairyflossy> JP+ defines MTRO as a callback for tt_metro, but tt_metro is NOT their 3rd Rail track
09:18:49 <andythenorth> tt_metro is just a constant expansion
09:18:51 <andythenorth> to a list of labels
09:19:45 <fairyflossy> Hrm I might not quite know well enough what's going on actually
09:20:43 <fairyflossy> Right yes I specifically declare one of the metro tracks to be MTRO and the other 3RDR so that's why it works for me
09:20:55 <fairyflossy> JP+ doesn't define any tracks that are MTRO
09:21:18 <andythenorth> ok and JP+ needs all 64 railtypes afaik
09:21:36 <andythenorth> so the compatibility props are only going to be effective for JP+ railtypes
09:21:51 <andythenorth> and there will be unpredictable or undefined behaviour when JP+ is used with other grfs that define railtypes
09:22:02 <andythenorth> and grf load order will be relevant
09:22:32 <fairyflossy> and that means that JP+ defining compatibility for MTRO doesn't matter because MTRO doesn't exist and trains with MTRO don't run on it?
09:22:40 <andythenorth> as far as I can understand
09:22:51 <andythenorth> and this is why Horse shouldn't define any railtypes
09:23:03 <andythenorth> because the full railtype space is required for other railtype grfs
09:23:25 <andythenorth> so the specific solution is to delete Horse metro trains
09:23:31 <andythenorth> as MTRO is not available
09:23:50 <peter1138> It's available if it's defined by a NewGRF that defines it.
09:24:15 <andythenorth> but other grfs cannot define railtypes without breaking JP+
09:24:19 <peter1138> Or you use NML's fallback functionality.
09:24:28 <andythenorth> because JP+ Tracks has reserved all 64 slots
09:24:45 <andythenorth> (I don't know if that's true, or a misunderstanding by me)
09:25:08 <peter1138> Railtype GRFs don't need to coexist. Not everyone is using JP+ tracks.
09:25:15 <andythenorth> hmm ` nmlc info: Railtype items: 63/64`
09:25:37 <peter1138> It is generally the idea that vehicles and infrastructure should be defined separately though.
09:25:53 <andythenorth> yes, I am out on a limb containing only me
09:25:58 <andythenorth> I am fine with that
09:26:24 <andythenorth> but I need to delete Horse metro I think
09:26:25 <fairyflossy> I agree with that idea, but then why can't JP+ say "Okay, we support MTRO" and horse says "We run on MTRO" but nothing happens unless you add a third set that says "This is MTRO"
09:26:43 <fairyflossy> Wouldn't that solve the problem?
09:26:47 <andythenorth> because JP+ needs 63 of the 64 slots
09:27:02 <andythenorth> I guess that leaves one free for compatibility
09:34:26 <dh1> this is the bane of my existence:
09:34:26 <dh1> change the ##name to 'Maori' (without special characters) as that's the official ISO English way to write it.
09:35:28 <peter1138> > ##name Maori (New Zealand)
09:35:31 <fairyflossy> andythenorth: I think JP+ can actually support MTRO, if I'm understanding what I did now correctly:
09:35:31 <fairyflossy> JP+ defines tracks 'SAA3' and 'SBA3'
09:35:31 <fairyflossy> SAA3 has alternative_railtype_list: ALT_SAA3
09:35:31 <fairyflossy> Add 'MTRO' to ALT_SAA3
09:35:31 <fairyflossy> Get Horse MTRO on JP+ 3rd Rail
09:35:43 <andythenorth> how was cross-grf railtype compatibility _supposed_ to work, if a railtype grf uses ~all the slots?
09:35:59 <andythenorth> it seems to be a difficult case
09:36:01 <dh1> i work with a lot of data with Māori names or words in it
09:36:43 <dh1> and it is an absolute lottery which tools will be happy with pōtae / macrons
09:37:05 <peter1138> One railtype grf: no problem. Multiple railtype grfs: user must be aware and only configure those known to be compatible.
09:40:09 <andythenorth> yeah ok so prop 0x1D
09:40:28 <andythenorth> means that `MTRO` doesn't need to be defined
09:41:35 <andythenorth> ok, I _think_ that works
09:41:52 <andythenorth> fairyflossy: need to reconfirm, but that might be a good catch thanks
09:42:23 <andythenorth> NML fallback table strikes again
09:42:31 <fairyflossy> I'm testing it right now
09:42:43 <fairyflossy> Editing a fresh copy of the JP+ Tracks source
09:44:46 <fairyflossy> andythenorth: Yup, downloaded fresh copy of JP+ Tracks Source
09:44:46 <fairyflossy> Compiled it. Iron Horse trains do not appear on 3rd Rail
09:44:46 <fairyflossy> Added "MTRO" to "ALT_SAA3"
09:44:46 <fairyflossy> Iron horse trains appear on 3rd rail
09:45:18 <andythenorth> this is with the patched Horse I sent which uses MTRO as the label?
09:45:41 <fairyflossy> This is with the one you sent earlier, I believe yes
09:45:57 <andythenorth> ok so that was very helpful thanks
09:46:06 <peter1138> Tiny bitmap fonts, bloomin'eck.
09:46:11 <fairyflossy> here's the .grf I just compiled if you want to test it on your end
09:47:50 <andythenorth> I did the same in my checkout
09:50:20 <andythenorth> ok so there's a specific remaining issue which is basically neurodiversity handbag fight about trains
09:51:59 <fairyflossy> But at least this means that JP+ can support Horse with a small edit, just doesn't atm
09:52:58 <andythenorth> Horse doesn't use MTRO as the fallback
09:53:11 <andythenorth> it uses SAA4, to conform to the standardised scheme
09:53:38 <andythenorth> but JP+ doesn't handle SAA4
09:53:43 <fairyflossy> But it's again simply a matter of JP+ adding things to their table if they want to
09:53:51 <fairyflossy> And if they don't that's on JP+ not choosing to support
09:54:03 <fairyflossy> and becomes intended feature?
09:54:24 <fairyflossy> It's not "Iron Horse doesn't work with JP+", it's "JP+ doesn't work with Iron Horse"
09:54:39 <fairyflossy> Iron Horse is setting out what it runs on, and it's up to the trackset to decide what it supports
09:55:39 <andythenorth> because SAA4 isn't in the base set of labels
09:55:41 <peter1138> Not exactly, cooperation is probably needed both sides.
09:55:53 <andythenorth> and the community expectation is that SAA4 should cascade to SAA3
09:56:06 <peter1138> So where MTRO doesn't exist, IH could try an alternative.
09:56:45 <andythenorth> part of this is I'm just staging a dirty protest about the NML fallback system, because it's problematic
09:57:48 <andythenorth> when I first added railtypes, the advice from Frosch was to define my own labels, and ignore everyone else
09:58:00 <andythenorth> because the spec gives them the means to change the semantics
09:58:10 <andythenorth> but that no longer works when a grf needs all of the slots
10:07:06 <peter1138> Hmm, no translations were updated this morning, coincidence or broken?
10:11:11 <LordAro> Mostly because they clearly haven't read the text properly, which generally calls into question either their ability to read English, or their attention to detail
10:11:20 <LordAro> neither of which are particularly desirable features for translators
10:12:00 <LordAro> but if you insist, i'll do it properly
10:15:25 <rito12_51026> Thank you very much
10:29:59 <peter1138> Judgement error. I have no biscuits.
10:42:09 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
11:09:53 <peter1138> Oops, bread is mouldy.
11:15:58 <andythenorth> I've eaten mouldy bread, don't advise it
11:21:08 <peter1138> I prefer to avoid it.
11:23:15 <peter1138> #14357 would let you specify multiple labels for each vehicle, but you'd still need to know what those labels are.
11:24:44 <peter1138> n both labels actually existed, then it would be able to run on both.
11:25:09 *** Flygon has quit IRC (Remote host closed the connection)
11:46:44 <_glx_> Clearly the AI didn't understand the code
11:48:14 <talltyler> The user’s profile contribution history is illuminating. A long list of PRs closed for “please don’t submit AI slop”.
11:48:35 <LordAro> it's oddly humanly written though
11:49:28 <LordAro> i mean in the lack of grammar & punctuation sense
11:52:50 <_glx_> Ho finding bugs by reading code works (when you really understand the code)
11:55:59 <peter1138> Don't forget the "I didn't know that was a bug" bugs...
12:00:31 <talltyler> My advice doesn’t apply to people who understand the code 🙂
12:02:02 <talltyler> Just to people who poke around GitHub repos looking for stuff to “fix”
12:26:06 <LordAro> isn't the base 2cc fork also dubiously named?
12:26:54 <ahyangyi> talltyler: I really like this: "It's better to find bugs by actually playing the game."
12:27:56 <ahyangyi> The existing AI agents all claim to be able to fix bugs, but they are not able to play the game. Which is a... very funny combination.
12:46:10 <peter1138> I need to free up space in my freezer. So I had an icecream.
12:46:30 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:46:32 *** WormnestAndroid has joined #openttd
13:25:27 <peter1138> Urgh, database joins. I need something like "join this if it's not already in the reults", but that would make it stateful I guess.
13:35:22 <ahyangyi> Which leads to the question about AI bug reports.
13:35:22 <ahyangyi> While I believe that any AI bug report *today* would be most likely bogus, can we say that there is less copyright concern with regards to them?
13:50:53 <Rubidium> the problem with AI bug reports is that it takes effort to discard them, thus reducing the likeliness for developers to look at bug reports and in the end the quality going down
13:51:32 <davidxn> The arrogance of just submitting a complete inversion of the logic without even testing it to see if it was wrong :X
13:52:14 <Rubidium> similarly with sloppy pull requests; for someone to approve it, they must understand it. If it's utter crap, that still takes a lot of time that someone would have likely spent on something more productive
13:53:43 <Rubidium> and to be honest, I have certain authors in a personal ban list when viewing pull requests because of the PR sloppiness
13:57:30 <Rubidium> so it'll wear people out and they'll just quit. As a result... the whole project dies. Although, maybe it would be a good experiment to have an OpenTTD-AI variant where some AIs are in charge of PRs and the likes. I wonder how long it takes until it doesn't compile anymore
14:01:58 <talltyler> “Dead OpenTTD theory” 😛
14:03:04 <peter1138> If my PRs are sloppy please tell me.
14:10:08 <LordAro> you usually tell us first :p
14:13:10 <Rubidium> well, it's definitely not anyone with OpenTTD-PR-merge rights
14:23:07 <ahyangyi> Rubidium: Yes, my question was only on the copyright part, and I do not question the other parts (where developer time is precious and looking at AI bug reports is counterproductive)
14:23:46 <ahyangyi> ahyangyi: I was wrong.
14:24:11 <ahyangyi> ( though tbh "finishing daily missions in a gatcha" is hardly "playing games" )
14:52:14 <peter1138> That was a bad choice.
15:21:19 *** Wormnest has joined #openttd
15:59:02 <andythenorth> I guess the railtype compatibility and powered properties don't recurse?
16:02:36 <andythenorth> I keep forgetting this
16:16:40 *** orudge` has quit IRC (Ping timeout: 480 seconds)
16:31:09 *** Smedles has joined #openttd
17:55:11 <peter1138> So the constants are defined in palette_func.h and 1) the spacing is odd (hysterical) 2) they're in hex. 105 in hex is... nice.
17:56:27 <_zephyris> So just give it a name there? Can do...
17:57:42 <LordAro> now comes the real challenge
17:57:53 <peter1138> Dunno, there's several other places where there is no constant.
17:59:13 <_zephyris> I searched for 105 and 0x69, seems to be the only usage
18:02:20 <_zephyris> Name all the colours, by most similar to the standard 140 CSS/HTML names
18:02:36 <_zephyris> Or name them PC_105
18:04:00 <peter1138> For a one-off use, I'm happy with no constant, to be honest.
18:04:45 <peter1138> Requiring an explicit `PixelColour{105}` instead of just `105` makes it bit clearer already.
18:04:58 <peter1138> And in Toyland some of the colours are changed, IIRC.
18:06:35 <peter1138> (Or one of the climates, anyway.)
18:06:52 <_zephyris> Water in toyland, anything else?
18:07:49 <_zephyris> Hmm, toyland-specific end game screens. The nichest easter egg possible
18:42:12 <Rubidium> especially the 1000 points toyland end game screen
19:16:26 *** ufo-piloot has quit IRC (Quit: you click on fancy icons. i execute code !)
19:17:38 *** ufo-piloot has joined #openttd
19:31:41 *** audigex has joined #openttd
19:31:41 <audigex> andythenorth: How would that work with the current way NML fallbacks work?
19:31:41 <audigex> Nice change though, would remove a significant headache for multi-mode vehicles
19:32:50 <andythenorth> it's slightly unclear
19:32:51 <brickblock19280> The same as currently it still just takes indexes to the table
19:33:28 <peter1138> They're two separate things, neither of them prevents the other from doing its thing.
19:33:29 <andythenorth> what's unclear is whether it eliminates the fallback approach
19:33:49 *** toktik has quit IRC (Remote host closed the connection)
19:34:11 <brickblock19280> It could but I think that it feels wrong to do so
19:34:24 <brickblock19280> Probably the best way though
19:34:34 <audigex> andythenorth: Yeah, that was my thought. Or whether it reduces the number of fallbacks needed
19:34:34 <audigex> Eg if I can just say "This works on any railtype that supports ELRL or SAA3/3RDC" then I don't need to define SAAZ surely?
19:35:04 <brickblock19280> Yeah SAAZ would no longer be necessary for trains
19:36:01 <brickblock19280> But falling back to SAAZ is unlikely to happen in practice
19:36:24 <peter1138> Why not comment on the PR? It's been opened a while.
19:36:49 <audigex> brickblock19280: You wouldn't fall back to SAAZ, but you'd have it in the railtype list first followed by fallbacks
19:37:29 <audigex> peter1138: I tend to reply to the PR when I have a specific input on changing the PR, rather than when I'm just figuring out how it works. Seems better than clogging up the PR with questions that are just me not understanding the change yet as I figure it out
19:37:50 <brickblock19280> peter1138: I don't have anything to add other than what I've already said
19:38:02 <andythenorth> my comment in June is that this isn't intended to replace fallbacks, which must have been related to something Michi said
19:38:56 <peter1138> So we use PRs to allow discussion about the PR. That's kinda the point.
19:39:27 <peter1138> Having it locked away in some Discord chat that other people can't see is not really useful.
19:39:28 <brickblock19280> An SAAA vehicle should not also have ELRL despite also wanting to be available there when I SAAA doesn't exist
19:40:06 <_glx_> I think you are overthinking fallback mechanism andy
19:40:42 <audigex> peter1138: I think it depends what's actually being discussed though
19:40:42 <audigex> "I think X should work differently" or "This seems a strange way to do Y" absolutely belongs in the PR for discussion
19:40:42 <audigex> "Can someone explain to me what this PR does and how Z works?" seems more suited to a random Discord chat because it doesn't need to be preserved for posterity or viewable by whoever's reviewing or merging the PR
19:41:14 <_glx_> fallback is just "set this label to whichever already defined label" with a priority order
19:41:23 <andythenorth> _glx_: it's because it's widely misused and misunderstood by vehicle grf authors
19:41:25 <_glx_> only the first existing is used
19:42:00 <brickblock19280> andythenorth: Is it? I've not run into many nonfunctional ones
19:42:21 <peter1138> Asking how it's meant to be used is a perfectly valid discussion on it. It enables things to be worked out. Like maybe it doesn't actually work in a way that is useful.
19:42:25 <_glx_> as I said in the other channel, fallback thing is just dynamically filling the static global property
19:43:43 <andythenorth> because it makes interactions with railtype grfs unpredictable
19:44:04 <andythenorth> I'm not 100% against it, I just think it's added confusion
19:44:22 <andythenorth> there are already 3 railtype properties to consider for compatibility
19:44:23 <_glx_> it mainly depends on load order I think, like most newgrf things
19:44:28 <andythenorth> and the additive compatibility
19:44:33 <audigex> _glx_: Right, but that's my point
19:44:33 <audigex> Let's say my fallback is (SAAZ, SAA3, ELRL), or (SAAZ, ELRL, SAA3)
19:44:33 <audigex> If SAAZ exists, great - it can run on both
19:44:33 <audigex> If SAAZ doesn't exist, then the train gets locked to either ELRL or SAA3
19:44:33 <audigex> What I actually want is to be able to give a list of rail types (ELRL, SAA3) that it can operate on, and THEN maybe provide a fallback if none of those are available (eg I might have SAA4 fall back to SAA3, but only if SAA4 doesn't exist)
19:44:39 <brickblock19280> It's obviously better than not seeing any trains on vanilla tracks
19:45:05 <andythenorth> `If SAAZ doesn't exist, then the train gets locked to either ELRL or SAA3`
19:45:42 <andythenorth> the train takes ELRL or SAA3 for it's prop 0x05 value, but the railtypes it runs on is determined by the union of all the railtype grfs present
19:45:45 <brickblock19280> That is current behavior
19:46:26 <andythenorth> that means that railtype authors need to consider each other's choices
19:46:28 <_glx_> railtypetable just sets shortcuts for when you define vehicle properties
19:46:34 <andythenorth> and try to anticipate what the vehicle will fallback to
19:46:43 <andythenorth> so railtype A tries to match MyLovelyTrain
19:46:46 <audigex> andythenorth: Mine sure as shit does with some rail types
19:46:53 <andythenorth> then player adds railtype grf B alongside A
19:47:03 <brickblock19280> They shouldn't
19:47:11 <andythenorth> now MyLovelyTrain behaves differently in railtype grf A
19:47:20 <ahyangyi> Ah, reminds me of font fallbacks
19:47:42 <ahyangyi> Web page chooses "A, B", user sets font C as a fallback for A, do you see B or C?
19:47:50 <ahyangyi> Chrome and Firefox make different answers here..
19:48:06 <andythenorth> yes it's quite similar
19:48:26 <_glx_> main issue is the compatibility is decided by railtype, while it should be done by vehicle (for me it would make more sense that way), and that's the idea behind #14357
19:49:37 <audigex> brickblock19280: BRTrains dual-voltage units don't work properly with some railtype sets
19:49:37 <audigex> Grab this combination, and several units only appear on 3rd rail and nobody's ever managed to explain to me why
19:49:45 <brickblock19280> It has to be done by both for any chance of interoperability with future railtypes
19:50:37 <brickblock19280> audigex: SAAZ doesn't exist so they become 3rd rail
19:51:02 <audigex> brickblock19280: Yes, exactly? I can't say "This should work on 3rd rail or ELRL" as far as I can tell?
19:51:08 <brickblock19280> They shouldn't was referring to the multiple track sets thing
19:51:21 <_glx_> I think the main concern for many it allowing high speed train on both normal and HS track, and it's painful to make it work with only railtype compat
19:51:39 <andythenorth> audigex: there are several answers to that
19:51:39 <brickblock19280> audigex: With SAAZ you can hope but this pr solves that
19:51:49 <audigex> This would be how I'd actaully want to define it
19:51:49 <audigex> The train would run on any rail type that supported either OPT1 or OPT2 (NOT just picking one or the other), and then would fall back to FALL and BACK if neither OPT1 or OPT2 was available
19:52:17 <andythenorth> have you not defined SAAZ in your train grf?
19:52:20 <brickblock19280> That won't happen
19:52:42 <_glx_> but railtype table is a simple property mapping a label to an index
19:52:51 <audigex> andythenorth: No, I don't provide any tracks, only trains
19:53:35 <andythenorth> until 14357 is added
19:53:41 <andythenorth> you need to add your own railtypes
19:53:54 <audigex> Should I be defining SAAZ?
19:53:54 <audigex> Y'all say this stuff like I should just know how it works, I've never seen a good explanation of it written down anywhere
19:53:56 <andythenorth> or accept that you don't control the behaviour of trains in your grf, railtype authors do
19:54:15 <andythenorth> audigex: it's quite a contested set of opinions currently
19:54:17 <brickblock19280> Which is imo the worst solution for railtype set compatibility
19:54:23 <audigex> andythenorth: Like I have to include graphics for a rail type in a train set?
19:54:33 <andythenorth> there are non-buildable types
19:54:42 <audigex> Then I have not a single clue what you're talking about
19:54:49 <andythenorth> you define SAAZ and make it cross compatible to ELRL and SAA3
19:55:01 <audigex> Where in the docs should I be looking to understand this? Because it's a complete enigma to me that I've never seen explained
19:55:08 <andythenorth> but you only get to do one, because JP+ Trains needs 63
19:55:24 <audigex> Define it where? My Railtype table?
19:55:27 <ahyangyi> andythenorth: virtual track types?
19:56:00 <andythenorth> audigex: as FEAT_RAILTYPES
19:56:01 <brickblock19280> Defining your own railtype hidden or not is bad unless your just bundeling a complete railtype set
19:56:01 <audigex> This shit's so confusing
19:56:05 <_glx_> hidden railtypes used for cross compat is something addressed by the PR IIRC
19:56:31 <andythenorth> audigex: ➕ ➕ to "confusing"
19:56:39 <andythenorth> you are not alone, nor the first on this path
19:56:57 <ahyangyi> andythenorth: This feels weirdly recursive 😛
19:57:04 <brickblock19280> audigex: The and would be in the vehicle item but other than that it should become this
19:57:16 <andythenorth> it's all resolvable though
19:57:31 <audigex> Literally all I want to do is be able to say "This is a train, it can run on (any, of, these ,rail, types,), or if they don't exist it can fall back to (any, of, these)
19:57:39 <audigex> A train set shouldn't have to give a shit beyond that
19:57:48 <_glx_> audigex: your EXAMPLE can only have one value, determined on grf loading
19:58:10 <audigex> _glx_: I understand that. I'm saying I'd like it, uhh, not to?
19:58:31 <_glx_> it's the NFO spec, NML add fancy stuff around it, but in the end it's still a single value
19:58:43 <andythenorth> at least until 14357
19:58:45 <brickblock19280> audigex: This isn't quite possible since it a list of independent fallback series as implemented in the pr but that should still cover all cases
19:59:08 <audigex> So what does 14357 change exactly? I'm still non the wiser
19:59:29 <andythenorth> it converts train prop 0x05 from a single railtype table index to a list
19:59:32 <brickblock19280> It allows a vehicle to have multiple indexes to the table
19:59:54 <audigex> So I'll just be able to say "ELRL, SAA3, 3RDC" and it'll run on any of them?
19:59:59 <brickblock19280> So it can go behave as multiple labels at the same time
20:00:01 <andythenorth> if they're defined
20:00:12 <audigex> And what happens if only 1 of the 3 is defined?
20:00:25 <andythenorth> it only runs on that 1
20:00:27 <audigex> It just works on that, or it falls back to something else?
20:00:38 <brickblock19280> It will be on that one and potentially any fallback for the others
20:01:05 <andythenorth> the fallbacks remain a bad idea
20:01:13 <brickblock19280> So that might need more control in nml but it can be done in nfo
20:01:40 <audigex> So let's say I have something that I want to run on any/all of (SAA4, 4RDC, or ELRL)
20:01:40 <audigex> But if none of those exist (and ONLY if none of those exist) I'll allow it to run on (SAA3 or 3RDC)
20:01:49 <audigex> Or rather, will it be possible with 14357
20:01:52 <andythenorth> audigex: or (and this will appear unhelpful) you ignore railtype grfs and include your own in your train grf
20:02:04 <andythenorth> (which is approximately what frosch recommended for Iron Horse)
20:02:14 <brickblock19280> audigex: Yes but not in nml
20:02:17 <audigex> andythenorth: You keep saying this and I still don't know what you mean :p
20:02:32 <brickblock19280> Or maybe but not easily
20:02:41 <brickblock19280> Could ofc be added to nml
20:02:52 <andythenorth> you **have** to cede control to the railtype grfs
20:03:01 <andythenorth> train author doesn't determine how the vehicle behaves
20:03:11 <andythenorth> until you accept that, it's all FML
20:03:15 <audigex> I am once again asking for this to happen
20:03:23 <audigex> How do we make this happen?
20:04:04 <brickblock19280> That syntax is theoretically possible with the pr but I don't think it's that good
20:04:09 <andythenorth> how are your predicates organised?
20:04:29 <_glx_> yeah I don't imagine a syntax change for the table itself
20:04:45 <_glx_> it's already confusing as it is
20:04:50 <andythenorth> how many combinations do you need to handle?
20:04:52 <brickblock19280> It's kinda necessary for the specified use case though
20:05:11 <brickblock19280> Nfo could do it
20:05:43 <peter1138> List all the railtypes you want in your translation table.
20:06:04 <audigex> It just seems like the obvious answer for vehicle set authors is to be able to say (ANY, OF, THESE) falling back to (SOME, FALLBACK, OPTIONS), falling back to (LAST, RESORT)
20:06:04 <audigex> Basically just fallback groups
20:06:14 <brickblock19280> audigex: This would need to be split into two different ones that only fallback if neither exists but that's entirely possible in grf/nfo
20:06:20 <peter1138> Then list all the compatible railtypes in prop 34.
20:06:28 <andythenorth> so (A, B, C) and (D, E)?
20:06:32 <audigex> It tries to find any in the first group. If one or more exists then it uses that group. If not, it falls back to the next group
20:06:38 <andythenorth> but if no B, then we fall back to the second group?
20:06:44 <brickblock19280> That is possible
20:06:46 <andythenorth> or is it 'none of A, B, C'?
20:06:49 <andythenorth> what's the predicate?
20:07:36 <audigex> (A, B, C), (D, E), (F, G), H
20:07:36 <audigex> If ANY of A/B/C exist, then the train operates on A or B or C
20:07:36 <audigex> If NONE of A/B/C exist, then check (D,E) and repeat the logic
20:07:51 <andythenorth> is this for multi-system? or just fallback?
20:08:30 <audigex> (A, B, C) would be multi system, if A and B exist it can operate on both. If A B C exist it can operate on all 3. If only A exists, it operate son A
20:08:30 <audigex> (ABC) > (DE) > (FG) > H is fallback
20:08:45 <audigex> I doubt anyone would need that much complexity
20:08:49 <brickblock19280> Hmm true that case actually isn't possible at more then one layer
20:08:59 <_glx_> railtypetable is a list of labels your vehicle grf expects (with or without fallback)
20:09:03 <andythenorth> audigex: have you observed the grf community? 🙂
20:09:14 <brickblock19280> Only abc > de would work
20:09:58 <andythenorth> SAAZ, [SAAE, SAA3], [ELRL, SAA3], [SAAE, 3RDR]
20:10:05 <audigex> But the point being I can say
20:10:05 <audigex> (SAAZ, ELRL, 4RDC), (SAA3, 3RDC), OTHER
20:10:05 <audigex> It'll try to run on 4th rail or ELRL, but if none exist it'll run on 3rd rail. And only if none of those exist will it fall back to other options
20:10:34 <brickblock19280> brickblock19280: More layers might work actually but it gets incredibly complex
20:10:35 <andythenorth> well you need all the combinations of SAA3 and other labels
20:10:44 <andythenorth> and all the combinations of ELRL and other labels
20:11:25 <audigex> No because it would have already used the first group if ELRL existed
20:11:41 <andythenorth> ok so then it's possibly just a single-mode vehicle?
20:11:50 <peter1138> If you can do an if-condition in NML then you can do it.
20:12:12 <peter1138> But whether that's wise is another matter.
20:12:26 <audigex> Yeah, if only 4RDC exists then it would operate as 4RDC single mode
20:12:26 <audigex> But if 4RDC and SAAZ exists it would operate on either
20:12:26 <audigex> Only if none of 4RDC/SAAZ/ELRL exist, would it fall back to 3rd rail, and then narrow gauge
20:12:29 <brickblock19280> That code would be incredibly ugly but so is the current nfo
20:12:31 <andythenorth> if railtypes had meaningless UUIDs
20:12:34 <andythenorth> with no semantics
20:12:37 <andythenorth> and badges for behaviour
20:12:47 <ahyangyi> Fortunately I don't work on railtype tables, otherwise I would keep coming up with weird scenarios such as (RED, YELLOW, GREEN, (METR > ELRL > RAIL))
20:12:57 <_glx_> hidden if-condition inside table definition was supposed to be helpful (that's the fallback stuff)
20:13:07 <andythenorth> I find this pretence that railtype translation tables have these lists in...very odd
20:13:19 <peter1138> _glx_, yeah, but in this case they want it to kinda be sideways or something.
20:13:19 <andythenorth> it entirely obfuscates the interface
20:13:20 <brickblock19280> It is it's just not capable enough once this pr is merged
20:13:20 <audigex> brickblock19280: Doesn't look that bad to me?
20:13:44 <brickblock19280> I mean that you could do it without changes to nml
20:14:09 <audigex> Yeah I'm working on the assumption NML would be changed to match
20:14:23 <brickblock19280> That syntax is very complex and hard to implement
20:15:15 <andythenorth> badges anyone? 👀
20:15:23 <brickblock19280> They don't help
20:15:41 <_glx_> nml only care about the actual table content when generating the act0 for the table, all other places will just use the key
20:16:24 <andythenorth> we should have auto-generated the railtype table in nml 😛
20:16:25 <_glx_> as an index into the actual act0 table
20:16:31 <andythenorth> and never let authors see it
21:02:33 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
21:03:53 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:48:30 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:48:51 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
21:52:46 <tony_pixel> _glx_: when i reference some item in switch before the first definition of said item, does nml simply store these forward references and replaces with calculate ids in the end?
22:10:42 <_glx_> tony_pixel: in most case I think forward references don't work with nml
22:16:53 <tony_pixel> In most cases yes, but I certainly did switches that reference item_... labels before the label itself is defined
22:17:07 <tony_pixel> I think I can check the source in any case
22:35:36 *** ChanServ sets mode: +v tokai
22:42:29 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:36:30 *** bryjen has quit IRC (Quit: Leaving)
continue to next day ⏵
