IRC logs for #openttd on OFTC at 2024-10-11
โด go to previous day
02:15:24 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:15:56 *** D-HUND is now known as debdog
03:00:08 *** herms61 has quit IRC (Quit: bye)
03:01:04 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:05:06 *** herms61 has joined #openttd
05:12:08 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:17:13 <kuhnovic> xarick: Is that a 70K ship save confirmed test, or just the save provided with the issue? ๐
07:23:52 <truebrain> _glx_: Yeah, the transition of a latest tag always takes a bit of time. On the plus side, it often is only a few days, so we might have that going for us? ๐
09:17:35 <kuhnovic> Hmm. Tried another PF performance improvement, which made it 176 times slower. Oops ๐
09:18:13 <peter1138> Is your "10% faster" one, or something else? ๐
09:20:50 <kuhnovic> Haha no, this is unrelated
09:23:51 <kuhnovic> I now tried to combine the open and closed maps into one map, and just mark a node as closed using a boolean. But I guess I broke some logic in the process, the PF is adding way too many nodes now.
09:26:14 <truebrain> that is also an unusual thing to do, in PFs? ๐
09:26:39 <truebrain> owh, maps, not nodes?
09:50:16 <xarick> oh I didn't test the 70k save, i probably should
10:21:56 <xarick> I found something really strange about the query item
10:23:17 <xarick> PrintWaterRegionDebugInfo
10:23:28 <xarick> it runs a GetUpdatedWaterRegion
10:23:47 <xarick> this doesn't seem to be synced in case of multiplayer
10:24:04 <xarick> wondering if it can cause desyncs...
10:39:52 <_jgr_> It does not need to be synced for multiplayer, it's not a problem
10:59:57 <kuhnovic> truebrain: Yeah, these keep track of which nodes are already opened / closed, so that they aren't added over and over again. I guess I broke the "not over and over again"-part...
11:01:39 <truebrain> Yeah, in most PFs you want different lists for them, as their access patterns are rather different ๐ your closed list is only an: is this node on the list ๐
11:15:31 <kuhnovic> My counterargument to that would be that you need to do a lookup anyway. If the node is already closed then we can skip it, but if it's already open then we need to do additional checking to see the new candidate node is better than the existing one. Right now this is done in two separate lookups using two separate maps. I think we can use one if we keep track of the closed/open state in the node
11:16:24 <kuhnovic> But I haven't been able to do that without breaking everything else ๐
11:17:37 <xarick> are you trying to make the pathfinder deal with 90 degrees in a smarter way?
11:18:10 *** akimoto has joined #openttd
11:20:30 <xarick> Reminds me when I was working on my failed double rail track pathfinding for my AI
11:21:35 <xarick> I needed to uniquely identify the various layouts
11:21:50 <xarick> couldn't get around it in an effective manner
11:26:48 <truebrain> kuhnovic: You go against a lot of very well worked out PFs ๐ But that should never stop us from trynig, ofc ๐ Doing these kind of things gives us the most insights ๐
11:30:04 <kuhnovic> Exactly. I like to fool myself into believing I'm the first who came up with this novel idea, and that it's going to improve everything ๐
11:30:46 <kuhnovic> xarick: What is not smart about the current way things are done?
11:31:53 <kuhnovic> I just found a few opportunities to improve the PF by doing fever (relatively expensive) checks. The PF shouldn't behave any different (or smarter)
12:00:13 *** akimoto has quit IRC (Remote host closed the connection)
12:05:12 <peter1138> LordAro, time to resurrect #10623?
12:06:05 <peter1138> (Removal of pathfinder settings)
12:06:15 <LordAro> i did have to look it up
12:10:50 <kuhnovic> Let's un-draft this one
12:12:27 <peter1138> Oops, that was meant to be start review. Oh well.
12:12:38 <kuhnovic> At least it's clear haha
12:12:48 <LordAro> 15 seconds is a good review time
12:13:47 <kuhnovic> Somehow push_back is still my knee-jerk reaction when working with vectors. I spent too long working with C++ 11.
12:13:58 <DorpsGek> [OpenTTD/OpenTTD] aquagnawt opened pull request #12989: Fix OpenTTD#12968, d20df82: Buildings that have rating_decrease_on_removal set to greater than 1000 may now not be removed by the player, unless the magic bulldozer is used. Additionally, added a new bit in the flags to represent the same thing. https://github.com/OpenTTD/OpenTTD/pull/12989
12:14:55 <xarick> GetDepotOrderType oh snap, this is returning bit flags
12:15:02 <LordAro> C++11 is the one that added emplace_back :p
12:16:35 <xarick> it's supposed to use & and ^
12:17:18 <xarick> could this function be renamed? I keep forgetting I'm dealing with bit masking
12:18:51 <peter1138> kuhnovic: Yeah, there's still some lying around ๐
12:19:40 <LordAro> xarick: the return type should tell you this
12:22:33 <peter1138> That means it can only contain that bit.
12:22:48 <peter1138> Or the opposite ๐
12:24:49 <peter1138> Depends what the intention is I guess.,
12:25:10 <peter1138> Some of this would be tidier with HasFlag...
12:26:34 <kuhnovic> It's kind a weird that this is a flag enum to begin with. To me they sound like options that can't coexist
12:26:54 <peter1138> You can have a service-at order though.
12:27:10 <peter1138> Not sure if that's what "servicing limit" means ๐
12:29:08 <kuhnovic> That's the flag that's set when a ship is sent for automatic servicing
12:33:26 <xarick> it's been 4 years, let's look at ships, if they're lost or so
12:34:02 <truebrain> I found a new disaster to add to the game
12:34:21 <truebrain> (currently happening in The Netherlands; trains are delayed)
12:35:13 <_glx_> Ship position looks so wrong
12:35:22 <truebrain> That is because it is wrong.
12:37:10 <_glx_> Wasn't it supposed to go through bottom lane?
12:37:54 <truebrain> For sure it wasn't suppose to be there, while the bridge is where it is
12:38:18 <truebrain> Playing chicken with a bridge, and losing
12:38:26 <_glx_> Yeah of course, but bottom would have been safer
12:39:01 <peter1138> Yeah looks like it went in the wrong hole so the bridge swings towards it instead of away from i.t
12:39:43 <kuhnovic> "Doing a suez canal"
12:39:54 <xarothbrook> That looks a bit like one of xarick's boat-pathfinder-test-cases.
12:40:46 <xarick> found some ships that haven't serviced since 1984, it's 1994
12:40:56 <xarick> depots might really be out of range
12:44:25 <kuhnovic> The depot search range is only 20 tiles. This value might have been kept excessively low to prevent the ship PF from slowing down the game.
12:48:57 <xarick> ships reversing on a lock is a cursed thing
12:49:08 <xarick> im surprised it doesn't crash openttd
12:49:53 <xarick> if it were to do some other, pretty sure it would crash
12:54:35 <_glx_> ship fit in a single tile, everything is fine
12:56:54 *** HerzogDeXtEr has joined #openttd
12:58:24 <xarick> sometimes I wonder why my own pathfinding came up with some weird places for depots
12:58:49 <xarick> it's maybe the interaction with 14 other AIs
13:00:03 <xarick> oh, a limitation of openttd
13:00:13 <xarick> can't place depots on canals owned by others
13:00:26 <xarick> so it goes all the way to build the depot in nowhere
13:03:19 <xarick> and then some other AI builds a path attached to someone else's path
13:03:34 <xarick> and the ships start taking different routes
13:03:48 <xarick> and won't ever be in range of that far-off depot ever again
13:06:59 <ahyangyi> So one part of the game accurately creates what should have been a rare corner case for another part of the game
13:07:16 <peter1138> Just add explicit service-at orders ๐
13:09:02 <xarick> I do, but it's a special version of my AI for testing purposes to test the water regions stuff
13:09:47 <xarick> it doesn't add explicit depot orders
13:10:05 <xarick> relies on automated servicing for it :p
13:17:28 <xarick> oh right, it also doesn't use buoys
13:18:03 <xarick> no buoys made it possible to have 70000 ships, it didn't hit the station limit
13:48:01 <xarick> can someone give meaning to those numbers
13:49:06 <xarick> 8 is something like... middle of the tile, 0xF is tile size or something?
14:02:28 <peter1138> and `& 0xF` is `% TILE_SIZE` but without division (not that compilers won't optimise that)
14:05:08 <xarick> so why weren't it used
14:29:11 <xarick> I'm trying to think of a fix for this, so that it's no longer confusing... this->current_order.GetDepotOrderType() != ODTFB_SERVICE
14:38:37 <xarick> NeedsAutomaticServicing is called from some weird places in aircraft_cmd.cpp
14:38:49 <xarick> compared with the other vehicles
14:43:34 <xarick> I remember having dealt with aircraft automated servicing before...
14:44:11 <peter1138> Because for aircraft the depots are part of the airport.
14:44:23 <peter1138> (Except for the ones that aren't)
14:44:47 <peter1138> For other vehicle types, the depots are always separate.
14:45:44 <xarick> ย Order::GetDepotOrderType returned ODTF_MANUAL (0) OrderDepotTypeFlags
14:46:56 <xarick> so from aircraft_cmd.cpp, it is checking if it needs an autoamtic servicing, but the order type is manual... uhm, i need to refresh my memory
14:47:31 <xarick> I remember dealing with this part and there were issues
14:47:44 <xarick> not sure if they got fixed
14:53:28 <peter1138> Definitely looks incoherent.
14:54:54 *** nielsm has quit IRC (Ping timeout: 480 seconds)
14:58:23 <xarick> if i remember it was something about automatic servicing being cancelled when the intention was to keep it
14:58:41 <xarick> because of a DoCommand
14:59:37 <xarick> the plane lands, and decides while on the strip, whether it goes to servicing or to terminal
15:00:25 <xarick> but if it was already going to servicing before hitting the strip, it would cancel this order due to checking again if it requires servicing
15:02:20 <xarick> not sure what developed from here on, considering this PR was closed
15:12:34 <xarick> nop, bug still present as of master
15:16:37 <xarick> aircraft already has a service at the airport's hangar, and now it is executing this check, which will run the do command which will cancel it
15:17:12 <xarick> switches to not sending
15:17:27 <xarick> the good news is that days are shorter now
15:18:08 <xarick> the other checkifaircraftneedsservicing will re enable it's sending to hangar before the place reaches the end of the strip
15:19:30 *** gelignite has joined #openttd
15:22:04 <soylent_cow[m]> there are some real cool GRFs that add eye candy buildings and things, as objects
15:22:22 <soylent_cow[m]> is there a way to make these object buildings accept and/or generate cargo?
15:25:22 <_pruple> short of recoding them as houses or industries, no
15:57:03 <xarick> how do i look at FS#1891?
15:57:20 <peter1138> it will be github issue 1891 too.
15:57:37 <peter1138> Because truebrain did a top notch job migrating things.
16:00:31 <LordAro> if in doubt, RB probably committed it
16:01:26 <peter1138> So, .io domains right?
16:08:11 <xarick> okay, so that code works
16:08:40 <xarick> ODTFB_PART_OF_ORDERS can never be, because this->HasDepotOrder() was already checked
16:09:01 <xarick> the other option is thus ODTF_MANUAL
16:09:24 <xarick> it's correct, but it's not using bitwise operations ๐ฆ
16:14:23 <xarick> (this->current_order.GetDepotOrderType() & ODTF_MANUAL)
16:15:37 <xarick> !(this->current_order.GetDepotOrderType() & ODTFB_SERVICE)
16:16:59 <xarick> actually ODTF_MANUAL is 0
16:56:04 <xarick> What is prettier? ... and is it worth fixing?
16:56:04 <xarick> `!(this->current_order.GetDepotOrderType() & ODTFB_SERVICE)`
16:56:04 <xarick> `this->current_order.GetDepotOrderType() == ODTF_MANUAL`
16:59:53 <xarick> but ODTF_MANUAL is 0, can't use HasFlag here, I think
17:43:56 <NGC3982> irssi interpreted that emoji as a hilight
17:54:02 <truebrain> peter1138: The third time it has been useful!!! ๐ฎ
18:06:03 <johnfranklin> Fuck, my ebook reader screen cannot be repaired.
18:06:59 <johnfranklin> And pocketbook price level has been doubled compared to two years ago.
18:13:43 <johnfranklin> โฆuntil I found eBay.
18:39:37 <johnfranklin> Oops, the same product is sold half price in Chinese shopping sitesโฆ
18:40:38 <merni> Maybe try actual books? :p
18:41:06 <merni> besides phone screens these days are big enough to function as a halfway decent e-reader
18:42:57 <peter1138> oled vs e-ink though.
18:43:18 <merni> That's true, though I've never used e-ink so I don't know what I'm missing
18:43:34 <merni> I'm more of a real ink person
18:44:00 <merni> aren't some e-readers also oled
18:44:24 <peter1138> It's best not to gatekeep how books should be read.
18:44:34 <peter1138> It's hard enough to get people to read at all.
18:44:36 <johnfranklin> When I first drink it, I didnโt add water. Lol
18:45:22 <johnfranklin> It was very thick, you should add 5x water
18:45:45 <merni> I can't shake the feeling there's a mirror in the middle of that shot even though there obviously isn't ๐ค
18:46:16 <peter1138> Also that's a lot of biscuits.
18:47:28 <andythenorth[d]> I believe it includes jaffa cakes
18:47:37 <andythenorth[d]> error no French Fancies
18:51:19 <johnfranklin> The GBP 315.68 one is sold as CNY 1899.
18:51:39 <peter1138> This is why we just throw everything away and get a new one.
18:51:46 <peter1138> Repair is more expensive than replacement.
18:55:05 <johnfranklin> If I had time, I would try to buy some parts and learn to make one from scratch. Linux system, not Android. Hope it would be cheaper.
18:56:51 *** Flygon has quit IRC (Read error: Connection reset by peer)
19:05:22 <ahyangyi> openttd on an e-ink device?
19:32:29 <peter1138> Heh, a 15th November release would've been fun.
19:33:14 <peter1138> I guess that is TT rather than TTD though. We've got a bit more time.
20:30:47 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
20:43:23 <xarick> oh crap, an assert triggered just now ๐ฆ
20:43:36 <xarick> I thought I was saved from them
20:49:22 <xarick> only triggered 2 years into the game ๐ฆ
20:54:22 <xarick> a ship depot that was previously found suddenly becomes out of range
20:54:52 <xarick> I suspect... docking tile cost variance again
20:58:51 <xarick> theoretically this variance could also affect the path choices regarding intermediate regions
20:59:55 <xarick> it just requires an extraordinary heavily conditioned scenario to cause it to happen
21:11:17 <peter1138> Maybe you want to exclude the docking tile penalty if it's not the same destination station.
21:18:03 <xarick> a ship in a docking tile can affect the path of a ship 5 regions away ๐
21:22:06 <xarick> I don't think I have enough time today
21:27:58 <andythenorth[d]> is it naptime?
21:28:02 <andythenorth[d]> falling asleep
21:44:58 <ian01223> truebrain: there you go
21:51:28 *** tokai|noir has joined #openttd
21:51:28 *** ChanServ sets mode: +v tokai|noir
21:58:19 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:12:11 <peter1138> Mad, an actual wiki PR.
22:13:05 <ian01223> the last one was in june of last year
22:13:14 <peter1138> And a bonus end-of-file change too?
22:19:13 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:22:07 <xarick> the ship in the dock caused this one to turn right
22:22:29 <xarick> causing the path cost to be increased and above 2000 ๐ฆ
22:22:41 <xarick> alright, cyas goodnight
22:29:18 <peter1138> Yeah, the penalty is working.
23:37:30 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day โต
