IRC logs for #openttd on OFTC at 2024-04-17
⏴ go to previous day
00:27:27 *** Wormnest has joined #openttd
01:37:03 *** bertvvvs has quit IRC (Quit: You have a nice day.)
01:37:17 *** Wormnest has quit IRC (Quit: Leaving)
01:50:35 <peter1138> So, er, I'd already been working on that.
01:53:04 <_jgr_> Ah well, I can rebase it on top of yours when that's merged
01:57:54 <peter1138> I did it the operator<=> way so that future changes to the cache structure won't need to be reflected in the cache check code.
02:01:00 <peter1138> Oh yes, because I've been trying to work out if the used_bitmap can go out of sync.
02:40:18 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:46:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:03 <DorpsGek> - Update: Translations from eints (by translators)
06:17:31 <truebrain> To document my experiments of last night 🙂
06:29:31 <locosage> vehs reorder is normal for every desync because of random effects
07:00:49 *** HerzogDeXtEr has joined #openttd
07:17:33 *** SigHunter has joined #openttd
07:20:26 <kuhnovic> That sure sounds like a fun desync...
07:23:09 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic closed pull request #12232: Fix #12228, #12231: Don't restrict path when checking ship reverse on first attempt, Pick a random trackdir if no path is found when force reversing https://github.com/OpenTTD/OpenTTD/pull/12232
07:49:27 <truebrain> kuhnovic: Undeterministic behavior is always fun for a game that should be deterministic, yes 😄
07:49:45 <truebrain> I am especially annoyed that running the same game twice gives different results
07:49:55 <truebrain> I am still hoping I am doing something wrong here
08:09:41 <pickpacket> truebrain: how can you tell that you're running the exact same game?
08:12:21 <peter1138> Visualisation of free vehicle indices...
08:12:40 <peter1138> (Not particularly useful but vaguely interesting)
08:13:50 <pickpacket> Btw, the opt in for the survey, is that among the usual settings? I've forgotten to check
08:14:21 <peter1138> It's under the main Game Options, first tab.
08:26:03 <peter1138> Oh, so the Emscripten build doesn't like <=> for std::array :S
08:26:39 <_glx_> No, it doesn't like the `= default`
08:27:34 <_glx_> And GCC yell about a memset
08:29:02 <peter1138> Yeah, because it's no longer a trivial type. Pom-te-pom.
08:34:44 <peter1138> That one is an easy fix though.
08:37:18 <peter1138> It's not the `= default` it doesn't like, it's the `= default` when the struct contains a `std::array<>`
08:38:54 <_glx_> yeah, because default is implicitely deleted
08:40:56 <peter1138> Cause and effect... the `= default` I defined is implicitly deleted, because std::array is missing operator<=>.
08:42:20 <peter1138> I conclude that because other operator<=> I defaulted do not get deleted, and those structs do not have std::array<>s in them.
08:45:04 <peter1138> And other platforms do. Only Emscripten is barfing.
08:46:39 <peter1138> It tries matching a few alternatives with different types which don't work of course.
08:52:59 <peter1138> Anyway, adding `for (size_t i = 0; i < index; i++) assert(this->data[i] != nullptr);` to `::GetNew(size_t size)` at pool_func.hpp:145 should confirm if the index found by used_bitmap correctly matches the first free index in the pool.
08:53:22 <peter1138> Brute force and might slow things a bit of course.
08:54:22 <_glx_> could be a too old emscripten image
08:54:46 <peter1138> It that never triggers it would suggest that indices are different because something actually exists when it shouldn't, rather than a fault in the bitmap system.
09:08:19 <_glx_> maybe enabling RANDOM_DEBUG
09:09:27 <peter1138> Yeah, given that diesel smoke and electric sparks are random, if random goes out of sync that would result in vehicle indices being different.
09:18:39 <peter1138> talltyler: I think I need an option to slow down town growth more, the existing only has slow, normal, fast and very fast. With the new stuff I seem to want slow, slower, slowerer, sloth-like, glacial, government-red-tape...
09:49:48 *** quantom2 has quit IRC (Quit: User went offline on Discord a while ago)
10:10:43 <peter1138> Hah, GB(x, 0, 64) does not work 😄
10:17:55 <peter1138> Oh of course it returns uint.
10:22:29 <_jgr_> That one has caught me out before 😛
10:42:34 <peter1138> Mildly interesting watching the used bitmap move with the old title save.
10:43:26 <peter1138> IIRC effect vehicles used to have a reserved range of IDs (for performance I assume...) so there is a gap, until modern OTTD replaces them.
10:47:09 <peter1138> Here's one with a gap 🙂
10:58:59 *** bertvvvs has joined #openttd
11:28:28 <peter1138> andythenorth: Kinda no, I don't want to control town growth individually, just tweak the overall rate.
11:28:47 <peter1138> Which there is already a setting for, but the range of it isn't enough.
11:33:20 <locosage> that's pretty common with openttd settings :p
11:35:50 <locosage> just separate effects :p
11:36:17 <peter1138> Yes, make everything more complex for very little gain.
11:39:01 <peter1138> Xarick's 70k ships does not fit 😄
12:00:44 *** marchnex has joined #openttd
12:34:18 *** keikoz has quit IRC (Ping timeout: 480 seconds)
12:35:10 <talltyler> peter1138: I use GS for this, but yeah it could use a custom option. The town growth code is so strange though…
12:36:13 <_glx_> ok it's annoying, `.\openttd.exe -D -ddesync=3 -g 'T:\dump_cmds\dmp_cmds_d601a577_000af5c0.sav'` can fail or not fail
12:36:17 <peter1138> We the option, we just need to extend it 🙂
12:38:56 <_glx_> and RANDOM_DEBUG outputs nothing because ` if (_networking && (!_network_server || (NetworkClientSocket::IsValidID(0) && NetworkClientSocket::Get(0)->status != NetworkClientSocket::STATUS_INACTIVE))) {` always false
12:39:01 <peter1138> Hmm, IsSavegameVersionBeforeOrAt() seems to just be a way to avoid savegame bumps. The SLV version is unrelated to the what happens if the condition matches 🙂
12:39:29 *** marchnex has quit IRC (Remote host closed the connection)
12:39:35 <peter1138> Took me a while to figure out I had to trim the commands.log before it would process it for some reason.
12:40:00 <_glx_> oh the commands.log part was fine for me
12:40:15 <peter1138> I guess I thought it would match the sync numbers? Or maybe it's just broken for me.
12:40:43 *** bertvvvs has left #openttd (You have a nice day.)
12:40:56 <_glx_> I don't understand how RANDOM_DEBUG is supposed to work
12:41:30 <_glx_> oh it needs a client connected I guess
12:43:14 <_glx_> let's add another temporary code change
12:46:43 *** marchnex has joined #openttd
12:58:53 *** marchnex has quit IRC (Ping timeout: 480 seconds)
13:02:47 <truebrain> Was about to say, RANDOM_DEBUG is for something else 🙂
13:02:57 <truebrain> It just sends the seeds more often to clients 🙂
13:04:41 <_glx_> that's the first diff, and there are many more
13:07:58 <peter1138> Those calls have a ton of dependencies.
13:08:23 <peter1138> e.g. should a train be stopping at a station...
13:10:19 <_glx_> and if I compare the output for 2 non desync run they are identical
13:10:38 <peter1138> This would cause the vehicle indices to be different, but that doesn't mean that they are not already different.
13:11:18 <peter1138> So it could be caused by, of the cause of... 😮
13:11:35 <peter1138> Eh, not cause of, but leading on to.
13:12:30 <_glx_> and if I compare 2 desync runs they also are identical
13:13:44 <_glx_> the annoying part is I always use the same savegame and the same commands.log and sometimes it detects a desync, sometimes it doesn't
13:14:57 <peter1138> Something uninitialised?
13:16:03 <peter1138> But also TB was seeing it was not always happening, so that matches.
13:16:04 <_glx_> so something happens between 00af5c0 and 000af5cc which cause deviation
13:18:51 <peter1138> Create a savegame each tick and compare 😉
13:19:08 <peter1138> And then when you find the tick, create a a savegame for each event in that tick, hehe
13:21:00 <_glx_> [2024-04-16 19:37:30] cmd: 000af5c0; 01; 00; 0000001f; 00001006; E5971F000F0001FF55000000 (CmdBuildVehicle)
13:21:00 <_glx_> [2024-04-16 19:37:35] cmd: 000af5c1; 46; 00; 00000020; 0000100e; 980D0000000155000000 (CmdSellVehicle)
13:21:00 <_glx_> [2024-04-16 19:37:36] cmd: 000af5c2; 27; 00; 0000001f; 00001006; E5971F000F0001FF55000000 (CmdBuildVehicle)
13:21:00 <_glx_> [2024-04-16 19:37:49] cmd: 000af5c8; 11; 0a; 00000074; 00000000; 9055120000 (CmdDepotSellAllVehicles)
13:21:02 <_glx_> [2024-04-16 19:37:52] cmd: 000af5c9; 1e; 0a; 00000070; 00001006; 90551200670B000000 (CmdCloneVehicle)
13:21:32 <_glx_> which should affect vehicle pool and possibly "move" effects
13:23:12 <_glx_> and the desync is detected only when there's a mismatch in total number of random calls during a tick
13:23:55 <_glx_> so out of order calls pass, but they are already wrong
13:24:12 <peter1138> Can you add debug for each of those calls that logs what index was used/freed? That could help narrow down the Event.
13:24:55 <peter1138> Have to then compare desync vs non-desync then.
13:49:38 <peter1138> Selling a vehicle with a different ID, so the problem has already occured.
13:50:34 <_glx_> it's between 2 CmdLevelLand and there's no other command
13:51:30 <locosage> isn't 12509 a possible desync?
13:52:07 <kale91> hm, a more rudimentary attempt then usual
13:54:19 <_glx_> hmm and my logging does not check DC_EXEC
13:54:38 <peter1138> "it will sort based on the pointer value." sounds like a bad idea if it affects game state, yes.
13:55:00 <peter1138> And of course is deterministic.
13:56:01 <_glx_> ok so I imagine those unlogged commands are autorenew/autoreplace
13:56:23 <peter1138> The index would not be different if it was coming from a client.
13:56:27 <peter1138> (And it would be logged...)
13:57:22 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdBuildVehicle -> 1880
13:57:22 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdSellVehicle -> 2313
13:57:22 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdSellVehicle -> 1880
13:57:22 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdBuildVehicle -> 1880
13:57:22 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdSellVehicle -> 2313
13:57:24 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdSellVehicle -> 1880
13:57:24 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdBuildVehicle -> 1880
13:57:26 <_glx_> [2024-04-17 15:31:52] dbg: [misc:0] CmdSellVehicle -> 2313
13:57:31 <_glx_> first batch, same on both
13:58:42 <_glx_> not showing cmd flag is not helpful
13:59:03 <_glx_> let's improve the logging
14:12:16 *** keikoz has quit IRC (Ping timeout: 480 seconds)
14:23:43 <peter1138> Hmm, std::source_location::current() is giving me the locatiojn of the call...
14:27:57 <peter1138> I didn't write clearly enough 🙂
14:28:42 <peter1138> It's giving me the location of the place where I added `const std::source_location location = std::source_location::current()` as a default constructor parameter.
14:31:35 <peter1138> Which is kind of logical but with, say, WindowDesc it uses the source location of where a WindowDesc is, instead of where the WindowDesc constructor is.
14:37:09 <peter1138> Anyway, this Timer thing in #12509 could be the cause of this.
14:39:19 <peter1138> There is a priority defined for some things.
14:48:41 <truebrain> _jgr_: : how are you finding these kind of issues?
14:49:17 <_jgr_> Just reading the source, the timer stuff is high risk so it seemed a good place to start looking
14:51:59 <_jgr_> Issue 12506 is form the JGR serve rlogs
14:52:12 <truebrain> Lolz; educated guesses ftw 😛
14:56:32 <_glx_> at least my logs seem to somehow match what truebrain could see in the JSON, vehicles "move" in the pool
14:56:48 <locosage> btw, would be nice to have some kind of mark on desync issues on gh
14:57:14 <locosage> just so they can be found easily
15:00:11 *** keikoz has quit IRC (Ping timeout: 480 seconds)
15:04:58 <locosage> vehicles pools shuffle all the time on desyncs
15:05:18 <locosage> wasted a lot of time looking for vehicle bugs back when I was still comparing saves for desyncs
15:07:30 <_glx_> I'm just running the same save and commands multiple times
15:08:11 <locosage> yeah, but after random states desyncs vehicle pool shuffles pretty fast
15:08:34 <locosage> faster than game detects a desync at least xD
15:09:38 <_glx_> and I get 2 different outputs visible after 8 economy days
15:10:54 <_glx_> but the desync happens after 62 economy days
15:19:18 <peter1138> `VATRegisterationNumber`
15:19:23 <peter1138> Something tells me that isn't right...
15:34:33 <merni> No, your previous installation should be all right
15:34:46 <merni> That dropdown is disabled in game because you can't change soundsets in game
15:35:19 <merni> (as you can read in the tooltip)
15:35:20 <merni> Earlier the dropdown was enabled but the individual options were disabled
15:36:22 *** Wormnest has joined #openttd
15:44:35 *** gelignite has joined #openttd
15:44:58 <pickpacket> hm. I wonder why I don't get any sound
15:45:10 <locosage> c++ is so obnoxious sometimes
15:45:17 <locosage> how the heck do I debug static_assert?
15:45:37 <peter1138> You can't, it's compile-time.
15:46:07 <locosage> yeah, but I've no idea why it fails
15:47:17 <peter1138> I'm going to guess with "because the condition is not met"
15:47:49 <merni> you could insert a print statement before the assert :P
15:48:17 <peter1138> Not with a static_assert.
15:48:19 <locosage> that ain't helping, it's in the middle of macro and constexpr pile
15:48:49 <peter1138> If it's failing to compile rather than failing the condition, then some part of it is not constexpr.
15:49:40 <locosage> it's failing condition, but I want to see the values it's checking at that point
15:50:19 <merni> just convert the static asser to a normal assert or a print?
15:50:31 <peter1138> Maybe you need a better environment...
15:50:42 <merni> what environment is that
15:51:04 <merni> truebrain: well, duh :)
15:51:40 <_jgr_> You could just temporarily remove the static_assert, such that you get a longer error message somewhere else
15:53:03 <peter1138> Macros are basically "not C++" anyway. So complain about macros instead. I know I do 🙂
15:53:29 <_jgr_> You could add an expression like: `char (*__dummy)[sizeof(static_cast<base *>(b)->variable))] = 1;` which would insert the value into the error message
15:53:46 <peter1138> Anyway, that should at least tell you which line is failing.
15:54:04 <peter1138> But the assert just means something is the wrong size.
15:56:01 <locosage> yeah, and I already checked all the sizes
15:57:39 <locosage> _jgr_: problem is that it shows for all uses of that macro, not just the one failing assert
15:58:32 <locosage> hm... maybe I can add if constexpr...
16:02:24 <_jgr_> Which compiler are you using? gcc at least ought to give you the lines it's expanded from
16:03:31 <peter1138> You also need a better environment still 🙂
16:03:46 <locosage> I know where it expands from
16:03:57 <peter1138> Excellent. Then you know which line has the wrong size.
16:04:09 <locosage> but it has the right size afaict
16:04:15 <peter1138> Clearly it does not.
16:04:30 <locosage> yes, and I'm trying to figure why not
16:05:20 <peter1138> Because your variable is a different size to your SLE_... type.
16:10:12 <locosage> ok, I think I figured out debugging at least
16:10:13 <locosage> `static_assert(..., "test"#variable" length:"#length)`
16:20:10 <peter1138> Amazing, we still build on random BSDs 😄
16:23:24 <pickpacket> is there anything I can do with pre-signals that I can't do just as well with path signals?
16:25:35 <pickpacket> nice. Then I won't spend a load of time learning how to use them
16:28:46 <locosage> pickpacket: overflow
16:28:50 <emperorjake> You need presignals for logic gates and other fancy techniques
16:29:00 <emperorjake> but many players don't bother with those
16:29:51 <talltyler> Priority merges are about the only good usecase. I sometimes use them.
16:30:11 <pickpacket> I don't do that stuff. Overflows, logic gates, complicated merges aren't my jam
16:31:13 <pickpacket> though I have to admit I don't really know when any type of logic gates solves a problem in the game
16:31:24 <talltyler> You can do depot overflows without special signals if you don’t mind sending every train through the depot 😉
16:31:27 <pickpacket> has anyone implemented Doom with logic gates in the game yet?
16:31:31 <talltyler> (I do on a regular basis)
16:31:43 <pickpacket> talltyler: poor man's overflow? :D
16:32:08 <locosage> more like lazy man's
16:33:19 <pickpacket> When I have too many trains backed up on a line I get rid of a few of them. Since I no longer build shared main lines and hubs a long queue just means I've over-provisioned the number of trains needed on the line
16:34:05 <pickpacket> so a queue won't block merges or splits, just back up the single line
16:57:11 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:01:18 <peter1138> Hmm, I wonder if installing the 'native' Discord app would solve my audio/video issues...
17:02:49 <_glx_> needs to do more debug, but ```using AutoreplaceMap = std::map<Vehicle *, bool>;
17:02:49 <_glx_> static AutoreplaceMap _vehicles_to_autoreplace;
17:02:49 <_glx_> ``` and ` for (auto &it : _vehicles_to_autoreplace) { /* call auto replace command */ }` might be our problem
17:04:51 <peter1138> The thing that's been there for 15 years and 5 years?
17:05:52 <_glx_> the std::map is only one year old
17:06:30 <_glx_> I think we just need to add a sorter to it
17:06:34 <peter1138> Fair. That should mapped by index.
17:06:53 <_glx_> but I added some Debug to validate
17:08:31 <peter1138> Or just do it by VehicleID.
17:08:53 <_glx_> I'll read the function 🙂
17:15:09 <peter1138> Something like that.
17:16:07 <peter1138> I saw the blame for the other two lines, not the std::map line 😮
17:16:34 <_glx_> yeah was going in the exact same direction
17:20:17 <peter1138> Yeah, unsorted I guess.
17:21:34 <peter1138> Perhaps the structure should be changed to not-a-map.
17:23:29 <_glx_> at least now I can consistently get the savegame+commands start at c0 and desync at fe
17:37:03 *** afgsdfg has joined #openttd
17:55:54 <peter1138> Gah, squash & merge lagged so I didn't get a chance to fix the commit title.
17:56:03 <pickpacket> I’d like depots to show how many vehicles are in them just like other lists do. Might have a look at how to do that in a few weeks unless none of you all feels inclined to 🙂
17:56:27 <pickpacket> Feels like a small qol thing to add
17:58:06 <merni> what about carriages that aren't connected to engines? do those count?
17:58:51 <peter1138> I've actually wanted a Depot List window a few times actually...
17:59:19 <merni> (also, one too many actuallies)
18:42:17 <talltyler> Okay, thats enough PRs for today 😅
18:47:47 <truebrain> so, desync fixed? 🙂
18:51:32 <Rubidium> seems at least one cause for desync has been fixed
18:53:25 <talltyler> Hmm, two hours ago I said “I’ll just test my fix and then I’ll do the lunch dishes” 🤔
18:53:40 <talltyler> But I kept finding bugs
18:54:04 <talltyler> I guess it’s time now
18:57:14 <_glx_> truebrain: Your testing of many of the saves help to reduce the test time (68 economy days doesn't take too long)
18:58:27 <Rubidium> it might be worth it to make a PR of your improvements to the desync rerunning documentation and code
18:58:49 <truebrain> for my parts I am already doing so, yeah 🙂
19:02:49 <truebrain> lol, command replay also allows you to add a "join" command, to join the actual server manually at a certain moment in time
19:05:21 <Rubidium> funny and useful if you want to run little vs big endian
19:06:18 <truebrain> the "desync to log" infra is so awkward
19:06:52 <truebrain> at lvl1 is meant to go into the command.log
19:06:58 <truebrain> but the lvl2 are all non-replayable commands
19:08:26 <_glx_> I redirected all the output from replay to misc, no need to put it in the file
19:08:52 <truebrain> yeah, but I think that is the wrong fix. I did it too, but it is just all a bit awkward
19:08:56 <truebrain> let's see if we can fix it up a bit nicer
19:10:06 <_glx_> yeah misc might not be the proper target, but sending "Injecting" and friends to command-out seems wrong too
19:11:59 <_glx_> and enabling RANDOM_DEBUG is not simple, there's no commented out define to uncomment
19:18:34 <truebrain> owh, unrelated change in 12519 .. I can hold on to that for another PR
19:22:51 <truebrain> hmm .. I fucked that PR up .. what did I do wrong .. 😄
19:23:20 <truebrain> `DEBUG_DUMP_COMMANDS` is not known in that file
19:24:22 <truebrain> I do not like defines like that, but okay 🙂
19:25:31 <truebrain> funny how early the game now desyncs, when replaying that log btw
19:25:55 <truebrain> now that PR works ... 🙂
19:27:56 <peter1138> Random comment about lots of pushing...
19:28:09 <truebrain> only valid reaction: stfu
19:28:26 <truebrain> *flips table*, also works 😛
19:30:07 <_glx_> at least now they don't overload the CI 🙂
19:31:15 <truebrain> that PR cost me a lot of time yesterday, the fact of not having that 😄
19:36:06 <peter1138> Yeah, that one stumped me for a bit last night 😄
19:37:41 <_glx_> oh and there's a `See Section 3.2` in section 3.2, should say 3.3
19:38:47 <truebrain> (Discord now supports markdown links 😄 )
19:40:17 <_glx_> so many QoL improvements for desync debug
19:40:48 <truebrain> I was shocked it still worked
19:41:00 <truebrain> I mean, it is not like we tested it in any recent times 😛
19:41:23 <_glx_> all the strcmp could be replaced, but it's less important 🙂
19:41:25 <truebrain> and I was surprised by how well it was documented and functional. That was a nice surprise 🙂
19:42:05 <truebrain> and now we wait for CodeQL 😛
19:44:09 <_glx_> 14 PR to backport, not bad 🙂
19:44:26 <truebrain> andythenorth: lolz. "Asking customers what they want? NAH!"
19:44:47 <_glx_> we just want to see what is unused
19:45:06 <truebrain> just the notion that you shouldn't listen to your users is close to insanity in my world 🙂
19:45:39 <_glx_> yeah listen, but ignore the silly ideas
19:45:47 *** audigex has joined #openttd
19:45:47 <audigex> I think there's a balance to be had - you have to listen to users and I think it's worth changing default settings towards what people actually use
19:45:47 <audigex> But at the same time users don't always understand game design and it's possible people ask for things they don't *really* actually want
19:46:16 <truebrain> I used the word "listen" and "asking" deliberately, yes 🙂
19:46:43 <truebrain> we will still hide block signals by default, remove shares, and more of that nonsense 😛
19:47:27 <audigex> I still think breakdowns should be off by default, and I'll die on this hill
19:47:33 <_glx_> oh and the variants, so newgrf author can overfill the build list 🙂
19:47:56 <truebrain> yeah .... I get that NewGRF authors wanted variants, but I think it is not the best addition to the game, personally 🙂
19:48:03 <audigex> _glx_: Wait until BRTrains switches to variants 😂 that UI is going to get thoroughly tested
19:48:32 <andythenorth> truebrain: make an option to turn them off 😛
19:48:36 <audigex> truebrain: I think we needed SOMETHING better than the refit option for liveries. I still don't think it was done in quite the right way in terms of having to make a new vehicle for every livery
19:48:37 <truebrain> it is like .. "oeh, shiny!" - *total abuse followed*
19:48:49 <_glx_> well they were using workarounds with refits, not better
19:49:06 <truebrain> owh, and yes, I blame the NewGRF authors, in case anyone was wondering 😛
19:49:26 <audigex> I blame Chris Sawyer for not planning ahead
19:49:43 <audigex> But yeah we really needed something for liveries and I didn't see any better ideas
19:50:03 <_glx_> yeah always blame them for using workarounds instead of asking proper implementation for what they want to do
19:50:32 <peter1138> Okay so I d d bad feature 😦
19:50:56 <truebrain> glass half-empty kinda guy 😛
19:51:05 <audigex> peter1138: NewGRF authors love you for it tbf, it's MUCH better than the previous option
19:51:17 <_glx_> variants are still better than livery refit, because they work with autoreplace
19:51:19 <truebrain> they just should learn to apply restrain!
19:51:36 <truebrain> we should have given them 10 variants for 1 dollar
19:51:42 <audigex> My only criticism is that I wish I could define livery variants more easily in NML, rather than having a whole new train for every livery combination
19:51:42 <truebrain> that would have helped 😄
19:52:05 <andythenorth> the harm is minimal
19:52:16 <andythenorth> probably not worse than 16k maps
19:52:18 <peter1138> Well that's an NML tooling change really.
19:52:29 <truebrain> PRs are welcome 😉 😛
19:52:53 <_glx_> that's a missing GRF property most likely
19:53:15 <_glx_> something to copy an existing engine properties
19:53:45 <peter1138> Or NML could just do it.
19:53:54 <truebrain> can we make NML charge money for its usage?
19:55:28 <_glx_> but nobody's reviewing nml PR anyway 🙂
19:55:31 <audigex> It seems to me like it's just something where NML could handle it. Hell, it could even be a wrapper on top of the current cargo_subtype stuff and most people wouldn't even have to change code
19:56:03 <truebrain> _glx_: there is a reason I no longer await approvals on any of our other Python projects 😛
19:56:21 <peter1138> My Python knowledge is very ... minimal.
19:57:34 <_glx_> and nml source is a pain
19:57:34 <truebrain> 20m to compile OpenTTD for CodeQL .. was it always that bad? I thought it was faster ...
19:57:38 <_jgr_> A lot of the needless duplication issues with NML have been "solved" by sticking template generators in front of it
19:58:37 <_jgr_> At the expense of unnecessarily large GRF files
19:58:43 <peter1138> An action 0 property to copy from another ID is... kinda weird.
19:58:53 <peter1138> But then again I guess that's kinda how houses and industries work.
19:59:06 <peter1138> And stations have the copy-layout thing, but not copy the whole station.
19:59:51 <peter1138> Someone would come up with a way to want it to behave differently...
19:59:54 <_glx_> layout can be huge, so yeah it's a good thing there
20:00:28 <andythenorth> _jgr_: I think that's mostly just me?
20:00:48 <peter1138> NML doesn't really do the "setting multiple IDs at once" thing that NFO/GRF made easy.
20:00:55 <_glx_> anyway on nml side it should be doable to tell to copy properties from another item, then apply your own overloads
20:01:04 <andythenorth> just add templating to nml 😛
20:01:12 <truebrain> just rewrite in Rust
20:01:17 <truebrain> solves everything, so I read
20:02:11 <peter1138> Also it's kinda annoying that the property numbers are all different between vehicle features.
20:02:13 <_jgr_> andythenorth: Your code and GRFs are forked and used as examples a lot more than your average GRF
20:02:55 <truebrain> Rubidium: that was the end of my local modification queue 🙂
20:03:04 <_glx_> something like `property [<another item>] {...}` could work
20:03:19 <andythenorth> _jgr_: I think most people just use the raw nml though, and delete the templated compile
20:03:21 <locosage> peter1138: especially as there are a few common ones
20:03:38 <audigex> I feel like what I really want is for NML to be handed the equivalent of the cargo_subtype switches and add each of them like variants
20:03:54 <andythenorth> just use cargo_subtypes?
20:04:14 <audigex> Essentially yeah, but enumerate it into the purchase manu
20:06:09 <truebrain> funny how we got from a steam comment to this conversation 😛
20:07:55 <audigex> Leave variants as they are so that I can still have
20:07:55 <audigex> Electrostar (non-purchasable variant header)
20:07:56 <andythenorth> audigex: but each cargo_subtypes entry would be array of all action 0 props
20:07:57 <audigex> But then for each of those `Class 375/3` units, it automatically enumerates the liveries
20:07:59 <audigex> Electrostar (non-purchasable variant header)
20:08:01 <audigex> -+ Southeastern Yellow
20:08:05 <audigex> -+ Southeastern Yellow
20:08:07 <audigex> +- London Overground "Aventra"
20:08:39 <audigex> andythenorth: This is where we get into "I have no idea how it works behind the scenes, just how I want it to work"
20:08:39 <audigex> If we have to add a separate item similar to cargo_subtypes that just stores that information, that's fine by me too
20:09:09 <andythenorth> I suppose we could add a new structure, that's like a vehicle block, but isn't a vehicle block
20:09:12 <andythenorth> but has all the same props
20:09:18 <peter1138> "Automatically enumerates the liveries" suggests you are automatically... creating the sprites?
20:09:18 <andythenorth> I'm unclear what's gained
20:09:22 <_jgr_> audigex: Having all these different vinyl options seems a tad overkill
20:09:43 <audigex> _jgr_: Welcome to BRTrains. That's kinda the point
20:09:48 <andythenorth> _jgr_: overkill isn't relevant to a survey set
20:09:51 <andythenorth> it's completionist
20:10:20 <andythenorth> Stock/dp/1915984181/ref=asc_df_1915984181/?tag=googshopuk-21&linkCode=df0&hvadid=691898106654&hvpos=&hvnetw=g&hvrand=16118118610393521908&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1006567&hvtargid=pla-2294290019991&psc=1&mcid=fff1fe454fd63c399ce24b12e7ee1679&th=1&psc=1&gad_source=1&gclid=CjwKCAjw5v2wBhBrEiwAXDDoJerwUVcfeiLxU_5Ppyc9Ra85chqHQcAVCq6RjoVnkgpNy7zXRNztThoC4sEQAvD_BwE
20:10:23 <audigex> Yeah exactly, the idea of BRTrains is that you can (eventually) have ANY unit that's been driven on the UK rail network in ANY livery it's been seen in
20:10:34 <peter1138> Confusing about Iron Horse is you have small/medium/large available for wagons all the way back in 1935...
20:10:49 <andythenorth> peter1138: that's the *only *confusing thing? 😮
20:10:54 <peter1138> But I would've thought the sizes would be date-related.
20:11:17 <truebrain> what was large in 1935 is small now? 😄
20:11:19 <andythenorth> I probably wanted bigger ones
20:11:27 <peter1138> All the variants themselves are mostly ignorable because you don't have to expand the tree. That's kinda the point.
20:11:48 <audigex> peter1138: The sprites are all drawn, not generated
20:11:48 <audigex> What I want is this, but in the purchase menu...
20:11:55 <locosage> _jgr_: it's fine... 🤭
20:12:14 <andythenorth> the main thing is that FIRS no longer breaks all the train grfs
20:12:20 <andythenorth> so that's solved
20:12:44 <truebrain> and I am reminded again why I dislike the way NewGRF authors "use" this functionality 🙂
20:12:49 <truebrain> so I refer back to my original statement 🙂
20:13:04 <audigex> truebrain: But players like it and enjoy it...
20:13:05 <_glx_> listing all engines of a series with the real unit number ?
20:13:21 <audigex> _glx_: haha that would perhaps be a step too far but I could make it happen
20:13:44 <truebrain> audigex: players? plural? you sure? 😛
20:13:51 <peter1138> That's how we ended up with the "joke" about only allowing one of each type to be built the other day 😄
20:14:19 <Rubidium> truebrain: zero players?
20:14:34 <audigex> truebrain: haha much as I'd like to think I just make BRTrains for myself, the discord for it has 60 members and there was a conversation earlier where I was given about another 10 unit requests
20:14:49 <truebrain> audigex: alter egos? 😛
20:14:53 <truebrain> (I can do this all night long!)
20:14:58 <truebrain> I am just pulling your leg, to be clear 🙂
20:15:00 <audigex> I have more than enough ego for the whole set thankyou
20:15:11 <audigex> If there's anything out there more important than my ego I want it caught and shot, immediately
20:15:51 <truebrain> then you have me, that just wants a train that "looks pretty", and get very annoyed / overwhelmed by the thousands of alternative looks & feels 😛
20:15:56 <audigex> I mean, to be clear, I understand that BRTrains is something of a niche set and that the needs of this kind of "completionist" set isn't necessarily representative of the typical GRF, but it would be nice if it was catered for
20:16:27 <audigex> If not, it just means I do the same thing but with livery refits and nobody is happy 😂
20:16:51 <truebrain> I still can't over the fact people want realistic trainsets in the game, but are fine with busses being these gigantic structures
20:16:56 <truebrain> that is something I cannot handle / deal with 😛
20:17:07 <audigex> I just don't use buses, problem solved
20:17:16 <audigex> Never mind the fact a Pendolino is the size of a small town
20:17:18 <truebrain> head-in-sand approach, that is acceptable 🙂
20:17:44 <_jgr_> Scale in the game is all wibbly-wobbly, you just have to embrace that
20:17:54 <truebrain> but yeah, I can fully accept there is a niche of people that like this kinda game 🙂
20:17:55 <_glx_> ships are best, you can stack them on a single tile
20:18:37 <Rubidium> it's quite realistic that there can be multiple ships in a 600 km by 600 km area ;)
20:19:21 <truebrain> wait, a bus is 600km long?
20:19:24 <truebrain> and only fits 30 pax?
20:19:48 <andythenorth> doesn't 32bpp fix the scale though?
20:19:52 <truebrain> people would die getting on and off the bus 😄
20:20:14 *** frosch123 has quit IRC (Quit: User went offline on Discord a while ago)
20:20:32 <truebrain> just the mileage on that bus
20:20:50 <truebrain> so we should also allow busses to stack on a single tile
20:21:00 <Rubidium> yeah, the quantum effects ;)
20:21:23 <truebrain> well, okay, let me rephrase: we should remove the code that busses stack up behind each other
20:21:26 <truebrain> as that clearly is unrealistic 😛
20:21:53 <_glx_> oh that allows to remove non working overtaking
20:22:02 <Rubidium> exactly what I was thinking
20:22:14 <andythenorth> we are absent this
20:22:37 <peter1138> Allow overlapping trains too?
20:22:44 <truebrain> _glx_: and all the weirdness around that, yes. I have an open bug about it 🙂
20:22:48 <peter1138> No need for signals of any sort.
20:22:55 <truebrain> peter1138: now don't be silly
20:22:58 <peter1138> Imagine the performance increase.
20:23:03 <andythenorth> Railroad Tycoon 3 trains overlap
20:23:10 <truebrain> we could handle thoouuusssaannndddssss of trains 🙂
20:23:11 <andythenorth> but only if you've signalled the track
20:23:32 <andythenorth> and one of the overlapping trains stops to allow the other to pass
20:23:36 <andythenorth> simulated sidings
20:23:38 <truebrain> it also means that there is 600km between two houses ... talking about distant neighbours
20:24:18 <_glx_> that's why 10000+ people wait at the bus stop
20:24:35 <truebrain> "I aint going back home! I rather sleep here for a few days!"
20:24:49 <truebrain> bus-stops are big enough to fir 10k people
20:24:53 <truebrain> so that all adds up
20:25:52 <truebrain> right, enough nonsense for one day. Time to get some early zzzs
20:25:59 <andythenorth> truebrain: have you ever seen depots in the game?
20:26:17 <_glx_> infinite space in one tile yes
20:26:31 <andythenorth> also...what is the point of Horse Variants?
20:26:34 <andythenorth> they're just the same
20:26:45 <_glx_> "it's bigger in the inside"
20:27:38 <andythenorth> what if we randomised the 2nd company colour on game start? 😛
20:28:04 <andythenorth> we have a setting
20:28:27 <andythenorth> can I ctrl-click any of that? 😛
20:34:37 *** Smedles has joined #openttd
20:36:25 <peter1138> Someone will want to copy the properties of a vehicle that isn't yet defined, won't they?
20:37:47 *** Smedles has joined #openttd
20:39:29 *** Smedles has joined #openttd
20:40:56 *** Smedles has joined #openttd
20:43:03 *** Smedles has joined #openttd
20:48:41 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:54:02 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:54:47 <peter1138> Hmm, backport for #12522? it's not exactly a fix though.
20:56:18 <peter1138> Oh I missed a trick, I should've used property 0xC0 for that.
21:03:29 <peter1138> IIRC JGRPP has a dynamic system for this.
21:04:02 <peter1138> Something like the NewGRF defines which IDs it will be using by name (I think)
21:05:02 <peter1138> Maybe we can do properties by name, and then just define a default mapping of the existing numbers for things that don't define one.
21:08:37 <peter1138> Defining a mapping separately means it works without a bump.
21:37:47 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:42:44 *** gelignite has quit IRC (Quit: Stay safe!)
22:01:16 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:14:37 *** Wormnest has joined #openttd
23:23:12 <_glx_> yeah the temperature drop is crazy
23:24:04 <_glx_> ah nice, FiosIsHiddenFile doesn't compile 🙂
23:42:03 *** ChanServ sets mode: +v tokai
23:48:41 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:50:15 <peter1138> Heh, I'd already got there 🙂
23:51:06 <peter1138> Eventually it would be nice to use the C++ versions of OTTD2FS/FS2OTTD.
23:51:22 <peter1138> But that's a bit messy because they decided on u8string and char8_t, so...
23:52:28 <_glx_> win32 API will still need wchar_t*
23:53:02 <peter1138> Yes, that's separate from conversion.
23:56:23 <peter1138> std::filesystem::path automatically converts utf-8 to native. But only when you use u8string/char8_t. Sigh 🙂
23:56:58 <peter1138> Can be forced by casting of course.
23:57:06 <_glx_> native in windows world is UTF16
23:58:13 <_glx_> anyway u8string/char8_t will cause more issues 😉
23:58:31 <peter1138> Yes.. that's why I'm grumbling about it!
23:58:45 <_glx_> the idea was nice, but the result is a carnage
23:59:16 <peter1138> u8path exists briefly, which will treat a std::string as a utf-8 path, but that's C++17 and deprecated in C++20.
continue to next day ⏵
