IRC logs for #openttd on OFTC at 2025-06-16
⏴ go to previous day
01:32:45 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:32:49 *** WormnestAndroid has joined #openttd
01:32:50 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:32:52 *** WormnestAndroid has joined #openttd
01:32:54 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:35:38 *** WormnestAndroid has joined #openttd
01:53:46 *** Wormnest has quit IRC (Quit: Leaving)
02:36:26 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:56:40 *** WormnestAndroid has quit IRC (Remote host closed the connection)
03:56:42 *** WormnestAndroid has joined #openttd
04:43:27 <DorpsGek> - Update: Translations from eints (by translators)
05:46:51 <truebrain> I really need to book myself some time to see why R2 uploads fail this often lately... worked perfect for months, but .. something changed
05:53:07 *** Flygon has quit IRC (Read error: Connection reset by peer)
06:09:45 <peter1138[d]> "Checking you're a human"
06:13:11 <pickpacket> truebrain: what's R2?
06:13:53 <peter1138[d]> andy probably closed the lid on the MBP.
06:13:56 <dwfreed> cloudflare's equivalent of amazon S3
06:14:20 <pickpacket> Btw I'm mainly playing on a nightly from a couple of weeks ago now and Oh. My. God. 15.0 is a huuuuuuge improvement from 14.1. Awesome work, everyone!
06:14:33 <pickpacket> peter1138[d]: typical andy
06:15:36 <dwfreed> I just realized R2 is both alphabetically and numerically 1 less than S3
06:39:52 <andythenorth> peter1138[d]: needed to sleep, the light was keeping me awake
06:43:33 <andythenorth> stupid price for a computer though
06:43:45 <andythenorth> one of my kids bought a gaming PC for £580
07:06:32 <DorpsGek> - Add: summary for week 24 of 2025 (by OpenTTD Survey)
07:06:39 <andythenorth> hmm can we run our infra on one used gaming PC?
07:11:03 *** reldred has joined #openttd
07:11:03 <reldred> just throw more docker containers at it
07:11:11 <reldred> they fix everything right
07:22:18 <andythenorth> except the problem of managing docker containers
07:22:44 <andythenorth> I assume that docker containers are compute-resource-independent?
07:23:14 <andythenorth> like the time that "inexperienced developers should use node.js serverside because it's non-blocking and therefore has no scaling limits"
07:38:08 <jfkuayue> I am always thinking if Apple website is accessible to visual impairments
07:41:35 <reldred> I mean, the text is at least actually text
07:42:09 <reldred> All the images have alt text
07:46:48 *** toktik is now known as Guest18227
07:48:49 *** Guest18227 has quit IRC (Remote host closed the connection)
07:53:10 <andythenorth> Apple usually lean into accessibility
07:53:24 <andythenorth> except when it comes to text that is low-contrast grey-on-grey
07:53:35 <andythenorth> and their approach to EU Cookie Law appears to have been yolo
07:53:50 <andythenorth> they set cookies, they don't ask, and no enforcement action has been brought against them
07:55:48 <reldred> eh not entirely, I think the EU has been going for the bigger ticket items though with Apple
07:56:24 <andythenorth> I am not a lawyer
07:56:40 <andythenorth> but the problem with a big cookie law case would be demonstrating harm
07:57:04 <andythenorth> the harm arising from using 8 KB or so of my end user telco device, is hard to quantify
08:02:12 <peter1138[d]> Are they tracking cookies or cookies necessary for operation of the site (basket state etc...)
08:04:55 <peter1138[d]> I better fire up Teams (in Chromium) 😦
08:06:16 <peter1138[d]> Excellent, it came up immediately, showed all my previous conversations... and then pops up a tiny alert that says I need to log in again.
08:07:15 <peter1138[d]> The joys of fucking "single page apps".
08:30:57 <andythenorth> peter1138[d]: Necessary cookies, comms and tracking cookies
08:31:15 <andythenorth> if you don't like them, set 'no cookies' in Safari, or ask your browser vendor how to do that
08:32:09 <andythenorth> still violates PECR
08:32:35 <andythenorth> but PECR is a lolz piece of unintended consequences
09:05:24 <peter1138[d]> Where did my coffee go...
09:52:53 *** squirejames has quit IRC (Quit: User went offline on Discord a while ago)
11:05:44 <_glx_> truebrain: Could not it be something in our workers?
11:32:32 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:32:35 *** WormnestAndroid has joined #openttd
11:39:37 <peter1138[d]> Bloody hell why can't I type these days 😦
11:54:45 *** foodliker has quit IRC (Quit: User went offline on Discord a while ago)
12:12:05 <kuhnovic> peter1138[d]: This must be the reason
12:30:36 <peter1138[d]> Urgh, silly Windows adopting ucs-2.
13:43:49 *** akimoto has joined #openttd
14:21:34 *** akimoto has quit IRC (Ping timeout: 480 seconds)
15:20:25 <peter1138[d]> Eh, I just think putting blobs of code into a commit message is weird, right?
15:20:28 *** Wormnest has joined #openttd
15:21:30 <kuhnovic> "My workflow is better, you need to accept that"
15:23:32 <talltyler> Preview action to the rescue yet again, so nice for checking simple PRs like this
15:40:00 *** gelignite has joined #openttd
16:18:31 *** felix has quit IRC (Ping timeout: 480 seconds)
16:20:46 <truebrain> at least they don't break randomly 😛
16:22:30 <truebrain> `"put: We encountered an internal connectivity issue. Please try again. (10001)"`
16:30:31 <truebrain> Scary little I can do about that, as I use a stream to read the data to write .. and that can't be rewind
16:30:51 <truebrain> Bit surprised this happens that often with R2 ..
16:31:44 <truebrain> retrying the whole upload is also tricky, as you are no longer sure everything is in a consistent state ..
16:33:01 *** Smedles has joined #openttd
16:33:05 <truebrain> (as in, you can't overwrite files, and you don't know whether R2 wrote a partial or not .. maybe it never does? I dunno ..)
16:37:21 <truebrain> deployed a small change; we will see if that does anything
16:38:36 <truebrain> it might break totally 😛
16:38:45 <truebrain> tomorrow morning we will know!
16:41:23 *** toktik is now known as Guest18254
16:41:47 *** Guest18254 has quit IRC (Remote host closed the connection)
16:43:54 <truebrain> peter1138[d]: What that commit message made me puzzle even more, is why it is in markdown syntax. Do some tools render the commit message as markdown? I know none, but now I feel I am missing something new going on 😄
17:28:18 <masteroktagon> Does anyone know where I find what is checked in order to determine if a roadvehicle can drive from one tile to another?
17:29:37 <_glx_> my first guess would be in roadveh_cmd.cpp
17:30:41 <masteroktagon> this looks right. thanks
17:33:53 <_glx_> most likely RoadVehController or IndividualRoadVehicleController
18:08:42 *** toktik is now known as Guest18260
18:18:56 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:01:17 <andythenorth> wonder if station grf spec can read the list of rated cargos for a station
19:01:45 <andythenorth> I have a local build of CHIPS which doesn't show cargo sprites waiting on platforms
19:01:55 <andythenorth> it's more relaxing to play
19:03:26 <andythenorth> but I'd like to show cargo sprites for rated cargos
19:03:38 <andythenorth> preferably by reading the badge for the cargo 😛
19:04:59 <andythenorth> eh I could show up to 4 cargos per tile, by designating 4 sprite locations to fill
19:05:20 <andythenorth> or use %4 on the tile location in the layout
19:16:53 <peter1138[d]> What is a "rated" cargo?
19:18:15 <peter1138[d]> Or do you mean you want to have it show cargo when that cargo has a rating, not when that cargo has anything waiting?
19:21:38 <_glx_> andythenorth: but that means bypass "automatic" handling of waiting cargo
19:21:53 <andythenorth> peter1138[d]: yes
19:21:59 <andythenorth> cargo waiting is....logical
19:23:34 <_glx_> if you handle drawing manually you can do as you like
19:23:54 <peter1138[d]> The algorithm is in `newgrf_station.cpp:581-604`
19:24:11 <peter1138[d]> Some stations probably already ignore this anyway.
19:24:22 <_glx_> yeah act3 + act2 with little/lot
19:24:26 <peter1138[d]> But ir would be nice not to.
19:24:53 <peter1138[d]> It's not magic, it's very simple and quite dumb.
19:25:02 <peter1138[d]> I had ideas to improve it to make it do other things.
19:25:14 <peter1138[d]> But then given newgrfs can dn do ignore it, I lost motivation.
19:25:19 <andythenorth> there is a place for 'only show cargo sprites if the station isn't working'
19:25:29 <andythenorth> but I'd like to try something else 🙂
19:25:38 <peter1138[d]> It would be nice if it was a player option.
19:25:49 <andythenorth> not a grf pitchforks debate
19:25:56 <peter1138[d]> So the station sets then behave the same and don't require special coding.
19:26:03 <andythenorth> in a multiplayer goal game, seeing cargo waiting is useful
19:26:23 <peter1138[d]> e.g. seeing different types of cargo
19:26:48 <_glx_> could show different cargo on different tile
19:26:59 <andythenorth> supply a list of 4 cargos to each tile, let the player choose the predicate
19:27:00 <peter1138[d]> One idea I had was to actually allocate the waiting cargo to specific platforms (or tiles).
19:27:36 <peter1138[d]> But if modern sets ignore the num_loading/num_loaded stuff, then there's not much point.
19:28:03 <peter1138[d]> IIRC most vehicle sets don't seem to be bother with act3 cargo types and num_loading/num_loaded these days.
19:28:24 <peter1138[d]> (Because authors don't like the rounding)
19:29:00 <peter1138[d]> Is there any reason why widget fill steps shouldn't be the same as resize steps?
19:29:23 <peter1138[d]> Main resize is for fill=1, resize=0
19:29:47 <peter1138[d]> But if resize=10, then ideally fill=10 rather than fill=1.
19:35:42 <peter1138[d]> Main *reason* is for fill=1, resize=0
19:37:05 <_glx_> ah no, must be the image buttons
19:37:31 <peter1138[d]> No, I'm revisiting #14145. And it seems I can fix all the issues by doing fill.height = resize.height.
19:37:40 <peter1138[d]> But there's a LOT of them.
19:37:57 <peter1138[d]> So now I'm wondering if it should just be default.
19:38:11 <peter1138[d]> It's very rare that we ever set the fill size.
19:38:53 <peter1138[d]> Setting fill size properly means the widget's resizes correctly on initial sizing, because that uses fill instead of resize.
19:39:44 <peter1138[d]> I believe this is mainly to handle initial sizing correctly for non-resizable widgets.
19:40:12 <peter1138[d]> But there's a whole load of widgets left over that we never bothered to set fill for, because "usually" it seems to work fine without it.
19:40:42 <_glx_> non-resizable are usually image buttons, because it would look ugly if not square
19:41:16 <peter1138[d]> Those will have fill=0 and resize=0 anyway.
19:42:00 <_glx_> in many case buttons are fixed and there a sizable panel in the row
19:42:51 <peter1138[d]> Yes, well I have to say you've completely misunderstood my question 🙂
19:43:18 <_glx_> I often misunderstand widgets 🙂
19:43:58 <_glx_> it's pure luck when it works if I touch windows
19:44:02 <peter1138[d]> All widgets have a fill step, and a resize step. Fill defines how the widget is initially sized, Resize defines how the widget is later resized.
19:44:39 <peter1138[d]> For an intentionally resizeable widget, we have always mostly just set the resize step. And it mostly works, as long as the widget is big enough to start with.
19:45:29 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:45:31 <peter1138[d]> But I did some digging and I think we should ALSO set the fill step for these widgets, so that if the widget isn't big enough to start with, the initial size is increased by the resize step, instead of by 1.
19:46:19 <peter1138[d]> Setting this manually for ALL resizeable widgets seems like 1) a lot of places to add `fill.height = resize.height` and 2) a lot of places to continue forgetting to do so.
19:46:49 <_glx_> can't be done internally at widget type level ?
19:47:00 <cmcaine> truebrain: Vim will render the commit messages as markdown. Github also uses markdown and uses the text of the commit for the PR message if there's only one commit.
19:47:00 <cmcaine> Markdown is also easy to read and understand for most progreammers at the moment.
19:47:00 <cmcaine> It's not super common for people to include code in commit messages, but it does happen in e.g. the linux kernel git commits.
19:47:00 <cmcaine> I'm not going to argue about it, tho
19:47:02 <peter1138[d]> So... is there any particular reason why we can just automatically make fill = std::max(fill, resize), in the widget code, instead of spread out everywhere, to be forgotten?
19:47:43 <cmcaine> Anyway, I have a couple of commits that add hotkey hinting now
19:47:44 <truebrain> cmcaine: GitHub doesn't render it as markdown for me, which what triggered my reaction 😄
19:47:47 <peter1138[d]> ... why we can't just ...
19:48:27 <truebrain> And vim of all tools does render it? Lol .. that is just funny 😄
19:48:33 <_glx_> oh and we have a template for PRs, so most likely the commit detailed message is ignored
19:49:07 <cmcaine> Github won't render commit messages as markdown, but it uses markdown everywhere else, including in the PR box.
19:49:13 <cmcaine> Yes, I know about the template
19:49:28 <truebrain> Anyway, I felt out of touch 😛
19:49:54 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:51:24 <cmcaine> For vim, I just mean that you can set the syntax highlighting for git commit messages to be markdown. It's easy and it suits me.
19:51:44 <cmcaine> I am now going to try not to think about this silliness for a while 😉
19:52:00 *** WormnestAndroid has joined #openttd
19:52:04 <_glx_> peter1138[d]: maybe nobody thought about that on initial implementation
19:53:05 <_glx_> highly configurable, but actually always using the same values
19:53:27 <peter1138[d]> Col, thank you for your contribution so far. There is no problem with including markdown in commit messages, I've done it myself loads of times.
19:54:01 <peter1138[d]> However, the silliness was asking for the CI to be ignored because you want to include a blob of code in a commit message. Which is not what commit messages are for.
19:55:25 <peter1138[d]> The CI checks exist for good reasons, so it is not sensible to randomly ignore them.
19:55:32 <peter1138[d]> (And I'm not even sure I can.)
19:56:42 <_glx_> I think only 3 people can
19:58:07 <peter1138[d]> _glx_: If you've ever seen a WWT_MATRIX in which the last row is the wrong size.... this is why 🙂
19:58:33 <peter1138[d]> This has affected parts of the picker window before, and affected the waypoint picker window before the new system was introduced.
19:58:48 <_glx_> if it can be automated to always have the correct value it seems better
19:58:58 <peter1138[d]> Basically I've been overhauling our UI for years, and only just noticed this is the problem.
19:59:28 <peter1138[d]> It affects the settings list in the game options window right now, but it's not a WWT_MATRIX so it's not as obvious 🙂
20:09:47 <cmcaine> This PR has the mockup I did and a screenshot of what the hints that I've been able to draw look like.
20:22:53 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
20:41:01 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:41:21 *** WormnestAndroid has joined #openttd
20:44:24 <peter1138[d]> Hmm, window reinit needs to be fixed now 😦
20:48:48 *** Wormnest has joined #openttd
21:34:19 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:46:37 *** tokai|noir has joined #openttd
21:46:37 *** ChanServ sets mode: +v tokai|noir
21:52:43 <peter1138[d]> I guess that's why it doesn't work :/
21:53:41 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:58:45 *** ahyangyi has quit IRC (Quit: User went offline on Discord a while ago)
21:59:54 <_zephyris> cmcaine: I'd be interested to see how it looks all in small font and all with drop shadow...
22:00:49 <peter1138[d]> Only the normal font has a drop shadow.
22:01:46 <peter1138[d]> While adding a drop shadow to the other font sizes is not impossible, I would considerbeyond the scope of the PR.
22:04:16 <_zephyris> Oh, didn't realise that.
22:04:39 <_zephyris> Am I imagining zoomed out town signs having a drop shadow?
22:04:50 <peter1138[d]> They draw the text twice 🙂
22:06:13 <peter1138[d]> (In fact, that is how the drop shadow is done for internally for antialiased text anyway, but changing how that is applied is a different task than adding hotkey indicators)
22:07:17 <peter1138[d]> The shadow is baked into the FS_NORMAL sprite font, so it's not just a simple on/off toggle.
22:07:46 <peter1138[d]> So it's not something I'd ask someone new to the code to try to tackle.
22:08:08 <cmcaine> I've done an outlined version too
22:08:18 <cmcaine> Looks better than the drop shadow, imo
22:09:26 <peter1138[d]> Outlines can be a pain depending on the font configuration.
22:10:35 <peter1138[d]> Not sure what that's meant to be.
22:14:01 <truebrain> 131 bytes 😄 hihihihi. You might want to give it an extension, Discord does better on that 🙂
22:15:04 <cmcaine> The image editing tool got upset.
22:15:36 <peter1138[d]> The issue with an outline is it doesn't properly fill.
22:15:39 <cmcaine> (This is just a crop of a screenshot)
22:15:54 <peter1138[d]> Same issue with the cargo icon outlines that was noted the same day.
22:16:17 <peter1138[d]> Rather, the issue with drawing an outline that way...
22:16:41 <cmcaine> peter1138[d]: What do you mean by this?
22:18:40 <cmcaine> I'm drawing the outline in a not so great way: drawing the text 4 times in black at slight offsets before I draw again in the primary colour.
22:18:57 <cmcaine> It is much more readable for me than when I was using the drop shadow, tho
22:19:13 <peter1138[d]> Yes, exactly that. Drawing it 4 times leaves gaps.
22:19:31 <peter1138[d]> You've done corners too, which leaves gaps clearly visible in all cases.
22:19:45 <peter1138[d]> With the cargo icon overlay I did sides instead of corners.
22:19:50 <peter1138[d]> But it's still not great.
22:20:11 <cmcaine> Yeah, I was gonna do it properly if it seemed better
22:20:49 <truebrain> How is F12 called on Chinese keyboards.. still F12? Or would this also get glyphs?
22:20:51 <peter1138[d]> This is exagerated, but there are gaps between the shadow and the text.
22:21:17 <peter1138[d]> For a shadow it's fine, because it's just a shadow.
22:21:27 <peter1138[d]> But for an outline, it is a problem.
22:23:09 <_zephyris> Shadows might not be the best, but they are consistent with the other graphic design - but I wouldn't worry about that for now, I suspect devil in the detail will be language/keyboard differences.
22:23:45 <truebrain> Image search later: it depends. You see both. I wonder how that works with hot keys...
22:32:02 <peter1138[d]> truebrain: remember when we added different blitters to do different things?
22:32:22 <peter1138[d]> debug. 8bpp. 32bpp. simple. optimized. anim. 40bpp. opengl...
22:33:57 <peter1138[d]> Turns out that makes it a pain to add things later :/
22:47:25 <wensimehrp> truebrain: it's still f12.
22:47:25 <wensimehrp> I use ANSI layout, here's cangjie layout
23:24:37 <peter1138[d]> Yeah, drawing the text 9 times 🙂
23:30:59 <peter1138[d]> Parse code is fragile? Surely 😄
23:31:17 <_glx_> GenerateWidget.cmake happily copied your comment, but SquirrelExport has stricter rules
23:31:46 <cmcaine> peter1138[d]: Computers is fast, and it's just a WIP for now 🙂
23:32:09 <_glx_> `//` is not expected anywhere in API
23:33:31 <jfkuayue> wensimehrp: I have been trying adapting the British layout, that @ is on the right
23:35:38 <_glx_> indeed, SquirrelExport.cmake doesn't expect that at all
23:37:25 <_glx_> `string(REGEX MATCH "([^,\t ]+)" ENUM_VALUE "${LINE}")` <-- indeed only values in the `enum` are expected
23:40:07 <_glx_> and comment "remover" doesn't handle these
23:44:35 <_glx_> BTW `SquirrelExport.cmake` just parse following our coding style
23:45:56 <cmcaine> Thanks for finding the root cause there.
continue to next day ⏵
