IRC logs for #openttd on OFTC at 2025-06-12
⏴ go to previous day
00:48:47 *** toktik has quit IRC (Remote host closed the connection)
02:36:52 *** Wormnest has quit IRC (Quit: Leaving)
02:40:41 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:12:14 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:17:14 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:17:16 *** WormnestAndroid has joined #openttd
03:17:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:17:27 *** WormnestAndroid has joined #openttd
03:17:30 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:17:31 *** WormnestAndroid has joined #openttd
03:56:46 <jfkuayue> Is “spacebars” just an abbreviation of “spacebar heating”?
04:42:45 <DorpsGek> - Update: Translations from eints (by translators)
06:18:30 <_zephyris> There's an in-game on-screen keyboard, surely that provides all the sprites you need?
07:45:47 <peter1138[d]> I never noticed that US english uses "maintain" instead of "service"
07:46:43 <peter1138[d]> So you end up with strings such as "Maintain non-stop" which could mean something completely different...
07:47:15 <peter1138[d]> Granted, "Service non-stop" is a bit of a ridiculous string anyway.
07:57:14 <wensimehrp> jfkuayue: xkcd moment
08:00:04 <wensimehrp> peter1138[d]: You mean 服务 维护 维修 保养 维保 修理 and families
08:17:35 <peter1138[d]> Speaking on font-weight inconsistencies...
08:18:08 <peter1138[d]> Damn it, my enter key is getting sensitive again.
08:21:28 <peter1138[d]> This best font stuff needs revision.
08:23:55 <wensimehrp> Those pixelated characters doesn't seem like unifont for me...
08:35:12 <peter1138[d]> wensimehrp: Seems to be a font with hinting. If the size is changed they no longer look like a pixel font. 😮
08:36:22 <peter1138[d]> Anyway, I hope I'm not pasting images of anything rude as I've no idea what it says 🙂
08:36:52 <jfkuayue> It is all “maintaining”
08:41:44 <peter1138[d]> Hmm, how are meant to know which variant of a font we need for CJK?
08:56:19 *** mindlesstux has joined #openttd
09:03:09 *** gelignite has joined #openttd
09:05:56 <peter1138[d]> It's picked "Noto Sans CJK SC" for Korean 😮
09:06:24 <peter1138[d]> (Because there is no information other than a few codepoints.)
09:53:20 <jfkuayue> Waiting for plane transfer, received an accident for the type of plane I am riding…
10:03:44 <peter1138[d]> What does that mean?
10:13:50 <peter1138[d]> Oh, news of an accident.
11:41:09 *** michi_cc has joined #openttd
11:41:09 <michi_cc> _jgr_: On PR#9953 you made some comments (and linked a JGRPP commit) regarding asymmetric compatible railtypes. Do you still remember the exact issues this fixes?
11:41:09 <michi_cc> The only things I come up with on the top of me head is when you build a new track up to a dead end with a reservation on or a manually reversing a train at just the right spot.
11:42:26 <michi_cc> frosch123: For PR#9953, did you have anything in mind on how to deal with savegame compatibility, or was that still up in the air?
11:59:51 <peter1138[d]> Don't think so, OpenGFX2+ content comes from there as well.
12:02:29 <_jgr_> michi_cc: There are mixed railtype layouts involving stations where this can cause train crashes without manual intervention, I can dig up the original report and go into more detail after work
12:20:15 <_zephyris> Right repo, bug report makes sense with the clearer title
12:22:28 <peter1138[d]> Oof, colleague did a silly. We're removing a load of database fields, and that means some views need to be dropped and recreated.
12:22:44 <peter1138[d]> They're done it in separate update files, so it won't be done in a single transaction.
12:23:05 <peter1138[d]> So it will leave things in broken state in the middle, or if it fails.
12:23:19 <michi_cc> _jgr_: Thanks, would be good. I have some other ideas around railtypes, and I don't want to miss something 🙂
12:23:54 <andythenorth> properties for compatibility? 😛
12:24:59 <cmcaine> I downloaded the OpenGFX2+ Landscape NewGRF and I don't see what it changes (beyond that bug) compared to using the OpenGFX2 HD Baseset. Maybe the idea is that it doesn't change anything and the NewGRFs are so you can choose which bits of the baseset to use?
12:25:03 <peter1138[d]> There's the 'problem' of placed two stations of different rail types end-to-end.
12:25:20 <andythenorth> or to put it less abstractly, if the model railroad crowd want to set actual axle weight in tonnes, maybe we should just make a static action 0 prop for that
12:25:20 <peter1138[d]> Trains reaching the end will crash into each other.
12:25:27 <peter1138[d]> (Because they are touching)
12:25:28 <andythenorth> and similar apparent cases
12:42:31 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:42:50 *** WormnestAndroid has joined #openttd
12:46:43 <_zephyris> Changes client-side baseset settings (like grass colour) to savegame/server-set
12:52:05 <michi_cc> peter1138[d]: Is that specific to path signals/reservations though or a general problem?
12:52:27 <peter1138[d]> No, just a general thing.
12:53:09 <michi_cc> Okay, then something akin to the JGR commit will solve some of that, but I'll consider it only somewhat in scope for now.
12:54:04 <peter1138[d]> Yeah, it's only vaguely something to consider when thinking about railtype compatibility.
12:54:43 <peter1138[d]> (Most of that issue is the movement/crashing code, which considers any touch as crashed)
13:08:21 <peter1138[d]> What's this about? 😮
13:26:19 <andythenorth> seems railtype standardised scheme has evolved....back to the future
13:37:49 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:37:50 *** WormnestAndroid has joined #openttd
13:57:12 <peter1138[d]> Looks like someone got in before michi...
14:03:21 <michi_cc> Yes, but it is basically what I'd have done anyway. But do watch out for some more modifications/additions 🙂
14:08:28 *** brickblock19280 has joined #openttd
14:08:28 <brickblock19280> I must have missed that you were meant to fix it sorry about that
14:12:41 <michi_cc> I said I would fix it, that's not the same as "meant to do it" though. If I have to do less, I'm not complaining 😁
14:13:55 <peter1138[d]> I didn't mean it was a problem 🙂
14:14:15 <peter1138[d]> andythenorth: right, so badges to set speed limit? :p
14:14:34 <andythenorth> speed is per vehicles right? 😛
14:14:39 <michi_cc> Quick poll: Should a section "When to use/when not to use" be at the start of the page or at the end? It is supposed to be a spec page, so usually you'd put such stuff into an appendix, but I'm afraid people will just not read that far.
14:14:45 <peter1138[d]> Dare I update VS Code?
14:14:55 <peter1138[d]> Will it try to install the bloody Copilot extension automatically again?
14:15:01 <brickblock19280> I think it's unnecessary since you can query railtype
14:15:40 <michi_cc> andythenorth: You might be interested in the modified axle load section. Subtle detail, but still.
14:16:21 <michi_cc> And yes, speed is per vehicle and set by prop 09.
14:16:39 <peter1138[d]> I'm just refreshing to see what else goes 😉
14:17:06 <michi_cc> A track set that wants to have a separate high speed track should just put a speed limit on the non-high speed track.
14:17:25 <michi_cc> peter1138[d]: Not much, but there will be some additions.
14:19:02 <peter1138[d]> Can we manage 15,000 bytes? Or at least 16,384?
14:19:32 <brickblock19280> Could this be clarified to only apply to tracks, I assume that's the intention?(only when D also used in set)
14:24:09 <michi_cc> brickblock19280: Clarified what exactly?
14:26:01 <brickblock19280> The current spec says that d should be only when D also exists which doesn't make sense for trains as a particular train set may only have trains fit for d but not D
14:26:31 <brickblock19280> It's in the table for specialized electrification types
14:31:25 <michi_cc> That section can definitely use some improvements, but it it is fully intentional that d (and a) should only be used when D (A) are used, too. All different track properties are abstractions, not specific real-world things. Use d implies you have two different kinds of DC electrification, so D is also in use, too.
14:32:59 <michi_cc> Using just d in a train set is not forbidden, but there's a specific note in "Summary for train sets" reagrding that.
14:33:26 <michi_cc> And yes, the Summary sections will be expanded upon.
14:33:51 <brickblock19280> I understand that but it makes it weird when using two train sets:
14:33:51 <brickblock19280> Has low voltage and high voltage uses d and D
14:33:51 <brickblock19280> Has only low voltage uses D
14:33:52 <brickblock19280> Low voltage trains do not use the same tracka
14:35:13 <brickblock19280> michi_cc: True but I think it's best to outline that in the main part since the behavior is different for train and track sets
14:37:30 <andythenorth> I suspect that relying on the semantics of labels which are supposed to be UUIDs will continue to fail
14:37:35 *** Flygon has quit IRC (Read error: Connection reset by peer)
14:37:46 <andythenorth> I've been software engineering for 27 years, and I've never seen it work well yet
14:38:04 <andythenorth> it's a problem in IRL too, with SKUs, machine serial numbers etc
14:38:27 <andythenorth> up to a point, it works fine, then it collapses under overloaded semantics
14:38:44 <andythenorth> then we need properties
14:38:51 <peter1138[d]> My favourite one is my team trying to give everything just one category.
14:38:59 <andythenorth> I often suffer that
14:39:07 <andythenorth> then do you sort by colour?
14:39:11 <brickblock19280> I also think trains should be allowed a list of track types but I assume that needs a grf version bump
14:39:22 <_jgr_> I think that the Java people had the right idea with the IDs just being reverse domain name based
14:39:24 <andythenorth> trains don't need a list of track types
14:39:38 <andythenorth> but newgrf authors stop need to pretending the "fallbacks" are real
14:39:49 <andythenorth> and that is unlikely to happen, so eh
14:40:08 <peter1138[d]> More railtype properties?
14:40:14 <brickblock19280> They do unless we want loads of compatibility railtypes which further creates the need for fallbacks
14:40:31 <andythenorth> fallbacks were only for old railtype grfs
14:40:39 <andythenorth> there have been some...mistakes
14:40:45 <peter1138[d]> Everything is old once it's released.
14:41:04 <michi_cc> What NewGRF authors actually should do is stop using fallbacks for every railtype under the sun. If you allow literally everything to fallback to everything, why have different railtypes at all, because the apparently are meaningless to yoou anyway?
14:42:03 <andythenorth> it's because vehicle authors emotionally need their vehicles to be available in all situations
14:42:26 <peter1138[d]> And also to realism.
14:42:41 <michi_cc> Oh, you'll love one point in the "When to use the scheme and when ''not'' to use the scheme" section that will appear soon 🙂
14:42:47 <andythenorth> and because apparently it's not really acceptable to expect railtype authors to provide compatibility 🙂
14:42:51 <andythenorth> even though that's the spec 🙂
14:43:22 <andythenorth> I am more grumpy about it, because I get all the requests to "make Iron Horse compatible with railtype grf xyz"
14:43:28 <andythenorth> so I'm not my sunniest self
14:46:04 <michi_cc> You may read the new introduction now 🙂
14:46:39 <michi_cc> I'm sure there are more when/when not points to be made, but other people can edit, too.
14:47:25 <andythenorth> I enjoyed the opening
14:47:43 <andythenorth> it would be helpful to aid readers that the first character is **not** exclusively gauge
14:48:16 <andythenorth> and I have a proposal that nobody else has bought into, which is that the second character is effectively private to the railtype 😄
14:48:23 <michi_cc> It's literally called "Track gauge and type class"?
14:48:43 <michi_cc> "The speed limit/appearance class is not used for trains and a train set should always use the class letter A in this position."
14:49:08 <andythenorth> semantically, it's a reserved UUID for the railtype to use as it wishes
14:49:10 <michi_cc> Already in the updated spec.
14:49:17 <andythenorth> and trains should never depend on the meaning of it
14:50:48 <andythenorth> but rack rail blitzes through that
14:50:53 <andythenorth> which I think is mistaken
14:52:45 <peter1138[d]> > If you feel the compulsory need to fill all 64 railtype slots.
14:52:58 <brickblock19280> How do we solve engines that should be powered on two different railtypes which don't power each other?
14:52:58 <brickblock19280> There are a few options I can think of:
14:52:58 <brickblock19280> Train grf defines railtype which is powered on the correct type. SUV does this, it's a support nightmare.
14:52:58 <brickblock19280> Engine can have multiple track types. Requires OpenTTD to change and make responsibility unclear, but does save railtype definitions.
14:52:58 <brickblock19280> Railtype grf defines hidden railtypes which vehicles use. How SETS and xUSSR does it currently, loads of railtypes and fallbacks.
14:53:00 <brickblock19280> New railtype prop similar to alternative but instead not remapping but rather "extending" the lable to function as this one. Same label can be used on multiple railtype definitions. Very messy but clear who is responsible.
14:53:01 <peter1138[d]> So which current track sets are "compliant"?
14:55:14 <brickblock19280> crime against humanity seems excessive
14:56:39 <brickblock19280> Not much point in having reserved speed classes when it's up to the railtype grf to decide
14:58:03 <michi_cc> andythenorth: I know, hence the quote: " but this is generally not standardized, limits interoperability and is only useful for co-developed train and track sets."
14:59:24 <brickblock19280> French ng trains defines trains for R tho
15:00:20 <michi_cc> It shoudn't. If a train only runs on rack rail, it is a different trac type, not an appearance.
15:01:02 <brickblock19280> They run on A but still defined on R so it's not a pure rack system
15:01:16 <michi_cc> andythenorth: I could be convinced to move the table to <newgrf-specs.tt-wiki.net/wiki/Standardized_Railtype_Scheme_extensions> though.
15:01:34 <brickblock19280> I would support that
15:02:20 <peter1138[d]> What happens if a train set wants to the scheme, but there's no railtypes loaded?
15:02:41 <michi_cc> "Define a fallback type via the railtype table in case you want the vehicle to be available on a different track if no matching track set is loaded."
15:02:48 <michi_cc> From "Summary for train sets"
15:03:06 <brickblock19280> A railtype set using the standard may redefine tho so it's not ideal
15:03:28 <brickblock19280> But that's the I always want my trains dilemma again
15:04:33 <michi_cc> Yes, so when not to use: If you consider it a crime against humanity when one of your vehicles or track types is not available in a specific game.
15:05:42 <michi_cc> The whole point of any standard is to allow mixing of different "products". If a NewGRF author doesn't want mixing, there's no point in using a standard.
15:05:43 <brickblock19280> "We don't support this but this is how you do it anyway"
15:09:52 <michi_cc> Well, rack and the example table has been relocated to the extensions page.
15:10:21 <brickblock19280> brickblock19280: Thoughts about this?
15:12:10 <andythenorth> brickblock19280: don't do that?
15:12:39 <andythenorth> in that case the railtype author has decided those trains shouldn't be powered in those cases
15:13:06 *** Wormnest has joined #openttd
15:13:34 <brickblock19280> No the railtype author doesn't want to define the track and the vehicle can't cleanly fallback
15:15:48 <brickblock19280> Train can go on X and Y even if only X or Y is defined ~~you can't do that currently~~
15:16:35 <michi_cc> brickblock19280: By hopefully waiting on a draft PR incoming soon ™️ :
15:16:58 <brickblock19280> Implemented as in alt 2?
15:33:57 <andythenorth> brickblock19280: this isn't a valid case 🙂
15:34:15 <andythenorth> I am aware that It's a real case in Horse, with LGV
15:34:22 <andythenorth> so I might seem split-brained
15:34:36 <andythenorth> but the railtype defines vehicle behaviour
15:35:18 <brickblock19280> I wouldn't have considered this for that IMO the current way horse does it is appropriate
15:35:56 <brickblock19280> more so for SAAZ vehicles since they are really just SAA3 + SAAE
15:43:49 <michi_cc> Okay, editing done for today. If you have comments, please make them. If you find typos, just fix them 🙂
15:50:05 <andythenorth> would we mind if I edited 'track gauge and type' to 'track type and gauge'?
15:50:42 <michi_cc> I wouldn't. Just don't forget to change where it is mentioned later on, too.
15:55:21 *** ialokin has quit IRC (Ping timeout: 480 seconds)
16:01:02 <andythenorth> brickblock19280: explore an angle
16:01:13 <andythenorth> there's nothing to prevent vehicle sets including railtypes
16:02:04 <andythenorth> if the vehicle author wants vehicles compatible with multiple electrification types, then they can include a railtype to manage that
16:03:27 <peter1138[d]> Hmm, do I or do I not?
16:03:36 <andythenorth> except when I don't
16:04:19 <brickblock19280> "The multi-system energy source classes (like e.g. Z or Y) are rarely appropriate for vehicles, as it would mean a vehicle needs both energy sources to be powered." goes against all implementations and what I assume was the intent
16:05:02 <brickblock19280> "Different track gauge and type classes should be neither powered nor compatible with each other." Dual gauge is an exception
16:06:27 <_jgr_> michi_cc: The save attached in the above is broadly the circumstances of the original report I got. It's a user error to use the wrong rail types like this but it still shouldn't result in train crashes.
16:11:06 <michi_cc> brickblock19280: I might have jumped the gun there a bit, as the whole multi-system mess really needs a different solutions (which I hope to make a PR for).
16:11:20 <andythenorth> it's solved trivially by railtypes
16:11:33 <andythenorth> assuming the spec stops fragmenting
16:11:43 <michi_cc> You are that right now this is how you have to do it right now, but I really consider this kludge.
16:11:46 <andythenorth> and with one important caveat, that I can't answer
16:11:47 <brickblock19280> I agree but we can not change the meaning and I doubt such a vehicle exists
16:12:12 <michi_cc> But yes, as it stands right now, it is wrong, so I'll remove it until it isn't anymore.
16:13:40 <andythenorth> I'm puzzled as to the issue 🙂
16:14:02 <andythenorth> it's not elegant, but the vehicle grf just defines a hidden railtype with a private label
16:14:06 <andythenorth> the vehicle uses that label
16:14:25 <andythenorth> the railtype manages compatibility to standard labels, e.g SAAE, SAA3 etc
16:14:35 <andythenorth> the sticking point is the limited grf slots
16:15:10 <brickblock19280> doesn't work since a railtype grf may put the standard labels in alternate and use any label they want to which the vehicle can't anticipate
16:16:03 <andythenorth> I don't understand
16:16:42 <andythenorth> if the vehicle grf makes a vehicle powered on SAAE, and SAA3, then what can possibly go wrong?
16:17:00 <brickblock19280> SAAE doesn't exist it may be called ELRL
16:17:06 <brickblock19280> most likely is
16:17:18 <andythenorth> ok, so the railtype grf is non-conformant with the scheme
16:17:32 <brickblock19280> that is the scheme
16:17:53 <andythenorth> it's meaningless to try and have the scheme enforce the correct behaviour for grfs that don't implement the scheme
16:18:50 <andythenorth> ok if the implication of that is as you imply, then SAAE is a label that should not be used
16:18:52 <andythenorth> and that should be noted
16:19:07 <andythenorth> and SAAN should also not be used
16:19:28 <brickblock19280> SAAE has to exist to adhere ELRL isn't necesarilly A in axle load that's up to the track set
16:20:04 <andythenorth> yeah ok, so for now, I'm just going back to using private labels in Iron Horse
16:20:08 <andythenorth> none of this makes any sense
16:20:09 <brickblock19280> ELRL could also be SACa they are two different schemes which the game forces to interact
16:21:01 <andythenorth> I think we should stop trying to do this
16:32:47 *** D-HUND is now known as debdog
16:35:42 <peter1138[d]> andythenorth: I didn't.
16:35:48 <peter1138[d]> They'll have left by now.
16:36:03 <peter1138[d]> Ah well. "Resting the knee" excuses.
16:36:12 <andythenorth> massage gun battery flat
16:36:39 <peter1138[d]> It didn't seem to help.
16:38:05 <peter1138[d]> ELRL is A in axle load, because it doesn't HAVE an axle load limit.
16:40:41 <peter1138[d]> So yeah, SAAE shouldn't be used because ELRL is what SAAE would be.
16:41:06 <peter1138[d]> andythenorth: You decided even with michi's unfucking it?
16:41:55 <andythenorth> none of the discussions about how to use it make sense
16:42:05 <andythenorth> the scheme is fairly straightforward
16:42:15 <andythenorth> but everyone concludes a different outcome
16:42:19 <peter1138[d]> Just use RAIL and ELRL.
16:42:54 <andythenorth> do you have a newsletter?
16:42:57 <andythenorth> I wish to subscribe
16:43:16 <peter1138[d]> IHA_ isn't RAIL, is it?
16:43:40 <andythenorth> it falls back to RAIL
16:43:49 <andythenorth> and is compatible with RAIL
16:44:10 <andythenorth> or something, I don't know, I keep changing the local version to try and accomodate railtype authors
16:44:20 <peter1138[d]> From my understanding, it seems like you have it backwards.
16:45:38 <talltyler> I’m surprised this wasn’t shown sooner. A good addition. 🙂
16:45:52 <andythenorth> peter1138[d]: entirely possible, I gave up trying to understand any of it several times
16:46:57 <peter1138[d]> Hmm, maybe it's some kind of trying to have multiple "standard RAIL" types?
16:47:56 <andythenorth> for the record, Horse uses IHA_ internally, but it falls back to RAIL in the silly fallback table thing
16:48:04 <andythenorth> which makes no sense, but appears to work
16:48:08 <peter1138[d]> So, from my current understanding, RAIL can't be removed, so you should use it instead of SAAN. ELRL can't be removed, so you should use it instead of SAAE.
16:48:19 <peter1138[d]> IHA_ is your equivalent to RAIL, so... it should just be RAIL.
16:48:36 <peter1138[d]> So the label is actually RAIL, not IHA_
16:48:38 <andythenorth> but I think there's some code somewhere in my compile that string splits on "IH"
16:48:52 <andythenorth> to append the power type
16:48:56 <peter1138[d]> michi_cc: That's what I'm reading from 🙂
16:48:58 <andythenorth> so it was easier to just yolo
16:49:05 <peter1138[d]> If I'm wildly out let me know.
16:49:25 <andythenorth> Iron Horse doesn't conform to the standardised scheme, so it's quite moot what I do 😛
16:49:46 <andythenorth> every time I try to comply I give up 😛
16:50:18 <peter1138[d]> If you use `RAIL` for `IHA_` and `ELRL` for `IHG_`, then... they work?
16:50:36 <peter1138[d]> And if a standardised scheme also replaces RAIl and ELRL, then everything still works.
16:50:44 <andythenorth> there is no problem
16:51:03 <michi_cc> The one thing is that e.g. RAIL isn't necessarily SAAN. The best label to use kinda depends on what the track set supplies. So a track set that actually uses axle loading would probably use SAEN instead for maximum compatibility.
16:52:00 <andythenorth> that, as far as I can determine, is fine
16:52:05 <michi_cc> Or summarised differently: Multi-system (and to some extend multi-gauge) compatibility shouldn't (and can't) be solved by railtype labels alone, but needs some proper support in OTTD.
16:52:12 <michi_cc> PR hopefully comming somewhat soon.
16:52:37 <andythenorth> High Clearance is deleted locally
16:52:44 <peter1138[d]> So `IHA_` and `IHG_` don't exist, because they are RAIL and ELRL
16:53:00 <andythenorth> they could exist, but it seemed pointless, and my compile would need special casing
16:53:08 <peter1138[d]> Seems like that part is correct, so you table that says "primary label" is just confusing me because the primary label is actually RAIL and ELRL 🙂
16:53:35 <andythenorth> the vehicle label is IHA_, but horse contains both vehicles and railtypes
16:53:40 <andythenorth> confusion may arise 😛
16:54:27 <andythenorth> arguably I just switch back RAIL and ELRL for the vehicles, and fix the compile
16:54:31 <peter1138[d]> SUKTS does this... which is wrong.
16:54:51 <andythenorth> which bit is wrong?
16:55:05 <peter1138[d]> Well, RAIL and ELRL are h ... hidden.
16:55:33 <andythenorth> interesting choices for 3RDR and SCA3 also
16:55:47 <andythenorth> possibly looking for UUIDs, taking any they could find
16:55:50 <peter1138[d]> Dual Voltaaaaaaage
16:56:00 <andythenorth> because the scheme doesn't accomodate sleeper colour
16:56:26 <andythenorth> that second character....as private UUID would have solved that
16:56:33 <andythenorth> 'decoration' is mentioned
16:57:26 <andythenorth> oh wait 3RDR is hidden anyway?
16:58:33 <peter1138[d]> Yes. Don't know why it's being added.
16:58:43 <andythenorth> maybe for compatibility with SAA3?
16:59:01 <peter1138[d]> SAA3 isn't defined.
17:01:48 <peter1138[d]> JP+ Tracks seems to handle it better.
17:02:08 <peter1138[d]> Althouhgh universal underground (grass) is a wtf.
17:06:10 <brickblock19280> peter1138[d]: this isn't wrong as ELRL is outside the scheme
17:07:10 <andythenorth> I'd interpreted them as inside the scheme
17:07:20 <andythenorth> perspectives eh? 😛
17:10:13 <peter1138[d]> > But if your track set defines anything that resembles unelectrified or electrified rail, you should use the RAIL and ELRL labels.
17:10:49 <andythenorth> ^ that was my reading
17:10:58 <andythenorth> they're within the scheme
17:11:08 <andythenorth> they just don't conform to the character-position semantics
17:12:03 <brickblock19280> SUKTS has tracks similar to RAIL that being RAIL
17:12:14 <brickblock19280> and others in speed classes
17:12:48 <michi_cc> They are both within and not within at the same time. RAIL and ELRL are not canonical labels in the sense that they obey the naming rules. At the same time, you can't really get rid of them, so for track sets using them ensures maximum compatibilty.
17:14:23 <peter1138[d]> What SUKTS appears to do is redefine RAIL/ELRL, and then hide them anyway. Possibly depending on parameters.
17:14:33 <brickblock19280> it depends on params
17:23:00 <andythenorth> I didn't even have any
17:23:01 <peter1138[d]> Although I only had 1 slice, so that's fair.
17:23:54 <andythenorth> railtypes have no other UUID than label?
17:24:54 <andythenorth> all those labels just for different ballast
17:25:31 <michi_cc> There are 4 billion labels, I think that is enough for ballast 🙂
17:25:53 <peter1138[d]> But they have to use only letters and numbers 😉
17:26:16 <peter1138[d]> Only 14 million labels after all.
17:27:40 <LordAro> 14 million labels ought to be enough for anyone
17:27:51 <peter1138[d]> Badges have no such limitations.
17:27:55 <brickblock19280> peter1138[d]: are you sure?
17:28:26 <brickblock19280> I've used *, $, (, ) , [, ] and =
17:28:35 <peter1138[d]> brickblock19280: It was my humour. Any byte is valid, but nearly everyone uses letters and numbers.
17:28:52 <peter1138[d]> Same with station classes
17:28:57 <brickblock19280> nml doesn any byte tho
17:29:17 <brickblock19280> since code is shared with lang strings so ~ is baned
17:37:58 <michi_cc> Doesn't nml support \ escapes for raw hex values?
17:38:17 <brickblock19280> I remember it still not working
17:39:43 <andythenorth> I don't think label exhaustion is a pressing issue 😄
18:23:04 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:25:16 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:38:05 *** WormnestAndroid has joined #openttd
19:06:36 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:08:00 *** WormnestAndroid has joined #openttd
19:15:49 <xarick> I'm playing the forbidden game
19:44:41 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:47:55 *** WormnestAndroid has joined #openttd
19:57:15 <pickpacket> xarick: Oblivion Remastered?
20:00:09 <peter1138[d]> Leisure Suit Larry?
20:32:26 <wensimehrp> Maitetsu: Last Run!
20:32:38 *** gelignite has joined #openttd
20:57:26 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:01:17 *** WormnestAndroid has joined #openttd
21:21:47 <peter1138[d]> Can you tell what's wrong with these?
21:26:38 <LordAro> also they don't look aligned with the text
21:31:29 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:48:14 <peter1138[d]> So the magic is the embedded squirrel function to do the valuate, neat.
21:48:35 <peter1138[d]> I can't approve it already ;p
21:49:54 <_zephyris> peter1138[d]: How do you feel about a black drop shadow, to match the text?
21:50:24 <peter1138[d]> Well. Funnily the issue here is there is a drop shadow. It's just not black.
21:53:48 <peter1138[d]> Also, not really keen.
21:59:57 <peter1138[d]> Basically, unlike text, the icons are not "flat", so adding a shadow is just weird.
21:59:58 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:00:18 *** WormnestAndroid has joined #openttd
22:01:31 *** tokai|noir has joined #openttd
22:01:31 *** ChanServ sets mode: +v tokai|noir
22:08:19 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:08:24 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:10:44 *** WormnestAndroid has joined #openttd
22:25:44 <peter1138[d]> Hmm, classes with virtual functions, or... variant with visitor...
22:26:41 <wensimehrp> peter1138[d]: Makes sense for me
22:34:48 <peter1138[d]> Hmm, embeddable vehicle icons? 😮
22:35:16 <peter1138[d]> (They're too big)
22:41:57 *** belajalilija has joined #openttd
22:41:57 <belajalilija> peter1138[d]: One of them has blue hair and that may be not historically accurate in some eras
22:46:14 <peter1138[d]> That's a hat, you know...
22:46:16 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:46:29 *** WormnestAndroid has joined #openttd
22:47:49 <peter1138[d]> Variant works. Less extensible but also less code.
22:54:02 <belajalilija> peter1138[d]: Well a bright blue hat is hardly the fashion of the late Victorian era is it? :kek:
23:17:31 <peter1138[d]> _glx_: well, it doesn't take long for AAAHogEx to be killed for exccessive CPU usage in valuator function.
23:52:01 <_glx_> hmm that should happen only if iterating a single item takes more than the allowed ops
continue to next day ⏵
