IRC logs for #openttd on OFTC at 2024-01-19
โด go to previous day
00:00:54 <peter1138[d]> Hmm, it does boost to 2.8 GHz.
00:01:10 <reldred> it did not however go zututututu
00:06:27 <reldred> what am i looking for?
00:06:45 <reldred> or more specifically what are you looking for?
00:06:50 <peter1138[d]> Boringly it just needs to look normal ๐
00:06:53 <reldred> the fonts look... fontish?
00:07:07 <reldred> I dunno, they don't appear offensive to me.
00:07:24 <peter1138[d]> But hey, at least you have you a ready-to-go build environment now ๐
00:07:26 <reldred> AA on or off, pixel font on or off,
00:07:38 <reldred> It won't build a bundle, but it at least built
00:08:04 <peter1138[d]> Well, looks fine to me, no letters in wrong places all over the screen ๐
00:08:22 <reldred> DONT say I never do anything for y'all :b
00:08:40 <reldred> (except cause headaches, I'm aware I do that)
00:08:53 <peter1138[d]> Only because I went with Misskey.
00:09:27 <reldred> My misskey is still working, after I pissed off the dog awful compose file and wrote my own that was less dogshit
00:19:41 <reldred> there we go, figure its worth noting it was checked with a mac incase anyone goes searching for your scalp in twelve years time.
00:33:03 <peter1138[d]> Well that is a bit ugly ๐ฆ
00:34:33 <peter1138[d]> I suspect the uniscribe GetGlyphToCharMap could be simplified, but not sure.
00:35:00 <peter1138[d]> As this is working around the same issue.
02:59:53 *** Wormnest has quit IRC (Quit: Leaving)
03:42:10 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:57:18 *** virtualrandomnumber has joined #openttd
04:57:48 *** virtualrandomnumber has quit IRC ()
06:08:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:25:20 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:28:01 *** _zephyris has joined #openttd
07:28:01 <_zephyris> reldred: Looks perfect, including kerning. ๐
07:32:09 *** tokai|noir has joined #openttd
07:32:09 *** ChanServ sets mode: +v tokai|noir
07:38:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
08:39:35 <LordAro> peter1138[d]: why not just make it a class method?
09:02:21 <peter1138[d]> Oh dear, 'forgot' about my Dad's wedding anniversary. These things we are supposed to remember that don't really have any bearing on us...
09:03:42 <LordAro> that's a very strange thing to have to remember
09:04:06 <LordAro> or was he relying on you to remind him, perhaps?
09:09:21 <peter1138[d]> Judging by the slightly passive-aggressive photo and message, no...
09:09:47 <LordAro> did he mean to send it to your mum? :p
09:09:55 <peter1138[d]> That would be difficult.
09:15:44 <peter1138[d]> I want to see how well this straight-line ship pathfinder works ๐
09:33:13 <peter1138[d]> Ah, it was GRF coder mistake. Odd because they said it affects the original sprites.
09:39:22 <andythenorth> too early for lunch?
09:39:33 <andythenorth> peter1138[d]: I had thoughts about that
09:39:36 <truebrain> for you? Yes. It would be breakfast. Not lunch.
09:39:46 <andythenorth> I think it works brilliantly for the first move (finding two points)
09:40:01 <andythenorth> then you hit a land tile, then you have to keep walking land until you find water
09:40:13 <andythenorth> then you have to check that water connects in a straight line with your starting water tile
09:40:27 <andythenorth> seems....like....you could end up checking a boatload of land tiles
09:40:44 <andythenorth> the proposed algorithm seems to be predicated on land 'knowing' where the nearest water tile is
09:40:49 <truebrain> ah ship pathfinder that auto-builds aquaducts! Solves all issues?!
09:41:13 <andythenorth> I guess the funny thing is that because pathfinding only water tiles is clearly inefficient
09:41:28 <andythenorth> the proposed solution is to use land tiles instead to find water, but they must know all the water tiles
09:46:25 <LordAro> ship pathfinder that hugs the coast might be fun
09:53:07 <peter1138[d]> I had a patch that makes ships avoid the coast.
09:53:27 <peter1138[d]> But only 2-3 tiles or so.
09:53:48 <peter1138[d]> Was there something about river boats and ocean boats?
10:09:43 <Eddi|zuHause> there were certainly discussions about that
10:10:24 <Eddi|zuHause> IIRC ships can define a canal/river speed and an ocean speed, but based on the tile, not geography.
10:11:27 <Eddi|zuHause> so a narrow strip of ocean doesn't act like a river, and a massive lake of river tiles doesn't act like an ocean
10:27:11 <_zephyris> Tabular numerals...
10:27:37 <_zephyris> [ignore the tragic profitability!]
10:38:55 <peter1138[d]> Shut up tummy, you had breakfast.
10:41:56 <truebrain> almost lunch ........ (at least for me ๐ )
10:52:31 *** APTX_ has quit IRC (Ping timeout: 480 seconds)
10:54:35 <xarick> `CountBits(WATER_REGION_EDGE_LENGTH - 1)` this no longer compiles ๐ฆ
10:57:06 <peter1138[d]> Hmm, why do you need to count the number of bits in that?
10:58:33 <xarick> any alternative to that?
11:03:40 <xarick> any other method to get that?
11:05:11 <peter1138[d]> Hmm, what happens if EdgeLength isn't a power of 2 for some reason...
11:06:33 <xarick> would have to find another solution
11:09:59 <xarick> maybe local_tile / WATER_REGION_EDGE_LENGTH
11:17:36 <xarick> assert((local_tile & (WATER_REGION_EDGE_LENGTH - 1)) == (local_tile % WATER_REGION_EDGE_LENGTH));
11:18:03 <xarick> less operations, i guess
11:21:26 <peter1138[d]> Well, % is possibly slower.
11:22:19 <peter1138[d]> If you With WATER_REGION_EDGE_BITS
11:22:46 <peter1138[d]> If you define WATER_REGION_EDIT_BITS as a constexpr then you know that the calculation happens at compile-time, so that is not a concern.
11:23:52 <peter1138[d]> So it would be doing "localtile >> 4"
11:27:40 <xarick> >> is cheaper than / ?
11:28:03 <LordAro> as a general rule, yes
11:28:15 <LordAro> but any compiler made in the last 30 years will optimise it for you
11:28:18 <merni> It ought to be but any compiler that sees x / 2^n will optimise it to a bit-shifr
11:28:42 <LordAro> you'll find that a compiler will rarely output an actual division operation
11:30:35 <LordAro> 5 is actually a multiply, several shifts and a sub
11:30:39 <LordAro> don't ask me how that works
11:31:40 <LordAro> division by pretty much any constant will not actually be executed as a division
11:32:05 <LordAro> (obviously it has to do an actual divide if it doesn't know what the value will be)
11:35:45 <peter1138[d]> Yeah / 16 & % 16 will be fine.
11:36:10 <peter1138[d]> Compiler replaces % 16 with & 15 usually.
11:36:28 <merni> Well, `x / 16 & % 16` is likely to be an error :p
11:36:56 <peter1138[d]> hah, that was an and & ๐
11:37:14 <_jgr_> The sub is to handle negative inputs, otherwise it's just fixed point arithmetic
11:40:30 <merni> Interestingly clang produces code involving `idiv` by default unless `-O` is given
11:41:04 <merni> perhaps different defauls?
11:41:12 <_jgr_> There's really no point compiling anything without a -O flag at some level
11:44:10 <peter1138[d]> Hmm, I can't even see where we set -O.
11:44:34 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
11:44:42 <merni> _jgr_: GCC apparently optimises away division even with `-O0` though, that is what threw me off
11:54:03 *** asymptotically2 has quit IRC (Ping timeout: 480 seconds)
11:59:10 *** asymptotically2 has joined #openttd
12:07:39 <peter1138[d]> My fellow cyclists might go out on their bikes for an hour, but it's still cold and frosty and I'm lazy anyway.
12:10:34 <xarick> anyways, my code is buggy somewhere
12:24:17 <xarick> i have a hard time reproducing this bug
12:24:38 <xarick> when I load from the savegame, it doesn't exhibit it
12:24:52 <xarick> when i build the route in-game, it happens
12:25:20 <peter1138[d]> Create an AI that builds the route ๐
12:30:10 <xarick> random lost ships for no real reason ๐
12:32:49 <xarick> i must have messed up somewhere
12:33:07 <xarick> happens in 4096x4096 maps
12:33:16 <xarick> doesn't happen on 256x256, doesn't happen on 512x512
12:33:25 <xarick> gonna keep testing until it happens
12:34:08 <peter1138[d]> Try 64x4096 if you need a long distance without a huge map.
12:34:46 <xarick> seems that invalidation is screwing something
12:34:59 <xarick> the first ship invalidates the 2nd ship
12:35:08 <xarick> and then the 2nd ship gets lost
12:35:27 <xarick> but this is my fault, I'm pretty sure
12:35:52 <xarick> I changed some ints to uint8_t's and uint16_t's maybe some limit is incorrect
12:55:59 <peter1138[d]> Hmm, I can't pass an initializer_list to SetWidgetsDisabledState ๐ฎ
12:57:55 <truebrain> I am happily using std::span .. hmmmm
12:58:52 <peter1138[d]> The issue I had is that, until C++23, it doesn't have const_iterator, no cbegin()/cend()
12:59:10 <LordAro> fun fact, libffi by default compiles with -march=<detected native>
12:59:15 <LordAro> guess how i know this
12:59:19 <LordAro> and how long it took me to figure it out
13:06:07 <truebrain> `error: use of undeclared identifier 'EM_ASM'`
13:06:20 <truebrain> the downside of Emscripten macros, you only see that it doesn't know the macro unless you removed its full context
13:06:27 <truebrain> you also don't want to know how long that took me ๐
13:07:11 <truebrain> Also, find the issue with this:
13:07:13 <truebrain> ```#elif !defined(__APPLE__) && !defined(__NetBSD__) && !defined(__FreeBSD__)
13:07:13 <truebrain> # include <sys/random.h>
13:07:13 <truebrain> #elif defined(__EMSCRIPTEN__)
13:07:13 <truebrain> # include <emscripten.h>```
13:07:44 <peter1138[d]> Yeah, wrong order ๐
13:09:11 <truebrain> hmm, why is emscripten asking me for survey ... did I fix Emscripten can send surveys? Can't remember ..
13:12:25 <truebrain> why not? Not sure ... I think I tried a few times, but I keep forgetting where it fails ๐
13:17:13 <truebrain> w00p, now with Emscripten support ^^ ๐
13:19:44 <truebrain> that should be sufficient to build signature validation on ... let's try!
13:20:18 <xarick> I get this weird behaviour... ๐ฆ
13:21:20 <xarick> Sarnwell Docks is right there on the left
13:22:09 <peter1138[d]> Does it do that in master?
13:22:43 <xarick> I suppose not, let me try
13:29:48 <truebrain> what would be a good english description to say a plugin has an invalid signature, so users understand it?
13:30:19 <truebrain> `Unauthorized` .. `Invalid Signature` .. `Couldn't validate` .. `Not by known author` ..
13:30:40 <truebrain> `Failed Validation`
13:35:33 <LordAro> i'd say invalid signature is fine
13:35:46 <truebrain> will do for now ๐
13:40:22 <xarick> oh noes, it happens in master too
13:40:33 <xarick> let me verify wether the ship is actually lost
13:41:12 <xarick> a stupid house growth blocked passage
13:41:55 <xarick> thx town growth algorithm
13:46:47 <xarick> honestly, I'd rather have ships bunch up at the location they can't pass and not wander around
13:47:07 <peter1138[d]> That isn't how pathfinding works ๐
13:47:12 <xarick> so that when I fix the blockage, they won't have to come from whatever they went
13:47:18 <truebrain> because ships know they cannot pass at a certain location .... *puzzled look*
13:47:45 <xarick> it's the last node with the cheapest cost they can reach
13:47:55 <xarick> cheapest estimate to dest
13:48:00 <truebrain> if you think about this a tiny bit longer, you will know that is not true ๐
13:50:32 <truebrain> in no world that was ever the case ๐
13:50:53 <xarick> okay let me load in 13.4
13:50:54 <truebrain> the lowest estimate is the closest tile to the destionation; by no means it is the tile blocking anything
13:51:25 <xarick> bah, savegame made with new version ๐
13:51:51 <_glx_> if there's no path, there's no paht
13:52:23 <truebrain> haha, we can make the PF even more expensive: if no path, add a big penalty for "going over land", and see when you do find a path
13:52:28 <truebrain> that must be the tiles blocking you
13:53:04 <peter1138[d]> Hovercraft pathfinder?
13:53:35 <truebrain> that never happened
13:56:31 <xarick> well well looks like it happens in master after all
13:56:55 <truebrain> once again Xarick got stuck in a local optimum
13:57:18 <truebrain> "it is true for my case, it must be true for any case!"
13:57:58 <xarick> pretty sure that if i load the savegame back, it gets unstuck
14:12:26 <xarick> I suspect it's the random path
14:12:30 <_glx_> guess it doesn't check all valid directions
14:12:50 <xarick> how did it end in that situation
14:14:48 <_glx_> if you make the canal larger it might unblock
14:16:34 <peter1138[d]> So it's stuck on one tile on TRACK_BIT_LEFT.
14:20:13 <_glx_> issue looks very similar too me
14:20:52 <xarick> switched to NPF, it fixed itself
14:21:56 <_glx_> I think it's may be fine with yapf in 13.4
14:23:16 <xarick> it's not doing a yapfshipcheckreverse
14:23:50 <xarick> somewhere in ShipChooseTrack is the bug
14:28:07 <peter1138[d]> ChooseShipTrack trusn INVALID_TRACK because it can't find a path that way.
14:28:23 <peter1138[d]> So it just turns out 90 degrees, and then does the same.
14:28:34 <peter1138[d]> ship_cmd.cpp:776
14:30:18 <xarick> why isn't a path found though?
14:30:27 <xarick> or why it works with NPF
14:37:29 <peter1138[d]> It turns around, then moves to the end of the tile and looks for a path.
14:38:05 <peter1138[d]> It does not search for a path after turning around because that is only done when reaching a new tile.
14:40:15 <peter1138[d]> Hmm, having said that this call does happen when it's about to move onto a new tile.
14:40:20 <peter1138[d]> (It then doesn't)
14:44:28 <peter1138[d]> Hmm, is there a call to find the 'next' trackdir from the current trackdir.
14:44:30 *** Extrems has joined #openttd
14:46:15 <xarick> i think I see the problem
14:46:34 <xarick> even when a path is not found, it still should return a track
14:47:34 <xarick> trying to compare to old yapf
14:47:52 <peter1138[d]> This is not new.
14:47:59 *** rudolfs[m] has quit IRC (Quit: Client limit exceeded: 20000)
14:48:49 <xarick> hmm... I'm kinda sure it didn't happen before, or I would have noticed
14:49:41 <xarick> maybe I'm wrong, but I've never seen my ships get stuck like that in 13.4
14:52:01 <FLHerne> it's not something I've seen, and I used to build a lot of ships on rivers
14:52:40 <FLHerne> they get trapped in corners like that when modifying terrain but never seen it with water tiles at the ends
14:52:47 <truebrain> I have never seen pink elephants; doesn't mean they aren't there ๐
14:53:14 <xarick> what was the value of YAPF_SHIP_PATH_CACHE_LENGTH
14:53:37 <FLHerne> I don't remember ships ever clustering at the closest point to their destination
14:53:42 <FLHerne> if they're lost they're lost
14:59:12 <xarick> confirmed, works with old yapf
14:59:29 <xarick> it returns something different than INVALID_TRACK
15:06:12 <xarick> if (!path_found && !node) return INVALID_TRACKDIR; might be this
15:08:00 <truebrain> do we have a function that converts a hexstring to a bytestring?
15:10:29 <_glx_> there's also the return at end of function (it used to not be INVALID_TRACKDIR)
15:11:23 <xarick> that one is just impossible to be reached
15:11:47 <xarick> it's just there because security bot whoever complains about it
15:12:04 <_glx_> truebrain: I can see DecodeHexNibble() and DecodeHexText(), but might not be what you want
15:12:50 <truebrain> no, that is what I was looking for; it is just written in a very old dialect ๐
15:20:11 <truebrain> still 300 lines of code to do signature validation .. more than I expected.
15:31:58 <truebrain> awh, C++20 doesn't offer a `constexpr std::string` ๐
15:34:17 <peter1138[d]> Even though I managed to replicate #11840... I can't do it again ๐ฎ
15:34:49 <truebrain> hmm, yeah, string_view works too
15:35:08 <truebrain> I think I am overcomplicating this, but that is okay: I have a hex-string compile-time I want to convert to a byte-array
15:35:24 <truebrain> I wrote a `static constexpr bool ConvertHexToBytes(std::string_view hex, std::span<uint8_t> bytes)`
15:35:27 <truebrain> but that is not going to help ofc
15:35:38 <_glx_> why not make it a compile time byte array ?
15:35:41 <truebrain> (I know, `static constexpr` is unneeded)
15:35:48 <truebrain> because us humans are better in reading a hex-string
15:36:03 <truebrain> and it is something we want to be able to read and put in other tools easily
15:36:09 <truebrain> (a public key, in this case)
15:37:00 <truebrain> mostly what I want, that compile-time it is checked that it is a hex-string, and not some other garbage
15:37:29 <_jgr_> That sounds like something you could more simply do using CMake, writing into rev.cpp, or similar
15:37:51 <truebrain> yeah, that would work too; but now I am curious if it can be done in C++ ๐
15:37:57 <truebrain> you know how that goes ๐
15:42:10 <truebrain> I miss Rust macros at these times ... ๐
15:42:30 <truebrain> well, at least let's check what the CI thinks about my work
15:42:40 <xarick> do I have the liberty to improve that function a bit?
15:42:48 <xarick> or just do what I was told
15:43:22 <merni> but here you are an open source contributor and not an employee so you can work on what you want
15:43:37 <merni> whether it will be accepted by other devs is a different matter :)
15:44:00 <xarick> I have a problem with line 275
15:44:20 <xarick> it will never be reached
15:44:46 <xarick> the for loop always returns something, there's no way it doesn't run
15:46:25 <xarick> but removing it will make security expert bot to say not all paths return something or similar error
15:47:23 <xarick> if I use a break in the loop, it then complains that the loop won't be ... looped
15:48:11 <xarick> there is a continue somewhere in the loop, so it loops
15:48:17 <peter1138[d]> 1) why worry about it. 2) `if (!path_found && node == nullptr) break;`
15:48:27 <peter1138[d]> Then it will break, and use the return at the end.
15:48:39 <merni> The security warnings can be ignored though, right?
15:48:48 <xarick> oh, nice! thanks, that solves my headache:=)
15:49:30 <peter1138[d]> But: It is fine to have a redundant return statement. It is not allowed to NOT have a return statement.
15:50:08 <xarick> a break as the last line in the loop was triggering many bots
15:50:22 <xarick> but there, I guess it's fine
15:54:13 <xarick> the track it returns is also weird though
15:54:32 <xarick> but at least it's what it used to do
15:57:34 <xarick> it would be valid if the ship was reversing at the other side of the tile
15:58:50 <xarick> some other function is solving it to a proper track
16:03:08 *** Wormnest has joined #openttd
16:04:29 <xarick> nevermind, I'm seeing things wrong
16:05:12 <xarick> the ship is actually one tile behind
16:05:48 <xarick> TRACK_DIR_LOWER_W exists in the tile
16:25:22 <xarick> All checks have passed
16:25:30 <xarick> no complaints from security expert
17:09:34 <peter1138[d]> Should've been fix.
17:47:54 <xarick> `const uint16_t nx = water_region_patch.x + offset.x;`
17:48:00 <xarick> water_region_patch.x is uint8_t
17:54:06 <xarick> pff generating a 4096x4096 map in debug mode zzz ๐ฆ
18:26:08 <xarick> why is this only happening on 4k maps... what am I doing wrong
18:37:12 <xarick> doesn't happen on 64x4096, neither in 4096x64
18:37:27 <LordAro> there are other options
18:40:50 <DorpsGek> - Update: Translations from eints (by translators)
18:47:58 <xarick> when i load back the savegame, it fixes itself
18:51:14 <LordAro> that sounds like it has desync potential
19:15:25 <peter1138[d]> Addressed by #11750?
19:22:30 <andythenorth> โNaps donโt kill people, nappers doโ
19:38:42 <_zephyris> Seems to lead to subtle but annoying colour mismatches in the GUI
19:39:21 <peter1138[d]> PC_ORANGE is only used by the smallmap.
19:40:06 <peter1138[d]> The slightly different colour there is because that is the colour someone drew pixels in.
19:40:14 <_zephyris> Hmm, I mean `_colour_gradient[COLOUR_ORANGE][4]`
19:40:29 <_zephyris> The line for the settings tree is different to the orange text.
19:40:53 <_zephyris> And the same for subcategory trees of trains I think
19:46:06 <frosch123> text colours (TC_xxx) and company colours (COLOUR_xxx) do not match
19:47:47 <peter1138[d]> Yeah, they just have an overlap in names. The line could be drawn with `_string_colourmap[TC_ORANGE]` instead of `_colour_gradient[COLOUR_ORANGE][4]` but so far nobody has been bothered enough by it ๐
19:48:39 <_zephyris> Weird that GUI elements are using CC rather than text colours then!
19:48:56 <frosch123> the window backgrounds and all button shades are CC
19:49:01 <frosch123> only text uses text colours
19:49:34 <peter1138[d]> Replace with hotkeys. Make it 12% faster.
19:50:56 *** virtualrandomnumber has joined #openttd
19:51:01 *** virtualrandomnumber has quit IRC ()
20:02:35 <_zephyris> No text, no translation needed, perfect!
20:04:24 <peter1138[d]> Might give up on this Doom WAD, the difficulty jumped ๐ฎ
20:04:49 <peter1138[d]> Not keen on enforced "die at the end of the map to reset your state"
20:16:54 <xarick> it is saying the origin which was added, and found with a docking tile, has a label of 0
20:17:18 <xarick> it's a docking tile! has water
20:24:13 <xarick> the region wasn't updated when i placed the canals
20:24:57 <xarick> but why isn't it happening on a map other than 4k
20:28:15 <xarick> geee... this was tedious to debug
20:29:10 <xarick> now as to find why the region wasn't updated...
20:43:10 <peter1138[d]> Oh, regression failed :/
20:51:18 <xarick> i tried this in master, and I just can't reproduce it
20:51:35 <xarick> it continues to be my code
21:01:16 <xarick> what in there is wrong
21:05:42 <xarick> dang it, Ithink i found it
21:06:31 <xarick> dang, false alarm, it's something else
21:07:40 <andythenorth> goes it play OpenTTD ?
21:07:43 <andythenorth> when is version 2?
21:10:09 <peter1138[d]> Hmm, can I ctest with valgrind...
21:10:44 <andythenorth> is this for your straight line ship pathfinder?
21:10:50 <andythenorth> or are you trying to Doom speedrun?
21:11:49 <peter1138[d]> 1/1 Test #65: regression_stationlist ...........***Failed 136.69 sec
21:11:52 <peter1138[d]> Okay so that ...
21:11:56 <_glx_> peter1138[d]: and only for VS2019
21:12:25 <peter1138[d]> I think it just timed out with valgrind rather than actually failing though.
21:12:33 <_glx_> it's timeout fail, so crash window or assert
21:13:53 <peter1138[d]> Yes, but I don't know how to see it :/
21:15:27 <_glx_> I can try something, but I need to install 2019 toolset first
21:15:57 <xarick> how do I debug master and my branch side by side with visual studio?
21:16:26 <xarick> i create another repository?
21:16:27 <peter1138[d]> Clone your local repo, checkout master, build it, run ijt.
21:25:23 <peter1138[d]> If I know how to fix regression to spit out an error instead of hanging on a Window :/
21:25:40 <andythenorth> did I break cdist this game?
21:31:13 <truebrain> And everything still works?
21:32:06 <peter1138[d]> Even the colours are right ๐
21:32:42 <Rubidium> not sure about everything, but the regression tests do not fail and I can get into the main menu. Though I forgot to make a release build, so it's practically a slide show and didn't want to wait an hour or so to recompile
21:34:42 <truebrain> Did anyone ever said you are crazy? ๐
21:35:16 <truebrain> And gratz, you are the first person in a decade to try "big" ๐
21:36:19 <Rubidium> well, I was fairly sure it wouldn't be completely dead because Debian (still) manages to build OpenTTD for s390x
21:39:40 <_glx_> ok I can configure with the right toolset, let's build and run regression
21:43:56 <_glx_> stupid me, I should get the PR code too
21:46:24 <_glx_> update your vcpkg clone
21:49:32 <xarick> cleared it, now it's building
21:50:12 <xarick> two visual studios building at the same time
21:50:38 <_glx_> good news, regression hangs when using 14.29 toolchain (VS2019)
21:51:21 <_glx_> I'll need to run my regression debug target
21:51:26 <peter1138[d]> Hmm... infinite loop?
21:52:27 <_glx_> please VS, stop opening hundreds of powershell windows
21:53:18 <xarick> I need to convince myself I need a 16 core cpu
21:53:29 <xarick> maybe this is a valid reason
21:53:59 <_glx_> that's what I get when I run openttd in VS using regression args
21:55:22 <peter1138[d]> Maybe that helps. It changes how the town_production_cargoes are reset.
21:57:23 <peter1138[d]> Although I've just noticed there's a break at :217 there that should probably be a continue...
21:57:35 <_glx_> same error, and on same cargo (bitnum 3 sorted[7]
21:58:39 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:58:57 <peter1138[d]> Can you see its town_production_effect value?
22:01:14 <peter1138[d]> So nothing special there :/
22:05:59 <peter1138[d]> @glx line 25 of cargotype.cpp, add {} to the end
22:12:34 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:16:29 <_glx_> _Mylast was wrong for the insertion of a value
22:16:48 <_glx_> 0xcdcd... is a memory error marker
22:16:56 <peter1138[d]> Yes, the vectors were not initialized correctly.
22:17:51 <peter1138[d]> std::array is the awkward container for that
22:22:14 <_glx_> seems to be a compiler bug too
22:25:31 <_glx_> nice I added the toolset to only one preset, and it's now applied to all
22:25:49 <andythenorth> oof I can't play properly
22:26:42 <peter1138[d]> _glx_: I think the bug is with a static vector, but this is an array of vectors.
22:32:51 <peter1138[d]> But oddly, I don't remember it failing before. But, it was c++17 before.
22:55:21 <peter1138[d]> Nice green tick now ๐
22:56:02 <_zephyris> (arguably) better... Except I can't work out what I'm supposed to use for black.
22:58:26 <_zephyris> And what's with the glitchy 2px wide lines using `GfxDrawLine`?
23:01:45 <_glx_> I think it's a known bug
23:01:46 <peter1138[d]> Known big, nobody fixed yet ๐
23:01:58 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:02:04 <peter1138[d]> Auto complete on my phone really hates bug.
23:02:21 <_glx_> someone tried IIRC, but it broke somewhere else
23:02:38 <_zephyris> I could use fill rect I guess
23:02:55 <peter1138[d]> Have you added a shadow to the line? Hmm
23:03:35 <_zephyris> Line: Same colour as orange text, scale with bevels, add shadow. +/- Icons: Same colour as orange text.
23:04:33 <peter1138[d]> Doesn't seem to be the same shade there, yet.
23:06:07 <_zephyris> Nope, can't find black! Currently `TC_BLACK`, which doesn't give black. `_colour_gradient[COLOUR_GRAY][0]` is gray too.
23:06:44 <peter1138[d]> PC_BLACK got line drawing.
23:07:16 <_glx_> TC_ is only for strings
23:07:58 <peter1138[d]> TC is only an index to an array of palette colours.
23:08:13 <_zephyris> `_colour_gradient[COLOUR_ORANGE][5]` is the same shade
23:08:40 <peter1138[d]> Only a coincidence. Newgrfs can change that.
23:09:37 <peter1138[d]> 195 is the palette colour that TC_ORANGE uses.
23:09:48 <_zephyris> It currently uses `_colour_gradient[COLOUR_ORANGE][4]`!
23:10:29 <_zephyris> Yeah, I'm after 0xC3
23:11:26 <peter1138[d]> Make line-drawing glyphs and draw it all as text ๐
23:13:12 <peter1138[d]> Don't do that, btw.
23:13:21 <_zephyris> I can think of several reasons it'd break!
23:14:01 <peter1138[d]> It's not a bad idea for the expand/shrink icon mind you.
23:17:04 <_zephyris> Well, there's always unicode private ranges...
23:18:46 <_zephyris> Hah, can't believe I hadn't checked the train/lorry/etc. icons. Looks great being rendered anti-aliased.
23:19:21 <peter1138[d]> That"d break when people use out-of-proportion font sizes.
23:19:30 <peter1138[d]> Yup, nice icons.
23:19:56 <peter1138[d]> Vertical alignment isn't quite correct.
23:23:20 <_zephyris> And would break with the current line height bug(?)/font property problem(?) under windows...
23:23:43 <_zephyris> peter1138[d]: Yeah, I thought I'd fixed that. Obviously not... Add to the todo
23:29:28 <_zephyris> Hmm, seems perfect actually. You're probably noticing the sub-par design of the aeroplane.
23:30:40 <peter1138[d]> Oh I guess it's the extra padding you get on top
23:31:42 <peter1138[d]> Sesningden. Such names.
continue to next day โต
