IRC logs for #openttd on OFTC at 2023-05-10
⏴ go to previous day
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]> 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:52 <glx[d]> H:/msys64/clang64/include/tchar.h:1131:15: note: expanded from macro '_T'
00:01:54 <glx[d]> H:/msys64/clang64/include/tchar.h:127:16: note: expanded from macro '__T'
00:01:58 <glx[d]> <scratch space>:38:1: note: expanded from here
00:02:16 <glx[d]> their headers are broken
00:03:10 <glx[d]> ah no, we break their headers
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
02:02:17 *** herms has quit IRC (Quit: bye)
02:15:26 *** Wormnest has quit IRC (Quit: Leaving)
03:03:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
05:25:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:45:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
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: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: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...
12:12:59 <glx[d]> hmm external upload service and bug reports
12:26:15 *** ag has quit IRC (Quit: User went offline on Discord a while ago)
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:15 <Citizen_Kane_23> If so it's amazing then
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: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: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> 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: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:37 <gnomechomsky> seems hard though
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: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:56 <glx[d]> cost for occupied station is weird IIRC
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: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: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: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: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:27:25 <petern> It gives the layouters slightly less work to do 😉
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: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> 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: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: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: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: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: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 yapf.xyz costs in openttd.cfg and at yapf_costrail.hpp ; most of the bugs will be there :p
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:33 <FLHerne> *that sounds plausible
13:48:26 <TrueBrain> also, totally non-OpenTTD, I fixed my heat issue
13:48:32 <glx[d]> oh I see why the std::move are useless it's actually a (SQObject)std::move(SQObjectPtr)
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: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: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:59 <TrueBrain> every new game you start
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:11 <TrueBrain> at least, I couldn't find any 😛
14:07:18 <TrueBrain> so the grey is new, I think
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:17 <petern> red is stop, green is go. that's different from no/yes tbh.
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:24 <TrueBrain> I saw this lovely red button to force my pull request to merge .. I pressed it 😛
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: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. https://www.radiolab.org/podcast/211213-sky-isnt-blue
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: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> 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: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: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: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> now they are identical to the readme buttons
14:26:46 <TrueBrain> I guess I go for consistency .. although I hate it 😛
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:15 <TrueBrain> "original UI" BaNaNaS download
14:31:31 <TrueBrain> the weirdos can keep their original stuff 🙂
14:31:42 <petern> The weirdos can use their new stuff
14:32:10 <TrueBrain> well, no I was looking for WASM UI mostly to help Android port
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: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: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: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: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: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:58:02 <TallTyler> `Could not find MSBuild version with C++ support. VS2015, VS2017, or VS2019 (with C++) needs to be installed.`
14:58:41 <glx[d]> ah so there's something wrong with your compiler
14:59:20 <glx[d]> and it can't find it here
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: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: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: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: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: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: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: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: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: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:36:43 <glx[d]> There, should solve the annotations
17:57:31 <TallTyler> #10700 passed all checks! \o/
18:06:21 <TrueBrain> did you also play to see if it actually works? *trolololol*
18:06:57 <TallTyler> Before pushing, even! 😛
18:43:43 <DorpsGek> - Update: Translations from eints (by translators)
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:59:48 <gnomechomsky> Also what if players could just put an object down which artificially modified the pathfinder costs?
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: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: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: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: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:57 <FLHerne> for that case, stopped trains could have near-infinite penalty
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: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: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: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: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: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:26 <TrueBrain> well, you should, but okay 😛
20:37:25 <glx[d]> I know this part because I introduced vcpkg caching
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:50:27 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:25:58 *** D-HUND is now known as debdog
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:38:58 *** henry is now known as m3henry
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: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: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: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:43:12 <m3henry> 1 for 0, 1 for blank, petern?
continue to next day ⏵
