IRC logs for #openttd on OFTC at 2024-01-25
⏴ go to previous day
00:00:10 <truebrain> if you want to authenticate with your pub-key, send packet A without a password
00:00:30 <truebrain> if you want to authenticate with your password, send packet B with the password in the hash
00:00:47 <xarick> waiting for December (300 days service intervals)
00:01:13 <truebrain> and maybe a third one for "backwards compatibility", where you can just send password plaintext
00:01:55 <peter1138[d]> Don't support too many options.
00:02:09 <truebrain> I suggest to remove the plain-text 😛
00:02:24 <truebrain> but the other two options might solve Rubidium's puzzle: if you want to login by password, you can
00:02:32 <truebrain> if you are whitelisted, that is fine too (and you don't need the password)
00:05:46 <truebrain> I think that is the summary, right _jgr_ ? Anything to add to it? 🙂
00:08:23 <_jgr_> That seems like a good summary to me 🙂
03:35:11 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:37:25 *** Wormnest has quit IRC (Quit: Leaving)
04:48:50 *** krushia has joined #openttd
06:25:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:32:03 *** tokai|noir has joined #openttd
07:32:03 *** ChanServ sets mode: +v tokai|noir
07:39:01 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:53:24 *** D-HUND is now known as debdog
08:09:50 <truebrain> I know what is missing with arrow-key movement .. acceleration. When you press really short, you expect 1 pixel, but you always get 10 😛
08:17:57 <truebrain> finally figured out what that 512 * ZOOM_LVL_BASE was .. I think. Had nothing to do with zoom. Just 128 * TILE_SIZE. Makes a lot more sense 😄
08:20:08 <peter1138[d]> That is kinda what I said.
08:20:17 <truebrain> the "kinda" part is important 😛
08:20:22 <truebrain> but it did trigger me to look at it again 🙂
08:20:44 <peter1138[d]> I mean, I thought that's what you understood already 🙂
08:21:33 <truebrain> clearly, I did not! 😄
08:21:33 <peter1138[d]> No actually, I misread.
08:21:44 <peter1138[d]> I don't know what you mean now ;D
08:22:27 <peter1138[d]> 512 is just a random value that "someone" choose without really thinking about it.
08:22:44 <truebrain> yeah, the 512 wasn't the issue. The ZOOM_LVL_BASE seems incorrect 😄
08:22:47 <peter1138[d]> Then when 4x extra was introduced that needed to be scaled up because the base size changed.
08:23:00 <peter1138[d]> So * ZOOM_LVL_BASE does that.
08:23:20 <truebrain> but a tile still has 16 pixels in the viewport
08:23:23 <truebrain> no matter what zoom 😛
08:26:20 <peter1138[d]> No. Tiles only have 16 subtile positions.
08:26:28 <peter1138[d]> But scrollpos_x/_y are in pixels.
08:27:00 <peter1138[d]> `RemapCoords()` does the same * ZOOM_LVL_BASE.
08:28:33 <truebrain> so then I am still confused what it has to do with ZOOM_LVL_BASE 😛
08:28:59 <peter1138[d]> Well we made every 4x larger.
08:29:13 <truebrain> so the viewport pixels were made larger?
08:32:59 <peter1138[d]> Subtiles are still 16 positions, that never changed (hah yet). The 3D tile x/y/z coordinates are converted to screen x/y coordinates. Screen coordinates were bumped up by ZOOM_LVL_BASE.
08:33:23 <truebrain> there are a few odds and bits about this still ... hmm
08:33:37 <truebrain> has to do with arrow-movement btw
08:35:57 <peter1138[d]> I can't find that bit again 😄
08:36:04 <truebrain> yeah, took me a while too
08:36:14 <truebrain> okay .... so the movement isn't 20
08:36:24 <truebrain> as there is a secret `2`
08:36:37 <truebrain> did not see that one coming
08:37:32 <truebrain> that explains why my math wasn't adding up there; okay, another thing that I now understand
08:37:38 <peter1138[d]> It's 10 or 50 * shift * the table lookup * current zoom level.
08:37:50 <truebrain> yeah, the table lookup was of surprising values 😄
08:37:57 <truebrain> makes sense, just didn't see it coming 😛
08:38:19 <peter1138[d]> Don't forget about autoscroll which everyone forgets about.
08:38:32 <truebrain> right, back to the max_scroll we go ..
08:38:43 <truebrain> as 512 tiles per 30ms is a weirdly large value
08:38:58 <peter1138[d]> And yet you said it scrolls too slowly 🙂
08:39:08 <truebrain> not after my fixes!
08:39:17 <truebrain> the value was fine, as it turns out; it was just not per time-unit
08:39:24 <peter1138[d]> Oh, it's not 512 tiles. It's 512 pixels.
08:39:40 <peter1138[d]> * ZOOM_LVL BASE 😄
08:39:53 <truebrain> scrollport is always in pixels at 4x zoom, right?
08:39:58 <truebrain> even if zoomed out, it doesn't rescale?
08:40:20 <truebrain> and there are 64 pixels in a tile, in the width
08:40:37 <truebrain> so that would mean 8 tiles per 30ms
08:41:46 <peter1138[d]> Sounds about right. That's slow when you're jumping from tile 0,256 to 256,0.
08:42:38 <truebrain> ah, yes, so that is why I doubled it
08:42:42 <truebrain> wauw, big circle much?
08:45:08 <peter1138[d]> I don't think it's 1 second. That's 65536 * ZOOM_LVL_BASE pixels to move, limited to 512 * ZOOM_LVL_BASE pixels.
08:45:45 <peter1138[d]> 128 steps. 1/30 * 128 = 4.2624 seconds, ignoring the slowing down at the end.
08:46:02 <truebrain> that for sure isn't true, as we can measure it is not over 2 seconds easily
08:46:15 <peter1138[d]> Oh you know what I did.
08:46:23 <peter1138[d]> 65536 is at ZOOM_LVL_BASE a;lready.
08:46:26 <truebrain> it is 16384 * ZOOM_LVL_BASE to scroll 256 tiles, not?
08:46:53 <peter1138[d]> 1.0656 seconds, correct 😄
08:47:31 <peter1138[d]> No wonder we have no idea what we're doing.
08:47:42 <peter1138[d]> I forgot I multiplied about 2 seconds after doing it.
08:47:54 <peter1138[d]> "we" loosely here.
08:48:36 <truebrain> my math says 960ms btw
08:48:56 <truebrain> it is 30ms btw, not 1/30 of a second 🙂
08:49:08 <truebrain> or am I wrong .. checkingggggg
08:49:13 <truebrain> (I feel like a certain person now 😛 )
08:49:27 <peter1138[d]> So with SVG RGBA to palette index, I also need a way to allow you to draw pixels in the animated range. They are effectively all magenta at this point :/
08:50:48 <truebrain> owh, this is in game-ticks ofc
08:51:03 <truebrain> well, I made it 30ms by dividing by 30ms 😛
08:51:48 <truebrain> what do we run on now ... I forgot
08:52:22 <peter1138[d]> I hope scrolling is not related to game ticks 😄
08:52:28 <truebrain> it is updated during
08:52:34 <peter1138[d]> (Yes I probably bungled that calculation too)
08:54:48 <truebrain> no, I can't be right
08:54:57 <truebrain> owh, draw-tick, yeah, pfew
08:55:13 <truebrain> this explains why it was scrolling at a different speed for some people
08:55:17 <truebrain> it is bound to the Hz you selected
08:55:47 <truebrain> so smoothscrolling was done during UpdateWindows(), which is called refresh-rate times per second
08:55:56 <truebrain> which can be 30Hz .. 60Hz ... 😛
08:56:05 <truebrain> and in my case: 144Hz!
08:56:43 <peter1138[d]> So your changes to make it timed-based are definitely correct (not that I thought that was wrong anyway)
08:56:55 <truebrain> yeah, but confirms we really should do it 😛
08:56:58 <truebrain> please proof-read my comments
08:57:01 <truebrain> I think I got it right now
09:05:11 <peter1138[d]> Do you know what/ SetViewportPosition is very weird.
09:06:17 <peter1138[d]> Okay, the last bit is magic.
09:07:02 <peter1138[d]> It is literally moving pixels around, checking what's in front of the viewport, so avoid having to actually redraw the viewport.
09:07:17 <peter1138[d]> So that explains the window iterator.
09:08:39 <peter1138[d]> This looks better, however there is one thing that might be nice to change.
09:09:20 <peter1138[d]> It's kind of separate to this issue but related enough that it could affect your changes significantly.
09:09:50 <peter1138[d]> intro_gui.cpp:242-255
09:10:17 <peter1138[d]> That is where the intro game is automatically panned when using the release-version intro game.
09:11:15 <peter1138[d]> It handles slow panning by itself, but it bypasses smooth scrolling (it wants to get to a specific point at a specific speed, rather than as fast as the smooth scrolling goes)
09:12:17 <peter1138[d]> Looks like it also depends on user activity. Oof.
09:14:39 <peter1138[d]> Oh. You know what. Forget it, this is horrible too 😉
09:15:36 *** thelounge345 has joined #openttd
09:20:15 <peter1138[d]> It might've been smooth but just following a vehicle at the time I was looking. Which will never be smooth 😄
09:23:48 *** thelounge345 has joined #openttd
09:30:06 <peter1138[d]> truebrain: you're a trend-setter. They're changing the "Allow Cheats" option to "Allow Commands" in Minecraft.
09:32:32 <truebrain> peter1138[d]: haha, excellent 😛
09:32:48 <truebrain> peter1138[d]: I will make it a point to look at it some day 🙂 For now, I want to push my "change default to smooth scrolling" 😛
09:33:40 <truebrain> can't believe it depended on the refresh-rate
09:34:05 <peter1138[d]> I guess nobody noticed.
09:34:22 <truebrain> also relatively new ofc, that refresh-rate can be configured
09:34:54 <peter1138[d]> I guess it would've been affected by fast-forward at some point in the past.
09:35:39 <truebrain> ugh, starting vscode makes a DNS request to their update server
09:35:42 <truebrain> but there are so many CNAMEs in there
09:35:50 <truebrain> that it exceeds the MTU of UDP when you are behind a VPN
09:35:54 <truebrain> so ... DNS resolving fails
09:35:58 <peter1138[d]> I'm trying to work out what 11860 conflicted with to require an update. Or was it just too many commits behind now...
09:36:02 <truebrain> why do people use such long CNAMEs 😦
09:36:41 <reldred> truebrain: fucking WHAT?
09:36:46 <reldred> why would you even DO THAT
09:36:59 <truebrain> peter1138[d]: It was just a rebase for me to enable preview so you can see it in the browser 🙂
09:37:15 <truebrain> dunno, since the 80s?
09:37:46 <reldred> Have CNAME's so long they can possibly exceed MTU in encapsulated traffic
09:38:07 <truebrain> `dig update.code.visualstudio.com` and have fun
09:38:14 <truebrain> at the moment it is relatively short
09:38:26 <truebrain> but they use random words for their load balancing
09:38:29 <truebrain> so sometimes there are very long words
09:38:45 <reldred> blame azure for everything
09:38:54 <reldred> and by association, blame microsoft
09:38:59 <peter1138[d]> I could just pi-hole it 🙂
09:39:05 <truebrain> it is also the infrastructure I work in, as the DNS repeater should know about the MTU limit 😛
09:39:32 <truebrain> but it is a fun issue, where I cannot launch VSCode for good parts of the day
09:39:35 <truebrain> I just have to be lucky
09:39:38 <truebrain> and not shut it down after
09:39:42 <truebrain> makes starting the day interesting
09:40:14 <reldred> I got involved in a really hilarious four way fight once between Apple, Avaya, and two different engineering teams from our largest telco in Australia
09:40:37 <truebrain> fragmented UDP doesn't exist 😛
09:40:50 <reldred> One of the two engineering teams wanted it to 😛
09:40:52 <truebrain> it either arrives or doesn't; I refuse to believe in any other world 😄
09:41:04 <truebrain> our network protocol used UDP to talk to the master-server
09:41:12 <truebrain> the issues that gave ........
09:41:20 <truebrain> (the reason it is now TCP btw)
09:41:30 <truebrain> some corperate networks do HORRIBLE shit with their traffic
09:42:11 <truebrain> but yeah, over the years more than one person suggested to fragment UDP. Which always made me giggle 😛
09:43:15 <reldred> So yeah, funny story, and I wasn't NDA'd so I'm free to share it. We kept running into a weird issue with the SIP trunks from $carrier getting a weird call dropout but *only* from incoming mobile phone calls from $carrier that were made from iPhones and only after a particular firmware version, and *only* when voice over LTE was enabled on the handset (which became the default pretty soon before).
09:43:25 <peter1138[d]> "i have a joke about fragmented udp but you wouldn't get it"
09:43:46 <truebrain> peter1138[d]: hahahaha, lol, wth! 😛 That is funny 😄
09:44:04 <reldred> So unlike most other carriers in Australia, this carrier was basically doing proxied SIP end to end. If you pulled apart a header you could see it had originally came from the LTE network and even see details about the originating tower, yadda yadda.
09:44:30 <reldred> At this time, $carrier was also mandating that all SIP trunks had to be set to UDP
09:45:15 <reldred> And what we found, was for calls coming from the VoLTE network, the goddamn codec list in the SIP header made the SIP invites get to nearly 1700 bytes...
09:46:26 <reldred> So the four way fight ended up being Apple and the PABX vendor beating the shit out of $carrier's SIP trunking team for mandating everyone use UDP. $carrier's SIP trunking team insisted on using UDP because they didn't want to wear the overhead of TCP.
09:47:46 <reldred> but why did it only happen after a particular firmware version? Apple added an extra flag to the SIP INVITE's *they* were sending to the VoLTE network that the end party needed to follow the RFC's to the fucking letter. Some 3GPP consortium specification blah blah blah.
09:48:52 <reldred> The Avaya PABX on the far end, got the fragmented UDP - which it had no problems reassembling btw - saw the flag in the header to obey the RFC's and silently drop any invites that didn't comply, and shitcanned all the phone calls coming specifically from iPhones running a certain firmware version.
09:49:23 <reldred> Some other PABX's however would memory leak and crash approximately 30mins after receiving the fragmented invite...
09:50:21 <reldred> (but I didn't have to maintain those makes of PABX, just the Avaya's, so my colleagues had the fun job of dealing with the frequent crashes after I identified what the cause was)
09:50:33 <truebrain> devices that support reassembling fragmented UDP have a nice issue called I WILL SHIT OVER YOUR DEVICE AND YOU WILL RUN OUT OF MEMORY NOW
09:53:08 <reldred> so yes, I spent far too much time at my last job reading sip invite headers and picking fights with carriers
09:53:58 <truebrain> I once had an ISP that had such crappy switches that UDP packets dropped in ~50% of the time. On its own annoying, but not a real problem. The real problem? They used EAPOL for authentication .. you had about 50% chance of being able to authenticate. It was "fun" 😛
09:54:30 <truebrain> especially fun was the part where a shithead of 19 years old start telling their IT department what the problem is ... LALALALA
09:55:19 <reldred> I monitor the DC setup I look after pretty obsessively. Everything's tracked, in Grafana, and on the wall for all to see.
09:55:42 <LordAro> truebrain: bwhaha. (re CNAMEs)
09:55:51 <truebrain> tnx for adding the context 😄
09:56:02 <truebrain> wait till you read peter1138[d] 's joke .. it is the best one of today
09:56:20 <peter1138[d]> I do wish it was mine, heh
09:56:24 <reldred> so yes, your little DNS fragmented UDP issue made me chuckle TrueBrain lmao
09:57:25 <LordAro> truebrain: i knew i was still scrolled up :p
09:59:43 <peter1138[d]> Hmm, music perhaps.
10:01:08 <peter1138[d]> Maybe I need something a bit more custom with SVG rendering that allows drawing a specific palette index directly.
10:01:33 <LordAro> that's a very old UDP joke
10:01:43 <LordAro> reldred: excellent story
10:03:06 <reldred> I just love imagining the dutiful little avaya pabx, handling fragmented UDP all day without a care in the world, carefully reassembling headers and getting on with the work, then all of a sudden getting one from an iphone, seeing the flag and going 'OK THEN!' and throwing it in the fucking *trash*
10:03:35 <reldred> and then saying *nothing*
10:03:59 <reldred> (until you collect from the wire level)
10:04:04 <LordAro> i dread to think how hard that was to debug
10:06:21 <_zephyris> peter1138[d]: Surely the simple work-around is to pre-process the svg, replacing colours that don't exactly match a palette colour? Gradients can't match, so should go blue. Semi-transparent shifts the colour of anything under it, so draw as blue. Etc.
10:09:45 <peter1138[d]> Nope, we can already convert RGB to palette index. Issue 1 is when you need to use or avoid specific palette indices for remapping, we can support this by limiting which palette indices we can map to. Issue 2 is the palette animation indices, which don't actually have a nearest colour they can map to (they're all 0,0,0 in the base palette table).
10:10:01 <peter1138[d]> (No amount of RGB LUTs would solve issue 2)
10:11:15 <peter1138[d]> I did this which lets you limit which palette indices are used by selecting (at the NewGRF level, not SVG) a pre-defined palette index restriction.
10:11:44 <peter1138[d]> But that doesn't help with animated indices, so I think is not the right way.
10:13:55 <peter1138[d]> It could be possible to add a "everything in this svg layer is palette index 220" attribute, so it basically ignores the any colour and just goes by alpha.
10:14:37 <peter1138[d]> But "svg layer" here means a separate SVG file embedded into the same sprite -- a bit like the mask sprite now, but you'd need one for each colour.
10:15:03 <peter1138[d]> Hmmm, or maybe a RGB X = Palette Index Y look up table provided by the NewGRF.
10:15:59 <peter1138[d]> Still a separate layer but it would be possible then to just use one layer for the remap.
10:17:42 <peter1138[d]> For authors it's a pain for sure, however it's done.
10:19:28 <_zephyris> IMO a layer for remap gets annoying. Because you might define a CC bit of the picture with a stroke occluded by another filled object, etc.
10:20:01 <_zephyris> I probably need to make a demo file to illustrate what I'm suggesting.
10:21:38 <peter1138[d]> No, I understand.
10:22:10 <peter1138[d]> To have it all in one svg file definitelky requires a custom SVG renderer that understands RGBAM.
10:23:37 <peter1138[d]> And still needs some custom attribute to specify which palette index to use, which no other svg software will understand.
10:24:06 <reldred> probably not the worst abuse of the SVG spec that's been committed
10:28:58 <emperorjake> I just saw that 11624 got merged as well, awesome
10:29:06 <emperorjake> time to make more PRs
10:32:50 <peter1138[d]> Extending nanosvg might be possible but it's all quite limited and basically a dead implementation at the moment.
10:33:16 <peter1138[d]> On the other hand, that means no need to worry about merging in updates.
10:33:38 <peter1138[d]> lunasvg is more capable but quite a bit larger, and we'd have to vendor that if we customize it.
10:34:16 <truebrain> lunasvg is available in vcpkg, so there is that
10:34:28 <peter1138[d]> That's useful to know.
10:34:30 <truebrain> just don't customize it! 😛
10:34:46 <peter1138[d]> I was considering switching as it supports stylesheets, nanosvg ignores them completely.
10:34:49 <truebrain> it is not available in Ubuntu, sad
10:35:19 <truebrain> so Linux would get dependant on vcpkg too; not sure that is a bad thing, honestly
10:35:30 <truebrain> it does deliver much more up-to-date versions of things
10:35:53 <peter1138[d]> I vendored nanosvg for now, in fact that's how it's designed to be used, it's basically a header-file implementaiton.
10:36:49 <peter1138[d]> I don't think we can do easier-to-use palette index stuff without customising, sadly.
10:38:09 <peter1138[d]> "Reverse-rendering" would help with Zephyris point (draw palette index first, overwrite with rgba second) but it's not easy for authors to use.
10:38:42 <truebrain> pff, since when do we care about authors
10:40:53 <locosage> the most cursed rust code I've ever written...
10:40:53 <locosage> iptrm = iptrm.add(1);
10:40:53 <locosage> iptrm < iptrm_end && *iptrm == *{jptr = jptr.add(1); jptr}
10:41:35 <peter1138[d]> I hope that's nothing to do with pointers.
10:41:44 <peter1138[d]> But given ptr...
10:42:30 <peter1138[d]> I don't know must about rust... is this a big unsafe block, or is each dereference checked?
10:42:51 <locosage> yeah just wrapped everything in unsafe
10:43:12 <xarick> could you make autosaves multithreaded
10:43:24 <xarick> lzma:9 takes 1 minute to save 4k maps
10:43:35 <locosage> trying to measure performance of different variations and random boundary checks in rust aren't helping
10:43:58 <peter1138[d]> So basically writing C in rust... good work.
10:44:17 <xarick> it only uses 1 thread to compress
10:44:28 <truebrain> yes; which is not the same thread as the game
10:44:30 <locosage> it is somehow faster than c++ xD
10:45:48 <peter1138[d]> The lzma part could possibly be multithreaded these days?
10:46:24 <peter1138[d]> Make a PR. My 256x256 maps don't need it.
10:47:05 <xarick> eh... well I tried looking at lzma code, it's a different style
10:47:22 <truebrain> peter1138[d]: xz, yes; lzma, not sure?
10:59:30 <xarick> oh lzma source is different now
11:08:08 <xarick> Easy .xz Stream encoder initialization
11:23:18 <xarick> yeah, i have no idea what im looking at
11:30:59 <xarick> those averages are scary high 😦
11:44:13 <xarick> at this pace... i predict about an average of 50 ms ship ticks when there's 5000 ships on all companies, that's 75000 ships
11:44:58 <xarick> 70000 ships* only 14 ais, my bad
11:46:00 <truebrain> So the argument is: in my super unrealistic use case it only takes 50ms to handle all ships? Not sure why that is "scary high", but that might be just me.
11:47:22 <belajalilija> no one needs 200+ ships on a multiplayer server
11:47:39 <xarick> the scary high part is about YapfShipFindNearestDepot in comparion with YapfShipChooseTrack/YapfShipCheckReverse
11:47:46 <belajalilija> and no single person needs 2800 ships on single player
11:50:10 <truebrain> Everyone should play how they like 😄
11:50:21 <truebrain> just assuming we can handle 70000 ships in a timely manner is .. unrealistic 😄
11:50:35 <truebrain> (as with any other vehicle type 😛 )
11:52:35 <emperorjake> The rest of the aircraft are owned by a separate company. There were 4 companies to get around the vanilla 5000 vehicle limit but I merged them in JGR to show the full amount of ships, trains and RVs
11:52:49 <xarick> wow, this still happens
11:53:12 <truebrain> emperorjake: very nice 😄
11:54:15 <emperorjake> My long running games always end up with hundreds of ships, even in MP
11:55:27 <xarick> what's the edge case gonna be now
12:04:22 <truebrain> hmm, OpenTTD isn't on the Epic Launcher .. how difficult would that be? 😛
12:06:10 <xarick> TRACKDIR_BIT_NONE (0) how ?
12:07:28 <xarick> for some reason I'm passing a teleported starting tile with no tracks
12:08:30 <xarick> that traversability bits is either lying to me or...
12:13:45 <xarick> another case of starting tile edge case, but how come it got no tracks from here?
12:21:23 <xarick> i dont trust breakpad debugger... these values make no sense
12:23:13 <xarick> why are the values optimized away?
12:27:24 <truebrain> Complain A: omg, this is so slow
12:27:30 <truebrain> Complain B: omg, why are things optimized
12:31:24 <xarick> if the diagdir was invalid, it would assert at DiagdirReachesTrackdirs
12:37:28 <reldred> Hmm, looks similar to the road direction stuff that was causing me issues with diagonal roads. What I found with that was you could have invalid diagdirs and they wouldn’t necessarily assert there, I was getting asserts for articulated vehicles shearing in two 🤣
13:12:38 <peter1138[d]> breakpad isn't a debugger.
13:14:35 <_glx_> Yeah it just writes the dump, and the dump is exactly like the old one
13:16:03 <_glx_> Dumps can give a hint on what happens, but not really more
13:39:52 <xarick> if I start a newgame with seed 1, will that also make the random seeds of AIs based of it?
13:40:59 <xarick> for some reason I'm not getting the AIs to replicate the same play they had before
13:41:07 <xarick> they're doing differently
13:45:36 <LordAro> map seed is not the same as random seed
13:55:38 <xarick> half a second and a 4k map savegame is done
14:19:16 <_glx_> It's fast but the savegame is huge
14:27:17 <xarick> expecting a crash any moment now
14:27:31 <xarick> calls to findnearestdepot have started
15:17:06 <peter1138[d]> 40 minutes later...
15:32:03 <_glx_> Might be simpler to implement a function to change service interval
15:32:51 <_glx_> Or just ctrl-send-to-depot
15:38:44 <xarick> i should be happy, but i'm not... a crash is expected... I didn't change anything
15:39:47 <xarick> something I did however was clear database errors, rescan solution, delete caches and rebuild
15:40:02 <xarick> but the code is unaltered
15:41:47 <LordAro> crashes that you can't reliably reproduce are the worst
15:54:55 <xarick> I suppose I didn't update the script properly
15:56:55 *** Wormnest has joined #openttd
15:58:20 <xarick> local depot_order_flags = AIOrder.OF_STOP_IN_DEPOT;
16:00:29 <xarick> local depot_order_flags = AIOrder.OF_STOP_IN_DEPOT | AIOrder.OF_GOTO_NEAREST_DEPOT;
16:02:36 <xarick> gonna change choosetrack to 10000
16:13:54 <truebrain> peter1138[d]: is it dinner time?
16:33:58 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
16:34:41 <peter1138[d]> Hmm, what to do about the closebox sprite...
16:46:56 <truebrain> Owh boy.. github is bitching about node16 stuff 😄
16:52:09 <LordAro> truebrain: how dare you use a slightly old version of nodejs
16:57:20 <peter1138[d]> I see at least one other project did the pinning thing...
17:08:14 <peter1138[d]> Uh, this is so weird.
17:23:30 <peter1138[d]> So SPR_CLOSEBOX is sprite no 143. That means it is actually a font sprite, complete with shadow. But we draw it as a normal sprite, with some special colour remap handling.
17:48:14 <rau117> The buoys will not be removed/hidden after the introduction of the new ship pathfinder?
17:50:47 <xarick> after 10 thousand years
17:55:49 <xarick> seems to involve locks, again
17:58:05 <peter1138[d]> Are you trying to pass through the lock wall?
17:59:17 <xarick> not all parameters make sense
18:01:36 <xarick> difficult to decipher whether the values are real or guesses
18:03:22 <xarick> the 2 regions involved apparently are the square at the bottom and the square at the left side
18:03:58 <xarick> which one is the parent, which one is the current
18:06:01 <xarick> there is a depot on the left region, so that's the current region
18:07:20 <xarick> there's none on the south, it's entering from the bottom to the left, the yapf is called at the region with the lock
18:07:31 <xarick> at the border shared by 2 regions
18:07:44 <xarick> the crash is on the lock, ok, it's starting to make sense
18:08:02 <xarick> let me show u depot screenshot
18:10:56 <xarick> traversability bits are lying
18:11:27 <xarick> there is no tracks when entered from the yellow arrow
18:11:52 <xarick> but somehow... the bit was set
18:12:32 <xarick> the green arrow is yapf starting a teleport pathfind call
18:12:39 <xarick> to the closest ship depot
18:12:43 <xarick> with is that one as red
18:14:24 <xarick> I'm like 90% sure the bug is actually not the pathfinder
18:14:29 <xarick> but the traversability bits
18:17:07 <xarick> assert((trackdirs & ~TRACKDIR_BIT_MASK) == TRACKDIR_BIT_NONE); this assert is misleading
18:18:00 <xarick> (TRACKDIR_BIT_NONE & ~TRACKDIR_BIT_MASK) == TRACKDIR_BIT_NONE
18:18:11 <xarick> it's not what I thought it is
18:24:35 <xarick> confirmed!... the bits lie
18:26:44 <xarick> similar to the situation with object tiles
18:29:30 <xarick> need to look at buildlock code, see what it does (not) do
18:40:03 <xarick> an actual source for desync
18:42:26 <xarick> i'm sure I had a hand in this part too
18:42:36 <xarick> now it's biting me in the ass
18:43:43 <xarick> build lock code is so different than the other build commands
18:45:41 <peter1138[d]> Nice. My comment was kinda right then 😉
18:47:36 <peter1138[d]> > No description provided.
18:47:55 <truebrain> except it was no accident 🙂
18:48:03 <truebrain> if you actually need a description for that PR, something is wrong 😛
18:48:12 <_glx_> yeah and he will most likely do a forced merge 😉
18:48:51 <truebrain> I need the other one first, it seems
18:49:12 <truebrain> at least it still works with Node20
18:53:02 <truebrain> ironically, Annotation Check doesn't notice its own annotation 😄
18:53:23 <_glx_> it doesn't have access to them
18:54:17 <truebrain> seems next month I will also be adding a ton of entries in dependabot file, to auto-bump workflows
18:54:22 <truebrain> should make life a bit easier
18:55:09 <talltyler> Ah, didn’t scroll up 🙂
18:56:44 <_glx_> but it was faster for me to fix it now 🙂
18:56:58 <truebrain> owh, I have a lovely chicken/egg issue
18:57:02 <truebrain> need to spam a bit more
18:57:38 <_glx_> as long as you don't move an issue with many comments to discussion 😉
18:57:52 <truebrain> as now I release v5, but we use v4 in our own actions
18:57:56 <truebrain> so next I need to update them to v5
18:57:59 <truebrain> and release a new v5
19:01:35 <truebrain> and only now we can do OpenTTD ... I think
19:04:58 <truebrain> even filled in the template! 😛
19:05:21 <truebrain> I will need to force-squash this PR; but I will nicely wait for an approval on this repo 😛
19:05:49 <peter1138[d]> Hmm, I guess I should try loading fractional bitmap sprite too.
19:06:01 <peter1138[d]> _zephyris: do you happen to have anything drawn I can use? 😄
19:34:30 <xarick> what about a rewrite of BuildLock?
19:39:22 <xarick> have it run DoClear on those tiles
19:42:50 <xarick> run DoClear, discard the price if water, something like that
19:51:16 <peter1138[d]> It needs to maintain the water type, that's why it does not clear the tile.
19:53:25 <xarick> gonna try something there
19:54:45 <_zephyris> peter1138[d]: SVGs? I've got a couple of prototypes kicking around...
19:55:24 <peter1138[d]> Nice, but, but I want to test fractional bitmap too. I guess I can just render SVG and try that 🙂
19:58:06 <_zephyris> Oh, I eee - yeah, nothing specific I'm afraid. I think the old OpenGFX+ Big GUI newgrf has 1.5x equivalent sprites?
20:09:19 <_glx_> oh no, my PR fails because stupid nodejs version enforcement 🙂
20:09:27 <truebrain> so approve mine already
20:09:58 <truebrain> I forgot a smiley 😄
20:10:42 <_glx_> hehe you PR failed too 🙂
20:12:00 <_glx_> yeah it's a pain to force merge on openttd master
20:13:18 <truebrain> with good reason, ofc 😄
20:15:31 <truebrain> now to test this on a fork to see if releases still work ..
20:15:41 <_glx_> don't unmute the bot on this repo 🙂
20:16:47 <_glx_> it's annoying for other repos but I think it's ok for main one
20:17:00 <truebrain> yup; that is why I kept it like this 😄
20:18:22 <_glx_> isn't there something to tell it the proper format ?
20:18:39 <truebrain> it will learn after the first, I believe
20:19:09 <truebrain> Let's see if anything broke
20:19:59 <_glx_> legacy might be an issue
20:20:45 <truebrain> at least one mistake in CDN upload; but I will fix when the CI is done checking this 🙂
20:21:14 <_glx_> yup legacy is an immediate fail
20:21:14 <truebrain> yeah, legacy barks hard
20:21:32 <truebrain> but time to sunset it, I guess
20:21:50 <_glx_> will be hard to keep it
20:22:45 <_glx_> people needing a very old linux compatible will have to self build
20:26:17 <Rubidium> well... good luck ;)
20:26:17 <_glx_> guess you'll need to update the token thing here too
20:26:52 <truebrain> yeah, I have that ready; just not pushing it yet 🙂
20:29:50 <xarick> glx, removelock also doesn't do clearsquare 😦
20:34:00 <truebrain> owh, gcc-matcher is still an issue
20:34:25 <truebrain> you wanna make a fork out of that repo _glx_ and make it node20 instead of node16? 😄
20:34:32 <truebrain> or shall we add it to the actions repo?
20:34:35 <truebrain> might be better, I guess ...
20:35:08 <xarick> pt_PT and pt_BR by the same translator, hmm
20:37:07 <_glx_> gcc and msvc are both on node16
20:38:44 <xarick> nevermind, I better not say it
20:41:54 <_glx_> let's open an issue on the repos, seems to react quite fast
20:42:08 <truebrain> you do that? Cool, tnx 🙂
20:42:15 <truebrain> I will prepare a fork in the meantime, but let's hope it is not needed
20:45:26 <_glx_> at least for 12 to 16 the new release happen on the same day the issue was open
20:48:17 <truebrain> that was SCARY quick
20:48:41 <_glx_> it's nice when action author reacts fast
20:48:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:48:53 <peter1138[d]> I think that works...
20:49:28 <truebrain> good; so now this should be green 🙂
20:49:38 <truebrain> we remove legacy afterwards
20:52:19 <peter1138[d]> Nice, even vanilla works, it just ignores the unknown zoom level.
20:54:35 <peter1138[d]> Hmm, so I guess better source zoom level choice would make sense.
20:57:00 <peter1138[d]> Also a bit inefficient with loading, but maybe not worth caring. All provided zoom levels are loaded, and then it either picks the matching sprite, or scales the highest zoom sprite to the desired zoom.
20:57:24 <peter1138[d]> "Probably fine" but perhaps scaling 1x to 2x is better than scaling 2.5x to 2x.
21:03:35 <locosage> it's a very interesting question what zoom lvl is better to scale
21:03:51 <locosage> I'm afraid in general it depends on how sprites are drawn
21:04:30 <locosage> there is also stuff like 1.5x might be preferable for 3x or vice versa
21:05:27 <peter1138[d]> Yeah, and also scaling down can be preferable to scaling up.
21:06:17 <locosage> there is also difference between svg an raster
21:06:31 <peter1138[d]> Avoiding-the-plague-option: configuration option to disable fractional scaling...
21:07:28 <locosage> well, you definitely need it for old raster stuff
21:07:38 <peter1138[d]> Hmm, also viewport sprites need care. I've only dealt with interface sprites really.
21:08:26 <peter1138[d]> Sure, there are people who complain about the sprites not being fractional, and then those who will complain about it :p
21:08:37 <locosage> veiwport scaling is already weird even without fractional
21:11:14 <peter1138[d]> I guess the option there is "don't provide fractional sprites for them"
21:11:55 <peter1138[d]> Unless I magically implement fractional viewport scaling too 😄
21:12:58 <locosage> what if viewport sprite is used in the gui?
21:13:40 <locosage> I mean station previews etc
21:33:00 <peter1138[d]> Hmm, I guess basing NewGRF-provided fractional scale as 1.0 == ZOOM_NORMAL makes most sense.
21:34:43 <peter1138[d]> Most people still consider ZOOM_LVL_OUT_4X to be normal 1x zoom. Such terminology.
21:35:28 <frosch123> i would expect 1.0 as the original TTD zoom level
21:35:59 <frosch123> the current 4x zoom-in is arbitrary, future screensizes may add more zoom levels
21:36:01 <peter1138[d]> Yes, that is what I meant. grf-py (and I think nml?) uses ZOOM_NORMAL for that.
21:36:31 <peter1138[d]> frosch123: Yup, this is precisely why I decided this 🙂
21:36:41 <frosch123> ok 🙂 so just ottd's ZOOM_LVL_NORMAL is confusing
21:36:49 <peter1138[d]> Interface already goes up to 5x.
21:38:07 <peter1138[d]> It is confusing, and I think we did originally have it set up so that NORMAL was original 1x. Hazy memory.
21:38:30 <peter1138[d]> And of the relevant settings refer to them as 1x 2x 4x zoom in levels.
21:44:57 <peter1138[d]> Hm, now I should put in sprite 731 as an svg.
21:52:19 <locosage> peter1138[d]: yeah, I even switched grf-py from ottd naming because it was confusing af
21:58:02 <_zephyris> peter1138[d]: It's a slightly 'messy' file - I'm interested how the svg rasteriser handles it. It's got gradient fills and strokes, transparent gradients, and linked/duplicate groups.
22:00:01 <_zephyris> peter1138[d]: Looks really good TBH. I guess the optimal behaviour would be to downscale from the next higher integer multiple zoom, or the next higher level if not available. ie. 2x, if missing, from 4x. 1.5x, if missing, from 3x. 1.5x, if missing 3x missing, from 2x, etc.
22:00:44 <peter1138[d]> Remember I said it didn't support much?
22:01:18 <peter1138[d]> 5x interface scale.
22:01:38 <peter1138[d]> It is a bit wonky on the wheels.
22:01:51 <_zephyris> Yeah, that's the linked duplicates
22:02:05 <_zephyris> How does inkscapes 'plain svg' fare?
22:02:33 <_zephyris> Practically, if you can get a useful output from inkscape then it's probably useable for artists.
22:03:31 <peter1138[d]> It's the same. Hmm.
22:03:54 <_zephyris> But, telling people not to use linked duplicates is easy 😉
22:04:57 <locosage> nml/grf-py/whatever could in theory solve that
22:05:39 <peter1138[d]> Your viewbBox is 0 0 20 20.000001 🙂
22:07:00 <peter1138[d]> My minifier makes a mess of it though.
22:07:36 <peter1138[d]> Of course, that's kind of expected...
22:09:42 <peter1138[d]> As for realistic sizes... these at 1x, 1.5x, 2x and 2.5x
22:09:53 <peter1138[d]> Damn, need to click to see actual size 😄
22:10:26 <peter1138[d]> Hmm, I should try mixing it.
22:12:21 <peter1138[d]> Ah, AlternateSprites does not understand SVGSprite yet.
22:14:45 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:23:39 <xarick> was trying to come up with an alternative solution
22:24:18 <peter1138[d]> It would definitely not have been more concise that two Invalidate calls.
22:25:10 <truebrain> "What did you do all day?" - "Fix build systems"
22:25:24 <truebrain> tnx _glx_ for the assist etc 🙂
22:25:30 <_zephyris> peter1138[d]: Hah. A perfect example of an imperfect input svg.
22:28:09 <xarick> how do I quote code in discord
22:28:39 <xarick> anyways, I was trying something like this
22:29:31 <tabytac> use 3 ` around the text ```like this```
22:30:56 <_glx_> more complex than needed 🙂
22:31:39 <xarick> alright, time to test the pathfinder again
22:32:17 <xarick> I should perhaps correct that assert I mentioned a few hours earlier
22:32:26 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:32:43 <andythenorth> such tax payment time
22:34:27 *** goddess_ishtar has joined #openttd
22:34:27 <goddess_ishtar> are there any resources for developing patches, or is it just "crack open the OpenTTD source and go to town"?
22:34:55 <_glx_> basically get the source, do your changes 🙂
22:36:46 <goddess_ishtar> given that I don't really know C++ this is going to be *interesting*
22:37:23 <xarick> IsValidTrackdirBits does not exist! need help!
22:37:48 <dwfreed> goddess_ishtar: that's okay, nobody knows C++
22:38:11 <truebrain> goddess_ishtar: there are also livestreams and youtube movies of people coding (even for OpenTTD). Not sure how helpful that is 😄
22:40:19 <peter1138[d]> Oh of course, the svg of 731 is "32bpp" and the 1x bitmap of 731 is 8bpp. We don't bother loading 8bpp if 32bpp are present.
22:44:06 <goddess_ishtar> I want to change things regarding town generation and that isn't exposed to NewGRFs so that doesn't leave many other options
22:46:02 <peter1138[d]> Hmm, this svg grf compresses from 63KB down to 12KB. Shame we don't support runtime compressed access.
22:46:12 <goddess_ishtar> is there any recommended toolchain or is it just "gcc and text editor of choice"?
22:52:59 <xarick> ``` assert((trackdirs & ~TRACKDIR_BIT_MASK) == TRACKDIR_BIT_NONE);
22:52:59 <xarick> assert(trackdirs != TRACKDIR_BIT_NONE);```
22:52:59 <xarick> Is there already a way to do what this does?
22:54:23 <talltyler> goddess_ishtar: If you’re on Windows, Visual Studio is about as plug-and-play as it gets, in my experience anyway
22:54:53 <_jgr_> goddess_ishtar: Sticking with the editor you're most comfortable with is probably sensible
22:55:03 <peter1138[d]> cmake, clang and vs code for me.
22:55:08 <goddess_ishtar> or rather, laptop is Windows desktop is Linux
22:55:25 <peter1138[d]> A little bit of heresy, but I do not miss the days when I used to search through the code with vim.
22:55:30 <goddess_ishtar> and I'm mostly a Python dev so I'm familiar with VS Code, not any actual IDE
22:55:45 <peter1138[d]> It is basically an IDE.
22:55:59 <peter1138[d]> Just with plugins to bolt it all together.
22:56:13 <goddess_ishtar> most IDEs I've used were horrifically bloated and slow
22:57:09 <_jgr_> You can work on OpenTTD with or without an IDE
22:57:25 <peter1138[d]> Oh what have I done...
22:57:26 <_jgr_> I wouldn't worry too much up front about the tooling
22:57:35 <truebrain> peter1138[d]: very large 😛
22:57:37 <_glx_> and we test many compilers
22:58:05 <_jgr_> I use a fairly simple editor
22:58:22 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:58:25 <goddess_ishtar> _jgr_: I've vaguely heard that C++ in general is painful without an IDE, although now that I think of it nobody's ever said *why*
22:58:39 <goddess_ishtar> so it may just be false
22:58:54 <truebrain> not having a decent file-overview can be painful; but otherwise ... it is just text 😛
22:58:56 <peter1138[d]> If you're fmailiar with VS Code, just use that.
22:59:01 <truebrain> an IDE doesn't help -that- much 😛
22:59:10 <truebrain> but yeah, I use VSCode, all day, every day, for C++; it is fine
22:59:32 <_jgr_> So long as your editor has some form of grep or find in files that is enough really
23:00:45 <peter1138[d]> I think we need to add scrollbars everywhere, my 1440p monitor is not enough for 8x interface scale!
23:00:58 <truebrain> and you can always ask for any help with C++; lately this channel already feels like we are training an LLM how to code, so .. you can't do worse 😄
23:01:01 <xarick> `assert(IsValidTrackdir(FindFirstTrackdir(trackdirs)));`this should do it
23:02:47 <truebrain> that face could be generated 😛
23:03:48 <goddess_ishtar> peter1138[d]: oh no
23:06:40 <peter1138[d]> locosage: in python, how can I convert 1.5 to the nearest integer multiplier/divisor pair?
23:06:52 <xarick> it should catch TRACKDIR_BIT_NONE from now on
23:07:10 <peter1138[d]> There's probably a simple algorithm but I'm lazy 😄
23:07:26 <locosage> nearest rational isn't very defined...
23:08:09 <locosage> but if all your fractions are of say 100 you can start with x / 100 and divide both by gcd
23:08:10 <peter1138[d]> Oh, 5 seconds search...
23:08:54 <locosage> lol, yeah, or import antigravity xD
23:10:16 <peter1138[d]> Hmm, I guess I could just go with "fractions" of 100, e.g. percentages.
23:11:13 <locosage> yeah, probably better for humans anyway
23:11:33 <locosage> it's not like 12/25 or smth is very readable
23:11:56 <peter1138[d]> That's why I want to convert a decimal to a fraction.
23:13:02 <peter1138[d]> Currently I use 1 byte as multiplier, 1 byte as divisor. That way I don't store floats, and can still have precise fractions.
23:14:01 <locosage> I'd just go with fractions of 100 in one int
23:16:58 <locosage> or even of 8 to limit craziness
23:17:23 <locosage> 40 to appease both base 10 fans and base 2 xD
23:19:53 *** Tirili has quit IRC (Remote host closed the connection)
23:19:57 <locosage> ui only snaps to 1/4 fractions of zoom
23:20:15 <locosage> almost feel like other values shouldn't even be allowed
23:31:56 *** Wormnest has joined #openttd
23:42:01 *** Ttech has quit IRC (Quit: Este é o fim.)
continue to next day ⏵
