IRC logs for #openttd on OFTC at 2024-02-28
⏴ go to previous day
00:01:11 <_glx_> anyway the special handling is from the time without docking tiles, it's probably not needed now
00:01:35 <peter1138> They can, yes, but that doesn't change the available track bits.
00:01:45 <_glx_> it's when the only way to detect the dock was to bump it
00:16:57 <peter1138> I think it's meant to make the ship arrive and not change direction as it reaches the dock -- it limits track bits to the current ship direction if that track bit is available.
00:17:35 <peter1138> Not sure if that's a work around for bumping, or just to make it look nicer.
00:54:00 <belajalilija> What needs my approval exactly
00:54:18 <belajalilija> The kiosk car thing?
00:57:40 <johnfranklin> belajalilija: Extend vehicle life (remember some have only 8 years)
00:58:54 <belajalilija> I’ll ask meja and brick
01:02:10 <belajalilija> Aside from agreeing what vehicles to draw I largely want to leave brickblock and meja alone
01:03:53 <belajalilija> I think the way we write the code should be consistent and the art style
01:04:22 <belajalilija> But i don’t expect either of them to write all the little notes i do
01:09:40 <belajalilija> Theres only 2 ways in which i will fuck with their work
01:11:38 <belajalilija> 1 it is a good time to do a release but their stuff isn’t ready and they cant be rushed, in such case I’ll disable the vehicle in the code for the bananas release, I already plan to do this with some of my stuff
01:12:58 <belajalilija> 2 they leave the project and i get an urge to redraw something they have already worked on, in such case I’ll all a param to enable old/new sprites so their work isnt lost, whichever they prefer
01:15:05 <belajalilija> I think av8 has a param like that
01:16:39 <belajalilija> belajalilija: And even if i do this I’ll still aim to keep their versions up to date in terms of liveries
02:02:33 *** herms has quit IRC (Quit: bye)
03:01:12 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:54:05 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:56:11 *** gnu_jj_ has joined #openttd
03:59:36 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:05:51 *** D-HUND is now known as debdog
06:20:01 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:36:47 <kuhnovic> xarick: Well I'm not the one to decide if you should PR or not. But I don't see what problem you have solved here tbh. I agree with peter1138: why do we need to bother with a special case?
07:30:31 *** HerzogDeXtEr has joined #openttd
08:40:02 *** SigHunter has joined #openttd
08:49:29 <peter1138> Shall I do my favourite test? How did TTD behave...
08:51:24 <belajalilija> TTD, wasn’t there a limit of 80 vehicles per type?
08:51:32 <belajalilija> Let’s bring that back
08:51:37 <belajalilija> Hard coded limit
08:58:02 <ahyangyi> Why do rail/road/tram types have only 2 random bits
08:58:33 <ahyangyi> they don't have triggers, and the random bits are derived from locations -- seems there's no computational burden to provide a few extra bits?
08:59:05 <ahyangyi> nor is there any savegame size or compatibility concerns
09:07:46 <peter1138> Next you'll be asking why it isn't a proper hash function.
09:31:20 <andythenorth> peter1138: there wasn't a mac version, so that's a feature we could drop? 😛
09:31:56 <peter1138> "Is this a regression?"
09:39:17 <ahyangyi> peter1138: Well, I won't ask that, though getting direct access to X/Y values would help
09:39:28 <ahyangyi> After which one can use whatever "proper" hash function they like
09:40:30 <ahyangyi> So this question actually has two parts:
09:40:44 <ahyangyi> 1. can we add access to X/Y coordinates
09:40:59 <ahyangyi> 2. if 1 isn't going to happen, can we extend a few random bits
09:42:16 <peter1138> Can we add truly random data?
09:42:31 <peter1138> Although that would really wind up certain people 😄
09:42:51 <ahyangyi> Truly random data means save format changes, bigger saves and other side effects
09:42:55 <peter1138> No reason, just pondering.
09:42:58 <ahyangyi> which I'm not asking for
09:44:03 <locosage> hmmm `X Error of failed request: BadValue (integer parameter out of range for operation)`
09:44:10 <peter1138> None of that (other than bigger saves due to actually storing random data for no reason) is true 🙂
09:44:17 <locosage> I had that before but in 13.4 I can fix that with `-v sdl`, not in 14.0
09:45:14 <ahyangyi> peter1138: I doubt people will like that saving and loading a game and seeing their roads change their look-and-feel
09:46:03 <ahyangyi> Of course if you add truly random data that's **not** used anywhere, that's another story...
09:57:18 *** gwyd4016 has joined #openttd
09:57:18 <gwyd4016> With the new TTF default font, NewGRFs that modify individual font sprites get ignored unless the old style sprite font setting is enabled, is this the desired behaviour? Can this setting be passed on to NewGRFs that want to modify sprite fonts so they can throw an error?
09:57:20 <peter1138> ahyangyi: Anyway the answer to this question is: nobody has had a need to increase the number of random bits and submitted a PR to change it.
09:57:56 <peter1138> What do NewGRFs do with individual characters?
09:58:08 <gwyd4016> Somewhat silly things
09:58:13 <gwyd4016> Replace them with icons
09:58:21 <peter1138> Throwing an error based on a user setting is not a particularly good idea.
09:58:55 <gwyd4016> Or at least a warning, some NewGRFs will self disable with incorrect configs
09:58:57 <peter1138> That setting can be changed at any time.
09:59:09 <gwyd4016> That is a good point
09:59:20 <gwyd4016> I guess this is more readme content than needing a warning
10:04:08 <peter1138> They also won't work for people using CJK languages.
10:07:43 <peter1138> How many different string-based icons are people useing...
10:12:00 <reldred> Changing fonts in OTTD has been around a long time, and have hardly been niche, a grf to replace characters with symbols is a pretty niche use.
10:13:22 <peter1138> But as a feature, it could be supported with a dedicated private-use area.
10:13:41 <peter1138> And hope that different NewGRFs don't use the same codepoints 😄
10:15:06 <peter1138> Doesn't help the size disparity issue though, but maybe SVG sprites could help there.
10:21:36 <kuhnovic> Do we have a function to generate a random bit? I need to generate a random Trackdir from TrackdirBits
10:23:26 <_zephyris> Hmm, I coded contextual substitutions to replace `{train}` with the train symbol etc... I wonder if I ever _removed_ that
10:25:46 <peter1138> You mean the literal text `{train}`?
10:26:06 <peter1138> Nice for testing at least 🙂
10:29:17 <peter1138> Oh yes, for SVG you wanted a sprite sheet. Not sure how that should work.
10:35:14 <peter1138> (Either split before embedding into GRF, or split within OpenTTD)
10:36:58 <ahyangyi> peter1138: Yep, hence the question here, what way of implementation is the most likely to get accepted?
10:37:50 <ahyangyi> I don't feel like delving into openttd source code for 20 hours only to submit a PR that gets refused because that's something people dislike
10:40:02 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
10:40:37 <ahyangyi> As long as there are no objections, I think I can go ahead and increase the bits
10:42:33 <_zephyris> peter1138: Split on grf encode, surely
10:42:41 <peter1138> I'll save you 20 hours. It's very near the top of newgrf_railtype.cpp/newgrf_roadtype.cpp.
10:42:54 <_zephyris> That's how sprite sheets work!
10:43:00 <peter1138> _zephyris: Okay, then it's nothing to do with me 😉
10:43:16 <ahyangyi> That's if I just increase the bits
10:43:35 <ahyangyi> Not to deal with various slippery slope questions and alternative implementation suggestions
10:45:07 <peter1138> The main reason not to expose tile xy and allow authors to define their own custom hash is hypothetical (as in nobody has tested it) performance issues.
10:45:58 <andythenorth> os the x and y for snow? 😛
10:46:17 <ahyangyi> Considering that native C is going to be faster than any potential hash function implemented with switches
10:46:41 <ahyangyi> you have convinced me that increasing random bits has its benefits regardless of what will happen to the callbacks in the future
10:46:45 <_zephyris> So deliberately just expose a simple pseudo-random like `(x + y * w) % prime`?
10:47:56 <peter1138> I would think the current CountBits() system could be replaced with a decent simple hash. And I would not worry about the bits changing from the previous system, it's just not that important.
10:47:59 <_zephyris> peter1138: Doesn't get to a useable solution though 🙂 A very post-14 problem though
10:48:13 <peter1138> I can make OpenTTD do it.
10:48:42 <peter1138> _zephyris: I can make OpenTTD do it, but it means it has to evaluate everything that isn't drawn too, so not ideal.
10:49:38 <_zephyris> So a grfcodec/nml problem then, is there any major issue there?
10:49:39 *** ChanServ sets mode: +v tokai
10:49:57 <peter1138> They will need to implement an SVG parser, and know how to crop every SVG.
10:50:07 <peter1138> So it's not exactly non-trivial.
10:50:21 <peter1138> So it's not exactly trivial.
10:51:11 <_zephyris> How's it actually encoded for ottd use then, as an SVG string?
10:51:31 <peter1138> Yes, it's literally the SVG file embedded into the GRF.
10:52:04 <peter1138> There are binary formats that could be used but that's another dependency.
10:52:12 <_zephyris> Maybe spritesheets aren't worth the effort 😉
10:52:28 <_zephyris> Memory usage presumably isn't an issue, SVGs are comparable to small bitmaps
10:53:00 <peter1138> SVGs can be larger, but they're only in memory while they're being converted to a bitmap.
10:53:17 <_zephyris> Yeah, a _proper_ cropping is hard.
10:53:26 <peter1138> They are rendered to a bitmap sprite when first used, just like normal sprites are loaded from file when first used.
10:54:44 <_zephyris> Thinking more broadly, you'd want to restrict the SVG features in the ottd svgs
10:55:01 <peter1138> They are "restricted" by what nanosvg supports currently.
10:55:17 <_zephyris> Which is good, and well-defined
10:55:30 <_zephyris> So pre-processing svgs (relatively) intelligently makes sense
10:55:34 <peter1138> This does make it pretty hard to make "textures".
10:55:52 <peter1138> It's good for icons and things but not ideal for say a ground sprite.
10:56:20 <_zephyris> Well, I'd argue this is a design doc problem
10:56:32 <peter1138> Might be fine for BonkyGFX though.
10:56:46 <_zephyris> It's not aiming to replace bitmaps, so design the spec to make it complementary
10:57:40 <peter1138> I managed to cobble together a rudimentary company-colour rectangle modelled after the TTD company-colour rectangle by overlaying various gradients in different forms. But it's not very good.
10:57:50 <peter1138> But also, I'm handwriting these SVGs, hehe.
10:58:42 <_zephyris> Man, hand-writing svg gradients...
10:59:34 <_zephyris> What would be useful for testing?
10:59:35 <peter1138> Well, there's a bug in nanosvg's handling of gradient coordinates which doesn't help.
11:00:55 <peter1138> (It treats unqualified coordinates as pixels when they're meant to be fractional)
11:01:11 <peter1138> I have a repo full of the icons I've made so far.
11:01:54 <peter1138> tvg download is 200MB. That's not very friendly.
11:03:02 <peter1138> I'm going to ignore that 😄
11:03:26 <peter1138> There was a tiny google-designed format too, so that's probably already been cancelled.
11:03:32 <reldred> woo! finally got shipping notif for my uconsole 😄
11:04:04 <reldred> only been... *checks notes* thirteen months since I ordered it
11:04:21 <reldred> Yeah it comes running raspbian with openttd already pre-installed apparently.
11:04:41 <reldred> gonna hafta compile jgrpp though
11:11:39 <peter1138> Raspbian CI target when? Heh
11:12:20 <reldred> I asked JGR about it and he said no thanks
11:17:14 <_zephyris> peter1138: Did you get a decent strategy for the 8bpp/mask behaviour?
11:17:32 <ajmiles> Is there a standard way the devs like to mark function arguments as unused to silence compiler warnings?
11:19:47 <ajmiles> OK, I can go with that
11:20:34 <ajmiles> It's a bit verbose/distracting in these interface style headers to have every param marked that way
11:21:47 <peter1138> Either that, or remove the names.
11:22:30 <ajmiles> Yeah, I considered removing the names, but that seems more reasonable if an particular implementation of the VideoDriver elects not to use one rather than the base class just having a virtual 'return' version that doesn't
11:22:58 <ajmiles> I think if I were implementing a new VideoDriver I'd expect to go to videodriver.hpp and see what the args are
11:23:23 <peter1138> Yeah if it's the base classic and therefore the "canonical definition" when go with `[[maybe_unused]]`.
11:23:56 <peter1138> reldred: I don't know what's involved, a quick look is mostly about running CIs *on* ARM...
11:27:20 <xarick> Lol, Square Enix is destroying Tifa
11:29:13 <reldred> is that like that soccer game
11:29:17 <peter1138> You mean this? Looks like a good change to me.
11:29:53 <reldred> that game i care so much about
11:30:21 <peter1138> I played a bit of one on Playstation years ago.
11:30:44 <reldred> we only owned a ps2 in our house because at the time it was the cheapest dvd player we could get
11:31:14 <reldred> it came with a weird version of simpsons hit and run that was like, super different to the actual store bought copy of the game
11:31:17 <xarick> looks like censorship in action
11:31:49 <ajmiles> She's supposed to be 15...
11:32:03 <ajmiles> It's an unusual hill to die on
11:32:50 <reldred> NOOOOOOO WHY CANT I SEE DOWN THE 15YR OLDS TOP NOOOOOOOOO THIS IS CENSORSHIP THIS IS DEMOCRACY MANIFEST
11:33:46 <peter1138> It's better anyway, but definitely better.
11:33:46 <reldred> there's no trains, there's no logistics, there's nothing for my tism to hyperfixate on, and like that you've lost me
11:33:48 <xarick> she's still 15 after all these years?
11:33:56 <ajmiles> It's a flashback scene
11:36:06 <peter1138> Well there are trains in FF 🙂
11:36:16 <xarick> I have no idea what her age is supposed to be. But it's an inconic character that's being changed for the sake of wokeness
11:36:47 <reldred> this is dumb and I don't care, I'm going to bed.
11:37:11 <ajmiles> They haven't changed her in the 'present day' game, so you can still go and look at her when she's not underage if you like
11:38:26 <_jgr_> Seems like a very small teacup to have a storm in to me
11:38:30 <LordAro> i think this is the point where we reach "this is actually off topic, go talk about something else"
11:38:42 <andythenorth> I have never seen that happen before, but I think it just arrived
11:39:16 <xarick> alright, back to ships
11:42:24 <ajmiles> Out of pure interest, what is the limiting factor on maps > 4K today? Is it memory, performance or some inherent "*we've run out of bits!*" limitation?
11:43:11 <kuhnovic> JGRPP does support bigger maps
11:43:31 *** jinks has quit IRC (Remote host closed the connection)
11:43:46 <ajmiles> Yeah, though I'm guessing their non-inclusion in the shipping version of the game speaks to some dissatisfaction with them?
11:44:45 <_jgr_> Most likely they don't want to deal with big reports like "I made the map enormous and now things are a bit slow"
11:45:10 <ajmiles> That wouldn't be like users of free software at all.
11:45:45 <_zephyris> Big maps are too big to be useful in most cases
11:45:50 <_zephyris> Maybe massive multiplayer games?
11:45:59 <_zephyris> But then slowness is even more important
11:47:52 <peter1138> Even 4kx4k is too much.
11:48:32 <ajmiles> I like playing on larger maps with town and industries reduced to at least Low, it gives a more realistic spacing between things
11:49:17 <ajmiles> But then my dreams of connecting up every industry to a single network will never be realised, so small maps are fun too
11:49:53 <peter1138> Huh, we've just passed the 10 year anniversary of 4k maps.
11:50:04 <johnfranklin> Cannot play xUSSR in <2k^2 maps
11:50:31 <peter1138> But yeah, people do play 4kx4k and wonder why the game is so slow because it's an old game from the 90s right...
11:51:58 <peter1138> (There may have been a few supporting commits before that.)
11:51:59 <talltyler> Core devs could make large maps run faster if they didn’t refuse to multi-thread the game
11:52:28 <peter1138> ((Although it doesn't look like it))
11:52:30 <talltyler> Wow they threw out limitations just like that huh
11:52:31 <kuhnovic> And the original game had a map limit of 256x256. That's 1/256th the amount of tiles.
11:54:03 <_jgr_> The tile loop can be made faster without needing to go to multiple threads
11:54:37 <xarick> i have these dock here with a station spread of 64 tiles. ship prefers to make a big detour to the one at the right instead of the other at the left
11:55:40 <andythenorth> why isn't Iron Horse drawing loop multi-threaded? 😛
11:55:49 <andythenorth> can action 3 results desync the game?
11:56:15 <peter1138> Ah the old extreme edge-case...
11:58:11 <kuhnovic> xarick: Is this path a result of checkShipReverse? If so then it's restricted to the HL path, which could explain this.
11:58:26 <xarick> no, it's chooseshiptrack this time
11:58:51 <kuhnovic> Ah ok. And it is restricting or not?
11:59:49 <xarick> not sure, I suspect is related to... the big docking tile area encompassing almost the entire map
12:00:04 <peter1138> I have a patch that multi-threads terrain generation, but it can only use a "normal" perlin noise generator instead of the fast generator that tgp uses. So it has to do more work and ends up not being any faster... 😄
12:01:01 <peter1138> 3 docks all over the map, good design 😄
12:01:04 <ajmiles> I did do a little profiling of the game earlier on a 4K map at a zoomed out level to see where the time was being spent, just to see if there was any low hanging fruit
12:01:19 <peter1138> I didn't even notice the one on the far right at first.
12:01:54 <kuhnovic> Yeah that's definitely going to confuse the PF a bit 😛
12:01:56 <peter1138> Rendering isn't really the issue, it's the sheer amount of tiles to process and everything on it.
12:02:07 <ajmiles> Right, and that's what was showing up
12:02:15 <kuhnovic> My money is on the tile loop
12:02:19 <ajmiles> I just wanted to make sure my stuff wasn't making things worse
12:04:24 <xarick> this is the docking tile area, if not mistaken
12:05:04 <_jgr_> The tile loop cost is linear with map size, so though expensive on big maps is still well-behaved
12:05:33 <xarick> CalcClosestStationTile should really check for tiles that are actually dockable
12:06:46 <peter1138> docking_station only contains actually dockable tiles, but "closest" requires... pathfinding.
12:10:45 <_jgr_> Most of what I've done to make it faster comes down to avoiding cache misses due to unnecessary reads of neighbour tiles
12:11:25 <xarick> yapf_ship_regions does the right checks
12:11:46 <xarick> yapf_ship kind of doesn't
12:12:10 <_jgr_> Water flooding, snow line movement and stuff like that were a problem on that front
12:14:24 <xarick> woah, that's a lot of rivers
12:14:50 <reldred> Rookie numbers. You should see what I did to rivers in JGRPP
12:15:04 <xarick> more rivers than the max allowed num of towns
12:15:10 <kuhnovic> _jgr_: Did this make it back to openttd vanilla?
12:15:16 <reldred> I miss when the setting was called ‘about a few’
12:15:31 <reldred> Now it’s ‘extremely many’
12:16:25 <reldred> That said there are some weird conditions for rivers that slow down generation and prevent creating some nice chained river systems
12:16:52 <_jgr_> kuhnovic: No, it increases code size/complexity, and is less important when vanilla is capped at 4kx4k
12:17:46 <xarick> there is a bug in the river generation related to terraform, it caused stalls. The stalls no longer happen in master, but the rivers end up disconnected
12:19:12 <xarick> hmm... GetBestOpenNode
12:19:42 <xarick> Kuhnovic the way you made this work, adding the origin points as actual destinations...
12:20:23 <xarick> there are 3 very distant regions as origin points
12:20:31 <xarick> they're not even neighbours
12:21:24 <kuhnovic> They will all "grow their own path" towards the ship position. Whoever gets there first (based on cost) wins.
12:22:08 <peter1138> Also why is this on 4x :S
12:22:09 <kuhnovic> That's too many rivers then 😛
12:22:59 <peter1138> Nice, 100ms per tick just for world ticks... in the scenario editor, with no towns and no industries.
12:23:08 <peter1138> What's JGRPP's max size...
12:27:28 <xarick> from the high lvl pf standpoint, the closest region is the one to the right
12:28:02 <xarick> it's 3 regions, vs 4 to the left vs 5 to the south
12:28:18 <xarick> but the closest is the one to the left in my opinion
12:30:51 <kuhnovic> Yup, but the high level pathfinder is making the decision, not your opinion 😛
12:32:19 <kuhnovic> This is a good example of the trade offs that have to be made when using a HL pathfinder. You will end up with situations that lead to suboptimal paths, simply because you ignore terrain details at the high level.
12:40:22 <merni> peter1138: 16k x 16k, or 1 million x 266
12:40:54 <merni> I doubt anyone actually uses the 1 million though lol
12:45:01 <peter1138> TGP failed, my map is completely water 😄
12:45:04 <ajmiles> The scrolling would be... pain
12:45:15 <merni> JGRPP has more zoom-out levels
12:47:32 <_jgr_> The absolute maximum size is not all that useful for actual play, but people kept asking for it and it was not hard to bump the number
12:48:28 <merni> I play 8k and I'm not surprised if people asked for 16k
12:56:28 <peter1138> Trying to play with as if the scale is larger means towns are all tiny. And station catchment is becomes too small.
12:56:59 <peter1138> "This rail station has parking spaces, but they drive in from 4 tiles away" is a bit silly 😄
12:59:04 <_jgr_> There is a setting to increase the catchment radius
13:07:25 <peter1138> _zephyris: No, not yet.
13:18:09 *** jinks has quit IRC (Remote host closed the connection)
13:30:05 <kuhnovic> Ugh, I've discovered a bug deep in YAPF...
13:33:04 <ajmiles> Save that for after he's fixed it 😄
13:34:44 <kuhnovic> Well bug, or "failure by design", that can de debated. A* should stop when the destination node is the best tile on the open list. YAPF instead stops when it adds the destination node to the open list. But there might be a better path to that destination that's yet to be added. And I have such a case.
13:35:55 <kuhnovic> Oh man, I'd love to fix it, but I'm afraid I might break something. YAPF is such a beast.
13:37:49 <ajmiles> I'm about to test the optimisation where I draw the entire world and UI in one draw call instead of one per sprite. Already had some fun GPU hangs getting here
13:38:35 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
13:39:40 *** SigHunter has joined #openttd
13:43:10 <xarick> really strange, it wants to pathfind to exactly where it is
13:43:39 <xarick> the docking tile area is not v->dest_tile
13:44:25 <xarick> 1st attempt fails then, the 2nd attempt is called
13:45:26 <kuhnovic> Attach the debug and step into YAPF. That's the only way to really see what's going on.
13:48:47 <xarick> i wish there was a better way to visualize the failed path
13:50:57 <xarick> in this situation the first attempt wasn't supposed to fail
13:51:39 <xarick> so i wanted to visualise what the heck it did before it failed
13:52:51 <xarick> what neighbours what path it tried, etc..
14:14:01 <xarick> managed to get something
14:14:14 <xarick> this is what it did before it failed, lol
14:17:06 <xarick> it really wants to pathfind to itself
14:23:24 <xarick> a massive docking tile area is the culprit
14:24:19 <xarick> destination tile is done via CalcClosestStationTile, and the closest tile is exactly where the ship is atm
14:24:29 <peter1138> kuhnovic: Affecting rail and road pathfinding too?
14:42:28 *** gelignite has joined #openttd
14:47:23 <kuhnovic> peter1138: Yup, all YAPF variants are affected
14:55:36 <peter1138> Okay, so while multi-stop docks probably didn't help, they were modelled on the existing ways of handling that, so not directly my fault 😉
14:57:39 <xarick> excelent coding skills
14:58:49 <xarick> solved the problem right away!
14:59:16 <xarick> totally ignores the high level pf
14:59:25 <xarick> and goes for the closest
14:59:51 <peter1138> Which works until the closest is not reachable.
15:00:07 <peter1138> (Or is a longer path than one slightly further away)
15:02:48 <kuhnovic> I vaguely remember somebody complaining about how as-the-crow-flies distance was bad 😛
15:03:22 <xarick> i could make it do a yapf call to each docking tile
15:03:53 <kuhnovic> peter1138: This. Fixed the edge case, broke the general case. The typical edge case whack-a-mole.
15:04:22 <kuhnovic> xarick: And absolutely murder the performance in the process 😆
15:05:03 <xarick> maybe it's possible to add multiple destinations
15:05:15 <xarick> not sure how yapf accepts that
15:05:56 <xarick> or do as Kuhnovic does... add multiple origins
15:06:15 <peter1138> `std::vector<TileIndex> docking_tiles` could be stored with the station if it is actually necessary for pathfinding (and performance) but whether it really helps is another matter.
15:08:18 <kuhnovic> Yapf can work with multiple destinations, but calculating the heuristic (the estimate) becomes more difficult. Which destination are you going to estimate to? An average of all destinations?
15:09:11 <xarick> it would estimate to each
15:09:25 <xarick> and return the shortest estimate, maybe
15:09:33 <kuhnovic> That was one of the reasons I went for a reverse search for water regions. That way you have one "destination": the ship
15:10:54 <kuhnovic> xarick: That would probably work, but you might end up doing lots of calculations if you have many destination tiles. It doesn't scale well.
15:13:01 <kuhnovic> It might become so significant that it's better to just forget about the estimate and set it to 0. That turns A* into Dijkstra. But now i'm just speculating, measure before you make such choices.
15:45:16 <ajmiles> One draw call working! And it's 10x faster for heavy frames than it was before.
15:46:17 <ajmiles> 10x faster for the GPU. Need to measure what the CPU perf uplift was from not having to issue so many draws
15:49:02 *** Wormnest has joined #openttd
15:51:56 <ajmiles> 60x faster the CPU. Good news too
15:56:20 <Eddi|zuHause> so it's now 600x faster overall. that's how that works. right? :p
15:58:21 <ajmiles> Then you take that 600 and square it
16:04:01 <xarick> this just in! I invented multiple destinations for yapf! let's see how broken it iss now
16:05:29 <xarick> SetIntermediateDestination might be a problem yet, I need to see what happens for now
16:14:46 <xarick> it wasn't too hard, I thought it would be harder to implement
16:15:41 <_glx_> if you have multiple destination just reverse and switch to multiple sources
16:16:33 <_glx_> ships are not affected by any one way limitations so A->B and B->A are the same
16:29:13 <peter1138> Nice, an AI updated to not use buoys.
16:32:41 <peter1138> Hmm, it's still placed some buoys, but not using them.
16:37:43 <ajmiles> I'm trying to figure out what a safe maximum is for the number of sprites that the renderer will try and draw in one frame and I'm already up to 1 million
16:40:28 <peter1138> Potentially a lot 🙂
16:42:37 <ajmiles> I probably need to implement some sort of growable buffer or I'm just going to have to pick a big number
16:43:36 <j_n> ajmiles: it feels cursed seeing a game as old as OpenTTD being rendered using triangles
16:44:44 <ajmiles> Save that until I start raytracing water reflections 🙂
16:45:17 <ajmiles> I was joking as I didn't think it'd be possible, now I'm not so sure...
16:46:10 <andythenorth> peter1138: you have a patch for that?
16:46:29 <andythenorth> TBH, it would be better as a flow value, signed byte
16:46:48 <andythenorth> 127 or -127 are untraversable in one direction
16:46:54 <andythenorth> everything else is a multiplier to speed
16:54:55 *** xertov has quit IRC (Quit: User went offline on Discord a while ago)
16:59:54 <kuhnovic> peter1138: This would instantly break the water region pathfinder haha
17:14:12 <_glx_> river slopes are one way, but untraversable anyway
17:14:38 <peter1138> So they're not one-way, they're no-way.
17:15:00 <_glx_> they could be handled as one way
17:15:13 <LordAro> but with a chance of crashing the boat
17:19:45 <xarick> wondering if i just add the intermediate dest into the mix
17:23:58 <peter1138> Well. This morning it looked like it was going to be raining all day and most of the evening. Now it's... just a little bit.
17:24:46 <peter1138> I've broken that icon 😄
17:40:59 <ajmiles> There's something wrong with the FPS counter in the game, as it disagrees with both my own FPS counter also NVIDIA's
17:41:07 <ajmiles> 6500 is the right number
17:43:53 <LordAro> release the magic smokoe
17:43:59 <ajmiles> It would be amusing if OpenTTD were the game to melt it
17:46:03 <xarick> teach me how to make a list of docking_tiles on stations
17:46:17 <xarick> TileArea but not really TileArea
17:46:26 <_glx_> it's already stored in the station IIRC
17:47:05 <xarick> not the real docking tiles only
17:49:12 <_glx_> for (TileIndex tile : st->docking_station) {
17:49:12 <_glx_> if (IsDockingTile(tile)) /* Add to your list */;
17:50:18 <xarick> i wanted a quick access NOSAVE cache kind of list on each station
17:50:33 <xarick> or i'd have to calculate that for every pathfinder call
17:51:32 <peter1138> BitmapTileArea is also a thing, but that is actually larger in your extreme test case.
17:53:56 <peter1138> Also it's a `std::vector<bool>` which is quite... "hmm" now.
17:55:35 <LordAro> unless you're doing weird things with it anyway
17:57:12 <andythenorth> rivers with flow
17:57:30 <andythenorth> then we do rivertypes
17:57:36 <andythenorth> then we have conveyors and pipes
17:58:15 <andythenorth> v14 not feature frozen yet, right?
17:58:15 <LordAro> if it's not accurately modelling fluid dynamics then it's not getting in
17:58:44 <andythenorth> I did fluid dynamics in my civil engineering degree
17:59:24 <andythenorth> although there is CFD analysis for e.g. aviation, civil engineering relies very largely on empirical models and established priors
17:59:49 <andythenorth> so stuff like 'turbulent flow' is just considered 'complex' and there's a rule of thumb for how many tonnes of concrete might be needed, and what shape
17:59:59 <andythenorth> then you build a scale model in a sandbox and run water
18:02:23 <_glx_> 14 is branched so only bug fixes
18:04:09 <andythenorth> peter1138: tile erosion rate?
18:04:16 <andythenorth> hmm Erosion GS maybe?
18:04:30 <peter1138> Tractive Effort Coefficient of sand erosion.
18:05:36 <andythenorth> disappearing docks?
18:18:37 <locosage> there was some article about a way to make rivers pretty well
18:20:34 <_jgr_> There was the rainfall river generator patch from the forums which did some kind of flow simulation
18:20:41 <_jgr_> Though "fast" it was not
18:21:15 <locosage> I have a generator based on that article on citymania and it's fast enough
18:21:39 <locosage> but couldn't quite figure all the quirks so they sometimes flow upward 😅
18:23:35 <_jgr_> For what it's worth I did a whole bunch of fluid dynamics and related stuff in my degree as well, and have used exactly 0 of it since then
18:25:28 <locosage> what i did isn't really simulating fluid dynamics or even erosion afaict
18:28:13 <locosage> third method, it generates river network and then terrain that matches it
18:35:44 <DorpsGek> - Update: Translations from eints (by translators)
18:47:05 <xarick> BitmapTileArea isn't too smart, how do I add tiles to it?
18:48:07 <_zephyris> I did a game dev forum and git poke for the terrain generators recently. Lots of nice and fast stuff, but the challenge would be ensuring rivers aren't on diagonal slopes afaict
18:50:10 <ahyangyi> _zephyris: Yep, I thought about importing river data, and "fix" the slopes later
18:50:24 <_zephyris> Yes, except for all of the corner cases where terraforming for one river tile prevents another one
18:50:48 <ahyangyi> And also when there are two choices, which one to take
18:50:49 <_zephyris> Could probably iterate from the river mouth upstream across all rivers?
18:51:02 <_zephyris> And give up when the route won't work
18:51:18 <_zephyris> That'd do rivers till the terrain gets too steep
18:51:19 <ahyangyi> Probably an iterative process not unlike a BFS should work
18:54:45 <peter1138> xarick: I wasn't suggesting you use that.
18:55:22 <xarick> uhm, what was I supposed to do?
18:55:29 <ahyangyi> Question: A station has at most 8 tile types, right?
19:01:21 <kuhnovic> _zephyris: When river pathfinder?
19:03:06 <_zephyris> Well... I think you're the man for the job!
19:03:19 <andythenorth> when water region support for industry tile varact 2? 😛
19:08:00 <andythenorth> ports in tiny lakes
19:08:18 <andythenorth> obviously now I *try* to get a map with one, I can't 😛
19:08:26 <andythenorth> but usually they are frequent
19:09:20 <andythenorth> oh, 'smooth' landscape gen doesn't do many lakes, but 'rough' does
19:09:30 <andythenorth> ok got one on the first 'rough' map
19:10:01 <_jgr_> You should be able to check tiles up to a distance of 15 in each axis
19:10:06 <peter1138> Ah you want "connected to large amount of water"
19:10:40 <peter1138> "Connected to N regions" would be more useful probably.
19:11:58 <andythenorth> _jgr_: I could do a tile walk
19:12:32 <andythenorth> there are lots of cases where that will fail in 3 directions, but the water area is actually large
19:12:44 <andythenorth> odd-shaped coasts
19:12:50 <andythenorth> islands, isthmuses etc
19:15:48 <peter1138> kuhnovic: Do you think there's an easy way to query for connected water regions without involving path finding?
19:15:58 <peter1138> Or relatively easy way, I should say.
19:30:35 <andythenorth> water regions are fixed size?
19:32:01 <frosch123> number of towns reachable by water or road?
19:41:24 <ahyangyi> Good point, perhaps the new pathfinding algorithm could finally provide the solution for the "port in a small lake" problem
19:42:18 <ahyangyi> Or, could we relax the requirements and get a rough number?
19:43:00 <ahyangyi> If that helps with performance
19:49:53 <xarick> why doesn't BitmapTileArea initializes automatically
19:54:46 <xarick> I fail at understanding how this works
19:55:42 <peter1138> Don't you just need a list of docking tiles?
19:59:12 <peter1138> start with `std::vector<TileIndex>` then
20:13:18 <peter1138> Okay, what rail/road/tram type GRFs use random bits?
20:19:09 <xarick> nice, that was much easier
20:21:11 <_glx_> BTW BitmapTileArea is a TileArea with extra stuff, so you still need to Add() first before using SetTile() or ClrTile()
20:22:11 <ahyangyi> peter1138: ASUB ||Ahyangyi's secret unreleased bullshit™||
20:22:26 <peter1138> BTA::Initialize() is used to cover the entire area first.
20:50:56 <peter1138> Okay so I guess the rail/road type random bit 'hash' comes from tree_cmd.cpp;530
20:51:48 <peter1138> BTA is built on top of a TileArea with some specific use-cases.
20:52:37 <_glx_> it has TileArea methods, but they are not usable it seems as they don't update the bitmap
20:52:38 <peter1138> Calling `Add()` on it will actually most likely not work.
20:53:11 <_glx_> Add() will increase the area, but the internal data will be broken
20:55:24 <peter1138> Not my finest work, but it does work.
21:05:13 <xarick> kuhnovic, there is a problemo
21:06:25 <xarick> regarding 12181, caching the whole path till the end might not be a good idea
21:07:10 <xarick> that red line is 100% cached
21:08:16 <xarick> in this situation, it won't even get back on track
21:08:40 *** gelignite has quit IRC (Quit: Stay safe!)
21:09:07 <xarick> the black squares is where the hpf thought would be a good path
21:09:29 <peter1138> Does it have a path to the destination?
21:11:12 <_glx_> and both high and low use the same destination ?
21:11:38 <xarick> the high pf was given the regions for each docking tile
21:12:22 <xarick> the low pf was given the docking tiles, 8 tiles
21:12:51 <xarick> maybe it's a me problem
21:13:04 <xarick> I'll create a clean branch about the work I'm doing
21:13:12 <xarick> but it won't mix well with 12181
21:19:36 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:21:22 *** thelounge345 has joined #openttd
21:39:46 <xarick> unsure about the cache
21:43:56 <andythenorth> limit approaches very ` nmlc info: Concurrent spritegroups: 238/256 ("generated/iron-horse.nml", line 641965)`
21:46:41 <kuhnovic> peter1138: There certainly is. Look in the water_regions.h header. I don't have the code here in front of me right now, but I believe the function is called VisitWaterRegionNeigbours.
21:50:53 <kuhnovic> xarick: So why is this bad? The LL PF disagrees with the HL PF and finds a better path to a better destination tile. It's a pretty radical difference in this case, but I don't see what's wrong with it. Unexpected maybe.
21:52:06 <xarick> it wasn't supposed to cache the last few tiles near the target
21:52:45 <kuhnovic> PeterNviaGitHub: I did actually hit a breakpoint on that case recently, when a ship was entering a depot. Not sure if it matters, but I thought I should mention it.
21:53:27 <peter1138> Yeah, when entering a depot it'll be following the path into the depot anyway.
21:53:50 <kuhnovic> Yeah it doesn't have a lot of choice
21:54:13 <peter1138> This special-case makes it ignore the pathfinder when just for the (old) docking tile. It isn't really necessary.
21:54:46 <peter1138> As glx said, probably something to do with bumping the dock. But we've since implemented ship rotation since then as well.
21:55:08 <peter1138> Eh, missing words again 😦
21:55:11 <xarick> hmm peter1138, that fix might not work for depot
21:55:21 <kuhnovic> Oh you mentioned it in the description. I need to read before I open my mouth.
21:56:39 <xarick> i guess it's fine, but the problem is that it's gonna flag the ship as lost?
21:56:44 <kuhnovic> I'm actually looking into that ship rotation part. I might be able to combine checkShipReverse and chooseShipTrack into one function and hopefully simplify things further.
21:58:00 <peter1138> Why would the ship be lost?
21:59:05 <xarick> there is an issue with how yapf works, when the next tile is the destination, a path won't be found, but now since there's the high lvl pf, I guess it's found from there?
21:59:53 <peter1138> Ships definitely still enter depots without being lost...
22:02:37 <xarick> interesting, now I'm confused
22:02:48 <kuhnovic> xarick: This might actually be related to the yapf-bug I discovered today. The is-at-destination-check is done in a weird way. But I need to spend some time digging deep into the details of yapf.
22:02:58 <kuhnovic> And I haven't had time yet
22:04:07 <xarick> that was what the special case was handling
22:04:16 <xarick> and now I can't trigger it, ... lol
22:06:11 <peter1138> Finish those pixels.
22:09:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:12:19 <xarick> I have no idea why it works now 🙂
22:14:06 <andythenorth> definitely naptime 🙂
22:14:12 <andythenorth> all the pixels can wait
22:14:34 <xarick> it was pathfinding to itself
22:15:19 <kuhnovic> Are you sure those weren't because of your local changes?
22:15:41 <kuhnovic> You were trying out all kinds of things
22:16:18 <xarick> in this place it was tile == CalcClosestStationTile
22:16:54 <andythenorth> should I play OpenTTD?
22:16:58 <kuhnovic> Well that must have been the issue
22:17:51 <xarick> the huge docking tile area was always the next tile, and in this situation the pathfinder was always failing to find a path
22:19:28 <xarick> it's not much different than peters approach, now a ship next tile can be the ship depot entry, and it magically finds a path
22:25:14 *** sinas128 has joined #openttd
22:25:24 <sinas128> take some time off horsing, enjoy the game
22:39:04 <reldred> Horsey horsey horsey, I’m waiting for some higher speed horses in my game. It’s 1972.
22:40:31 <xarick> okay, I don't even need
22:40:54 <xarick> master is sufficient to expose the issue
22:44:17 <andythenorth> reldred: change your daylength speed 😛
22:47:24 <xarick> you will notice it will fail to find a path on `attempt 0`. `v->tile == m_destTile`
22:53:57 <_glx_> I accidentally triggered the NOT_REACHED() from game thread and it failed to generate screenshot (_screen was nullptr)
22:54:38 <reldred> andythenorth: no, I will make it longer >:3
22:54:42 <_glx_> but this NOT_REACHED is annoying, I can't see how I triggered the crash
22:55:19 <reldred> I'm actually enjoying spending longer lengths of real world time moving through each generation in Horse
22:56:07 <xarick> gonna create an issue, I think it's important enough to warrant it
22:56:38 <reldred> also, plz merge my allignments PR, cooking my own version every release is tedious 😛
22:56:58 <reldred> I need to do another horse+nars game
22:59:40 <peter1138> I keep putting tabs in vs code when hitting a break point... who came up with the idea of removing shift as fast forward?
22:59:48 <andythenorth> I set the Horse alignment per peter1138 bug reports 😛
22:59:54 <andythenorth> "others are wrong"
23:01:10 <reldred> nah I'm just stirring shit again, I need to get around to making that new-nars
23:01:16 <andythenorth> you reported Horse offsets were wrong twice 😛
23:01:34 <andythenorth> so I fixed them, then I fixed the fix
23:03:41 <_glx_> GSStrings are so annoying
23:05:42 *** tokai|noir has joined #openttd
23:05:42 *** ChanServ sets mode: +v tokai|noir
23:12:37 *** tokai has quit IRC (Ping timeout: 480 seconds)
23:19:50 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:27:07 <_glx_> so it's just one hill formed GS string (STR_UNDEFINED is from a workaround adding dummy extra parameters)
23:54:36 <xarick> the game works in mysterious ways
23:55:19 <xarick> fast = from the station cache
23:56:00 <xarick> slow = from the station other cache + testing for actual ship destination docking tile
23:57:18 <xarick> im going with the slow
continue to next day ⏵
