IRC logs for #openttd on OFTC at 2023-05-10
00:01:48 <glx[d]> worked around (basically replaced the "wrong" value with 0) only for the build to fail later with ```In file included from D:/developpement/GitHub/glx22/OpenTTD/src/ini.cpp:15:
00:01:48 <glx[d]> H:/msys64/clang64/include/c++/v1/fstream:574:19: error: use of undeclared identifier 'L__mdstr'
00:01:48 <glx[d]> __file_ = fopen(__s, __mdstr);
00:01:48 <glx[d]> ^
00:01:48 <glx[d]> D:/developpement/GitHub/glx22/OpenTTD/src/stdafx.h:213:60: note: expanded from macro 'fopen'
00:01:50 <glx[d]> # define fopen(file, mode) _wfopen(OTTD2FS(file).c_str(), _T(mode))
00:01:50 <glx[d]> ^
00:01:52 <glx[d]> H:/msys64/clang64/include/tchar.h:1131:15: note: expanded from macro '_T'
00:01:52 <glx[d]> #define _T(x) __T(x)
00:01:54 <glx[d]> ^
00:01:54 <glx[d]> H:/msys64/clang64/include/tchar.h:127:16: note: expanded from macro '__T'
00:01:56 <glx[d]> #define __T(x) L##x
00:01:56 <glx[d]> ^
00:01:58 <glx[d]> <scratch space>:38:1: note: expanded from here
00:01:58 <glx[d]> L__mdstr
00:02:00 <glx[d]> ^
00:02:16 <glx[d]> their headers are broken
00:03:10 <glx[d]> ah no, we break their headers
00:03:33 <glx[d]> oups
00:06:54 *** ufo-piloot has quit IRC (Ping timeout: 480 seconds)
00:11:25 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:11:27 *** WormnestAndroid has joined #openttd
00:26:02 *** ufo-piloot has joined #openttd
00:37:06 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10799: Change: Try to better preserve train orders/info when re-arranging vehicle chains.
02:02:17 *** herms has quit IRC (Quit: bye)
02:03:03 *** herms has joined #openttd
02:15:26 *** Wormnest has quit IRC (Quit: Leaving)
02:59:32 *** D-HUND has joined #openttd
03:03:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:40:10 *** keikoz has joined #openttd
04:59:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10801: Codechange: rework Gamelog changes from union to classes
05:21:35 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10801: Codechange: rework Gamelog changes from union to classes
05:25:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
05:39:04 *** axet has joined #openttd
07:30:36 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #10799: Change: Try to better preserve train orders/info when re-arranging vehicle chains.
07:45:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
08:32:00 <DorpsGek> [OpenTTD/OpenTTD] andythenorth commented on pull request #10799: Change: Try to better preserve train orders/info when re-arranging vehicle chains.
08:33:51 <petern> Sensor 1: +37.9ยฐC (low = -273.1ยฐC, high = +65261.8ยฐC)
08:33:56 <petern> I think those limits might be wrong.
08:45:05 <LordAro> well the low limit isn't impossible
09:20:16 *** Flygon has quit IRC (Remote host closed the connection)
09:26:06 *** axet has quit IRC (Quit: Leaving.)
09:56:34 <TrueBrain> pfff, such a classic-thinker-remark to make ๐Ÿ˜›
09:56:35 <TrueBrain> ๐Ÿ˜„ ๐Ÿ˜„
09:56:53 <TrueBrain> I reject your reality and say it is possible! ๐Ÿ˜›
09:58:37 <TrueBrain> euh .. "impossible" .. ugh, typing in the early morning is hard! ๐Ÿ˜›
09:59:19 <TrueBrain> and when I do s/bla/blaaa on Discord, it doesn't send that to IRC .. which is also annoying ๐Ÿ˜ฆ
10:19:37 <petern> Yes, it "cleverly" edits the last line...
10:19:55 <TrueBrain> it also does it wrong .. as in, you should not do the last slash
10:19:58 <TrueBrain> which is .... wrong
10:35:38 <LordAro> slack did/does that as well, iirc
10:36:04 <TrueBrain> they are both wrong!
10:48:47 <petern> `C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: memory exhausted`
10:48:49 <petern> Nice?
10:57:36 <glx[d]> Openttd is huge
10:58:27 <glx[d]> Oh CI is now using 13.1, was 12.2 some days ago
10:58:46 <LordAro> probably because 13.1 was released a few days ago :)
10:59:04 <glx[d]> Yeah I have 13.1 in my local mingw
11:29:35 <petern> Hmm, do I want a router that can run Pi-Hole in a container...
11:42:25 *** keikoz has joined #openttd
11:43:20 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10801: Codechange: rework Gamelog changes from union to classes
11:53:51 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10800: Codechange: Iterator loops
11:59:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10800: Codechange: Iterator loops
12:00:59 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on issue #10681: [Crash]: Segmentation fault
12:12:59 <glx[d]> hmm external upload service and bug reports
12:16:44 *** axet has joined #openttd
12:18:10 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi commented on issue #10561: [Bug]: Game doesn't detect keyboard layout change for hotkeys
12:26:15 *** ag has quit IRC (Quit: User went offline on Discord a while ago)
12:27:13 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10800: Codechange: Iterator loops
12:27:36 <glx[d]> unless I made a mistake in my analysis
12:34:02 <Citizen_Kane_23> petern: Is that even possible?
12:34:11 <petern> Yes.
12:34:15 <Citizen_Kane_23> If so it's amazing then
12:38:07 <DorpsGek> [OpenTTD/OpenTTD] github-code-scanning[bot] commented on pull request #10800: Codechange: Iterator loops
12:44:44 <petern> It's not really that surprising, many routers run a locked-down Linux system.
12:50:00 <LordAro> routers can be a standard linux system, if you so choose
12:50:22 <LordAro> dunno if there's anything for windows, tbf
12:54:05 <petern> Yes, run under WSL ๐Ÿ˜‰
12:54:12 <LordAro> lol
12:55:03 <TrueBrain> how lovely .. all this C++-ifying of textfile, means my survey GUI is now 3 lines, instead of 30+ with weird allocs ๐Ÿ˜›
13:01:06 <TrueBrain> `welsh.txt:224: info: STR_UNITS_HEIGHT_SI: Param idx #0 'COMMA' doesn't match with template command 'DECIMAL'` so many warnings!
13:01:25 <TrueBrain> didn't we fix that for translators? Do they now have to do that boring job? ๐Ÿ˜›
13:02:06 <glx[d]> eints will fix it
13:02:16 <TrueBrain> no, it will move the problem to the translator
13:02:20 <TrueBrain> they need to click through all those translations
13:02:28 <TrueBrain> and fix the right thing
13:02:34 <TrueBrain> this seems like a string/replace
13:02:57 <TrueBrain> yeah, honestly, we really should do that for the translators
13:03:00 <TrueBrain> far less work for us than for them
13:05:19 <glx[d]> hmm so with mingw CI now slowly moving to gcc 13.1 I'll need to fix some new warnings
13:06:38 <TrueBrain>
13:06:38 <TrueBrain> all 4 yellow looks weird
13:06:43 <TrueBrain> but this also looks off ๐Ÿ˜› Suggestions?
13:07:15 <glx[d]> I see 2 yellow and 2 oranges
13:07:21 <TrueBrain> yes; 4 yellow looks odd
13:07:25 <TrueBrain> this looks off too
13:08:16 <glx[d]> red is a no for sure
13:08:33 <TrueBrain>
13:08:33 <TrueBrain> looks really sketchy
13:08:37 <glx[d]> maybe blue or purple for the top ones
13:09:26 <gnomechomsky> does anyone understand the pathfinder?
13:09:34 <gnomechomsky> Im going to try and work on this one
13:09:37 <gnomechomsky> seems hard though
13:09:38 <glx[d]> it's magic ๐Ÿ™‚
13:10:09 <glx[d]> well it's an A* algorithm implementation
13:10:35 <FLHerne> hm, the second example there puzzles me
13:11:47 <FLHerne> the first one can be explained as a pf costs thing, especially with the (imo buggy) thing that short trains in the way have low cost
13:12:02 <TrueBrain> how can I change the text colour on a button? ๐Ÿ˜„
13:12:07 <TrueBrain> black on green looks weird ..
13:12:18 <glx[d]> SetTextStyle
13:12:29 <TrueBrain> tnx
13:12:45 <FLHerne> oh, second one is the same, but the cost merely for the tight 90ยฐ corners is more than that of a short train?
13:12:53 <FLHerne> really daft
13:12:56 <glx[d]> cost for occupied station is weird IIRC
13:12:59 <FLHerne> if that's what it is
13:13:09 <gnomechomsky> How do I identify my trains when I'm using the debugger? E.g. how do I get the display name for a Train object?
13:13:22 <glx[d]> unit_number
13:13:29 <gnomechomsky> thanks
13:14:16 <gnomechomsky> ah and then to get the display name from the unit number?
13:14:49 <glx[d]> default name is "Train <unit_number>" so
13:15:27 <gnomechomsky> Ah, i was thinking there could be like an off by one or something
13:15:36 <gnomechomsky> but even so how would I confirm?
13:15:44 <TrueBrain> `NWidget(WWT_PUSHTXTBTN, COLOUR_GREEN, WID_NAS_PREVIEW), SetMinimalSize(71, 12), SetFill(1, 1), SetDataTip(STR_NETWORK_ASK_SURVEY_PREVIEW, STR_NULL), SetTextStyle(TC_WHITE),` .. does not change the colour to white ๐Ÿ˜ฆ
13:18:39 <glx[d]> colour is hardcoded in the string ?
13:20:57 <TrueBrain> ah, yes, smart cookie
13:20:57 <TrueBrain> tnx ๐Ÿ™‚
13:20:59 <glx[d]> because `DrawLabel(r, this->type, clicked, this->text_colour, this->widget_data, this->align, this->text_size);` uses the colour defined with SetTextStyle() (TC_BLACK if not manually set)
13:22:24 <glx[d]> vast majority of colour tags in strings need to be removed (but it's a huge job)
13:22:38 <TrueBrain> I might as well do that while at it ๐Ÿ˜›
13:22:45 <TrueBrain> so no more `{BLACK}` as prefix?
13:23:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #10802: Update: help out translators and do the COMMA -> DECIMAL for them
13:23:40 <glx[d]> depends on where the string is used, I'm not sure all text drawing code has been changed to TC_BLACK as default
13:23:52 <glx[d]> petern: might know better
13:23:58 <FLHerne> yeah, it's yapf costs being stupid
13:24:17 <TrueBrain> for 10802, either we merge it before tonight, or it becomes invalid ๐Ÿ˜„ The eints docs do not describe what to actually do in this scenario ..
13:24:46 <petern> Anything that uses DrawString directly still uses TC_FROMSTRING.
13:24:50 <FLHerne> the trains are only one tile, so the total cost of a train being in the way is yapf.rail_pbs_cross_penalty = 300
13:25:24 <petern> (directly without specifying colour. All the standard widget stuff uses black by default now, but stuff in other windows may not)
13:25:25 <FLHerne> whereas yapf.rail_curve45_penalty = 100 and the empty bays have four extra corners compared to the occupied straight one
13:25:29 <FLHerne> gnomechomsky: ^
13:25:47 <TrueBrain> do we want all colours gone in strings?
13:25:53 <FLHerne> you should find that if you create a scenario identical but for longer trains it works
13:26:00 <petern> I think eventually yes, but not yet.
13:26:09 <TrueBrain> do you already want me to do it in new GUIs?
13:26:15 <FLHerne> or change the penalties (did the PR to hardcode the penalties get merged?)
13:26:58 <petern> Might as well.
13:27:02 <TrueBrain> okiedokie
13:27:25 <petern> It gives the layouters slightly less work to do ๐Ÿ˜‰
13:28:13 <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #10802: Update: help out translators and do the COMMA -> DECIMAL for them
13:28:25 <glx[d]> well we had recently
13:28:43 <glx[d]> and eints didn't yell at us
13:28:44 <petern> TBH I didn't check every string was correctly converted, I assume you had help from a tool ๐Ÿ™‚
13:29:02 <TrueBrain> petern: I used `sed`. Then `make` to tell me which I did wrong ๐Ÿ˜›
13:29:09 <TrueBrain> were no more warnings after that commit ๐Ÿ™‚
13:29:13 <petern> Nice.
13:29:21 <TrueBrain> so as long as `english.txt` is untouched, we should be good ๐Ÿ˜›
13:29:52 <gnomechomsky> FLHerne: so should the penalties be changed or the issue closed ?
13:30:05 <FLHerne> gnomechomsky: well, it's a real issue
13:30:11 <TrueBrain> glx[d]: yeah, and next eints push looked fine, so this seems to be the correct way to handle this ๐Ÿ™‚
13:30:53 <glx[d]> worst case is eints reverting some changes if a translator touched a string I guess
13:31:01 <TrueBrain>
13:31:01 <TrueBrain> petern: : the blue I can fix easily, but the caption should have been white. Will this be a global thing, or does every window has to tell the caption text should be white?
13:31:13 <FLHerne> gnomechomsky: adjusting penalties is likely to fix it but cause other problems; IMO the fundamental issue is that YAPF calculates the cost of a train in the way per-tile
13:31:29 <FLHerne> which is nonsensical because a short train is just as obstructive as a long one
13:32:07 <FLHerne> so ideally patch yapf/yapf_costrail.hpp to calculate something more sensible
13:32:19 <glx[d]> should be possible to make caption default to TC_WHITE
13:32:24 <petern> Caption is awkward, sometimes it should be dark, sometimes white.
13:32:43 <TrueBrain> I will add `SetTextStyle(TC_WHITE),` ๐Ÿ™‚
13:33:11 <TrueBrain> I thought they were all white ๐Ÿ™‚
13:33:34 <TrueBrain> can't find one that isn't ๐Ÿ˜›
13:33:48 <TrueBrain> owh, Cargo Flow Legend! But that is a bug ...
13:33:56 <petern> lol
13:34:18 <petern> White news window... but that uses a fake caption anyway, so
13:34:27 <TrueBrain> companies have multi-colour
13:34:32 <TrueBrain> but it really seems white is the default?
13:34:35 <gnomechomsky> FLHerne: What's the downside of having an infinite cost for obstructions?
13:35:02 <gnomechomsky> Ah I guess the train could take a really roundabout route to try and overtake one in front?
13:35:04 <FLHerne> gnomechomsky: you don't want your train to go around the entire map just to avoid waiting
13:35:08 <FLHerne> yes
13:35:24 <glx[d]> ` this->text_colour = tp == WWT_CAPTION ? TC_WHITE : TC_BLACK;` maybe
13:35:41 <TrueBrain> it is what I typed atm; pretty sure there are nicer solutions ๐Ÿ˜„
13:35:57 <gnomechomsky> Maybe the value should just be fixed and boosted to something that works with most waiting bays?
13:36:16 <TrueBrain>
13:36:16 <TrueBrain> pretty?
13:36:48 <FLHerne> at the moment, the cost of a stopped train in the way is effectively yapf.rail_pbs_cross_penalty * the number of tiles it occupies, which causes very short trains to have an impractically low penalty
13:36:51 <glx[d]> looks nice
13:37:18 <FLHerne> so yes, I think having a fixed value or possibly a floor would be better
13:37:27 <gnomechomsky> how about the penalty of an obstructing train is multiplied by the time spent waiting?
13:37:34 <FLHerne> that's not entirely trivial because YAPF doesn't really know about 'trains' being in the way
13:37:41 <FLHerne> only their track occupations, iirc
13:37:54 <glx[d]> for stations it should probably be yapf.rail_pbs_cross_penalty * length of station
13:38:04 <gnomechomsky> So if the train in the way clears quickly, you'll take the shorter route, if it stays stopped for a while and there's still a better route, you'll select the other route?
13:38:10 <FLHerne> so you need something that counts the first occupied tile of a segment and adds a penalty or something
13:38:23 <FLHerne> that would be nice in principle I think
13:38:40 <FLHerne> might be complicated to add given how it works now
13:39:33 <FLHerne> glx[d]: I don't see how stations are relevant here
13:39:57 <FLHerne> (although the pathfinder has other problems with them)
13:40:16 <glx[d]> here it's not, but if station is longer that train it's calculated weirdly IIRC
13:41:05 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
13:42:09 <FLHerne> glx[d]: you mean yapf.rail_longer_platform_penalty ?
13:42:32 <FLHerne> there's a yapf.rail_longer_platform_per_tile_penalty but that's 0 by default
13:43:25 <TrueBrain> `An unexpected error has occurred and we've been automatically notified. Errors are sometimes temporary, so please try again. ` .. I killed GitHub! Well, I think it was already damaged, but what-ever ๐Ÿ˜›
13:44:37 <glx[d]> I fear #10802 will fail because mingw i686 is on 13.1 for this run
13:44:46 <FLHerne> gnomechomsky: anyway, for train pathfinding look at the list of costs in openttd.cfg and at yapf_costrail.hpp ; most of the bugs will be there :p
13:44:54 * FLHerne afk for a bit
13:45:00 <gnomechomsky> FLHerne: I think you could do it by passing a pointer to the vehicle down to ReservationCost() and then multiplying the penalty by the waiting time
13:45:12 <gnomechomsky> there's a counter in the vehicle for time spent waiting at a signal i think
13:45:20 <TrueBrain> glx[d]: nothing I can't force ๐Ÿ™‚
13:45:23 <FLHerne> that sou.ds
13:45:33 <FLHerne> *that sounds plausible
13:48:26 <TrueBrain> also, totally non-OpenTTD, I fixed my heat issue
13:48:29 <TrueBrain>
13:48:32 <glx[d]> oh I see why the std::move are useless it's actually a (SQObject)std::move(SQObjectPtr)
13:48:33 <TrueBrain> it has fangs now ๐Ÿ˜„
13:55:58 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #10803: Fix: redundant move in return statement
13:57:13 <TrueBrain> glx[d]: that it works on other compilers ... that is just weird ๐Ÿ˜›
13:57:32 <glx[d]> well it's fine codewise, just useless
13:57:55 <TrueBrain> well, codewise .. you return a Ptr, but you get the Object?
13:58:06 <glx[d]> it's squirrel
13:58:22 <TrueBrain> yeah, you are right, I don't want to know ๐Ÿ™‚
13:58:36 <glx[d]> struct SQObjectPtr : public SQObject
13:59:06 <TrueBrain> I don't ... no, nevermind ๐Ÿ™‚
13:59:28 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10803: Fix: redundant move in return statement
13:59:36 <TrueBrain> you might need to retrigger some jobs, GitHub is having issues ๐Ÿ™‚
13:59:54 <TallTyler> TrueBrain: Interesting, first green buttons I've seen ๐Ÿ™‚
14:00:33 <TallTyler> You do you, but I don't know about introducing another design option for this. To me, green means Confirm
14:00:42 <TallTyler> Do grey buttons not look good?
14:00:44 <TrueBrain> TallTyler: lies! You seen them a lot!
14:00:57 <TallTyler> Oh wait, Generate
14:00:59 <TrueBrain> every new game you start
14:01:00 <TrueBrain> EVERY
14:01:01 <TrueBrain> ๐Ÿ˜„
14:01:12 <TallTyler> Okay, but that's still a big action button
14:01:26 <glx[d]> that's why I suggested blue or purple
14:01:28 <TrueBrain> these are also actions buttons ๐Ÿ˜› Feel free to fiddle around to find better UI
14:01:31 <TrueBrain> but I couldn't find any
14:01:42 <TrueBrain> not without literally introducing a new coloured button
14:02:11 <gnomechomsky> Is there any effort to get trains in waiting bays to clear the bays in order of the longest waiting to the least longest waiting?
14:02:41 <gnomechomsky> currently they don't seem to be ordered (or are ordered by something else in the code e.g. id?)
14:02:46 <petern> Some of those colours are quite... "hmm"
14:03:05 <TallTyler> Did grey buttons not look good?
14:03:07 <petern> Not in your window, that's fine. Just the colours available ๐Ÿ™‚
14:03:15 <TrueBrain> yup, we need more colours
14:03:23 <TrueBrain> TallTyler: grey on grey? No, that looks absolutely terrible ๐Ÿ™‚
14:03:27 <TrueBrain> you don't even see they are buttons
14:03:32 <TallTyler> We do that a lot, though
14:04:05 <TrueBrain> not with floating buttons
14:04:09 <TrueBrain> only with embedded buttons
14:04:16 <TrueBrain> where their context makes them more clear
14:04:16 <TallTyler> Options GUI, FIOS windows, vehicle details, company window
14:04:30 <TallTyler> Not that we should look to company window for inspiration ๐Ÿ˜›
14:04:40 <TrueBrain> but I tried a bunch of combies, this looked best. I am open for others, but please try them out yourself ๐Ÿ™‚
14:05:09 <TallTyler> Ah, I see what you mean regarding floating vs embedded buttons
14:05:21 <TrueBrain> and yes, company window is the worst of all choices there ๐Ÿ˜›
14:05:26 <TrueBrain> still can't believe nobody fixed that ๐Ÿ˜„
14:05:33 <TrueBrain> the buttons are all over the place too
14:05:40 <TallTyler> Ignoring company window, mostly just the options menu uses floating grey buttons that match the window background
14:06:01 <TrueBrain> yeah, but they have context. In a popup dialog it just doesn't work
14:06:50 <petern> Do we have a background colour for popups other than red (this is not an error...)
14:07:05 <TrueBrain> nope
14:07:11 <TrueBrain> at least, I couldn't find any ๐Ÿ˜›
14:07:18 <TrueBrain> so the grey is new, I think
14:07:21 <TallTyler>
14:07:23 <TrueBrain> (and yes, red was terrible :P)
14:07:30 <TrueBrain> owh, you are right, in-game we have those silly blue shit ๐Ÿ˜„
14:07:37 <TallTyler> Also floating buttons ๐Ÿ˜›
14:07:51 <TrueBrain> yeah, okay, you get stuck on what I meant there: yes/no is fine in the same colour
14:07:56 <TallTyler> We don't do red No and green Yes buttons anywhere, do we?
14:07:57 <TrueBrain> but when you add a second colour, it gets weird
14:08:02 <petern> I think that's fine, but also, that blue means "gameplay window"
14:08:15 <petern> So this new one can't be that blue ๐Ÿ™‚
14:08:20 <TrueBrain> for the popup I picked the game options window colour
14:08:24 <TrueBrain> to unite that feeling
14:08:26 <glx[d]> can use settings color
14:08:31 <TallTyler> We tend to use grey for system/settings/etc
14:08:32 <petern> red no/green yes is a bad idea.
14:08:33 <glx[d]> as it affects a setting
14:08:35 <TrueBrain> (as the setting is under game options)
14:08:54 <petern> 1) colour-blind 2) implies one is bad and one is good
14:08:55 <TrueBrain> TallTyler: surprisingly, no -> red, yes -> green is a cultural thing
14:09:04 <TrueBrain> the internet somewhat unified that
14:09:08 <TrueBrain> but .. yeah
14:09:17 <petern> red is stop, green is go. that's different from no/yes tbh.
14:09:28 <TallTyler> Good point
14:09:35 <TrueBrain> what surprises a lot of people at first, I believe in India, people go in full white to funurals
14:09:44 <TrueBrain> as here that would be very very odd, as it is mostly black
14:10:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #10802: Update: help out translators and do the COMMA -> DECIMAL for them
14:10:24 <TrueBrain> I saw this lovely red button to force my pull request to merge .. I pressed it ๐Ÿ˜›
14:10:43 <glx[d]> hehe
14:10:45 <petern> red go button? :p
14:10:49 <TrueBrain> ๐Ÿ˜„
14:11:00 <TrueBrain> in GitHub's case, red is of "danger"
14:11:10 <TrueBrain> which they did pretty well throughout their UI
14:11:18 <glx[d]> like remove repository is in red
14:11:20 <petern> Yup.
14:11:22 <TrueBrain> if a button is red, it means you need to think twice ๐Ÿ˜›
14:11:25 <TallTyler> I wonder if red "danger" is culturally universal ๐Ÿค”
14:11:36 <TrueBrain> the Internet really changed things when it comes to what colours mean, which is funny
14:11:47 <TrueBrain> there is a Vox short of that, which was interesting
14:12:24 <TrueBrain> lot more weird things about colours in different cultures
14:12:52 <TrueBrain> like some having words for light-blue, other than prefixing with light
14:13:08 <TrueBrain> and others just mixing a few colours under the same name we consider different colours
14:13:13 <TrueBrain> the world is so incredibly weird! ๐Ÿ˜„
14:13:52 <TrueBrain> anyway, back to this popup ... grey background was meant to make it more relatable to the game options, where this option is hosted under
14:13:59 <TrueBrain> to unify those two together
14:14:11 <TrueBrain> similar for the yellow buttons, as that was recently introduced there too ๐Ÿ™‚
14:14:34 <TrueBrain> I just need a secondary colour to fit with that; and our palette is ...... small ๐Ÿ˜›
14:14:37 *** HerzogDeXtEr has joined #openttd
14:14:44 <glx[d]> pff I was fearing my PR wouldn't pick the image with 13.1, but it did for x86_64 at least
14:15:30 <TallTyler> I think about this Radiolab episode all the time, about how blue was one of the last colors we invented a word for, because we didn't have a dye for it. People weren't even aware that it was its own color. One of the interviewees tried that on his own daughter.
14:15:50 <TrueBrain> did you also know that blue used to be the colour for girls?
14:15:56 <TrueBrain> it only changed in like 1910 somewhere
14:16:06 <TrueBrain> it is scary recent, that we consider blue for boys
14:16:08 <glx[d]> yeah pink was a male thing
14:16:11 <TallTyler> I did, and dresses were worn by boys until breeching age
14:16:38 <TallTyler> I'm glad those stupid invented norms are going away now, and we only have to deal with them in GUI ๐Ÿ˜›
14:16:48 <glx[d]> pink and red for males because blood nicely blend with it during battles
14:16:49 <TrueBrain> we honestly need more of a styleguide ๐Ÿ˜›
14:16:56 <TrueBrain> every checked out the padding between buttons
14:16:59 <TallTyler> I still think green buttons mean Generate / Go / Confirm
14:17:06 <TrueBrain> petern: has been doing a fine job unifying shit, but boy ......
14:17:25 <TallTyler> Can AndyGPT write us a style guide?
14:17:33 <petern> Oh it's still way too manual for my liking :p
14:17:56 <TrueBrain> TallTyler: again, I am open for other suggestions, but please in the form of a suggestion. If we list all things we don't like about our UI .. ๐Ÿ˜› And for a suggestion, checkout my PR and fiddle around. By far the easiest ๐Ÿ™‚
14:18:16 <petern> And there really are places where it needs to be just slightly different to make it look right.
14:18:34 <TrueBrain> not being lazy, but this is just the best colour-set I could find ๐Ÿ™‚
14:18:52 <petern> Looks fine to me.
14:19:30 <TrueBrain> owh, I only now see that existing buttons in Game Options are grey too
14:19:54 <TallTyler> We could make those yellow ๐Ÿ˜‰
14:19:58 <TrueBrain>
14:19:58 <TrueBrain> those are actually buttons ๐Ÿ˜„
14:20:07 <petern> The yellow tabs were meant to be stand out from the other buttons.
14:20:19 <glx[d]> ``` Windows (windows-latest / x86)
14:20:19 <glx[d]> succeeded May 10, 2023 in 4m 49s ```
14:20:23 <glx[d]> that was fast
14:20:37 <glx[d]> probably one of the fastest run
14:21:23 <TrueBrain> so annoying that changes branches is enough to trigger a full recompile sometimes
14:21:53 <TallTyler> Hmm, need to figure out how to install nlohmann_json
14:22:08 <TrueBrain> vcpkg install ... ๐Ÿ˜›
14:22:18 <TrueBrain> I updated the instruction documents we have for it btw ๐Ÿ™‚
14:23:20 <gnomechomsky>
14:23:43 <gnomechomsky> Why is there ++v->wait_counter on that line?
14:23:53 <gnomechomsky> and a few lines down? The wait counter is already being incremented elsewhere
14:24:05 <TrueBrain>
14:24:06 <TrueBrain> vs
14:24:07 <TrueBrain>
14:24:14 <TrueBrain> the second one is "correct"
14:25:00 <glx[d]> hmm they are info buttons, so blue like blue square road signs ๐Ÿ˜‰
14:25:19 <TrueBrain> README etc are also info buttons
14:25:50 <glx[d]> yeah and they are grey in game options but yellow for newgrf
14:26:16 <TrueBrain> #make-all-buttons-yellow
14:26:37 <TrueBrain>
14:26:37 <TrueBrain> now they are identical to the readme buttons
14:26:46 <TrueBrain> I guess I go for consistency .. although I hate it ๐Ÿ˜›
14:27:30 <TrueBrain> also means
14:27:32 <TrueBrain>
14:27:58 <glx[d]> at least user have to read to find where to click ๐Ÿ™‚
14:28:09 <TrueBrain> dark-patterns we have plenty
14:28:14 <TrueBrain> but this at least is consistent
14:28:31 <TrueBrain> as mentioned before, most windows have their buttons the same colour as the background
14:28:40 <TrueBrain> red on red, blue on blue, grey on grey
14:28:51 <TrueBrain> except for new-game ofc
14:29:03 <TrueBrain> (and NewGRF, and and and :P)
14:29:24 <TrueBrain> I still like network GUIs most
14:29:30 <TrueBrain> they are much nicer on the eye
14:29:36 <TallTyler> Vcpkg is failing to work properly so I canโ€™t try it, but I wouldnโ€™t mind seeing more buttons in dialogues changed from floating to integrated with the window itself
14:29:39 <TrueBrain> (grey buttons, blue background)
14:30:09 <petern> My issue is many of the design choices are TTD-original, and changing that moves us away from TTD.
14:30:15 <glx[d]> do you need help with vcpkg ?
14:30:42 <TrueBrain> petern: it is why I started with WASM for UI ๐Ÿ˜›
14:31:02 <petern> How does that help?
14:31:15 <TrueBrain> "original UI" BaNaNaS download
14:31:18 <TrueBrain> "modern UI"
14:31:22 <petern> Ah
14:31:24 <TrueBrain> problem solved ๐Ÿ˜„
14:31:31 <TrueBrain> the weirdos can keep their original stuff ๐Ÿ™‚
14:31:42 <petern> The weirdos can use their new stuff
14:31:50 <TrueBrain> ๐Ÿ˜„ ๐Ÿ˜„
14:31:55 <glx[d]> xml ui ๐Ÿ™‚
14:32:10 <TrueBrain> well, no I was looking for WASM UI mostly to help Android port
14:32:19 <TrueBrain>
14:32:31 <TrueBrain> ugh, I was going to stop doing this, as there are 256 combinations .. I am not going to post them all ๐Ÿ˜›
14:32:59 <petern> Get Andy to choose via NewGRF callback.
14:33:44 <TrueBrain> I am just going to make the UI as boring as the rest, so it is consistent .. and someone else can deal with the "but how to make it look pretty" ๐Ÿ˜›
14:33:46 <glx[d]> a big "This job failed" thanks github, very helpful
14:35:43 <TrueBrain> lol, seems even new pushes aren't announced (in a timely manner)
14:35:52 <glx[d]> `local variable 'ret' will be copied despite being returned by name [-Wreturn-std-move]`
14:36:01 <glx[d]> I hate you gcc 13.1
14:36:11 <TrueBrain> most likely the feeling is mutual ๐Ÿ˜›
14:36:32 <TrueBrain> I now updated 10719 with new screenshots; TallTyler : it is now consistently boring with the rest ๐Ÿ˜› But no more green.
14:36:58 <glx[d]> ah no it's clang and linux
14:37:43 <glx[d]> so one compiler wants std::move, the other one doesn't want it
14:37:49 <TrueBrain> mwhahahahaha
14:38:03 <DorpsGek> [OpenTTD/OpenTTD] anatolyeltsov updated pull request #10541: Feature: Industry production graph
14:38:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #10719: Feature: opt-in survey when exiting a game
14:38:30 <petern> TrueBrain: white buttons on top works for me.
14:39:05 <TrueBrain> I so don't like that you visually can't spot where you can preform an action ... but petern is right, that is how TTD was designed ..
14:39:31 <TrueBrain> so now we fix Newgame, NewGRF, Network GUIs too, right? ๐Ÿ˜›
14:39:41 <TrueBrain> I will get the torches
14:39:47 <TrueBrain> do you get the pitchforks?
14:39:59 <petern> I've probably got a patch for some of them ๐Ÿ˜‰
14:40:18 <petern> Newgrf is definitely a mess.
14:40:23 <TrueBrain> it is terrible UX; but what can you do ๐Ÿ™‚
14:40:32 <petern> Well, we can design it. I have ideas ๐Ÿ˜‰
14:40:38 <TrueBrain> if we remove the colours from the strings, it would be easier to make themes
14:40:42 <petern> *redesign
14:40:47 <petern> Yup.
14:41:01 <glx[d]> <> <-- it's "funny"
14:41:04 <TrueBrain> "boring flat colours" and "actually visual pleasant"
14:41:12 <petern> We did recently have someone ask about changing window colours.
14:41:50 <TrueBrain> glx[d]: joy!
14:42:34 <TrueBrain> so you want the move for clang, but not for gcc ... ๐Ÿ˜„
14:42:44 <TrueBrain> well, it doesn't hurt GCC
14:42:46 <TrueBrain> mute the warning? ๐Ÿ˜›
14:43:01 <glx[d]> that's was my next idea yes
14:44:00 <TrueBrain> right, now to get the infrastructure there for secret generation, so we now when survey results are made by "official" binaries .. let's seeeeeee ... I know how to do it, just too bored to actually do it ๐Ÿ™‚
14:44:28 <TrueBrain> (lot of moving parts that need to be done .. boring work ๐Ÿ˜› )
14:54:35 <petern> FFS, wondered why nobody had responded to a Facebook post... I posted it in the wrong group ๐Ÿ˜ฎ
14:55:30 <TallTyler> glx[d]: Yes please ๐Ÿ™‚
14:55:30 <TallTyler> Here's the prompt and result from Command Prompt (Win 10):
14:55:52 <TrueBrain> petern: Does Facebook still exist?!
14:56:03 <TallTyler> Googling the error gives no results that seem to apply to me, they're either language issues or something related to MinGW which I don't think applies here
14:57:22 <glx[d]> tried .\bootstrap-vcpkg.bat ?
14:57:52 *** nielsm has joined #openttd
14:58:02 <TallTyler> `Could not find MSBuild version with C++ support. VS2015, VS2017, or VS2019 (with C++) needs to be installed.`
14:58:11 <petern> Sadly so.
14:58:41 <glx[d]> ah so there's something wrong with your compiler
14:59:02 <TallTyler> vcpkg or VS?
14:59:06 <glx[d]> VS
14:59:11 <glx[d]> vcpkg uses VS
14:59:20 <glx[d]> and it can't find it here
15:04:40 <TallTyler> Awesome
15:05:02 <glx[d]> check "Desktop Development with C++ " is installed in VS
15:06:58 <TallTyler> It's checked in the installer, but I'll try updating to see if that helps
15:09:09 *** Wormnest has joined #openttd
15:10:57 <petern> My current dread: "Just insert some dummy data"
15:11:56 <TrueBrain> TallTyler: Also update vcpkg (git pull) just to make sure they didn't fix it in the meantime ๐Ÿ™‚
15:22:41 <DorpsGek> [OpenTTD/OpenTTD] glx22 dismissed a review for pull request #10803: Fix: redundant move in return statement
15:22:44 <DorpsGek> [OpenTTD/OpenTTD] glx22 updated pull request #10803: Fix: redundant move in return statement
15:24:24 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #10803: Fix: disable "redundant move" warnings for GCC
15:54:16 <TallTyler> Okay, got vcpkg to install the JSON dependency, but I can't get cmake to find it. It wants a .cmake file, but there aren't any in the install folder
16:02:55 <TrueBrain> Vcpkg generates those
16:03:31 <TrueBrain> If it can find one library it should be able to find the rest
16:03:48 <TrueBrain> Following the instructions in the docs worked for me on MSVC
16:04:05 <TrueBrain> Don't forget to run the integrate step of vcpkg
16:07:43 <petern> Oops, I hit the uint16 scrollbar limit ๐Ÿ˜„
16:08:20 <petern> NWID_MATRIX scrolls by pixel, so it's a lot less than 65535 items.
16:10:57 <TrueBrain> You silly goose
16:12:37 <petern> HONKHONK
16:22:22 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi opened pull request #10804: Fix #10467: [YAPF] Trains do not use all available tracks
16:26:15 <TallTyler> I'm running into issues following the instructions. I don't have a `vcpkg/vcpkg` folder, so `.\vcpkg\vcpkg integrate install` from their quick start guide fails
16:26:34 <TallTyler> This feels like an incredibly stupid place to be stuck, but I'm really confused by this process
16:28:12 <petern> first vcpkg is the path, second vcpkg is the exe
16:29:01 <TallTyler> Aha, need to run it from the parent folder
16:32:43 <TallTyler> Oh, looks like we found it! Let's see if it builds and works... ๐Ÿ™‚
16:35:20 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10801: Codechange: rework Gamelog changes from union to classes
16:35:55 <TallTyler> It works! Thanks all for the help ๐Ÿ™‚
16:37:36 <TallTyler> Guess I have no excuse to ignore my map import PR now that we have a JSON library, or at least a way to add one...
16:37:39 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10801: Codechange: rework Gamelog changes from union to classes
16:46:07 *** gelignite has joined #openttd
16:51:36 <TrueBrain> TallTyler: Yeah, I looked at your PR, not difficult to update to this library ๐Ÿ™‚
16:51:45 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10700: Codechange: Split dates and timers into Economy and Calendar time
16:52:09 <TallTyler> I hope actions work now
16:52:56 <glx[d]> stop adding action runs, I have "Script missing mode enforcement" queued for 1h
16:53:13 <glx[d]> ๐Ÿ™‚
16:54:43 <TallTyler> Right, time to do something else while I wait for actions
16:55:08 <TallTyler> Updating my map import PR will wait until the library is merged, no need to rush there ๐Ÿ™‚
16:55:26 <glx[d]> and it most cases PRs will fail if they pick the newest image
17:13:06 *** Wolf01 has joined #openttd
17:13:25 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep commented on pull request #10691: Change: Add Depots and DepotIDs for airports with hangars.
17:14:16 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #10691: Change: Add Depots and DepotIDs for airports with hangars.
17:29:00 <gnomechomsky> Have people noticed the check annotations job failing?
17:29:57 <TrueBrain> Like 3 messages above yours :p
17:31:35 <TrueBrain> TallTyler: you can use the `nlohmann-json` branch instead of `master`, if you like ๐Ÿ™‚
17:32:34 <gnomechomsky> TrueBrain: I thought they were talking about different jobs
17:32:47 <gnomechomsky> is nlohmann-json going to be a new dependency?
17:32:59 <glx[d]> I'm still waiting for GitHub to finally run the last check on my PR
17:33:11 <glx[d]> Optional dep
17:33:44 <TrueBrain> it will never come ๐Ÿ˜›
17:33:55 <TrueBrain> you can't even cancel it ๐Ÿ˜›
17:34:16 <TrueBrain> ah, ther eI can cancel it
17:34:38 <TrueBrain> there you go
17:34:46 <glx[d]> It was a rerun because internal failure
17:34:54 <TrueBrain> yeah, but it never actually started
17:35:06 <TrueBrain> it ended up in an even weirder state
17:35:09 <TrueBrain> but I fixed it ๐Ÿ˜›
17:35:15 <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #10803: Fix: disable "redundant move" warnings for GCC
17:36:43 <glx[d]> There, should solve the annotations
17:57:31 <TallTyler> #10700 passed all checks! \o/
17:59:34 <TrueBrain> gratz!
18:06:21 <TrueBrain> did you also play to see if it actually works? *trolololol*
18:06:57 <TallTyler> Before pushing, even! ๐Ÿ˜›
18:17:40 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi updated pull request #10804: Fix #10467: [YAPF] Trains do not use all available tracks
18:25:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #10782: Add: NewGRF string code "9A 21" to display force from textstack.
18:43:42 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:43:43 <DorpsGek> - Update: Translations from eints (by translators)
18:50:31 <DorpsGek> [OpenTTD/OpenTTD] mrmbernardi commented on issue #9609: [Bug]: Pathfinder prefers occupied plain track over free station track
18:53:21 *** axet has quit IRC (Quit: Leaving.)
18:54:46 <gnomechomsky> I just noticed that my PR #10804 may help with the idea of getting rid of pathfinder settings. Trains will look for alternate routes if they're stuck for a while, mitigating the issue of deadlocks arising because of the pathfinder settings.
18:54:48 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #9577: Feature: Multi-tile depots
18:59:48 <gnomechomsky> Also what if players could just put an object down which artificially modified the pathfinder costs?
18:59:54 <gnomechomsky> might be fun
19:00:40 <gnomechomsky> I think advanced players could really make use of that to support proper overtaking lanes and such, and if they screw stuff up with them then it's on them for using it
19:02:31 <gnomechomsky> Do reserved tiles have info about who exactly is reserving them?
19:03:56 <gnomechomsky> If so, I could write a PR to have the cost of crossing reserved tiles be fixed per reserving train. This would remove the weird effect of the pathfinder behaving differently if the path is blocked by a long train or a short train
19:05:23 <FLHerne> gnomechomsky: I don't think so
19:05:47 <FLHerne> I was thinking you could fix that by adding a cost per conflicting reservation 'segment' rather than per-tile
19:05:51 <FLHerne> there's probably a better word
19:06:29 <FLHerne> i.e. apply a cost for the first conflicting tile, but not consecutive ones, then reset when there's a gap
19:06:30 <gnomechomsky> yeah but how do you find each segment in a performant way?
19:07:49 <gnomechomsky> I'm thinking you'd need to build a collection for each segment you encounter
19:08:17 <gnomechomsky> check if the current tile is reserved, if so, is it connected to any of the collections of reserved tiles you've seen, if so, don't add the cost
19:09:20 <gnomechomsky> complicated and would tank the performance as you'd need to check your current tile against all other seen reserved tiles
19:10:50 <gnomechomsky> The more performant way to do it would be to build a data structure as you're reserving and unreserving the tiles
19:11:16 <FLHerne> I guess the state tracking would be in CYapfRailNodeT
19:11:17 <gnomechomsky> then the pathfinder can look at this to see who's reserving what, and if it's already added a penalty for a certain train's reservations, don't add another one\
19:11:37 <FLHerne> what you say seems needlessly complicated, I think?
19:12:01 <FLHerne> the cost calculation already walks the tiles; store a 1-bit flag "last tile was reserved"
19:12:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #10805: Codechange: use std::string instead of char* for original editor strings
19:12:16 <FLHerne> add penalty if the current tile is reserved and the previous one wasn't
19:12:50 <FLHerne> (this based on very quickly skim-reading the code, so might be wrong :p)
19:13:47 <gnomechomsky> But it doesn't explore the tiles in order does it?
19:14:12 <glx[d]> it does explore from start to end
19:14:14 <FLHerne> I think it has to, otherwise m_last_signal_was_red and friends wouldn't work
19:14:30 <glx[d]> and it knows previous node
19:14:45 <gnomechomsky> ah I think I see
19:15:16 <gnomechomsky> Ah so this cache doesn't live on between FindPath calls does it?
19:15:20 <gnomechomsky> otherwise things would break I guess
19:17:44 <gnomechomsky> hmm there's a spelling mistake with m_targed_seen lol
19:19:40 <FLHerne> hah
19:19:58 <gnomechomsky> Okay so in theory we just need to add m_reservation_seen and then only add reservation costs when its 0, then set it. Then clear it when we go off a reservation
19:21:04 <FLHerne> I think for naming consistency it would be m_last_tile_was_reserved or so
19:21:32 <FLHerne> the m_xyz_seen ones are set once and then never cleared during a search, if I understand correctly
19:21:47 <gnomechomsky> ah, good point
19:23:17 <gnomechomsky> It could change pathfinding around blocked trains dramatically to add this however. I'm not sure how it would affect existing saves people are using
19:23:51 <FLHerne> but otherwise yes, that was my vague idea of how it should work
19:24:10 <gnomechomsky> You'd also need to up the default pbs penalties to match the "average train length" it would have usually generated
19:24:50 <FLHerne> I'm pretty sure the change would be positive in almost all cases, assuming the penalty for the typical 5-tile or whatever train stays the same
19:25:10 <gnomechomsky> yeah so up it to a 1500 flat penalty?
19:25:35 <FLHerne> the behaviour with 1-tile trains is just broken, frankly - as in that bug report, which is far from the first time I've seen it come up
19:25:51 <gnomechomsky> I think its worth doing too. I can work on it tomorrow. Also I think my other PR is still good. It feels so good to see a blocked train resolve a deadlock itself ๐Ÿ™‚
19:26:10 <FLHerne> I bet *some* weirdo openttdcoop weirdo has invented a network design that relies on it, but _shrug_
19:26:54 <FLHerne> your other one seems ok, but it would be much nicer to do the right thing immediately rather than wait :p
19:26:54 <glx[d]> openttdcoop don't use pbs
19:27:08 <FLHerne> ok, some nonaffiliated weirdo :D
19:27:36 <glx[d]> they have enough presignal abuses ๐Ÿ™‚
19:27:58 <gnomechomsky> FLHerne: The thing is you'd need to know the future for that one since the right decision depends on how soon the train in front is unblocked
19:28:01 <FLHerne> but yeah, your current PR seems like a good 'backstop' for imperfect penalties
19:28:05 <gnomechomsky>
19:28:11 <gnomechomsky> Yeah it solves this annoyance
19:28:23 <gnomechomsky> This sort of thing would make me yell at my screen lol
19:28:45 <FLHerne> hm
19:28:56 <gnomechomsky>
19:28:57 <FLHerne> for that case, stopped trains could have near-infinite penalty
19:28:59 <gnomechomsky> That too
19:29:03 <FLHerne> hm
19:29:30 <gnomechomsky> FLHerne: Ah good idea.
19:29:36 <FLHerne> I guess ideally, the penalty of a train would go up the longer it's been stopped for, but that requires information that pathfinder probably doesn't know...
19:29:57 <glx[d]> last screenshot has the exact opposite behaviour with NPF
19:30:09 <glx[d]> trains never chose middle track
19:30:22 <gnomechomsky> FLHerne: I think it might know, I'd have to check but maybe the counter i'm relying on is also incremented when a train is stopped
19:30:38 <gnomechomsky> but yeah i'd need the vehicle on the tile, which I'm not sure how to get
19:30:48 <gnomechomsky> there's probably a data structure for it obviously
19:31:04 <FLHerne> I forget the name of the law, but overall the best estimate of future waiting time is the current waiting time, because the average vehicle is halfway through its wait
19:31:32 <FLHerne> unless you have other special knowledge
19:31:44 <gnomechomsky> Sounds like the lindy effect
19:32:11 <FLHerne> yeah, that's the one
19:46:16 <gnomechomsky> Actually I have an idea that would maybe get rid of PBS penalties and take into account the Lindy effect
19:48:05 <gnomechomsky> Idk how expensive it is, but if you can look for an engine on the tile you're costing, then you add it's waiting time to the cost.
19:48:47 <gnomechomsky> Should automatically only count each blocking train once, and it accounts for the waiting time of the blocking trains, not your own impatience
19:49:06 <gnomechomsky> And would also allow repathing for normal signals
19:52:51 <glx[d]> looking for engine on a tile has a cost
19:54:07 <gnomechomsky> Maybe tiles with engines could be marked as the engines move around
19:55:19 <gnomechomsky> Then you'd know exactly where to look and it only adds one branch and removed some of the PBS related branches
19:58:03 <glx[d]> it's already like that, but using some hashing
19:59:16 <glx[d]> see FindVehicleOnPos()
20:00:37 <gnomechomsky> I'd have to check tomorrow because I don't have a computer now
20:00:49 <glx[d]> and tiles with engines are reserved ๐Ÿ˜‰
20:01:05 <gnomechomsky> glx[d]: Even when PBS aren't used?
20:01:27 <Eddi|zuHause> yes
20:01:44 <gnomechomsky> The other thing I was wondering about is if there's any demand to have blocks entered by the train who's waited the longest
20:04:59 <glx[d]> trains would need to know other waiting trains for that
20:05:21 <gnomechomsky> Can't you just tick the vehicles in order of longest waited ?
20:05:22 <glx[d]> the loop just follow vehicle index
20:05:53 <gnomechomsky> Yeah you'd need to sort the pool by waiting time, but the thing is changes in the order wouldn't happen very often
20:06:05 <gnomechomsky> Only when trains start or stop waiting
20:06:15 <glx[d]> the pool can be huge
20:06:52 <glx[d]> every vehicle is in it, including wagons, smoke effects, ...
20:08:01 <gnomechomsky> I think the operations required to keep it sorted would be sparse. Only when a train starts or stops waiting you simply swap it's position with one of the trains who isn't waiting
20:09:12 <gnomechomsky> I'd need to look at the code to be sure obviously
20:11:41 <Rubidium_> if the vehicle waiting longest can finally proceed, all waiting vehicles after it need to be moved up in rank
20:15:36 <Rubidium_> also, it doesn't quite solve the issue deadlocking trains completely. Say you got 3 input and 3 output tracks with switches in between. Train A is waiting on track 1 for a long time to go to track 3 but it can't yet. Now train B arrives at track 2 continueing on track 2 so it goes. After that track 3 after the switches becomes free (and while train B is still crossing) train C arrives at track 3 to
20:15:42 <Rubidium_> continue on track 3... and that one will happily go still blocking train A.
20:21:16 <gnomechomsky> It's not meant to fix deadlocks like that
20:21:32 <gnomechomsky> That's probably not even ideal since a stopped train may be a slower train getting overtaken
20:21:42 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:21:56 <gnomechomsky> It's meant to fix waiting bays and the messages you get from them
20:23:21 <andythenorth> hmm
20:23:31 <andythenorth> didn't rewrite Horse to use more text stack yet ๐Ÿ˜›
20:23:36 <andythenorth> such goals, such failed
20:34:11 <glx[d]> TrueBrain: I think you forgot to update cache key when adding icu and harfbuzz to vcpkg in release, both libs are recompiled everytime
20:34:40 <TrueBrain> it should update the cache after merging to master
20:34:43 <TrueBrain> should-would-could
20:34:47 <TrueBrain> well, I guess not
20:34:53 <TrueBrain> vcpkg does this? Yeah, okay, they won't
20:34:58 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:34:59 <TrueBrain> well, something to fix with nlohmann-json ๐Ÿ˜„
20:35:37 <glx[d]> that's why `# Increase the number whenever dependencies are modified` comment exists ๐Ÿ˜‰
20:35:53 <TrueBrain> are you now trying to make me feel bad? ๐Ÿ˜›
20:36:01 <glx[d]> not at all
20:36:26 <TrueBrain> well, you should, but okay ๐Ÿ˜›
20:37:25 <glx[d]> I know this part because I introduced vcpkg caching
20:37:38 <glx[d]> but it's easy to miss
20:37:52 <TrueBrain> I can also just delete the cache entry ๐Ÿ˜›
20:38:14 <TrueBrain> but that means it rebuilds everything next time ๐Ÿ™‚
20:38:25 <glx[d]> yes should be fine, we don't do releases as intensively as CI
20:38:27 <TrueBrain> well, I hope to finished survey stuff tomorrow; so I guess we can wait a few more days ๐Ÿ™‚
20:39:20 <glx[d]> but waiting until another dep is added is fine too
20:40:09 <glx[d]> and nightly finally built
20:40:26 <glx[d]> after needing a forced restart for linux target
20:40:41 <glx[d]> github issues are annoying
20:42:17 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #10805: Codechange: use std::string instead of char* for original editor strings
20:42:39 <glx[d]> this one was short ๐Ÿ™‚
20:50:27 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:15:13 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10805: Codechange: use std::string instead of char* for original editor strings
21:25:58 *** D-HUND is now known as debdog
21:31:48 *** Flygon has joined #openttd
21:52:08 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:03:13 *** tokai|noir has joined #openttd
22:03:13 *** ChanServ sets mode: +v tokai|noir
22:10:04 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:37:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #10800: Codechange: Iterator loops
22:37:37 *** henry has joined #openttd
22:38:08 *** henry has quit IRC ()
22:38:20 *** henry has joined #openttd
22:38:58 *** henry is now known as m3henry
22:41:07 <m3henry> I thought it might be handy to show the number of industries already built in the build window.
22:42:04 <glx[d]> ah yes looks like a good idea
22:43:23 <m3henry> Though I'm not sure how I would go about right aligning the number in the matrix widget
22:44:02 <petern> Draw it with SA_RIGHT
22:51:17 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #10800: Codechange: Iterator loops
22:53:58 <m3henry> Looks like the window needs redrawing when industries are built/closed
23:09:30 <petern> That doesn't seem like a problem
23:12:15 *** gelignite has quit IRC (Quit: Stay safe!)
23:15:10 *** m3henry has quit IRC (Remote host closed the connection)
23:15:21 *** m3henry has joined #openttd
23:16:26 <m3henry> It isn't, I'd not needed to use InvalidateWindowData before, fortunately it was easy to find the canonical way
23:16:42 <DorpsGek> [OpenTTD/OpenTTD] github-code-scanning[bot] commented on pull request #10800: Codechange: Iterator loops
23:16:48 <petern> Well you can just mark dirty.
23:17:47 <m3henry> Ah, I see, that does less work does it?
23:19:27 <petern> Depends what the window is doing. If it needs to precalculate things or build lists then invalidate is the way to. If it just needs to redraw because it's changed, then marking it dirty is fine. IMHO.
23:19:38 <petern> *way to go
23:20:38 <m3henry> Fair, PR incoming anyways
23:20:43 <petern> I guess if you are calculating and storing the number of existing industries, invalidate ๐Ÿ™‚
23:21:16 <petern> And also check if a large map with lots of industries doesn't tank it. You've not go much going on in the picture I saw.
23:24:01 <m3henry> Fortunately it's already cached
23:29:29 <m3henry> Also, draw 0 when no industries, or leave blank?
23:31:59 <glx[d]> haha codeql doesn't like you ๐Ÿ™‚
23:36:22 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #10800: Codechange: Iterator loops
23:36:57 <glx[d]> 0 would be consistent
23:43:12 <m3henry> 1 for 0, 1 for blank, petern?