IRC logs for #openttd on OFTC at 2025-05-13
⏴ go to previous day
00:02:12 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:02:47 *** WormnestAndroid has joined #openttd
00:10:38 *** akimoto has quit IRC (Remote host closed the connection)
00:23:43 <peter1138[d]> Spam, glorious spam.
01:36:27 *** Flygon has quit IRC (Read error: Connection reset by peer)
01:39:37 *** tokai|noir has joined #openttd
01:39:37 *** ChanServ sets mode: +v tokai|noir
01:46:30 *** tokai has quit IRC (Ping timeout: 480 seconds)
01:49:33 *** Wormnest has joined #openttd
01:55:49 <yiffgirl> #0 0x000071839f8ade22 in ?? () from /usr/lib/libc.so.6
01:55:49 <yiffgirl> #1 0x000071839f8a1fda in ?? () from /usr/lib/libc.so.6
01:55:49 <yiffgirl> #2 0x000071839f8a2024 in ?? () from /usr/lib/libc.so.6
01:55:51 <yiffgirl> #3 0x000071839f91c05e in poll () from /usr/lib/libc.so.6
01:55:51 <yiffgirl> #4 0x000071839e9a0e77 in ?? () from /usr/lib/libSDL3.so.0
01:55:53 <yiffgirl> #5 0x000071839e98c876 in ?? () from /usr/lib/libSDL3.so.0
01:55:53 <yiffgirl> #6 0x00005d1fcee199f1 in VideoDriver_SDL_OpenGL::Paint() ()
01:55:55 <yiffgirl> #7 0x00005d1fcee1dd53 in VideoDriver::Tick() ()
01:55:55 <yiffgirl> #8 0x00005d1fcee18367 in VideoDriver_SDL_Base::MainLoop() ()
01:55:57 <yiffgirl> #9 0x00005d1fcefba18c in openttd_main(int, char**) ()
01:55:57 <yiffgirl> #10 0x000071839f8376b5 in ?? () from /usr/lib/libc.so.6
01:55:59 <yiffgirl> #11 0x000071839f837769 in __libc_start_main () from /usr/lib/libc.so.6
01:55:59 <yiffgirl> #12 0x00005d1fceab6875 in _start ()
01:59:52 <yiffgirl> so... i guess something is going funky in Paint()? maybe?
01:59:52 <yiffgirl> this doesn't seem all that helpful
02:11:59 *** gnu_jj_ has joined #openttd
02:15:35 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:27:23 *** Wormnest has quit IRC (Quit: Leaving)
02:28:10 <_glx_> well we don't support SDL3
02:29:10 <_glx_> and the trace shows it's something happening in SDL3
03:03:45 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:03:46 *** WormnestAndroid has joined #openttd
03:03:49 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:03:50 *** WormnestAndroid has joined #openttd
03:03:53 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:04:05 *** WormnestAndroid has joined #openttd
03:05:43 <yiffgirl> i think that's just the sdl 2 to 3 shim rather than it being compiled with sdl3
03:07:17 <yiffgirl> anyway. i assume that's all I can learn here?
03:07:49 <dwfreed> install libc and libsdl debug symbols so your backtrace is actually useful
04:30:17 <yiffgirl> gdb only bothers to load the symbols from debuginfod when not running as sudo, but trying to connect from a non-sudo gdb gets denied by ptrace... and even with sudo i can't tell it not to do that
04:42:33 <yiffgirl> yiffgirl: update: `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` worked, let's see what happens...
04:47:44 <DorpsGek> - Update: Translations from eints (by translators)
05:12:28 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:01:46 <peter1138[d]> Try a stack trace of a different thread. That one might just waiting for a locked one
06:05:40 <peter1138[d]> `thread apply all bt`
06:29:21 <pickpacket> Hmm. I've forgotten again; what's the upper limit of how big FIRS (or any other industry set) can become?
06:29:37 <pickpacket> Something about cargo id?
06:32:33 <andythenorth> pickpacket: 64 cargos
06:38:06 <andythenorth> raising the limit would lead to situations like this
06:38:15 <andythenorth> very bad for compile times 😛
06:40:33 <yiffgirl> peter1138[d]: wow. that's a lot
06:48:15 <pickpacket> andythenorth: I don't understand what's problematic about that output 🤔 How many cargo types are in FIRS now?
06:48:40 <andythenorth> nobody really needs 11388 trains in one grf 😛
06:48:49 <andythenorth> and the compile time is shockingly bad
06:49:09 <pickpacket> What has that got to do with cargo ids, though?
06:49:31 <pickpacket> The number of trains, I mean
06:50:01 <andythenorth> it's more about limits, and why they're good
06:50:41 <peter1138[d]> yiffgirl: Mostly threads set up by other things, e.g. audio processing.
06:50:53 <peter1138[d]> However, yeah, doesn't seem to be ottd itself in a loop.
06:51:09 <pickpacket> The reason I ask is because someone in Hellish's last stream commented that "chickens and eggs should be part of FIRS" and Hellish suggested joining the FIRS dev team and adding it. And it got me wondering whether it's even possible to add anything more to it 😂
06:52:32 <peter1138[d]> I would suggest that that is more of a "that's a stupd idea so you'll have to do it yourself if you want to" answer :p
06:53:23 <pickpacket> No sense in trying if it's not even technically possible though 😄
06:59:41 <andythenorth> it's entirely possible
06:59:51 <andythenorth> you'd have to figure out where chickens and eggs come from
06:59:53 <andythenorth> and which makes which
07:01:38 <yiffgirl> the "firs dev team" is just you andy, right?
07:18:44 <yiffgirl> peter1138[d]: i wonder if i tell it to continue it'll fix itself... nope. had to send it a stop signal again.
07:23:14 <yiffgirl> but i guess if it's not actually stuck in a loop then something must be wrong with the graphics on my end
07:23:14 <yiffgirl> arch doesn't even package actual sdl2 any more, just the 2-to-3 shim
07:23:34 <yiffgirl> is there anything more i can do from here?
07:23:39 <peter1138[d]> Yeah "it kinda works, let's ship it"
07:24:00 <peter1138[d]> Disable "hardware acceleration" in OpenTTD and hope it doesn't happen again.
07:29:03 *** reldred has joined #openttd
07:29:03 <reldred> Hardware acceleration is inconsistent even on Windows
07:29:19 <reldred> Even between Nvidia and AMD
07:29:31 <reldred> Worked really well on a mac I had for a while though
07:30:21 <andythenorth> yiffgirl: I get help, but yes
07:31:49 <reldred> but then tonnes of people have no issues with hardawre acceleration so yeah, strange
07:33:29 <pickpacket> andythenorth: I didn't understand the 1000+ trains bit. Does the number of cargoes affect that?
07:35:03 <andythenorth> it was more of an abstract point 😛
08:33:52 *** Smedles_ has joined #openttd
08:37:18 *** Smedles has quit IRC (Ping timeout: 480 seconds)
08:51:22 *** mindlesstux has joined #openttd
09:01:23 <xarick> std::byte is returning?
09:10:03 *** SigHunter has joined #openttd
10:08:12 *** kuhnovic has joined #openttd
10:08:12 <kuhnovic> Lunch and coffee, what a day
11:12:02 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:12:06 *** WormnestAndroid has joined #openttd
11:31:18 <xarick> air stuff kind of working...
11:31:53 <xarick> air has a complete different build logic than the other transport modes...
11:32:46 <xarick> and I'm trying to fit it in
12:17:07 <pickpacket> xarick: I'm trying to fit in, too
13:18:06 *** kuka_lie has joined #openttd
13:23:27 <peter1138[d]> No, it was a deliberate change.
13:38:29 <pickpacket> LordAro: issue or PR?
13:39:36 <pickpacket> What am I looking for?
13:53:26 <pickpacket> ohhh. I think I know which one in that case.
14:36:03 <xarick> how does unbunch order works in that way anyway?
14:36:20 <xarick> it's not part of the orders
14:38:18 <xarick> oh nevermind, i am confused
14:39:06 <xarick> ah while creating orders
14:40:32 <xarick> > I very rarely use the unbunch functionality because I prefer to use timetables to spread the vehicles evenly
14:40:53 <xarick> but isn't exactly that what unbunch does?
14:41:54 <_glx_> unbunch doesn't use timetable at all
14:42:21 <_glx_> autoseparation (JGRPP feature) uses timetables
14:42:53 <talltyler> If you are using timetables, unbunching does set them "on time" when they leave the unbunching depot. So you can use timetables to choose how long vehicle stop at stations, if you want.
14:43:22 <talltyler> But the timetable has no effect on the unbunching behavior.
14:43:30 <talltyler> So you are correct, I am just being pedantic. 😄
14:43:35 <_glx_> I don't imagine an IA using timetables anyway
14:43:51 <talltyler> I don't think they can
14:44:09 <xarick> it's not implemented 😦
14:44:29 <xarick> and I don't understand timetables to start coding on that
14:45:03 <_glx_> it's hard enough to use for human, so let it out of AI world
14:46:30 <_glx_> order handling is already a pain for AIs
14:50:07 <xarick> can we have the unbunch flag?
14:52:44 <xarick> 14260 was already merged
15:01:59 <xarick> regression.txt conflicts
15:02:13 <xarick> because it prints the line number
15:06:55 <xarick> oh snap, conflicts with the new stuff
15:07:20 *** Wormnest has joined #openttd
15:13:08 <xarick> I actually remember checking if any AI was using the function for rail waypoints and I found none
15:13:30 <xarick> do i still create a compatibility thiingy
15:15:16 <xarick> how am I supposed to do this with separate PRs 😦
15:21:41 <_glx_> xarick: wait for #13456 merge, then you can add compat layer to #13455 (should not be too hard, something like calling the new ScriptVehicleList_Station() and add the list from ScriptVehicleList_Waypoint())
15:23:48 <xarick> scriptwaypointlist should also use the vehicle type treatment, gonna try copy paste
15:31:40 <_glx_> waypoints are specific to one type
15:32:15 <_glx_> no need to add vehicle type filter
15:34:06 <xarick> can't have a waypoint that is both rail and road nowadays?
15:34:47 <xarick> yeh, you're right, it can't
16:00:31 *** Flygon has quit IRC (Remote host closed the connection)
16:24:03 <xarick> 13409 needs a compatibility layer
16:31:30 <_glx_> yes, for older AI if AIStation::GetStationID fails it should fallback to AIWaypoint::GetWaypointID to restore old behaviour
16:36:00 *** gelignite has joined #openttd
16:36:37 <xarick> hmm, that's a bit of a problem
16:38:58 <xarick> Unsure if it's safe to rely on AIStation::GetStationID
16:42:30 <_glx_> ```local id = AIStation::GetStationID(tile);
16:42:30 <_glx_> return (id == -1) ? AIWaypoint::GetWaypointID(tile) : id;```
16:43:35 <xarick> I was looking for the official invalid station constant
16:43:56 <_glx_> but typically should be -1
16:45:05 <_glx_> other option is AIStation.IsValidStation(id)
16:45:18 <xarick> it's in BaseStation for reasons...
16:46:26 <_glx_> ah of course, since it's shared with waypoints
16:47:25 <xarick> ```AIStation.GetStationIDCompat14 <- AIStation.GetStationID;
16:47:25 <xarick> AIStation.GetStationID <- function(tile) {
16:47:25 <xarick> local id = AIStation.GetStationIDCompat14(tile);
16:47:25 <xarick> if (id == AIBaseStation.STATION_INVALID) return AIWaypoint.GetWaypointID(tile);
18:49:01 <peter1138[d]> I lack the ability to test low memory 😮
18:51:43 <peter1138[d]> Hmm, cgroups perhaps.
18:52:25 <_jgr_> I doubt that the old behaviour will work at all on non-Windows due to overcommit
19:05:19 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:23:00 <xarick> when is darwin 300 available?=
19:23:14 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:24:28 *** WormnestAndroid has joined #openttd
19:26:47 <frosch123> It works with ulimit.
19:26:47 <frosch123> The intention is not low memory though. The test is about low address space in 32bit builds for windows and emscripten, where we do not know how much heap is occupied by external deps.
19:33:38 <peter1138[d]> `ulimit -m` hasn't worked since kernel 2.4.30...
19:37:23 <peter1138[d]> Okay well anyway, if it's desirable and the intention is to ensure that the sprite cache is pre-allocated to a certain size, this is not going to help.
19:53:03 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
19:56:20 *** WormnestAndroid has joined #openttd
19:56:37 <LordAro> peter1138[d]: pros of uploading first
19:58:46 *** akimoto has joined #openttd
20:09:06 *** WormnestAndroid has quit IRC (Read error: No route to host)
20:09:07 *** WormnestAndroid has joined #openttd
20:36:34 <peter1138[d]> Alright, how would you implement an iterator that starts "in the middle" and alternately takes from the front and back?
20:37:11 <peter1138[d]> e.g. a range of `0 1 2 3 4 5 6 7 8 9` should go something like `5 4 6 3 7 2 8 1 9 0`.
20:37:25 <peter1138[d]> With added fun that "the middle" might be somewhere else.
20:37:40 <peter1138[d]> e.g. `3 2 4 1 5 0 6 7 8 9`
20:41:47 <xarick> something distance maybe?
20:43:27 <xarick> I did a similar thing when iterating the tiles of a road path. I want to place the depot closest to the middle of the road.
20:48:35 <Rubidium> peter1138[d]: is range in that context essentially a span? Or a continuous range of integers like iota?
20:49:35 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:51:19 *** WormnestAndroid has quit IRC (Read error: No route to host)
20:54:28 <talltyler> I need to write code more often, I'm super rusty
20:55:16 *** WormnestAndroid has joined #openttd
21:00:58 <talltyler> What am I missing here? It buys the selected vehicle, never randomizing (even if I always randomize without checking the flag).
21:06:05 <talltyler> Trying to resolve Andy’s random horse wagon problem, but eight hours of Unreal Engine (real job) has cooked my brain 😛
21:10:05 <peter1138[d]> 1) If the variant isn't expanded, no children will be listed.
21:10:36 <peter1138[d]> 2) You only include direct children, no further descendants.
21:13:57 <talltyler> Mmm, is there a better list of available engines to iterate through?
21:14:19 <talltyler> Looking for grandchildren, etc., sounds like recursion will be needed 🙂
21:14:37 <talltyler> (As you’ve already done when drawing them)
21:20:13 <peter1138[d]> Well, there's the actual engine list...
21:24:10 <peter1138[d]> (And you should probably just fill a container of EngineID, not GUIEngineListItems)
21:24:32 <talltyler> That does sound easier 🙂
21:24:51 <talltyler> I’ll have a crack at that later, thanks for the help 😄
21:33:41 <andythenorth> might be easier in the long run to invert, and have the grf handle a 'give me a random ID''
21:34:00 <andythenorth> variants are great, but there are facets....and authors use them for weird stuff in weird ways
21:34:07 <andythenorth> I'd consider decoupling 🙂
21:35:36 <peter1138[d]> Hmm, that's a different kind of iterator 😮
21:36:30 <peter1138[d]> 'generator' file not found.
21:37:05 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:44:24 *** michi_cc has joined #openttd
21:44:24 <michi_cc> Rubidium: Could also use ranges::zip_view instead of the generator I think, but then that is C++23, too.
21:45:30 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:50:44 <talltyler> andythenorth: A callback or a property containing a list of IDs?
21:53:38 <peter1138[d]> A callback can only return one value, so it would need to be repeatedly called.
21:53:52 <peter1138[d]> (Or registers, but they're still limited)
21:58:34 <talltyler> Right, I mean the callback would select randomly and provide the ID to be built
21:59:28 <talltyler> Could be a novel way for authors to do naughty things, who knows 😄
21:59:31 <peter1138[d]> Oh, right. Yeah.
21:59:54 <peter1138[d]> Conflating it with the other "need" of "build 3 random parts"
22:00:28 <talltyler> This is not “fill to length” 🙂
22:00:46 <talltyler> That can be achieved by clicking the button multiple times, I don’t see the need to automate that
22:01:42 <talltyler> Besides enabling Train Whack (which is a noble goal), what’s the usecase for a separate list of possible alternatives?
22:02:31 <talltyler> The main reason I’m using variants is because players can easily see the pool of possible options using an existing GUI they’re already looking at
22:03:06 <talltyler> I would hate to see the possible alternatives listed in extra text, that would be terrible design on my part to make that necessary 🙂
22:05:17 <talltyler> I suppose one argument is “an item can only be in one hierarchy” — so you couldn’t have a milk tank in Food Wagons and Tank Wagons simultaneously
22:05:22 *** kuka_lie has quit IRC (Quit: Lost terminal)
22:19:04 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:20:00 *** WormnestAndroid has joined #openttd
22:21:13 <peter1138[d]> terminate called after throwing an instance of 'std::bad_alloc'
22:21:13 <peter1138[d]> what(): std::bad_alloc
22:22:31 <peter1138[d]> Used firejail to limit memory.
22:22:49 <peter1138[d]> [2025-05-13 23:22:41] dbg: [misc:0] Not enough memory to allocate 2048 MiB of spritecache. Spritecache was reduced to 8 MiB.
23:17:14 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:27:21 *** WormnestAndroid has joined #openttd
23:29:16 <frosch123> talltyler: train alterations on build are complicated. You always have to also consider what clone vehicle, renew vehicle, and replace vehicle shall do. Random vehicle flipping is already slightly broken on that
23:29:44 <talltyler> Yes, I discovered that 🙂
23:30:04 <talltyler> I have stopped writing code, design needs to happen first 😄
23:30:22 <frosch123> Consist templates or whatever they are called may fix all of that though
23:31:07 <talltyler> Template replace? I've used it in JGRPP, it's not a magic bullet 🙂
continue to next day ⏵
