Config
Log for #openttd on 18th February 2019:
Times are UTC Toggle Colours
00:01:17  *** HerzogDeXtEr has quit IRC
00:02:01  *** tokai has joined #openttd
00:02:01  *** ChanServ sets mode: +v tokai
00:09:00  *** tokai|noir has quit IRC
00:18:07  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: New non-rectangular sparse station catchment area https://git.io/fh5s1
00:32:40  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: New non-rectangular sparse station catchment area https://git.io/fh5HZ
00:44:42  <Samu> a
00:44:47  <peter1138> b
00:46:09  <peter1138> Yay, all checks passed.
01: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.
01:06:14  <peter1138> Or something else.
01:07:26  <peter1138> Ah, git-extras was installed.
01: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
01:23:56  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5HK
01: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
01:35:13  *** snail_UES_ has joined #openttd
01:36:14  *** Thedarkb-X40 has joined #openttd
01:42:40  *** Wormnest has quit IRC
02:03:15  *** Thedarkb-X40 has quit IRC
02:26:13  *** Progman has quit IRC
02:26:39  <Samu> what have you guys done to zoom?
02:26:44  <Samu> it's so slow now
02:26:47  <Samu> https://imgur.com/sifVKTq
02:35:00  *** Samu has quit IRC
03:25:57  *** debdog has joined #openttd
03:29:19  *** D-HUND has quit IRC
03:56:58  *** glx has quit IRC
04:00:11  *** supermop_Home has quit IRC
06:26:38  *** cHawk has quit IRC
06:31:34  *** cHawk has joined #openttd
06:41:06  <peter1138> Nothing to do with having 15 AIs running...
06:49:23  *** snail_UES_ has quit IRC
06:57:12  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5dC
07:08:10  *** nielsm has joined #openttd
07:26:20  *** andythenorth has joined #openttd
07:27:07  <nielsm> morning
07: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
07:30:00  <peter1138> Oh no!
07:30:32  <peter1138> That's like being a kid and turning up to school on a Saturday.
07:37:28  <peter1138> Brave.
07: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
07:37:32  <peter1138> Foolish.
07:37:35  <peter1138> Both.
07:37:56  <peter1138> "If you wish, you can delete your fork of **OpenTTD/OpenTTD**"
07:38:03  <peter1138> Yeah, no, why the heck would I want to do that.
07:42:57  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5d7
07:54:18  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fh5FO
07:54:24  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5F3
08:04:03  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5F8
08:04:54  <peter1138> Oh, the station part of an oil-rig produces cargo? Hmm.
08:05:17  <peter1138> Ah, no, the station part of an oil-rig tries to find a nearby station. Hmm.
08:05:41  <peter1138> Need a back trace to find the caller.
08:05:45  <peter1138> So need debug mode.
08:05:46  <peter1138> Yawn.
08: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
08:08:56  <peter1138> nielsm, yeah, that test is very worthwhile.
08:09:12  <peter1138> Glad I didn't try it first, as I may not have bothered with the caching stuff.
08:10:20  <nielsm> heh
08:10:33  <nielsm> it sounds like it's actually faster now than originally?
08:10:56  <peter1138> I think it's about the same.
08:11:21  <peter1138> It no longer needs to search the map array for every cargo delivery.
08:14:14  <andythenorth> hmm Horse
08:14:22  <andythenorth> will it ever be done? o_O
08:16:15  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fh5FP
08:16:46  <peter1138> I think my additional FindStationsAroundTiles() function that takes a nearby list is spurious.
08: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.
08:20:23  <peter1138> In which case, I may not need to call it at all.
08:21:16  <andythenorth> oof been doing Horse 2 since August 2017
08:21:22  <andythenorth> it's probably 'done'
08:21:34  <andythenorth> apart from I haven't drawn all the trains :x
08:57:35  *** andythenorth has quit IRC
09:48:59  *** andythenorth has joined #openttd
10: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
10:17:49  <_dp_> damn, now I have two github accounts thanks to azure thing
10:18:03  <peter1138> Har har
10:18:05  <_dp_> well, might as well switch to this one
10:18:32  <peter1138> Don't be a cunt though, that's my job.
10:19:13  <peter1138> You can suggest better algorithms without implying that what's been suggested is totally worthless.
10:20:09  <_dp_> it's not worthless, it would work fine for random town distribution
10:20:13  <peter1138> It should be obvious that not everybody studies this algorithm stuff, they just scratch an itch.
10:20:25  <_dp_> just what's the point of making several solutions for one problem?
10:20:55  <peter1138> And most people just scratching their itch won't know about the name of some random algorithm that does something efficiently.
10:21:34  <andythenorth> at least include [emoji] :P
10:21:39  <andythenorth> it takes the edge off it
10:21:52  <andythenorth> we have quite a lot of new contributors, and I want them to stay
10: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.
10:21:56  <_dp_> andythenorth, right, I totally forgot xD
10:27:04  <_dp_> peter1138, there are just too many spatial structures, you need a complete list of use cases to pick the best one
10:27:29  <_dp_> though k-d tree would probably work just fine for everything
10:28:00  <_dp_> good compromise between speed and simplicity
10:29:02  <andythenorth> bbl etc
10:29:03  *** andythenorth has quit IRC
10:29:23  <_dp_> but anyway finding some spatial library would be even better regardless of what structure it uses
10:48:11  <peter1138> _dp_, sure, but most people don't know *any* of them.
10:48:23  <peter1138> I never studied algorithms, and it shows.
10:48:49  <peter1138> Finding some spatial library is useful if you know you should be looking for a spatial library.
10:51:55  <peter1138> So I'm currently using an unordered_set to maintain a list of station catchment tiles.
10:52:02  <peter1138> What algorithms should I use instead? :p
10:53:53  <nielsm> bitmap with offset?
10:54:08  <nielsm> seeing it's most likely the catchment area is a rectangle-ish shape
10:54:32  <nielsm> i.e. most "set" bits are in a clump and most of the rest is clear
10:55:05  <Eddi|zuHause> storing a circumrectangle for early "not overlapping" tests?
10:55:12  <nielsm> for instance get the classic station rectangle bounds (orthogonal tile area), make a bitmap that size, and fill it in
10:57:20  <peter1138> Are you talking about when I am building the list or querying the list?
10:57:46  <peter1138> For querying we already know we are within this rect, otherwise we wouldn't be querying it.
10:57:59  <peter1138> Bitmap.
10:58:05  <peter1138> std::bitset?
10:58:15  <_dp_> peter1138, I kinda want to look for the library myself but have my hands full with citymania servers atm :(
10:58:19  <_dp_> Also want to find some solution for Tz0-Tz4 highlight as well
10:58:22  <_dp_> it's much harder as those damn things grow
10: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.
10: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
10:59:19  <_dp_> a bit of a patchpack-quality solution though as it needs hardcoded threshold
11: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?
11:02:40  <nielsm> I think so yes, find all candidate stations to have cargo supplied from industry
11:03:14  <peter1138> It's solved, just probably not using some fancy efficient algorithm, because I never studied algorithm.
11:04:28  <nielsm> wouldn't even a simple quadtree over towns, and one over stations, be useful in general, I wonder?
11:08:04  <peter1138> std::quadtree?
11:08:15  <peter1138> :(
11:08:18  <nielsm> I doubt that exists :)
11:09:01  <nielsm> it's just splitting two-dimensional space into four quadrants, and each quadrant containing multiple points are split into further quadrants
11:09:16  <nielsm> all equal splits
11:11:41  <_dp_> peter1138, and where is the bottleneck in your current implementation?
11:11:58  <_dp_> tile set is a reasonable thing, don't see yet why is it being slow
11:12:34  <peter1138> It's okay, I was just test it for all stations, which is a lot on a 4096^2 map.
11:13:39  <peter1138> That's improved by filtering on station catchment rect first, so the list of stations to test is much smaller.
11:13:46  <_dp_> peter1138, you mean max amount of stations? how much is that even?
11:13:59  <peter1138> There actually isn't a bottleneck at the moment.
11:14:09  <peter1138> But that doesn't mean things can't be improved.
11:14:38  <peter1138> Also there's a bit overhead (cpu and code-size wise) in maintaining nearby lists for towns and industries.
11:14:48  <peter1138> Dunno
11:15:12  <peter1138> https://fuzzle.org/~petern/ottd/wentbourne.sav
11:15:16  <peter1138> ^ this is my stress-test save.
11:15:35  <peter1138> Might be useful for testing station sign performance improvements too.
11: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.
11:21:35  <_dp_> peter1138, I shouldn't have opened that save on my laptop xD
11:21:39  <peter1138> Haha
11:21:50  <peter1138> It's 8 fps on my i7-8700k
11:22:29  <nielsm> it's rather heavy :P
11:23:34  <_dp_> and that's only 2k stations, when max is 0xFFFD it seems
11:23:54  <_dp_> @calc 0xFFFD * (64+20)**2
11:23:54  <DorpsGek> _dp_: 462400848
11:24:03  <peter1138> Ouch.
11:24:24  <peter1138> Wait, what's the (64+20)^2?
11:24:36  <_dp_> yeah, that's a lot of tiles... but I thought it would be worse tbh
11:24:45  <peter1138> Maximum catchment.
11:25:06  <peter1138> You probably can't fit that many on the map, though.
11:25:35  <_dp_> peter1138, there is more than enough space on 4k map :p
11:25:47  <_dp_> but yeah, it's getting unreasonable
11:26:02  <_dp_> @calc 5000 * (32+10)**2
11:26:02  <DorpsGek> _dp_: 8820000
11:26:24  <peter1138> 2^4096
11:26:30  <_dp_> not that bad
11:26:35  <peter1138> Wrong dimension :D
11:26:47  <peter1138> 16777216 tiles
11:27:00  <peter1138> Is somewhat less than 462400848
11:27:43  <_dp_> peter1138, yeah, but more than 0xFFFD stations
11:27:56  <_dp_> 462400848 is the max possible number of catchment tiles
11:28:01  <_dp_> that I got wrong btw
11:28:08  <_dp_> @calc 0xFFFD * (64+16*2)**2
11:28:08  <DorpsGek> _dp_: 603952128
11:28:26  <peter1138> Why 16*2?
11:28:49  <peter1138> Max catchment is 10, so 64+20 was correct.
11:28:51  <_dp_> damn, nwm, that was right
11:29:11  <_dp_> I thought it's 0x10 for some reason xD
11:30:15  <peter1138> :)
11:30:42  *** andythenorth has joined #openttd
11:43:38  <andythenorth> well
11:44:36  <peter1138> That's true.
11:46:12  <andythenorth> so I should redesign Horse to use vehicle variants? o_O
11:51:42  <peter1138> Yes.
11:51:46  <peter1138> No.
11:51:50  <peter1138> You're just procrastinating it.
11:52:14  <peter1138> Do you want vehicles to automatically change appears/specs over time?
11:52:19  <andythenorth> do I?
11:52:33  <peter1138> Do you want vehicles to be able to be repainted or upgraded over time?
11:52:45  <andythenorth> I already removed that from 2 newgrfs :)
11:52:51  <andythenorth> so nah
11:53:02  <andythenorth> auto-replace between variants, right?
11:53:08  <peter1138> Variants would require autoreplace to change their stuff.
11:53:09  <peter1138> Yes.
11:53:17  <peter1138> Basically they become independent.
11:53:22  <andythenorth> yeah, so they're different IDs so just use autoreplace
11:54:13  <peter1138> "Operation on non-blocking socket would block." Uhmm.. hmm..
11:54:15  <andythenorth> so....what happens if one variant is an engine and another is a wagon? o_O
11:54:40  *** WWacko1976-work has quit IRC
11:54:44  <peter1138> You wouldn't be able to autoreplace between them.
11:55:01  <andythenorth> will they appear in the same group?
11:55:05  <peter1138> Presumably.
11:55:06  <andythenorth> in the buy menu
11:55:24  <peter1138> Like it'd be a loading error.
11:55:30  <peter1138> *likely
11: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
12: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?
12:08:00  <andythenorth> hmm
12:08:04  <andythenorth> FIRS Steeltown is broken
12:08:19  <peter1138> Oh no.
12:08:30  <andythenorth> oh yes
12:08:41  <andythenorth> time to start FIRS 4
12:08:47  <Eddi|zuHause> i did finally find an aluminium deposit for a whooping 2 aluminium
12:08:50  <andythenorth> and 64 cargos and stuff
12:09:07  <Eddi|zuHause> now i can build trailers for my tractor, or something else
12:11:58  <andythenorth> hmm
12:12:00  <andythenorth> cryo tankers?
12:12:18  <andythenorth> probably just use 'tank car' already :P
12:14:04  <andythenorth> the thing about changing FIRS
12:14:15  <andythenorth> it breaks my savegames really frequently :P
12:28:09  <andythenorth> so does a cryo plant increase production if ENSP are delivered?
12:28:14  <andythenorth> or is it fixed output? o_O
12:28:18  <DorpsGek_II> [OpenTTD/OpenTTD] citymania-org commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5ha
12:29:58  <peter1138> and?
12:30:46  <Eddi|zuHause> i think there's something
12:32:08  <andythenorth> cliffhanger
12:32:25  <Eddi|zuHause> legen... wait for it...
12:32:48  <andythenorth> hmm
12:33:06  <andythenorth> 64 cargos, 52 of them different subtypes of common metals? o_O
12:33:13  * andythenorth wonders
12:33:31  <peter1138> Hah
12:33:36  <nielsm> 20 grades of steel
12:34:00  <Eddi|zuHause> so essentially just random numbers? :p
12:34:11  <andythenorth> pig iron, cast iron, molten iron
12:34:23  <andythenorth> steel, stainless steel, specialty steel
12:34:30  <peter1138> Damascus steel
12:36:07  <Eddi|zuHause> i meant these quality numbers like "301"
12: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
12:36:55  <nielsm> I should maybe try the same for stations
12:37:22  <nielsm> right now I'm not actually sorting the items across the dimension, just taking the first element and praying :P
12:38:14  <andythenorth> reynolds 301
12:38:49  <andythenorth> I gave away my Raleigh bike with a Reynolds 301 frame
12:38:50  <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5hH
12:38:53  <andythenorth> it was crap
12:39:01  <andythenorth> now it sells on ebay for ££
12:40:33  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5h7
12:41:02  <nielsm> 2263 stations tree built in 30 ms
12:41:19  <nielsm> that's rather slow, wouldn't want to rebuild that all the time
12:41:40  <peter1138> Is it quick to add/remove individually, or does it need to rebuild?
12:42:03  <nielsm> "depends" :P
12:42:27  <nielsm> I haven't actually written a function to insert into the tree
12:42:40  <nielsm> or look up in it
12:43:29  <Eddi|zuHause> these tree structures are usually written for insert and lookup operations, not complete rebuilding
12:45:06  <nielsm> yeah I should probably aim to make a balanced tree initiall, even if the cost is higher
12:45:17  <nielsm> then maybe have a dumb insert without rebalancing'
12:45:47  <_dp_> peter1138, oops, didn't notice it was unfinished
12:45:53  <nielsm> I'm not sure how to rebalance a tree of this type
12:45:58  <_dp_> tbh I'm not sure where is it heading myself xD
12:50:49  <peter1138> Heh
12:51:10  <peter1138> Also, I really like the temporary tile highlight in my patch, would be good as a separate PR :D
12:52:37  <peter1138> https://fuzzle.org/~petern/ottd/towncatchment2.png < this one
12:55:25  <_dp_> peter1138, how does it choose town for red highlight?
12:55:53  <_dp_> but yeah, highlights are good, we need more of them :)
12:55:56  <peter1138> It can only showing the catchment of 1 town.
12:56:00  <peter1138> -ing
12:56:14  <_dp_> it's just they look a bit ugly like that
12:56:39  <peter1138> In what way?
12: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.
12:58:05  <nielsm> https://0x0.st/ziTQ.png  now it's slow!!
12:58:31  <peter1138> Hmm.
12:59:23  <peter1138> Caek time!
12:59:46  *** Gabda has joined #openttd
12:59:52  <Gabda> hi
13:00:13  <Gabda> question about poiners stored in vector
13:00:19  <nielsm> https://0x0.st/ziT1.png   <-- looks much more balanced now
13:00:23  <Gabda> https://github.com/OpenTTD/OpenTTD/pull/7242/files#diff-06bd4ba3f3d3562bbd2bfab378786ca4R343
13:01:00  <Gabda> if more towns are added, and they get reallocated
13:01:10  <Gabda> would this vector break?
13:01:11  <nielsm> towns don't get reallocated
13:01:23  <nielsm> they're stored in a pool of fixed size
13:01:42  <nielsm> neither do stations, industries, vehicles
13:02:00  <Gabda> so I can store the memory addresses without problem?
13:02:04  <nielsm> yes
13:04:02  <Gabda> and should I?
13:04:17  <Gabda> or storing the indexes would be better?
13:06:11  <peter1138> Depends if you need the pointer or just the index.
13:06:59  <Eddi|zuHause> is looking up the pointer from the index really a troublesome operation?
13:07:10  <nielsm> it's not :)
13:07:18  <nielsm> storing the index will typically save memory
13:07:33  <peter1138> Save a tiny amout of memory.
13:07:46  <nielsm> 2 or 6 bytes depending on 32 or 64 bit
13:07:59  <nielsm> but depending on amount of data it can add up :P
13:08:18  <Eddi|zuHause> we're talking about maybe 3000 towns?
13:10:19  <peter1138> Actually how does it achieve this resizing? I see a ReallocT...
13:11:17  <nielsm> faster in release build :P https://0x0.st/ziTL.png
13:11:57  <peter1138> Oh, yes.
13:12:11  <peter1138> Not much point testing a debug build for performance, only correctness.
13:12:46  <Gabda> oh, you are building a kdtree?
13:12:55  <nielsm> yeah trying to make a generic thing
13:13:00  <nielsm> generic-ish
13:13:45  <Gabda> splitting by tile x-y or col-row?
13:13:56  <peter1138> Oh really.
13:13:58  <nielsm> tily x/y
13:14:30  <peter1138> The pool is just a lot of individual allocations, not a big block split up.
13:14:34  <nielsm> I suppose it could just as well split by screen coordinates
13:14:53  <peter1138> So the realloc is just for the part of the pool that stores the pointers to the actual items.
13:15:12  <peter1138> I always assumed it was an actual proper pool :
13:15:13  <peter1138> :p
13:15:38  <Gabda> i was thinking about is splitting by col-row would make the "circle" when searching a point touch less bounding rectangles
13:15:53  <Gabda> as a speciality of manhattan
13:16:44  <Gabda> is -> if
13:16:46  <nielsm> https://github.com/nielsmh/OpenTTD/commit/efa3f009afdfc74ef52c3276bcbf8f1f5734bd03
13:18:38  <peter1138> Can this be used to find stations near an industry?
13:18:43  <peter1138> Asking for a friend.
13:18:48  <nielsm> that would be one use case
13:19:28  <peter1138> Hmm, how do you get information from it?
13:19:39  <nielsm> right now you don't :P
13:19:48  <peter1138> Right, so I wasn't missing anything :)
13:22:12  <Gabda> tgi
13:22:24  <Gabda> this will be interesting :)
13:22:59  <Gabda> (I am writing from mobile, tgi was a random char seq.)
13:24:08  *** Flygon_ has quit IRC
13:26:58  <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdeI
13:27:35  <Eddi|zuHause> between looking at the sky and looking at the ground, my fps drops to 1/4
13:31:37  <_dp_> totally random idea: turn Tile type into separate array for each field
13:31:40  <_dp_> coz CPU cache
13:33:39  * andythenorth wonders whether carbon black justifies a train :P
13:35:11  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdeW
13:35:30  <peter1138> _dp_, tile type?
13:35:36  <peter1138> You mean like it used to be?
13:35:43  <peter1138> _m8[t]
13:35:50  <andythenorth> apparently https://c8.alamy.com/comp/DB6ND9/hopper-cars-carrying-carbon-black-on-bnsf-freight-train-at-perry-oklahoma-DB6ND9.jpg
13:36:10  <andythenorth> also these are quite unique looking trucks http://cltautotrasporti.it/wp-content/uploads/2015/07/cb-03.jpg
13:38:13  <_dp_> peter1138, yeah
13:38:35  <peter1138> Doable. It was merged before the map accessors were created.
13:38:51  <peter1138> Worth benchmarking it.
13:41:23  <peter1138> nielsm, why uint16 for your node index/coordinates?
13:42:21  <nielsm> please don't ask
13:42:24  <peter1138> Oh.
13:42:48  <peter1138> Also, put T element first, for alignment reasons.
13:43:01  <peter1138> Not that it matters I suppose.
13:43:17  <peter1138> uint16 could probably be a template parameter.
13: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.
13:48:42  *** andythenorth has quit IRC
13:50:58  <_dp_> peter1138, which "iterate" is you talking about?)
13:51:31  <peter1138> 2.
13:52:02  <peter1138> FindStationsAroundTiles doesn't iterate the set, at least not in my understanding of iterators.
13:52:28  <_dp_> peter1138, ctrl-f "iterate" only finds your last comment ;)
13:54:16  <nielsm> does this look right? :)  https://0x0.st/ziTy.txt
13:54:35  <nielsm> so many sigils
13:55:13  <peter1138> Ah you said "loop"
13:55:17  <peter1138> catchment_tiles loop
13:55:48  <peter1138> I don't loop on the catchment tiles, but there is a test inside a loop, yeah.
13:57:20  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
13:57:49  <peter1138> ^^
13:58:03  <peter1138> AddNearbyStations() is basically just converting from std::set to StationList :p
14:01:09  <_dp_> "So a loop of (catchment + area)**2 tiles" I meant the loop before your changes
14:01:42  <_dp_> also I'm talking about FindStationsAroundTiles, you nhir
14:01:48  <_dp_> still have w*h here
14:02:41  <Eddi|zuHause> i'm trying to follow your discussion, but neither of your statements make much sense
14:02:45  <peter1138> Yeah, 1*1 or 2*2 are the only occurrences.
14:03:04  <peter1138> Not 64x64 or anything like that.
14:03:23  <Eddi|zuHause> there are 2*1 houses
14:03:40  <_dp_> ah, "town->stations_near->catchment_tiles loop" yeah, ignore that one)
14:03:43  <peter1138> Houses are 1x1, each part produces individually on different tickets.
14:03:54  <_dp_> I meant stations_near loop there
14:03:59  <peter1138> The only thing which is 2x2 is... Company HQ.
14:04:13  <peter1138> stations_near is pretty tiny.
14:04:29  <_dp_> peter1138, don't industries also use FindStationsAroundTiles?
14:04:47  <peter1138> Not any more. I checked the flow and it's unnecessary.
14:04:52  <_dp_> peter1138, well, it depends on how many stations are there
14:05:03  <peter1138> Because i->stations_near already contains exactly the info which is needed.
14:05:35  <peter1138> We're talking low tens, not hundreds or thousands.
14:05:46  <peter1138> Hmm, this threading is getting confusing :)
14:06:03  <_dp_> xD
14: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.
14:06:56  <_dp_> peter1138, well, we're comparing it to tens (max 20) tile search rows
14:07:16  <Eddi|zuHause> how do you get "max 20"?
14:07:20  <peter1138> For houses, I determined that it's always 1x1, so took the loop out.
14:07:23  <peter1138> _dp_, 20^2
14:07:27  <peter1138> So yeah, 400 tiles.
14:07:32  <peter1138> Eddi|zuHause, MAX_CATCHMENT is 10.
14:07:36  <peter1138> Actually it's 21x21
14:07:41  <peter1138> 441
14:08:01  <_dp_> peter1138, 20 rows, one row is one operation basically for cpu, I'm pretty sure of that
14:08:02  <nielsm> finally got it wrangled to compile...
14:08:14  <peter1138> Err...
14:08:18  <peter1138> What?
14:08:37  <peter1138> I don't think that's actually the case.
14:09:21  <_dp_> peter1138, vectorization+l1 cache
14:09:33  <_dp_> peter1138, compared to set lookup I'd bet on row search
14:09:35  <Eddi|zuHause> in what mythical data structure does checking one row (for what?) consist of one single instruction?
14:10:46  <_dp_> Eddi|zuHause, I don't mean literally one operation,  but CPUs are very very very good at optimizing stuff like that
14: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) ...
14:10:53  <peter1138> the doesn't sound like one operation to me.
14:11:06  <peter1138> I don't think it'll be optimizing that into a one-op row.
14:11:41  *** Progman has joined #openttd
14:11:53  <peter1138> (_settings_game.station.modified_catchment ? MAX_CATCHMENT : CA_UNMODIFIED);
14:12:00  <peter1138> I could apply that optimization, woo.
14:14:22  <_dp_> peter1138, hmm, ok, mb I got too carried away thinking how fast it could be not how it actually is xD
14:14:35  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
14:15:22  <peter1138> I wonder about std::bitset.
14:15:24  <_dp_> peter1138, checking station for each tile probably doesn't cache well indeed
14:15:36  <peter1138> And its' not just that op :-)
14:15:46  <peter1138> And you can't skip early once you have one, because you need them all.
14:16:02  <peter1138> (Although you can skip the distance tests when you've already included one)
14:16:06  <_dp_> peter1138, hm, or mb it does, since most checks lead to same station so it can cache
14:16:20  <_dp_> peter1138, also you can build list first and check stations later
14:16:28  <nielsm> hm what's the easiest way to get a plain string of a station name (for console printing)
14:16:40  <_dp_> bitset I've no idea how good is
14:16:52  <_dp_> kinda hard to screw up something this simple so should be ok xD
14:17:13  <Eddi|zuHause> so, how then is building a list of stations faster than taking the list of stations we already built before?
14:17:31  <peter1138> Ok, bitset is an issue.
14:17:40  <peter1138> bitsets are fixed size.
14:18:15  <peter1138> 7225 bits for each one.
14:18:21  <peter1138> I don't think that's even a memory optimization.
14:18:46  <Gabda> nielsm, I am interested in that as well
14:19:00  <peter1138> I'm getting confused.
14:19:09  <_dp_> peter1138, you mean it pre-allocates that much? can't it be changed?
14:19:20  <peter1138> It's std::vector<bool> that can be variable, and is also optimized especially for bools.
14:19:32  <peter1138> _dp_, yeah, std::bitset<size> is a template parameter.
14:19:39  <nielsm> Gabda: https://0x0.st/ziTx.txt
14:19:43  <peter1138> So std::vector<bool> is doable.
14:19:44  <nielsm> try that
14:20:05  <nielsm> hmm no
14:20:13  <nielsm> unless it prints in black on black
14:20:14  <_dp_> only thing I know about std::vector<bool> is that is a failure of an std container xD
14:20:21  <peter1138> Well then.
14:21:04  <_dp_> doesn't mean it works bad, just not a proper container :)
14:21:23  <nielsm> ah this works
14:21:25  <_dp_> coz you can't take & of an element
14:21:40  <nielsm> Gabda: https://0x0.st/ziT3.txt
14:21:55  <nielsm> https://0x0.st/ziTY.png
14:22:01  <nielsm> now to check if it's actually correct :D
14:22:28  <peter1138> So a 4x2 rail station would be ... 15 bytes, not at least 120.
14:22:51  <peter1138> Storing tileindex is pretty wasteful, certainly.
14:23:11  <nielsm> hmm no, it seems to do something wrong
14:23:22  *** sla_ro|master has joined #openttd
14:23:39  <peter1138> _dp_, it's useful discussion cos I found those optimizations.
14:23:44  <Gabda> the printing or the algorithm to find the nearest station?
14:23:49  <peter1138> And there's more to do.
14:24:48  <_dp_> I'd probably just make an uint8 * though for a bit map instead of fancy containers
14:25:16  *** kiwitree has joined #openttd
14:26:24  <_dp_> all you need is like i = y * w +x ; a[i>>3][i&7]
14:26:52  <_dp_> oops, a[i>>3]&(1<<(i&7)) :)
14:27:39  <peter1138> Hmm, it would need to assume MAX_CATCHMENT.
14:27:48  *** m3henry has joined #openttd
14:27:54  <m3henry> https://stackoverflow.com/questions/17794569/why-is-vectorbool-not-a-stl-container
14:27:57  <peter1138> (Or you can iterate the tiles twice)
14:28:04  <m3henry> Woo log stalking
14:28:07  <peter1138> Spies are lucking again.
14:28:12  <peter1138> LURKING
14:28:30  <m3henry> Sapping mah sentry?
14:29:01  <peter1138> I remember when TF2 was fun.
14:29:11  <peter1138> 10 years ago :/
14:29:19  <_dp_> peter1138, why MAX_CATCHMENT?
14: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?
14:29:54  <_dp_> Eddi|zuHause, it's just a HasBit :p
14:29:56  <m3henry> sweet mary mother of god
14:30:03  *** sla_ro|master has quit IRC
14:30:37  <peter1138> Hmm, actually no need to scan the tiles, duh...
14:30:38  <Eddi|zuHause> _dp_: we already have a HasBit...
14:30:42  <peter1138> GetStationCatchment() would be fine.
14:31:37  <peter1138> Eddi|zuHause, HasBit(x[i >> 3], i & 7) isn't that much clearer.
14:31:57  <peter1138> (And is probably wrong)
14:32:39  <peter1138> HasBit(x[i / 8], i % 8) is kinda clearer in its intentions, but %...
14:32:40  <_dp_> fun part is doing range query on bitset xD
14:32:57  *** sla_ro|master has joined #openttd
14:33:17  <_dp_> peter1138, compilers are probably smart enough to optimize
14:33:28  <peter1138> --debug-level=3
14:33:47  <peter1138> So my next task is to make adding a new industry *not* wipe out all the caches.
14:33:52  <peter1138> It jus needs to add.
14:33:52  <Eddi|zuHause> peter1138: got to hope that the compiler knows to optimize / and % with power-of-two constant
14:33:54  <peter1138> *just
14:34:05  <peter1138> Eddi|zuHause, / 8 definitely, % 8 maybe not. maybe.
14:34:14  <_dp_> peter1138, well, benchmarking without optimization is not a good idea anyway)
14:34:17  <m3henry> Eddi: compilers have been doing that for a long long time, don't worry
14:34:23  <Eddi|zuHause> peter1138: i don't see how one would be more difficult than the other
14:34:36  <peter1138> Probably not.
14:34:54  <Eddi|zuHause> peter1138: and on CPU level, both are the same operation, usually
14:35:34  <m3henry> Compilers have been optimising non-power-of-two divides and multiplies for quite a while too
14:35:45  <peter1138> Of course, with a uint8 * i have to mess about with memory allocation of it.
14:35:46  <Eddi|zuHause> if your CPU has an integer-div operation, it usually outputs both div and mod at the same time
14: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.
14:36:15  <Eddi|zuHause> (however, the point here is to avoid the integer-div in the first place)
14:36:58  <nielsm> where is std::optional when you need it
14:36:58  <_dp_> peter1138, station constuction doesn't happen very often, it's totally fine to rebuild
14:37:03  <nielsm> (it's in c++17)
14:41:26  *** sla_ro|master has quit IRC
14:41:56  <m3henry> Eddi|zuHause: https://godbolt.org/z/KnxEl7
14:43:39  <Eddi|zuHause> m3henry: i'm pretty sure i read about that before, but the asm is pretty meaningless to me
14:44:10  <m3henry> The important thing to note is there is no idiv indtruction for the divide-by-constant
14:44:10  *** sla_ro|master has joined #openttd
14:45:59  <peter1138> https://godbolt.org/z/VioV4R < "n / 8" is different to "n >> 3"
14:46:48  <nielsm> because of negative numbers behavior it looks like
14:46:53  <Eddi|zuHause> there's weirdness with signed vs unsigned
14:46:56  <peter1138> ah of course
14:47:05  <m3henry> Did you mean https://godbolt.org/z/gwY6VT
14:47:13  <peter1138> Yes, same with uint
14:48:03  <peter1138> % 9 is nice ;)
14:48:21  <peter1138> % 7 is even longer.
14:49:27  *** sla_ro|master has quit IRC
14:49:50  <Eddi|zuHause> %257 is fun :)
14:50:06  *** sla_ro|master has joined #openttd
14:53:38  <peter1138> _dp_, and to be fair, it's what we already do anyway.
15:00:32  <_dp_> peter1138, you mean stating rect rebuilding? bitmap is a bit heavier but whatever, player actions are rare
15:01:26  <_dp_> peter1138, btw, have you considered separating non-rectangular area patch from nearest caches?
15:01:41  <_dp_> peter1138, bitmap should take care of all the performance differences anyway
15:02:34  <peter1138> I thought about it but I changed many algorithms since as they didn't make sense with the cache in place.
15: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.
15:04:04  <nielsm> okay, got the nearest item search working in the tree
15:04:12  <peter1138> It could probably be split if I include the station distance check, but the FOR_ALL_STATIONS was the killer.
15:04:20  <_dp_> peter1138, it would just make it much more straightforward
15:04:22  *** snail_UES_ has joined #openttd
15:04:33  <_dp_> peter1138, caches are quite questionable and need a lot of benchmarking
15:06:01  <peter1138> Without the caches I saw 5ms per world tick, instead of 2ms.
15:06:13  <peter1138> I suppose it isn't alot but it's still significant.
15:06:22  <peter1138> That is with the station distance check in place.
15:06:29  <_dp_> peter1138, that's with unordered_set, right?
15:06:46  <peter1138> Yes, but with the distance check so it doesn't check that much.
15:08:31  <peter1138> bHmm, it's not quite the original patch, as that made it a third catchment type option, which was downvoted :p
15:10:36  *** snail_UES_ has quit IRC
15:16:41  <peter1138> Without the caches, we're resorting to scanning 441 tiles again.
15:17:31  <_dp_> ha, new idea
15:17:31  <peter1138> 441 tiles, and some tests on those tiles, vs iterating a list with a few items in it.
15:17:56  <_dp_> for each tile keep a set of catching stations but DO NOT DUPLICATE sets, point to the same one
15:18:10  <_dp_> a bit hard to work with but super fast lookups
15:18:10  <peter1138> ?
15:18:13  <peter1138> For each tile do what?!
15:18:28  <peter1138> ...
15:18:34  <peter1138> I'm not storing a list of nearby stations for every tile.
15:18:49  <_dp_> make a set of stations that contain that tile in their area
15:19:17  <_dp_> many tiles have same sets so you only need to store a pointer to a set
15:19:27  <_dp_> and there are not many different sets
15:19:28  <peter1138> Store where?
15:20:03  <_dp_> make another map array
15:20:06  <peter1138> o_O
15:20:15  <_dp_> I know I was agains it but that was for highlights :p
15:20:16  <peter1138> Okay now I know you are taking the piss >:
15:22:00  <_dp_> well, it's still much less memory than bitmaps worst case :p
15:22:18  <_dp_> not sure if it actually eliminates the need for those bitmaps though
15:23:44  <peter1138> If you don't store catchment list then you need to rescan the station rect.
15:25:33  <peter1138> Also I've wasted most of the day talking about this, and I'm supposed to be working. :/
15:26:06  <Eddi|zuHause> i know that feeling
15:26:15  <_dp_> xD
15:26:20  <Gabda> I see you with your new map array idea :P
15:36:54  <nielsm> https://0x0.st/ziAN.jpg
15:36:56  <nielsm> yay
15:37:22  <peter1138> Now that might be useful.
15:38:25  <peter1138> Although a map scan might've been quicker? I dunno.
15:38:36  <peter1138> Needs a larger are :p
15:38:39  <peter1138> *area
15:39:19  *** Samu has joined #openttd
15:40:56  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdUW
15:42:32  <nielsm> https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:kdtree
15:43:00  <Samu> hi
15:44:13  *** drac_boy has joined #openttd
15:44:24  <drac_boy> hi there to anyone else with a sunny sky ;)
15:44:25  <drac_boy> heh
15:44:41  <nielsm> sun's about to set here so... maybe hi?
15:45:08  <drac_boy> heh evening then nielsm :)
15:47:21  <drac_boy> doing anything or just slow night for now?
15:48:39  <nielsm> writing a k-d tree data structure that might be useful for speeding up lookups of towns/stations by map coordinates
15:49:43  <drac_boy> ah..ok
15:51:11  <Samu> it's raining here
15:51:13  <Samu> finally
15:53:10  *** Wormnest has joined #openttd
15: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
15:56:32  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdUQ
16:01:04  <Samu> who's english?
16:01:05  <Samu> static const uint RIVER_OFFSET_DESERT_DISTANCE = 5; ///< Radius around river tiles without Desert Zone
16:01:50  <Samu> Radius around river tiles to unset Desert Zone
16:03:22  <Samu> Circular search radius to create non-desert around a river tile.
16:03:51  <peter1138> As opposed to a square radius?
16:04:02  <Samu> it's a circultar tile search
16:04:08  <Samu> circular
16:04:17  <Samu> ok i put tile
16:04:27  <Samu> static const uint RIVER_OFFSET_DESERT_DISTANCE = 5; ///< Circular tile search radius to create non-desert around a river tile.
16:05:34  <Eddi|zuHause> in maximum or manhattan distance, circles are square
16:05:53  <Samu> I don't know, it's a CircularTileSearch
16:06:09  <Samu> i think it's square
16:07:57  <Samu> CircularTileSearch(&t, RIVER_OFFSET_DESERT_DISTANCE, RiverModifyDesertZone, NULL);
16:11:24  *** sla_ro|master has quit IRC
16:15:39  <Eddi|zuHause> i'm pretty sure CircularTileSearch uses maximum distance
16:16:19  <Samu> copy pasting title from one of peter1138 commits
16:17:23  <peter1138> Hah
16:17:29  <Samu> Codechange: Use const instead of magic number for circular tile search radius to create non-desert around a river tile.
16:18:18  <Eddi|zuHause> have i mentioned today yet that the game should use euclidean in more places, to be more intuitive?
16:18:28  <peter1138> Not today.
16:18:35  <peter1138> euclidean catchment size?
16:18:41  <Eddi|zuHause> for example
16:19:00  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7194: Fix: Remove desert around lakes upon generation. https://git.io/fhHqA
16:19:42  <Eddi|zuHause> (that, however, might actually break some people's savegames :p)
16:19:54  <Gabda> manhattan distances are nice
16:19:55  <peter1138> "break"
16:20:11  <Eddi|zuHause> s/savegames/networks/
16:20:14  <peter1138> Non-rectangular catchments is going to do that.
16:20:19  <Gabda> they deserve love as well :)
16:20:52  <drac_boy> :)
16:20:56  <Eddi|zuHause> well, theoretically it would, but most people won't notice :p
16:21:06  <peter1138> Yeah.
16:24:11  <nielsm> https://0x0.st/ziAG.png   uhm... yeah, are you planning on making an IE 12 or what?
16:25:50  <Gabda> nielsm: in build, why do you start buildsubtree from begin+1, what happens to the very first element?
16:26:48  <nielsm> it gets discarded!
16:27:28  <drac_boy> nielsm or someone messed up with the numpad and entered wrong version? :)
16:27:35  <nielsm> bug from when I was building the tree differently
16:28:04  <nielsm> and funny you should mention it just now, because it was exactly the cause of the crash I was getting here
16:29:26  <Samu> I have questions about this https://github.com/OpenTTD/OpenTTD/pull/7234/files#diff-ebbc445f07842947d83d0f98b7fa5140R1050
16:29:29  *** m3henry has quit IRC
16:29:39  <Samu> must re-test
16: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
16:33:01  <Gabda> well, I am reading your code to learn new things
16:33:27  <Gabda> already saw some new and fine things
16: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)
16:43:40  <peter1138> Samu, so many questions...
16: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
16:45:18  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdTH
16:49:03  <Samu> what I used to have was 3 checks, now it's down to just 1
16:49:57  <nielsm> well, I tried making actual use of the tree and initial smoke testing does not cause explosions!   https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:kdtree
16: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
16:51:03  <nielsm> could, yes
16: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
17:01:19  <peter1138> nielsm, does that... work? :D
17:01:39  <nielsm> it seems like it works right now, yes
17:01:50  <nielsm> for getting nearest town
17:02:05  <peter1138> Need the tile highlight test that Gabda did
17:02:07  <Samu> if the station is mine and there's an industry without neutral station, will the cargo go to the industry
17:02:07  *** sla_ro|master has joined #openttd
17:02:09  <peter1138> If it works and is fast...
17:02:11  <peter1138> Then brilliant.
17:02:26  <Samu> how could you reduce 3 checks to just 1
17:02:30  <Samu> and still make it work
17:02:32  <Gabda> ok, it improves performance on big item counts only
17:02:55  <Samu> I must be really dumb
17:03:23  <drac_boy> samu or not dumb but just slower?
17:03:28  <drac_boy> I dunno
17:03:36  <Eddi|zuHause> Gabda: that's usually when you need performance the most :p
17:03:37  <peter1138> Samu, probably ;)
17:04:04  <Samu> if (ind->st != NULL && ind->st != st) continue;
17:04:11  <Gabda> i was thinking about making a kdtree as well, but dropped the idea, because I got scared of rebalancing it
17:04:36  <Gabda> but it is really nice to see your implementation
17:05:19  <nielsm> huh, I didn't realize SmallVector already had both Contains and Include that effectively implement a "stupid set"
17:05:26  <nielsm> (linear search membership test)
17:05:40  <Samu> if ind->st != NULL
17:05:54  <Samu> if the industry has neutral station
17:05:59  *** andythenorth has joined #openttd
17:06:01  <Gabda> Eddi: yes, but it can be a next step, as the current version is also a big improvement
17:06:39  <Samu> what if the industry doesn't have neutral station
17:07:08  <nielsm> then it does the normal thing
17:07:24  <Samu> what if the station I'm delivering at
17:07:27  <Samu> is a neutral station
17:07:44  <nielsm> actually, you're not reading it
17: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
17:08:22  <nielsm> if (ind->st != NULL && ind->st != st)  <- if the industry has a neutral station AND that station is not this station
17:09:10  <Samu> what if the industry doesn't have a neutral station and I'm delivering at some other industry's neutral station?
17:09:43  <nielsm> then you look a station.cpp line 359
17:10:10  <nielsm> and discover that those industries are already separated out earlier
17:10:34  <Samu> ah
17:10:55  <drac_boy> hmm I guess italy does seem to be alone then
17:11:21  <andythenorth> yo
17:11:31  <supermop_work> HI ANDY
17:11:48  <andythenorth> is cat?
17:12:15  <andythenorth> hmm
17: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
17:12:22  <andythenorth> I like how JGR gets the tailspin of OpenTTD bugs
17:12:24  <andythenorth> :|
17:12:35  <andythenorth> things that are fixed upstream, but not in JGRPP
17:12:51  <drac_boy> hi firs creator :)
17:12:52  <drac_boy> heh
17:13:06  <Gabda> but that can be done with recurssions, true
17:14:16  <andythenorth> so 'Hot Metal' or 'Molten Iron'?
17:14:35  *** HerzogDeXtEr has joined #openttd
17:14:36  <andythenorth> hot metal is the IRL term in steel industry, but it's not obvious in game
17:14:39  <Samu> so it works
17:14:40  <drac_boy> andy is it supposed to be pre-poured metal?
17:14:43  <Samu> oki
17:15:04  <andythenorth> https://st3.depositphotos.com/11171026/16639/i/1600/depositphotos_166393228-stock-photo-molten-iron-molten-metal-poured.jpg
17:15:17  <drac_boy> andy if it is I would had called it molten then
17:15:24  <drac_boy> oh..yeah I would say molten for sure :)
17:15:51  <drac_boy> as 'hot metal' could suggest blacksmithing/welding which isn't exactly "as that hot"
17:16:41  <drac_boy> any other cargo related questions you might have on mind now andy? :)
17: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
17:23:07  <andythenorth> supermop_work: played any Horse? o_O
17:24:30  <nielsm> not that it matters, it's not a station tree I have here but a town tree
17:24:46  <nielsm> (nothing ever queries a tile area for towns, does it?)
17:25:31  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick updated pull request #7158: Add: Client setting gui.start_spectator https://git.io/fhSk4
17: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
17: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
17:29:07  <nielsm> Eddi|zuHause, not looking for ideas for new things to do just yet :P
17:29:38  <Eddi|zuHause> nielsm: i'm an expert at derailing by feature request :p
17:31:08  <andythenorth> hmm
17:31:22  <andythenorth> so what supplies would a cryo plant need?  If any? https://en.wikipedia.org/wiki/Industrial_gas#Gas_production_technology
17:31:37  <andythenorth> (air products cryo, not methane)
17:32:09  <drac_boy> well andy you could technically just feed it Chemical from the firs refinery?
17:32:18  <andythenorth> no refinery in this economy
17:32:29  <drac_boy> ah hm dunno then sorry :)
17:37:06  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick opened pull request #7243: Change: Decrease the min #opcodes https://git.io/fhdIq
17:37:06  <peter1138> Hi.,
17:37:39  <peter1138> Hmm, I should test subsidies.
17:38:25  <peter1138> Error: Assertion failed at line 3803 of /home/petern/Projects/OpenTTD/src/station_cmd.cpp: location.w == 1 && location.h == 1
17:38:28  <peter1138> Yay, it crashes ;D
17:38:46  <peter1138> Unfortunately, that was Wentbourne, after a few days.
17:39:05  <peter1138> If I try to run Wentbourne in a debug build, it'll take literal days...
17:39:53  <Eddi|zuHause> you could start with debug level 1?
17:40:07  <peter1138> No, backtraces are fairly useless.
17:40:17  <peter1138> I'm just going to grep for all callers first :-)
17:41:04  <Eddi|zuHause> also, you could make a savegame closer to the crash
17:41:20  <peter1138> Or make a smaller savegame.
17:41:52  <nielsm> it would be useful with some debug commands like "create a new subsidy right now"
17:42:38  <Eddi|zuHause> can a game script issue subsidies?
17:43:07  <peter1138> q
17:43:20  <peter1138> Whenever you see "q" I means I did ESC : q in the wrong window.
17:43:24  <peter1138> *it
17:44:10  <Eddi|zuHause> it usually says :q in those cases
17:44:52  <peter1138> irssi responds to ESC as well.
17:45:00  <peter1138> Arrrr
17:45:14  <peter1138> That's a few seconds per frame.
17:47:02  <peter1138> ...
17:47:23  <peter1138> I see, this is obvious and I'm surprised it hasn't happened before.
17:48:00  <peter1138> Top corner of an industry is a hole so i->location is not actually an industry tile...
17:48:08  <nielsm> https://0x0.st/zim1.png  <- no crashes!
17:48:24  <peter1138> Good.
17:48:39  <peter1138> Using the kdtree to determine which signs to draw?
17:48:53  <peter1138> Or just adding stations
17:48:55  <nielsm> no, just which town is nearest
17:49:00  <peter1138> Ahh
17:49:00  <nielsm> when adding stations
17:49:18  <peter1138> Performance?
17:49:21  <nielsm> difference is this was a new generated world and I wrote an Insert function on the tree :P
17:49:26  <nielsm> not measured
17:49:26  <peter1138> :D
17: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
17:50:01  *** drac_boy has left #openttd
17:50:20  <nielsm> noooooo
17:50:32  <nielsm> I started the scenario editor and placed a single town and it asserted :(
17:50:41  <peter1138> Haha
17:50:48  <nielsm> I know what the issue is though
17:54:23  <nielsm> https://0x0.st/zimj.png  <- created by building some random towns in the editor
17:56:11  <nielsm> https://0x0.st/zime.png  <- and then I clicked "build many random towns" which will do a full tree rebuild afterwards
17:58:32  <nielsm> pushed that
17:59:00  <Eddi|zuHause> push it real good
17:59:23  <Eddi|zuHause> (anyone even remember that song?)
17:59:39  <andythenorth> time to move newgrfs to github?
18:00:50  <peter1138> Yes please
18:03:00  *** synchris has joined #openttd
18:03:09  *** sla_ro|master has quit IRC
18:04:05  <andythenorth> means I might be able to do FIRS 4 without breaking FIRS 3, which needs maintenance releases
18:06:26  <andythenorth> planetmaker: can we teach bundles to git?
18:06:56  <nielsm> stations are more interesting than towns, because stations are created and removed all the time!
18:08:52  <Eddi|zuHause> andythenorth: i think you should first create the github repo, and then ask that question again :)
18:09:12  <andythenorth> well then I might end up stuck with a github repo, and no way back to hg
18:09:16  <andythenorth> and no bundles
18: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"
18:10:54  <peter1138> nielsm, as long as add/remove is fast... I guess it's not? :(
18:11:22  <peter1138> Hmm, those pretzel pieces were a bit stale...
18:12:35  <andythenorth> this is heresy, but I prefer redmine's repo view to github's
18:12:49  <andythenorth> github doesn't show many commits per page, and it's really non-compact
18:12:53  <nielsm> peter1138, Insert is log(n)
18:13:13  <nielsm> but can cause the tree to become imbalanced if enough items are inserted in a poorly chosen order
18:14:05  <nielsm> Remove is not implemented yet, but can require rebuilding a partial tree, so worst case is O(n*log(n)^2)
18:15:10  <peter1138> How slow is rebuild?
18:16:34  <peter1138> Oh you just said :p
18:20:02  <nielsm> might be slower actually, since I'm sorting and re-sorting elements a lot
18:20:19  *** Gabda has quit IRC
18:20:27  <_dp_> nielsm, with how rare player actions are you can probably get away even with a full tree rebuild
18:21:58  *** m3henry has joined #openttd
18:22:13  <_dp_> though I'm not sure if there is any benefit for having a tree for stations
18:22:21  *** Wolf01 has joined #openttd
18:22:34  <Wolf01> o/
18:24:07  <m3henry> o/
18:25:41  <peter1138> Right, now to compare Wentbourne side-by-side.
18:25:49  <peter1138> master vs non-rect-catchment
18:26:06  <Wolf01> So, I had my head in astroneer for the entire day today... I'm playing it too much
18:26:22  <Wolf01> I couldn't concentrate at work
18:26:57  <peter1138> Waiting for the average ms to creep up for World ticks.
18:27:14  <peter1138> Slightly issue with the framerate display, it takes ages to get there are very low rates.
18:27:43  <Wolf01> It should be time based, instead of quantity based
18:27:58  <peter1138> Okay.
18:28:03  <peter1138> _dp_, all this worrying...
18:28:20  <peter1138> I'm seeing a 0.1ms performance increase with my patch.
18:28:25  <Wolf01> :o
18:28:37  <peter1138> So non-rect catchments is faster than master.
18:28:53  <peter1138> Wolf01, not a lot, but that's per tick.
18:29:03  <peter1138> Actually it's 0.13ms.
18:29:12  <peter1138> 3.9ms per second.
18:29:19  <_dp_> peter1138, wait, 0.1 from master, not just unsorted_set?
18:29:32  <peter1138> Er, or would be, except I'm nowhere near 33 fps.
18:29:55  <peter1138> _dp_, er...
18:30:02  <peter1138> non-rect 1.76ms
18:30:06  <peter1138> master 1.9ms
18:30:21  <peter1138> Using unordered_set and all my other optimizations.
18:30:34  <Wolf01> So freenode is telling me to upgrade mirc
18:30:42  <_dp_> peter1138, ah, I thought you did bitmaps
18:31:08  <peter1138> No, I looked, but it requires significant processing at the "IsTileInCatchment()" stage.
18:32:37  <_dp_> peter1138, for caches you probably need a test with a lot of town growth as well
18: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.
18:33:12  *** Gja has joined #openttd
18:33:20  <peter1138> And then, in the rare cases I *do* iterator the catchment tiles, I'll need to write an iterator.
18:33:34  <Wolf01> Upgrading mirc...
18:33:39  <Wolf01> BBL
18:33:42  *** Wolf01 has quit IRC
18:33:45  <peter1138> So "just use a bitmap" is kinda... sure, doable but not easy.
18:36:12  <peter1138> For town growth I am actually iterating the map array to find stations, in case any station is a new one.
18:36:23  <_dp_> peter1138, dunno, sounds like just a bit tile coords math to me
18:36:36  <peter1138> _dp_, how so?
18:36:48  <peter1138> coordinate maths against what?
18:36:50  *** Wolf01 has joined #openttd
18:36:59  <Wolf01> Upgraded mirc
18:37:03  <peter1138> Oh you mean the bitmap thing.
18:37:19  <_dp_> peter1138, i mean just a simple conversion from global xy to bitmap xy and back
18:37:40  <peter1138> None of which is necessary with the current unordered_set.
18: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.
18:38:45  <_dp_> peter1138, you mean performance cost or development?
18:38:45  <peter1138> Although that needs to take into account station size, not just its top corner xy.
18:38:53  <peter1138> _dp_, development cost.
18:39:04  <_dp_> peter1138, performance-wise unordered set does heavier math under the hood
18:40:07  <nielsm> funny line, DEBUG(sl, 0, "Unknown savegame type, trying to load it as the buggy format");
18:40:20  <nielsm> "the buggy format" is presumably well known?
18:40:48  <peter1138> I could just use a vector...
18:41:11  <andythenorth> PR count will soon overtake issue count :D
18:41:16  <andythenorth> 78 vs 53
18:42:27  <peter1138> andythenorth, you can fix that.
18:42:38  <peter1138> andythenorth, approve PRs, or create more issues.
18:42:57  <Wolf01> The target is to lower the issues to 0, so PRs can overtake them autimagically
18:43:05  <Wolf01> *automagically
18:43:22  <andythenorth> stalebot
18:43:52  <Wolf01> Or merge all PRs and issues will decuplicate
18:44:37  <_dp_> yeah, stalebot is unrivaled bugfixer :p
18:45:16  *** gelignite has joined #openttd
18:47:40  *** glx has joined #openttd
18:47:40  *** ChanServ sets mode: +v glx
18:50:10  *** andythenorth has quit IRC
18:59:19  *** kiwitree has quit IRC
19:08:41  *** Gabda has joined #openttd
19:09:46  <supermop_work> Eddi|zuHause: of course i remember
19:23:06  *** Smedles has quit IRC
19:26:23  <Wolf01> https://steamcommunity.com/profiles/76561198028113296/screenshot/934964517263047548 Eddi|zuHause I found the wolframite!
19:27:39  *** sim-al2 has joined #openttd
19:29:12  *** Smedles has joined #openttd
19:32:53  *** frosch123 has joined #openttd
19:39:40  *** sim-al2 has quit IRC
19:41:24  *** Supercheese has joined #openttd
19:54:23  *** Supercheese has quit IRC
19:56:11  *** Supercheese has joined #openttd
20:06:26  *** Wormnest has quit IRC
20:09:05  <peter1138> hi
20:11:59  <supermop_work> hi
20:13:06  <peter1138> Mmm, beef fillet steak
20:15:43  <peter1138> Yeah so was there an AI that made subsidies?
20:15:47  <peter1138> Er.. GS
20:15:56  *** andythenorth has joined #openttd
20:16:01  <peter1138> andythenorth would know.
20:16:20  <andythenorth> yo
20:16:25  <andythenorth> I reckon no
20:16:30  <andythenorth> what was the question?
20:16:38  <nielsm> well, there is an api to create subsidies
20:16:38  <nielsm> static bool Create(CargoID cargo_type, SubsidyParticipantType from_type, uint16 from_id, SubsidyParticipantType to_type, uint16 to_id);
20:16:41  <peter1138> Was there a GS that made subsidies :D
20:16:45  <nielsm> in ScriptSubsidy
20:16:53  <glx> maybe some goal scripts
20:17:10  <andythenorth> oof NFI sorry
20:18:42  <andythenorth> one day I make a GS maybe
20:18:44  <andythenorth> although...
20:18:48  <andythenorth> maybe not
20:18:50  <peter1138> Your name is in the credits of one.
20:19:02  <andythenorth> yeah, that wasn't really me, I just playtested
20:19:19  <andythenorth> GS involves way too much handling of state etc for me
20:19:30  <andythenorth> it's a lot of stuff to think about that I am not good at
20:19:51  <andythenorth> all the saveload stuff etc is complex
20:21:23  <peter1138> Ok... UFO landed on my only raod vehicle, while it was stopped int he depot.
20:21:43  <andythenorth> ouch
20:21:50  <andythenorth> NewDisasters
20:22:17  <peter1138> Palette animation on to make fast-forward bareable.
20:22:31  <andythenorth> eh?
20:24:34  <Gabda> I've read back on the IRC messages about my town name refresh PR
20:26:15  <andythenorth> if I move FIRS to github
20:26:17  <andythenorth> and then I die
20:26:34  <andythenorth> ....
20:26:44  <andythenorth> coop is bus-proof
20: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
20:27:06  * andythenorth suspects it's probably fine, except for me, but I'll be dead
20:28:33  <peter1138> Hmm, still no subsidies.
20:28:48  <peter1138> Maybe I've broken it?
20:30:03  <peter1138> No, I've only changed the code that detects if cargo is subsidized, but I'm not seeing any offers.
20:30:57  <peter1138> Oh.
20:31:06  <nielsm> hmm, I wonder if a k-d tree can be used to extract items in order of distance to a point?
20:31:16  <peter1138> Passenger subsidies are disabled if cargodist is enable!
20:31:23  <nielsm> i.e. not just get nearest items, but get X nearest items
20:31:26  <andythenorth> eh wat?
20:31:35  <andythenorth> too much things
20:31:47  <peter1138> Why would that be the case?
20:32:15  <peter1138> OTOH, I should be seeing cargo subsidies too.
20:33:08  <peter1138> Why!
20:33:40  <nielsm> https://github.com/OpenTTD/OpenTTD/blob/349cbee6e90a7a7257a2872755540d5555f6ee90/src/station_cmd.cpp#L3087-L3088
20:33:49  *** synchris has quit IRC
20:33:51  <peter1138>     (svn r25882) -Change [FS#5766]: Don't offer subsidies for auto-distributed cargo.
20:34:30  <andythenorth> oof
20:35:17  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #5766: (Re)consider subsidies should work under cargo-dist https://git.io/fhdmU
20:35:52  <peter1138> Yup, cargo dist off ... get a subsidy.
20: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
20:36:36  <andythenorth> on the other hand cargodist is pretty lame
20:38:45  <peter1138> Ok, subsidy works :D
20:39:19  <glx> it should work with cargodist if source and destination are correct
20:39:28  <peter1138> No, it's specifically disabled.
20:39:38  <glx> I know it is
20:39:44  <peter1138> Oh.
20:40:05  <peter1138> Yeah, you just can't control src & dst very much.
20:40:20  <peter1138> Short of not creating links. Easier for cargo, I guess.
20:40:43  <Gabda> nielsm, I don't think you can
20:41:02  <andythenorth> I don't really get the problem
20:41:17  <andythenorth> if there's a subsidy A->B, build a route A->B
20:41:36  <andythenorth> cdist will then route cargo A->B
20:41:53  <andythenorth> most of the 'problems' of cdist are because it's counter-intuitive
20:42:05  <glx> cdist may also do A->C->D->B
20:42:08  <andythenorth> no
20:42:16  <andythenorth> I said build a route A->B
20:42:22  <andythenorth> two nodes
20:42:33  <andythenorth> :D
20:42:42  <Gabda> <nielsm> (nothing ever queries a tile area for towns, does it?) <- IsCloseToTown does
20:42:52  <andythenorth> cdist works exactly as advertised, and is mostly not broken
20:43:00  <andythenorth> it's just not really useful
20:43:10  <andythenorth> it's a high cost way to avoid automated transfers
20:43:15  <andythenorth> enable / avoid /s
20: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
20:44:27  <nielsm> and that may have decreased since a station was built
20:44:44  <nielsm> (not that it usually will, but it could potentially have)
20:45:26  <m3henry> Man this line is awkward to grok:
20:45:26  <m3henry> this->buf  = *this->blocks.Append() = CallocT<byte>(CHUNK);
20:46:59  <peter1138> :D
20:47:26  <nielsm> cute
20:47:30  <peter1138> It's allocating CHUNK bytes of memory, and storing the pointer to it in this->blocks and this->buf
20:47:35  <m3henry> Yeah
20:47:47  <m3henry> Just readign it as such takes time
20: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
20:49:27  <peter1138> Okay, I just remembered I can't iterate catchment_tiles this way here :-(
20:50:28  *** Gja has quit IRC
20:53:37  <glx> hmm cargo packets have source, and I think there's a way to know if the cargo did a direct travel
20:54:50  <peter1138> Does it need to be direct?
20:57:56  <andythenorth> oof github import of FIRS failed :P
20:58:09  <andythenorth> doesn't say why :P
20:58:39  *** Gabda has quit IRC
21:00:33  <andythenorth> this is why I frigging hate mercurial
21:00:35  <andythenorth> (bin35) firs$ hg up v4-test
21:00:36  <andythenorth> abort: uncommitted changes
21:00:37  <andythenorth> (commit or update --clean to discard changes)
21:00:38  <andythenorth> (bin35) firs$ hg st
21:00:42  <andythenorth> no changes
21:01:01  <andythenorth> it really doesn't understand branches at all
21:04:00  <andythenorth> frosch123: how did you complete the nml -> github clone?
21:06:01  *** Wormnest has joined #openttd
21:06:35  <glx> git init, git add, git commit ?
21:07:21  <peter1138> Quite.
21:07:22  <LordAro> but muh history
21:13:11  <glx> https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git <-- seems easy
21:16:51  <andythenorth> sometimes the github importer works, and sometimes not
21:17:00  <andythenorth> I was able to import nml, frosch wasn't :|
21:17:22  <dwfreed> andythenorth: yeah, mercurial's behavior wrt branches is... weird
21:32:54  *** gelignite has quit IRC
21:44:36  *** snail_UES_ has joined #openttd
21:44:57  <andythenorth> oof GH import failed again
21:45:05  <andythenorth> meh
21:45:36  <peter1138> Did you expect something different?
21:46:25  <andythenorth> I wondered if it was timing out upstream or downstream
21:46:46  <andythenorth> 'try again' is valid in most computing situations :P
21:48:09  <frosch123> andythenorth: i have a local hg-fast-export
21:48:18  <andythenorth> ok
21:48:21  <andythenorth> I'll do the same
21:48:26  <frosch123> shall i clone something
21:48:53  <frosch123> it's already setup, so it's like 5 minutes
21:49:08  <andythenorth> if you don't mind
21:49:11  <andythenorth> I want to try moving FIRS
21:50:04  <Samu> I'm gonna assume my AI is now ready
21:50:17  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdY3
21:52:41  <frosch123> do you have a foobar email or gh account?
21:52:56  *** drac_boy has joined #openttd
21:53:01  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYs
21:53:05  <drac_boy> hi there world ;)
21:53:17  <frosch123> hm, oh, there is no foobar
21:53:22  <frosch123> i thought i read that
21:55:48  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYG
21: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
21: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
21: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
21:57:29  <DorpsGek_II> [OpenTTD/OpenTTD] michicc closed issue #7226: NPF: Ship: Assertion failure when ship encounters shore https://git.io/fh7CV
21:57:46  <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
21:58:44  <peter1138> BitmapTileArea+Iterator...
21:58:54  <peter1138> I'd be surprised if this works.
21:59:38  * peter1138 tests performance.
21:59:49  <peter1138> Hmm, well...
21:59:54  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYC
22:00:08  <Samu> uploaded v8, plz test https://bananas.openttd.org/en/
22:00:14  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYl
22:00:19  <peter1138> _dp_, it works.
22:00:25  <peter1138> _dp_, slightly ... quicker ...
22:00:36  <peter1138> I think. I might be misremembering.
22:00:58  <peter1138> master 1.9ms
22:01:09  <peter1138> std::unordered_set 1.76ms
22:01:16  <peter1138> bitmaptilearea 1.44ms
22:01:44  <Samu> question, which vehicle set do I need to play FIRS?
22:01:58  <Samu> my ships couldn't transport engineering supplies
22:02:43  <peter1138> It's going to annoy m3henry, because it uses SmallVector :/
22:02:53  <frosch123> firs import requires git fsck :p
22:03:01  <andythenorth> ?
22:03:13  <drac_boy> samu basically nearly anything except the vanilla trains
22:03:17  <andythenorth> is the repo inconsistent?
22: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
22:04:32  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYB
22:04:37  <frosch123> there are 4 eints commits with: nulInCommit: NUL byte in the commit object body
22:04:55  <_dp_> peter1138, that's not a bad improvement actually
22:05:18  <Samu> https://github.com/OpenTTD/OpenTTD/pull/7230 wow why was it merged just like that?
22:05:23  <_dp_> peter1138, also you're measuring tick time, it's unclear how much of that is even related to stations
22:05:42  <peter1138> _dp_, when it jumped to 40ms, I knew it was me.
22: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
22:06:13  <_dp_> peter1138, yeah, on increasing side it's more clear)
22:06:15  <Samu> you're blatantly making opf do worse, :p
22: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
22:07:29  <Samu> I need to see what happened to removal of 90 degrees
22:07:35  <Samu> was it really removed or not?
22:07:38  <peter1138> Yes, I'm aware. I'm happy with it reducing. I haven't checked memory usage.
22:08:01  <peter1138> It's less than master, that's pretty important.
22:08:12  <nielsm> ah okay, reproduced the crash now
22:08:42  <nielsm> now, where are dead station signs removed...
22: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)
22: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 :)
22:10:24  <Samu> must investigate
22:10:40  <andythenorth> drac_boy: for ottd?
22:11:02  <drac_boy> yeah
22:11:13  <andythenorth> TE is almost irrelevant in most ottd gameplay situations
22:11:30  <andythenorth> it only makes a difference in very specific situations
22: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
22:12:03  <andythenorth> so geared locomotives are basically just slow, wiht no upside
22:12:09  <andythenorth> with *
22:12:20  <glx> nielsm: somewhere in the gameloop
22: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
22: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
22:14:35  <nielsm> glx found it, station_cmd.cpp StationHandleBigTick
22:14:46  <glx> yes that's it :)
22: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
22:16:55  <glx> and you can probably use its return value in OnTick_Station()
22:19:03  <drac_boy> samu actually I think squid/fish should be capable firs/ecs-ready ships too .. if that ever helps?
22:20:17  <peter1138> _dp_, I'm surprised I managed to get it working. I even inherited from the existing tilearea+iterator.
22:21:17  <Samu> I'm refering about this last merge
22:21:43  <andythenorth> drac_boy: TE is irrelevant unless train speed drops below some level
22:21:49  <andythenorth> I tested it a lot recently https://dev.openttdcoop.org/attachments/download/9254/TE_vs_HP-speed-factor-1b.png
22:22:06  <Samu> it's making opf do even worse than it already is
22:22:07  <andythenorth> HP is significant, TE is not
22:22:20  <drac_boy> andy well I guess I don't know why the first train refused to hit 50kph then :)
22:22:22  <frosch123> well... what does git call the "commit object body"?
22:22:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
22:23:05  <andythenorth> frosch123: I'll google
22:23:15  <frosch123> i only found the git source code
22: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
22:23:45  <Samu> they are stuck
22:23:47  <drac_boy> samu not sure .. you asked which sjips can be used with firs .. I responded to that
22:23:52  <drac_boy> ships*
22:24:02  <andythenorth> frosch123: no answers :( https://stackoverflow.com/questions/42807257/github-wont-accept-this-old-commit-how-do-i-fix-it
22:24:04  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdY7
22:24:06  <Samu> ah, thanks, I'm about something  else now
22:24:15  <drac_boy> np
22:24:23  <Samu> they're stuck in a reverse loop
22:24:51  <andythenorth> oof google gets me one SO result, a spanish mercural RSS feed thing, and a 403
22:24:53  <andythenorth> :(
22:25:32  <andythenorth> drac_boy: sounds like you have one of the cases where TE does apply
22:25:38  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdYF
22:25:39  <andythenorth> not enough HP / ton
22:25:47  <Samu> how do I contest a merge? :o
22:25:55  <andythenorth> contest?
22:26:13  <Samu> j0anjosep merge
22:26:23  <andythenorth> there's no concept of 'contest'
22:26:27  <andythenorth> you can complain on the PR
22:26:33  <andythenorth> and see what response you get
22:26:37  <Samu> https://github.com/OpenTTD/OpenTTD/commit/6ca637b8c149efe2cb8ccffccbfd98530f633d58
22:26:42  <peter1138> Samu, why did you not comment on PR?
22:26:49  <andythenorth> you think it's buggy?
22: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 :)
22:27:07  <peter1138> You should have commented on the PR with your thoughts at the time, not complain later.
22:27:11  <Samu> you were telling me 90 degrees were to be removed for ships
22:27:16  <Samu> then it wasn't
22:27:52  <nielsm> peter1138, I pushed some code that does k-d trees with stations too, now: https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:kdtree
22:28:06  <Samu> now this is merged, I'm testing it right now, and opf ships are locked in a reverse-loop
22:28:14  <peter1138> Samu, no, we were saying it's possible.
22:28:25  <andythenorth> frosch123: don't suppose we can just drop the offending commits?
22:28:30  <peter1138> Samu, this is why you should always comment on the PRs, not just chat in IRC where it is not recorded.
22:28:54  <glx> and you can test the PRs before they are merged too
22:28:58  <drac_boy> hmm just finally looked now .. the irregular airport catchment does seem interesting
22:29:10  <peter1138> Samu, anyway, if you want to "contest" a PR, you know exactly what to do.
22:29:13  <peter1138> Open a new issue!
22:29:18  <Samu> but why would I bother, everytime I talk about opf, you complain about it being obsolete
22:29:22  <frosch123> andythenorth: fixed it :)
22:29:26  <andythenorth> yay
22:29:33  <peter1138> Samu, that doesn't mean we want to break.
22:30:33  * drac_boy wonders what else coals can be used for beside steelmills/powerplants
22:30:59  <andythenorth> https://en.wikipedia.org/wiki/Coal_liquefaction
22:31:03  <andythenorth> also town gas
22:31:07  <andythenorth> lime kilns
22:31:13  <andythenorth> coke ovens
22:31:15  <m3henry> Append is turning out to be the largest commit of this PR
22:32:03  <andythenorth> brick kiln, cement kiln
22:32:14  <andythenorth> domestic fuel
22:32:30  <nielsm> boy scout camps!
22:32:33  <drac_boy> hmm coal bricks .. thats a new one to me .. will have to check ty
22:32:47  <nielsm> not bricks made from coal, bricks fired with coal
22:33:33  <Samu> there is a right way to do 90 degs for opf
22:33:43  <Samu> i had it done, but it was rejected
22:34:06  * andythenorth is confused
22:34:20  <peter1138> _dp_, nice benefit, it's now safe to iterate catchment_tiles as the order is guaranteed.
22:34:35  <andythenorth> why are we implementing 90 degs for opf?
22:34:58  *** snail_UES_ has quit IRC
22:35:01  <nielsm> why was the 90 deg turns setting ever made apply to anything other than trains?
22:35:02  <peter1138> Hmm, so...
22:35:06  <Samu> then j0anjosep comes in, makes 90 degs be checked before the pathfinder, which breaks opf, and it gets accepted :(
22:35:14  <nielsm> it was only supposed to ever be about trains
22:35:28  <Samu> I'm sad
22:35:31  <peter1138> debug visualizations are really useful.
22:35:31  <drac_boy> hm anyway I'll let you talk about stations and pathfinders .. going off for a while here
22:35:31  <frosch123> why? ships turned just as sharp
22:35:36  *** drac_boy has left #openttd
22: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
22:35:55  <peter1138> Made it much easier to verify that station catchment works.
22:36:30  <frosch123> though now they turn in place? i read something like that
22:36:40  <peter1138> Yeah that's a thing.
22:36:51  <Samu> gonna create an issue
22:36:57  <peter1138> Samu, finally.
22:37:39  <glx> next time you could try the PR before it's merged ;)
22:37:51  <frosch123> andythenorth: my upload is too small, push will take 30 minutes or so :p
22: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
22:38:28  <glx> especially when you know what could fail
22:38:29  <peter1138> Prozone 13 catchment areas, oh boy.
22:38:51  <LordAro> oh, you're definitely going to break all ottdc games :p
22:39:18  <andythenorth> frosch123: is the process repeatable? o_O
22:39:24  <nielsm> peter1138, prozone 13 is the one with synchronised oil trains?
22:39:27  <frosch123> yes
22:39:37  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdOC
22:39:48  <frosch123> i repeated it 5 times with various author mappings
22:39:55  <andythenorth> I should set up to do it locally then, I have 6 or so repos to convert :)
22:40:01  <andythenorth> maybe not right now though :)
22:40:29  <frosch123> hmm, do you mean "repeatable" or "incrementable"?
22:40:49  <andythenorth> I mean can I follow instructions and get it done?
22:40:58  <andythenorth> unless you or someone else would do it for me :P
22:40:59  <frosch123> i always convert the whole repo, no idea whether it can also do incremental updates
22:41:20  <frosch123> andythenorth: up to know i used the package from debian stable
22:41:39  <frosch123> but now i patched the script to filter out NUL in commit messages
22:41:39  <peter1138> Ah, Resize doesn't clear :-)
22:41:50  <frosch123> which eints apparently produces sometimes/somewhen
22:42:06  <glx> I think the instructions in https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git should work too
22:42:25  <glx> as it seems frosch123 is using the indicated tool
22:42:54  <frosch123> yes, hg-fast-export
22: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
22:44:18  <andythenorth> can we wrap a shell script around it? :P
22:44:33  <andythenorth> might be a lot to move in future
22:44:44  <glx> author thing is somehow manual
22:44:57  <frosch123> i could probably run it on devzone
22:45:00  <frosch123> better bandwidth :p
22:45:16  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick opened issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOR
22:45:59  <peter1138> Samu, add a reference to the offending commit/PR as well.
22:46:48  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOz
22:47:49  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOg
22:49:08  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOw
22:50:47  <Eddi|zuHause> why is the tractor called a rough terrain vehicle, when it gets stuck on every tiny bump?
22:51:51  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOK
22:52:13  <andythenorth> frosch123: devzone sounds like a nice idea :)
22:52:15  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
22:52:17  * andythenorth must to bed 
22:54:13  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdOi
22:55:34  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOX
22:56:06  <peter1138> andythenorth, not again.
22:56:26  <peter1138> Broken savegame - Invalid chunk size
22:57:04  <peter1138> I should add a button to allow broken savegames to be deleted easily :p
22:57:07  <peter1138> I have so many.
22:57:13  <DorpsGek_II> [OpenTTD/OpenTTD] glx22 commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOM
23:00:58  *** m3henry has quit IRC
23:03:14  <peter1138> Right, I suppose it makes sense to start squashing it down.
23:06:07  <peter1138> ModifyStationRatingAround is an interesting one.
23:06:23  <peter1138> It doesn't take the size of the station into account, only its top corner (st->xy)
23:07:43  <peter1138> Perhaps I should use StationList for the nearby stations list.
23:07:53  *** Wolf01 has quit IRC
23:08:00  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOx
23:08:46  <peter1138> I'll try it.
23:10:27  <Samu> I like the big penalty for 90 degree turns
23:10:40  <Samu> but unsure about total removal of it for ships
23:10:46  <peter1138> I removed that. I need to open it as a new PR.
23:13:00  <nielsm> this tree-juggling is rather difficult... :s
23:13:38  *** andythenorth has left #openttd
23:15:31  <nielsm> I broke something... https://0x0.st/ziBS.png
23:15:42  <nielsm> none of those were built holding ctrl or doing classic station walking
23:15:47  <peter1138> :)
23:15:53  <nielsm> they just connected spontaneously :(
23:16:10  <peter1138> Hmm, problem with using smallvector is its not ordered, except how I order them. Hmm.
23:16:39  <peter1138> And there's an Erase method but it's not simple.
23:17:23  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro opened pull request #7245: Remove: OPF https://git.io/fhd3e
23:17:43  <LordAro> the complaints were boring me
23:17:54  <peter1138> !
23:18:01  <peter1138> I already had a patch for that ;(
23:19:40  <LordAro> i'm not sure if it requires any savegame conversion
23:20:05  <nielsm> it probably would
23:20:16  <nielsm> games with the old setting need to convert to one of the other PFs
23:20:28  <LordAro> mm
23:20:30  <nielsm> or they'll trigger NOT_REACHED paths
23:20:47  <nielsm> reach the unreachable
23:21:23  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep opened pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3v
23:24:22  <glx> hmm afterload change should take care of it
23:24:34  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7245: Remove: OPF https://git.io/fhd3J
23:25:08  <frosch123> well, i guess andy does not read logs :p
23:25:23  <frosch123> but i cannot transfer the repo since andy already has one named "firs"
23:26:03  <glx> ah no it may need another conversion step
23:26:08  <LordAro> "Broken savegame - Invalid chunk size" hmm.
23:26:12  <LordAro> i should think so
23:26:40  <LordAro> changing the constants to 0,1 instead of 1,2 will definitely require extra work
23:26:55  <glx> you removed settings too, so savegame conversion required
23:28:43  <peter1138> Those removed settings need to be replaced with SDT_NULL
23:29:02  <LordAro> right, was just going to ask how settings actually get removed
23:29:25  <glx> add "to" and don't remove it in ini I think
23:29:30  <peter1138> https://github.com/OpenTTD/OpenTTD/compare/master...PeterN:remove-opf
23:29:33  <peter1138> ^ what I did.
23:29:55  <peter1138> I think it worked, I can't remember :P
23:30:26  <glx> yes that works too
23:30:28  <peter1138> Ah, no, unfinished, I didn't get around to actually bumping the version.
23:32:47  <peter1138> Hmm, SmallVector has a STL-style iterator, using Begin() and End()
23:32:52  <peter1138> TileArea has something... other.
23:33:47  <LordAro> why isn't SL_MAX_VERSION defined as 0xffff or similar?
23:33:55  <LordAro> didn't it used to be?
23:34:07  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3C
23:34:16  <glx> max is always the next version
23:34:28  <LordAro> i must be misremembering
23:34:33  <peter1138> It probably was, but it doesn't make much difference.
23:34:59  *** frosch123 has quit IRC
23:35:09  <peter1138> It's always one above the current version, so no harm done.
23:35:28  <glx> I think it used to be a big number, but it's not really important as long it's in the "future"
23:35:38  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep updated pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3v
23:35:47  <peter1138> Hmm, SmallVector needs an EraseItemIfItExists function :/
23:35:55  <peter1138> Oh, I can just add it.
23:36:04  <glx> and indeed your removal is incomplete peter1138 :)
23:36:11  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3l
23:36:48  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep commented on pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd38
23:37:42  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep updated pull request #7246: Fix #7224 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3v
23:38:24  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro updated pull request #7245: Remove: OPF https://git.io/fhd3e
23:38:56  <LordAro> peter1138: thoughts on altering the setting values?
23:39:01  <peter1138> Why?
23:39:02  *** Thedarkb1-T60 has joined #openttd
23:39:10  <LordAro> it would be neater, but probably quite a lot of effort to just do i--;
23:39:15  <peter1138> Quite.
23:39:45  <LordAro> oh, the comment's disappeared anyway
23:39:50  <LordAro> ¯\_(ツ)_/¯
23:41:23  <glx> I think loading check will magically convert 0 to 1
23:41:49  <peter1138> That or reset it to the default (so 2) ?
23:42:39  <michi_cc> So how can merge https://github.com/OpenTTD/OpenTTD-git-hooks/pull/9, that Fix, Fix just looks ugly.
23:43:02  <peter1138> ?
23:43:34  <peter1138> Oh.. who can merge :)
23:44:09  <LordAro> michi_cc: though, GH doesn't recognise Fix #foo, #bar
23:45:01  <LordAro> and i forget, should i be removing strings from other languages? or do i let eints do that? or do it in a separate commit?
23:45:14  <michi_cc> For closing or for linking? Mostly it would be Fix #issue, #bad_PR I guess.
23:45:19  *** Thedarkb-T60 has quit IRC
23:45:53  <LordAro> for my specific purpose, i don't see my issue as directly fixing either issue or PR
23:46:06  <LordAro> so i just added a Close in the PR description, which won't go into the commit message
23:46:23  <LordAro> i suspect you're not talking about #7245 though
23:47:41  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7246: Fix #7244 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3V
23:48:15  <glx> checked, it will use min value
23:49:28  <glx> string removal can go in a second commit
23:50:45  <LordAro> glx: min value will be NPF though, not the default - is that desirable?
23:51:40  <peter1138> Hmm, maybe I should change StationList to be a list of StationIDs.
23:51:41  <glx> it was using OPF, so NPF is not a bad fallback
23:51:51  <LordAro> true
23:51:57  <peter1138> Then I can sort by number to ensure synchronized order.
23:52:09  <peter1138> That's not doable with Station *.
23:53:45  <DorpsGek_II> [OpenTTD/OpenTTD] J0anJosep updated pull request #7246: Fix #7244 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3v
23:54:18  <glx> frosch123 has write access for git-hooks, but as an admin I can do it too
23:56:30  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro updated pull request #7245: Remove: OPF https://git.io/fhd3e
23:58:13  *** HerzogDeXtEr has quit IRC
23:58:51  <glx> but I won't, I requested a change

Powered by YARRSTE version: svn-trunk