IRC logs for #openttd on OFTC at 2025-06-10
⏴ go to previous day
00:04:39 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:05:51 *** Flygon has quit IRC (Read error: Connection reset by peer)
00:11:07 *** WormnestAndroid has joined #openttd
00:31:32 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:35:43 *** WormnestAndroid has joined #openttd
02:01:37 *** Wormnest has joined #openttd
02:42:49 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:47:53 *** Wormnest has quit IRC (Quit: Leaving)
03:14:30 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:18:18 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:18:21 *** WormnestAndroid has joined #openttd
03:18:30 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:18:31 *** WormnestAndroid has joined #openttd
03:18:34 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:18:46 *** WormnestAndroid has joined #openttd
03:56:17 *** D-HUND is now known as debdog
04:42:20 <DorpsGek> - Update: Translations from eints (by translators)
06:10:00 <andythenorth> alternative idea: call slow functions less
06:10:08 <andythenorth> hmm that's probably not the metagame being played eh
06:58:19 <andythenorth> I cut about 4 seconds off a Horse method by not calling it recursively
06:58:29 <andythenorth> it was a 5s total run time
07:00:06 <andythenorth> maybe I could have asked Python to make my method faster?
07:09:36 *** SigHunter has joined #openttd
07:24:36 <peter1138[d]> Just throw caches at it.
08:11:49 *** mindlesstux has joined #openttd
08:13:50 <andythenorth> my cache updating method is slow now 😦
09:03:39 <LordAro> right, brief panic over
09:03:53 <LordAro> SATA power connector on my NAS's boot drive fell out
09:21:06 <peter1138[d]> Aren't they usually quite snug?
09:31:05 <LordAro> probably a combination of "right near the edge of the case so was probably disturbed while taking the (3-sided) panel off" and "is a molex adapter"
09:55:51 <xarick> someone dared to buy an Intel gpu
09:57:15 <xarick> is the 40bpp for HDR monitors or...
10:04:08 <peter1138[d]> No, it's an internal detail to do with animation.
10:11:18 <xarick> OrderBackup also create OrderLists...
10:39:43 <xarick> v->orders can be both nullptr and empty
10:40:03 *** akimoto has joined #openttd
10:47:38 <peter1138[d]> v->orders can only be a pointer to an OrderList.
10:47:55 <peter1138[d]> The OrderList can be empty, but v->orders itself cannot be empty.
10:50:29 *** WormnestAndroid has quit IRC (Remote host closed the connection)
10:50:42 *** WormnestAndroid has joined #openttd
10:58:12 *** akimoto has quit IRC (Remote host closed the connection)
11:09:25 <xarick> what triggers orderbackup creation
11:13:40 *** Flygon has quit IRC (Read error: Connection reset by peer)
11:13:44 <xarick> orderbackup not working as I expect...
11:13:56 <xarick> what are the conditions for it?
11:17:50 <xarick> well order back up works in 15.0-beta2, but not on master
11:18:24 <xarick> assuming I did replicate the same steps
11:19:18 <xarick> 1. pick vehicle with orders
11:19:25 <xarick> 2. manual send to depot
11:19:41 <xarick> 3. open depot window, sell vehicle
11:20:16 <xarick> result: orders are restored in 15.0-beta2, but not on master
11:21:05 <_glx_> This area has been rewritten recently
11:23:06 <peter1138[d]> I probably broke it. Let's wait for James to make an issue :p
12:05:15 <peter1138[d]> (I see the cause.)
12:07:30 <peter1138[d]> That's just my spare innertubes.
12:54:45 <xarick> can different vehicle types share orders
12:58:02 <peter1138[d]> And even then, not always. Articulated road vehicles have extra rules.
12:58:16 <peter1138[d]> Also, helicopters and aircraft are the same type by might not share orders.
12:59:06 <peter1138[d]> I mean, that is the issue I did ask for, but the tone of "oh just add the old way back, that'll be easiest"... 🙂
12:59:27 <xarick> hmm okay, instead of caching OrderLists, I'm gonna cache the first_shared of each OrderList
13:00:43 <xarick> but I still wanted to group this by vehicle type
13:07:00 <xarick> `Company::Get(v->owner)->order_lists[v->type].push_back(this->first_shared);`
13:08:45 <xarick> `Company::Get(this->first_shared->owner)->order_lists[this->first_shared->type].push_back(this->first_shared);`
13:10:38 <_glx_> oh of course it's not possible to check order backup with regression AI because AI don't backup
13:24:35 <_glx_> ok for some weird reason front->orders is null
13:27:52 <xarick> I can't seem to trigger it
13:33:30 <_glx_> hmm weird, `v->orders = new OrderList(std::move(new_o), v);` returned nullptr
13:35:47 <_glx_> I don't understand, debugger says it's nullptr, but it's not
13:36:33 <LordAro> compiler doing some reordering
13:36:35 <_glx_> that's annoyingly not helpful
13:39:09 <peter1138[d]> _glx_: if you're trying to diagnose why orders are not backed up, need need. I'll fix it in a couple of hours.
13:39:14 <peter1138[d]> (It's really easy, and really stupid.)
13:39:58 <_glx_> yes I know you'll do it, but it's fun to see debugger doing weird things
13:40:21 <peter1138[d]> As LordAro says, compiler reordering, not the debugger 🙂
13:40:57 <peter1138[d]> LordAro, I'm not used to 100 mile rides any more 😭
13:41:08 <peter1138[d]> I think I know the answer to that.
13:41:30 <peter1138[d]> Also call it 160km cos it sounds more.
13:42:42 <LordAro> peter1138[d]: if it helps, me neither
13:43:01 <peter1138[d]> You're used to much more 🙂
13:43:07 <LordAro> i'm having a couple of weeks off
13:55:49 <LordAro> peter1138[d]: my arbitrary strava number is looking very sad compared to the previous two years
13:57:13 <xarick> I can't reach this piece of code, I tried many things already
14:00:39 <_glx_> this function is called when OrderList is created
14:03:00 <xarick> how can there be previous shared vehicles though if it's just created
14:04:24 <_glx_> when cloning another vehicle maybe
14:05:12 <xarick> OrderList isn't initiated
14:10:09 <peter1138[d]> Ah the old "it's only a game" excuse for poor security.
14:31:32 <peter1138[d]> Maybe someone will make a GameScript based password authentication system... 😮
14:35:24 *** efessel has joined #openttd
14:35:24 <efessel> I was thinking for a long time it would be nice to link game players to external auth systems such as discord using oauth. Then various group level permissions could be managed, including joining companies.
14:35:24 <efessel> But that's a far out idea.
14:45:04 <_glx_> peter1138[d]: improving admin port might be better
14:45:47 <peter1138[d]> I was joking based on that one time someone did try to use Story Page stuff for admin functions...
14:45:54 <_glx_> it already receives some info about client, but not the public key
14:46:05 <efessel> Can I please ask what's currently insecure about shared key for company access?
14:46:45 <efessel> I understand it needs to be sent as-is without hash correct? Isn't the connection encrypted now?
14:57:59 <efessel> Yes, ok just the PR I had linked in the discussion - yes saving passwords has always been a minor issue
15:05:06 <peter1138[d]> The devs are not going to add the old password system back into the game, so there is no point trying to argue for that.
15:07:07 *** Wormnest has joined #openttd
15:09:53 <efessel> Just discussing. Not sure why this is completely off the table without alternative solutions. It could be an optional feature too.
15:11:08 <xarick> some military parade in my city
15:12:14 <xarick> insurmountable noise of those jets in the air, feels like we're in a war zone
15:14:15 <xarick> I don't like the message they're bringing this time...
15:15:31 *** kuhnovic has joined #openttd
15:15:58 <xarick> if only I could be deaf today
15:16:21 <xarick> but the ground shakes with the noise anyway
15:40:03 *** f_ is now known as funderscore
15:55:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:55:50 *** WormnestAndroid has joined #openttd
16:02:45 <peter1138[d]> Hmm, do I have time to cycle.
16:41:04 <efessel> peter1138[d]: Can always make time
17:15:32 <cu-kai> _jgr_: are you aware of a potential bug with path signals not applying routefinding restrictions/rules if they are placed at a depot exit
17:17:13 <cu-kai> well, it seems to be a bit hit and miss, from my experiements anyway. you cannot deny exit to a depot so it seems, but reserving a slot is possible (and happens on a seemingly random basis and not in the order trains are queued up to exit said depot)
17:19:47 <_jgr_> If you want to hold a train in the depot you'd probably want to use wait at path signal for reservation ending here instead
17:20:10 <_jgr_> Depots do not have any queuing behaviour
17:20:40 <cu-kai> i'll try that, thank you
17:22:20 <cu-kai> that solves that problem at least, but not the problem of slots being given to "not the next train" leaving the depot
17:23:23 <cu-kai> perhaps that is the bug instead, since this works fine if i place the signal away from the depot (but then i risk a standoff with a train attempting to enter said depot)
17:23:51 <cu-kai> this is a massively first world problem and i can work around it by using a loop by the depot i guess
17:24:16 <_jgr_> Perhaps you want the path end acquire or wait mode?
17:24:47 <_jgr_> I'm not really sure what layout you are trying to do here
17:25:25 <cu-kai> how do you mean? i'd like a train leaving the depot to immediately acquire a slot upon leaving the depot. the current behaviour is: the train is waiting to leave the depot and is given the slot, but another train leaves the depot in front of it
17:26:31 <cu-kai> it wasn't really a layout per-se, it was an experiment
17:27:40 <_jgr_> I can't say I've ever tried to do something like that with a depot, but I can have a look a bit later
17:28:31 <cu-kai> i can provide two saves if you like
17:29:16 <_jgr_> That'd be helpful, thanks
17:29:22 <cu-kai> np, give me a few minutes
17:36:31 <peter1138[d]> (Or is it duplicating something that we already have?)
17:53:16 <cu-kai> there are two saves, one demonstrates the bug, one demonstrates the workaround
17:53:26 <cu-kai> well, what i perceive to be a bug, at least
17:53:34 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
17:53:35 <cu-kai> feel free to tell me if i'm doing something wrong
17:56:22 <cu-kai> i recommend to enable fast forward when testing, then make all the trains leave the depot at the same time
18:03:32 <_jgr_> Train 2's current order is such that it doesn't match the next order condition in the if and so is not required to acquire the slot to leave
18:04:03 <_jgr_> The slot occupancy test does not make sense because any train which is in the slot can never leave
18:04:46 <_jgr_> The condition should probably be modified to whether the slot is occupied and this vehicle is not a member
18:05:01 <cu-kai> i see, so why does it work if the signal is not next to the depot?
18:05:17 <cu-kai> in that situation, this works as i designed it
18:12:52 <_jgr_> This is probably because there is some slightly special behaviour for reservations from depots, so I'd expect that a nominally successful 0 length reservation would result in the train not actually leaving
18:13:11 <_jgr_> I'd have to check that more thoroughly later
18:14:22 <cu-kai> sure, thank you for your help and time with this.
18:14:42 <cu-kai> also i wasn't able to prevent the train from trying to route towards the one-way path signal
18:15:02 <_jgr_> It's becuase you're using a pathfinder deny, so that the train can then not see the destination at all
18:15:24 <cu-kai> even with wait at path signal, i couldn't prevent this, so i removed all rules from the signal by the depot in save 2
18:15:35 <cu-kai> however, when using wait at path signal, they would never proceed forward into Dalreoch
18:15:40 <cu-kai> even if the slot was empty
18:15:54 <_jgr_> For this pattern of holding the train in the depot you might find it easier to just use a conditional order with a timetable wait in the depot
18:16:26 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:16:28 <cu-kai> sure, thanks. defeats the object of the slot experiment, but i do understand.
18:16:34 <cu-kai> [19:15:35] <cu-kai> however, when using wait at path signal, they would never proceed forward into Dalreoch
18:16:56 <cu-kai> with regards to this, try changing the "deny" into a "wait at path signal" at the signal between the tunnels, heading towards Dalreoch
18:17:02 <cu-kai> the trains will become stuck at this signal
18:17:46 <_jgr_> Let me make some modifications, to show you what I mean
18:28:56 <cu-kai> ah, i see, so you did the slot rules at the other end
18:29:53 <cu-kai> also with this setup, it seems you do not need any rules on the signal between the tunnels, towards Dalreoch
18:30:03 <cu-kai> since you already check for path reservation at the next signal
18:30:16 <cu-kai> thx, i did not think to do it this way
18:31:16 *** WormnestAndroid has joined #openttd
19:00:15 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:02:47 *** WormnestAndroid has joined #openttd
19:12:17 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:12:37 *** WormnestAndroid has joined #openttd
19:14:04 <peter1138[d]> Hmm, well, that brake pad was a bit low.
19:30:12 <peter1138[d]> Resin pads so they wear first.
19:47:22 <peter1138[d]> Hmm, pretty sure there's no liquid sealant left in that tyre 😮
19:47:31 <peter1138[d]> Bikes eh? Who'd...
19:54:33 <squirejames> (from Discus, rather than Disk, from Diskette)
20:09:29 <peter1138[d]> Are you saying that a 5
20:19:13 <squirejames> Sufficient numbers thereof
20:19:16 <peter1138[d]> Hmm, I probably ought to put it all away.
20:48:48 <andythenorth> my advice is: don't touch disks or discs after a steep descent
20:52:04 *** gelignite has joined #openttd
21:33:59 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:37:16 <xarick> solo companies, doing better
21:38:40 <xarick> gotta try 14 companies now
21:56:55 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:57:56 <LordAro> andythenorth: can confirm
21:59:19 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:01:34 *** tokai|noir has joined #openttd
22:01:34 *** ChanServ sets mode: +v tokai|noir
22:03:41 <xarick> 3 cache structures now
22:04:19 <xarick> a cache for first shared vehicles per type per company
22:04:31 <xarick> a cache for free wagons per company
22:05:25 <xarick> a cache for vehicles per type per group per company
22:05:30 *** WormnestAndroid has joined #openttd
22:07:49 <xarick> i need to test 14 coronas, it doesn't use shared orders...
22:08:34 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:20:51 <efessel> Always hear you're not supposed to touch the disc to avoid contaminating with oil, not sure how important that is in practice. But probably doesn't matter if it's super hot. Why would you touch it then lol
22:21:42 <LordAro> if your hands are greasy enough to make a difference you should probably see someone about it
22:30:02 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:34:19 *** herms has quit IRC (Quit: Ping timeout (120 seconds))
22:37:00 *** WormnestAndroid has joined #openttd
continue to next day ⏵
