IRC logs for #openttd on OFTC at 2024-05-19
⏴ go to previous day
00:16:17 <yeah_its_gloria> how funny am I allowed to be with limitations
00:30:43 <wensimehrp> Controller support? 😛
00:33:50 <yeah_its_gloria> Game Mode just makes them frames faster (apparently)
00:33:59 <yeah_its_gloria> I assume it just pauses some stuff like iCloud sync or whatevs in the background
00:34:42 <klote> train pathfinding broken?
00:57:04 <yeah_its_gloria> I had a feeling I made a mistake
00:59:41 <wensimehrp> What is wrong with github teams?
01:04:40 <_glx_> what do you think is wrong ?
01:26:10 <wensimehrp> Every one is a child team member
01:28:31 *** gelignite is now known as Guest6946
01:28:34 *** gelignite has joined #openttd
01:35:51 *** Guest6946 has quit IRC (Ping timeout: 480 seconds)
01:59:28 <_glx_> there's no member in translators team, they are only in child teams
02:02:32 <wensimehrp> wait I thought it's saying that everyone is a *child* member, but not a *child team* member
02:06:45 *** Wormnest has quit IRC (Quit: Leaving)
02:45:00 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:23:18 *** gelignite has quit IRC (Quit: Stay safe!)
04:40:27 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
04:43:22 <DorpsGek> - Update: Translations from eints (by translators)
04:58:07 *** HerzogDeXtEr has joined #openttd
05:59:37 <andythenorth> grf 'parameters' could just be settings maybe?
06:01:39 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
06:32:10 *** SigHunter has joined #openttd
06:43:51 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
06:44:34 *** SigHunter has joined #openttd
06:59:10 *** SigHunter has quit IRC (Remote host closed the connection)
07:00:12 *** SigHunter has joined #openttd
07:09:51 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
07:12:13 *** ChanServ sets mode: +v tokai
07:51:22 *** SigHunter has joined #openttd
08:16:56 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
08:24:45 <truebrain> I like how this keeps being delayed 🙂
09:31:04 *** gelignite has joined #openttd
09:34:29 *** XYZ_ has quit IRC (Ping timeout: 480 seconds)
09:40:44 *** SigHunter has joined #openttd
10:31:13 *** squirejames has quit IRC (Quit: User went offline on Discord a while ago)
10:34:26 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
10:36:13 *** SigHunter has joined #openttd
11:01:47 <andythenorth> so FIRS needs updated to work with Wallclock
11:01:52 <andythenorth> not sure what that entails though
11:02:01 <andythenorth> 'every three months' is no longer accurate
11:09:39 *** gelignite has quit IRC (Quit: Stay safe!)
11:12:51 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
11:23:33 *** SigHunter has joined #openttd
11:49:12 <talltyler> It would be “every three minutes” but industry cargo scaling affects the callback frequency, which I believe FIRS uses instead of actually checking the date
11:49:51 <talltyler> We could add a global GRF variable for “game is in wallclock mode” but that wouldn’t communicate the cargo scaling
11:51:34 <andythenorth> if FIRS should just delete supplies
11:51:54 <andythenorth> and rewrite the secondary production algorithm
11:52:26 <talltyler> The other supplies method is to use a stockpile, like in PIRS
11:52:36 <andythenorth> yes I was thinking the same
11:53:58 <talltyler> It is “easier” because you don’t have to deliver frequently, although you could have the industry consume a fraction of the waiting supplies instead of a fixed amount, to incentivize keeping a smaller stockpile. Renewed Village Growth GS does this.
11:54:30 <andythenorth> on the other hand if vehicle running costs, payments, servicing, town loop, etc all work
11:54:47 <andythenorth> then current FIRS mechanic should be capable of being refactored
11:56:13 <talltyler> Not sure exactly what you mean but the ratio of supplies to produced cargo is still the same, just faster or slower depending on the chosen industry cargo scale.
11:56:31 <talltyler> The issue is mostly UI
11:57:00 <andythenorth> supplies calculation is just a loop on a certain periodicity
11:57:16 <peter1138> What problem are we working around today?
11:57:26 <andythenorth> not working around...yet
11:57:32 <andythenorth> this is more 'what should it do'
11:58:44 <andythenorth> so do we assume the existing behaviour continues as is if game is not in wallclock mode?
11:58:52 <andythenorth> and why did we keep not-wallclock-mode?
11:59:08 <talltyler> When I opened the cargo scaling PR there was some discussion of exposing it to GRF for UI purposes, but we determined that making it a global variable was just asking for GRF authors to try to override it
11:59:22 <talltyler> andythenorth: We did, calendar mode is still there and unchanged 🙂
11:59:40 <andythenorth> what was the rationale for keeping it?
11:59:53 <talltyler> Pitchforks, of course
12:00:19 <talltyler> Oh, you didn’t write “not” 🙂
12:00:59 <andythenorth> we couldn't just do '12 minutes = old calendar mode'? 🙂
12:01:11 <talltyler> I originally wrote a wallclock-only PR and proved that pitchforks were ready to strike, got a great Zorg comment about it 😄
12:01:47 <talltyler> It’s fine, I am happy to not have to fight any battles.
12:01:58 <andythenorth> what does cargo scaling do?
12:02:08 <andythenorth> I have PR 10606 open
12:02:11 <talltyler> Wallclock mode being completely new meant I could introduce whatever limitations I wanted without anyone complaining 🙂
12:02:27 <peter1138> For UI purposes, provide a string code that automatically handles wall lock or not more?
12:03:03 <andythenorth> peter1138: might be a good route
12:03:15 <peter1138> {num} {economy periods}
12:03:37 <peter1138> Wow, autocorrect fails
12:03:38 <andythenorth> how many 256 tick callbacks per economy period?
12:06:36 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
12:10:22 <andythenorth> FIRS '3 months' is actually counting 256 tick callbacks
12:10:28 <andythenorth> think it counts 27
12:10:52 <andythenorth> and allows that might give the player longer than 3 months, due to 8 or 9 of those callbacks per calendar month
12:12:52 <andythenorth> string code where I tell OpenTTD how many 256 callback cycles, and it gives me back something useful for the player? 😛
12:14:15 <talltyler> I am hesitant to design something quite so specific
12:14:48 <talltyler> But the risk is that a generalized solution not limited to UI would be a footgun
12:15:14 <talltyler> I absolutely want it to work for FIRS, of course 🙂
12:15:32 <talltyler> You should not need to redesign features unless you really want to
12:15:53 <talltyler> I am at the airport about to go through security, will think on this further 🙂
12:15:56 <andythenorth> I think the FIRS code is portable 🙂
12:17:53 <_glx_> andythenorth: scripts don't support it
12:47:14 <andythenorth> cargo label for "Seals, Hoses and Belts"? 😛
12:47:25 <andythenorth> SEAL, HOSE or BELT?
13:08:07 <talltyler> Scaling a time interval would display strange intervals — what if production scaling is 110%, so FIRS periods are 3.3 minutes?
13:08:07 <talltyler> We could create a string code that takes a cargo name and an amount and displays “[cargo name] [units] per [month or minute]”. This would handle stockpiling industries but not FIRS.
13:08:07 <talltyler> We could also expose the settings (and/or the number of ticks per production callback call) directly to GRFs and let them do their own math, but this feels like a footgun if they could also use it for production math.
13:10:14 <talltyler> I’m hoping someone has a fourth option I haven’t thought of 🙂
13:16:20 <andythenorth> we can completely freeze calendar date?
13:16:29 <andythenorth> so we can't project forward to get a 'deliver by' date?
13:16:49 <peter1138> Deliver within 10 minutes
13:17:29 <peter1138> But the game displays that...
13:19:59 <ahyangyi> andythenorth: Seals...? 🦭
13:34:20 *** andythenorth[m] has joined #openttd
13:34:30 *** calbasi[m]1 has joined #openttd
13:34:40 *** audunm[m] has joined #openttd
13:34:50 *** Bilb[m] has joined #openttd
13:35:00 *** blikjeham[m] has joined #openttd
13:35:10 *** citronbleuv[m] has joined #openttd
13:35:20 *** cjmonagle[m] has joined #openttd
13:35:30 *** CornsMcGowan[m] has joined #openttd
13:35:40 *** einar[m] has joined #openttd
13:35:49 *** elliot[m] has joined #openttd
13:36:00 *** emilyd[m] has joined #openttd
13:36:10 *** FelixActually[m] has joined #openttd
13:36:19 *** fiddeldibu[m] has joined #openttd
13:36:39 *** freu[m] has joined #openttd
13:36:50 *** giords[m] has joined #openttd
13:36:59 *** grag[m] has joined #openttd
13:37:10 *** gretel[m] has joined #openttd
13:37:20 *** hamstonkid[m] has joined #openttd
13:37:30 *** Heiki[m] has joined #openttd
13:37:40 *** pikaHeiki has joined #openttd
13:37:49 *** igor[m] has joined #openttd
13:37:59 *** imlostlmao[m] has joined #openttd
13:38:09 *** jact[m] has joined #openttd
13:38:19 *** jeeg[m] has joined #openttd
13:38:31 *** jeremy[m] has joined #openttd
13:38:40 *** joey[m] has joined #openttd
13:38:49 *** karl[m]123 has joined #openttd
13:38:59 *** karoline[m] has joined #openttd
13:39:10 *** kstar892[m] has joined #openttd
13:39:20 *** leward[m] has joined #openttd
13:39:29 *** luffy[m] has joined #openttd
13:39:40 *** luk3Z[m] has joined #openttd
13:39:50 *** magdalena[m] has joined #openttd
13:39:59 *** menelaos[m] has joined #openttd
13:40:09 *** nolep[m] has joined #openttd
13:40:20 *** osvaldo[m] has joined #openttd
13:40:29 *** patricia[m]12 has joined #openttd
13:40:40 *** patrick[m]1 has joined #openttd
13:40:49 *** paulus[m] has joined #openttd
13:41:00 *** phil[m]123 has joined #openttd
13:41:10 *** philip[m] has joined #openttd
13:41:19 *** playback2396[m] has joined #openttd
13:41:29 *** royills[m] has joined #openttd
13:41:40 *** Rdolfs[m] has joined #openttd
13:41:50 *** shedidthedog[m] has joined #openttd
13:42:01 *** Farrokh[m] has joined #openttd
13:42:10 *** soylent_cow[m] has joined #openttd
13:42:19 *** throwawayaccount[m] has joined #openttd
13:42:30 *** temeo[m] has joined #openttd
13:42:40 *** thelonelyellipsis[m] has joined #openttd
13:42:49 *** thomas[m]12345678 has joined #openttd
13:43:00 *** tonyfinn has joined #openttd
13:43:10 *** Gadg8eer[m] has joined #openttd
13:43:29 *** JamesRoss[m] has joined #openttd
13:43:41 *** VincentKadar[m]1 has joined #openttd
13:43:50 *** Elysianthekitsunesheher[m] has joined #openttd
13:43:59 *** wormnest[m] has joined #openttd
13:44:11 *** xyii[m] has joined #openttd
13:44:19 *** Guest6982 has joined #openttd
13:44:29 *** yubvin[m] has joined #openttd
13:44:40 *** zzy2357[m] has joined #openttd
14:18:34 *** SigHunter has joined #openttd
14:46:45 *** Wormnest has joined #openttd
16:09:59 <andythenorth> is option 4 "delete FIRS supplies"?
16:10:06 <andythenorth> and the secondary processing
16:12:43 <emperorjake> Delete the thing that's been one of the defining features of FIRS since 0.1? Nah
16:13:55 <talltyler> Option 4 could be for FIRS to check the economy date instead of counting production ticks, and always require delivery every 3 minutes
16:14:12 <talltyler> 1 economy month = 1 minute
16:14:46 <talltyler> We can add a global variable for if the game is in wallclock mode so you can use the right string
16:15:15 <talltyler> Because even in calendar timekeeping mode, economy scaling will make the current “every 3 months” wrong
16:16:13 <talltyler> I forget if I added GRF variables to get the economy date yet
16:17:38 <andythenorth> "Supplied: [days remaining]"
16:17:52 <andythenorth> difficulty is we can't refer to any date concepts
16:17:58 <andythenorth> no months, weeks, days, or dates
16:18:08 <andythenorth> and how long is a period?
16:18:12 <talltyler> Yes, timetables have a similar problem and are now relative
16:18:31 <talltyler> 1 period = 12 minutes = what everybody thinks of as one year 🙂
16:18:57 <andythenorth> oof I have to unsee the timetable window
16:18:59 <talltyler> I hope everyone is enjoying the omelet I made 😄
16:19:17 <andythenorth> I mean...how does the timetable change the vehicle speeds?
16:19:22 <andythenorth> makes no sense at all
16:19:39 <talltyler> It does not, but start date and arrival and departure dates don’t mean anything if time is frozen
16:20:05 <talltyler> So it shows it in seconds, in the future (or in the past if the vehicle is late)
16:20:37 <talltyler> Time to get off my plane, will check back in a few hours perhaps
16:20:50 <talltyler> I will do my best to fix the mess I’ve created 😄
16:22:50 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
16:49:22 <peter1138> Less options are better.
16:50:24 <peter1138> Making the game format things appropriately is better than letting the NewGRF try to.
16:53:29 <andythenorth> I see this as akin to unit conversion
16:53:41 <andythenorth> trying to handle it in grf will just lead to a lot of requests for vars
16:53:55 <andythenorth> "deliver supplies in 7 knots"
17:01:30 <audigex> Perhaps spritesets for trains can provide two spritesets (like loaded: and loading: spritegroups currently in NMl), one standard (mandatory) and one reciprocal (optional)
17:01:30 <audigex> If the consist allows pushpull (unit at each end flagged for driving?) then the consist is reversed automatically using the reciprocal spriteset if available?
17:02:14 <audigex> … that was meant to be a reply to a pushpull conversation, either I’ve gotten the wrong channel or my discord didn’t update properly
17:04:38 <ahyangyi> didn't you write "remove industrial non-track tiles, just use objects instead"
17:23:47 <peter1138> push-pull does not need extra sprites
17:35:29 <audigex> peter1138: It does for assymetric driving trailers (almost all only have a cab at one end) or locomotives (UK Class 91)
17:35:29 <audigex> I guess if you don't have headlights on the sprites it could just flip the first 4 and last 4 views, but a Class 91 and Mk4 DVT needs more than 8 sprites each with headlights
17:36:54 <audigex> You also need extra sprites if you have assymetric liveries
17:37:29 <peter1138> Yuo can handle all that just with the flipped state that already exists.
17:37:44 <peter1138> No need to complicate things by extending loading/loaded.
17:38:32 <audigex> I'm not saying to extend loading/loaded, to be clear, just that it seems an easy way to define normal and reversed sprites in a single spritegroup
17:39:00 *** toomuchtoby has quit IRC (Quit: User went offline on Discord a while ago)
17:44:29 *** SigHunter_ has joined #openttd
17:44:46 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
17:51:20 <peter1138> vehicle_is_reversed probably?
17:52:43 <audigex> The discussion (in another channel, I hit the wrong one by the looks of it) was about the concept of automatically reversing consists in the game natively rather than newGRFs bodging it together
17:53:52 <audigex> So my suggestion was that for each item we could provide a spritegroup (normal and reversed) and then the game would automatically constitute them into the right order
17:55:21 <peter1138> And my point is, if the game does handle push/pull natively, then you would use that flag to determine if you need to provide a cab with head lights or tail lights.
17:55:32 <andythenorth> aren't the lights in a layer anyway? 😛
17:55:39 <andythenorth> sorry, *grenade*
17:55:54 <peter1138> You still need to pick the correct layer if it is.
17:56:45 <peter1138> There are already 8 directions, for push/pull the game would have to automatically use the "wrong" direction.
17:57:01 <peter1138> That does not need extra sprites, they already exist.
18:06:56 <audigex> You're assuming the driving vehicle on each end is identical, though?
18:08:11 <audigex> If the driving vehicle is assymetric you can't just use the other direction out of the 8
18:08:45 <peter1138> That's why you use the reversed flag.
18:09:23 <audigex> How would you handle this without another sprite?
18:09:58 <peter1138> of course you need a more sprites if you want it too look different when reversed.
18:10:07 <peter1138> But the mechanism for that already exists.
18:12:05 <audigex> That's my point, though?
18:12:05 <audigex> It would be nice if I could draw two spritesets (one forward, one reversed) and then provide them together to OpenTTD in one SpriteGroup, and then OpenTTD automatically just uses the reversed one when the train is going the other direction
18:12:05 <audigex> Rather than having to bodge it in NML, the game would automatically reverse the consist, using the "reversed" sprite in the spritegroup for that vehicle (if available), otherwise just using the normal sprite (which would work fine for eg most coaches and MU middle cars)
18:12:40 <peter1138> Selecting the sprite based on flags is not a bodge.
18:13:24 <audigex> It is in combination with the other nonsense we have to do to make pushpull work
18:13:48 <audigex> And in any case, wouldn't it just basically be shorthand for a vehicle_is_reversed switch? Nothing wrong with simplifying things where it makes sense to do so
18:14:16 <peter1138> Sure but you're talking about removing that, here.
18:14:33 <peter1138> Plenty wrong with special-casing just that flag.
18:15:15 <audigex> For 99% of vehicles `default:` would now either just provide one 8-view spriteset, or a spritegroup containing 2x 8-view spritesets
18:15:15 <audigex> Yes it's "special casing", but it's literally the standard thing we do with almost every single vehicle? Why not streamline it when it's by far the most common use case
18:15:47 <audigex> I mean, we do it with `loading` and `loaded` already? Those could both be done with switches too
18:16:45 <audigex> Why are we special-casing `cargo-count` but not `vehicle_is_reversed`?
18:17:28 <brickblock19280> you don't need anything for push-pull as it will just use the sprites for the other direction
18:17:41 <audigex> brickblock19280: As above... good luck if your unit or livery is assymetric
18:18:01 <peter1138> loading/loaded works regardless of the actual capacity.
18:18:02 <brickblock19280> there are 8 sprites in a sprite set for that reason
18:18:19 <peter1138> And of course it's a very old feature.
18:18:29 <brickblock19280> this is the case regardless of push pull
18:19:01 <peter1138> Reversed can be done with the existing flag, and isn't needed in all cases. No need to complicate things.
18:19:29 <audigex> brickblock19280: Sure, you still need 16 sprites
18:19:29 <audigex> I'm just saying it would be nice to have a simpler way to construct that
18:19:40 <audigex> peter1138: It's not complicating, it's simplifying?
18:20:15 <brickblock19280> fair enough but one switch isn't to bad adding it to NMLC might be worth it but not to the spec
18:20:34 <peter1138> It's complicating it because you're adding new syntax, both to NML and NFO spec, that is only relevant to trains.
18:20:51 <brickblock19280> adding more ways of doing something makes it more complicated in ways
18:20:52 <peter1138> Or just you just test the existing flag that exists and doesn't need new syntax.
18:21:22 <peter1138> (And only relevant to *some* rail vehicles)
18:22:15 <andythenorth> What is push-pull? Is it a grf thingnor an OpenTTD thing?
18:22:36 <peter1138> It's the whole "don't reverse my consist when it gets reversed" thing.
18:23:09 <andythenorth> What’s the spec?
18:23:33 <brickblock19280> As I see it you just need a has cab flag / allows push-pull and a new vehicle is reversed variable in order to not introduce weird behaviour into current grfs which do grf side push-pull.
18:24:45 <audigex> That's probably what it comes down to: if the responsibility for reversing the vehicle and units is handed off to OpenTTD rather than the GRF, then I'm of the opinion that it should *all* be handed off to OpenTTD
18:24:45 <audigex> If OpenTTD itself is doing the push-pull, then logically the GRF developer should just say "here's the normal spriteset and reversed spriteset, do your thing"
18:24:45 <audigex> What peter is suggesting is that OpenTTD does some of it but the GRF still has to do some too, which is a weird division of responsibility
18:25:33 <andythenorth> What does the grf have to do?
18:26:35 <audigex> In Peter's proposal the GRF is still responsible for checking if the vehicle is reversed and swapping the sprite, while OpenTTD reverses the consist order
18:26:35 <audigex> In my proposal the GRF just provides either 1 (normal) spriteset or 2 (normal and reversed) spritesets and OpenTTD takes it from there however it wants to handle things
18:27:01 <brickblock19280> that is openttd
18:27:17 <brickblock19280> only thing that will be wrong is lights
18:27:18 <audigex> Right.... I thought we were having a discussion about improving OpenTTD?
18:27:34 <andythenorth> Why are the lights wrong?
18:27:51 <audigex> I'm saying "here's how to improve it" and being met by "that's just how it is"
18:28:13 <brickblock19280> the vehicle has red lights at the back but it is flipped and the grf doesn't check and shows red lights at front instead of yellow ones
18:28:19 <brickblock19280> it really isn't a big deal
18:28:23 <audigex> andythenorth: Andy, Class 91 is the obvious example
18:28:27 <audigex> It's not just about lights
18:28:53 <brickblock19280> the only differance between the left and right there is the lights
18:29:30 <andythenorth> Ok so lights, and what else? 🙂
18:29:57 <brickblock19280> no those will work just like now
18:30:35 <andythenorth> The train isn’t repainted when it reverses 🙂
18:30:57 <audigex> Aight I guess that comes back to the lights
18:31:11 <andythenorth> Lights are a non-issue
18:31:27 <audigex> Tell that to the thousands of sprites in my set with lights drawn onto the sprite...
18:31:30 <andythenorth> Which vehicle in the consist needs red lights?
18:31:49 <andythenorth> (Not a trick question)
18:32:18 <brickblock19280> the one that is travelling at the back (generally)
18:32:32 <andythenorth> And we have a var for that
18:32:53 <brickblock19280> we have two already but neither can be used
18:32:59 <brickblock19280> so we need one more
18:33:11 <andythenorth> Why can’t they be used?
18:33:52 <brickblock19280> one would make the old ironhorse flip for livery thing break and the other would break grf side push-pull
18:34:14 <andythenorth> But we slready have position in consist var
18:34:42 <audigex> At which point the GRF is doing all the work anyway, so why are we bothering handing it off to OpenTTD to do it properly?
18:34:49 <audigex> We may as well just carry on bodging it
18:35:18 <andythenorth> We want a magic way for OpenTTD to do tail lights,? 🙂
18:35:22 <brickblock19280> andythenorth: true but there could be cases where the lights show if you have two cab cars with lights but both sets are visible
18:36:01 <andythenorth> Write a spec for tail lights maybe?
18:36:21 <andythenorth> I just check if vehicle is rear of consist, but eh
18:36:33 <audigex> The context here is "Push-pull is currently a bodge we hack into GRFs, it would be good if OpenTTD did push-pull properly and automatically"
18:36:33 <audigex> Followed by "And if OpenTTD is reversing the consist, it would make sense for the GRF author to be able to hand off sprite-reversing too, by providing normal and (optional) reversed sprites rather than fiddling around with switches), rather than half the responsibility remaining with the GRF"
18:36:56 <andythenorth> Still don’t understand
18:37:18 <andythenorth> The point of push pull is to *not* reverse the sprites 🙂
18:37:33 <andythenorth> Isn’t that the actual feature players want?
18:38:29 <audigex> Essentially my proposal is that the GRF stops doing push-pull AT ALL, except that an 8-view spriteset can be provided with a second 8-view spriteset which is the reciprocal where the unit is assymetric
18:38:29 <audigex> If only one spriteset is provided, then the reciprocal view is used automatically as you'd expect
18:38:29 <audigex> If a second is provided, then the reciprocal is pulled from the second spriteset instead because the unit is assymetric
18:38:42 <audigex> Again, I'll refer you to the Class 91 16-views above
18:39:14 <andythenorth> I think your asking for a tail light spec maybe?
18:39:17 <audigex> Currently the GRF does that work with a switch using `vehicle_is_reversed`, I'm saying that if the responsibility for push-pull is handed off to OpenTTD, it makes sense to hand of ALL that responsibility
18:39:35 <audigex> andythenorth: Not a fucking chance unless you're volunteering to convert BRTrains to use it...
18:39:59 <andythenorth> Ok we maybe have crossed wires 🙂
18:40:05 <audigex> Joking aside: I agree it would be a positive thing in general to have a way to define lights. But it doesn't resolve the issue for existing sets
18:40:23 <ahyangyi> Excuse me, but I don't see how asymmetric the provided 16 views are
18:40:30 <ahyangyi> besides the tail lights
18:41:07 <andythenorth> If we want different sprites, use a varact2 chain 🙂
18:41:21 <andythenorth> I think peter might disagree about that though?
18:41:29 <audigex> audigex: Yeah when you start talking varact and action0 etc you just completely lose me, and I think the majority of GRF developers along with me...
18:41:46 <audigex> There's a reason we all use NML and avoid the rest as much as possible
18:41:57 <andythenorth> I get that but the spec is the spec
18:41:58 <ahyangyi> the nml term is "switch"
18:42:21 <andythenorth> OpenTTD has to do what it does
18:42:38 <brickblock19280> I think it makes for openttd to do it and I would prefer that but given Newgrfs have to do it currently for flipped so having them do it for a new one would be the most consistent. Letting NML do it automatically might however be worth it but Openttd doing it doesn't make sense when it is just a switch
18:43:09 <brickblock19280> I'll send a pic of current behaviour
18:43:43 <audigex> Either way my point comes down to: If it's OpenTTD's responsibility then make it ALL be OpenTTD's responsibility, the GRF defines the vehicle and sprites and OpenTTD decides what it wants to do with them. That's the sensible division of responsibility, rather than leaving half with GRFs
18:43:43 <audigex> If we can use `loading` and `loaded` rather than the GRF using `cargo_count` in a switch, I don't see why we can't use `normal` and `reversed` instead of using `vehicle_is_reversed`?
18:44:11 <andythenorth> How will OpenTTD know what you intend?
18:44:16 <ahyangyi> I think it makes sense that OpenTTD automatically flip the wagons. I just don't understand that 16 view example.
18:44:17 <peter1138> `loading` and `loaded` are part of the action 2 spec.
18:44:40 <andythenorth> it’s not trivially extensible
18:44:45 <audigex> andythenorth: How does it know what I intend with `loading`?
18:44:59 <peter1138> I knows because it's the spec.
18:45:15 <andythenorth> what does ‘reversed’ mean?
18:45:19 <audigex> If this comes down to "it's difficult and we'd have to change the spec, and we just don't want to do that much work" then fine, but conceptually I don't think the argument against what I'm saying has logical merit
18:45:27 <brickblock19280> both of these are heading the same way but the grey should be yellow but there isn't the light switch making it grey instead
18:45:53 <audigex> andythenorth: What does "loading" mean? They're all just words. Use whatever word you mean
18:46:06 <brickblock19280> I don't think we should change the spec when making the compiler change is easier and gives the same result to you the end user
18:46:16 <andythenorth> Loading is algorithmic, driven by load amount
18:46:25 <ahyangyi> brickblock19280: Thanks for the example, I think I understand it now.
18:46:49 <audigex> brickblock19280: That's fine by me too, if we want to make NML accept the syntax I propose and then reconstitute it into a switch, no problem
18:46:54 <andythenorth> Is reversed: flipped, push pull reversed, reversed at station, reversed when built?
18:47:11 <peter1138> What's the point though? How is it clearer than a switch that selects the two states?
18:47:39 <brickblock19280> personal preference at which point one could fork NML
18:47:44 <audigex> peter1138: Again, how is `loading` and `loaded` clearer than a switch selecting the states using `cargo_count`
18:47:59 <peter1138> Adding new syntax for something that can already be done does not simplify things.
18:48:06 <brickblock19280> they don't behave the same and that is very old syntac
18:48:07 <peter1138> loading and loaded are not implemented as a switch.
18:48:13 <andythenorth> And loaded/loading is worse than a switch
18:49:17 <peter1138> It is the correct thing to use.
18:49:37 <audigex> I think we're getting bogged down in the technicality
18:49:37 <audigex> My point is simple "IF OpenTTD takes over responsibility for reversing the consist and sprites for push-pull, it should take over all the responsibility including allowing a second spriteset to be provided where sensible"
18:49:37 <audigex> I couldn't care less if NML does it, OpenTTD does it, or something else does it... conceptually, it makes sense at that point for the GRF author to just provide either 1 or 2 spritesets and not think about it
18:49:59 <audigex> The detail isn't the point: put the logic wherever. I'm talking about the concept and logical consistency
18:50:03 <peter1138> Okay, well you can patch NML to do it I guess.
18:50:14 <peter1138> But it's entirely unnecessary.
18:50:35 <peter1138> Build it into your templates or something.
18:51:37 <audigex> It's unnecessary for you, but just because something doesn't make sense to you, it can still have a benefit for others
18:51:51 <audigex> Plus it makes things more accessible for new newGRF authors which is always a good thing IMO
18:51:58 <andythenorth> The spec tends to do badly with this kind of addition
18:52:16 <ahyangyi> Perhaps there should be some semi-official NML template collections
18:52:33 <ahyangyi> Considering how hard it is to use NML without some templating preprocessor
18:52:35 <andythenorth> what’s the combinatorial requirement?
18:52:53 <peter1138> "doesn't make sense"... oh, I understand what you mean. But implementing another way to do the same thing does not make sense.
18:52:54 <ahyangyi> semi-official in the sense of "official recommendation", not "official maintenance"
18:53:31 <andythenorth> We now need loading_reversed, loading_unreversed, loaded_reversed, loaded_unreversed
18:53:48 <andythenorth> But reversed has to be optional
18:54:42 <andythenorth> But trains action2 has fixed bytes for loaded/loading
18:55:06 <ahyangyi> I don't think they are asking for changing the newgrf spec at this point
18:55:16 <brickblock19280> it might be more code without the switch then
18:55:26 <ahyangyi> they just want it *somewhere in the tech stack*
18:55:42 <ahyangyi> and I think the obvious place is just a... pnml macro
18:55:57 <andythenorth> Now I have to leave
18:56:13 <andythenorth> Pnml is a plague
18:56:26 <andythenorth> Massive boat anchor
18:56:27 <ahyangyi> I agree but that's because I understand Python.
18:57:07 <andythenorth> pnml is significantly harder than python
18:57:38 <andythenorth> The reason it’s survived is that python is ~impossible for most people to install
18:57:47 <audigex> ahyangyi: This please. I literally don't care where it goes
18:57:56 <brickblock19280> I find pnml harder
18:58:04 <brickblock19280> do it in your pnml then
18:58:30 <audigex> brickblock19280: To be clear: I literally don't care where it goes *outside of the GRF*
18:58:45 <brickblock19280> that is outside the grf tho
18:58:49 <brickblock19280> it is pre nml
18:59:00 <audigex> You're just being facetious now
18:59:11 <brickblock19280> no different from in nml in code use tbh
19:00:06 <audigex> You know what I mean: outside of the *scope* of the GRF. The GRF author just optionally provides a second spriteset attached to any spriteset they provide, which gives reciprocal views when needed
19:00:27 <brickblock19280> `switch(FEAT_TRAINS, PARENT, name, vehicle_is_flipped) {
19:00:27 <brickblock19280> spritegroup (sg_yes) {
19:00:31 <brickblock19280> spritegroup (sg_yes) {
19:00:35 <brickblock19280> spritegroup (sg_all) {
19:00:35 <andythenorth> Seems a strange way to get tail lights 🙂
19:00:37 <brickblock19280> reversed_loaded:
19:00:39 <brickblock19280> reversed_loading:
19:00:41 <brickblock19280> it would be smaller tbf
19:00:59 <andythenorth> Serious suggestion: can we teach a GPT to generate grf?
19:01:11 <andythenorth> Default GPT can’t
19:01:40 <ahyangyi> Default GPT told me many imaginary functions when I asked it about "OpenTTD callbacks" 😛
19:01:55 <audigex> I like how we've all tried
19:01:59 <andythenorth> It’s phenomenal at python
19:02:11 <andythenorth> But it probably read the docs
19:02:19 <ahyangyi> Admittedly I mostly just poke GPT for fun
19:02:20 <brickblock19280> maybe it can write grf-py
19:02:39 <brickblock19280> there is truly a lot of documentation to read
19:05:25 <andythenorth> What does train var 40 mean in the new push pull spec?
19:06:10 <audigex> What does it mean in the current spec? 😅
19:07:14 <andythenorth> Position in consist (amongst other things)
19:08:32 <audigex> I presume you mean "is it from the front of the train as built, or relative to current movement"?
19:09:19 <brickblock19280> as built would be my opinion
19:10:01 <andythenorth> Give it a parameter for relative
19:10:06 <audigex> I don't think it matters as long as it's consistent, but yeah since code assumes as built with "from end" being the reciprocal, keep that the same?
19:10:21 <andythenorth> Need a way to get ‘last’
19:11:26 <audigex> Or change `position_in_consist` to have 4 variants. `position_in_consist_from_`
19:11:26 <audigex> `front_as_travelling`
19:12:09 <audigex> That way you can use _as_travelling if you want to raise the front pantographs or something, and _as_built for current behaviour
19:12:18 <brickblock19280> add two new ones it what that would be but it makes sense
19:12:45 <brickblock19280> I would keep "current" behaviour
19:13:04 <audigex> Yeah 2 new ones (_as_travelling) and the existing ones (_as_built) remain as they are
19:13:23 <audigex> Names for example purposes, we could leave the existing names, whateve
19:14:09 <brickblock19280> or two in nml names don't mater to the spec other than backwards compatibility in
19:18:04 <audigex> It makes sense to leave existing ones as they are, since that would avoid breaking existing GRFs. I'd assume you'd have to "opt-in" new vehicles to the new push-pull, to avoid double-flipping (once by OpenTTD, once by the GRF)
19:18:04 <audigex> So the GRF author of existing sets can either leave it as it is, or add the new `push_pull: 1` flag, and at that time (while removing their own push-pull implementation) can decide if any functionality currently using `position_in_...` should move to the new `_as_travelling` versions
19:18:04 <audigex> Examples off the top of my head would be things like pantographs (some units have 2 pantographs and raise it on the fore end of the unit) or visual effects for diesel locomotives etc
19:21:14 <brickblock19280> we might not need the extra reversed variable then even as it would be opt in making the use of `vehicle_is_reversed`completely fine
19:22:03 <brickblock19280> _as_traveling is probably something which could be figured out by the grf but I don't know if that makes it invalid for adding
19:23:08 <audigex> I figure it's just simplest to just leave `position_in_consist` and `position_in_consist_from_end` as "as built" and adding the `_as_travelling` versions
19:23:08 <audigex> That way you just pick which suits your needs for that particular switch (varact, look at me speaking NFO)
19:27:53 <andythenorth> it's easier to check a specific single var if the push-pull flag is set
19:28:12 <andythenorth> than invert the meaning of var 40 / 41 checks if consist is push-pull reversed
19:28:35 <andythenorth> it's almost potato / potato, but reversing ranges is non-trivial, especially if you're not in python or rust or something
19:28:43 <andythenorth> and doing it manually is error prone
19:29:19 <andythenorth> (all of the above I'm referring to as nml / nfo author context)
19:30:15 <brickblock19280> would that be adding two or not?
19:30:38 <andythenorth> yes adding new ones
19:31:09 <audigex> I guess it could function as `position_in_consist` (etc) does now, unless the new `push_pull` flag is enabled in which case it functions as `position_in_consist_as_travelling`?
19:31:38 <audigex> Ideally I'd say 4 options is less confusing, though
19:32:49 <_jgr_> position_in_consist and position_in_consist_from_end are both from variable 40, NML could output something which selects the relevant subset depending on the reversing flag without the NFO being excessively bad
19:35:13 <audigex> That makes sense, since both sets are available NML can just translate to whichever
19:35:26 <georgevb> andythenorth: Pantographs. When there are two, one can be used in one direction, and the other. Also it can be, that there is one pantograph, but it is up when going back, and down when going forward (or vice versa)
19:36:47 <andythenorth> yeah, would be fine if you read a position var
19:37:05 <andythenorth> _jgr_: if there was no var, I'd just write a procedure 😛
19:37:26 <andythenorth> it's just consist length - position, if reversed, or some similar basic arithmetic
19:38:35 <andythenorth> such armchair coding 🙂
19:53:51 <peter1138> You don't need vars if every part is a separate variant 😉
20:46:56 <andythenorth> to make some towns regional capitals in GS, do I need to learn about Voroni partitions?
20:49:01 <ahyangyi> 🤔 Probably not, since technically the voronoi partitions are decided by the centers, not the other way around
21:17:21 <Tirili> I noticed that in the usual game mode, passengers don't have a specific destination where they want to go and one can fetch them anywhere (the longer the distance, the bigger the amount of money you get). And for resources, it is similar: Just carry them as far as you can to get the highest reward.
21:17:32 <Tirili> Are there mods which make these things a little more realistic?
21:19:46 *** virtualrandomnumber has joined #openttd
21:20:00 *** virtualrandomnumber has quit IRC ()
21:28:33 <_glx_> there's cargo distribution for that
21:29:00 <_glx_> symetric for passenger/mail, asymetric for others
21:30:13 <Tirili> Is this a settings suggestion?
22:19:21 *** casemate_crusader has quit IRC (Ping timeout: 480 seconds)
22:20:56 *** tartessos has quit IRC (Ping timeout: 480 seconds)
22:21:06 *** klote has quit IRC (Ping timeout: 480 seconds)
22:21:06 *** wensimehrp has quit IRC (Ping timeout: 480 seconds)
22:21:11 *** audigex has quit IRC (Ping timeout: 480 seconds)
22:21:16 *** talltyler has quit IRC (Ping timeout: 480 seconds)
22:21:16 *** admeliora has quit IRC (Ping timeout: 480 seconds)
22:21:21 *** rau117 has quit IRC (Ping timeout: 480 seconds)
22:21:26 *** yiffgirl has quit IRC (Ping timeout: 480 seconds)
22:21:26 *** telk5093 has quit IRC (Read error: Connection reset by peer)
22:21:26 *** bootmii has quit IRC (Read error: Connection reset by peer)
22:21:26 *** jfs has quit IRC (Read error: Connection reset by peer)
22:21:26 *** muxydugoulp has quit IRC (Read error: Connection reset by peer)
22:21:26 *** michi_cc has quit IRC (Read error: Connection reset by peer)
22:21:26 *** johnfranklin has quit IRC (Read error: Connection reset by peer)
22:21:26 *** emperorjake has quit IRC (Read error: Connection reset by peer)
22:21:26 *** salut3585 has quit IRC (Remote host closed the connection)
22:21:26 *** _glx_ has quit IRC (Remote host closed the connection)
22:21:26 *** masteroktagon has quit IRC (Remote host closed the connection)
22:21:26 *** xarothbrook has quit IRC (Write error: connection closed)
22:21:26 *** gerrard_ has quit IRC (Write error: connection closed)
22:21:26 *** petike873 has quit IRC (Write error: connection closed)
22:21:26 *** amadeus6152 has quit IRC (Write error: connection closed)
22:21:26 *** gebik4544 has quit IRC (Write error: connection closed)
22:21:26 *** kuhnovic has quit IRC (Write error: connection closed)
22:21:26 *** truebrain has quit IRC (Write error: connection closed)
22:21:26 *** _jgr_ has quit IRC (Write error: connection closed)
22:21:26 *** DorpsGek_vi has quit IRC (Write error: connection closed)
22:21:26 *** __karma has quit IRC (Write error: connection closed)
22:21:26 *** peter1138 has quit IRC (Write error: connection closed)
22:21:26 *** locosage has quit IRC (Write error: connection closed)
22:21:26 *** yeah_its_gloria has quit IRC (Read error: Connection reset by peer)
22:21:26 *** softinterlingua_9093 has quit IRC (Read error: Connection reset by peer)
22:21:26 *** gwyd4016 has quit IRC (Write error: connection closed)
22:21:26 *** _zephyris has quit IRC (Write error: connection closed)
22:21:26 *** georgevb has quit IRC (Write error: connection closed)
22:21:26 *** silent_tempest has quit IRC (Write error: connection closed)
22:21:26 *** alfagamma7 has quit IRC (Write error: connection closed)
22:21:26 *** ahyangyi has quit IRC (Write error: connection closed)
22:21:26 *** brickblock19280 has quit IRC (Write error: connection closed)
22:21:26 *** kamnet has quit IRC (Write error: connection closed)
22:21:26 *** andythenorth has quit IRC (Write error: connection closed)
22:21:26 *** belajalilija has quit IRC (Remote host closed the connection)
22:21:26 *** efessel has quit IRC (Write error: connection closed)
22:21:49 *** DorpsGek_vi has joined #openttd
22:26:16 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:37:04 <Tirili> Is it possible to use FIRS and Cargodest in Scenarios?
23:24:41 *** audigex has joined #openttd
23:24:41 <audigex> Cargodist is built into the game, so yes that's possible regardless of any other consideration. Scenarios are a little more situational:
23:24:41 <audigex> If making your own scenario, yes it's easy: just enable the newGRF before starting the scenario maker and placing the industries
23:24:41 <audigex> If it's someone else's scenario and you want to modify it, it's still possible but you'll probably have to mess around more (remove industries, remove any industry GRFs, add FIRS, place industries)
23:25:14 *** SigHunter_ has quit IRC (Ping timeout: 480 seconds)
23:25:42 <audigex> You'd probably also be better off asking these questions in Discord channel #openttd-help - this channel is specifically for discussing development of the code of the game itself. You'll usually get answers in here but fewer people keep track of it and you'll generally get better, faster help over in that channel
23:43:42 *** SigHunter has joined #openttd
23:52:14 <Tirili> Alright, audigex, thank you for your explanations!
continue to next day ⏵
