IRC logs for #openttd on OFTC at 2019-02-18
⏴ go to previous day
00:26:00 <peter1138> Hmm, what happened? So quiet :(
00:26:06 <peter1138> Oh yeah, of course, IRC is dead.
00:27:37 <milek7> i guess most people went to sleep
00:41:29 <peter1138> Damn, can't use that :(
00:47:36 <supermop_Home> IM DESIGNING A DONUT KIOSK
00:48:17 <supermop_Home> rather I designed it, now just annotating some elevations
00:48:32 <supermop_Home> while it renders in rhino in the background
00:59:32 <supermop_Home> 90 minutes into this rendering I see that the espresso machine does not have it's material applied
01:02:01 *** ChanServ sets mode: +v tokai
01:18:07 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: New non-rectangular sparse station catchment area https://git.io/fh5s1
01:32:40 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: New non-rectangular sparse station catchment area https://git.io/fh5HZ
01:46:09 <peter1138> Yay, all checks passed.
02:04:57 <peter1138> Oh, that's why my "git pr" command no longer works... my git version got upgraded and it includes one, but it works differently.
02:07:26 <peter1138> Ah, git-extras was installed.
02:08:25 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5H2
02:23:57 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5HK
02:31:05 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5HD
02:35:13 *** snail_UES_ has joined #openttd
02:36:14 *** Thedarkb-X40 has joined #openttd
03:26:39 <Samu> what have you guys done to zoom?
07:41:06 <peter1138> Nothing to do with having 15 AIs running...
07:57:12 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5dC
08:26:20 *** andythenorth has joined #openttd
08:27:40 <nielsm> I had forgotten all about taking today and tomorrow off work, and had to be reminded by a colleague after turning up at the office
08:30:32 <peter1138> That's like being a kid and turning up to school on a Saturday.
08:37:29 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN merged pull request #7220: Change: Increase maximum number of orders from 64000 to ~16.7m. https://git.io/fhQLh
08:37:56 <peter1138> "If you wish, you can delete your fork of **OpenTTD/OpenTTD**"
08:38:03 <peter1138> Yeah, no, why the heck would I want to do that.
08:42:57 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5d7
08:54:18 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fh5FO
08:54:24 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5F3
09:04:03 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5F8
09:04:54 <peter1138> Oh, the station part of an oil-rig produces cargo? Hmm.
09:05:17 <peter1138> Ah, no, the station part of an oil-rig tries to find a nearby station. Hmm.
09:05:41 <peter1138> Need a back trace to find the caller.
09:05:45 <peter1138> So need debug mode.
09:06:25 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5F0
09:08:56 <peter1138> nielsm, yeah, that test is very worthwhile.
09:09:12 <peter1138> Glad I didn't try it first, as I may not have bothered with the caching stuff.
09:10:33 <nielsm> it sounds like it's actually faster now than originally?
09:10:56 <peter1138> I think it's about the same.
09:11:21 <peter1138> It no longer needs to search the map array for every cargo delivery.
09:14:22 <andythenorth> will it ever be done? o_O
09:16:15 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fh5FP
09:16:46 <peter1138> I think my additional FindStationsAroundTiles() function that takes a nearby list is spurious.
09:17:23 <peter1138> That list has already been catchment checked, so no need to do any looping, just convert from std::set<Station *> to StationList.
09:20:23 <peter1138> In which case, I may not need to call it at all.
09:21:16 <andythenorth> oof been doing Horse 2 since August 2017
09:21:22 <andythenorth> it's probably 'done'
09:21:34 <andythenorth> apart from I haven't drawn all the trains :x
10:48:59 *** andythenorth has joined #openttd
11:14:13 <DorpsGek_II> [OpenTTD/OpenTTD] citymania-org commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5Aj
11:17:49 <_dp_> damn, now I have two github accounts thanks to azure thing
11:18:05 <_dp_> well, might as well switch to this one
11:18:32 <peter1138> Don't be a cunt though, that's my job.
11:19:13 <peter1138> You can suggest better algorithms without implying that what's been suggested is totally worthless.
11:20:09 <_dp_> it's not worthless, it would work fine for random town distribution
11:20:13 <peter1138> It should be obvious that not everybody studies this algorithm stuff, they just scratch an itch.
11:20:25 <_dp_> just what's the point of making several solutions for one problem?
11:20:55 <peter1138> And most people just scratching their itch won't know about the name of some random algorithm that does something efficiently.
11:21:34 <andythenorth> at least include [emoji] :P
11:21:39 <andythenorth> it takes the edge off it
11:21:52 <andythenorth> we have quite a lot of new contributors, and I want them to stay
11:21:56 <peter1138> As you do seem to know, this is rare skill, and it'be nice if in cases like this you could just suggest the algorithms to use without being sarcastic.
11:21:56 <_dp_> andythenorth, right, I totally forgot xD
11:27:04 <_dp_> peter1138, there are just too many spatial structures, you need a complete list of use cases to pick the best one
11:27:29 <_dp_> though k-d tree would probably work just fine for everything
11:28:00 <_dp_> good compromise between speed and simplicity
11:29:23 <_dp_> but anyway finding some spatial library would be even better regardless of what structure it uses
11:48:11 <peter1138> _dp_, sure, but most people don't know *any* of them.
11:48:23 <peter1138> I never studied algorithms, and it shows.
11:48:49 <peter1138> Finding some spatial library is useful if you know you should be looking for a spatial library.
11:51:55 <peter1138> So I'm currently using an unordered_set to maintain a list of station catchment tiles.
11:52:02 <peter1138> What algorithms should I use instead? :p
11:54:08 <nielsm> seeing it's most likely the catchment area is a rectangle-ish shape
11:54:32 <nielsm> i.e. most "set" bits are in a clump and most of the rest is clear
11:55:05 <Eddi|zuHause> storing a circumrectangle for early "not overlapping" tests?
11:55:12 <nielsm> for instance get the classic station rectangle bounds (orthogonal tile area), make a bitmap that size, and fill it in
11:57:20 <peter1138> Are you talking about when I am building the list or querying the list?
11:57:46 <peter1138> For querying we already know we are within this rect, otherwise we wouldn't be querying it.
11:58:15 <_dp_> peter1138, I kinda want to look for the library myself but have my hands full with citymania servers atm :(
11:58:19 <_dp_> Also want to find some solution for Tz0-Tz4 highlight as well
11:58:22 <_dp_> it's much harder as those damn things grow
11:58:42 <_dp_> to put all the large towns into a separate list/set and using same spatial tree for small ones will work I guess.
11:59:05 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5xo
11:59:20 <_dp_> a bit of a patchpack-quality solution though as it needs hardcoded threshold
12:02:08 <_dp_> peter1138, I haven't looked at your station patch yet, what are you trying to solve, find all stations around the industry?
12:02:40 <nielsm> I think so yes, find all candidate stations to have cargo supplied from industry
12:03:14 <peter1138> It's solved, just probably not using some fancy efficient algorithm, because I never studied algorithm.
12:04:28 <nielsm> wouldn't even a simple quadtree over towns, and one over stations, be useful in general, I wonder?
12:08:18 <nielsm> I doubt that exists :)
12:09:01 <nielsm> it's just splitting two-dimensional space into four quadrants, and each quadrant containing multiple points are split into further quadrants
12:11:41 <_dp_> peter1138, and where is the bottleneck in your current implementation?
12:11:58 <_dp_> tile set is a reasonable thing, don't see yet why is it being slow
12:12:34 <peter1138> It's okay, I was just test it for all stations, which is a lot on a 4096^2 map.
12:13:39 <peter1138> That's improved by filtering on station catchment rect first, so the list of stations to test is much smaller.
12:13:46 <_dp_> peter1138, you mean max amount of stations? how much is that even?
12:13:59 <peter1138> There actually isn't a bottleneck at the moment.
12:14:09 <peter1138> But that doesn't mean things can't be improved.
12:14:38 <peter1138> Also there's a bit overhead (cpu and code-size wise) in maintaining nearby lists for towns and industries.
12:15:16 <peter1138> ^ this is my stress-test save.
12:15:35 <peter1138> Might be useful for testing station sign performance improvements too.
12:16:33 <peter1138> _dp_, I wanted to achieve non-rectangular catchments, so I evolved a solution that worked. I didn't think "hmm, i can use this algorithm" at any point.
12:21:35 <_dp_> peter1138, I shouldn't have opened that save on my laptop xD
12:21:50 <peter1138> It's 8 fps on my i7-8700k
12:23:34 <_dp_> and that's only 2k stations, when max is 0xFFFD it seems
12:23:54 <_dp_> @calc 0xFFFD * (64+20)**2
12:24:24 <peter1138> Wait, what's the (64+20)^2?
12:24:36 <_dp_> yeah, that's a lot of tiles... but I thought it would be worse tbh
12:25:06 <peter1138> You probably can't fit that many on the map, though.
12:25:35 <_dp_> peter1138, there is more than enough space on 4k map :p
12:25:47 <_dp_> but yeah, it's getting unreasonable
12:27:00 <peter1138> Is somewhat less than 462400848
12:27:43 <_dp_> peter1138, yeah, but more than 0xFFFD stations
12:27:56 <_dp_> 462400848 is the max possible number of catchment tiles
12:28:08 <_dp_> @calc 0xFFFD * (64+16*2)**2
12:28:49 <peter1138> Max catchment is 10, so 64+20 was correct.
12:28:51 <_dp_> damn, nwm, that was right
12:29:11 <_dp_> I thought it's 0x10 for some reason xD
12:30:42 *** andythenorth has joined #openttd
12:46:12 <andythenorth> so I should redesign Horse to use vehicle variants? o_O
12:51:50 <peter1138> You're just procrastinating it.
12:52:14 <peter1138> Do you want vehicles to automatically change appears/specs over time?
12:52:33 <peter1138> Do you want vehicles to be able to be repainted or upgraded over time?
12:52:45 <andythenorth> I already removed that from 2 newgrfs :)
12:53:02 <andythenorth> auto-replace between variants, right?
12:53:08 <peter1138> Variants would require autoreplace to change their stuff.
12:53:17 <peter1138> Basically they become independent.
12:53:22 <andythenorth> yeah, so they're different IDs so just use autoreplace
12:54:13 <peter1138> "Operation on non-blocking socket would block." Uhmm.. hmm..
12:54:15 <andythenorth> so....what happens if one variant is an engine and another is a wagon? o_O
12:54:40 *** WWacko1976-work has quit IRC
12:54:44 <peter1138> You wouldn't be able to autoreplace between them.
12:55:01 <andythenorth> will they appear in the same group?
12:55:24 <peter1138> Like it'd be a loading error.
12:58:14 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5pj
13:03:25 <Eddi|zuHause> so, i spent some hours in these caves, haven't found any tungsten... do i need to go deeper or am i just unlucky?
13:08:04 <andythenorth> FIRS Steeltown is broken
13:08:41 <andythenorth> time to start FIRS 4
13:08:47 <Eddi|zuHause> i did finally find an aluminium deposit for a whooping 2 aluminium
13:08:50 <andythenorth> and 64 cargos and stuff
13:09:07 <Eddi|zuHause> now i can build trailers for my tractor, or something else
13:12:18 <andythenorth> probably just use 'tank car' already :P
13:14:04 <andythenorth> the thing about changing FIRS
13:14:15 <andythenorth> it breaks my savegames really frequently :P
13:28:09 <andythenorth> so does a cryo plant increase production if ENSP are delivered?
13:28:14 <andythenorth> or is it fixed output? o_O
13:28:18 <DorpsGek_II> [OpenTTD/OpenTTD] citymania-org commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5ha
13:30:46 <Eddi|zuHause> i think there's something
13:32:25 <Eddi|zuHause> legen... wait for it...
13:33:06 <andythenorth> 64 cargos, 52 of them different subtypes of common metals? o_O
13:34:00 <Eddi|zuHause> so essentially just random numbers? :p
13:34:11 <andythenorth> pig iron, cast iron, molten iron
13:34:23 <andythenorth> steel, stainless steel, specialty steel
13:36:07 <Eddi|zuHause> i meant these quality numbers like "301"
13:36:40 <nielsm> hmm, I tried writing a k-d tree builder for towns, in a debug build it can construct 368 towns (wentbourne!!) in a little less than 4 ms
13:36:55 <nielsm> I should maybe try the same for stations
13:37:22 <nielsm> right now I'm not actually sorting the items across the dimension, just taking the first element and praying :P
13:38:49 <andythenorth> I gave away my Raleigh bike with a Reynolds 301 frame
13:38:50 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5hH
13:39:01 <andythenorth> now it sells on ebay for ££
13:40:33 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5h7
13:41:02 <nielsm> 2263 stations tree built in 30 ms
13:41:19 <nielsm> that's rather slow, wouldn't want to rebuild that all the time
13:41:40 <peter1138> Is it quick to add/remove individually, or does it need to rebuild?
13:42:27 <nielsm> I haven't actually written a function to insert into the tree
13:43:29 <Eddi|zuHause> these tree structures are usually written for insert and lookup operations, not complete rebuilding
13:45:06 <nielsm> yeah I should probably aim to make a balanced tree initiall, even if the cost is higher
13:45:17 <nielsm> then maybe have a dumb insert without rebalancing'
13:45:47 <_dp_> peter1138, oops, didn't notice it was unfinished
13:45:53 <nielsm> I'm not sure how to rebalance a tree of this type
13:45:58 <_dp_> tbh I'm not sure where is it heading myself xD
13:51:10 <peter1138> Also, I really like the temporary tile highlight in my patch, would be good as a separate PR :D
13:55:25 <_dp_> peter1138, how does it choose town for red highlight?
13:55:53 <_dp_> but yeah, highlights are good, we need more of them :)
13:55:56 <peter1138> It can only showing the catchment of 1 town.
13:56:14 <_dp_> it's just they look a bit ugly like that
13:57:29 <peter1138> Kinda hard to see when it has to be zoomed out to fit it all. And you nede to make things transparent.
14:00:13 <Gabda> question about poiners stored in vector
14:01:00 <Gabda> if more towns are added, and they get reallocated
14:01:10 <Gabda> would this vector break?
14:01:11 <nielsm> towns don't get reallocated
14:01:23 <nielsm> they're stored in a pool of fixed size
14:01:42 <nielsm> neither do stations, industries, vehicles
14:02:00 <Gabda> so I can store the memory addresses without problem?
14:04:17 <Gabda> or storing the indexes would be better?
14:06:11 <peter1138> Depends if you need the pointer or just the index.
14:06:59 <Eddi|zuHause> is looking up the pointer from the index really a troublesome operation?
14:07:18 <nielsm> storing the index will typically save memory
14:07:33 <peter1138> Save a tiny amout of memory.
14:07:46 <nielsm> 2 or 6 bytes depending on 32 or 64 bit
14:07:59 <nielsm> but depending on amount of data it can add up :P
14:08:18 <Eddi|zuHause> we're talking about maybe 3000 towns?
14:10:19 <peter1138> Actually how does it achieve this resizing? I see a ReallocT...
14:12:11 <peter1138> Not much point testing a debug build for performance, only correctness.
14:12:46 <Gabda> oh, you are building a kdtree?
14:12:55 <nielsm> yeah trying to make a generic thing
14:13:45 <Gabda> splitting by tile x-y or col-row?
14:14:30 <peter1138> The pool is just a lot of individual allocations, not a big block split up.
14:14:35 <nielsm> I suppose it could just as well split by screen coordinates
14:14:53 <peter1138> So the realloc is just for the part of the pool that stores the pointers to the actual items.
14:15:12 <peter1138> I always assumed it was an actual proper pool :
14:15:38 <Gabda> i was thinking about is splitting by col-row would make the "circle" when searching a point touch less bounding rectangles
14:15:53 <Gabda> as a speciality of manhattan
14:18:38 <peter1138> Can this be used to find stations near an industry?
14:18:43 <peter1138> Asking for a friend.
14:18:48 <nielsm> that would be one use case
14:19:28 <peter1138> Hmm, how do you get information from it?
14:19:39 <nielsm> right now you don't :P
14:19:48 <peter1138> Right, so I wasn't missing anything :)
14:22:24 <Gabda> this will be interesting :)
14:22:59 <Gabda> (I am writing from mobile, tgi was a random char seq.)
14:26:58 <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdeI
14:27:35 <Eddi|zuHause> between looking at the sky and looking at the ground, my fps drops to 1/4
14:31:37 <_dp_> totally random idea: turn Tile type into separate array for each field
14:33:39 * andythenorth wonders whether carbon black justifies a train :P
14:35:11 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdeW
14:35:36 <peter1138> You mean like it used to be?
14:38:35 <peter1138> Doable. It was merged before the map accessors were created.
14:38:51 <peter1138> Worth benchmarking it.
14:41:23 <peter1138> nielsm, why uint16 for your node index/coordinates?
14:42:48 <peter1138> Also, put T element first, for alignment reasons.
14:43:01 <peter1138> Not that it matters I suppose.
14:43:17 <peter1138> uint16 could probably be a template parameter.
14:46:29 <peter1138> _dp_, am I confusing "iterate" with some other meaning? I am not considering a "contains" test to be iterating, as it is a hash internally afaik.
14:50:58 <_dp_> peter1138, which "iterate" is you talking about?)
14:52:02 <peter1138> FindStationsAroundTiles doesn't iterate the set, at least not in my understanding of iterators.
14:52:28 <_dp_> peter1138, ctrl-f "iterate" only finds your last comment ;)
14:55:17 <peter1138> catchment_tiles loop
14:55:48 <peter1138> I don't loop on the catchment tiles, but there is a test inside a loop, yeah.
14:57:20 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
14:58:03 <peter1138> AddNearbyStations() is basically just converting from std::set to StationList :p
15:01:09 <_dp_> "So a loop of (catchment + area)**2 tiles" I meant the loop before your changes
15:01:42 <_dp_> also I'm talking about FindStationsAroundTiles, you nhir
15:02:40 <Eddi|zuHause> i'm trying to follow your discussion, but neither of your statements make much sense
15:02:45 <peter1138> Yeah, 1*1 or 2*2 are the only occurrences.
15:03:04 <peter1138> Not 64x64 or anything like that.
15:03:23 <Eddi|zuHause> there are 2*1 houses
15:03:40 <_dp_> ah, "town->stations_near->catchment_tiles loop" yeah, ignore that one)
15:03:43 <peter1138> Houses are 1x1, each part produces individually on different tickets.
15:03:54 <_dp_> I meant stations_near loop there
15:03:59 <peter1138> The only thing which is 2x2 is... Company HQ.
15:04:13 <peter1138> stations_near is pretty tiny.
15:04:29 <_dp_> peter1138, don't industries also use FindStationsAroundTiles?
15:04:47 <peter1138> Not any more. I checked the flow and it's unnecessary.
15:04:52 <_dp_> peter1138, well, it depends on how many stations are there
15:05:03 <peter1138> Because i->stations_near already contains exactly the info which is needed.
15:05:35 <peter1138> We're talking low tens, not hundreds or thousands.
15:05:46 <peter1138> Hmm, this threading is getting confusing :)
15:06:46 <peter1138> Basically for industries we can either just directly use stations_near, or convert it to a StationList when it's needed as input to some other function. Ideally I would fix everything to use the same type.
15:06:56 <_dp_> peter1138, well, we're comparing it to tens (max 20) tile search rows
15:07:16 <Eddi|zuHause> how do you get "max 20"?
15:07:20 <peter1138> For houses, I determined that it's always 1x1, so took the loop out.
15:07:27 <peter1138> So yeah, 400 tiles.
15:07:32 <peter1138> Eddi|zuHause, MAX_CATCHMENT is 10.
15:07:36 <peter1138> Actually it's 21x21
15:08:01 <_dp_> peter1138, 20 rows, one row is one operation basically for cpu, I'm pretty sure of that
15:08:02 <nielsm> finally got it wrangled to compile...
15:08:37 <peter1138> I don't think that's actually the case.
15:09:21 <_dp_> peter1138, vectorization+l1 cache
15:09:33 <_dp_> peter1138, compared to set lookup I'd bet on row search
15:09:35 <Eddi|zuHause> in what mythical data structure does checking one row (for what?) consist of one single instruction?
15:10:46 <_dp_> Eddi|zuHause, I don't mean literally one operation, but CPUs are very very very good at optimizing stuff like that
15:10:47 <peter1138> _dp_, for each tile, it is checking the tiletype, getting the station index, then getting the station, then checking if that station is valid, then checking against the station's real catchment (before it was MAX_CATCHMENT) ...
15:10:53 <peter1138> the doesn't sound like one operation to me.
15:11:06 <peter1138> I don't think it'll be optimizing that into a one-op row.
15:11:41 *** Progman has joined #openttd
15:11:53 <peter1138> (_settings_game.station.modified_catchment ? MAX_CATCHMENT : CA_UNMODIFIED);
15:11:59 <peter1138> I could apply that optimization, woo.
15:14:22 <_dp_> peter1138, hmm, ok, mb I got too carried away thinking how fast it could be not how it actually is xD
15:14:35 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
15:15:22 <peter1138> I wonder about std::bitset.
15:15:24 <_dp_> peter1138, checking station for each tile probably doesn't cache well indeed
15:15:36 <peter1138> And its' not just that op :-)
15:15:46 <peter1138> And you can't skip early once you have one, because you need them all.
15:16:02 <peter1138> (Although you can skip the distance tests when you've already included one)
15:16:06 <_dp_> peter1138, hm, or mb it does, since most checks lead to same station so it can cache
15:16:20 <_dp_> peter1138, also you can build list first and check stations later
15:16:28 <nielsm> hm what's the easiest way to get a plain string of a station name (for console printing)
15:16:40 <_dp_> bitset I've no idea how good is
15:16:52 <_dp_> kinda hard to screw up something this simple so should be ok xD
15:17:13 <Eddi|zuHause> so, how then is building a list of stations faster than taking the list of stations we already built before?
15:17:31 <peter1138> Ok, bitset is an issue.
15:17:40 <peter1138> bitsets are fixed size.
15:18:15 <peter1138> 7225 bits for each one.
15:18:21 <peter1138> I don't think that's even a memory optimization.
15:18:46 <Gabda> nielsm, I am interested in that as well
15:19:00 <peter1138> I'm getting confused.
15:19:09 <_dp_> peter1138, you mean it pre-allocates that much? can't it be changed?
15:19:20 <peter1138> It's std::vector<bool> that can be variable, and is also optimized especially for bools.
15:19:32 <peter1138> _dp_, yeah, std::bitset<size> is a template parameter.
15:19:43 <peter1138> So std::vector<bool> is doable.
15:20:13 <nielsm> unless it prints in black on black
15:20:14 <_dp_> only thing I know about std::vector<bool> is that is a failure of an std container xD
15:21:04 <_dp_> doesn't mean it works bad, just not a proper container :)
15:21:25 <_dp_> coz you can't take & of an element
15:22:01 <nielsm> now to check if it's actually correct :D
15:22:28 <peter1138> So a 4x2 rail station would be ... 15 bytes, not at least 120.
15:22:51 <peter1138> Storing tileindex is pretty wasteful, certainly.
15:23:11 <nielsm> hmm no, it seems to do something wrong
15:23:22 *** sla_ro|master has joined #openttd
15:23:39 <peter1138> _dp_, it's useful discussion cos I found those optimizations.
15:23:44 <Gabda> the printing or the algorithm to find the nearest station?
15:23:49 <peter1138> And there's more to do.
15:24:48 <_dp_> I'd probably just make an uint8 * though for a bit map instead of fancy containers
15:25:16 *** kiwitree has joined #openttd
15:26:24 <_dp_> all you need is like i = y * w +x ; a[i>>3][i&7]
15:26:52 <_dp_> oops, a[i>>3]&(1<<(i&7)) :)
15:27:39 <peter1138> Hmm, it would need to assume MAX_CATCHMENT.
15:27:48 *** m3henry has joined #openttd
15:27:57 <peter1138> (Or you can iterate the tiles twice)
15:28:07 <peter1138> Spies are lucking again.
15:29:01 <peter1138> I remember when TF2 was fun.
15:29:19 <_dp_> peter1138, why MAX_CATCHMENT?
15:29:33 <Eddi|zuHause> <_dp_> oops, a[i>>3]&(1<<(i&7)) :) <- ans who the fuck will remember what that's meant to be in 6 years?
15:29:54 <_dp_> Eddi|zuHause, it's just a HasBit :p
15:29:56 <m3henry> sweet mary mother of god
15:30:37 <peter1138> Hmm, actually no need to scan the tiles, duh...
15:30:38 <Eddi|zuHause> _dp_: we already have a HasBit...
15:30:42 <peter1138> GetStationCatchment() would be fine.
15:31:37 <peter1138> Eddi|zuHause, HasBit(x[i >> 3], i & 7) isn't that much clearer.
15:31:57 <peter1138> (And is probably wrong)
15:32:39 <peter1138> HasBit(x[i / 8], i % 8) is kinda clearer in its intentions, but %...
15:32:40 <_dp_> fun part is doing range query on bitset xD
15:32:57 *** sla_ro|master has joined #openttd
15:33:17 <_dp_> peter1138, compilers are probably smart enough to optimize
15:33:47 <peter1138> So my next task is to make adding a new industry *not* wipe out all the caches.
15:33:52 <peter1138> It jus needs to add.
15:33:53 <Eddi|zuHause> peter1138: got to hope that the compiler knows to optimize / and % with power-of-two constant
15:34:05 <peter1138> Eddi|zuHause, / 8 definitely, % 8 maybe not. maybe.
15:34:14 <_dp_> peter1138, well, benchmarking without optimization is not a good idea anyway)
15:34:17 <m3henry> Eddi: compilers have been doing that for a long long time, don't worry
15:34:23 <Eddi|zuHause> peter1138: i don't see how one would be more difficult than the other
15:34:54 <Eddi|zuHause> peter1138: and on CPU level, both are the same operation, usually
15:35:35 <m3henry> Compilers have been optimising non-power-of-two divides and multiplies for quite a while too
15:35:45 <peter1138> Of course, with a uint8 * i have to mess about with memory allocation of it.
15:35:46 <Eddi|zuHause> if your CPU has an integer-div operation, it usually outputs both div and mod at the same time
15:36:08 <peter1138> And if I extend the station size, I *have* to wipe it and rebuild. Currently we can just add a tileindex to the set.
15:36:15 <Eddi|zuHause> (however, the point here is to avoid the integer-div in the first place)
15:36:58 <nielsm> where is std::optional when you need it
15:36:58 <_dp_> peter1138, station constuction doesn't happen very often, it's totally fine to rebuild
15:43:39 <Eddi|zuHause> m3henry: i'm pretty sure i read about that before, but the asm is pretty meaningless to me
15:44:10 <m3henry> The important thing to note is there is no idiv indtruction for the divide-by-constant
15:44:10 *** sla_ro|master has joined #openttd
15:46:48 <nielsm> because of negative numbers behavior it looks like
15:46:53 <Eddi|zuHause> there's weirdness with signed vs unsigned
15:47:13 <peter1138> Yes, same with uint
15:48:21 <peter1138> % 7 is even longer.
15:50:06 *** sla_ro|master has joined #openttd
15:53:38 <peter1138> _dp_, and to be fair, it's what we already do anyway.
16:00:32 <_dp_> peter1138, you mean stating rect rebuilding? bitmap is a bit heavier but whatever, player actions are rare
16:01:26 <_dp_> peter1138, btw, have you considered separating non-rectangular area patch from nearest caches?
16:01:42 <_dp_> peter1138, bitmap should take care of all the performance differences anyway
16:02:34 <peter1138> I thought about it but I changed many algorithms since as they didn't make sense with the cache in place.
16:03:41 <peter1138> The first commit is without the caches, and works, but there's probably other bugs that've been fixed that haven't been taken care of.
16:04:04 <nielsm> okay, got the nearest item search working in the tree
16:04:12 <peter1138> It could probably be split if I include the station distance check, but the FOR_ALL_STATIONS was the killer.
16:04:20 <_dp_> peter1138, it would just make it much more straightforward
16:04:22 *** snail_UES_ has joined #openttd
16:04:33 <_dp_> peter1138, caches are quite questionable and need a lot of benchmarking
16:06:01 <peter1138> Without the caches I saw 5ms per world tick, instead of 2ms.
16:06:13 <peter1138> I suppose it isn't alot but it's still significant.
16:06:22 <peter1138> That is with the station distance check in place.
16:06:29 <_dp_> peter1138, that's with unordered_set, right?
16:06:46 <peter1138> Yes, but with the distance check so it doesn't check that much.
16:08:31 <peter1138> bHmm, it's not quite the original patch, as that made it a third catchment type option, which was downvoted :p
16:16:41 <peter1138> Without the caches, we're resorting to scanning 441 tiles again.
16:17:31 <peter1138> 441 tiles, and some tests on those tiles, vs iterating a list with a few items in it.
16:17:56 <_dp_> for each tile keep a set of catching stations but DO NOT DUPLICATE sets, point to the same one
16:18:10 <_dp_> a bit hard to work with but super fast lookups
16:18:13 <peter1138> For each tile do what?!
16:18:34 <peter1138> I'm not storing a list of nearby stations for every tile.
16:18:49 <_dp_> make a set of stations that contain that tile in their area
16:19:17 <_dp_> many tiles have same sets so you only need to store a pointer to a set
16:19:27 <_dp_> and there are not many different sets
16:20:15 <_dp_> I know I was agains it but that was for highlights :p
16:20:16 <peter1138> Okay now I know you are taking the piss >:
16:22:00 <_dp_> well, it's still much less memory than bitmaps worst case :p
16:22:18 <_dp_> not sure if it actually eliminates the need for those bitmaps though
16:23:44 <peter1138> If you don't store catchment list then you need to rescan the station rect.
16:25:33 <peter1138> Also I've wasted most of the day talking about this, and I'm supposed to be working. :/
16:26:06 <Eddi|zuHause> i know that feeling
16:26:20 <Gabda> I see you with your new map array idea :P
16:37:22 <peter1138> Now that might be useful.
16:38:25 <peter1138> Although a map scan might've been quicker? I dunno.
16:38:36 <peter1138> Needs a larger are :p
16:40:56 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdUW
16:44:13 *** drac_boy has joined #openttd
16:44:24 <drac_boy> hi there to anyone else with a sunny sky ;)
16:44:41 <nielsm> sun's about to set here so... maybe hi?
16:45:08 <drac_boy> heh evening then nielsm :)
16:47:21 <drac_boy> doing anything or just slow night for now?
16:48:39 <nielsm> writing a k-d tree data structure that might be useful for speeding up lookups of towns/stations by map coordinates
16:53:10 *** Wormnest has joined #openttd
16:53:42 * drac_boy is just haing a slight slow morning for now .. catching up with weekday emails beside working the spec in my grf
16:56:32 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdUQ
17:01:05 <Samu> static const uint RIVER_OFFSET_DESERT_DISTANCE = 5; ///< Radius around river tiles without Desert Zone
17:01:50 <Samu> Radius around river tiles to unset Desert Zone
17:03:22 <Samu> Circular search radius to create non-desert around a river tile.
17:03:51 <peter1138> As opposed to a square radius?
17:04:02 <Samu> it's a circultar tile search
17:04:27 <Samu> static const uint RIVER_OFFSET_DESERT_DISTANCE = 5; ///< Circular tile search radius to create non-desert around a river tile.
17:05:34 <Eddi|zuHause> in maximum or manhattan distance, circles are square
17:05:53 <Samu> I don't know, it's a CircularTileSearch
17:07:57 <Samu> CircularTileSearch(&t, RIVER_OFFSET_DESERT_DISTANCE, RiverModifyDesertZone, NULL);
17:15:39 <Eddi|zuHause> i'm pretty sure CircularTileSearch uses maximum distance
17:16:19 <Samu> copy pasting title from one of peter1138 commits
17:17:29 <Samu> Codechange: Use const instead of magic number for circular tile search radius to create non-desert around a river tile.
17:18:18 <Eddi|zuHause> have i mentioned today yet that the game should use euclidean in more places, to be more intuitive?
17:18:35 <peter1138> euclidean catchment size?
17:19:00 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fhHqA
17:19:42 <Eddi|zuHause> (that, however, might actually break some people's savegames :p)
17:19:54 <Gabda> manhattan distances are nice
17:20:11 <Eddi|zuHause> s/savegames/networks/
17:20:14 <peter1138> Non-rectangular catchments is going to do that.
17:20:19 <Gabda> they deserve love as well :)
17:20:56 <Eddi|zuHause> well, theoretically it would, but most people won't notice :p
17:25:50 <Gabda> nielsm: in build, why do you start buildsubtree from begin+1, what happens to the very first element?
17:27:28 <drac_boy> nielsm or someone messed up with the numpad and entered wrong version? :)
17:27:35 <nielsm> bug from when I was building the tree differently
17:28:04 <nielsm> and funny you should mention it just now, because it was exactly the cause of the crash I was getting here
17:29:53 <Eddi|zuHause> drac_boy: more like it was looking for some library element and when it wasn't there it picked an overly suggestive error message
17:33:01 <Gabda> well, I am reading your code to learn new things
17:33:27 <Gabda> already saw some new and fine things
17:37:41 <drac_boy> sorry to ask but had to wonder - was italy the only one who actually built electric locomotives that had a very dysfunctional body style? (not a normal box w/wo nose that is)
17:43:40 <peter1138> Samu, so many questions...
17:44:45 <Eddi|zuHause> "vulkandriverquery: /home/pgriffais/src/Vulkan/base/vulkanexamplebase.cpp:823: void VulkanExampleBase::initVulkan(): Assertion `res == VK_SUCCESS' failed." <-- i think someone missed the point on what an assert should be
17:45:18 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdTH
17:49:03 <Samu> what I used to have was 3 checks, now it's down to just 1
17:50:40 <Gabda> nielsm: in FindContained you could define p1 as {min(x1, x2), min(y1, y2)}, and p2 as max, so it would be foolproof
17:59:58 <nielsm> Gabda I skimmed the paper you linked in a comment, it's not something I'm going to look into doing right away, would rather try to make a basic structure usable
18:01:19 <peter1138> nielsm, does that... work? :D
18:01:39 <nielsm> it seems like it works right now, yes
18:01:50 <nielsm> for getting nearest town
18:02:04 <peter1138> Need the tile highlight test that Gabda did
18:02:07 <Samu> if the station is mine and there's an industry without neutral station, will the cargo go to the industry
18:02:07 *** sla_ro|master has joined #openttd
18:02:09 <peter1138> If it works and is fast...
18:02:26 <Samu> how could you reduce 3 checks to just 1
18:02:32 <Gabda> ok, it improves performance on big item counts only
18:03:24 <drac_boy> samu or not dumb but just slower?
18:03:36 <Eddi|zuHause> Gabda: that's usually when you need performance the most :p
18:04:04 <Samu> if (ind->st != NULL && ind->st != st) continue;
18:04:11 <Gabda> i was thinking about making a kdtree as well, but dropped the idea, because I got scared of rebalancing it
18:04:36 <Gabda> but it is really nice to see your implementation
18:05:19 <nielsm> huh, I didn't realize SmallVector already had both Contains and Include that effectively implement a "stupid set"
18:05:26 <nielsm> (linear search membership test)
18:05:54 <Samu> if the industry has neutral station
18:05:59 *** andythenorth has joined #openttd
18:06:01 <Gabda> Eddi: yes, but it can be a next step, as the current version is also a big improvement
18:06:39 <Samu> what if the industry doesn't have neutral station
18:07:08 <nielsm> then it does the normal thing
18:07:24 <Samu> what if the station I'm delivering at
18:07:44 <nielsm> actually, you're not reading it
18:08:13 <Eddi|zuHause> Gabda: i haven't looked at a k-d-tree specifically, but rebalance operations aren't really that scary, just a lot of recursing
18:08:22 <nielsm> if (ind->st != NULL && ind->st != st) <- if the industry has a neutral station AND that station is not this station
18:09:10 <Samu> what if the industry doesn't have a neutral station and I'm delivering at some other industry's neutral station?
18:09:43 <nielsm> then you look a station.cpp line 359
18:10:10 <nielsm> and discover that those industries are already separated out earlier
18:10:55 <drac_boy> hmm I guess italy does seem to be alone then
18:12:22 <Gabda> Eddi: the kdtree I was thinking of had bounding boxes for every node which contained the boundig box of all the points in the node's subnodes
18:12:22 <andythenorth> I like how JGR gets the tailspin of OpenTTD bugs
18:12:35 <andythenorth> things that are fixed upstream, but not in JGRPP
18:13:06 <Gabda> but that can be done with recurssions, true
18:14:16 <andythenorth> so 'Hot Metal' or 'Molten Iron'?
18:14:35 *** HerzogDeXtEr has joined #openttd
18:14:36 <andythenorth> hot metal is the IRL term in steel industry, but it's not obvious in game
18:14:40 <drac_boy> andy is it supposed to be pre-poured metal?
18:15:17 <drac_boy> andy if it is I would had called it molten then
18:15:24 <drac_boy> oh..yeah I would say molten for sure :)
18:15:51 <drac_boy> as 'hot metal' could suggest blacksmithing/welding which isn't exactly "as that hot"
18:16:41 <drac_boy> any other cargo related questions you might have on mind now andy? :)
18:22:12 <nielsm> hmm looking at FindStationsAroundTiles (original version) and can't come up with any way to use my town k-d tree to improve it that will definitely be an improvement
18:23:07 <andythenorth> supermop_work: played any Horse? o_O
18:24:30 <nielsm> not that it matters, it's not a station tree I have here but a town tree
18:24:46 <nielsm> (nothing ever queries a tile area for towns, does it?)
18:25:31 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7158: Add: Client setting gui.start_spectator https://git.io/fhSk4
18:27:43 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick closed pull request #7204: Feature: Game setting to define how industries with neutral stations accept and supply cargo from/to surrounding stations. https://git.io/fhH19
18:28:33 <Eddi|zuHause> nielsm: could query town on station or industry placement, to get the closest town of the whole area instead of just the top tile
18:29:07 <nielsm> Eddi|zuHause, not looking for ideas for new things to do just yet :P
18:29:38 <Eddi|zuHause> nielsm: i'm an expert at derailing by feature request :p
18:31:37 <andythenorth> (air products cryo, not methane)
18:32:09 <drac_boy> well andy you could technically just feed it Chemical from the firs refinery?
18:32:18 <andythenorth> no refinery in this economy
18:32:29 <drac_boy> ah hm dunno then sorry :)
18:37:39 <peter1138> Hmm, I should test subsidies.
18:38:25 <peter1138> Error: Assertion failed at line 3803 of /home/petern/Projects/OpenTTD/src/station_cmd.cpp: location.w == 1 && location.h == 1
18:38:46 <peter1138> Unfortunately, that was Wentbourne, after a few days.
18:39:05 <peter1138> If I try to run Wentbourne in a debug build, it'll take literal days...
18:39:53 <Eddi|zuHause> you could start with debug level 1?
18:40:07 <peter1138> No, backtraces are fairly useless.
18:40:17 <peter1138> I'm just going to grep for all callers first :-)
18:41:04 <Eddi|zuHause> also, you could make a savegame closer to the crash
18:41:20 <peter1138> Or make a smaller savegame.
18:41:52 <nielsm> it would be useful with some debug commands like "create a new subsidy right now"
18:42:38 <Eddi|zuHause> can a game script issue subsidies?
18:43:20 <peter1138> Whenever you see "q" I means I did ESC : q in the wrong window.
18:44:10 <Eddi|zuHause> it usually says :q in those cases
18:44:52 <peter1138> irssi responds to ESC as well.
18:45:14 <peter1138> That's a few seconds per frame.
18:47:23 <peter1138> I see, this is obvious and I'm surprised it hasn't happened before.
18:48:00 <peter1138> Top corner of an industry is a hole so i->location is not actually an industry tile...
18:48:39 <peter1138> Using the kdtree to determine which signs to draw?
18:48:53 <peter1138> Or just adding stations
18:48:55 <nielsm> no, just which town is nearest
18:49:21 <nielsm> difference is this was a new generated world and I wrote an Insert function on the tree :P
18:49:56 <drac_boy> anyway andy have fun figuring out cargos (I have a slight similar issue here too but meh) .. going off for today here
18:50:32 <nielsm> I started the scenario editor and placed a single town and it asserted :(
18:50:48 <nielsm> I know what the issue is though
18:59:00 <Eddi|zuHause> push it real good
18:59:23 <Eddi|zuHause> (anyone even remember that song?)
18:59:39 <andythenorth> time to move newgrfs to github?
19:03:00 *** synchris has joined #openttd
19:04:05 <andythenorth> means I might be able to do FIRS 4 without breaking FIRS 3, which needs maintenance releases
19:06:26 <andythenorth> planetmaker: can we teach bundles to git?
19:06:56 <nielsm> stations are more interesting than towns, because stations are created and removed all the time!
19:08:52 <Eddi|zuHause> andythenorth: i think you should first create the github repo, and then ask that question again :)
19:09:12 <andythenorth> well then I might end up stuck with a github repo, and no way back to hg
19:09:50 <Eddi|zuHause> andythenorth: i'm fairly certain that the answer is "yes" but the answer will be meaningless to you unless you can say "ok, do it right now"
19:10:54 <peter1138> nielsm, as long as add/remove is fast... I guess it's not? :(
19:11:22 <peter1138> Hmm, those pretzel pieces were a bit stale...
19:12:35 <andythenorth> this is heresy, but I prefer redmine's repo view to github's
19:12:49 <andythenorth> github doesn't show many commits per page, and it's really non-compact
19:12:53 <nielsm> peter1138, Insert is log(n)
19:13:13 <nielsm> but can cause the tree to become imbalanced if enough items are inserted in a poorly chosen order
19:14:05 <nielsm> Remove is not implemented yet, but can require rebuilding a partial tree, so worst case is O(n*log(n)^2)
19:15:10 <peter1138> How slow is rebuild?
19:16:34 <peter1138> Oh you just said :p
19:20:02 <nielsm> might be slower actually, since I'm sorting and re-sorting elements a lot
19:20:27 <_dp_> nielsm, with how rare player actions are you can probably get away even with a full tree rebuild
19:21:58 *** m3henry has joined #openttd
19:22:13 <_dp_> though I'm not sure if there is any benefit for having a tree for stations
19:25:41 <peter1138> Right, now to compare Wentbourne side-by-side.
19:25:49 <peter1138> master vs non-rect-catchment
19:26:06 <Wolf01> So, I had my head in astroneer for the entire day today... I'm playing it too much
19:26:22 <Wolf01> I couldn't concentrate at work
19:26:57 <peter1138> Waiting for the average ms to creep up for World ticks.
19:27:14 <peter1138> Slightly issue with the framerate display, it takes ages to get there are very low rates.
19:27:43 <Wolf01> It should be time based, instead of quantity based
19:28:03 <peter1138> _dp_, all this worrying...
19:28:20 <peter1138> I'm seeing a 0.1ms performance increase with my patch.
19:28:37 <peter1138> So non-rect catchments is faster than master.
19:28:53 <peter1138> Wolf01, not a lot, but that's per tick.
19:29:03 <peter1138> Actually it's 0.13ms.
19:29:19 <_dp_> peter1138, wait, 0.1 from master, not just unsorted_set?
19:29:32 <peter1138> Er, or would be, except I'm nowhere near 33 fps.
19:30:21 <peter1138> Using unordered_set and all my other optimizations.
19:30:34 <Wolf01> So freenode is telling me to upgrade mirc
19:30:42 <_dp_> peter1138, ah, I thought you did bitmaps
19:31:08 <peter1138> No, I looked, but it requires significant processing at the "IsTileInCatchment()" stage.
19:32:37 <_dp_> peter1138, for caches you probably need a test with a lot of town growth as well
19:32:38 <peter1138> Need to convert the TileIndex in x & y components, then subtract the bitmap offsets, then bounds check both min/max, and then finally do the bitmap lookup.
19:33:20 <peter1138> And then, in the rare cases I *do* iterator the catchment tiles, I'll need to write an iterator.
19:33:45 <peter1138> So "just use a bitmap" is kinda... sure, doable but not easy.
19:36:12 <peter1138> For town growth I am actually iterating the map array to find stations, in case any station is a new one.
19:36:23 <_dp_> peter1138, dunno, sounds like just a bit tile coords math to me
19:36:48 <peter1138> coordinate maths against what?
19:37:03 <peter1138> Oh you mean the bitmap thing.
19:37:19 <_dp_> peter1138, i mean just a simple conversion from global xy to bitmap xy and back
19:37:40 <peter1138> None of which is necessary with the current unordered_set.
19:38:32 <peter1138> So if nielsm can make a k-d tree station list then I can use that instead of scanning the map, maybe.
19:38:45 <_dp_> peter1138, you mean performance cost or development?
19:38:45 <peter1138> Although that needs to take into account station size, not just its top corner xy.
19:38:53 <peter1138> _dp_, development cost.
19:39:04 <_dp_> peter1138, performance-wise unordered set does heavier math under the hood
19:40:07 <nielsm> funny line, DEBUG(sl, 0, "Unknown savegame type, trying to load it as the buggy format");
19:40:20 <nielsm> "the buggy format" is presumably well known?
19:40:48 <peter1138> I could just use a vector...
19:41:11 <andythenorth> PR count will soon overtake issue count :D
19:42:27 <peter1138> andythenorth, you can fix that.
19:42:38 <peter1138> andythenorth, approve PRs, or create more issues.
19:42:57 <Wolf01> The target is to lower the issues to 0, so PRs can overtake them autimagically
19:43:52 <Wolf01> Or merge all PRs and issues will decuplicate
19:44:37 <_dp_> yeah, stalebot is unrivaled bugfixer :p
19:45:16 *** gelignite has joined #openttd
20:09:46 <supermop_work> Eddi|zuHause: of course i remember
20:27:39 *** sim-al2 has joined #openttd
20:29:12 *** Smedles has joined #openttd
20:32:53 *** frosch123 has joined #openttd
20:41:24 *** Supercheese has joined #openttd
20:56:11 *** Supercheese has joined #openttd
21:13:06 <peter1138> Mmm, beef fillet steak
21:15:43 <peter1138> Yeah so was there an AI that made subsidies?
21:15:56 *** andythenorth has joined #openttd
21:16:01 <peter1138> andythenorth would know.
21:16:30 <andythenorth> what was the question?
21:16:38 <nielsm> well, there is an api to create subsidies
21:16:38 <nielsm> static bool Create(CargoID cargo_type, SubsidyParticipantType from_type, uint16 from_id, SubsidyParticipantType to_type, uint16 to_id);
21:16:41 <peter1138> Was there a GS that made subsidies :D
21:18:42 <andythenorth> one day I make a GS maybe
21:18:50 <peter1138> Your name is in the credits of one.
21:19:02 <andythenorth> yeah, that wasn't really me, I just playtested
21:19:19 <andythenorth> GS involves way too much handling of state etc for me
21:19:30 <andythenorth> it's a lot of stuff to think about that I am not good at
21:19:51 <andythenorth> all the saveload stuff etc is complex
21:21:23 <peter1138> Ok... UFO landed on my only raod vehicle, while it was stopped int he depot.
21:22:17 <peter1138> Palette animation on to make fast-forward bareable.
21:24:33 <Gabda> I've read back on the IRC messages about my town name refresh PR
21:26:15 <andythenorth> if I move FIRS to github
21:26:44 <andythenorth> coop is bus-proof
21:26:58 <Gabda> and now I don't know if I should continue it, or wait till the k-d tree implementation will be generic enough to shave off a few more percentage from the refresh time
21:27:06 * andythenorth suspects it's probably fine, except for me, but I'll be dead
21:28:33 <peter1138> Hmm, still no subsidies.
21:28:48 <peter1138> Maybe I've broken it?
21:30:03 <peter1138> No, I've only changed the code that detects if cargo is subsidized, but I'm not seeing any offers.
21:31:06 <nielsm> hmm, I wonder if a k-d tree can be used to extract items in order of distance to a point?
21:31:16 <peter1138> Passenger subsidies are disabled if cargodist is enable!
21:31:23 <nielsm> i.e. not just get nearest items, but get X nearest items
21:31:47 <peter1138> Why would that be the case?
21:32:15 <peter1138> OTOH, I should be seeing cargo subsidies too.
21:33:51 <peter1138> (svn r25882) -Change [FS#5766]: Don't offer subsidies for auto-distributed cargo.
21:35:17 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #5766: (Re)consider subsidies should work under cargo-dist https://git.io/fhdmU
21:35:52 <peter1138> Yup, cargo dist off ... get a subsidy.
21:36:29 <andythenorth> on the one hand I really like cargodist, and it was an achievement for fonso to get it done and in trunk
21:36:36 <andythenorth> on the other hand cargodist is pretty lame
21:38:45 <peter1138> Ok, subsidy works :D
21:39:19 <glx> it should work with cargodist if source and destination are correct
21:39:28 <peter1138> No, it's specifically disabled.
21:40:05 <peter1138> Yeah, you just can't control src & dst very much.
21:40:20 <peter1138> Short of not creating links. Easier for cargo, I guess.
21:40:43 <Gabda> nielsm, I don't think you can
21:41:02 <andythenorth> I don't really get the problem
21:41:17 <andythenorth> if there's a subsidy A->B, build a route A->B
21:41:36 <andythenorth> cdist will then route cargo A->B
21:41:52 <andythenorth> most of the 'problems' of cdist are because it's counter-intuitive
21:42:05 <glx> cdist may also do A->C->D->B
21:42:16 <andythenorth> I said build a route A->B
21:42:41 <Gabda> <nielsm> (nothing ever queries a tile area for towns, does it?) <- IsCloseToTown does
21:42:52 <andythenorth> cdist works exactly as advertised, and is mostly not broken
21:43:00 <andythenorth> it's just not really useful
21:43:10 <andythenorth> it's a high cost way to avoid automated transfers
21:43:15 <andythenorth> enable / avoid /s
21:44:15 <nielsm> hmm FindStationsAroundTiles is actually a bit strange, in that if I were to change it to look for station signs, it would also have to depend on the max station spread
21:44:27 <nielsm> and that may have decreased since a station was built
21:44:44 <nielsm> (not that it usually will, but it could potentially have)
21:45:26 <m3henry> Man this line is awkward to grok:
21:45:26 <m3henry> this->buf = *this->blocks.Append() = CallocT<byte>(CHUNK);
21:47:30 <peter1138> It's allocating CHUNK bytes of memory, and storing the pointer to it in this->blocks and this->buf
21:47:47 <m3henry> Just readign it as such takes time
21:48:59 <_dp_> nielsm, iirc k-d trees can do k-nearest neighbor query but if you want to do it for all the points simply sorting would be faster
21:49:27 <peter1138> Okay, I just remembered I can't iterate catchment_tiles this way here :-(
21:53:37 <glx> hmm cargo packets have source, and I think there's a way to know if the cargo did a direct travel
21:54:50 <peter1138> Does it need to be direct?
21:57:56 <andythenorth> oof github import of FIRS failed :P
21:58:09 <andythenorth> doesn't say why :P
22:00:33 <andythenorth> this is why I frigging hate mercurial
22:00:35 <andythenorth> (bin35) firs$ hg up v4-test
22:00:36 <andythenorth> abort: uncommitted changes
22:00:37 <andythenorth> (commit or update --clean to discard changes)
22:00:37 <andythenorth> (bin35) firs$ hg st
22:01:01 <andythenorth> it really doesn't understand branches at all
22:04:00 <andythenorth> frosch123: how did you complete the nml -> github clone?
22:06:01 *** Wormnest has joined #openttd
22:06:35 <glx> git init, git add, git commit ?
22:16:51 <andythenorth> sometimes the github importer works, and sometimes not
22:17:00 <andythenorth> I was able to import nml, frosch wasn't :|
22:17:22 <dwfreed> andythenorth: yeah, mercurial's behavior wrt branches is... weird
22:44:36 *** snail_UES_ has joined #openttd
22:44:57 <andythenorth> oof GH import failed again
22:45:36 <peter1138> Did you expect something different?
22:46:25 <andythenorth> I wondered if it was timing out upstream or downstream
22:46:46 <andythenorth> 'try again' is valid in most computing situations :P
22:48:09 <frosch123> andythenorth: i have a local hg-fast-export
22:48:21 <andythenorth> I'll do the same
22:48:26 <frosch123> shall i clone something
22:48:53 <frosch123> it's already setup, so it's like 5 minutes
22:49:08 <andythenorth> if you don't mind
22:49:11 <andythenorth> I want to try moving FIRS
22:50:04 <Samu> I'm gonna assume my AI is now ready
22:50:17 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdY3
22:52:41 <frosch123> do you have a foobar email or gh account?
22:52:56 *** drac_boy has joined #openttd
22:53:02 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYs
22:53:17 <frosch123> hm, oh, there is no foobar
22:53:22 <frosch123> i thought i read that
22:55:49 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYG
22:56:12 <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #7237: Codechange: Move some common code after adding/removing tiles to a station to its own function. https://git.io/fhdYZ
22:56:44 <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #7230: Fix #7226: No ship track due to "forbid 90 deg turns"-> Do not call pathfinders. https://git.io/fhdYn
22:57:23 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7230: Fix #7226: No ship track due to "forbid 90 deg turns"-> Do not call pathfinders. https://git.io/fh7Pg
22:57:29 <DorpsGek_II> [OpenTTD/OpenTTD] michicc closed issue #7226: NPF: Ship: Assertion failure when ship encounters shore https://git.io/fh7CV
22:57:47 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7237: Codechange: Move some common code after adding/removing tiles to a station to its own function. https://git.io/fh54N
22:58:44 <peter1138> BitmapTileArea+Iterator...
22:58:54 <peter1138> I'd be surprised if this works.
22:59:54 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYC
23:00:14 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYl
23:00:25 <peter1138> _dp_, slightly ... quicker ...
23:00:36 <peter1138> I think. I might be misremembering.
23:01:09 <peter1138> std::unordered_set 1.76ms
23:01:16 <peter1138> bitmaptilearea 1.44ms
23:01:44 <Samu> question, which vehicle set do I need to play FIRS?
23:01:58 <Samu> my ships couldn't transport engineering supplies
23:02:43 <peter1138> It's going to annoy m3henry, because it uses SmallVector :/
23:02:53 <frosch123> firs import requires git fsck :p
23:03:13 <drac_boy> samu basically nearly anything except the vanilla trains
23:03:17 <andythenorth> is the repo inconsistent?
23:04:06 <drac_boy> although I can't recall if newships.grf would be generic enough (its older than firs afaik) to still accept every single firs cargos now that you mention it
23:04:32 <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYB
23:04:37 <frosch123> there are 4 eints commits with: nulInCommit: NUL byte in the commit object body
23:04:55 <_dp_> peter1138, that's not a bad improvement actually
23:05:23 <_dp_> peter1138, also you're measuring tick time, it's unclear how much of that is even related to stations
23:05:42 <peter1138> _dp_, when it jumped to 40ms, I knew it was me.
23:05:49 <nielsm> bah, before I managed to get the station kdtree into a wrong state where it contained station ids that were invalid, now I'm not sure what I did for that
23:06:13 <_dp_> peter1138, yeah, on increasing side it's more clear)
23:06:15 <Samu> you're blatantly making opf do worse, :p
23:07:11 <_dp_> peter1138, but for decreasing it's hard to tell where 0 actually is, 0.5ms may be 25% improvement or mb 99% for all we know
23:07:29 <Samu> I need to see what happened to removal of 90 degrees
23:07:35 <Samu> was it really removed or not?
23:07:38 <peter1138> Yes, I'm aware. I'm happy with it reducing. I haven't checked memory usage.
23:08:01 <peter1138> It's less than master, that's pretty important.
23:08:12 <nielsm> ah okay, reproduced the crash now
23:08:42 <nielsm> now, where are dead station signs removed...
23:09:43 <drac_boy> just curious what any of you think of geared steam locomotives in general? (low speed high tractive cheap locomotive early in)
23:09:56 <drac_boy> I know they didn't have a lot of buyers outside north america at times but still .. a game is just a game :)
23:10:40 <andythenorth> drac_boy: for ottd?
23:11:13 <andythenorth> TE is almost irrelevant in most ottd gameplay situations
23:11:30 <andythenorth> it only makes a difference in very specific situations
23:11:57 <DorpsGek_II> [OpenTTD/OpenTTD] michicc requested changes for pull request #7028: Feature: Option to group vehicle list by shared orders https://git.io/fhdYo
23:12:03 <andythenorth> so geared locomotives are basically just slow, wiht no upside
23:12:20 <glx> nielsm: somewhere in the gameloop
23:12:38 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7028: Feature: Option to group vehicle list by shared orders https://git.io/fhdYK
23:12:43 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7028: Feature: Option to group vehicle list by shared orders https://git.io/fhdY6
23:14:35 <nielsm> glx found it, station_cmd.cpp StationHandleBigTick
23:15:54 <drac_boy> andy well last I checked te does matter unless I guess you're the type who loves to make up 4-loco 40-wagon trains on supermaps which in that case ignore me then ;) 27kph for 700hp/40kn versus 50kph for 550hp/70kn on same train
23:16:55 <glx> and you can probably use its return value in OnTick_Station()
23:19:03 <drac_boy> samu actually I think squid/fish should be capable firs/ecs-ready ships too .. if that ever helps?
23:20:17 <peter1138> _dp_, I'm surprised I managed to get it working. I even inherited from the existing tilearea+iterator.
23:21:17 <Samu> I'm refering about this last merge
23:21:43 <andythenorth> drac_boy: TE is irrelevant unless train speed drops below some level
23:22:06 <Samu> it's making opf do even worse than it already is
23:22:07 <andythenorth> HP is significant, TE is not
23:22:20 <drac_boy> andy well I guess I don't know why the first train refused to hit 50kph then :)
23:22:22 <frosch123> well... what does git call the "commit object body"?
23:22:47 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
23:23:05 <andythenorth> frosch123: I'll google
23:23:15 <frosch123> i only found the git source code
23:23:37 <Samu> now opf ships reverse, believing they can do a 90 degree after the reverse, but on the next tile, the track is not given to it
23:23:47 <drac_boy> samu not sure .. you asked which sjips can be used with firs .. I responded to that
23:24:04 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdY7
23:24:06 <Samu> ah, thanks, I'm about something else now
23:24:23 <Samu> they're stuck in a reverse loop
23:24:51 <andythenorth> oof google gets me one SO result, a spanish mercural RSS feed thing, and a 403
23:25:32 <andythenorth> drac_boy: sounds like you have one of the cases where TE does apply
23:25:38 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYF
23:25:39 <andythenorth> not enough HP / ton
23:25:47 <Samu> how do I contest a merge? :o
23:26:22 <andythenorth> there's no concept of 'contest'
23:26:26 <andythenorth> you can complain on the PR
23:26:33 <andythenorth> and see what response you get
23:26:42 <peter1138> Samu, why did you not comment on PR?
23:26:49 <andythenorth> you think it's buggy?
23:26:56 <drac_boy> andy again .. the second train had less hp but it could hit the speed limit due to te .. but anyway seem we're not on the same maps so never mind :)
23:27:07 <peter1138> You should have commented on the PR with your thoughts at the time, not complain later.
23:27:11 <Samu> you were telling me 90 degrees were to be removed for ships
23:28:06 <Samu> now this is merged, I'm testing it right now, and opf ships are locked in a reverse-loop
23:28:14 <peter1138> Samu, no, we were saying it's possible.
23:28:25 <andythenorth> frosch123: don't suppose we can just drop the offending commits?
23:28:30 <peter1138> Samu, this is why you should always comment on the PRs, not just chat in IRC where it is not recorded.
23:28:54 <glx> and you can test the PRs before they are merged too
23:28:58 <drac_boy> hmm just finally looked now .. the irregular airport catchment does seem interesting
23:29:10 <peter1138> Samu, anyway, if you want to "contest" a PR, you know exactly what to do.
23:29:19 <Samu> but why would I bother, everytime I talk about opf, you complain about it being obsolete
23:29:22 <frosch123> andythenorth: fixed it :)
23:29:33 <peter1138> Samu, that doesn't mean we want to break.
23:30:33 * drac_boy wonders what else coals can be used for beside steelmills/powerplants
23:31:15 <m3henry> Append is turning out to be the largest commit of this PR
23:32:03 <andythenorth> brick kiln, cement kiln
23:32:33 <drac_boy> hmm coal bricks .. thats a new one to me .. will have to check ty
23:32:47 <nielsm> not bricks made from coal, bricks fired with coal
23:33:33 <Samu> there is a right way to do 90 degs for opf
23:33:43 <Samu> i had it done, but it was rejected
23:34:20 <peter1138> _dp_, nice benefit, it's now safe to iterate catchment_tiles as the order is guaranteed.
23:34:35 <andythenorth> why are we implementing 90 degs for opf?
23:35:01 <nielsm> why was the 90 deg turns setting ever made apply to anything other than trains?
23:35:06 <Samu> then j0anjosep comes in, makes 90 degs be checked before the pathfinder, which breaks opf, and it gets accepted :(
23:35:14 <nielsm> it was only supposed to ever be about trains
23:35:31 <peter1138> debug visualizations are really useful.
23:35:31 <drac_boy> hm anyway I'll let you talk about stations and pathfinders .. going off for a while here
23:35:31 <frosch123> why? ships turned just as sharp
23:35:49 <DorpsGek_II> [OpenTTD/OpenTTD] michicc requested changes for pull request #7176: Fix #6633: Cargo monitor industry delivery now accounts for which IndustryID the cargo was delivered to https://git.io/fhdOY
23:35:55 <peter1138> Made it much easier to verify that station catchment works.
23:36:30 <frosch123> though now they turn in place? i read something like that
23:36:40 <peter1138> Yeah that's a thing.
23:37:39 <glx> next time you could try the PR before it's merged ;)
23:37:51 <frosch123> andythenorth: my upload is too small, push will take 30 minutes or so :p
23:38:15 <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7176: Fix #6633: Cargo monitor industry delivery now accounts for which IndustryID the cargo was delivered to https://git.io/fhdOZ
23:38:28 <glx> especially when you know what could fail
23:38:29 <peter1138> Prozone 13 catchment areas, oh boy.
23:38:51 <LordAro> oh, you're definitely going to break all ottdc games :p
23:39:18 <andythenorth> frosch123: is the process repeatable? o_O
23:39:24 <nielsm> peter1138, prozone 13 is the one with synchronised oil trains?
23:39:37 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdOC
23:39:48 <frosch123> i repeated it 5 times with various author mappings
23:39:55 <andythenorth> I should set up to do it locally then, I have 6 or so repos to convert :)
23:40:01 <andythenorth> maybe not right now though :)
23:40:29 <frosch123> hmm, do you mean "repeatable" or "incrementable"?
23:40:49 <andythenorth> I mean can I follow instructions and get it done?
23:40:58 <andythenorth> unless you or someone else would do it for me :P
23:40:59 <frosch123> i always convert the whole repo, no idea whether it can also do incremental updates
23:41:20 <frosch123> andythenorth: up to know i used the package from debian stable
23:41:39 <frosch123> but now i patched the script to filter out NUL in commit messages
23:41:39 <peter1138> Ah, Resize doesn't clear :-)
23:41:50 <frosch123> which eints apparently produces sometimes/somewhen
23:42:25 <glx> as it seems frosch123 is using the indicated tool
23:42:54 <frosch123> yes, hg-fast-export
23:43:32 <frosch123> most work is creating the author mapping file, but since there are only finite authors on devzone, and they are mostly the same for the repos, i should have most
23:44:18 <andythenorth> can we wrap a shell script around it? :P
23:44:33 <andythenorth> might be a lot to move in future
23:44:44 <glx> author thing is somehow manual
23:44:57 <frosch123> i could probably run it on devzone
23:45:00 <frosch123> better bandwidth :p
23:45:59 <peter1138> Samu, add a reference to the offending commit/PR as well.
23:50:47 <Eddi|zuHause> why is the tractor called a rough terrain vehicle, when it gets stuck on every tiny bump?
23:52:13 <andythenorth> frosch123: devzone sounds like a nice idea :)
23:52:15 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
23:54:13 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdOi
23:56:06 <peter1138> andythenorth, not again.
23:56:26 <peter1138> Broken savegame - Invalid chunk size
23:57:04 <peter1138> I should add a button to allow broken savegames to be deleted easily :p
continue to next day ⏵
