IRC logs for #openttd on OFTC at 2024-12-29
⏴ go to previous day
01:32:19 *** nielsm has quit IRC (Ping timeout: 480 seconds)
02:04:34 *** Wormnest has quit IRC (Quit: Leaving)
03:20:23 *** gnu_jj_ has joined #openttd
03:23:56 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:27:53 *** godbed_ has joined #openttd
03:31:18 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:31:18 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:46 <DorpsGek> - Update: Translations from eints (by translators)
05:18:24 *** APTX has quit IRC (Ping timeout: 480 seconds)
07:56:56 *** godbed is now known as debdog
09:02:12 *** aperezdc has quit IRC (Remote host closed the connection)
09:09:40 <truebrain> So far we always said: Dockerfiles is for others to arrange, there is too much variation and choices to upstream only one of them
09:10:53 <truebrain> Given two devs left comments that do not suggest that, are we going to upstream one now? (Open question; I am not fuzzed either way)
09:40:16 <peter1138> Hmm, I can't remember how to test a script's compatibility level.
09:40:49 *** aperezdc has joined #openttd
09:51:18 <truebrain> I forgot I should add comments to PRs, not only on Discord 😛
09:52:56 <peter1138> Urgh, YouTube, stop it.
09:54:18 <peter1138> The preview misfeature that skips the part of the video you previewed (with no audio) when you go to play it. Urgh.
09:54:43 <peter1138> "Previewed" meaning "left the mouse cursor over it for a few seconds"
10:04:47 <truebrain> lol, really? That is just silly
10:56:09 <LordAro> seemed mildly AI generated
10:56:40 <LordAro> i have no idea why it would've decided to build zlib
11:00:07 <truebrain> or why not pick generic-linux, and take it from there 🙂
11:00:39 <truebrain> lot of trial&error, I am sure 🙂
11:02:28 <peter1138> I didn't really look before.
11:18:32 <andythenorth> hmm is this an improvement?
11:18:35 <peter1138> Oh of course, the essential step of... building opengfx.
11:20:38 <andythenorth> pff, some aren't just colours 😐
11:34:09 *** wubbianalt has joined #openttd
11:34:09 <wubbianalt> I’m looking for help creating two French railway signals in OpenTTD's 8bpp style for a project. I’d like the signals to look accurate and clean—just like real French signals but adapted to fit OpenTTD’s pixel art style
11:36:23 *** wensimehrp has joined #openttd
11:36:23 <wensimehrp> wubbianalt: Better off posting in Discord channel #add-on-development
11:59:50 <johnfranklin> Finally good weather
12:12:30 <_glx_> Yeah my comments on docker PR didn't imply we would accept it, I was just trying to help
12:12:53 <xarick> hyper-v no longer boots 😦
12:13:19 <_glx_> Why using hyper-v directly ?
12:17:27 <Rubidium> might it be a billionth of a promille faster?
13:09:14 *** Smedles has joined #openttd
13:11:35 <xarick> screw it, I'm uninstalling it
13:16:56 <andythenorth> see also, why does Windows deactivate after updates?
13:17:28 <andythenorth> it's an OEM edition on a gaming PC, and child appears to not have the OEM license
13:58:53 *** kuka_lie has joined #openttd
14:00:37 <andythenorth> bluetooth antenna
14:01:03 <andythenorth> there is bluetooth on board, but it has an external antenna which can screw int
14:02:14 <andythenorth> but he said it deactivated after an OS update so eh 😛
14:11:13 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
14:58:54 <kuka_lie> i want to make rss/atom feed to my website and i want to know what software you use for your atom feed
15:03:55 <_glx_> kuka_lie: `jekyll-feed`
15:22:22 *** Wormnest has joined #openttd
16:23:16 <pickpacket> Attention all: I just want you all to know how satisfied I am about finally finishing up a GS I started with during the summer :D
16:24:58 <pickpacket> And also thanks again to whoever it was that added victim count to the vehicle crash GS event :)
16:27:02 <pickpacket> I have a question: In my own fork I've added an event for when a company is renamed. It's useful for keeping the company listing in my log book up to date. If I push that PR today and everything looks good, is there a chance it could be shipped in 15.0 or has that ship sailed? It's a tiny change that takes about 1 minute to code review at most :)
16:30:57 <xarick> > [GenerateWorld] 70218456 us
16:30:57 <xarick> > [GenerateWorld] 70048233 us
16:30:57 <xarick> > [GenerateWorld] 69409203 us
16:30:58 <xarick> > Rubidium's TileOffset + fixes + changes / Release
16:30:58 <xarick> > [GenerateWorld] 71445353 us
16:31:00 <xarick> > [GenerateWorld] 71665492 us
16:31:00 <xarick> > [GenerateWorld] 71282446 us
16:31:58 <_glx_> 15 is still in beta, so no feature freeze
16:34:18 <peter1138> Given an HSQUIRRELVM, can I determine the running script's API version?
16:41:31 <_glx_> instance has versionAPI (protected)
16:42:45 <peter1138> Yeah, I don't know to get to it.
16:45:29 <_glx_> foreign pointer in vm contains instance->engine and engine only knows API name (AI or GS), not the version
16:47:47 <_glx_> seeing the current use, I guess we could move version from instance to engine
16:48:50 <peter1138> I'm not sure I should be using it mind you.
16:49:11 <peter1138> I'm looking at the "pad parameters to 20 to make old badly behaved scripts happy"
16:49:38 <xarick> so... rubidium's performant code... is slow
16:49:50 <peter1138> Which 1) doesn't really make sense for well behaved scripts, 2) doesn't make much sense when FormatString() itself (will) no longer do that.
16:50:00 <xarick> or my added changes that make it slow
16:50:16 <peter1138> Oh, and 3) the parameter limit is removed.
16:50:43 <peter1138> So I was wondering if pad-to-20 could be turned off for "v15" scripts or something.
17:02:53 <_glx_> hmm actually the dummy fill is only used during validation, if string is correct none of the dummy values will be in encoded string
17:05:14 <_glx_> it's only there to not trigger "Not enough parameters" errors for silly scripts
17:19:29 <peter1138> Yes, exactly, it's for legacy scripts, but because there's no version check it's done for all scripts.
17:20:34 <peter1138> I think it's better for a script targetting v15 to fail than to pretend the validation passes because it used to pass in an older version.
17:22:29 <_glx_> another option could be to put something in compat scripts
17:27:06 <_glx_> api version being a string, it's a pain to check
17:32:50 <Rubidium> xarick: have you considered that all the 'fixes' to make it possible to assert on overflowing TileOffsets will have a significant effect on performance? Because as far as I am aware doing the fixes for the overflow-check triggering requires changes to the calling code, so it accounts for overflows itself... meaning you moved a lot of 'Debug-runtime' stuff into 'Release' checks. Furthermore, did you
17:32:56 <Rubidium> consider that Release does not disable assertions, so... where previously only TileAdd was checked now any case where the operator+ variant is used gets slowed down by the 'prevent overflow checks'.
17:34:42 <xarick> i found a bug in my code, I was missing an operator +=, will check again
17:35:10 <xarick> in my added code for your branch
17:36:20 <xarick> I have Release with assertions disabled, I made a custom ... config file thingy and manually disabled it
17:36:27 <Rubidium> xarick: and given you likely checked with asserts enabled, you are not getting into the 'performant' territory anyway. After all, 'we' just added checks to many more cases against overflows
17:37:35 <_glx_> peter1138: I think it should be possible to remove ScriptText::SCRIPT_TEXT_MAX_PARAMETERS from cpp, then define GSText.SCRIPT_TEXT_MAX_PARAMETERS in compat scripts
17:38:01 <_glx_> and add a mechanism to check existence of the constant
17:43:52 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:45:58 <xarick> [2024-12-29 17:43:08] dbg: [misc:0] [GenerateWorld, 1] 71139073 us [avg: 71139073.0 us]
17:45:58 <xarick> [2024-12-29 17:44:28] dbg: [misc:0] [GenerateWorld, 1] 70944965 us [avg: 70944965.0 us]
17:45:58 <xarick> [2024-12-29 17:45:41] dbg: [misc:0] [GenerateWorld, 1] 70179198 us [avg: 70179198.0 us]
17:50:18 <xarick> I'm wondering if I could make TileOffset also behave like TileOffsetC and get rid of TileOffsetC entirely
17:51:11 <xarick> but this would undo the performant path :/
17:52:21 <xarick> my current strategy is, keep both TileOffset and TileOffsetC
17:53:02 <xarick> tile + TileOffsetByXXX if you need the performant path
17:53:31 <xarick> tile + XXX if you need to check boundaries
17:53:38 <xarick> XXX being dir, diagdir, axis
17:53:58 <xarick> if it's off the map it returns INVALID_TILE
17:54:27 <xarick> but on the performant path, without asserts, it just passes
17:54:33 <xarick> with asserts, it asserts
18:29:01 <_glx_> oh minimap is broken it seems, at least "map contours", and it crashes for me in debug build
18:46:45 *** tokai|noir has joined #openttd
18:46:45 *** ChanServ sets mode: +v tokai|noir
18:53:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:54:44 <_glx_> but previous version have weird colours
19:01:37 <_glx_> oh weird coulours are in 14.1 too
19:02:08 <peter1138> Isn't "weird colours" just a setting for colour blindness?
19:04:20 <_glx_> no real diff when changing the setting, and it only lists 0m in the legend
19:04:34 <peter1138> Hmm, what compiler? Because this works fine for me.
19:04:52 <_glx_> I'll check with gcc later
19:05:20 <_glx_> oh and 14.1 is the steam version
19:05:24 <peter1138> My MinGW build works fine.
19:07:30 *** gelignite has joined #openttd
19:53:11 *** Smedles has joined #openttd
20:24:35 <_glx_> even 13.4 (and some are blinking)
20:26:26 <Rubidium> _glx_: does the same happen in the actual release build? So, the one that the github runner made many months ago
20:27:38 <Rubidium> oh dear, so we can't blame some recent compiler change ;(
20:27:46 <_glx_> should be something local to me as 12.2 is affected too
20:28:12 <peter1139> I never experienced that on Windows 11.
20:28:30 <peter1139> But that was over a year ago I last ran it.
20:44:58 <_jgr_> Is your map_height_limit setting set to something strange?
20:48:05 <peter1138> 15.0-beta1 is fine for me on Windows.
20:48:28 <_glx_> oh let me check the map_height_limit
20:51:01 <_glx_> ah it's supposed to be clamped between 15 and 255
20:51:52 <_glx_> well 0 seems to be (auto)
20:52:23 <_jgr_> If the value if 0 during a running game that would be consistent with getting non-deterministic colours like that
20:55:46 <_glx_> if set to 15 everything is fine
21:00:03 <_glx_> so it is map_height_limit
21:07:01 <_jgr_> Which path are you using to make these maps?
21:08:28 <_glx_> and GenerateWorld() sets the value to 30
21:09:34 *** gelignite has quit IRC (Remote host closed the connection)
21:09:42 *** gelignite has joined #openttd
21:09:49 <_glx_> but it's somehow reset after generation
21:10:56 <peter1138> Could be some other setting that influences height?
21:16:06 <_glx_> MakeNewgameSettingsLive()
21:16:55 <_glx_> oh wait I was still in openttd startup
21:19:50 <_glx_> ok when I click on Generate, MakeNewgameSettingsLive() sets it to 0, GenerateWorld() sets it to 30, MakeNewgameSettingsLive() sets it to 0
21:22:38 <_glx_> it was `newgame` in game_start.scr
21:23:27 <_glx_> yeah an old text, didn't imagine the side effect
21:23:32 <peter1138> I don't know why you'd do that, but also I don't think it should break things in this way.
21:32:41 <xarick> how do i detect a struct member is not initialized?
21:34:01 <_glx_> compiler may warn when you use a not yet initialized member
21:41:36 *** ahyangyi has joined #openttd
21:41:36 <ahyangyi> xarick: Compiling the project with Address Sanitizer might help.
21:42:01 <_glx_> it's problematic on windows
21:42:35 <ahyangyi> Yeah, but once someone finds the bug, every platform can benefit.
21:42:41 <ahyangyi> It's a debugging tool.
21:43:02 <_glx_> everytime I tried in visual studio it couldn't even start openttd
21:50:02 <_glx_> and if we remove SCRIPT_TEXT_MAX_PARAMETERS the compat script change will be needed anyway (old script may use GSText.SCRIPT_TEXT_MAX_PARAMETERS)
21:51:59 <peter1138> Oh is that a thing too?
22:01:25 <_glx_> yeah if you remove something from the API you need to readd an equivalent for older stuff
22:01:44 <peter1138> I mean I didn't expect it to be visible in the API 🙂
22:03:13 <_glx_> my test removes it from the API while keeping it internally because I didn't want to rewrite everything
22:10:06 <_glx_> anyway it seems quite easy to detect old API version in this specific case
22:14:48 <xarick> I'm turning TileOffset into a frankenstein struct
22:16:10 <_glx_> you probably overthinking and complicating for no actual benefit
22:24:13 <peter1139> _glx_, what does the code in the ScriptText constructor do?
22:25:13 <_glx_> just tests for GSText.SCRIPT_TEXT_MAX_PARAMETERS existence
22:25:38 <pickpacket> oh shit. I made a PR of my change months ago 😂 Totally forgot. I'll address the review comments now
22:25:43 <peter1139> Hmm, so we need to do that every time a GSText is made.
22:26:19 <_glx_> I did test here because it was near
22:34:54 *** kuka_lie has quit IRC (Remote host closed the connection)
22:35:18 <_glx_> but it should be doable in ScriptText::GetEncodedText() with use of ScriptObject::GetActiveInstance()
22:36:32 <_glx_> oh or even _FillParamList, let's test
22:36:52 <peter1139> I don't know how to get the value.
22:39:48 <peter1139> _FillParamList doesn't have access to the vm either.
22:43:57 <_glx_> yeah I can access the instance via ScriptObject::GetActiveInstance(), but engine is protected
22:48:41 <_glx_> to get the value, insert ```cpp
22:48:41 <_glx_> sq_getinteger(vm, -1, &value);
22:48:41 <_glx_> ``` between second if and sq_pop
22:57:54 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:02:20 <xarick> I'm unsure about this last commit
23:02:50 <xarick> but I wanna migrate TileOffsetC to TileOffset somehow
23:04:39 <xarick> the use of NOT_REACHED() doesn't inspire confidence
23:14:01 <_glx_> peter1138: updated the test case
23:17:52 *** oftc is now known as Guest4479
23:18:20 <_glx_> still not the best place I think
23:20:38 *** Westie has quit IRC (Ping timeout: 480 seconds)
23:26:43 <peter1138> Without compatibility
23:27:29 <andythenorth> hmm, Horse is so slow
23:27:52 <andythenorth> what if OpenTTD handled the random vehicle crap 😛
23:28:01 <andythenorth> and the variants that are just colour remaps 😛
23:28:12 <andythenorth> compile time improved by 9000%
23:29:34 <_glx_> oh that's a very nasty GS doing weird thing with string args 🙂
23:30:06 <talltyler> Vehicle sets a bitmask of company colours to be chosen randomly for each wagon?
23:32:59 <peter1138> Iron Horse uses non-company colour remaps.
23:33:12 <peter1138> _glx_: yes, it's broken, but I need it to be broken to test this 🙂
23:33:33 <peter1138> I'm specifically using the old version for this reason.
23:33:53 <peter1138> So with my current changes there is no parameter limit for GSText any more.
23:34:10 <_glx_> authors will be happy with that
23:38:38 <_glx_> oh I know where to put the detection, and set legacy mode
23:38:51 <peter1138> game_text.cpp looks good to me.
23:39:10 <peter1138> But what did you have in mind?
23:41:23 <_glx_> detection in RegisterGameTranslation() and setting a static optional in ScriptText
continue to next day ⏵
