IRC logs for #openttd on OFTC at 2025-09-20
            
00:02:22 *** Flygon has joined #openttd
01:58:13 *** Wormnest has quit IRC (Quit: Leaving)
02:19:31 *** dh1 has quit IRC (Ping timeout: 480 seconds)
02:28:25 *** davidxn has joined #openttd
02:28:25 <davidxn> https://cdn.discordapp.com/attachments/1008473233844097104/1418785836719145082/image.png?ex=68cf62c7&is=68ce1147&hm=a63a3f7ab7f689e2e0a166b808c3f75c5164e03db0f01995ba24507930e3c5ad&
02:28:25 <davidxn> https://cdn.discordapp.com/attachments/1008473233844097104/1418785837101092916/image.png?ex=68cf62c7&is=68ce1147&hm=4baa0a494baaaf4a23ef309b64be0689d630d98ce6f9cd9dc34fe6cc2f22c951&
02:28:25 <davidxn> Oh my god why are trains' max speeds recorded as their actual in-game shown value but road vehicles' max speeds are twice that value
02:29:18 *** dh1 has joined #openttd
02:30:54 <davidxn> Boats are expressed as double their in-game max speed and aircraft with 1/4 of their in-game max speed
03:19:23 <reldred> There's a seperate setting that controls the plane speed, 1/4th speed was chosen for gameplay purposes
03:19:32 <reldred> Dunno what the deal with boats is
03:19:46 <reldred> You can change the plane speed divisor though
03:23:03 <davidxn> Yep, I knew about that setting - that one sort of makes sense πŸ™‚ Although there was something funny about that - I remember that the speed values stored on planes are the *4 values, and it's only when they're actually moved that the 1/4 penalty applies to the speed... I'd have to look it up again, though
03:35:32 *** dh1 has quit IRC (Ping timeout: 480 seconds)
03:44:58 *** dh1 has joined #openttd
03:46:25 *** Zathras has joined #openttd
03:49:59 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:10:15 *** keikoz has joined #openttd
04:11:42 *** kaibaneddy has joined #openttd
04:11:42 <kaibaneddy> davidxn: Precision vs bigness in a single byte value. (127mph top speed in 0.5mph increments for ships, vs 2040mph top speed in 8mph increments for planes, etc) Chris Sawyer being efficient. πŸ™ƒ
04:12:40 <davidxn> kaibaneddy: Aha πŸ™‚ That’s incredible! I’ve never coded in a world where space efficiency on that level matters
04:37:38 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/2aaffbe23ca559c9fc1b5824a5807e1dcf8373e1
04:37:39 <DorpsGek> - Update: Translations from eints (by translators)
05:43:55 *** Flygon has quit IRC (Remote host closed the connection)
06:46:32 <andythenorth> well
06:46:41 <andythenorth> such coffee
07:01:11 *** WormnestAndroid has quit IRC (Remote host closed the connection)
07:01:14 *** WormnestAndroid has joined #openttd
07:17:26 <DorpsGek> [OpenTTD/OpenTTD] Rito13 updated pull request #14605: Feature: [#13915] Make vehicle testing offers appear in one window. https://github.com/OpenTTD/OpenTTD/pull/14605
07:17:53 <DorpsGek> [OpenTTD/OpenTTD] Rito13 commented on pull request #14605: Feature: [#13915] Make vehicle testing offers appear in one window. https://github.com/OpenTTD/OpenTTD/pull/14605#issuecomment-3314712620
07:48:45 <andythenorth> hmm
07:49:52 <andythenorth> I might have hallucinated something
07:50:03 <andythenorth> I thought grfs were supposed to be load-order independent, these days
07:50:27 <andythenorth> except for those using Action A etc
07:59:52 <andythenorth> so Iron Horse defines a narrow gauge railtype using the official label NAAN
08:00:10 <andythenorth> and JP+ tracks defines a narrow gauge railtype using the official label NAAN
08:00:40 <andythenorth> but if Iron Horse is loaded after JP+, the JP+ narrow gauge railtype is overwritten by the Iron Horse railtype
08:01:40 <andythenorth> this is irrelevant to Iron Horse containing trains, the same effect happens with other grfs
08:02:44 <reldred> Same happens with road sets
08:03:16 <reldred> I do some trickery currently loading RattRoads and U&RATT 0.5 (for the HAUL roads) simultaneously.
08:03:35 <reldred> (and because I want the darker dirt roads from RATT for the town roads)
08:04:05 <reldred> Also the same can happen with station sets and object sets that define the same category
08:04:15 <reldred> the one loaded later takes priority for the name, yadda yadda
08:04:36 <andythenorth> I understand how it works on the spec level
08:05:03 <andythenorth> just weird how it's used
08:05:16 <andythenorth> why do the railtype grfs set the standardised labels?
08:05:29 <andythenorth> why don't they set private labels, then set standardised in compatibility props?
08:05:43 <andythenorth> it seems like bad behaviour in the current convention
08:06:03 <reldred> Might not have occurred to anyone back then
08:06:21 <reldred> Or the assumption is that people would only load one 'big' rail set.
08:06:46 <andythenorth> even 2 small sets will conflict over common types
08:07:25 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1418871156785807421/image.png?ex=68cfb23d&is=68ce60bd&hm=595168c5612f4320d6e29de3c480ec589c00016210a21c214757456b2ded6cd1&
08:07:44 <reldred> Hmm, by that I mean you'd only load one U&Rermm/JPSet Tracks/NK Tracks, but you might then load over the top something like industrial trackset, etc.
08:07:44 <andythenorth> I can't make any sense of that ^
08:08:04 <reldred> I mean, in no universe would I tell people to load JP+ tracks alongside another track set
08:09:11 <andythenorth> yair, it was just in my grf list already
08:11:21 <andythenorth> hmm load order isn't the only factor
08:11:35 <andythenorth> U&REMM overwrites NuTracks narrow gauge, whatever the load order
08:12:26 <reldred> If anyone came into Discord channel #openttd or Discord channel #openttd-help complaining of that we'd just tell them 'don't'
08:12:37 <andythenorth> which makes sense
08:12:42 <andythenorth> but I want to understand the behaviour
08:13:12 <andythenorth> I had a situtation which I thought was workable, but Iron Horse now breaks JP+
08:13:24 <andythenorth> because I've moved Iron Horse to use standardised labels where they exist
08:13:38 <reldred> How so? just load horse before JPTracks?
08:14:16 <andythenorth> recently, child #1 showed me his minecraft mod load order across 5 modding frameworks 😐
08:14:35 <reldred> Yeah none of this stuff is particularly new challenges with Modding
08:15:07 <reldred> https://cdn.discordapp.com/attachments/1008473233844097104/1418873094520569856/image.png?ex=68cfb40b&is=68ce628b&hm=79607da4aa3f7d6f10d33889674bdf2d887dccc48e3b3f37b0552549397869bb&
08:15:07 <reldred> Here's an example of my mod load list in OpenTTD
08:15:33 <reldred> Cyberpunk isn't so much an issue with load orders, only with archive pacakges overwriting base game assets.
08:15:48 <reldred> Elder Scrolls and Fallout games are very very critical on load order for mods
08:15:48 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1418873267720163398/image.png?ex=68cfb434&is=68ce62b4&hm=35d5108adc5cd3df6051f98acd5710ae1524ca0310f5c7dbe087e76eeeed7a32&
08:15:48 <andythenorth> don't live in such a world πŸ˜›
08:16:20 <reldred> Like, it's a challenge that anyone who gets deep into modding understands thhat load order is important.
08:16:46 <andythenorth> hrrrm
08:17:00 <andythenorth> ok but it's so unacceptable for some people to deal with load order
08:17:06 <andythenorth> that they must have a grf parameter instead
08:17:11 <andythenorth> which they'll also forget to set
08:17:13 <andythenorth> or not know about
08:17:20 <andythenorth> or can't change during game
08:17:42 <andythenorth> maybe I can disable Horse with railtypes
08:18:13 <reldred> Like, I don't know a single game with modding where load order isn't important (apart from cyberpunk, but their modding is a bit weird)
08:18:26 *** dh1 has quit IRC (Remote host closed the connection)
08:18:32 <reldred> Stellaris is critical, mods will even have crazy ### prefixes and stuff to force order with alphabetical sort
08:18:57 *** dh1 has joined #openttd
08:19:17 <andythenorth> maybe I can prevent Horse defining NAAN if it's already present
08:19:30 <andythenorth> I thought NML had some cargo culted code to do that already
08:19:33 <reldred> And Stellaris is a mainstream large publisher game with first party modding support
08:21:21 <andythenorth> how are players supposed to know what speeds to set in U&REMM?
08:21:39 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1418874740742950972/image.png?ex=68cfb593&is=68ce6413&hm=e9cc1013f33bbf47eb73a5ba335769a34098591e8ab12b37f16dd30df1b53722&
08:22:01 <andythenorth> Iron Horse NG trains go 45 mph
08:22:04 <reldred> it was the players who badgered Ufiby to add that feature
08:22:15 <reldred> so surely some of them must know why they wanted it
08:22:51 <andythenorth> so the player has to load the grfs, then go to like 2050, use 'vehicles never expire' and note down all the vehicle speeds for each base railtype
08:23:03 <andythenorth> then go back, possibly do an mph to km/h conversion
08:23:07 <andythenorth> then set all of the values
08:23:34 <reldred> I just disable speedlimits on rails entirely πŸ˜›
08:25:01 <reldred> But, look at the stats, there's a huge component of the player base that just simply Chooses Not To entirely.
08:25:21 <reldred> And that's OK I guess. Boring to me but eh.
08:27:27 <andythenorth> hmm
08:27:43 <andythenorth> I guess grfs don't prevent players loading the gun and shooting themselves in the head
08:28:07 <reldred> It's not your responsibility to fix all the worlds ills
08:28:35 <andythenorth> currently I'm loading railtype grfs with Horse to test them
08:28:46 <reldred> And you certainly can't 'idiot proof' modding computer games.
08:29:10 <andythenorth> there's no reliable way to assume cooperation across railtypes, unlike cargos
08:29:25 <_jgr_> With things like speed parameters, most players aren't going to know or care, so it's important that the default is sensible
08:29:25 <andythenorth> this is so brain-breaking compared to cargos
08:30:22 <andythenorth> ok, so the only way to know if a train grf works with railtype grfs is to load them in the same game and test them
08:30:42 <andythenorth> multiple railtype grfs are fairly unpredictable in combination, so I'm excluding that path
08:30:53 <andythenorth> my QA criteria is 'not broken'
08:31:10 <andythenorth> but I think I need to refine it to 'not broken by Iron Horse'
08:31:24 <andythenorth> because lots of railtype grfs are just broken already
08:35:18 <reldred> Yeah, I mean, I look at bananas and treat 99% of it as garbage.
08:35:21 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1418878186405625907/image.png?ex=68cfb8c9&is=68ce6749&hm=4adcc2392fe0787f4238e46a3b5bb87f67a406cf74ab5896ee44ab26d7458dbd&
08:35:21 <andythenorth> I'm sure these are going to help the situation
08:35:29 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1418878221755220040/image.png?ex=68cfb8d1&is=68ce6751&hm=ee0682d8fff18c3d70520032883fa2d52e9fdba3bc715053eea25f7ce9bc011d&
08:36:58 <reldred> Situation Normal: All fucked up.
08:38:01 <andythenorth> right channel change time πŸ˜›
08:38:09 <andythenorth> [now making a list of broken railtype grfs]
08:40:25 <reldred> I think you're on the right track with your approach, if people complain, tell them to load horse first or GTFO
08:41:54 <andythenorth> scope is limited to "Horse doesn't break the railtype grf"
08:53:40 *** Wolf01 has joined #openttd
09:25:04 <andythenorth> hmm not sure what grf spec feature is mapped to nml's `railtype_available()`
09:27:00 <andythenorth> is it some GRM method?
09:29:37 <andythenorth> the function seems to resolve to `expression.GRMOp`
09:31:56 *** michi_cc has joined #openttd
09:31:56 <michi_cc> andythenorth: It's just a special Action 7/9 condition
09:39:46 <andythenorth> nml wiki recommends this copy-paste conditional before a railtype declaration
09:39:46 <andythenorth> `if (railtype_available("FOO_") || (loading_stage == LOADING_STAGE_RESERVE)) {`
09:39:57 <DorpsGek> [OpenTTD/OpenTTD] AnnoyingBart commented on issue #14632: [Bug]: No GRF manager in Beta 3? https://github.com/OpenTTD/OpenTTD/issues/14632
09:40:29 <andythenorth> I'm unclear how I'd extend that, or modify the booleans, so that the railtype only activates if the type is not already reserved by label
09:41:38 <andythenorth> was trying to work out the semantics of `railtype_available` - whether it means "railtype can be instantiated" or "railtype is already instantiated"
09:46:54 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
10:01:05 <andythenorth> ok so it's 0x0D here I think https://newgrf-specs.tt-wiki.net/wiki/Action7#condition-type
10:04:45 <andythenorth> there's also 0x0E for 'railtype label is defined'
10:06:36 <michi_cc> Railtypes are allocated in reservation stage. So this means that in reservation stage, the label is defined if an act 0 defining the railtype came before the check in load order. After reservation stage, order doesn't matter anymore.
10:07:28 <andythenorth> thanks
10:07:37 <andythenorth> now trying to figure out the nml semantics
10:07:51 <andythenorth> `railtype_available` is boolean true if the label is not defined
10:07:55 <andythenorth> it checks 0x0D
10:08:20 <andythenorth> unless I've missed an inversion somewhere
10:08:51 <michi_cc> And reservation stage is only relevant for defining a new railtype, not for using it in a vehicle. Not sure how exactly NML maps the railtypetable fallback to the laoding stages (also, c.f. <https://newgrf-specs.tt-wiki.net/wiki/GrfLoadingStages>)
10:09:23 <andythenorth> `During reservation stage especially cargo- and railtypes are reserved, so their existence can be tested by all GRFs in activation stage independent of loading order.`
10:09:28 <andythenorth> seems highly relevant to this case
10:10:15 <michi_cc> If `railtype_available` is in fact using 0D (and not 0E), the descriptions is either highly misleading or you found a bug.
10:10:46 <andythenorth> well I might be missing a boolean inversion
10:11:30 <andythenorth> https://github.com/OpenTTD/nml/blob/master/nml/expression/functioncall.py#L362
10:12:14 <andythenorth> it's entirely consistent with history that nml is wrong, and people have been cargo-culting this and it never worked https://newgrf-specs.tt-wiki.net/wiki/NML:Railtypes#Railtype_IDs
10:12:17 <michi_cc> Hmm, maybe, I don't know how the NML internals translate Action 7s, but the Act7 can only skip, so if something shall be done if the railtype is available, the condition for the skip does indeed need to be inverted.
10:12:20 <andythenorth> but more probable I"m wrong
10:13:34 <michi_cc> So a `if (x) Y` would probably be a `Act 7 !X (skip to A) Y A`
10:16:14 <andythenorth> dare we try and read the generated nfo?
10:17:33 <andythenorth> I only see one action 7, preceded by a lot of action D
10:18:03 <andythenorth> https://gist.githubusercontent.com/andythenorth/6ab501b41f63edc683131370e9909c68/raw/199ad9a9b85830f36f5cf93bce7f32b318594e48/gistfile1.txt
10:18:46 <andythenorth> for avoidance of doubt, I do **not** understand any of that πŸ˜›
10:19:32 <andythenorth> oh there's an action 9 there also
10:20:19 <michi_cc> Yeah, seems that NML uses Act 9 here, because it works in all stages
10:22:50 <andythenorth> `\dx4E41414E` is the label parameter to var 0x0D?
10:23:36 <michi_cc> I guess
10:25:34 <andythenorth> I'm reading 4 sprites skipped
10:25:45 <andythenorth> the action D stuff...I have no clue πŸ™‚
10:26:51 <andythenorth> oh does the action 9 skip everything before the action 7?
10:27:09 <andythenorth> so that the label will *always* be reserved, skipping the check on 0x0D?
10:28:08 <michi_cc> No, the last byte is the skip count, so the act9 in this case will skip only the next action
10:30:24 <michi_cc> So basically NML sets `param[123]` based on the test, and then uses that (and some more magic) to get to a condition for the Action 7 directly before the act 0.
10:38:18 <andythenorth> ah that explains why the action 7 doesn't check 0x0D directly
10:42:03 <andythenorth> so I want to skip the action 0 if the railtype label already exists
10:42:15 <andythenorth> whilst not breaking whatever this nml magic is trying to achieve πŸ™‚
10:54:25 <locosage> I think I copied in grf-py rail type table what nml does <https://github.com/citymania-org/grf-py/blob/4794eaa17e4522268249d3d5cc9534f0a0f6a521/grf/grf.py#L998>
10:55:39 <locosage> Not sure I copied the exact actions it does but I sure looked at the decompile to make sure it works the same
11:09:38 <andythenorth> looks like the spec has everything needed to only enable a railtype if another grf hasn't already reserved it
11:09:49 <andythenorth> but the implementation is .... beyond me πŸ™‚
11:17:28 <reldred> sleep on it πŸ˜›
11:17:36 <reldred> or have a nice cup of tea
11:42:45 <peter1138> https://github.com/grishka/Smithereen/blob/master/CLAUDE.md
11:53:45 *** klibber has joined #openttd
11:53:45 <klibber> A question to you all, how do you build faster when just trying to test you implementation ?
11:57:25 *** SigHunter has quit IRC ()
11:58:32 <_glx_> Debug build ?
12:00:17 *** SigHunter has joined #openttd
12:01:48 <peter1138> Well, reading scroll back, I'm not sure why it's surprising that two GRFs defining the same thing will, uh, define the same thing.
12:02:52 <_glx_> Yeah, first grf creates the label, any grf after it overwrites
12:03:01 *** Flygon has joined #openttd
12:03:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #14632: [Bug]: No GRF manager in Beta 3? https://github.com/OpenTTD/OpenTTD/issues/14632
12:05:42 <andythenorth> as I read the spec, I should be able to prevent overwriting a label if it exists
12:06:13 <andythenorth> the alternative is using my own label, but the community doesn't like that
12:08:01 <andythenorth> a second alternative is not caring
12:14:23 <rito12_51026> klibber: Build on multiple cores?
12:16:25 <peter1138> You can't prevent another NewGRF overwriting something you've defined, but you can detect if it already exists and prevent your own NewGRF overwriting the existing definition.
12:18:42 <andythenorth> yes, that's what I wish to do
12:18:51 <andythenorth> Well Behaved NewGRF Citizen
12:19:38 <andythenorth> I can do it in nml by detecting specific other grfids, that I know the contents of
12:20:17 <peter1138> Regarding using custom labels and defining things like SRS via compatibility lists... maybe that would work? I don't know, but I do know that the compatibility lists wasn't in the original railtype spec.
12:21:43 <andythenorth> it's theoretically and practically possible to do that route
12:22:16 <andythenorth> but it's also theoretically and practically fragile as the Standardised Scheme requires very large numbers of labels to be supported as 'compatible'
12:22:32 <andythenorth> whilst also blurring the semantics of whether they are actually 'compatible
12:23:15 <andythenorth> for me not overwriting another railtype grf, the best solution seems to be "don't care, change the load order"
12:23:23 <andythenorth> but only because I'm bad at nml πŸ˜›
12:26:09 <peter1138> How many railtypes would I have available if I namespaced the labels?
12:27:09 <andythenorth> this is like an exam question about bytes
12:27:13 <peter1138> Now that rail vehicles can have multiple railtypes, if multiple labels define the same compatibility label, do they get all?
12:27:37 <peter1138> andythenorth, I increased it to a uint16_t :-)
12:27:59 <andythenorth> the resolution of compatibility is not something I'd dare to answer
12:28:36 <peter1138> I could look at the code.
12:28:48 <peter1138> Or I could continue smashing up fractional sprite scaling.
12:28:55 <andythenorth> I am going to Tesco
12:29:01 <andythenorth> to buy kale
12:33:28 <peter1138> I am going to a BBQ.
12:33:32 <peter1138> It's going to rain.
12:36:30 <_glx_> yeah rainy here, and lost 10Β°C (it was 30Β°C yesterday)
12:37:34 <peter1138> Warm at the moment.
13:00:22 <LordAro> i just ended up walking 5 miles in the rain
13:00:34 <LordAro> without significant waterproofs
13:32:09 *** Wormnest has joined #openttd
14:28:52 <andythenorth> oops
14:29:52 <andythenorth> was it wettening?
14:30:06 <LordAro> my jeans are still damp
14:35:41 <andythenorth> hmm, what if I declare the railtype action 0 in a conditional for `LOADING_STAGE_RESERVE`, then otherwise only declare it if it doesn't exist
14:36:11 <andythenorth> still unclear on what `railtype_available()` tests though
14:58:23 <DorpsGek> [OpenTTD/OpenTTD] Moth-Tolias opened pull request #14634: Change: Replace the "(City)" identifier in the town directory with the city icon https://github.com/OpenTTD/OpenTTD/pull/14634
15:21:43 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #14635: Feature: Scale cargo payment decay rate https://github.com/OpenTTD/OpenTTD/pull/14635
15:22:26 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #14634: Change: Replace the "(City)" identifier in the town directory with the city icon https://github.com/OpenTTD/OpenTTD/pull/14634#pullrequestreview-3249093052
15:23:14 <andythenorth> so afaict, `railtype_available()` means 'railtype is not available'
15:23:27 <andythenorth> so possibly it means 'railtype can be defined'
15:24:48 <andythenorth> changing the bool to false on this line causes the railtype to be available in game, but without any of the action 0 props set
15:24:49 <andythenorth> https://gist.github.com/andythenorth/44598959435e1c6056c3a8bb45a85751#file-gistfile1-txt-L7
15:25:22 <andythenorth> or I misunderstand 'reserve'
15:25:28 <andythenorth> and 'activate'
15:26:54 <andythenorth> maybe I have to actually learn about GRM πŸ˜›
15:28:01 <andythenorth> ok so yeah, a GRM reservation will cause the railtype label to be available
15:28:17 <andythenorth> so there's no way to conditionally enable a railtype action 0 afaict
15:28:20 <yiffgirl> so, what are people thinking for the explanation of how cities work?
15:28:20 <yiffgirl> "This town is a City πŸ™οΈ, and as such generates four times more cargo than normal."
15:31:10 <_jgr_> yiffgirl: That is not what the city flag does, or are you proposing to make it do that?
15:31:36 <_jgr_> All it does it increase the town growth speed
15:32:40 <andythenorth> wonder what happens if I don't make a GRM reservation for a railtype?
15:33:26 <andythenorth> bad things πŸ™‚
15:34:14 <yiffgirl> _jgr_: brain fart. my mistake
15:35:11 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #14636: Feature: Alternate station rating algorithm https://github.com/OpenTTD/OpenTTD/pull/14636
15:36:57 <talltyler> Very draft, but I've been stuck on this for a while so I wanted to get it out there
15:37:10 <talltyler> For comments, feedback, inspiration, etc.
15:38:42 <yiffgirl> oh i am super hyped for this
15:40:14 <andythenorth> think railtypes might be the ditch I die in πŸ˜„
15:40:44 <andythenorth> there must be a predicate that will cause the railtype to **not** be reserved if another grf has reserved it already
15:41:07 <andythenorth> no, that won't work, due to later stage
15:41:12 <jessicathegunlady> talltyler: What it proposes to do is to solve issues I've observed for quite some time now. Not significant, but a flaw regardless. This seems to alleviate every case where a penalised station rating just doesn't make sense. I'm fully in favour.
15:41:13 <andythenorth> wonder if I can set a param
16:01:05 <yiffgirl> jgr does have a breakdown of how the various factors affect station rating. i'd love to see something akin to that make it in.
16:04:20 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
16:04:21 <michi_cc> andythenorth: Well you need to store the result of act 7/9 condition 0D or 0E into a param (with act D) in the reservation stage, and use this to skip the act 0 in all stages if necessary.
16:07:21 <andythenorth> that makes sense
16:07:21 <andythenorth> although... if I forget what I've done, and in some later revision I try to use additive action 0 props...I'll have regrets πŸ™‚
16:23:43 <talltyler> yiffgirl: Yes, but stylistically it doesn’t match anything else in OpenTTD so we can’t just upstream it.
16:23:43 <talltyler> I started work on doing this as one of the usual yellow tooltips, but made a mistake somewhere when refactoring, the station ratings are now wrong. Didn’t even get to the UI part.
16:23:43 <talltyler> https://github.com/2TallTyler/OpenTTD/tree/station-rating-why
16:24:25 <talltyler> This is where I got stuck, I was frustrated with this part and put it down, then got distracted by other things πŸ™‚
16:25:08 <locosage> If jgrpp does it the same way as cmclient it's a style worth introducing imo
16:25:30 <locosage> It's used in other places in cmclient as well
16:27:15 <locosage> Initial rating breakdown patch on forum used yellow tooltips and it looked so bad I made my own
16:28:02 <locosage> Also, there is a tricky question how to show upstream penalties in these tooltips
16:32:52 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on pull request #14636: Feature: Alternate station rating algorithm https://github.com/OpenTTD/OpenTTD/pull/14636#issuecomment-3315090970
16:36:02 *** kuhnovic has joined #openttd
16:36:02 <kuhnovic> talltyler: cool stuff, I'm looking forward to trying it out
16:39:29 <kuhnovic> By the way, openrct2 has a Park Rating Inspector plugin which gives the user insights about what's influencing the park rating. Don't know if you're into RCT but it might be a source of inspiration. At least if you plan on showing the user why the rating are what they are.
16:39:46 <kuhnovic> Probably best to just do one thing at a time πŸ˜‰
17:07:00 <DorpsGek> [OpenTTD/OpenTTD] Rito13 opened pull request #14637: Feature: Reward or fine at the end of engine preview. https://github.com/OpenTTD/OpenTTD/pull/14637
17:09:06 <jessicathegunlady> that's...
17:09:08 <jessicathegunlady> whuh
17:10:55 <jessicathegunlady> This seems to go against base OpenTTD's goals as a project.
17:11:29 <rito12_51026> really
17:12:19 <_glx_> there's already a penalty for not using a preview (you don't get preview for some time)
17:12:33 <jessicathegunlady> Oh, intriguing, I didn't realise.
17:13:29 <jessicathegunlady> This still seems like a more... Impactful change. Would this not be the kind of thing that should just be a GameScript instead?
17:15:39 <jessicathegunlady> I'm not *opposed* to it, I like the idea, I'm just testing if my assessment of 'this doesn't seem like it should be a part of base OpenTTD' is broadly agreed upon.
17:21:54 <jessicathegunlady> The vanilla vehicle preview implementation feels like it's not meant to *expect* the player to assess the vehicle. It's just "we're developing this, and you can try it out if you like." Thus the penalty for not *using* said preview on top of that. Manufacturers just go 'eh, what's the point?' if a company doesn't use the opportunities it's given.
17:21:57 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #14638: Codechange: Refactor station rating code slightly and add comments https://github.com/OpenTTD/OpenTTD/pull/14638
17:23:50 *** truebrain has joined #openttd
17:23:50 <truebrain> jessicathegunlady: You are not wrong; typically this has been delegated to scripts, as otherwise you get in an endless debate what the correct penalty is πŸ˜›
17:24:00 <jessicathegunlady> lmao
17:24:09 <jessicathegunlady> Yeah that doesn't help things. Gotta have a consensus.
17:24:19 <_jgr_> Engine previews are already a bit useless, an extra penalty would make them even more so
17:24:34 <truebrain> It is not about consensus, but about different play styles πŸ™‚
17:24:41 <jessicathegunlady> I'm not sure I'd agree.
17:24:50 <jessicathegunlady> truebrain: Oh, yeah, but like... Dev consensus.
17:25:04 <jessicathegunlady> Or one dev with PR management can put their foot down, I guess?
17:25:15 <truebrain> It is more: if this would be an event where a GS can react to and create such headlines, you get infinitely more playability πŸ™‚
17:25:46 <rito12_51026> jessicathegunlady: Mayby GRFs instead of GS?
17:25:58 <jessicathegunlady> _jgr_: There's a bonus as well. It's sorta risk/reward, it motivates you to test it.
17:26:21 <jessicathegunlady> rito12_51026: I'm not sure how a GRF could handle it, but I'm just not familiar with GRFs as a whole.
17:26:42 <jessicathegunlady> I think "events" like this should ideally be up to a GameScript to implement.
17:26:58 <truebrain> https://github.com/OpenTTD/OpenTTD/blob/master/CONTRIBUTING.md#project-goals is btw a nice write-up about the idea behind what I just mentioned. Most important snippet:
17:26:58 <truebrain> `The preferred method to introduce new gameplay features is to extend the content APIs, supporting ever more add-on content / mods.`
17:27:34 <jessicathegunlady> Thank you, that's kinda what I've been trying to say.
17:28:04 <jessicathegunlady> jessicathegunlady: The issue with this is that users can only run one GameScript at present.
17:28:45 <jessicathegunlady> More a flaw with GameScripts as a whole, though.
17:31:47 <andythenorth> it's not 100% true
17:31:58 <andythenorth> if GS had been developed as libs with a standard interface
17:32:13 <andythenorth> it's entirely possible to call all main() on all the registered libs
17:32:19 <andythenorth> within the tick loop
17:32:27 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #14637: Feature: Reward or fine at the end of engine preview. https://github.com/OpenTTD/OpenTTD/pull/14637#issuecomment-3315129184
17:32:40 <andythenorth> obvs that requires GS authors to behave well
17:33:28 <andythenorth> maybe I should force the issue with FIRS GS
17:33:32 <andythenorth> but that's unfinished
17:35:15 <locosage> truebrain: that does apply to things like #14636 too btw ;)
17:35:25 <locosage> especially since there is already a station rating callback
17:36:56 <jessicathegunlady> andythenorth: We could probably also do with better ways to communicate between GameScripts if such a thing is implemented.
17:37:06 <truebrain> How the penalty was calculated was btw what promoted my response on this. I just envisioned people wanting to try alternative approach to that πŸ˜„
17:37:14 <jessicathegunlady> I'm not sure why the current limitation exists. I assume there's a good reason.
17:37:30 <_jgr_> Currently you need to choose the GS you want before you start playing. Changing after the fact is very cumbersome. But for things like engine previews you're likely not going to know whether any configuration is good enough until you've been playing for a while.
17:38:16 <rito12_51026> jessicathegunlady: The current behavior is already a little bit different than TTDs
17:38:33 <truebrain> We once had a draft to attach a GS to each separate "thing", so different engines could even have different GSes attached πŸ˜›
17:38:35 <truebrain> It was a nice draft
17:39:12 <jessicathegunlady> truebrain: Like...
17:39:29 <jessicathegunlady> GRFs could provide their own GS?
17:40:07 <jessicathegunlady> Just wondering what... Well, what 'attaching' a GS is in this case.
17:40:32 <truebrain> have a GS per town, per industry-group, per ...
17:40:38 <truebrain> let me find the wiki page .. it was a nice idea
17:40:40 <jessicathegunlady> Oohhhhhh, right.
17:40:41 <truebrain> just nobody ever build it πŸ˜›
17:40:54 <andythenorth> it inspired me to yolo FIRS GS
17:41:12 <andythenorth> there was a lot of hot air about "GS and GRF can't work together, ever, by design and computer science facts"
17:41:14 <jessicathegunlady> I'm definitely thinking about improving GS stuff long term, including handling cross-GS loading.
17:41:38 <andythenorth> I generate FIRS GS from the FIRS grf compile, by templating squirrel with python
17:41:55 <andythenorth> so lots of things that could never work...do because of static properties being inserted
17:42:28 <truebrain> https://wiki.openttd.org/en/Development/Design%20Drafts/Scripts/Capability-based%20API
17:42:36 <jessicathegunlady> andythenorth: Do you have an example so I can better understand?
17:44:20 <jessicathegunlady> truebrain: I'm admittedly not a very big fan of having a strict 'this script handles industries, this script handles towns', and the available APIs are limited by those strict categories.
17:44:22 <andythenorth> jessicathegunlady: it's probably easier to get the FIRS repo
17:44:36 <andythenorth> https://github.com/andythenorth/firs/tree/v5-release-track
17:45:04 <jessicathegunlady> Oh, the GS is in there, heck. I'll have a poke around.
17:45:23 <andythenorth> there's no API for GS to get a lot of GRF facts, so I just generate a big LUT
17:46:55 <DorpsGek> [OpenTTD/OpenTTD] James103 started discussion #14639: Allow Game Scripts to post news items of non-basic types https://github.com/OpenTTD/OpenTTD/discussions/14639
17:48:39 <jessicathegunlady> jessicathegunlady: Mostly because I think it should be a guideline. GameScripts may have goals that slightly conflict, but could work together if both scripts are able to negotiate with each other and ensure compatibility.
17:49:11 <andythenorth> hi, let me send you a newsletter about railtypes? πŸ™‚
17:49:30 <jessicathegunlady> lmfao
17:49:37 <andythenorth> GS won't cooperate
17:49:43 <andythenorth> but it's ok because nobody writes GS
17:49:45 <andythenorth> πŸ˜›
17:49:45 <jessicathegunlady> "here's my 500 word essay on what I think should be changed"
17:49:53 <jessicathegunlady> andythenorth: GS won't cooperate?
17:49:59 <andythenorth> authors won't
17:50:18 <andythenorth> but "everybody knows nobody uses GS because you can only have one" 🀣
17:50:37 <locosage> truebrain: judging by listed api that page seems surprisingly recent
17:50:50 <locosage> ScriptGoal is very much exclusive for old scripts though
17:50:56 <truebrain> jessicathegunlady: Like andy said: building a system that depends on authors of any addon to play nice is not a good system, we found out the hard way πŸ™‚ Hence the strict isolation, avoids all that conflict, and puts it in the hands of the player what they like/dislike πŸ™‚
17:51:41 <truebrain> And if you really wanted to, you can make an API for GSes to talk to each other πŸ˜›
17:51:53 <truebrain> It is also easier in the execution model btw
17:51:54 <andythenorth> we could also static analyse what capabilities each script wants write access to?
17:52:00 <truebrain> no
17:52:11 <jessicathegunlady> truebrain: It's definitely something I'd like to look in to.
17:52:39 <andythenorth> there was also a strong proposal to 'replace the entire mod system, without replacing the content APIs'
17:52:40 <andythenorth> from TB
17:52:46 <jessicathegunlady> I *think* there's ways to potentially have - or force - different GSs to play nicely with each other or get to deal with mutually assured destruction.
17:52:50 <andythenorth> but time and interest intervened I believe
17:53:05 <truebrain> Time .. time ... time is such a weird resource to have
17:53:13 <andythenorth> is it illusion?
17:54:07 <truebrain> Not sure, let me look out of the window
17:54:14 <truebrain> AHH, NO, THE LIGGHTT, AARRRGGHHHH
17:55:12 <yiffgirl> andythenorth: i'm really curious what this looked like
17:55:42 <andythenorth> it's in a github gist somewhere
17:56:34 <mnhebi> truebrain: I sometimes ponder about installing some red light therapy lights to help with my eyes..
17:57:09 <truebrain> I am afraid if I do that, people would knock on my door a lot
17:57:46 <yiffgirl> jessicathegunlady: pinning the 95 theses to the dev channel
17:58:10 <truebrain> https://gist.github.com/TrueBrain/fe3c80e7dc9313b7ac7941540e5dee22
17:58:10 <truebrain> More rambling about the same system; no clue how coerent it is in 2025 πŸ™‚
18:00:40 <andythenorth> directly inspired how I structured FIRS GS https://github.com/andythenorth/firs/tree/v5-release-track/src/gs/templates/vulcan
18:00:49 <andythenorth> with capability specific modules
18:02:52 <truebrain> I think that gist let me to WASM and creating a terrain generator in it πŸ˜› Not sure anymore πŸ˜„
18:05:54 <jessicathegunlady> I think my current thought is something along the lines of, like:
18:05:54 <jessicathegunlady> Say we give Scripts a 'ScriptType' property when declared, or perhaps an array.
18:05:54 <jessicathegunlady> This ScriptType is an array that determines what part of the API a script has access to.
18:05:54 <jessicathegunlady> If two scripts use the same ScriptType, they're incompatible. Maybe a script can have a list of "these are the types I need for base functionality", and a list of "these are extra features I can do without".
18:05:54 <jessicathegunlady> - If two scripts collide on "mandatory" types, mutually assured destruction.
18:05:55 <jessicathegunlady> - If two scripts collide on "optional" types, their access to the API concerning that ScriptType is removed. A script should have an easy way to check if it has access to a type to toggle on or off excess functionality.
18:05:55 <jessicathegunlady> - I'm thinking optional types could have some way to be toggled on or off, so that users can go in to a script's settings menu and adjust features in there.
18:05:57 <jessicathegunlady> I'm struggling to think of how compatibility could be negotiated between two scripts, especially since there needs to be a good way to ensure the two *versions* of the scripts are compatible, and my brain is already full before I've even *started* to think about this. I need to send the message at some point, so.
18:06:45 <DorpsGek> [OpenTTD/OpenTTD] Rito13 commented on pull request #14637: Feature: Reward or fine at the end of engine preview. https://github.com/OpenTTD/OpenTTD/pull/14637#issuecomment-3315146538
18:09:30 <truebrain> I think you are overestimating who writes GSes πŸ™‚ But I can be wrong πŸ˜„
18:09:52 <jessicathegunlady> Oh, quite possibly.
18:10:08 <jessicathegunlady> I've worked on my own GS in pretty much complete isolation from any other GS authors.
18:10:09 <truebrain> Most already have a hard time creating an event-loop, we figured out πŸ™‚
18:10:14 <truebrain> (no offense to anyone, just what it is)
18:10:31 <jessicathegunlady> ...To be fair, there isn't exactly a lot of great documentation out there.
18:10:37 <truebrain> So any part where you hope the script would detect that functionality is disabled and deals with that properly .... I don't think that is going to happen πŸ™‚
18:10:45 <truebrain> I do not disagree πŸ™‚
18:11:09 <truebrain> But the main thing with your reasoning: their GS will work fine without any other GS loaded. So they will never see the issues.
18:11:11 <jessicathegunlady> I'd like to work on improving documentation for sure. But you do make a good point, maybe my idea has limited applicability overall.
18:11:20 <truebrain> That is where the other ideas come from, to guide that a lot more
18:11:43 <truebrain> Making it a more reactive programming language, in a sense
18:12:16 <jessicathegunlady> Aye, I get what you're saying.
18:14:21 <jessicathegunlady> Suppose it might make more sense to implement a simpler solution like the hard divisions that were mentioned before.
18:15:34 <jessicathegunlady> Worst case scenario, more complex options get implemented down the line if multiple GS authors *do* want to cooperate on this kind of front.
18:18:18 <jessicathegunlady> My primary experience comes from modding specific Unity games where usually there's multiple people developing things who are largely reasonable, and generally very competent with the language they're using.
18:18:38 <truebrain> And now I can say: welcome to our little garden πŸ˜„
18:19:28 <jessicathegunlady> *yep*
18:19:30 <jessicathegunlady> I love it.
18:19:32 <jessicathegunlady> Strict binary.
18:19:46 <jessicathegunlady> People who can barely put a script together VS people who work with C++ for their day job.
18:20:55 <rito12_51026> I have an irrelevant question, is this code snippet clear? :
18:20:55 <rito12_51026> `
18:20:55 <rito12_51026> {
18:20:55 <rito12_51026> &a0 &a1 * #2 &a2 * #2 6 - #2 Bool #1 ! #1
18:20:55 <rito12_51026> &a2 &a3 * #2 &a4 * #2 8 - #2 Bool #1 ! #1
18:20:56 <rito12_51026> and #2
18:20:56 <rito12_51026> &a0 &a1 &a2 &a3 &a4 print %5
18:20:58 <rito12_51026> if #2
18:20:58 <rito12_51026> &a2 Bool #1
18:21:00 <rito12_51026> &a0 &a1 &a2 1 - #2 &a3 &a4 f %5
18:21:00 <rito12_51026> if #2
18:21:02 <rito12_51026> &a1 Bool #1
18:21:02 <rito12_51026> &a0 &a1 1 - #2 &a2 &a3 &a4 f %5
18:21:04 <rito12_51026> if #2
18:21:04 <rito12_51026> &a0 Bool #1
18:21:06 <rito12_51026> &a0 1 - #2 &a1 &a2 &a3 &a4 f %5
18:21:06 <rito12_51026> if #2
18:21:08 <rito12_51026> &a3 Bool #1
18:21:08 <rito12_51026> &a0 &a1 &a2 &a3 1 - #2 &a4 f %5
18:21:10 <rito12_51026> if #2
18:21:10 <rito12_51026> &a4 Bool #1
18:21:12 <rito12_51026> &a0 &a1 &a2 &a3 &a4 1 - #2 f %5
18:21:12 <rito12_51026> if #2
18:21:14 <rito12_51026> } f ( Int Int Int Int Int ) &Void
18:21:14 <rito12_51026> 3 3 3 2 2 f #5
18:21:16 <rito12_51026> `
18:21:51 <jessicathegunlady> I don't understand it in the slightest. But I also don't have any surrounding context either, so...
18:22:55 <rito12_51026> Here is the same code but written in python:
18:22:55 <rito12_51026> `def f(a,b,c,d,e):
18:22:55 <rito12_51026> if(not(a*b*c - 6) and not(c*d*e - 8)):
18:22:55 <rito12_51026> print(a,b,c,d,e)
18:22:55 <rito12_51026> if(a):
18:22:56 <rito12_51026> f(a-1,b,c,d,e)
18:22:56 <rito12_51026> if(b):
18:22:58 <rito12_51026> f(a,b-1,c,d,e)
18:22:58 <rito12_51026> if(c):
18:23:00 <rito12_51026> f(a,b,c-1,d,e)
18:23:00 <rito12_51026> if(d):
18:23:02 <rito12_51026> f(a,b,c,d-1,e)
18:23:02 <rito12_51026> if(e):
18:23:04 <rito12_51026> f(a,b,c,d,e-1)
18:23:04 <rito12_51026> f(3,3,3,2,2)`
18:23:13 <truebrain> jessicathegunlady: What might be good for your context: more than one person, even some devs, learnt to program because they wrote AI/GS.
18:23:45 <jessicathegunlady> Oh, nice.
18:23:57 <jessicathegunlady> I didn't mean what I said seriously, to be clear.
18:24:32 <truebrain> Well, I meant more: you are not far off πŸ™‚
18:24:51 <truebrain> More than one person started with zero programming knowledge, and years later are programmers πŸ˜›
18:30:30 <rito12_51026> truebrain: _That would be me_
18:37:45 <andythenorth> does nml have some way of declaring global params (not constants)?
18:37:51 <andythenorth> and not action 14 params
18:38:28 <andythenorth> is that what action D does?
18:45:59 <andythenorth> seems I can just declare them inline
18:46:52 *** Tirili has joined #openttd
18:47:12 <talltyler> I’d never really written code before I picked up NML to make GRFs, then C++ to fix some things in OpenTTD
18:53:40 <mmtunligit> i keep poking my head into the repos to try and figure out how something works and im worried that ill poke through one of these days and end up actually doing something
18:53:59 <truebrain> Case and point(s) πŸ˜„
18:54:32 <jessicathegunlady> truebrain: Aaaah, right, gotcha.
18:56:24 <jessicathegunlady> I definitely appreciate ways that people can get in to programming in ways that are easier.
19:00:14 <yiffgirl> https://cdn.discordapp.com/attachments/1008473233844097104/1419035443164614727/image.png?ex=68d04b3e&is=68cef9be&hm=e67099091b173654fbb679a600232db93d8b1fab7251eb10e7715bdaa8f10aac&
19:00:34 <yiffgirl> thoughts
19:01:30 <truebrain> "grows faster than normal" ... WHAT IS NORMAL?! πŸ˜„
19:01:49 <jessicathegunlady> I think info like that should generally be placed at the bottom. I also feel like it's a bit... Bloated?
19:02:55 <locosage> I think it should be placed at the wiki :p
19:03:09 <jessicathegunlady> My impulse for implementing a feature like this is to change the 'Town is growing x' stat. Add a city icon somewhere in it, and put an underline beneath the number. When a user hovers over it, they see an explanation for the unusual icon.
19:03:28 <jessicathegunlady> locosage: Also not an unreasonable idea.
19:03:29 <truebrain> Tooltips? How modern! πŸ˜„
19:03:54 <truebrain> (to me it is funny how UI design changed in the last 20 years)
19:03:54 <jessicathegunlady> *...good point. my brain forgets 'oh, this is just a common thing we have a name for'*
19:04:28 <truebrain> These days if we see something with a line under it, we hover it and expect a tooltip. But that is relatively recent in UI design πŸ™‚
19:04:39 <locosage> detailed breakdown on town growth speed in the tooltip might be a decent idea
19:04:46 <locosage> like patchpacks do for station rating
19:04:53 <andythenorth> info like that should be added by GS πŸ˜›
19:05:09 <yiffgirl> andythenorth: πŸ—žοΈ
19:05:26 <jessicathegunlady> yeah, we're changing the original game, which we can and will never do, as it is forbidden by law
19:05:28 <locosage> andythenorth: well, if gs is the one controlling growth speed...
19:06:38 <andythenorth> https://cdn.discordapp.com/attachments/1008473233844097104/1419037054649765928/image.png?ex=68d04cbe&is=68cefb3e&hm=b745c72bb72bd53fada4dd7e03211525e9107c30f591fefaa5bf47b41b5665fe&
19:06:52 <yiffgirl> oh, you mean... yes, i guess that makes sense. hitting you with a newspaper rescinded
19:07:10 <andythenorth> displaying a fixed growth string in the core client limits what GS can do
19:07:22 <andythenorth> a GS might have other ideas about 'city'
19:07:28 <truebrain> Why is this town unhappy? What did we do to the town to make it unhappy? Poor town. Can we make it happy?
19:07:37 <andythenorth> MarvinTown
19:07:55 <jessicathegunlady> andythenorth: Good point, honestly. A GS may override it. Then the tooltip only adds confusion, unless the GS is given a way to override it.
19:07:56 <yiffgirl> in my defence i *was* asked to do this.
19:08:18 <andythenorth> yiffgirl: entirely normal way to develop anything here πŸ˜›
19:08:28 <andythenorth> as many opinions as bumholes πŸ™‚
19:08:31 <yiffgirl> true that
19:08:52 <jessicathegunlady> ~~This is why you consult me. I'm an opinion generating machine. It's what I was born for.~~
19:09:26 <yiffgirl> and of course, you only get feedback once you show yours off.
19:09:26 <yiffgirl> ...wait, that's not how the saying goes...
19:09:31 <truebrain> jessicathegunlady: For some reason I now expect you to output `42` on every next question πŸ˜›
19:09:51 <jessicathegunlady> lmao
19:11:14 <yiffgirl> well, i should probably still pr the window title change. nobody complained about that part
19:12:20 <jessicathegunlady> Aye. Personally I feel the icon should come before the name, but even just having an icon is a plus to me.
19:15:24 <andythenorth> hmm railtypes then
19:15:57 <andythenorth> I think I've got an implementation where Iron Horse disables railtypes if another grf defines it
19:16:12 <andythenorth> I'm only doing this to stop people whining about not having being able to use all 64 slots
19:16:33 <andythenorth> I wonder if it would be better to wait for that problem to go away
19:17:56 <yiffgirl> https://cdn.discordapp.com/attachments/1008473233844097104/1419039896865210490/image.png?ex=68d04f63&is=68cefde3&hm=768c9ae31fa08031cc71bec30c3d658693c7a20ca3b3003712a6fb8e410809cd&
19:17:56 <yiffgirl> jessicathegunlady: here's what that looks like. personally i prefer it like this too, but it *is* inconsistent...
19:17:56 <yiffgirl> i suppose we'll have to see what folks in here prefer
19:19:45 <jessicathegunlady> Oh wait, is the city icon at the end of the city's name a thing in v15 overall?
19:21:00 *** Wormnest has quit IRC (Quit: Leaving)
19:36:02 <DorpsGek> [OpenTTD/OpenTTD] Rau771 commented on pull request #14636: Feature: Alternate station rating algorithm https://github.com/OpenTTD/OpenTTD/pull/14636#issuecomment-3315193781
19:38:16 *** Tirili has quit IRC (Remote host closed the connection)
19:39:54 *** Tirili has joined #openttd
19:42:10 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic merged pull request #14606: Codechange: Use YAPF for river builder pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14606
19:44:21 <kuhnovic> And with that we got of another pathfinder
19:44:35 <andythenorth> \o/
19:44:49 <yiffgirl> jessicathegunlady: yes, i was the one who did that =p https://github.com/OpenTTD/OpenTTD/pull/14504
19:44:49 <yiffgirl> i didn't draw or add the icon myself though, that was zephyris and peter respectively
19:45:09 <jessicathegunlady> Oooh.
19:45:25 <jessicathegunlady> I haven't played on v15 yet. Me likey very much.
19:48:02 <yiffgirl> i originally wanted it to also show up when you were zoomed very far out, but it's still better than no indication at all
19:54:20 <michi_cc> kuhnovic: So we can start writing ENPF now? 🀣
19:55:27 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on pull request #14603: Change: Add lock penalty to ship pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14603#pullrequestreview-3249221384
19:57:09 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #14603: Change: Add lock penalty to ship pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14603
19:58:08 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on pull request #14603: Change: Add lock penalty to ship pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14603#pullrequestreview-3249221945
19:58:28 <kuhnovic> michi_cc: YOLOPF
19:58:38 <andythenorth> LLMPF
19:59:59 <kuhnovic> There must be a suitable german word that already ends with PF.
20:00:39 <michi_cc> German words? Definitely. Suitable? Well...
20:00:40 <andythenorth> LOLPF
20:00:52 <kuhnovic> SchwanzkoPF ? Maybe not
20:01:16 <michi_cc> dickhead? 🀣
20:01:32 <kuhnovic> Hence the maybe not πŸ˜›
20:01:47 <michi_cc> Well, Dampf (steam) is probably the best one.
20:02:14 <kuhnovic> That's actually a very good one
20:02:33 <kuhnovic> It better be dam fast then
20:04:47 <andythenorth> how did we go so long without sticky menus? πŸ˜›
20:04:51 <andythenorth> like 30 years
20:05:04 <andythenorth> I only just noticed that I didn't notice the change
20:13:21 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:21:59 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #14638: Codechange: Refactor station rating code slightly and add comments https://github.com/OpenTTD/OpenTTD/pull/14638#pullrequestreview-3249245762
20:24:21 <DorpsGek> [OpenTTD/OpenTTD] Rau771 commented on pull request #14636: Feature: Alternate station rating algorithm https://github.com/OpenTTD/OpenTTD/pull/14636#issuecomment-3315239487
20:24:55 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #14603: Change: Add lock penalty to ship pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14603#pullrequestreview-3249246329
20:26:34 *** WormnestAndroid has joined #openttd
20:31:44 *** SigHunter has quit IRC ()
20:34:29 *** SigHunter has joined #openttd
20:36:51 *** SigHunter has quit IRC ()
20:38:56 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:39:59 *** WormnestAndroid has joined #openttd
20:44:14 *** SigHunter has joined #openttd
20:50:01 *** SigHunter has quit IRC ()
20:53:03 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic merged pull request #14603: Change: Add lock penalty to ship pathfinder. https://github.com/OpenTTD/OpenTTD/pull/14603
20:57:04 *** SigHunter has joined #openttd
21:01:35 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #14637: Feature: Reward or fine at the end of engine preview. https://github.com/OpenTTD/OpenTTD/pull/14637#issuecomment-3315255270
21:06:11 *** tokai|noir has joined #openttd
21:06:11 *** ChanServ sets mode: +v tokai|noir
21:12:46 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic opened pull request #14640: CodeChange: Simplified structure of yapf_ship_regions. https://github.com/OpenTTD/OpenTTD/pull/14640
21:12:49 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on pull request #14637: Feature: Reward or fine at the end of engine preview. https://github.com/OpenTTD/OpenTTD/pull/14637#issuecomment-3315262122
21:12:50 *** SigHunter has quit IRC ()
21:13:05 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:13:29 <andythenorth> naptime?
21:13:35 <andythenorth> or 65k railtypes?
21:19:56 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #14640: CodeChange: Simplified structure of yapf_ship_regions. https://github.com/OpenTTD/OpenTTD/pull/14640#pullrequestreview-3249280341
21:20:12 *** SigHunter has joined #openttd
21:27:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #14640: CodeChange: Simplified structure of yapf_ship_regions. https://github.com/OpenTTD/OpenTTD/pull/14640#pullrequestreview-3249287907
21:31:29 *** andythenorth is now known as Guest26989
21:31:30 *** Guest26989 is now known as andythenorth[d]
21:31:30 *** andythenorth has joined #openttd
21:31:40 <andythenorth> :o my irc client still works
21:35:28 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #14633: Fix #14631, Fix 1cb0cbcb6c: Waypoint customs spec not allocated properly on initial construction. https://github.com/OpenTTD/OpenTTD/pull/14633#pullrequestreview-3249289798
21:36:13 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:40:56 *** lobster has joined #openttd
21:43:17 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #14640: CodeChange: Simplified structure of yapf_ship_regions. https://github.com/OpenTTD/OpenTTD/pull/14640
21:44:19 *** andythenorth has left #openttd
21:45:12 <andythenorth[d]> ok naptime
21:45:16 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic updated pull request #14640: CodeChange: Simplified structure of yapf_ship_regions. https://github.com/OpenTTD/OpenTTD/pull/14640
21:45:56 <peter1138> Right that thing about compatible railtypes wouldn't work because the compatible type also has to exist.
21:48:56 <andythenorth[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1419077896865058927/image.png?ex=68d072c7&is=68cf2147&hm=cf9c9f5fa3595b9e25b3197c5bf0eb3b605e93c9489301ed9dd00aadca447383&
21:48:56 <andythenorth[d]> unrelated, but I wonder if we took a left turn somewhere πŸ™‚
21:49:18 <andythenorth[d]> this is gold standard compatibility
21:49:38 <kuhnovic> This is art
21:49:58 <andythenorth[d]> it's not even completionist, this is just scratching the surface
21:50:06 <andythenorth[d]> (it's not mine)
21:50:50 <andythenorth[d]> doesn't even support all the axle loads it's supposed to
21:50:59 <andythenorth[d]> nor the secondary AC and DC voltages
21:51:07 <andythenorth[d]> nor 4th rail
21:52:29 <andythenorth[d]> no to be fair, those aren't included in this grf, so that's not valid critique
21:53:19 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:53:54 *** dh1 has joined #openttd
21:56:03 <peter1138> > Error renaming openttd.new to openttd.grfCMake Error at /home/petern/src/openttd/cmake/scripts/CreateGRF.cmake:61 (message): GRFCodec failed
21:56:10 <peter1138> Hmm, not seen that before :o
22:16:11 <andythenorth[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1419084755370115112/image.png?ex=68d0792b&is=68cf27ab&hm=9b6e2fdc7d093a1b82bc1d5d1f36bb936498a2ea7dc6cda38037eefa57fbbaf0&
22:16:11 <andythenorth[d]> is this more grf string colour mangling, or is it an openttd change that detects electrified railtypes?
22:16:28 <andythenorth[d]> think it's the U&ReRMM grf
22:16:33 <peter1138> GRFs being GRFs.
22:16:34 <andythenorth[d]> not terminating colour code
22:16:47 <peter1138> There's a PR that probably fixes it but not sure.
22:18:01 <andythenorth[d]> I was going to bed πŸ˜›
22:18:14 <andythenorth[d]> but now more railtpyes stuff turned up πŸ˜›
22:19:13 <andythenorth[d]> railtype grfs tend to redefine `RAIL` to be the lowest speed option
22:19:29 <andythenorth[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1419085588040257587/image.png?ex=68d079f1&is=68cf2871&hm=8838f42be2a76adbfd5608358c88ed4a8a12246ae373a6c55bafc510c72fbc08&
22:19:29 <andythenorth[d]> which makes the value for 'Rail types:' here entirely correct, but confusing to players
22:19:37 <andythenorth[d]> 🀷
22:20:11 <jessicathegunlady> We love development work giving excuses to stay up way too late.
22:20:34 <andythenorth[d]> did I have wine?
22:20:43 <andythenorth[d]> if I did, I've forgotten
22:20:54 <jessicathegunlady> ...Don't think you mentioned it if you did.
22:21:12 <peter1138> Is anyone using badges on railtypes for things like gauge yet?
22:21:27 <peter1138> (Of course not.)
22:22:16 <andythenorth[d]> I have...ideas 😐
22:22:25 <andythenorth[d]> but not for gauge
22:22:29 <andythenorth[d]> "that would be silly"
22:24:00 <andythenorth[d]> inside the Horse compile, there's a a base track type, which equates to 'gauge + loading gauge yada yada'
22:24:15 <andythenorth[d]> then it has capabilities, like 'electrified' and 'very high speed'
22:25:12 <andythenorth[d]> railtype classes? πŸ˜›
22:32:40 <andythenorth[d]> lol 3 of the 'Horse must be made compatible with these' railtype grfs don't follow the standardised scheme
22:33:17 <andythenorth[d]> wow, that sounds way more bitter than I intended πŸ™‚
22:33:31 <andythenorth[d]> some people have made some honest mistakes, then possibly copied each other πŸ™‚
22:36:03 <yiffgirl> andythenorth[d]: are the maintainers in here / active? if it's a mistake i'm sure they'd be happy to correct it.
22:36:03 <yiffgirl> or elaborate on why it's intended
22:36:25 <jessicathegunlady> I mean, I don't think *anyone* in these kinds'a cases are *deliberately* choosing it. It's just poor communication of intent.
22:36:28 <andythenorth[d]> it's more of an Discord channel #add-on-development topic
22:36:34 <jessicathegunlady> True.
22:37:18 <andythenorth[d]> it's just a failure to read the spec
22:37:31 <andythenorth[d]> easily done
22:38:00 <jessicathegunlady> Aye. Ill consideration, mayhaps.
22:47:42 *** sdfsdfsdf has joined #openttd
22:48:03 *** sdfsdfsdf has quit IRC ()
23:01:55 <peter1138> Ill communication
23:08:32 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
23:13:12 <andythenorth[d]> Sabotage
23:15:20 <peter1138> What exactly is the "Candidate: needs considering" label for?
23:15:36 <peter1138> Do we don't consider (however briefly) all PRs?
23:15:40 <peter1138> ...
23:15:43 <peter1138> Do we not consider (however briefly) all PRs?
23:22:42 <talltyler> I apply it to my own PRs to mean β€œdon’t be afraid to tell me this is a terrible idea” πŸ˜›
23:23:46 <talltyler> And/or β€œneeds opinions from multiple people, not just a code review”
23:24:34 <peter1138> Well in my mind it means "We really REALLY ought to consider this as a candidate for merging"
23:24:49 <peter1138> Which is a bit... weird to have, let alone self-apply.
23:25:37 <talltyler> The helptext for the label says opinions required, no? We have another label β€œcandidate: yes” which I would never self-apply πŸ™‚
23:26:09 <talltyler> β€œNeeds considering whether we actually want this” is how I interpret it πŸ™‚
23:28:44 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler merged pull request #14638: Codechange: Refactor station rating code slightly and add comments https://github.com/OpenTTD/OpenTTD/pull/14638
23:30:31 <peter1138> Opinions are always required.
23:32:13 <peter1138> There's also no need for the "draft" label, because the PR itself is already a draft.
23:34:21 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:36:48 *** WormnestAndroid has joined #openttd
23:56:31 *** Flygon has joined #openttd