IRC logs for #openttd on OFTC at 2023-06-05
⏴ go to previous day
00:46:19 *** Soni has quit IRC (Ping timeout: 480 seconds)
02:25:04 *** Soni has quit IRC (Ping timeout: 480 seconds)
02:37:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:25:14 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:21:59 <TrueBrain> I still love how easy godbolt makes testing these things out 🙂
07:27:24 <TrueBrain> lol, before optimization, a `string_view` produces worse code than a `const string &` 😄 (it makes one less object)
07:33:03 <TrueBrain> owh, I was even looking wrong .. the tenary operator also creates a new std::string
07:33:11 <TrueBrain> that is why string_view is in fact worse ..
07:35:28 <TrueBrain> why is this so much fun 😄
08:35:49 <TrueBrain> lol, I didn't know only contributors could set labels on GitHub .. I thought everyone could
08:35:53 <TrueBrain> that makes things a lot easier 😄
08:40:23 <dP> contributors can't, only members can
08:44:02 <TrueBrain> haha, fun things you can learn about GitHub: if you make 2 PRs of the same commit, all status reports happen on both
08:44:08 <TrueBrain> even if the workflow says it runs for one of the two 😄
08:53:23 <TrueBrain> lol, how ... why ... owh my 😛 That will be fun 😄
08:54:48 <TallTyler> Objects don’t get destroyed when you terraform under them? Should they?
08:55:06 <TrueBrain> should you be able to terraform when there is an object?
08:55:08 <TrueBrain> SO MANY QUESTIONS! 😄
08:55:11 <Brickblock1> I don't think they should
08:55:59 <Brickblock1> you can even get water above sea level
08:56:05 <TallTyler> Objects have to have a flag set to build on water, right? That could indicate that terraforming is prohibited, unless we want to allow it on slopes or something
08:56:06 <petern> There's a flag that tries to make them behave like plain bought land.
08:56:28 <TrueBrain> it is a briliant bug 🙂
08:56:44 <TallTyler> Oh, the one to allow anything to remove them?
08:58:07 <petern> Or at least, allow implicit removal by the owner.
08:58:19 <Brickblock1> these are the flags on that object:
08:58:19 <Brickblock1> `OBJ_FLAG_ANYTHING_REMOVE, OBJ_FLAG_ANIMATED, OBJ_FLAG_ON_WATER, OBJ_FLAG_DRAW_WATER, OBJ_FLAG_NO_FOUNDATIONS, OBJ_FLAG_ALLOW_BRIDGE, OBJ_FLAG_NOT_ON_LAND`
08:58:26 <petern> You can terraform plain owned land, but you can't own ocean.
08:58:44 <petern> Therefore this issue doesn't affect plain own land.
09:00:10 <TallTyler> Yes `OBJ_FLAG_ANYTHING_REMOVE` was the one I was thinking of. Couldn’t look up the specs fast enough. 🙂
09:04:58 <TrueBrain> I am too, but another hour before lunch 😢
09:05:35 <petern> It'll be elevenses time for you 🙂
09:05:59 <TrueBrain> btw, petern , you were struggling to compile on your laptop; did you also know VSCode has a `--tunnel` mode, where you can start VSCode on one machine via CLI, and access it from any other via the web? Much like Codespaces, only on your own machine 🙂
09:06:23 <TrueBrain> I basically only use that these days 😛
09:06:30 <TrueBrain> as my hardware is more powerful than codespaces 🙂
09:06:49 <petern> And already set up for compiling 😄
09:08:08 <TrueBrain> I stopped using this method, as it bounces everything via `vscode.dev` which can be laggy
09:08:20 <TrueBrain> but the other way is poorly documented 😄 You need `code-server` for that, and then you can keep everything local
09:09:02 <TrueBrain> the first is for n00b users, the second for expert users 😛
09:09:36 <TrueBrain> (especially as you need to install a keyring, and more of that shit, with the second method .. the first one "just works")
09:44:55 <TrueBrain> `invalid value workflow reference: no version specified` that is the least descriptive error I have seen in a while ..
09:45:01 <TrueBrain> and I didn't actually make a change here, I thought ..
09:53:20 <TrueBrain> so silly you can't use subfolders for reusing workflows
09:53:24 <TrueBrain> makes administration a nightmare
10:09:16 <TrueBrain> right ... that was a lot of work ... but it seems to work very well ... now to convert an actual repository of ours, instead of my sandbox 🙂
10:28:48 <TrueBrain> turns out, I suck at renaming variables 😄
10:32:51 <TrueBrain> can't believe this is actually doing what I expect 😄
10:33:47 <TrueBrain> glx[d]: I could use a really critical look on that PR; if you need more context or whatever, just let me know .. I really hope this will make our life a lot easier 🙂
10:34:37 <TrueBrain> after lunch, I will apply this to TrueWiki, see if it can actually deploy .. as that is the one step I haven't been able to test 😄
10:58:57 <petern> > note: add an explicit instantiation declaration to suppress this warning if
11:42:00 <LordAro> "IdleAI doesn't do anything, but when I have a stake, I know which of these companies I want to go to and maybe even send them money."
11:42:56 <FLHerne> Is this belated complaints about the shares removal?
11:43:32 <FLHerne> there's no wrong way to play the game, but there are certainly strange ones
11:45:26 <LordAro> professional spacebar heaters
12:18:35 <andythenorth> the game probably has a strong appeal to some non-neurotypical people
12:19:24 <andythenorth> having spent a lot of time in RL model train groups when I was younger, I suspect an overlap
12:25:59 <TallTyler> At least that user was open to an alternate method and even said it was probably silly
12:33:35 <petern> Buried deep in non-resolving templates...
12:34:00 <andythenorth> is that a call for help?
12:34:02 <andythenorth> waving or drowning?
13:03:35 <Eddi|zuHause> people who are still able to wave are probably not drowning
13:26:00 <TrueBrain> LordAro: that actually was a perfect example of a spacebar heater, yes 🙂 And I love the comment for it 🙂
13:31:16 <TrueBrain> right, now I first need to merge that commit before I can roll it out to other repos .. but from testing I think it all works as expected 😄
13:45:33 <TrueBrain> now with explicit secret definition 🙂
13:46:06 *** D-HUND is now known as debdog
13:46:30 <TrueBrain> if only I could do it right the first time or something
14:02:22 *** ChanServ sets mode: +v tokai
14:08:14 *** _aD has quit IRC (Quit: leaving)
14:09:49 <TrueBrain> glx[d]: was there anything else, or still looking? (not meant to rush you; just want to keep the boat flowing :D)
14:17:21 <glx[d]> I could as well approve
14:17:56 <TrueBrain> is this now easier to follow?
14:18:06 <TrueBrain> or does it still feel like magic? 😄
14:20:50 <glx[d]> it's understandable (step names and comments help a lot)
14:21:09 <TrueBrain> also a lot less code
14:21:34 <glx[d]> even without understanding every thing in details it makes sense
14:23:31 <glx[d]> and the important part is less copy/paste, so only one place to update when bumping deps
14:23:50 <TrueBrain> I am really curious how that will go over time 🙂 I really hope it delivers 🙂
14:24:44 <glx[d]> seeing the "pain" it is with current workflows in all the different repos, it can only be better
14:26:09 <TrueBrain> thank you very much
14:26:29 <glx[d]> the only way to be sure it fully works is to use it
14:28:08 <TrueBrain> mostly I suspect there are options missing .. but we can fix that as we find them 🙂 The annoying part is that I first need to merge the change in every repo, before it can actually be tested .. but okay, we will see how it goes 🙂
14:29:19 <glx[d]> it's like releases, we can't really test the workflow before a real release (because uploading and other stuff)
14:29:37 <TrueBrain> normally you can cheat a bit by doing it in your fork
14:29:44 <TrueBrain> but because of credentials, here that even isn't really possible
14:30:31 <glx[d]> yeah when testing release workflow I disable the final step usually because I can't do it
14:31:25 <glx[d]> at least I can validate all steps except publish
14:39:58 <TrueBrain> I was wondering why nothing was working .. but it is one of the few things I still need to release, for good reasons 🙂
14:45:49 <petern> > 15 files changed, 411 insertions(+), 503 deletions(-)
14:46:09 <TrueBrain> depends; does it improve the functionality?
14:46:52 <petern> Not really although it does remove list end markers, because vectors know how long they are.
14:47:14 <TrueBrain> good enough for me!
14:47:18 <petern> And removing macros is "improving the functionality" in a way.
14:47:24 *** HandsomeKK has joined #openttd
14:47:24 <HandsomeKK> may i ask how can i solve the lang prob with traditional chinese
14:47:51 <CK2347> It seems it's incomplete
14:47:58 <CK2347> and missing characters
14:48:18 <HandsomeKK> but i've checked in steam it said alright and reinstall
14:49:10 <LordAro> you need to use a font that actually supports those characters
14:49:23 <LordAro> as it says, see the readme for details
14:49:27 *** gelignite has joined #openttd
14:49:38 <HandsomeKK> LordAro: how should i do
14:49:40 <petern> In most cases it does try to find one.
14:49:52 <HandsomeKK> how to change then
14:49:57 <HandsomeKK> can anyone teach me
14:50:30 <petern> Ah, "Chinese (Simplified)" just works for me, but "Chinese (Traditional)" doesn't
14:50:48 <petern> First one switches to "Microsoft YaHei" as the font.
14:57:32 <TrueBrain> right, time to test this new workflow ... the testing one worked ... now for the release one ... instant failure 😄 haha 🙂 Owh boy ...
14:57:59 <TrueBrain> `secrets: inherit` doesn't work for explicit secrets, it seems .. annoying
14:58:53 <glx[d]> you can use the `font` console command
14:59:12 <TrueBrain> ah, I am cross-organization, and then inherit breaks .. I shouldn't have started with the wiki 😛
14:59:34 <glx[d]> it's simpler to change fonts with 13+
15:00:01 <LordAro> glx[d]: "simpler" doing some heavy lifting in that sentence
15:00:18 <glx[d]> still not ideal, but better than needing to edit cfg by hand
15:02:31 <glx[d]> I think in most cases when a font can't be determined for a given language it's because of currencies
15:02:44 <TrueBrain> `write tcp 172.17.0.2:48520->140.82.112.34:443: write: broken pipe` ... GitHub ... please don't be like this ...
15:03:14 <glx[d]> put tape around the pipe 🙂
15:04:31 <TrueBrain> owh boy, here are the PRs again ...
15:05:30 <TrueBrain> LordAro was still on duty right? 😄
15:07:25 <Rubidium_> that's a nice summoning :D
15:08:02 <TrueBrain> okay ... deployment on the GitHub side worked as epxected ... now the question: does my deployment script on the infra side also work as expected ...
15:09:08 <TrueBrain> always nice, if things actually work 🙂
15:09:24 <TrueBrain> now let's try a preview 🙂
15:12:14 <TrueBrain> hmm .. changes on the production wiki aren't committed ... why not ... interesting ...
15:14:25 <TrueBrain> no errors in the logs, no activity on github .. interesting
15:16:09 <TrueBrain> ghehe, forgot to give the new bot permission to bypass branch protection 😄
15:22:10 <TrueBrain> IT WORKS! Previews deploy just fine too 😄
15:22:24 <TrueBrain> now I just have to repeat this ... 12 times? 🙂 But that is survivable 😛
15:29:43 <LordAro> does the crash template not allow setting a title?
15:41:20 <TrueBrain> LordAro: It does. They just don't. 😄
15:42:12 <TrueBrain> Or when they do ... 😄
15:42:56 <LordAro> now that you've finished rewriting workflows, don't suppose you fancy writing a bot that automatically decodes crash dumps? :p
15:43:16 <LordAro> or perhaps just a bot that pings glx[d] whenever a new crash issue is posted would suffice
15:44:16 <glx[d]> automatic dump is complicated I think
15:46:34 <glx[d]> ah needs to download 13.1 stuff (first dump for this version)
16:03:58 <TrueBrain> LordAro: I was more thinking about integrating minidump to the game, and report that to us automated (after approval, ofc)
16:04:19 <glx[d]> that's the newgrf list for the crash save
16:04:48 <TrueBrain> it crashes on ReadByte?
16:05:58 <glx[d]> if I follow the data I have from the dmp the crash happens during reading of zbase
16:06:31 <TrueBrain> do we even want to know? 😄
16:06:41 <TrueBrain> (why ReadByte fails)
16:07:17 <glx[d]> well fails on `return *this->buffer++;`
16:07:20 <TrueBrain> does it throw or segfault?
16:07:48 <TrueBrain> buffer a `nullptr`?
16:09:13 <TrueBrain> no, that is nearly impossible ..
16:11:49 <TrueBrain> right, I am going to bring the new wiki to production ... let's see how real-world traffic does 🙂
16:16:29 <TrueBrain> seems to work as expected; but please let me know if you notice reports about wiki acting up, tnx 🙂
16:17:08 <petern> I don't need another synth. I don't need another synth. I don't need another synth.
16:17:28 <TrueBrain> you bought it already didnt you?
16:19:26 <petern> zbase crashes. On a system with 4GB RAM.
16:19:53 <petern> Nah, not bought... yet.
16:20:15 <Eddi|zuHause> zbase will probably also crash on the synth :p
16:21:42 *** HerzogDeXtEr has joined #openttd
16:23:25 <petern> What the heck github, I was still typing that.
16:23:41 <LordAro> maybe you need a new keyboard
16:23:52 <TrueBrain> sorry, I will log out my remote desktop to your machine
16:23:58 <TrueBrain> I accidentially hit the enter key
16:26:31 <TrueBrain> I am rather happy this new infra actually works .. it is so much simpler .. from GitHub to AWS .. now let's hope it is as stable as the current infra 😛
16:42:50 <TrueBrain> LordAro: from what I can gather from Sentry and breakpad, it does correct stackwalking on Windows / Linux / MacOS, which means that the stacktraces produced by it already contains readable strings .. basically, it would make glx obsolete (hihi, just kidding ofc)
16:43:09 <TrueBrain> but, I haven't found a way yet to use their result in our own reporting
16:50:41 <glx[d]> oh if we can have useful stack without needing lots of manual work I'm fine
16:51:37 <glx[d]> of course the dmp also contains some data, but usually the important one is optimised out
16:52:14 <TrueBrain> what I have been toying with, is what if we drop our own crashlog handling completely, and use the sentry one. It means that if a user opts out to send their crash-reports, they also have nothing to send manually
16:52:28 <TrueBrain> but at least it moves all the complexity for all OSes to breakpad (or crashpad)
16:52:39 <TrueBrain> but I am wondering if there is a way to manually dump the sentry report to disk
16:52:43 <TrueBrain> so people can report that again manually
16:53:24 <TrueBrain> that said, one of the downsides of automated reports, is that sending the savegame along is really ..... tricky
16:53:42 <TrueBrain> (they are often big .. so you don't want to collect a lot of them)
16:55:46 <glx[d]> yeah and crash save is not always usable to reproduce issues
16:56:56 <TrueBrain> similar with the png, only .. even less likely to be useful; just sometimes 🙂
17:03:23 <glx[d]> so this->buffer was 0x1F7346D9720 on crash, this->buffer_start is 0x1f7356d9718 (from what I can get in the dmp)
17:03:57 <glx[d]> would mean this->buffer is not between start and end for some weird reasons
17:04:48 <petern> Smells like a bit-flip.
17:05:21 <glx[d]> but I'm just guessing from the almost inexistent data I have
17:05:55 <TrueBrain> petern: happens more than once .. so not a cosmic ray at least 😄
17:06:23 <petern> I stopped using my Q6600 in the end because it became old & flakey.
17:06:48 <JGR> The user claims that it crashes the same way every time
17:09:34 <TrueBrain> petern: CodeQL works better if one would be GetItem and the other GetOrCreateItem 😛
17:09:37 <TrueBrain> instead of a parameter 😄
17:10:08 <petern> Yeah, I didn't create or change this API here though 🙂
17:11:01 <TrueBrain> Rubidium dismissed the old one with `GetItem with parameter true creates an item when none is found, so it never returns nullptr. `
17:11:35 <petern> Well, there are two calls to this function, so that's the next thing to change 😉
17:12:18 <TrueBrain> it is just silly that `GetItem` can create an item 😛
17:12:45 <petern> Works for me. I'll tackle that next ;p
17:19:03 <LordAro> TrueBrain: why not use sentry for "automated" crash reports, but fallback to our one for "manual" reports?
17:19:15 <TrueBrain> because they both take over signal handling
17:19:20 <TrueBrain> so having both is ... complicated
17:20:42 <TrueBrain> it does kinda work on Linux, as we use a very lightweight way of intercepting crashes
17:20:48 <TrueBrain> but on Windows ... we capture `edp` and shit
17:20:54 <TrueBrain> it becomes .... complicated 🙂
17:21:06 <TrueBrain> not impossible; just before I delve into shit like that, I have to wonder: do we even need it?
17:22:33 <JGR> The stuff with esp/rsp is only really needed for the custom dialog afterwards
17:23:01 <JGR> And even then you could probably allocate a stack page some other way
17:23:45 <JGR> Presumably with sentry you'd have to remove that anyway
17:26:40 <TrueBrain> so basically, all these backends make minidumps
17:27:52 <glx[d]> TrueBrain: do you intend to run backport script with --mark-done ?
17:29:07 <TrueBrain> glx[d]: all done! Tnx for the reminder 🙂
17:30:16 <TrueBrain> I could also bitch of the lack of capitalization at the beginning of sentences 😛
17:30:52 <glx[d]> oh seems one PR missed the backport train 🙂
17:30:54 <TrueBrain> fuck it, I am in a nitpick mood 😛
17:32:04 <TrueBrain> glx[d]: nah, it is in there 🙂
17:33:26 <TrueBrain> Ruining the game, one review at the time
17:34:09 <TrueBrain> JGR: kinda; but the stacktrace after sentry is also not .. useful 😛
17:34:26 <TrueBrain> it is just complicated .. I rather highjack the minidump from sentry and store that .. but ... can I .. hmm
17:34:31 <TrueBrain> or do we need to wrap around breakpad ourselves ..
17:37:26 <JGR> Would getting rid of the crash logger imply losing all the other OpenTTD specific information
17:37:38 <TrueBrain> no, not at all; you can augment sentry reports
17:37:54 <TrueBrain> in fact, it is well advised to add all that information 🙂
17:38:07 <TrueBrain> means in Sentry you can filter on that data really easily
17:38:42 <TrueBrain> ah, okay, minidump doesn't contain readable stacktraces, but Sentry backend decodes it, as you upload pdbs to it
17:38:49 <TrueBrain> that makes sense, I guess
17:39:19 <TrueBrain> so instead of glx we can just upload it to sentry, and it will tell us exactly what the stacktrace was, basically 🙂
17:40:55 <TrueBrain> basically, from what I can tell, the only thing we would lose, are savegame, when done automated
17:41:09 <TrueBrain> we could still make the savegame locally, ofc
17:44:03 <TrueBrain> too bad we don't have a subscription at Sentry that allows us to store debug symbols on our backend and point them to it .. they want us to upload it to theirs .. so every night ........ 😛
17:45:28 <TrueBrain> owh, and the other thing you would lose, if we go this way, that for us developers we also no longer see a stacktrace on linux when it crashes; basically, for those too lazy to use gdb 🙂
17:48:42 <JGR> That is likely to impact dedicated servers
17:50:51 <JGR> Perhaps I'm misunderstanding this, I should go read up on sentry when I've got some time
17:51:57 <TrueBrain> ghehe; basically, from what I can tell, what we can pull off is:
17:51:57 <TrueBrain> - Opt-in automatically send crash reports to us, which include a minidump (read: stacktraces), gamelog, other metadata
17:51:57 <TrueBrain> - Otherwise we store a small bundle of this information on disk, for people to attach to an issue. In the backend we then upload that bundle to Sentry
17:52:12 <TrueBrain> what we lose is: no more Linux / MacOS stacktraces for developers, and savegames are not send to Sentry
17:52:19 <TrueBrain> we could still have crash.sav for the second options, ofc
17:53:00 <TrueBrain> so the difference would be small; but the second option is a bit of work, as that is normally not what is supported 😄
17:53:47 <TrueBrain> I know the first works, as I already have code for that 🙂
18:32:00 <LordAro> petern: couldn't GetItem have been marked as const?
18:34:09 <petern> It took an hour to merge and NOW you say something 😄
18:42:45 <DorpsGek> - Update: Translations from eints (by translators)
18:44:00 *** gelignite has quit IRC (Quit: Stay safe!)
18:55:58 <LordAro> previous version? deleting baseset while running, perhaps?
19:18:21 *** gelignite has joined #openttd
19:39:12 *** debdog has quit IRC (Ping timeout: 480 seconds)
19:48:07 *** gelignite has quit IRC (Quit: Stay safe!)
19:52:22 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
19:57:43 <LordAro> Rubidium_: your move :p
20:13:23 <petern> My Linux system has chosen "Noto Sans CJK JP" to display Chinese (Traditional) ... so it is workable 😄
20:21:01 <petern> Eh, WSL, almost the same 😄
20:37:04 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:05:12 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:13:17 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:16:10 *** discord_user_03329cf has joined #openttd
21:16:10 <discord_user_03329cf> Where would i make a suggestion? I’d like to suggest an option to disable whatever it is that makes vehicles not be introduced at a specific time
21:17:53 <glx[d]> isn't there a flag for that ?
21:19:12 <discord_user_03329cf> You mean for grf authors? No idea, don’t code, but if there is then that’s cool
21:20:12 <discord_user_03329cf> Itd be cool for it to be universal but that alone covers most of my issue
21:23:31 <JGR> There isn't a flag for that
21:24:07 <Brickblock1> It would be a really nice thing to have
21:24:17 <discord_user_03329cf> It would
21:25:29 <pickpacket> discord_user_03329cf: do you mean that they would always be introduced in the year they're designed?
21:26:36 <discord_user_03329cf> Not what i want, but an idea, in locomotion, that other Chris sawyer transport game, there was a reliability penalty if you bought a vehicle within 2 years of its introduction
21:27:17 <JGR> This behaviour already exists
21:27:45 <discord_user_03329cf> But everyone had the vehicle
21:27:57 <discord_user_03329cf> And it was introduced at the first of January
21:28:12 <discord_user_03329cf> “Can a grf author impact reliability or is it random?”
21:28:28 <discord_user_03329cf> I said this in the addon channel but i felt it relevant to move here
21:28:50 <pickpacket> is there a reliability penalty for early purchasing now? I always play without breakdowns and pay no attention to reliability
21:28:51 <discord_user_03329cf> From what I’ve seen reliability just seems random
21:29:08 <discord_user_03329cf> pickpacket: There is if you have the special access
21:29:30 <discord_user_03329cf> Like when it says “oh we have some new shit, wanna test it?”
21:30:15 <pickpacket> discord_user_03329cf: cool!
21:31:25 <discord_user_03329cf> It’s a mechanic i like in a way but I’d prefer it to come like 2 years before full introduction
21:31:25 <discord_user_03329cf> So say you had a Leyland National mk2 (irl released in 79) it would always come out in 79 in hand but would be offered in 77 for example
21:32:58 <petern> Reliability is randomized based on the prototypical properties, but it follows a curve that makes maximum raeiability come after a couple of years.
21:33:51 <petern> As the exclusive preview is year, that's a year of perhaps lower reliability than regular availability.
21:34:06 <discord_user_03329cf> Can max be controlled by the author?
21:34:19 <discord_user_03329cf> petern: Fair, thought it was 2
21:34:27 <discord_user_03329cf> Not played in a few months I’ll be honest
21:34:32 <pickpacket> I just checked the NewGRF spec and you're right that authors can't affect the reliability. That's a shame, imho. I feel like the factors deciding whether to buy a new engine are tractive effort, acceleration, top speed, and reliability. If I want to write a NewGRF that introduces some more engines I'd like to be able to tweak all of those
21:35:25 <discord_user_03329cf> Yeah reliability would be fun to mess with
21:36:27 <discord_user_03329cf> Oh you bought a Temsa Avenue? Well fuck you it’s going to break down all the time
21:36:42 <discord_user_03329cf> Shame i can’t make them spontaneously combust also just like irl
21:38:24 <discord_user_03329cf> I really hate that bus
21:38:34 <pickpacket> An engine with a high top speed and acceleration but terrible reliability is a completely different thing than one with slow acceleration and top speed but high tractive effort and reliability
21:39:42 <pickpacket> discord_user_03329cf: to be fair I see no reason adding vehicles that have *no* redeeming properties :D
21:40:03 <pickpacket> but bedtime for me now :)
21:40:40 <discord_user_03329cf> pickpacket: I want to add vehicles if i like them or not
21:43:36 <discord_user_03329cf> discord_user_03329cf: They were very common in my area and seem to be getting more common again due to budget cuts, so they feel relevant to me
21:44:37 <discord_user_03329cf> The burnt one in the picture is either from route 5 or X4, both of which have recently started using them again after not for a few years
21:59:13 <FLHerne> I thought there was something to allow introducing related vehicles (e.g. loco and matching carriages) at the same time, but I can't find it
21:59:21 <FLHerne> maybe it was one of andy's imaginary spec ideas
22:14:49 <glx[d]> there's some synchronisation of introduction randomness
22:17:57 <andythenorth> if the intro date is identical, the randomisation will be identical
22:18:12 <andythenorth> so simultaneous introductions can be achieved
22:19:36 <petern> There is a flag to attempt to synchronize reliability if the introduction dates are different.
22:19:53 <petern> But I think andy gave up trying to test that.
22:20:57 <andythenorth> I recall running the game on ffwd for a bit 😛
22:21:01 <andythenorth> can't remember the conclusion
22:21:09 <andythenorth> I think I concluded we need automated testing 😛
22:35:59 <petern> You're my automated testing.
22:38:14 *** Kitrana has quit IRC (Read error: Connection reset by peer)
22:43:06 *** Kitrana has joined #openttd
22:45:14 *** Kitrana1 has joined #openttd
22:51:09 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
22:58:34 *** felix has quit IRC (Ping timeout: 480 seconds)
23:03:48 <zephyris> petern: I tried forcing some settings for the baseset extra grf, by adding a line to the static newgrf section of the cfg... Interestingly it looks like it's specifically ignored, may 'just' be a matter of removing this check.
23:05:28 <glx[d]> no it's explicitely done to prevent using system grf as newgrf
23:05:56 <glx[d]> I think a new ini section would be better
23:07:53 <glx[d]> and static newgrf are added at the end of the newgrf list, while baseset newgrf are inserted on top
23:09:32 <glx[d]> hmm another option could be extra parameters to baseset setting
23:12:40 <glx[d]> some kind of new format for `graphicsset = "original_dos"` to include the parameters for xxx_extra.grf
23:18:27 *** Kitrana1 has quit IRC (Quit: Leaving.)
23:18:50 *** Kitrana has joined #openttd
23:22:49 <glx[d]> maybe like driver parameters
23:22:55 *** tokai|noir has joined #openttd
23:22:56 *** ChanServ sets mode: +v tokai|noir
23:29:34 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
