Back to Home / #openttd / 2019 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2019-02-18

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