IRC logs for #openttd on OFTC at 2023-03-01
⏴ go to previous day
01:10:13 *** tokai|noir has joined #openttd
01:10:13 *** ChanServ sets mode: +v tokai|noir
01:17:12 *** tokai has quit IRC (Ping timeout: 480 seconds)
01:35:07 <kamnet> "As time told, people mostly used NRT to create eyecandy road types, which wasn't what it was created for in the first place. "
01:35:07 <kamnet> It wasn't? Since when?
01:41:21 <audigexJon> Sounds like bollocks to me - what possible use would we have had for 64 road types if not for eyecandy?
01:48:48 <kamnet> I get what he's trying to say - NRT should be focused on giving unique roads for unique vehicles to drive on rather than a wider variety of vehicles. But that's still going to be eyecandy for many players.
02:04:15 *** herms has quit IRC (Quit: bye)
02:10:56 <Eddi|zuHause> that's not really how roads work
02:12:58 <Eddi|zuHause> and "neighbourhood roads, where trucks can't go, excepf if they have a delivery point inside that town zone" isn't really relevant for gameplay
03:02:29 *** Wormnest has quit IRC (Quit: Leaving)
03:36:39 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:45:19 *** D-HUND is now known as debdog
03:59:27 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
03:59:32 *** WormnestAndroid has joined #openttd
04:07:37 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
04:08:26 *** WormnestAndroid has joined #openttd
04:17:43 *** TROILUS4 has joined #openttd
04:19:17 *** TROILUS has quit IRC (Remote host closed the connection)
04:19:17 *** TROILUS4 is now known as TROILUS
05:34:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:36:21 *** WormnestAndroid has joined #openttd
06:53:51 <andythenorth> NRT was created to remove catenary from tram tracks
06:54:13 <andythenorth> it was predictable that 16 types wouldn't be enough
06:54:20 <andythenorth> so it was extended to 64
06:54:21 <Eddi|zuHause> that's one of the more obvious uses,
06:54:31 <andythenorth> which we also predicted wouldn't be enough
06:54:57 <andythenorth> but it's a lot easier to justify "more than 64 is silly" compared to "16 is enough"
06:55:21 <andythenorth> more than 64 the UI has very diminished usability
06:55:58 <andythenorth> eddi you need more sleep 😛
06:56:02 <andythenorth> I checked your timestamps
06:57:04 <Eddi|zuHause> it's been... problematic recently
07:08:05 *** WormnestAndroid has quit IRC (Remote host closed the connection)
07:30:31 *** sla_ro|master has joined #openttd
07:42:11 *** sla_ro|master has quit IRC ()
07:42:37 <kamnet> 64 may well indeed be enough especially in regard to the UI. It's already a mess with trains. At least a patch which sorts them alphabetically is somewhat helpful.
07:43:50 *** sla_ro|master has joined #openttd
08:33:31 *** test123 has joined #openttd
08:33:45 *** test123 has quit IRC (Remote host closed the connection)
08:37:49 *** J_likes_cake has joined #openttd
08:37:49 <J_likes_cake> Wanted to ask if there is a reason for the A* pathfinders to only use Manhattan distance as it's heuristic? I don't really know if it's an optimal heuristic
08:42:41 <LordAro> where is all this riscv64 stuff coming from all of a sudden?
08:49:24 <LordAro> J_likes_cake: you can't do any diagonal movements, so i don't see why manhattan wouldn't be optimal
08:49:41 <LordAro> (i.e. x,y to x+1,y+1)
08:51:09 <J_likes_cake> I'm very sorry if this is dumb, because I don't know the game at all. I'm just interested in path finders
08:51:09 <J_likes_cake> Are there possibilities that some paths are blocked?
08:57:31 <J_likes_cake> Ok disregard I'm dumb and switching stuff
08:57:31 <J_likes_cake> Basically I just wanted to know if there is a reason for not using more sophisticated heuristics and what the standard in games is anyway
08:57:31 <J_likes_cake> Because I only know some stuff about general search outside of games
08:57:31 <J_likes_cake> (Hope I'm not spammy)
08:58:38 <dP> everything but roadvehs can move diagonally though
09:00:16 <dP> I don't think pathfinder in openttd is very much optimized
09:00:25 <dP> no one wants to touch it 😅
09:02:32 <J_likes_cake> I'm kind of interested in contributing to something open source and maybe I will just try some basic heuristic and see if there are any improvements at all and if it would be worth it
09:02:32 <J_likes_cake> I also should maybe play the game first lol
09:03:21 <LordAro> dP: it can move diagonally, but it still has to go through a manhattan-distance number of tiles to move diagonally
09:03:52 <LordAro> aircraft & ships can just move diagonally, this is true
09:04:12 <LordAro> but aircraft don't use a pathfinder at all
09:05:49 <dP> LordAro: no, it's 192 units for straight piece and 128 for diagonal
09:06:08 <dP> actually, I remember pf taking that into account as well
09:06:19 <dP> though it was a bit wrong as it assumed euclidean distance
09:07:18 <dP> dP: though, number of tiles is manhattan
09:07:37 <dP> but pf heuristic should use distance not number of tiles, no?
09:09:36 <petern> Kuhnovic: Friendly poke, did you get anywhere with this? 😄
09:11:15 <dP> that ship pf though is kinda weird...
09:15:27 <dP> inventing new algorithms in a well-researched field is usually not the way to go
09:25:09 <J_likes_cake> Yeah there's nothing to reinvent
09:25:09 <J_likes_cake> Abstractions Heuristics or LM-Cut perform well enough
09:25:09 <J_likes_cake> The question is just if the computational overhead is worth it for path finding and I have no clue about that
09:55:39 <petern> We need it to be at least more computationally efficient than it already is 🙂
10:30:27 <LordAro> that seem reasonable to everyone else?
10:31:43 <petern> No, I would have left it closed.
10:33:26 <petern> We have a solution, our CI/CD tells us it works. If you're running RISC-V you only care about performance because performance isn't great. Everything I search for comes up with its unbeatable performance... per watt.
10:40:51 <pickpacket> What's the most computationally intensive part of the game? Is it the pathfinding?
10:42:17 <petern> Depends what's going on. It can be, enough that we add explicit caching of things.
10:45:05 <pickpacket> what else is in the running for the "computationally intensive part" award? :D
10:46:18 <JGR> Vehicle movement and all the associated bookkeeping is usually significant
10:46:19 <pickpacket> I've only played with an AI once. It started building airports everywhere almost at once, which really killed all the joy for me
10:47:07 <JGR> If you're looking to do performance improvement work, I'd really recommend doing some profiling/performance measurements
10:47:21 <JGR> You're working in the dark otherwise
10:47:30 <pickpacket> I'm not. I'm just curious :)
10:48:51 <pickpacket> As everyone else I'm already swamped in projects and life, and the codebase looks like it may have a steep learning curve for someone who's hardly seen C++ before
10:49:15 <pickpacket> also I spend a significant part of my spare time just *playing* the game...
10:51:33 <dP> pickpacket: water being water 😅
10:51:56 <JGR> That is also fairly simple to fix
10:52:24 <pickpacket> dP: why is that heavy+
10:52:32 <dP> JGR: did you fix it in jgrpp?
10:53:25 <dP> pickpacket: it tries to flood stuff and isn't very effecient about it
10:54:20 <JGR> Caching whether a water tile's 4 neighbours are already water and not doing any flooding checks in that case makes the problem go away
10:54:51 <dP> you mean you just add a bit to map array?
10:55:28 <JGR> Yes, water is mostly unused bits, might as well do something useful with them
10:55:47 <pickpacket> almost lunch time now... 5 more minutes
10:56:26 <dP> yeah, need to be careful with updating it though when terraforming
10:57:00 <pickpacket> JGR: is that something you can easily upstream or would it be simpler to re-implement (by someone else, I assume)?
10:58:13 <dP> actually, it's better to cache not 4 waters neigbours but just whether there was terra change
10:58:24 <dP> you don't need to constantly flood shores as well
11:00:31 <JGR> That has rather more edge cases to deal with
11:00:37 <petern> LordAro, looks like they invented a benchmark that takes into account power consumption too 🙂
11:01:18 <LordAro> that can be important
11:01:25 <LordAro> probably not if you're playing a game though
11:01:57 <dP> JGR: idk, seems about the same to me, you still need to update on terra and propagate on flood
11:14:50 <JGR> pickpacket: I could, but it's only noticeable on large maps, not sure there'd be much interest to merge it
11:21:44 *** WormnestAndroid has joined #openttd
11:29:35 <dP> I remember master hellish did a long viewers game on 4k map with lots of water
11:29:48 <dP> had to restart it mid-stream partially because of the water
11:30:17 <dP> as it eats significant chunk of the game loop that could've been used for other stuff
11:31:22 <dP> probably wouldn't have last the whole way even with water fixes though
11:42:03 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
11:48:13 <Xarick> who's a group expert? vehicles have a v->group. Can that group be set to DEFAULT_GROUP, ALL_GROUP, INVALID_GROUP or NEW_GROUP? Asking which ones they can have when saved
11:48:41 <Xarick> because I'm increasing number of groups and need to do conversion
11:49:57 <pickpacket> JGR: what counts as a large map?
11:55:37 <JGR> pickpacket: The bigger the map, the more shaving tiny bits off the tile loop is useful. There isn't a hard threshold.
11:59:38 *** gelignite has joined #openttd
12:26:53 <Xarick> oops, something failed
12:27:30 <Xarick> the groups are gone in my branch
12:30:58 <Xarick> they're back, forgot to convert parent group
12:51:28 *** azubieta608226 has joined #openttd
12:53:16 *** Mek_ has quit IRC (Read error: Connection reset by peer)
12:53:27 *** Hirundo has quit IRC (Ping timeout: 480 seconds)
12:53:45 *** Hirundo has joined #openttd
12:53:52 *** Osai has quit IRC (Ping timeout: 480 seconds)
12:54:27 *** V453000 has quit IRC (Ping timeout: 480 seconds)
12:54:55 *** V453000 has joined #openttd
12:55:02 *** avdg has quit IRC (Ping timeout: 480 seconds)
12:55:22 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
12:55:37 *** Hazzard has joined #openttd
12:57:07 *** azubieta60822 has quit IRC (Ping timeout: 480 seconds)
13:07:27 *** Osai has quit IRC (Ping timeout: 480 seconds)
13:07:32 *** avdg has quit IRC (Ping timeout: 480 seconds)
13:11:46 <Xarick> scrollbar can't have more than ~65k items listed
13:13:06 <Xarick> so i thought, a max of 64k groups per company, how do i do this?
13:13:18 <Xarick> and a max of 64k stations per company
13:13:40 <Xarick> or someone should rebase 8006
13:14:08 <petern> It needs more work than just a rebase, that's why it stalled.
13:14:58 <petern> Most players don't even use groups (it's a bit hidden) so allowing more than 64k is... "okay but why"
13:15:39 <Xarick> there's just no other reason i can give
13:33:25 <FLHerne> pickpacket: at least on a slow computer, industry tiles doing ridiculously complicated va2 chains to render their sprites can really hit performance if there are a few on screen
13:34:04 <FLHerne> not looking at anyone in particular whose name begins with 'a' :p
13:34:31 <FLHerne> I think JGR has some patch to improve caching of those too, unless it got upstreamed and I missed it
13:37:52 <JGR> I do have various changes related to that, some of them aimed at those industry sets
13:38:43 <JGR> Mostly they are probably too complicated/non-obvious to upstream
13:42:06 <FLHerne> upstream does a lot of complicated and non-obvious stuff already
14:04:02 <Xarick> how are groups deleted, where is the code?
14:04:15 <Xarick> delete g; where does this go?
14:11:32 <Xarick> there is no Group::~Group()
14:11:43 <glx[d]> ah no we rewritten delete for pool items
14:12:17 <Xarick> i wanna do something on deletion
14:12:34 <Xarick> subtract 1 to num_groups of a company
14:12:42 <Xarick> it's a company property im creating
14:13:15 <LordAro> needless to say, something specific to groups should not be added to that
14:13:35 <glx[d]> yeah I just link to how we delete
14:17:06 <glx[d]> you probably need to implement Group::~Group()
14:18:38 <glx[d]> like it's done for BaseStation or Order
14:30:16 <Xarick> 64k groups per company
14:30:55 <Xarick> when a company buys another, how are the groups handled?
14:40:27 <petern> They company gets all the groups.
14:43:36 <petern> Xarick: Problem with that is when groups are cleaned up you then need to check if g->owner exists, then get the company, then update the number of groups. For very group.
14:45:55 <petern> Must better to just do it in the few places where groups are expected to be added/deleted.
14:49:52 <glx[d]> another option could be to cache the counts at pool level in a generic way
15:11:52 *** WormnestAndroid has joined #openttd
15:13:19 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:13:29 *** WormnestAndroid has joined #openttd
15:40:38 <Xarick> need to do a num_stations too
15:43:10 <Xarick> buoys don't count as stations, but oil rigs do, right?
15:43:19 <Xarick> for station listing purposes?
15:44:37 <Xarick> how am I dealing with oil rigs
15:52:16 <Xarick> this means, in the current openttd
15:52:42 <Xarick> i could have a list with more than 65535 items, given enough oil rings and stations?
15:52:54 <Xarick> ah, no, the hard cap is 64k, that includes neutral
16:14:23 *** TROILUS has quit IRC (Read error: Connection reset by peer)
16:14:38 *** TROILUS has joined #openttd
16:44:46 *** HerzogDeXtEr has joined #openttd
17:15:38 *** gelignite has quit IRC (Read error: Connection reset by peer)
17:23:04 *** ChanServ sets mode: +v tokai
17:29:06 *** GeorgeVB has joined #openttd
17:29:06 <GeorgeVB> Could someone help with
17:29:06 <GeorgeVB> For some reason, ELRL trains, like from BRTrains2, are shown in non electrified depots, but I can't understand what makes them to act this way
17:30:04 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
17:33:00 *** Wormnest has joined #openttd
17:46:30 <audigexJon> BRTrains track definitions are a shitshow, so it's possible it's a GRF bug not an OpenTTD one?
17:47:19 <audigexJon> Is it all BRTrains ELRL units showing up, or just some? If just some, which ones?
17:48:01 <GeorgeVB> Dutch trains set does not have an issue
17:48:17 <GeorgeVB> I didn't check others
17:48:53 <audigexJon> Also the screenshot doesn't seem to show BRTrains2 - those are RUKTS units - am I missing something there?
17:49:46 <GeorgeVB> I didn't check other sets yet, BRtrains2 was just the first one to reproduce
17:54:16 <audigexJon> Looks like a bug with the track set, not OpenTTD itself - this conversation probably belongs in Discord channel #add-on-development or somewhere specific to the track set
18:03:00 <andythenorth> petern: I had sandwich spread on toast
18:04:33 <andythenorth> FLHerne: I wonder about caching the result to permanent storage and only updating it occasionally
18:04:47 <andythenorth> FIRS smacks down fps in my experience
18:04:59 <andythenorth> for that exact case of a few industries on the screen
18:05:39 <andythenorth> it doesn't need to check snowline, fence state, terrain etc on every drawing tick
18:14:39 <Xarick> what's the difference between BaseStation and Station
18:15:26 <Xarick> do I iterate BaseStation or Station, to count the number of station indexes?
18:15:38 <andythenorth> what kind of station is it?
18:16:07 <Xarick> trying to get who owns the station index
18:22:57 <Xarick> number of stations cache mismatch
18:23:57 <Xarick> where is the station deleted
18:25:49 <Xarick> ah, StationHandleBigTick
18:30:12 <Xarick> this dude delays the removal of the station
18:31:00 <Xarick> i build a station, num_stations counter goes up by 1
18:31:17 <Xarick> i remove station, the sign remains, I am still the owner of the sign
18:31:39 <Xarick> then after a while, the sign is about to poof, but the num_stations cache is already wrong
18:32:32 <Xarick> num_stations on the cache is 1, but it's actually 0 when i count the num of stations i own
18:33:58 <Rubidium> because your code's logic is flawed?
18:37:01 <Xarick> okay i think i found the problem
18:39:19 <Xarick> this->owner instead of _current_company
18:40:34 <glx[d]> _current_company is only usable at command level I think
18:44:00 <Xarick> okay, i partially solved the scrollbar, no more than 64k groups per company, nor 64k stations per company
18:44:25 <Xarick> the only problem is the neutral stations being counted in the station list window
18:45:26 <Xarick> that would surpass the limit of 64k
18:45:48 <Xarick> scrollbar bug will occur when there's 65535 or more items
18:46:19 <Xarick> 1535 different oil rigs is probably not gonna happen
18:46:38 <Xarick> but if someone tries enough, it can still crash the scrollbar
18:47:37 <DorpsGek> - Update: Translations from eints (by translators)
18:53:37 <Xarick> i still didn't do this one
18:55:56 <Xarick> and i guess that's the last one
19:04:47 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:52:15 <Xarick> how do I distinguish between a station and a waypoint
20:06:21 <Xarick> BaseStation was the wrong one, :p
20:09:50 <Xarick> interesting, i can't re-use a station of a ghost station of another company
20:10:01 <Xarick> i always thought I could
20:14:21 *** TROILUS has quit IRC (Read error: Connection reset by peer)
20:14:22 *** TROILUS3 has joined #openttd
20:14:23 *** TROILUS3 is now known as TROILUS
20:15:17 <glx[d]> BaseStation is the base for Station and Waypoint
20:22:24 <Xarick> my goodness, OrderList is everywhere
20:26:04 <Xarick> afterload, order_sl, saveload, station_sl, vehicle_sl, waypoint_sl
20:33:43 <LordAro> orders are pretty fundamental to the game, as it turns out
21:26:23 *** geli has quit IRC (Quit: Stay safe!)
21:30:51 <glx[d]> why would you change anything here ?
21:42:54 <Xarick> i don't need to do any saveload conversion for OrderList?
21:44:52 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:47:24 <glx[d]> anyway I can see the main issue with orders, we can have over 1M vehicles, but only 64000 order lists
21:47:53 *** Extrems has quit IRC (Ping timeout: 480 seconds)
21:50:10 <Xarick> i can't find the function for this
21:51:13 <glx[d]> seems it doesn't exist
21:53:45 <pickpacket> 1M vehicles… 64k order lists… has anyone ever been even close to these linits?
21:55:55 <glx[d]> but yeah 1M vehicles is more than enough 🙂
21:57:11 <glx[d]> though 64k order lists means only 64k head vehicles if not sharing orders
22:11:02 <glx[d]> stupid me it's not a fix, it's a cleanup
22:11:09 <petern> Huh, oddly quiet tonight.
22:13:32 <glx[d]> auto cancel is so nice
22:16:59 <Xarick> how do i test desync stuff?
22:17:29 <Xarick> i added some cache checking for the num_stations, num_groups in openttd.cpp
22:17:42 <Xarick> but i wanna test it in a release build, which is faster
22:18:13 *** sla_ro|master has quit IRC ()
22:20:12 <glx[d]> just read the code, it needs _debug_desync_level > 1
22:20:55 <Xarick> hmm where is it outputting the text
22:21:57 <glx[d]> start with -d desync=2
22:27:30 <Xarick> thanks, dang it's slow
22:27:50 <glx[d]> yes it checks every tick
22:28:06 <glx[d]> that's why it's not enabled by default
22:30:43 <Xarick> ah, i see commands-out.log
22:31:00 <Xarick> this is gonna fill quickly with 14 AIs
22:31:28 <glx[d]> that's the command log, not the desync check
22:45:24 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:52:10 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:52:19 <Xarick> wow codeQL is useful indeed
22:52:31 <Xarick> pointed errors i missed
22:56:16 <Xarick> lol regression failing because of invalid station id being different
23:30:05 *** Extrems has joined #openttd
continue to next day ⏵
