Times are UTC Toggle Colours
00:46:19 *** Soni has quit IRC 02:10:11 *** Soni has joined #openttd 02:25:04 *** Soni has quit IRC 02:33:43 *** D-HUND has joined #openttd 02:33:54 *** Soni has joined #openttd 02:37:05 *** debdog has quit IRC 03:40:10 *** keikoz has joined #openttd 05:25:14 *** keikoz has quit IRC 06:16:47 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461778364 07:10:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461846828 07:14:16 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461858186 07:21:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461868900 07:21:59 <TrueBrain> I still love how easy godbolt makes testing these things out ๐ 07:22:54 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461870738 07:24:33 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947 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 ๐ 07:39:49 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1461896669 08:25:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1461919433 08:27:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10915: Fix: when syncing width of GUI items, take padding into account https://github.com/OpenTTD/OpenTTD/pull/10915#pullrequestreview-1462000929 08:27:10 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10915: Fix: when syncing width of GUI items, take padding into account https://github.com/OpenTTD/OpenTTD/pull/10915 08:28:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1462003319 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:38:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 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:52:49 <DorpsGek> [OpenTTD/OpenTTD] Brickblock1 opened issue #10948: [Bug]: Water ends up on sloped tiles when terraforming objects https://github.com/OpenTTD/OpenTTD/issues/10948 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> https://cdn.discordapp.com/attachments/1008473233844097104/1115202345790357554/Fravas_Transport_1970-01-29.png 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:07 <petern> There's a flag that tries to make them behave like plain bought land. 08:56:20 <petern> Is that in use here? 08:56:28 <TrueBrain> it is a briliant bug ๐ 08:56:32 <Brickblock1> petern: yes 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:03:55 <petern> Hmm, am I hungry... 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:15 <petern> No I didn't. 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:50 <petern> And already set up for compiling ๐ 09:07:53 <TrueBrain> https://code.visualstudio.com/docs/remote/tunnels 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:08:48 <TrueBrain> `wget -O- https://aka.ms/install-vscode-server/setup.sh | sh && code-server serve-local --accept-server-license-terms --disable-telemetry --without-connection-token --quality=insiders` 09:09:03 <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:20:23 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914#pullrequestreview-1462105019 09:23:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10946: Cleanup: remove stre-style GetString https://github.com/OpenTTD/OpenTTD/pull/10946 09:38:44 *** Flygon has joined #openttd 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:21 <TrueBrain> so silly you can't use subfolders for reusing workflows 09:53:24 <TrueBrain> makes administration a nightmare 09:56:04 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10890: Feature: Create group of vehicles from manage vehicle list button. https://github.com/OpenTTD/OpenTTD/pull/10890#pullrequestreview-1462169108 10:08:57 <DorpsGek> [OpenTTD/actions] TrueBrain opened pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 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:11:24 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:19:28 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:27:02 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:27:53 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:28:47 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:28:48 <TrueBrain> turns out, I suck at renaming variables ๐ 10:29:29 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 10:31:02 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 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 10:58:59 <petern> Yay :/ 11:01:47 <DorpsGek> [OpenTTD/actions] glx22 commented on pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462280243 11:03:31 <DorpsGek> [OpenTTD/actions] TrueBrain commented on pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462284098 11:22:32 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 11:24:31 <DorpsGek> [OpenTTD/actions] TrueBrain commented on pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462316543 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:03 <LordAro> good grief 11:42:56 <FLHerne> Is this belated complaints about the shares removal? 11:43:20 <LordAro> yes 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:20:09 <DorpsGek> [OpenTTD/actions] glx22 commented on pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462399938 12:25:59 <TallTyler> At least that user was open to an alternate method and even said it was probably silly 12:30:35 *** nielsm has joined #openttd 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:26:46 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 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:44:31 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 13:45:32 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 13:45:33 <TrueBrain> now with explicit secret definition ๐ 13:46:07 *** D-HUND is now known as debdog 13:46:30 <TrueBrain> if only I could do it right the first time or something 13:46:34 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 13:50:17 *** _aD has joined #openttd 14:02:22 *** tokai has joined #openttd 14:02:22 *** ChanServ sets mode: +v tokai 14:08:14 *** _aD has quit IRC 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:09 <DorpsGek> [OpenTTD/actions] glx22 commented on pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462653331 14:17:16 <glx[d]> it's very minor 14:17:21 <glx[d]> I could as well approve 14:17:29 <TrueBrain> nah 14:17:31 <TrueBrain> let me fix it 14:17:56 <TrueBrain> is this now easier to follow? 14:17:57 <DorpsGek> [OpenTTD/actions] TrueBrain updated pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 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:02 <TrueBrain> good! 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:25:03 <TrueBrain> true ๐ 14:26:02 <DorpsGek> [OpenTTD/actions] glx22 approved pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45#pullrequestreview-1462678791 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:27:32 <DorpsGek> [OpenTTD/actions] TrueBrain merged pull request #45: Feature: reusing workflows for testing / preview / release https://github.com/OpenTTD/actions/pull/45 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:49 <DorpsGek> [OpenTTD/actions] TrueBrain created new tag: v4.1.0 https://github.com/OpenTTD/actions/releases/tag/v4.1.0 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:45:51 <petern> Hmm 14:45:55 <petern> I guess that's a win. 14:46:09 <TrueBrain> depends; does it improve the functionality? 14:46:11 <TrueBrain> ๐ 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> https://cdn.discordapp.com/attachments/1008473233844097104/1115290784648933436/image.png 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:48:21 <HandsomeKK> still happen 14:48:47 <CK2347> Change language 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:50:58 <HandsomeKK> how can i change 14:55:18 <TrueBrain> always best to ask for help in the Discord channel #openttd-help channels a Discord offer, but for how to change fonts best to look at https://wiki.openttd.org/en/Archive/Community/FAQ%20troubleshooting#my-user-interface-is-too-small-to-read-my-font-is-unreadable-or-faulty . And use the font as mentioned by petern ๐ 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:23 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949 15:04:31 <TrueBrain> owh boy, here are the PRs again ... 15:05:30 <TrueBrain> LordAro was still on duty right? ๐ 15:07:01 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947#pullrequestreview-1462770867 15:07:25 <Rubidium_> that's a nice summoning :D 15:07:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10947: Codechange: convert C-style GetTownName API to std::string returning API https://github.com/OpenTTD/OpenTTD/pull/10947 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:08:45 <TrueBrain> it seems it does ๐ฎ 15:09:08 <TrueBrain> always nice, if things actually work ๐ 15:09:24 <TrueBrain> now let's try a preview ๐ 15:09:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949 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:22:30 <TrueBrain> tnx again glx[d] ๐ 15:26:51 <DorpsGek> [OpenTTD/OpenTTD] darkdazmad opened issue #10950: [Crash]: https://github.com/OpenTTD/OpenTTD/issues/10950 15:27:26 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi commented on pull request #10804: Fix #10467: [YAPF] Trains do not use all available tracks https://github.com/OpenTTD/OpenTTD/pull/10804#issuecomment-1577018717 15:29:43 <LordAro> does the crash template not allow setting a title? 15:31:25 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949#pullrequestreview-1462833329 15:33:15 <DorpsGek> [OpenTTD/OpenTTD] darkdazmad commented on issue #10950: [Crash]: -monday 5th june 2023 -darkdazmad https://github.com/OpenTTD/OpenTTD/issues/10950 15:35:15 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949#pullrequestreview-1462841564 15:41:20 <TrueBrain> LordAro: It does. They just don't. ๐ 15:41:47 <LordAro> i see 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) 15:51:00 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #10950: [Crash]: -monday 5th june 2023 -darkdazmad https://github.com/OpenTTD/OpenTTD/issues/10950 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:04 <glx[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1115310078698995813/image.png 16:04:19 <glx[d]> that's the newgrf list for the crash save 16:04:48 <TrueBrain> it crashes on ReadByte? 16:04:50 <TrueBrain> impressive ๐ 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:18 <TrueBrain> does it throw or segfault? 16:07:22 <glx[d]> 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:27 <petern> zbase crashes. On a system with 4GB RAM. 16:19:32 <petern> I wonder... ... 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:13 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10951: Codechange: Reorganise hotkey initialisation. https://github.com/OpenTTD/OpenTTD/pull/10951 16:23:15 <petern> ... 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:30:53 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10951: Codechange: Reorganise hotkey initialisation. https://github.com/OpenTTD/OpenTTD/pull/10951#pullrequestreview-1462944475 16:38:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949 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:35 <TrueBrain> but sometimes 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:49 <petern> Smells like a bit-flip. 17:04:56 <glx[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1115325394581725184/image.png 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:21 <DorpsGek> [OpenTTD/OpenTTD] github-code-scanning[bot] commented on pull request #10951: Codechange: Reorganise hotkey initialisation. https://github.com/OpenTTD/OpenTTD/pull/10951#pullrequestreview-1463005806 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:06:56 <petern> Ah, okay. 17:08:25 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10951: Codechange: Reorganise hotkey initialisation. https://github.com/OpenTTD/OpenTTD/pull/10951#pullrequestreview-1463009066 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:11:42 <petern> (with true) 17:12:18 <TrueBrain> it is just silly that `GetItem` can create an item ๐ 17:12:35 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10951: Codechange: Reorganise hotkey initialisation. https://github.com/OpenTTD/OpenTTD/pull/10951 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:19:36 <petern> Bit more than 2. 17:20:08 <LordAro> i see 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:20:58 <LordAro> mm... 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:30 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952 17:26:40 <TrueBrain> so basically, all these backends make minidumps 17:26:58 <petern> Oh comment error. 17:27:52 <glx[d]> TrueBrain: do you intend to run backport script with --mark-done ? 17:27:58 <TrueBrain> owh, I forgot 17:27:59 <TrueBrain> let me fix that 17:28:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952 17:29:07 <TrueBrain> glx[d]: all done! Tnx for the reminder ๐ 17:29:42 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952#pullrequestreview-1463047008 17:29:53 <TrueBrain> nitpick alert! 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:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952#pullrequestreview-1463049196 17:30:54 <TrueBrain> fuck it, I am in a nitpick mood ๐ 17:32:04 <TrueBrain> glx[d]: nah, it is in there ๐ 17:32:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10914: Feature: allow to do a hostile takeover of an AI company (in singleplayer) https://github.com/OpenTTD/OpenTTD/pull/10914 17:32:44 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952 17:33:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952#pullrequestreview-1463054452 17:33:12 <petern> Locusts 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:56 <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:45:30 <TrueBrain> (read: me) 17:46:02 <frosch> just enable coredumps 17:48:42 <JGR> That is likely to impact dedicated servers 17:48:50 <TrueBrain> in what way? 17:50:51 <JGR> Perhaps I'm misunderstanding this, I should go read up on sentry when I've got some time 17:51:58 <TrueBrain> ghehe; basically, from what I can tell, what we can pull off is: 17:51:58 <TrueBrain> - Opt-in automatically send crash reports to us, which include a minidump (read: stacktraces), gamelog, other metadata 17:51:58 <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:52:43 <DorpsGek> [OpenTTD/OpenTTD] darkdazmad commented on issue #10950: [Crash]: segfault on game-start https://github.com/OpenTTD/OpenTTD/issues/10950 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:12:36 *** Wolf01 has joined #openttd 18:29:57 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10952: Codechange: Split GetItem with GetOrCreateItem. https://github.com/OpenTTD/OpenTTD/pull/10952 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:34:51 <LordAro> sorry :p 18:36:51 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #10950: [Crash]: segfault on game-start https://github.com/OpenTTD/OpenTTD/issues/10950 18:41:19 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #10950: [Crash]: segfault on game-start https://github.com/OpenTTD/OpenTTD/issues/10950 18:42:44 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/433ec6b5bd4f5148b8e41bc2ddb7c83490c3cdbd 18:42:45 <DorpsGek> - Update: Translations from eints (by translators) 18:44:00 *** gelignite has quit IRC 18:53:24 <DorpsGek> [OpenTTD/OpenTTD] darkdazmad commented on issue #10950: [Crash]: segfault on game-start https://github.com/OpenTTD/OpenTTD/issues/10950 18:55:58 <LordAro> previous version? deleting baseset while running, perhaps? 18:56:08 *** keikoz has joined #openttd 19:18:21 *** gelignite has joined #openttd 19:39:12 *** debdog has quit IRC 19:48:07 *** gelignite has quit IRC 19:50:04 *** debdog has joined #openttd 19:52:22 *** HerzogDeXtEr has quit IRC 19:56:42 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10871: Codechange: replace C-style idioms with C++-style for file name generation https://github.com/OpenTTD/OpenTTD/pull/10871#pullrequestreview-1463297289 19:57:20 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10895: Codechange: replace seprintf with fmt::format/std::to_string https://github.com/OpenTTD/OpenTTD/pull/10895#pullrequestreview-1463298812 19:57:37 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949#pullrequestreview-1463299688 19:57:43 <LordAro> Rubidium_: your move :p 20:00:56 *** Tirili has joined #openttd 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 21:05:12 *** keikoz has quit IRC 21:13:17 *** Wolf01 has quit IRC 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:18:34 <discord_user_03329cf> Flag? 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:04 <discord_user_03329cf> Damn 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:25:37 <discord_user_03329cf> Yeah 21:25:53 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10871: Codechange: replace C-style idioms with C++-style for file name generation https://github.com/OpenTTD/OpenTTD/pull/10871 21:26:03 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10895: Codechange: replace seprintf with fmt::format/std::to_string https://github.com/OpenTTD/OpenTTD/pull/10895 21:26:16 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10949: Codechange: replace C-style string backing of StringBuilder with std::string https://github.com/OpenTTD/OpenTTD/pull/10949 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:37 <discord_user_03329cf> Yeah 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:03 <Rubidium_> thanks LordAro 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:37:10 <pickpacket> lol 21:38:23 <discord_user_03329cf> https://cdn.discordapp.com/attachments/1008473233844097104/1115394208665194567/IMG_2593.png 21:38:23 <discord_user_03329cf> https://cdn.discordapp.com/attachments/1008473233844097104/1115394209046864034/IMG_2594.png 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:40:48 <discord_user_03329cf> https://cdn.discordapp.com/attachments/1008473233844097104/1115394819347464305/Screenshot_2022-02-17-17-58-08-601_com.google.android.googlequicksearchbox.jpg 21:40:48 <discord_user_03329cf> https://cdn.discordapp.com/attachments/1008473233844097104/1115394819716554814/Screenshot_2022-02-17-17-58-23-421_com.google.android.googlequicksearchbox.jpg 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:18:29 <andythenorth> it does the job 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:43:06 *** Kitrana has joined #openttd 22:45:14 *** Kitrana1 has joined #openttd 22:51:04 *** felix_ has joined #openttd 22:51:09 *** Kitrana has quit IRC 22:58:34 *** felix has quit IRC 23:03:48 <zephyris> https://cdn.discordapp.com/attachments/1008473233844097104/1115415707312734228/opengfx2_hacktrial.png 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 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