IRC logs for #openttd on OFTC at 2026-02-23
⏴ go to previous day
01:53:02 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
01:53:18 *** MinchinWeb[m] has joined #openttd
02:55:32 *** Wormnest has quit IRC (Quit: Leaving)
03:13:36 *** Smedles has joined #openttd
04:12:49 *** Zathras_1 has joined #openttd
04:12:52 *** Zathras_11 has joined #openttd
04:16:11 *** Zathras_4 has quit IRC (Ping timeout: 480 seconds)
04:16:16 *** Zathras_7 has quit IRC (Ping timeout: 480 seconds)
04:52:21 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:52:23 *** WormnestAndroid has joined #openttd
04:52:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
04:52:36 *** WormnestAndroid has joined #openttd
04:52:39 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
04:52:50 *** WormnestAndroid has joined #openttd
05:11:38 <DorpsGek> - Update: Translations from eints (by translators)
05:14:59 <__abigail> There are a couple of lines here that revert to non-US spelling (synchroni**s**ation, behavio**u**r)
07:21:50 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
07:22:09 *** MinchinWeb[m] has joined #openttd
07:27:39 <DorpsGek> - Add: summary for week 08 of 2026 (by OpenTTD Survey)
09:24:13 <peter1138> Darling hold my hand?
09:36:12 <LordAro> peter1138: nah that's jet2
09:38:27 *** gelignite has joined #openttd
10:15:11 <xarick> no more AI developments in the last 2 weeks :|
11:25:06 <peter1138> Hmm, pick industry to fund then pick layout?
11:39:09 *** reldred has joined #openttd
11:43:17 <peter1138> Not the dreaded picker window...?
11:46:16 <mmtunligit> pickerwindows good
11:47:13 *** locosage has joined #openttd
11:47:13 <locosage> would be hard to see what layout actually fits with a window
11:50:44 <mmtunligit> this is how i feel too
11:51:09 <__abigail> Another one to show off to recruiters
11:51:18 <mmtunligit> and then i get reviews back and poseidon himself has thrown a massive wave over
12:29:22 <andythenorth> hmm dotted tile outlines? or outline only the borders of the whole area?
12:29:33 <andythenorth> or tiles with `?` glyphs in them? or dice
12:51:21 *** toktik has quit IRC (Remote host closed the connection)
13:20:47 <peter1138> Hmm, most of the "Port" layouts are pretty large anyway.
13:22:12 <peter1138> And that's with excluding the water check tiles.
13:40:20 <andythenorth> the maximum bounding box of most FIRS industries will tend to 'large'
13:52:56 <peter1138> And that's a 10x7 or something.
13:54:32 <peter1138> Tile highlight only allows a whole rectangle, no arbitrary shapes. Hmm.
14:06:54 <peter1138> Port has a couple of 10x10 layouts though. So that's fun.
14:11:02 <andythenorth> spiral walk around the tile the player clicked, testing for buildable
14:11:57 <andythenorth> being really horrible, the GS Storybook has a button type where the player can click a tile, so the mythical FIRS GS could 'fix' industry placement, as it can also know all the layouts
14:12:13 <andythenorth> [but player would have to use the Storybook to build industries]
14:14:08 *** efessel has joined #openttd
14:14:08 <efessel> Morning/afternoon - has anyone reported any issues with desyncing with the 15.x release?
14:15:52 <efessel> Ok, I'm going to try to track down some debug logs - seems like there is a desync issue on our vanilla servers with 15. Seems pretty sporadic, the best type of bug.
14:42:51 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
14:44:34 *** MinchinWeb[m] has joined #openttd
15:37:20 *** Smedles has joined #openttd
16:00:45 *** Wormnest has joined #openttd
16:02:02 *** Flygon has quit IRC (Read error: Connection reset by peer)
17:02:29 <_glx_> hmm Vehicle::Crash() calls RandomRange(), but that could just be a easy to see side effect
17:05:53 <peter1138> Vehicle tile hash may be in a different order for different clients, right?
17:07:00 *** f_ has quit IRC (Ping timeout: 480 seconds)
17:07:10 <peter1138> FloodVehiclesOnTile seems to use it directly.
17:08:05 <peter1138> As does CheckTrainCollision.
17:25:41 <Rubidium> _glx_: could you check a Windows debug build with my savegame?
17:26:52 <_glx_> I have 2 VS sessions, one with windows, and one with wsl
17:27:02 <Rubidium> I want to first check whether it might be a compiler bug
17:28:22 <Rubidium> you can just load the game and wait like a second for the news message to pop up
17:29:29 <_glx_> pff of course it's a norev000
17:29:55 <Rubidium> doesn't matter, you don't need multiplayer for my savegame
17:31:19 <Rubidium> peter1138: I've got a situation of loading same savegame in single player with different results within about 2 seconds
17:31:50 <peter1138> Yes, vehicles moving will mean the tile hash data is different.
17:33:19 * Rubidium wonders what in the tile hash is non-deterministic in that case
17:33:53 <peter1138> I'll make a commit for you test in a second.
17:37:25 <Rubidium> I might not have been clear enough. Official Linux build and own debug build reliably get a result of 142, over about 5 attempts. Official Windows build gets reliably a result of 192. As far as I know with the same initial state, i.e. -x -c missing.cfg -g path/to/save. I wouldn't know in what manner our hash is non-deterministic in that context.
17:38:10 <peter1138> Tile hash is non-deterministic as long as the game is running.
17:38:52 <peter1138> But when loading a savegame it should be all be in the same state regardless of build.
17:38:53 <Rubidium> _glx_: interesting! The MSVC release build gets 192, linux 142
17:39:51 <_glx_> but I'm testing with master
17:40:59 <peter1138> Heh, there's a comment about the non-determinism of the tile hash, in a commit written by... Xarick.
17:43:09 <_glx_> 192 with release build (still master)
17:43:14 <Rubidium> _glx_: can you build today's nightly / g 1883bb6731? The release executable does gets 192 (like Windows release build of 15.2)
17:44:55 <Rubidium> my debug build still gets 142 as well
17:44:56 <_glx_> ok, Vehicle::Crash calls are inverted
17:45:25 <_glx_> in debug it first does the 188 people vehicle
17:45:36 <Rubidium> so I guess we can conclude that MSVC release builds are different from MSVC debug builds and GCC builds
17:45:59 <_glx_> in release it's the opposite
17:49:05 <_jgr_> It's probably the last line of CheckTrainCollision then
17:50:05 <_glx_> `return TrainCrashed(t) + TrainCrashed(coll);` is a bad idea when Random is involved
17:50:37 <Rubidium> I doubt that splitting it into two lines will help much
17:51:12 <_jgr_> TrainCrashed also does various other with path reservations, etc.
17:51:23 <_jgr_> A non-deterministic order does not seem helpful
17:52:33 <_glx_> splitting the line, I get 142 in release
17:53:20 *** gelignite has joined #openttd
17:53:42 <peter1138> It did used to be two lines.
17:53:44 <_glx_> RandomRange(188) + RandomRange(47)
17:53:57 <Rubidium> now the real question: is the random/savegame state after the call the same or different between the 192 and 142 variants?
17:55:27 <Rubidium> I just want to make sure whether this is a 'transient' desync as in "only" the news message is affected, or that the gamestate afterwards differs as well
17:55:34 <xarick> did I do something bad?
18:02:11 <_glx_> hmm TrainCrash() reserves under consist, which can trigger stations random
18:03:47 <_glx_> and TriggerStationRandomisation() has a nice Random() call
18:04:28 <_glx_> so the issue is not the number of victims, but the order of the calls
18:04:55 <_glx_> if trains in station is crashed before or after train not in station
18:09:26 <xarick> I saw a 'sort' somewhere
18:09:34 <xarick> what about stable_sort
18:23:50 <_glx_> I think with the test savegame only the number of victims is different because it's using default stations, but a newgrf station could get a different animation state via the triggers
18:25:18 <xarick> isn't there an InteractiveRandom?
18:28:45 <xarick> line industry_gui.cpp:682 seems suspicious?
18:30:22 <_glx_> no it uses InteractiveRandom because it's the correct use
18:32:35 <xarick> almost2.sav, im testing it i get 142 vs 192 too
18:32:50 <xarick> was it supposed to desync?, not getting a desync error
18:33:50 *** michi_cc[d] has joined #openttd
18:33:50 <michi_cc[d]> Well, execution order between sequence points is unspecified, so the compiler changing the order of function calls around is fully standard.
18:56:08 <xarick> i tested a msvc clang build
18:58:51 <xarick> yay, clang builds in under 100 seconds
19:11:47 *** goddess_ishtar has joined #openttd
19:11:47 <goddess_ishtar> hrm, I wonder - would an autosort feature for the active NewGRF list be useful?
19:14:19 *** coobies has joined #openttd
19:14:19 <coobies> Seems like it could be dangerous because the load order is important
19:14:39 <goddess_ishtar> load order does matter, but it also tends to follow recognizable patterns - your infrastructure GRFs are probably going before your tracktypes - in a way which is entirely player-managed and thus prone to human error and unwieldiness
19:15:01 <goddess_ishtar> not tracktypes
19:15:04 <goddess_ishtar> you get what I mean
19:15:40 <goddess_ishtar> but yeah, it'd be a separate button that the user would have to consciously invoke for that reason
19:15:43 <goddess_ishtar> too many corner cases
19:16:55 <goddess_ishtar> so the sorter would use Bananas tagging data or whatever to try and categorize grfs, and then sort them based on that
19:18:00 <goddess_ishtar> which is likely to produce something broadly correct, which the user can then fine-tune if necessary
19:18:57 <goddess_ishtar> people already do this with the NML fake headers, they just suck because they're inherently jank
19:19:33 <goddess_ishtar> (and they rely on you, the user, to make sure that you've put the right GRF under the right heading)
19:19:57 <goddess_ishtar> (we should eliminate ways for the user to shoot themselves in the foot whenever possible)
19:28:33 <peter1138> Hmm, so I guess the out-of-order tile hash is probably not a problem, but still might be worth investigating?
19:33:37 <Rubidium> peter1138: in this case it's probably not the problem, but I can imagine (especially) the flooding case to be affected when there are multiple vehicles on the same tile.
19:36:11 <xarick> flood a depot with vehicles inside
20:49:46 *** WormnestAndroid has quit IRC (Remote host closed the connection)
20:49:48 *** WormnestAndroid has joined #openttd
21:23:23 <Wolf01> By the way... topic is old
21:23:28 <andythenorth> should Horse include powered brake vans (so they can lead the train?)
21:24:02 <andythenorth> @NeddyK does it in Sunshine Trains
21:24:54 <andythenorth> maybe it's one feature too far :P
21:46:02 <andythenorth> grf lolz for something that would be better done in the client :)
21:52:15 <andythenorth> emperorjake ^ if I add one of those to Horse, any thoughts? 👀
21:55:02 <andythenorth> hmm what speed to give it though :P
22:00:33 <mmtunligit> i mean if its just there to be a dummy engine that doesnt actually do anything besides have the train face a certain way, presumably youd want to set it as the max speed of any locos in the set so that other cars can drag the speed back down to whatever the currect era is
22:02:04 <andythenorth> I think maybe it's silly, and people who really want it can use Jake's existing grf
22:31:10 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:59:12 <DorpsGek> peter1138: 15.1 | Website: *.openttd.org (source: github, translator: translator, server list: servers, wiki: wiki) | Don't ask to ask, just ask | 'Latest' is not a valid version, 'Most recent' neither | English only
22:59:16 <DorpsGek> peter1138: topic [<channel>]
22:59:22 <peter1138> Can't remember it :/
23:06:03 <xarick> oh, nevermind, I see the problem
23:06:21 <xarick> Zeppeliner cleared vs zeppeliner crashed, yeah that's a bug in transai
23:17:42 <xarick> oh, fanioz has a version from 2025
23:17:52 <xarick> but bananas still on 2019
23:45:47 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
23:49:41 *** MinchinWeb[m] has joined #openttd
23:56:24 <emperorjake> andythenorth: I wouldn't be opposed, bit niche but can definitely be useful 🙂
continue to next day ⏵
