IRC logs for #openttd on OFTC at 2023-05-11
β΄ go to previous day
00:32:35 <TallTyler> I also vote for 0, following the industry view on the map
00:34:08 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
00:53:00 *** m3henry has quit IRC (Quit: m3henry)
03:02:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:24:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
05:48:16 *** gelignite has joined #openttd
07:42:52 *** axet has quit IRC (Quit: Leaving.)
07:53:25 <petern> WTF, I had some mosfets arrive yesterday, and I've already lost them.
07:53:52 <petern> Individually, but it was 5 in a small antistatic bag.
08:05:11 <Citizen_Kane_23> Making something?
08:05:22 <TrueBrain> a sensor to detect mosfets, I am sure π
08:06:00 <petern> Not if I can't find them...
08:06:55 <TrueBrain> last week I searched for a ... while longer than I want to admit for my multimeter
08:07:00 <TrueBrain> it was right next to me
08:07:05 <TrueBrain> but so used of it being there .. that I couldn't see it
08:13:01 <andythenorth> Big Clive moments?
08:13:17 <andythenorth> Donβt let the magic smoke out
08:59:31 <TrueBrain> why only SE petern ?
09:02:01 <petern> Just feels wrong showing a count of industries in game.
09:02:22 <TrueBrain> why? (honest question, to be clear; I don't see what the difference is and like to understand :D)
09:07:42 <petern> Can't explain! Something about exposing data that is part of gameplay (working out the best set of industries to serve)
09:08:00 <TrueBrain> indirectly it is already exposed ofc in the industry directory
09:08:08 <TrueBrain> but you have to eye-ball that now π
09:09:42 <TrueBrain> I have no opinion about it btw; mostly what I was thinking if it is SE only, how long it will take for a ticket to come on: the SE shows different things in the same window as in-game π
09:11:22 <TrueBrain> I think this argument works fine: we would only expose the fundable industry count, and not the rest, is silly in-game
09:11:29 <TrueBrain> so it turns out, I agree with your SE-only π
09:12:10 <petern> Ah yes that was another point that I'd already forgotten π
09:12:40 <petern> But yes, it should be obvious that SE gives you more tools for this sort of thing than game play... it's an SE π
09:13:21 <petern> (Damn "a" if you say it long, "an" if you say it abbreviated...)
09:13:39 <TrueBrain> haha, English is weird π
09:20:50 <petern> Huh, weird. Windows updated and now the WSL cursor is different.
09:21:33 <petern> Ah, now it's changed. Weird.
09:40:00 *** Flygon has quit IRC (Remote host closed the connection)
09:47:58 <LordAro> doesn't the map already show industry numbers?
09:49:26 <glx[d]> It does but in tiny font
09:50:38 <glx[d]> Hmm ld failed again on CI
09:54:07 <TrueBrain> the gift that keeps on giving
09:54:11 <TrueBrain> remove mingw you say? π
09:54:20 <TrueBrain> force everyone to use a proper solution, like WSL, you say? π
09:55:25 <glx[d]> Well using ldd might fix it
09:58:01 *** felix has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** hnOsmium0002 has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** nebulabc has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** esselfe has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** nik has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** Ttech has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** rightnut has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** greeter has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** xT2 has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** dale has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** dwfreed has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** twpol has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** Extrems has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** colde has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** mindlesstux has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** Smedles has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** APTX has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:01 *** birdjj has quit IRC (charon.oftc.net resistance.oftc.net)
09:58:15 *** Smedles has joined #openttd
09:58:15 *** esselfe has joined #openttd
09:58:15 *** dwfreed has joined #openttd
09:58:15 *** rightnut has joined #openttd
09:58:15 *** greeter has joined #openttd
09:58:15 *** Extrems has joined #openttd
09:58:15 *** mindlesstux has joined #openttd
10:00:46 *** hnOsmium0002 has joined #openttd
10:00:46 *** nebulabc has joined #openttd
10:02:02 <petern> Somehow I never noticed them.
10:04:24 <Rubidium_> glx[d]: did it run out-of-memory?
10:05:31 <Rubidium_> if so, maybe run 'make openttd' first, and then the normal 'make' to not have two massive link processes running in parallel
10:06:06 *** Webster has quit IRC (Ping timeout: 480 seconds)
10:13:00 <petern> Added by r11474, on the sly.
10:37:06 <glx[d]> `C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bfd_new_link_order failed` <-- it's not OOM this time it seems
10:40:33 <petern> But that's x86... Hmm.
11:18:35 <Rubidium_> maybe not adirect OOM but a malloc that returns nullptr and that lets bfd_new_linke_order fail?
11:54:58 <gnomechomsky> were normal signals removed from master?
11:55:53 <gnomechomsky> hidden behind a setting
11:59:08 *** EmperorJake has joined #openttd
11:59:08 <EmperorJake> Path signals are the new normal
11:59:13 <Eddi|zuHause> i think you have a strange definition of "normal"
12:04:47 <petern> They should be removed.
12:04:58 <LordAro> also they've been hidden since 12.0
12:05:07 <petern> But alas it's not possible π
12:05:39 <petern> Build an AI to analyse the best signal placement for block to path replacement π
12:12:25 <gnomechomsky> Whats the signal look ahead penalty mean in yapf?
12:13:05 <Eddi|zuHause> "it's complicated"?
12:13:37 <Eddi|zuHause> i believe it was meant to be some kind of load balancing
12:16:05 <gnomechomsky> I dont think it adds real penalties the cost but idk
12:16:37 <Eddi|zuHause> no, there's some weird quadratic formula that calculates a penalty
13:09:55 <petern> `args[1] = (uint64)(size_t)details` ... nice
13:11:47 <petern> SetDParam really needs some love.
13:14:06 <glx[d]> Could use std::variant, free type check on param read
13:15:04 <petern> Yeah but also in this case it's storing a pointer to a static char buffer -- which makes that hard to convert to std:;string.
13:16:10 <glx[d]> Worse, it's storing a pointer into an uint64 array
13:19:33 <glx[d]> But switching FormatString to std::string is a deep rabbit hole
13:20:28 <glx[d]> Though most of the surrounding is done
13:20:36 <Eddi|zuHause> we should have listened to people and reimplemented the game in like Java or whatever 15 years ago
13:21:36 <Eddi|zuHause> about once a year someone suggested we do that with some random language
13:22:15 <glx[d]> We should have used VB π
13:22:45 <petern> Anyway, my thought is replace the global SetDParam stuff with a local parameter struct filled as needed. But it would be slower.
13:23:26 <Eddi|zuHause> i think the last one wasn't even that long ago, and he started by taking a version from before the C++ conversion, because that apparently was easier?!?
13:24:00 <glx[d]> Not easier but without some features they didn't like
13:24:57 <pickpacket> Eddi|zuHause: you know the game should be written in a hodgepodge of languages from different eras!
13:55:22 <Rubidium_> the main "problem" with SetDParamStr is that usually a std::string_view is enough, but in some cases (like the error GUI and some news things?!?) it copies out the strings (stredup), which either makes things less efficient (alloc, copy, dealloc for each SetParamStr) or harder (two StringParameters, one which copies the strings and one that doesn't).
13:56:14 <Rubidium_> though I think the first step would be moving the formatting to C++, and then handle the string parameters and stuff
13:59:13 <Rubidium_> on the other hand, I expect petern to already have a patch for it
14:02:36 <petern> Not sure I follow #10807
14:03:21 <petern> Lack of clarity between "current train" and "other trains" for me.
14:06:30 <petern> Linking to the other day on Discord isn't really helpful.
14:09:35 <gnomechomsky> It's just about pathfinding so every train is another train I guess
14:09:52 <gnomechomsky> There isn't this sort of distinction
14:10:53 <gnomechomsky> Is there anything I could explain in particular?
14:11:56 <LordAro> discord (or text chat in general) is ephemeral - if it's not in the PR, it might as well not exist
14:12:05 <LordAro> anything explanatory that's in discord needs to be in the PR
14:12:51 <gnomechomsky> What's missing in the PR?
14:15:25 <LordAro> "15:03:21 < petern> Lack of clarity between "current train" and "other trains" for me."
14:18:06 <Eddi|zuHause> something tells me that this should be a different penalty
14:18:37 <Eddi|zuHause> "reservation per tile" penalty vs "any reservation at all" penalty
14:21:36 <gnomechomsky> I'm not so sure on the justification of the per tile one. If there's a short train in a big block, the cost will vary a lot depending on if the short train has just entered the block or is at the end of it
14:22:21 *** Maantje00 has joined #openttd
14:22:37 <gnomechomsky> Theoretically maybe it should be higher if the train has just entered, but it adds a penalty equal to 3 45 degree turns per tile which is huge imo. especially if the short train is fast
14:23:21 <gnomechomsky> Perhaps we could add a separate penalty but the per tile one should be made quite small like maybe 50 or less
14:25:01 *** D-HUND is now known as debdog
14:26:49 <TrueBrain> hmm ... testing is tricky π
14:27:24 <TrueBrain> as I installed the signing request key on our repo, and threw it from my local machine .. so I can't test it on my fork π
14:27:32 <TrueBrain> time to create another branch in our upstream .. don't see another way π
14:30:17 <TrueBrain> also made sure that JGR can, if he likes, request survey-keys for JGRPP; so they become verified survey results. Fully optional btw, but I tried to make it as easy as I could π
14:33:33 <JGR> Are you interested in survey results from my branch?
14:33:42 <TrueBrain> no, are you, is the question π
14:33:45 <JGR> I didn't think that those would be much use to you TBH
14:34:01 <TrueBrain> and it might, to see what is popular there. But at least I have the door open π
14:34:54 <JGR> I haven't really looked properly at the survey related stuff yet, I am a bit behind
14:35:13 <TrueBrain> no rush or worries; just so you know, if you like, you can join. And if not, all is well too π
14:40:28 <JGR> I will take a look and let you know, many thanks
14:40:47 <TrueBrain> I just didn't want to make the same mistake we did in the past, and make it very difficult to integrate later π Hihi π
14:40:54 <andythenorth> glx[d]: Squirrel
14:41:02 <TrueBrain> now the main question .... why do I get 403s back from the server .... I have no code-path that allows for a 403 ...
14:42:45 <TrueBrain> haha, cloudflare being cloudflare .. π
14:42:51 <TrueBrain> `<title>Just a moment...</title>`
14:42:55 <TrueBrain> no, you can't validate me π
14:50:10 <TrueBrain> `Detects basic SQL authentication bypass attempts` .. on a piece of JSON? Impressive ...
14:52:53 <TrueBrain> ah, because we don't say it is a JSON payload .. so the WAF goes all crazy π Funny π
15:19:26 *** HerzogDeXtEr has joined #openttd
15:23:01 *** gelignite has quit IRC (Quit: Stay safe!)
15:48:06 <TrueBrain> not sure if I should ignore surveys with invalid keys (which is different from having no key) or not
15:48:14 <TrueBrain> when they are invalid, it is very likely someone is "trying to be funny"
15:49:43 <TrueBrain> that means #10719 is now ready for review
15:58:05 <TrueBrain> glx[d]: I now have a run that ends with `could not read symbols: memory exhausted`
16:04:22 <TrueBrain> yippie, survey-key also works .. so I now have verified survey results in the backend π
16:22:01 <LordAro> does transmitting a survey via the crashlog actually work?
16:22:09 <LordAro> i'd think that's a bit too much for a signal handler to be doing...
16:38:33 <JGR> Strictly speaking a signal handler should not call malloc, but that is a lost cause in practice
16:39:35 <JGR> If you can manage to write out a crash save then sending a survey as well is not much of a stretch
16:43:00 <TrueBrain> Couldn't have worded it better π
16:56:13 <petern> You could perhaps detect on start up if it crashed last time...
16:56:39 <petern> But yeah, the crash save already breaks all the rules π
16:59:49 <TrueBrain> That is what breakpad does. Store just enough info to send a crash report on next start
17:00:12 <TrueBrain> Crashpad starts an extra process to let that process inspect and send
17:01:08 <TrueBrain> But sending just a survey seems to work fine π
17:01:40 <TrueBrain> Hopefully the survey never crashes .. crash of a crash of a crash of a ... ? π
17:02:09 <petern> Hmm, are we missing something? Can you just set a flag and then somehow check that later...
17:04:12 <TrueBrain> That is about SIGTERM
17:04:27 <TrueBrain> Which you can even ignore if you like :p
17:04:38 <TrueBrain> SIGABRT is a bit different π
17:04:55 *** Wormnest has joined #openttd
17:04:56 <petern> Well, it mentions SIGTERM but only in the example handlers, not the surrounding text.
17:18:25 <frosch> TrueBrain: iirc signal handlers do not recurse. a signal during signal-handling is always an immediate kill
17:22:20 <TrueBrain> frosch: Boooooooooo
17:23:40 <JGR> You can handle signals within your signal handler if you want
17:23:52 <JGR> It's explicitly turned off in the vanilla crash log handler
17:25:29 <TrueBrain> I was puzzled by 10808, but luckily so is the compiler
17:27:34 <frosch> do you also receive all those github notifications about failed actions? or only info@ ?
17:27:58 <TrueBrain> If you are the creator you get notifications
17:28:05 <glx[d]> github notifications everywhere π
17:29:47 <petern> "Not listened to this album for a while..." "Christ it's 26 years old..."
17:31:20 <glx[d]> and if that doesn't fix recent problems we still have another option π
17:31:34 <petern> FFS, must remember to compile before push...
17:32:27 <petern> Or at least, let it finish :p
17:32:28 <TrueBrain> petern: At least this makes more sense π
17:33:11 <petern> I've started at this one for so many months, it's committed in various branches I have but somehow not just submitted...
17:33:41 <glx[d]> but stringID is enough for boundings ?
17:35:41 <glx[d]> I always forget we have overrides using GetString internally
17:45:44 *** herms has quit IRC (Quit: Ping timeout (120 seconds))
18:20:55 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:42:10 <DorpsGek> - Update: Translations from eints (by translators)
18:42:35 <petern> Heh, memory again π
18:56:41 *** gelignite has joined #openttd
19:05:09 *** Wormnest has joined #openttd
19:06:26 *** axet has quit IRC (Quit: Leaving.)
19:32:39 *** esselfe has joined #openttd
19:36:57 *** m3henry has joined #openttd
20:11:44 <Eddi|zuHause> that's an achievement nowadays
20:12:44 <Eddi|zuHause> i remember when i went from a computer with 1GB+2GB swap to a computer with 4GB, and what worked previously immediately went into OOM
20:16:45 <Rubidium_> is it me, or is GetStringWithArgs(buff, STR_JUST_RAW_STRING, &tmp_params, last) not just an expensive strecpy(buff, <string>, last)?
20:17:04 *** m3henry has quit IRC (Quit: m3henry)
20:17:15 *** m3henry has joined #openttd
20:17:28 <petern> I wondered about that, but I wasn't sure if any control codes in the raw string would do weird things.
20:18:16 <petern> I then promptly forgot about it π
20:18:41 <petern> Still haven't found these MOSFETs... wtf.
20:22:29 <Rubidium_> hmm, SCC_RAW_STRING_POINTER goes through FormatString... so maybe not a direct strecpy
20:29:46 <petern> "final link failed: memory exhausted."
20:30:10 <petern> Get rid of MinGW right? π
20:31:49 <glx[d]> because now it's using ninja and lld
20:32:37 <glx[d]> and seems to work for #10806
20:33:44 <glx[d]> while #10808 is still on make and ld
20:48:14 *** m3henry has quit IRC (Quit: m3henry)
20:49:27 *** keikoz has quit IRC (Ping timeout: 480 seconds)
20:57:44 <petern> Why didn't that cancel the approval...
21:02:16 <LordAro> it does seem a bit weird about it sometimes
21:02:32 <LordAro> don't know if it does some detection for "just a rebase"
21:05:18 <TrueBrain> I mostly see that happen when using the UI to rebase
21:26:15 <petern> Apparently it's the trees.
21:28:03 <andythenorth> "think I solved it"
21:28:11 <andythenorth> oh should it be Moar?
21:28:42 <petern> Have one option called "4k maps are dumb"
21:36:53 <petern> Do I want to do a silly amount of miles this weekend...
21:56:14 <Eddi|zuHause> what's a silly amount? 10? 100? 1000?
21:57:27 <Eddi|zuHause> split across how many days?
21:58:00 <Eddi|zuHause> i was assuming "weekend" meant more than one
21:58:33 <Eddi|zuHause> 200km is like one tour de france etappe?
22:01:00 <petern> Just got to remember to eat I suppose.
22:01:23 <petern> My normal rule of no cake because I've not earned it can get in the bin.
22:03:11 <TrueBrain> The cake? Or the rule? π
22:03:11 *** ChanServ sets mode: +v tokai
22:03:37 <Eddi|zuHause> the cake is a lie
22:03:55 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:10:09 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:29:14 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:01:19 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:39:13 *** gelignite has quit IRC (Quit: Stay safe!)
continue to next day β΅