IRC logs for #openttd on OFTC at 2024-04-06
⏴ go to previous day
00:08:16 <Eddi|zuHause> we probably had enough of those :p
00:10:35 *** Tirili has quit IRC (Remote host closed the connection)
00:32:59 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
01:38:37 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
01:54:30 *** Tirili has quit IRC (Quit: Leaving)
01:56:32 *** Wormnest has joined #openttd
02:09:12 *** bertvvvs has quit IRC (Quit: You have a nice day.)
02:36:17 *** Wormnest has quit IRC (Quit: Leaving)
02:50:03 *** gnu_jj_ has joined #openttd
02:53:11 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:58:40 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:18:22 *** Smedles has joined #openttd
03:48:23 <locosage> peter1138: it would be useful to have a buy limit for every vehicle controllable with gs
04:41:31 <DorpsGek> - Update: Translations from eints (by translators)
06:16:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:22:32 <peter1138> That's a big list to control
06:22:50 <peter1138> With no meaningful way to know what they are.
06:34:11 *** keoz has quit IRC (Ping timeout: 480 seconds)
06:37:25 <andythenorth> peter1138: Just generate the GS alongside the grf…then use engine ID
06:52:46 <pickpacket> the forums are broken 😢
07:49:08 *** HerzogDeXtEr has joined #openttd
07:56:37 *** SigHunter has joined #openttd
08:13:56 <kamnet> The forums are again unbroken.
09:11:30 <xarick> so I tested 10000, I find no ships in limbo
09:11:51 <xarick> 10000 is sufficiently big enough of a penatly
09:15:45 <xarick> okay, the other problem I have is service at nearest depot having not enough range to find a depot 😦
09:15:53 <xarick> but that's unrelated to 12335
09:32:22 <kuhnovic> That's something else, which we both have unfinished PRs for 😉
10:42:12 <xarick> 5000 tested, it's sufficient too
10:42:26 <xarick> I think the reasoning is
10:43:15 <xarick> (region size + region size) * tile cost
10:43:34 <xarick> anything above 3200 seems to be a safe bet
10:43:59 <xarick> to account for 1 region discrepancy
10:44:48 *** gelignite has joined #openttd
10:48:12 <xarick> walking from 1 intermediate region to another is only 16 * 100
10:51:01 *** tateisukannanirase has joined #openttd
10:51:01 <tateisukannanirase> Does YAPF always just follow the least costly path every time?
10:55:16 <truebrain> Unless it goes on strike
10:57:21 <tateisukannanirase> it's French?
10:59:54 <reldred> Is your car on fire and upside down in the street? If so then yes.
11:00:38 <_glx_> No need for a strike for that
11:00:53 <tateisukannanirase> Well it's an RV and there's lots of black smoke 😄
11:05:57 <andythenorth> kamnet: I don't see an iOS version via the alternative app stores being viable
11:06:22 <andythenorth> the CTF is likely to be triggered, and unless we charge for OpenTTD, it's not affordable afaict
11:06:36 <andythenorth> and we're not likely to charge for OpenTTD
11:14:05 <FLHerne> I don't, personally, think that charging 50p specifically to cover that would be unreasonable
11:14:27 <FLHerne> but are there alternate app stores that would allow GPL compliance?
11:14:57 <FLHerne> tateisukannanirase: yes, but a lot of factors are included in 'cost'
11:15:20 <andythenorth> Apple should never have allowed the previous OpenTTD, "no GPL" is their own policy
11:15:33 <kamnet> andythenorth: You can sideload without an Appstore. But there's no reason an iOS developer could not charge a small fee for making it easier to do through an app store. I don't see this as a barrier.
11:15:58 <FLHerne> see all the yapf.*_penalty = 200 entries in openttd.cfg
11:15:59 <andythenorth> it's a tall poppy issue
11:16:24 <andythenorth> having a product for sale raises the chances of a copyright strike / claim / case
11:17:24 <kamnet> That's an issue that's always existed, though.
11:18:09 <kamnet> Who knows what that previous developer licensed as in order to get Apple approval. and nobody knows what happened to get the app removed, either.
11:23:14 *** georgevb has joined #openttd
11:23:14 <georgevb> peter1138: We just need a better way to manage appearing and disappearing of models, and you would have about 2 available at the time 😉
11:23:50 *** gelignite has quit IRC (Quit: Stay safe!)
11:23:54 <tateisukannanirase> flherne: thanks. I have been working a bit on refining OneTileCost for road vehicles, but I have not yet put any thought into what happens downstream of that function.
11:24:34 <peter1138> georgevb: Yea, my bad I had never expire on as I was testing the tree
11:24:35 <xarick> 3000 tested, it's also sufficient. no ships in limbo
11:24:56 <peter1138> Xussr is very useful for that 🙂
11:25:20 <xarick> I expect to find issues now
11:25:22 <FLHerne> There's a certain amount of caching, which shouldn't normally be an issue, but it might get stale if you're trying to implement dynamic costs of some kind
11:26:25 <peter1138> With #12434 it looks a lot better
11:26:34 <georgevb> But a better way to manage appearing and disappearing models from the menu is thinh, I miss a lot
11:26:38 <tateisukannanirase> flherne: at the moment I'm just trying to reform the calculation of the occupied level of drive through stops and I haven't noticed any caching yet.
11:27:06 *** gelignite has joined #openttd
11:28:05 <georgevb> I just wish to say "appear at" "disappear at" and not to have any change. In case random is needed, may be GRF should be able to do it on its side
11:30:16 <FLHerne> tateisukannanirase: https://github.com/OpenTTD/OpenTTD/issues/7592 is the kind of thing I was thinking of, and the "Do not cache road vehicle path within 8 tiles of destination with multiple entrances" commit that 'fixes' it is probably why you're not seeing an effect
11:30:59 <FLHerne> (that seems a bit hacky to me, but should work for most sane road layouts)
11:32:15 <andythenorth> georgevb: you can sync multiple vehicles, but no way to prevent the random jitter
11:33:58 <georgevb> And that is a huge problrm for xUSSR set, wich I wish to be solved someday
11:36:24 <andythenorth> why is random a problem? 🙂
11:37:24 <peter1138> It's basically a realism set with actual dates, I think.
11:38:54 <peter1138> RV path cache is cleared near the destination so that road stop availability can be taken into account. I think it also doesn't clear it if there's only 1 drive-In stop
11:40:22 <peter1138> Clearing the cache isn't really a hack. Having the path cache at all is the real hack.
11:40:35 <peter1138> But it helps so much with performance
11:43:40 <tateisukannanirase> Interesting, the tt-forums thread linked in that issue is interesting. Load balancing in stations is something I want to improve, by enycouraging vehicles to use the back-side of drive-through stops. Mixed success, however. It's surprising how well the basic weighting, however crude you think it is, works.
11:46:26 <georgevb> andythenorth: because the model, that came 1 year earlier can appear 1 year later.
11:46:26 <georgevb> An other problem is model lyfe. Current game engine expects that model is available 8 years or longer, while we have models that were available only in a sertain year.
11:47:07 <truebrain> someone went gravedigging
11:48:17 <andythenorth> georgevb: you've ruled out designing the grf to fit OpenTTD? Rather than expecting OpenTTD to support the grf?
11:49:18 <FLHerne> peter1138: fair point
11:51:24 <georgevb> I expect compromises are possible on both the sides.
11:51:24 <georgevb> GRFs development requests are one of the main sources for OpenTTD to enhance and extend.
11:55:36 <georgevb> We have gathered here not to argue, but to find mutually beneficial solutions.
11:57:03 <FLHerne> Frankly I find all the interconnected model life and reliability a bit weird
11:57:36 <FLHerne> why can't there just be callbacks for "is this vehicle available now?" and "how reliable is it?"
11:58:57 <FLHerne> set authors usually have a good idea of the results they want, and then waste time reverse-engineering parameters to get that
12:00:27 <andythenorth> reasons have been advanced before, but I don't remember them
12:00:45 <andythenorth> it's the kind of thing, where if it was technically possible, surely it would have been done by now?
12:01:09 <andythenorth> isn't it impossible to have an availability callback?
12:01:14 <andythenorth> due to circularity
12:01:50 <emperorjake> The fact that intro dates are randomised gives no incentive for coding accurate dates, because they'll just be randomised anyway. So it's always just 19XX-01-01
12:02:34 <Eddi|zuHause> the whole phase and early retirement thing is a pile of wtf
12:02:55 <emperorjake> I would also support non-randomised intro dates, as it's become more important now that the game supports much longer timescales
12:03:35 <Eddi|zuHause> i don't think puting the GRF in charge of the randomisation is the correct solution
12:03:47 <emperorjake> waiting on that 18 month randomised delay becomes a lot longer when a game year lasts a real week
12:04:03 <andythenorth> oh also it was a policy that this should be GS
12:04:14 <andythenorth> because GRF doesn't have global view of game state
12:04:28 <andythenorth> the proper domain was GS
12:04:36 <andythenorth> but that argument took place 12 years ago, and here we are
12:04:53 <Eddi|zuHause> you can put it in a setting...
12:05:17 <FLHerne> Eddi|zuHause: why not? it can be as random as the author wants
12:05:24 <andythenorth> we have engine availability already in GS, why is this even an issue now?
12:05:37 <Eddi|zuHause> FLHerne: but it should be as random as the PLAYER wants
12:06:19 <Eddi|zuHause> because things like "the game year takes a week" is a player choice, not an author choice
12:06:39 <andythenorth> it's solvable in GS, therefore it's a content problem, not an OpenTTD problem
12:06:49 <FLHerne> Trying to keep things out of grf control has consistently proven to be a design mistake, IMO
12:07:15 <andythenorth> don't trust grf authors
12:07:17 <Eddi|zuHause> the bigger design mistake would be putting competing concepts in control
12:07:54 <FLHerne> grf authors always want the control anyway, and just do it in needless complicated ways because that's all that's available
12:08:34 <andythenorth> 'policy is to move extending the game to content', but 'every content extension must be debated by core devs and hangers on, as to whether it's valid gameplay'
12:08:40 <andythenorth> "I see no conflict there"
12:09:05 <FLHerne> GS as a whole is probably a design mistake, but GS controlling features of a particular grf is definitely a design mistake :p
12:09:17 <Eddi|zuHause> who in this debate is a "core dev"?
12:09:36 <Eddi|zuHause> definitely not me
12:09:36 <andythenorth> I'm "hangers on"
12:09:58 <andythenorth> I feel it might be lunch
12:10:29 <andythenorth> bad andythenorth seems to be out of his box
12:11:09 <andythenorth> next I'll be digging up the transcript where the GS <-> GRF argument was won (or lost)
12:11:17 <andythenorth> a nice sandwich perhaps?
12:12:31 <locosage> FLHerne: and having to fork every freaking grf to configure a server is definitely not a "design mistake" 😜
12:12:37 <Eddi|zuHause> andythenorth: i think that argument once was "won" by "let's make a hybrid", which then never happened
12:12:48 <andythenorth> I made a hybrid FIRS
12:12:56 <Eddi|zuHause> no, long before that
12:13:24 <andythenorth> TB wrote a spec 🙂
12:14:33 <andythenorth> hmm youtube...I only have to hover over the wrong video about marriage comedy, and for the next week I'm hitting "don't recommend" on manosphere red pill sigma crap
12:14:52 <andythenorth> really quite rapid
12:30:35 <xarick> confirmed! 1500 is a too low penalty
12:39:38 <peter1138> andythenorth: Fried salad
12:39:57 <peter1138> PeterNviaGitHub: j_n Asasignals will be affected by this.
12:41:17 <peter1138> Cheese hot x bun for me.
12:43:09 <Eddi|zuHause> that doesn't look like a full meal
12:43:35 <andythenorth> it meets lunch criteria
12:43:50 <andythenorth> obviously the chips are omitted, so it wouldn't count as dinner
12:44:24 <peter1138> Too easy to eat too much. Especially after bike ride.
12:45:00 <andythenorth> what shall we make Flat today?
12:46:14 <peter1138> I've got a Jillian Michaels video somewhere for some reason...
12:48:42 <andythenorth> VariantContainer things?
12:49:15 <andythenorth> becomes this after building a few
12:49:34 <andythenorth> so the folded buy menu changes from
12:49:52 <LordAro> peter1138: is it windy down south as well?
12:50:05 <andythenorth> it's getting windy where I am
12:50:14 <LordAro> nothing like 12mph @ 300W
12:50:15 <peter1138> It's almost like the Blaze HST coaches shouldn't be a variant of the Blaze HST engines.
12:50:25 <andythenorth> "one considers that option"
12:50:50 <peter1138> I have no power meter, so I don't know.
12:51:10 <LordAro> neither do i, but it's what one of the others said
12:51:26 <andythenorth> it's convenient to group them together, and I _think_ I rely on them being variants to sync the availability
12:51:31 <peter1138> Ah. I take that with a pinch of salt, being 6'6" and somewhat heavier than them 😄
12:51:56 <peter1138> andythenorth: Fair, I guess it would otherwise be separated by the engine / wagon split.
12:52:10 <LordAro> peter1138: i imagine everyone ends up trying to hide behind you
12:52:14 <peter1138> Especially on a windy day. Difficult to tuck in when everyone is a foot shorter...
12:52:56 <andythenorth> peter1138: yup. I rely on VEHICLE_FLAG_SYNC_VARIANT_EXCLUSIVE_PREVIEW as well
12:53:03 <andythenorth> otherwise engine, but no coaches
12:53:09 <peter1138> Skipped the last couple of hills today as my knee is playing up (after I injured it on Wednesday)
12:53:27 <andythenorth> not sure if wagons actually respect exclusive preview 😛
12:53:30 <LordAro> mine's been making some funny noises in the last couple of weeks
12:53:40 <LordAro> which is decidedly unfun 10 days before Mallorca
12:54:05 <LordAro> really don't want a repeat of last year
12:54:32 <peter1138> Going away on a cycling trip and having to spend it all at the beach sounds like a terrible idea.
12:54:50 <peter1138> (No, beach holidays don't appeal to me either, heh)
12:54:52 <xarick> too many trains in a certain newgrf
12:55:10 <LordAro> not when i'm spending €lots on bike hire
12:55:13 <peter1138> Wait til you see what regular players do with NewGRFs.
12:55:22 <andythenorth> 6000 variant name switches 😛
12:55:27 <xarick> makes my AI testing engine/wagon attachments take 10 years
12:55:33 <peter1138> Not just one. Not just two. Dozens of vehicle NewGRFs.
13:14:24 <_glx_> xarick: that's why I recommend you to just check newgrf id and provide a reduced set of working engine/wagons combo
13:21:08 <andythenorth> I wonder about GRF <-> GS comms 😛
13:29:02 <peter1138> Hmm, CZTR bridges fails due to #12435, but I think it is actually bugs in the NewGRF.
13:29:58 <peter1138> It reserves 4 chunks of 24 sprite IDs, but then tries to use them either in one block, or goes outside its reserved range.
13:30:20 <peter1138> Reserves 24, gets 6212, tries to use 6212+44.
13:31:13 <peter1138> So perhaps it's too strict right now.
13:31:22 <_glx_> CHIPS nfo version reserves a lot 🙂
13:31:31 <peter1138> Reserving a lot and using them correctly is fine.
13:32:06 <peter1138> GRM sprites doesn't HAVE to guarantee the reserved range is contiguous, but it will be. But this NewGRF just assumes it is.
13:33:55 <peter1138> Yeah, no warnings with chips.
13:34:18 <peter1138> Maybe instead of checking GRM reservations it's simply enough to check if a sprite does not already exist (if it's outside the baseset range)
13:36:57 <peter1138> Actually I should read the spec before asserting that 🙂
13:39:07 <peter1138> Doesn't say either way.
13:39:24 <peter1138> Modular Wider Bridges reserves a single sprite ID, and just uses that as a base offset.
13:47:59 <xarick> oh wow, 2000 was not sufficient...
13:48:13 <xarick> got 3 companies with limbo ships
13:50:03 <peter1138> Ah no, my debug output is wrong 😄
13:51:04 <peter1138> (It output that first one as it was not a matching range, but there was a matching range after it)
13:56:12 <Rubidium> peter1138: maybe we should just do ASLR on GRM reservations, so if the user does the wrong thing it usually breaks ;) You reserved 24 and 20 and assumed they would be a contiguous 44? Tough luck, they're at completely different locations ;)
13:56:36 <peter1138> Okay, due to loading order, I think using SpriteIDs outside your allocated reservation can cause problems.
13:58:17 <peter1138> With this patch that kinda happens.
13:58:23 <peter1138> They're "randomized" by changing the load order.
13:58:41 <peter1138> Oh but everything you reserve will be contiguous.
13:58:59 *** gelignite has quit IRC (Read error: Connection reset by peer)
13:59:10 <peter1138> So should we be lenient and allow that as long as it's within the lower and upper limits, or be strict...
13:59:28 <peter1138> I'm hesitant to break "working" NewGRFs.
13:59:46 <peter1138> (Other than the ones that are clearly one and potentially breaking other things.)
14:01:31 <_glx_> reservations are handled one GRF at a time IIRC, so even if it should be possible to get non continuous ranges it probably never happens
14:02:14 <peter1138> But if you reserve 32, but actually use 64, you'll be trampling on something else's reserved sprites.
14:02:33 <peter1138> Although to be fair, the something else will overwrite them.
14:02:39 <_glx_> ah indeed if you reserve 32 you can't use more than 32
14:02:53 <peter1138> This might be some of the "it doesn't work unless you load it in this order" issues that people think is just normally...
14:03:18 <Eddi|zuHause> so we're "fixing" undefined behaviour today?
14:04:02 <Eddi|zuHause> the whole grf spec only exists because of undefined behaviour
14:04:45 <Eddi|zuHause> all the 80+ vars are "undefined behaviour, that happened to work"
14:05:11 *** virtualrandomnumber has joined #openttd
14:05:17 <_glx_> reserving 32 and using 64 when being the only loaded grf might cause crashes (but we probably have some stuff to prevent that)
14:06:01 <peter1138> No, that will be fine.
14:06:15 <Eddi|zuHause> just skimming backwards, is there any reason NOT to specify "separate reservations will be continuous within the same GRF"?
14:06:48 <peter1138> SpriteIDs are allocated as they are used anyway, GRM just means you get a block reserved for you, before Action 1s use up everything below < 16384.
14:07:30 <peter1138> (Not sure why GRM sprites need to be below 16384 any more, possibly something legacy)
14:07:38 *** gelignite has joined #openttd
14:09:27 <peter1138> Rubidium: I could do that just for fun, but... not really helpful 😄
14:09:52 <peter1138> Maybe be related to other bits being used in the places these values are placed.
14:10:27 <peter1138> e.g. if it's a callback result (not sure if that would ever make sense...) only bits 0..14 are usable.
14:11:42 <_glx_> oh the usual 15bits results
14:11:47 <Eddi|zuHause> but non-callback results are spritesets, not sprites?
14:14:37 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
14:17:17 <peter1138> CZTR Bridges reserves a total of 96 sprites but tries to load 116 sprites.
14:18:17 <peter1138> If it's kept strict, it's more like to be properly fixed. If it's mostly working but only a little bit isn't it might not even get noticed...
14:21:13 *** Ares has quit IRC (Quit: Leaving)
14:21:16 <_glx_> trying to access more than reserved should never have worked
14:22:33 <peter1138> Replaced "not reserved" with "not within reserved range" so it's more explicit on what it is expecting.
14:24:38 <peter1138> Although by default these messages aren't visible unless running from a terminal window. Hmm.
14:25:57 <peter1138> Judging by how confusing people find anything in a text console...
14:48:37 *** aperezdc has quit IRC (Remote host closed the connection)
14:53:16 *** aperezdc has joined #openttd
15:03:31 <xarick> penalty of 2000 insufficient 😦
15:14:28 <Eddi|zuHause> no idea what you're trying to do, but chances are no amount of finite penalty will prevent constructing a pathologic case breaking it
15:28:49 <xarick> i'm testing 12335, and trying to find the best value for the reverse penalty
15:29:19 <xarick> I know 3000 works I already tested it
15:29:45 <xarick> currently testing 2500
15:39:35 *** Wormnest has joined #openttd
15:45:35 <j_n> peter1138: in that case I'd like to discontinue Asasignals
15:46:00 <j_n> AsasGFX will replace it, coming soon™️
15:46:09 <peter1138> Well that's up to you 🙂
15:46:35 <peter1138> asasignals may randomly stop working properly in the future anyway.
15:48:09 <j_n> is there a way to work around that change or do I just eat shit
15:49:06 <peter1138> Well you can fix the NewGRF to do it correctly 🙂
15:50:18 <_glx_> replacenew vs replace for signals
15:50:56 <j_n> I thought replacenew was exclusively for replacing new graphics introduced by OpenTTD or a patch pack
15:53:02 <peter1138> And most signals are non-original
15:53:12 <peter1138> Only 1275-1290 are original TTD signals.
15:53:16 <_glx_> well you use replace to replace the 2 basic green/red, all others are via replacenew
15:53:27 <j_n> oh that's what the change meant
15:53:32 <peter1138> replace is good for those.
15:53:44 <peter1138> replacenew should be used for the rest
15:53:54 <peter1138> If your sprite ID is > 4895, Action A is wrong 🙂
15:54:44 <j_n> I used replace because I found it more convinient
15:54:47 <j_n> gah, I should've known...
15:55:05 <_glx_> well it works until it won't 🙂
15:55:34 <_glx_> additional graphics can move without notice
15:55:45 <_glx_> that's why action 5 exists
15:58:53 <j_n> even so, I eventually plan to replace the functionality of Asasignals with a fork of OpenGFX2 (along with other ideas of mine)
15:59:02 <j_n> would be usable in multiplayer and visible on the title screen
16:02:52 <locosage> PeterNviaGitHub: tbf newgrf spec wasn't "always" very clear 😜
16:06:59 <peter1138> > This means only sprites with a number up to (and including) 4895 may be replaced by action A.
16:07:13 <locosage> added few months ago ;)
16:07:19 <peter1138> December 2023. That's basically always.
16:07:50 <peter1138> The fact it's new suggests that Rb already found this issue and had to edit the specs because nobody would listen :p
16:08:20 <peter1138> > action A modifies TTD's built-in sprites
16:08:26 <peter1138> That has been there forever.
16:08:41 <peter1138> TTD's built-in sprites does not include things OpenTTD adds.
16:09:27 <locosage> I think it was me who brought it up
16:09:41 <locosage> but it didn't say it can't be used for openttd adds ;)
16:09:56 <locosage> also, who the heck knows which are the new one, they all look the same in aligner
16:10:19 <locosage> anyway, it's good that it's clarified now
16:10:47 <xarick> gonna wait 1 more year just to be sure
16:11:52 <peter1138> It was always the case, that was the entire point of Action 5 existing.
16:13:38 <peter1138> Hmm, how does `SPR_EMPTY_BOUNDING_BOX` get allocated...
16:14:12 <peter1138> Or is it always just a sprite that doesn't exist 😮
16:14:27 <locosage> locosage: oh, yeah, found the discussion
16:38:13 <peter1138> Bit more useful, but presentation isn't ideal...
16:53:51 <peter1138> Maybe shrink the sprite number list and put the information below it.
16:58:00 <_glx_> showing which grf provides the sprite is nice
16:58:39 <peter1138> That's actually already there 🙂
16:59:05 <peter1138> But it would just show "Aligning sprite 5,199 (dutchsignals)" before.
16:59:46 <peter1138> This won't, sadly, help with GRM reserved sprites, or action 1 spritesets.
17:01:09 <peter1138> Oh wait, spritecache->id is the nfo line
17:02:23 <FLHerne> Can NML just do the right thing regardless? i.e. use Action5 for replace() when appropriate?
17:02:45 <FLHerne> or would it be hard to determine the amount of GRM reservation at compile time?
17:02:52 <_glx_> not the exact same syntax
17:03:08 <peter1138> FLHerne: No, because the numbers don't mean anything.
17:03:32 <peter1138> GRM reservation is nothing to do with Action 5.
17:03:47 <FLHerne> you'd have to know which version of OpenTTD they were trying to address sprites of
17:05:31 <peter1138> I guess nfo line isn't that useful for NML users.
17:05:38 <peter1138> But maybe it's more useful than the loaded ID.
17:08:09 <peter1138> Spritesets don't have useful IDs by themselves anyway.
17:08:22 <peter1138> GRM reservations neither.
17:12:51 <peter1138> And for a GRM or Act1 sprite, just this
17:13:13 <peter1138> No sprite ID, as the dynamic ID isn't useful. But the NFO line is included (in standard file:line format)
17:14:00 <peter1138> So the numbers listed under the 'Pick sprite' button are also a bit useless, but difficult to show much information there.
17:14:13 <peter1138> Perhaps file:line would be better there though.
17:18:56 <locosage> nfo line isn't particularly useful either
17:19:26 <peter1138> nfo line is basically "GRF data block"
17:20:01 <peter1138> It's more useful than the loaded Sprite ID, and there is no other identifier that can be used.
18:03:38 <peter1138> Hmm, `std::span<const std::unique_ptr>` does, surprisingly, work.
18:07:22 <peter1138> No reason, I'm just easily surprised.
18:31:17 <LordAro> i was about to say, no need for std::array there
18:39:32 <peter1138> Failed to notice it was on rebase & merge instead of squash for the first one 😦
18:42:08 <rau117> andythenorth: this requires taking away **the only** GS slot. If you want to play with xussr real dates + town grow you need to choose. Moreover this requires additional work on grf dev part and on the player part, instead of idk, changing one NML parameter
18:49:19 <andythenorth> that's the API though
18:57:21 <rau117> rau117: well, possibility to add several gamescripts will be great for that, but (sorry, just a guess) needs way more work on openttd side than adding possibility to precisely control randomness (or at least being able to completely disable it)
18:57:21 <rau117> no argue, for a regular gameplay such a tiny random isn't so painful (except breakdowns)
18:57:21 <rau117> but when prototype locomotive comes out a year after mass-production variant looks suspicious
19:02:34 <andythenorth> has anyone proposed an actual spec?
19:02:37 <andythenorth> start a discussion
19:02:54 <locosage> what does that randomization even achieve?
19:03:10 <locosage> feels like a poor attempt of increasing replayability of the original game
19:06:05 <andythenorth> it's in the original so it has to be kept?
19:07:06 <locosage> just hardcode as 4 :p
19:07:17 <locosage> though I guess it's 73 now...
19:09:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:10:43 <andythenorth> so what would the spec be?
19:27:07 <peter1138> Not duplicating the action 5 information is actually more lines of code, but... at least it's not duplicated and therefore potentially wrong.
19:32:27 *** zzy2357[m] has quit IRC (Quit: Client limit exceeded: 20000)
19:59:18 <Eddi|zuHause> i failed today's xkcd, i think.
20:15:13 <silent_tempest> Eddi|zuHause: This seems to EZ. Lol
20:16:16 <Eddi|zuHause> i think you got an easier one... i had one with 4 inputs of 3 different colours
20:22:53 <peter1138> Hmm. I actually thought that was part of the other commit, oops.
20:35:37 <peter1138> Bringing out the old commits now.
20:42:24 <michi_cc> Two stupid people thinking the same, eh? 🙂
20:44:58 <peter1138> My stack-overflow (taken with a pinch of salt of course) answer I saw ages ago...
20:47:32 <peter1138> In terms of default operation, accumulate is the same as reduce too, except "accumulate" has the implication it's adding.
21:10:52 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:15:40 <truebrain> Btw, so the xz repo is no longer blocked but a 404. So I guess it is private now, meaning the original author has access .. so hopefully he can clean up the mess soon 🙂
21:30:34 *** Flygon has quit IRC (Read error: Connection reset by peer)
21:46:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:03:43 <peter1138> I think I'm just going to have to disagree with LordAro. Not on bikes though 🙂
22:11:58 *** aperezdc has quit IRC (Remote host closed the connection)
22:12:09 *** aperezdc has joined #openttd
22:14:44 <truebrain> Pfew. Otherwise the world would be broken.
22:35:42 <truebrain> Helped dispatched. It will arrive in 2034
22:54:21 *** gelignite has quit IRC (Quit: Stay safe!)
23:04:23 <peter1138> Will xz be back by then...
23:39:16 *** bertvvvs has joined #openttd
continue to next day ⏵
