Log for #openttd on 19th February 2019:
Times are UTC Toggle Colours
00:02:21  *** tokai|noir has joined #openttd
00:02:21  *** ChanServ sets mode: +v tokai|noir
00:05:56  <DorpsGek_II> [OpenTTD/OpenTTD] michicc approved pull request #7246: Fix #7244 #7226: OPF doesn't take 90 deg turns into account.
00:06:14  <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7246: Fix #7244 #7226: OPF doesn't take 90 deg turns into account.
00:06:21  <DorpsGek_II> [OpenTTD/OpenTTD] michicc closed issue #7244: OPF ships locked in a reverse-loop
00:09:24  *** tokai has quit IRC
00:11:10  *** snail_UES_ has joined #openttd
00:15:03  <DorpsGek_II> [OpenTTD/OpenTTD] LordAro updated pull request #7245: Remove: OPF
00:28:15  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened issue #7247: With lots of vehicles, PerformanceAccumulator large performance impact itself
00:28:24  <nielsm> I have now pushed some code written and attempted debugged while way too tired
00:29:04  <nielsm> probability of bugs: high
00:29:23  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
00:29:54  <peter1138> ^ just putting that out there cos I forget.
00:30:25  <Eddi|zuHause> it's crazy how disoriented you are after 3 steps in a cave...
00:30:33  <Eddi|zuHause> not even beacons help
00:30:49  <glx> you don't have torchs ?
00:30:58  <glx> that was nice in minecraft
00:31:42  <Eddi|zuHause> you have beacons that are long-range, and tethers that might help you short-range
00:32:05  <Eddi|zuHause> but i'm in a tractor and thus disconnected from the tether network
00:33:16  <nielsm> peter1138 yeah, I'm not sure what to do about that other than separate vehicle types into each their own array
00:33:26  <nielsm> so they can be timed as one unit
00:33:38  <peter1138> Good luck with that :/
00:34:04  <peter1138> FOR_ALL_VEHICLES_OF_TYPE
00:34:07  <peter1138> Maybe...
00:41:18  <peter1138> ttps://
00:41:22  <peter1138> So... how is performance?
00:42:03  <glx> oh indeed performance is done for each vehicle of a train
00:42:04  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
00:42:36  <nielsm> peter1138, haven't measured that at all yet
00:43:01  <peter1138> Ok.
00:44:48  *** Flygon has joined #openttd
00:46:29  <nielsm> first priority is to have the algorithms be bug free :)
00:46:55  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
00:46:59  <peter1138> Nah, ship it!
00:48:09  <peter1138> Oh, FOR_ALL_VEHICLES_OF_TYPE() even exists, hah
00:48:45  <glx> yes and FOR_ALL_AIRCRAFT too
00:49:00  <nielsm> also it feels good to see my performance measurements get used and prompt optimization :3
00:49:27  <nielsm> (which was in fact part of the reason I wanted to do it)
00:50:22  *** Supercheese has quit IRC
00:53:55  <peter1138> Hmm, oh
00:56:46  <glx> it doesn't seem too hard to group by vehicle types in CallVehicleTicks()
00:58:51  <peter1138> Yeah, I've done it one way.
00:59:04  <peter1138> 12fps...
00:59:08  <peter1138> train ticks 24ms
00:59:14  <peter1138> roadvehicles ticks 50ms
00:59:19  <peter1138> So ...
00:59:39  <peter1138> Oh, I need to call the ticks of the non-vehicle vehicles.
00:59:45  <glx> the FOR_ALL_VEHICLES loop can be a FOR_ALL_VEHICLES_OF_TYPE enclosed in a for VEH_BEGIN to VEH_COMPANY_END
01:00:35  <nielsm> *yawn* gn
01:00:39  <peter1138> EffectVehicle & DisasterVehicle
01:00:40  <peter1138> nn
01:00:49  <peter1138> I think that's the only other two.
01:00:51  <glx> then a FOR_ALL_VEHICLES_OF_TYPE enclosed in a for VEH_COMPANY_END to VEH_END to do v->Tick for others
01:01:40  <peter1138> It's a macro, so you can't use a variable.
01:01:43  <peter1138> I'm doing it with templates.
01:03:52  <glx> ha yes it neads real type
01:04:01  <peter1138> I'm on it ;)
01:04:35  <glx> but techically we will end up doing 6 FOR_ALL_VEHICLES loop
01:04:45  <glx> with some filtering
01:05:05  <peter1138> Yes.
01:05:09  <peter1138> Normally you'd say that'd be worse.
01:05:27  <peter1138> But in this case it's far outweighed by the PerformanceAccumulator.
01:05:37  <glx> skipping elements in the loop should not cost too much yes
01:06:24  <peter1138> Separate arrays could be faster BUT you'd need to maintain them :/
01:08:39  *** nielsm has quit IRC
01:10:30  <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.
01:10:53  <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.
01:11:32  <peter1138> Hmm
01:11:34  <peter1138> Not riht.
01:11:53  <peter1138> Oh, I saw on master :-)
01:12:09  <peter1138> Cos I accidentally commited there, so made a branch, then reset master. Yeah, git pro!
01:12:44  <glx> hehe
01:13:10  <glx> usually I start coding on master, create the branch, then commit
01:13:30  <glx> but it's easy to forget a step
01:13:40  <peter1138> Simulation rate: 9,999.99 fps
01:13:45  <Eddi|zuHause> i usually create a branch, and forget to actually switch to the branch
01:13:47  <peter1138> Yeah, I don't think that's a problem.
01:13:56  <peter1138> Hmm
01:14:04  <peter1138> I always do it with git checkout -b
01:14:06  <peter1138> So it puts you in it.
01:14:41  <Eddi|zuHause> git is completely weird
01:16:15  <peter1138> Makes a performance benefit on the ProZone 13 save.
01:16:41  <peter1138> master average 25.25 ms
01:16:50  <peter1138> vehicle-tick-split average 15.75 ms
01:16:52  <peter1138> That's pretty major.
01:20:26  <peter1138>
01:20:46  <peter1138> glx, so I did that as a quick joke-test...
01:20:55  <peter1138> But that benefit is so good it might be worth it...
01:22:27  <peter1138> 6 days faster, heh
01:23:23  *** sim-al2 has joined #openttd
01:24:43  <glx> yeah performance counter should have a minimal impact on the performances
01:25:26  <peter1138>
01:25:30  <peter1138> ^ wentbourne
01:25:46  <peter1138> ok, 10.9 fps there, not 12.
01:26:07  <peter1138> Ah, need to wait a bit for the avg to settle.
01:26:50  <peter1138> 3 ms overhead for RVs
01:27:06  <peter1138> Hmm, not valid yet.
01:27:47  <peter1138>
01:27:50  <peter1138> better values.
01:28:07  <peter1138> Not much overhead for RVs, but loads of trains.
01:28:13  <peter1138> 28ms
01:28:27  <peter1138> And then another 15ms overhead for the counter itself.
01:28:38  <peter1138> Or I missed a vehicle type :)
01:29:14  <glx> the gameloop time reduction is still impressive
01:30:47  <Eddi|zuHause> effect vehicles?
01:31:28  <glx> they are not counted
01:32:16  <peter1138> 6.46 ms -> 2.86 ms on another large but not massive save.
01:32:45  <glx> how many RVs compared to trains in wentbourne ?
01:32:50  <peter1138> FFWD speed 4.3x -> 9.4x
01:33:10  <peter1138> 5,499 RVs
01:33:23  <peter1138> 4,833 Trains (but they're all very long)
01:33:33  <peter1138> 2,818 Ships
01:33:53  <peter1138> I guess YAPF is quite good since the path caching.
01:34:07  <glx> it's weird RV takes more time than trains
01:34:30  <peter1138> Yes, they're all single vehicles.
01:34:54  <peter1138> The trains are about 7 tiles long
01:35:10  <glx> because each train means a 7 tick calls
01:35:11  <peter1138> Some are double that.
01:35:17  <peter1138> 14.
01:35:25  <glx> right
01:35:46  <peter1138> Yeah, over 70,000 vehicles.
01:36:04  <peter1138> But on the other hand, the tick does nothing for the wagons.
01:36:31  <peter1138> Still, I'd expect trains to be worse due to having to handle those.
01:37:07  <peter1138> Maybe ... profiler? :D
01:38:28  <glx> and TrainLocoHandler() is called twice
01:38:31  <peter1138> Azure doesn't want to build non-rect-catchmente :/
01:38:35  <peter1138> Yea
01:39:02  <peter1138> I wondered if you could call it once, and then run the game at a higher rate ;)
01:39:29  <Eddi|zuHause> iirc the calling multiple times was a max speed issue
01:39:49  <Eddi|zuHause> or, workaround
01:44:14  *** sim-al2 has quit IRC
01:45:48  <peter1138> Oh dear, my catchment patch went from +72-51 to +538-109 :(
01:46:19  <glx> maybe caused by pathfinding
01:46:38  <peter1138> I mean line count in the patch.
01:46:44  <glx> I think trains make less pathfinding calls
01:46:49  <peter1138> Oh right.
01:47:08  <peter1138> Yes, less junctions, and reservations.
01:47:17  <peter1138> Hmm, path_cache for RVs? :p
01:47:28  <peter1138> That only worked for ships because they don't collide.
01:47:47  <peter1138> Although it could work for RVs.
01:47:58  <peter1138> Just accept traffic jams occasionally.
01:48:04  <peter1138> Realism(tm)
01:48:05  <glx> RVs take care of not hitting the vehicle in front of them
01:48:53  <glx> jams won't be worse I think
01:49:53  <glx> (I don't know if we use a penalty for occupied road tile)
01:51:30  <peter1138> Oh my lord.
01:51:38  <peter1138> RoadVehicleStates is bitstuffed...
01:51:43  <peter1138> In this day & age :(
01:56:00  *** sim-al2 has joined #openttd
01:57:11  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on pull request #7245: Remove: OPF
02:07:07  <peter1138> glx, yup./
02:07:10  <peter1138> 25ms for RVs now.
02:07:55  <peter1138> Although, they can't find paths :p
02:08:17  <glx> ah you commented the pathfinding call
02:08:33  <peter1138> Effectively.
02:08:39  <peter1138> No, I actually implemented the path cache.
02:08:52  <peter1138> Hmm, maybeit's just the save, it works in my small game.
02:10:36  <peter1138> Yeah, they're pathfinder, just I'm doing it wrong :/
02:15:24  <peter1138> Hmm, it's turning a tile too early.
02:16:49  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
02:17:33  <peter1138> Oh, I see.
02:17:43  *** supermop_Home_ has joined #openttd
02:23:07  *** Progman has quit IRC
02:28:10  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
02:47:48  <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.
02:48:25  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
02:55:09  <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.
02:59:31  *** Gustavo6046 has quit IRC
03:06:16  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
03:12:04  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
03:12:12  *** Gustavo6046 has joined #openttd
03:23:11  <DorpsGek_II> [OpenTTD/OpenTTD] JGRennison commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
03:25:06  *** D-HUND has joined #openttd
03:28:29  *** debdog has quit IRC
03:32:15  *** sim-al2 has quit IRC
03:36:55  *** Thedarkb-X40 has joined #openttd
03:41:37  *** Samu has quit IRC
03:48:14  *** glx has quit IRC
04:23:07  *** Wormnest has quit IRC
04:57:30  *** supermop_Home_ has quit IRC
05:09:09  *** Pikka has joined #openttd
05:46:59  *** seatsea has quit IRC
06:03:43  *** snail_UES_ has quit IRC
06:53:32  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #7249: The currently selected base graphics set is missing 4 sprites. This is despite having the latest OpenGFX 0.5.2.
06:53:33  <DorpsGek_II> [OpenTTD/OpenTTD] James103 closed issue #7249: The currently selected base graphics set is missing 4 sprites. This is despite having the latest OpenGFX 0.5.2.
07:43:13  <LordAro> presumably will want a release of ogfx before 1.9.0
07:56:43  <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.
08:03:51  <peter1138> Just needs a colour icon on the OpenGFX version of the group icons ;D
08:20:48  *** nielsm has joined #openttd
08:24:39  *** Gabda has joined #openttd
08:29:20  <nielsm> morning
08:35:49  <Gabda> morning
08:37:54  *** WWacko1976-work has joined #openttd
08:45:42  <Gabda> nielsm: did you read my message yesterday about the IsCloseToTown function?
08:47:26  <nielsm> yes
08:51:53  <nielsm> not like it's actually use anywhere important :)
08:52:55  <Gabda> only on town placing
08:53:27  <Gabda> did you look for a function like this, or I misunderstood your queston?
08:53:46  <nielsm> it is functions like that yes
08:55:14  <Gabda> this kd tree will be really good :)
08:58:24  <nielsm> I think viewport signs (town names, station names, player signs) wouldn't also be a good candidate
08:58:46  <nielsm> those aren't map coordinates but view coordinate, that should work just as well
08:59:31  <Gabda> so they would be a good candidates or wouldn't?
08:59:48  <Gabda> -a
09:01:50  <nielsm> they could make the UI more responsive on large games, perhaps :)
09:04:53  <nielsm> for stations, it looks like the more common case is actually to find all stations belonging to a specific town, rather than near something or within a tile area
09:08:08  <peter1138> nielsm, every single bit of cargo produced scans the map looking for nearby stations, so that isn't right.
09:08:35  <peter1138> nielsm, however! That isn't the case with the non-rect PR, so don't spend time on that :)
09:09:09  <nielsm> yeah I looked a bit at it and saw it would be troublesome to attempt improving with just a kdtree
09:09:30  <nielsm> because of station spread settings that can change over time
09:10:06  <nielsm> right now looking at UpdateTownRating, and I can't seem to find anywhere storing the town zone radii non-squared
09:12:02  <Eddi|zuHause> why do you need the nonsquared radius?
09:12:24  <nielsm> I want the rectangle encosing the circle
09:12:45  <Eddi|zuHause> is that ever used anywhere else in the game?
09:12:51  <nielsm> to look just stations inside that rect as candidates for the circular test
09:12:56  <nielsm> I think not...
09:16:04  <Eddi|zuHause> anyway, the town pool not a good enough storage?
09:17:10  <nielsm> I'm experimenting with using a spatial tree to look up towns and stations near a tile/tile area
09:17:22  <nielsm> possibly improving performance
09:17:49  <Gabda> is there a maximum possible with for town/station names, and sign texts?
09:18:11  <_dp_> nielsm, have you actually profiled the game to find slow places or are you just picking up random ones?
09:18:11  <Gabda> if we don't cosider zoom, font and font size
09:18:31  <nielsm> _dp_ I'm just doing everything! :)
09:18:54  <nielsm> literally searching for FOR_ALL_STATIONS and FOR_ALL_TOWNS and seeing if they are a spatial lookup
09:19:15  *** Westie has quit IRC
09:19:28  *** kiwitree has joined #openttd
09:19:35  <Eddi|zuHause> Gabda: there used to be a limit in pixels that governed how many characters you can input, but that probably got changed when we introduced different fonts
09:19:39  <_dp_> k-d tree is good but aimlessly putting it everywhere can easily make things slower
09:20:24  <_dp_> nielsm, yeah, FOR_ALL_ loops are good candidates for replacement
09:20:50  <_dp_> but things like tile scan probably aren't
09:21:11  <_dp_> at least I'd try to optimize tile scan first if it seems slow
09:21:54  <_dp_> btw, it would be nice to have some collection of savegames and a way to automatically benchmark a change on all of them
09:21:55  <Eddi|zuHause> nielsm: i think for this you should use a more crude upper bound than "current radius non-squared" of each town.
09:21:56  <Gabda> by tile scan you mean tiles in a rectangle, or just a set if tiles?
09:22:31  <Gabda> *of
09:22:53  <_dp_> Gabda, yeah, in rectangle, don't think random scan is used anywhere in the game
09:23:02  <nielsm> okay, looks like squared_town_zone_radius is not calculated as a number squared, but directly...
09:23:13  <nielsm> so I'd actually have to take the root of that
09:23:15  <nielsm> ugh
09:23:37  <Eddi|zuHause> we have the "-v null:ticks=1000" thing, can that output the times at the end?
09:24:32  <Eddi|zuHause> nielsm: integer root doesn't sound like a trivial thing
09:24:36  *** Westie has joined #openttd
09:24:40  <nielsm> yeah this sucks :(
09:25:48  <nielsm> let's go with a worse estimate and just take the squared radius divided by 2
09:26:13  <_dp_> nielsm, does your k-d tree use manhattan? you'll need more than just root then as it's longer on diagonals
09:26:17  <nielsm> it should still be fewer towns visited
09:26:42  <nielsm> it uses manhattan, and I'm using it to search orthogonal tile areas
09:27:32  <nielsm>
09:27:41  <_dp_> aren't there a function for integer root already
09:28:32  <_dp_> btw, it seems you need sqrt(2r) for manhattan radius if I did the math right
09:28:33  <Eddi|zuHause>
09:28:45  <Eddi|zuHause> but we might need one that rounds up
09:29:26  <_dp_> Eddi|zuHause, IntSqrt() + 1 ;)
09:29:55  <Eddi|zuHause> _dp_: not quite the same :p
09:30:25  <_dp_> Eddi|zuHause, good enough :p
09:30:56  <Eddi|zuHause> nielsm: you could make a lookup table for the first 20 or so values
09:32:51  <_dp_> Eddi|zuHause, just storing an already squared value in town would probably be faster
09:33:40  <Eddi|zuHause> _dp_: what? the problem posed was that we currently only have the squared values available.
09:34:53  <_dp_> Eddi|zuHause, oh, I meant already square-rooted
09:35:36  <_dp_> Eddi|zuHause, or mb I should call them  non-squared but they are calculated directly as squared so...
09:36:05  <nielsm> pushed some more code to the above branch, of course untested (it compiles!)
09:53:06  <Eddi|zuHause> turns out we really already have IntSqrt(uint) in math_func.cpp
09:58:23  <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.
09:59:02  <peter1138> Wrong issue :p
09:59:51  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
10:00:52  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7245: Remove: OPF
10:03:11  <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
10:07:21  *** WWacko1976-work has quit IRC
10:08:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself
10:21:10  <DorpsGek_II> [OpenTTD/OpenTTD] Moth-Tolias commented on pull request #7204: Feature: Game setting to define how industries with neutral stations accept and supply cargo from/to surrounding stations.
10:24:24  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7204: Feature: Game setting to define how industries with neutral stations accept and supply cargo from/to surrounding stations.
10:26:09  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7234: Feature: Game setting to define how industries with neutral stations accept and supply cargo from/to surrounding stations.
10:31:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
10:32:06  *** andythenorth has joined #openttd
10:32:42  <peter1138> andythenorth is here.
10:33:40  <andythenorth> yo
10:33:56  <nielsm> this is troublesome, when I ffwd ottd I get electrical noise in my speakers
10:34:28  <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on pull request #7235: Change: Non-rectangular sparse station catchment area
10:36:56  <andythenorth> remove original land generator next? o_O
10:37:33  <Eddi|zuHause> andythenorth: only if you also rewrite TGP
10:37:46  <andythenorth> river-native TGP
10:37:54  <nielsm> release post title, "OpenTTD 1.9.0: The Revolution"
10:37:56  <andythenorth> we let the water carve the landscape
10:38:08  <Eddi|zuHause> nielsm: NoOpenTTD?
10:38:08  <andythenorth> so do rivers shape the land, or does the land shape where rivers go? o_O
10:38:16  <andythenorth> NotOpenTTD
10:38:23  <nielsm> OpenNoTTD
10:38:36  <Eddi|zuHause> NotOpenNoTTD
10:41:58  <andythenorth> hmm
10:45:21  <DorpsGek_II> [OpenTTD/website] Eddi-z updated pull request #58: Monthly Dev Post of March 2019
10:51:20  *** Thedarkb1-T60 has quit IRC
10:51:23  <Eddi|zuHause> andythenorth: the problem is, both, and you need to simulate a few million years of plate tectonics in a few seconds :)
10:52:17  <andythenorth> if only the map had a variety distribution :P
10:54:55  <nielsm> should really fix GetClosestDeletedStation again
10:56:15  * andythenorth still wondering whether to split Pig Iron or not :P
10:56:40  <andythenorth>
10:56:47  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
10:57:17  <andythenorth> the Foundry casts engine blocks etc, which uses cast iron (grey iron) rather than pig iron
10:57:37  <andythenorth> and in all my test games I never ship pig iron to the foundry, it all goes into steel chain
10:58:05  <andythenorth> now that the 2-cargo-out restriction is removed, this can be adjusted :P
10:58:58  <andythenorth> eh there's no cargo flag for 'this cargo is molten'
11:01:00  <andythenorth> oof
11:01:09  <andythenorth> renaming cargos upsets people in forums though :(
11:01:10  <_dp_> inserting few values into a sorted list is better done with just insertion as in insertion sort
11:01:33  <_dp_> I think some sort implementations even use insertion sort for a small arrays
11:02:08  <andythenorth> and I used IRON cargo label for Pig Iron :(
11:02:37  * andythenorth wonders if a complete spec would help for FIRS
11:02:46  <andythenorth> *all* of everything worked out in advance
11:02:51  <_dp_> I mean binsearch + memmove type insertion btw
11:02:57  <andythenorth> including all planned and future  changes in OpenTTD
11:03:04  <andythenorth> with scheduled release dates
11:04:49  <nielsm>   what did I do??
11:05:06  <nielsm> (spoiler: nothing strange, the real station sign is hidden behind the gray one)
11:07:31  <peter1138> _dp_, yes, I was considering adding that instead.
11:07:50  <peter1138> We already do MemMove when removing items, should be too much bother to do the same when adding.
11:09:52  <_dp_> peter1138, though keep in mind you need bacwards memmove for insertion
11:12:01  <andythenorth> it's nice that we have a FROG cargo now :)
11:12:04  <andythenorth>
11:12:38  <nielsm> conceptual at least?
11:14:47  <nielsm> everyone likes making jokes with cargo labels :P
11:15:06  <nielsm> BOOM, CHSE, JAVA
11:19:03  <andythenorth> T800 is Terminator
11:19:27  <andythenorth> and we have Kill Bill cargo also
11:19:28  <andythenorth> KBLL
11:20:49  <nielsm> I wonder if I should just make a PR of my kdtree now?
11:20:55  <nielsm> it seems to work :P
11:21:11  *** Samu has joined #openttd
11:21:39  <nielsm> should make a release build and one of the master I based it on, and compare perf
11:22:42  * andythenorth should figure out what's left to do on 16-cargo industry nml :P
11:22:49  <andythenorth> and then get a clean merge into nml master
11:23:08  <andythenorth> :)
11:24:22  <nielsm> my own indcargonum branch of it on github is good enough to work on that winter wonderland project I've put on hold for now
11:24:49  <nielsm> at least it seems to produce functioning GRF for the new callbacks
11:24:54  <nielsm> and new props
11:25:34  <andythenorth> I suspect the main issue is just having clean commits
11:25:39  <andythenorth> and updating the docs :P
11:25:55  <peter1138> Didn't we do the clean commits? Or was it just a rebase?
11:26:00  <andythenorth> you rebased
11:26:04  <andythenorth> and cleaned a few
11:26:06  <peter1138> Ah, okay.
11:26:14  <peter1138> Yes, you had a merge IIRC.
11:26:15  <andythenorth> what makes logical atomic commits, dunno
11:26:29  <peter1138> Yeah, about that.
11:26:31  <andythenorth> I'd like to be sure it's actually working before worrying about the history :D
11:26:45  <peter1138> My non-rect-catchment branch is starting to suffer there.
11:26:54  <peter1138> As I changed implementation details mid way.
11:26:58  <andythenorth> things that touch everything are hard to make atomic
11:27:23  <peter1138> I'm wondering if my BitmapTileArea could be useful elsewhere.
11:27:35  <andythenorth> this is why we need long-run branches sometimes :P
11:27:38  <andythenorth> maybe with the builds
11:27:56  <andythenorth> then things can brew for a bit
11:28:01  <peter1138> Peter1138sPatchPack?
11:28:18  <peter1138> With variants, multi-stop docks and unicorns.
11:28:20  <andythenorth> you need a recursive bacronym
11:28:25  <andythenorth> but yeah
11:28:38  <andythenorth> I have been playing NRT + a few other things
11:28:44  <andythenorth> but I'm not shipping a PP :P
11:28:59  <andythenorth> hmm, time to go
11:28:59  <peter1138> Other than the conceptual issue of splitting road and tram types, it seems to work okay.
11:29:05  <andythenorth> seems to work fine
11:29:08  <andythenorth> BBL
11:29:10  *** andythenorth has quit IRC
11:29:18  <peter1138> But solving that is a rewrite, and means dumping all the existing NewGRFs, so not going to happen.
11:29:21  <peter1138> Bye.
11:30:48  <nielsm>
11:30:52  <crem2> Rewrite is usually the most fun.
11:31:13  <nielsm> barely any difference :)
11:31:25  <Eddi|zuHause> jpg?
11:31:32  <crem2> Why is it two pictures side by side? Is it a version for 3D glasses?
11:31:54  <Eddi|zuHause> crem2: "we put 12 errors in this picture, can you spot them?"
11:32:10  <nielsm> crem2: notice the title bar at the top
11:32:17  <nielsm> it's two different branches
11:32:25  <nielsm> left is master, right is my experimental kdtree branch
11:32:34  <nielsm> which might or might not improve performance
11:33:19  <nielsm> Eddi|zuHause: jpg because that's what sharex decided on, can't bother to tune it :P
11:35:13  <nielsm>  <- the spike is smaller in kdtree!
11:35:49  *** Thedarkb-X40 has quit IRC
11:36:25  <nielsm> I should let it run for a while to look for desyncs
11:39:17  *** Samu has quit IRC
11:42:43  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh opened pull request #7250: K-d tree data structure for spatial lookups
11:44:04  <nielsm> hm the kdtree branch seems to be falling behind... it might just be a bit slower overall :(
11:45:48  <_dp_> nielsm, try it with zoning patch to feel the difference xD
11:49:50  <nielsm> hmm I should factor out ForStationsNearTile(TileIndex tile, int threshold, Func callback)
11:50:10  <nielsm> and derive ForStationsNearTown from that
11:50:41  <Gabda> nielsm: typo in use kdtree:remove for towns commit msg, one less :
11:51:13  <nielsm> oops :P
11:51:19  <Gabda> (I did not want to make a review comment just on this :) )
11:51:22  <nielsm> well it'll probably get squashed at some point
11:51:38  <nielsm> right now it's just a dev diary commit log
11:52:03  <Eddi|zuHause> i probably shouldn't try to play astroneer again before they fixed the entering-vehicle-bug
11:52:31  <Gabda> that was going to be my next question, if you plan to squash the fixes later
11:52:32  <nielsm> hmm regressions fail, interesting
11:54:40  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
11:54:51  *** sim-al2 has joined #openttd
11:58:00  *** Flygon has quit IRC
12:15:44  *** Progman has joined #openttd
12:20:17  <nielsm> I don't understand how this has broken ScriptVehicleList_Station
12:36:52  *** Samu has joined #openttd
12:37:22  <Samu> hi
12:52:00  <nielsm> this should really not be possible, all of a sudden some vehicles are no longer considered to be visiting a certain station in the regression?
12:52:08  *** Thedarkb-T60 has joined #openttd
13:00:32  <Gabda> are they considered to visit another station instead?
13:01:56  <nielsm> I'm not sure
13:05:04  <nielsm> but the GetClosestTown() ListDump result is correct at least
13:15:53  <nielsm> AIOrder::UnshareOrders needs documentation on what happens to the orders list afterwards, is it now a copy or is it cleared?
13:22:55  <nielsm> InsertConditionalOrder and ditto append don't seem to actually have a way of specifying the jump condition?
13:25:18  <Samu> i think it is cleared
13:25:36  <Samu> the UnshareOrders question
13:25:42  <nielsm> if you know the answer, a quick PR to fix it would be good :)
13:29:16  <nielsm> well at least I can inspect this now
13:32:27  *** octernion has joined #openttd
13:35:18  <nielsm> okay it's probably a difference in station numbering somehow
13:38:18  <nielsm> yeah, it is
13:38:20  *** snail_UES_ has joined #openttd
13:49:16  <nielsm> why are station signs missing in this regression run...
13:49:51  <nielsm> well only of the AI player
13:51:46  <Samu> sorry, was having lunch. I don't know if that's the intention
13:51:59  *** andythenorth has joined #openttd
13:52:08  <Samu> unsharing orders, clears the orders list
13:52:16  <nielsm> it doesn't matter what the intention is
13:52:21  <nielsm> document what actually happens
13:52:34  <nielsm> right now there is no intention because there is no documentation
13:53:00  <Samu> Don't know how other AIs use that function
13:53:07  <Samu> what they expect
13:53:24  <nielsm> if any AI uses it and expects that orders become a copy, well that AI is buggy
13:53:39  <nielsm> since that goes against the actual behaviour
13:54:00  <nielsm> most likely everyone has just tested what happens (or read the code)
13:54:43  <nielsm> but document it and it becomes correct behaviour by definition and anyone assuming otherwise were buggy all along
13:55:07  <Samu> makes sense
14:00:55  <Samu> I'm not great at english, but will try
14:01:00  *** snail_UES_ has quit IRC
14:07:57  <Samu> * @note   This also clears the orders list from the given vehicle.
14:08:07  <Samu> good english?
14:08:57  <nielsm> "After unsharing orders, the orders list of the vehicle is empty." and just part of the normal description text, not a note
14:09:03  <nielsm> and I found the reason for the bug
14:09:14  <nielsm> regression failure
14:10:14  <Samu> what bug, sorry I wasn't paying attention
14:11:06  <nielsm> regressions failing in my kdtree branch
14:11:50  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
14:15:46  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick opened pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle.
14:16:13  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh approved pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle.
14:19:51  *** sim-al2 has quit IRC
14:20:46  *** andythenorth has quit IRC
14:24:52  <supermop_work> took me an hour to get to work on my two stop commute
14:25:56  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh merged pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle.
14:26:22  <supermop_work> what
14:26:37  <supermop_work> i don't want stop sharing orders to work that way
14:26:51  <nielsm> for AI's
14:26:55  <nielsm> it's been working that way all the time
14:27:00  <nielsm> when an AI does it
14:39:23  <peter1138> I suggest adding a parameter to decide if it should wipe or copy.
14:39:41  <peter1138> Then add the appropriate compat stuff.
14:40:53  <nielsm> I'm not sure, but I think if you call CopyOrders with destination a vehicle that currently has shared orders, the sharing is cancelled
14:44:51  *** octernion has quit IRC
14:59:20  <Samu> dont know what's kdtree supposed to do
14:59:42  <Samu> too jargon for me
15:01:50  <nielsm> faster lookup of stations and towns near some tile area
15:05:02  <nielsm> it does help nearest town lookup speed the way AI depends on it, so there is in fact a performance improvement with kdtree there, yay
15:05:29  <nielsm> not quite as big as the voronoi patch, but still pretty good
15:12:33  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
15:14:30  <Samu> looks like error-prone?
15:15:22  <nielsm> it's tricky since it needs to update an index every time the indexed objects are added, removed, or change position
15:15:37  <nielsm> so there is some risk of forgetting an update somewhere
15:35:25  <Samu> what about the overused circular tile search?
15:36:58  *** andythenorth has joined #openttd
15:37:29  <nielsm> whatever needs to be searched for needs to be indexed first, and creating the index can be expensive
15:38:06  <nielsm> so it's only useful for things that don't move very much, and aren't created/removed all the time
15:38:49  <nielsm> industries or industrytiles may also be a candidate but not sure
15:40:15  <_dp_> wow, even master eats 2Gb with 60k stations
15:40:38  <_dp_> I'm not opening that with non-rect patch :p
15:40:58  <peter1138> What savegame?
15:41:17  <_dp_> peter1138, wait a sec, I'll make one with less stations
15:41:31  <peter1138> No, that's fine, I have 32GB RAM :p
15:42:03  <_dp_> yeah but I don't and I still want to see the effect :p
15:42:31  <_dp_> and not just dead pc kind of effect xD
15:45:50  <peter1138> I wonder how much extra memory non-rect uses now.
15:45:59  <peter1138> I've not been measuring that at all
15:47:08  <Samu> an ai that uses many stations, buoys included?
15:47:12  <Samu> shipai
15:47:16  <Samu> nocab with ships
15:47:18  <peter1138> Buoys don't have catchment.
15:47:21  <Samu> oh
15:47:47  <peter1138> Also the catchment memory is dynamic, so a 1x1 station uses less than 64x64.
15:47:48  <Samu> maybe admiralai with buses
15:48:09  <Samu> my ai doesn't mass much stations
15:48:49  <Samu> brb let me look at my tests
15:49:00  <peter1138> A 1x1 bus stop should use 7 bytes for the bitmap data, and 8+4+4+4 for the metadata about the bitmap.
15:49:07  <peter1138> Hmm, I could make that 8+4+2+2 thinking about it.
15:49:19  <peter1138> 16 bytes would be neater than 20 bytes.
15:49:29  <peter1138> Actually!
15:49:39  <peter1138> It already yes.
15:50:22  <peter1138> Oh, another 16 bytes to store capacity and count of the data.
15:50:26  <peter1138> size_t :/
15:51:37  <peter1138> The bitmap data would be around 800 bytes for the largest station size
15:52:40  <_dp_> surprisingly non-rect doesn't use more memory... I must be doing smth wrong xD
15:53:00  <Samu> Nonocab
15:53:01  <_dp_> guess 1x1 stations are big part of it
15:53:05  <Samu> simleai
15:53:10  <Samu> simpleai
15:53:14  <Samu> admiralai
15:53:33  <Samu> but they don't reach any close to 64k stations
15:53:38  <Samu> about 2.7k
15:53:39  <peter1138> Hmm, yes, wentbourne is faster on my i5 @ 3.3 GHz than my i7 @ 4.5 GHz
15:53:46  <peter1138> So hyperv is quite a performance hit.
15:53:59  <Samu> what is this wentbourne i keep hearing
15:54:10  <peter1138> A CPU heavy savegame.
15:54:33  <Samu> oh where is i
15:54:34  <Samu> t
15:54:54  <peter1138> I linked to it in my issue about frame rate performance performance.
15:55:41  <peter1138> /usr/bin/ld: string.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
15:55:45  <peter1138> Well that's interesting.
15:57:02  <Samu> does not respond
15:57:50  <Samu> ah, got it
15:57:59  <_dp_> I wonder what uses so much memory in master, could it be std::list?
15:58:07  *** Wormnest has joined #openttd
15:58:14  <peter1138> Probably the number of orders ;p
15:58:32  <peter1138> Should we add a memory profile window? ;)
15:58:42  <_dp_> but I don't have any vehicles
15:59:00  <peter1138> It was a joke.
15:59:11  <peter1138> There's also the sprite cache.
15:59:35  <Samu> wow that's slow :p
16:00:09  <Samu> 5 fps
16:01:26  <peter1138> Hmm, prozone 13 has some very large catchment areas.
16:01:58  <Samu> how do you have over 5000 road vehicles
16:02:10  <peter1138> RVs is the performance killer in that save.
16:02:15  <peter1138> Constantly pathfinding.
16:02:42  <peter1138> I started to adapt the ship path cache to rvs last night, but it didn't quite work :-)
16:04:14  <Samu> switched to NPF, duplicated ms
16:08:33  <Samu> too many roads
16:08:58  <Samu> why wouldn't cache work for road vehicles?
16:10:12  <nielsm> they run on fixed tracks, not quite the same as open water
16:18:42  <peter1138> Samu, it does work, but I had a bug.
16:18:46  <peter1138> And it was 3am, so I went to bed.
16:19:08  <peter1138> It dropped ms/t for RVs from 60ms to 25ms.
16:19:15  <peter1138> And that was with it broken.
16:19:43  <DorpsGek_II> [OpenTTD/OpenTTD] pi1985 updated pull request #7029: #6315 Rail fences in snow or desert
16:22:34  <nielsm> well, that was an attempt
16:22:40  <nielsm> but it failed
16:22:55  <nielsm> couldn't rebase onto master
16:25:50  <peter1138> Certainly a git history fail.
16:30:15  *** Gabda has quit IRC
16:32:55  *** Gabda has joined #openttd
16:35:30  *** glx has joined #openttd
16:35:30  *** ChanServ sets mode: +v glx
16:37:01  *** sla_ro|master has joined #openttd
16:38:08  *** Gja has joined #openttd
16:41:19  <peter1138> Uhm... crash in squirrel? :S
16:42:51  <Samu> you get 60 ms? i get 130 ms, trash cpu :|
16:43:20  <peter1138> Hmm, why would Realloc fail on 32 items?
16:43:41  <peter1138> 32 bytes, in fact.
16:43:50  <glx> OOM ?
16:44:19  <Samu> out of mana?
16:45:24  <Samu> what the heck
16:45:59  *** kiwitree has quit IRC
16:48:21  <peter1138> Could be some AI regression with non-rect-catchment, I guess.
16:48:39  <Samu> heh, you have lost ships in that savegame, because towns blocked passage
16:50:44  <peter1138> I've never played that game.
16:50:53  <peter1138> It's just a savegame I use for stress testing.
16:51:48  <andythenorth> imagine the stress those ships are feeling
16:51:57  <andythenorth> eh can we give vehicles an emotional quotient? o_O
16:52:02  <andythenorth> 'this vehicle is happy'
16:52:06  <andythenorth> 'this vehicle is sad'
16:52:06  *** Gja has quit IRC
16:52:11  <andythenorth> 'this vehicle has existential dread'
16:52:31  <andythenorth> 'this vehicle took uppers and is travelling at double the safe speed'
16:54:13  <Samu> when will you do something about prevent town block pr?
16:54:28  <peter1138> When we feel like it.
16:54:43  <Samu> ok
16:54:58  <Samu>
16:55:00  <Samu> now
16:55:02  <Samu> :P
16:55:19  <peter1138> No, when We feel like it, not when you feel like it.
16:56:06  <peter1138> Hmm, okay, so my insert algorithm is wrong.
16:56:17  <andythenorth> it's a very uninteresting problem, that probably does need solved one day samu
16:56:23  <peter1138> I guess that is corrupting memory.
16:56:27  <andythenorth> but 'one day' is probably not 'today' on any given day
16:58:22  <andythenorth> so...errr....k-d tree for storing cargo payment rates that vary by map location? o_O
17:01:34  <peter1138> No?
17:06:13  <andythenorth> figured
17:06:23  <andythenorth> k-d tree for storing trees? o_O
17:06:40  <andythenorth> pin a random tree seed to one in 16 tiles or something
17:06:44  * andythenorth BS ideas
17:24:39  <nielsm> so, we should really have a unit test framework too, not just the integration test that the current regressions are
17:25:01  *** Pikka has quit IRC
17:29:21  *** HerzogDeXtEr has joined #openttd
17:34:15  * andythenorth has wondered about that
17:34:27  <andythenorth> unit tests are massive investment of time
17:34:37  <andythenorth> but when they do start catching regressions, they're your best friend
17:50:48  <Eddi|zuHause> unit tests are hard to put together afterwards
17:51:11  <Eddi|zuHause> because you must first split the program into units that can be tested
17:51:29  <nnyby> there are many standalone functions in openttd that could definitely be unit tested as is
17:51:40  <nnyby> i've been meaning to try setting something up for that
17:52:27  <nielsm> first unit testing question: reinvent the wheel or import a huge library for it?
17:53:36  <andythenorth> unit tests have some kind of coverage-related negative approach initially
17:53:47  <Eddi|zuHause> probably go with the library (the user shouldn't be bothered with this, right?)
17:53:56  <nnyby> my first stab would be to use a testing library, ideally a small one instead of a huge one
17:53:57  <andythenorth> where they have to be maintained, they trigger on false positives a lot, and they don't have enough coverage to catch many real cases
17:54:34  <andythenorth> there's a critical mass of tests needed before thye're productive
17:54:39  <andythenorth> they're *
17:54:49  <nnyby> if the functions you're testing are reasonably simple, you'll never get false positives
17:55:21  *** Sacro has quit IRC
17:55:34  *** Sacro has joined #openttd
17:55:51  <Eddi|zuHause> are the simple functions really worth testing, though?
17:58:12  <nnyby> well there's kind of an art when deciding what to test: first you would test the stuff that's well-understood but widely used throughout the application, like the Pool functions. you could write a bunch of tests that test the limits of these data structures, etc. and find bugs that way. Or just rely on Samu :P
18:00:05  <nielsm> core/ parts, blitters, pathfinder cores, are some of the lower hanging fruit presumably
18:03:59  <nnyby> i imagine there are many edge cases that could be found and fixed in all those parts using automated tests. that said, would a user ever run into many of these edge cases? maybe not. Still, we could get some assurance that these core parts are behaving as expected
18:04:37  <nielsm> for instance the sprite sorting bug we merged in a little while ago, it'd be nice if a test could have caught that
18:08:15  <Gabda> today I've learned what is the difference between vector resize and reserve... and I've learned it the hard way.
18:08:25  *** Wolf01 has joined #openttd
18:09:02  <Wolf01> o/
18:10:12  *** synchris has joined #openttd
18:15:27  *** frosch123 has joined #openttd
18:20:17  <Samu> this TODO is false
18:20:20  <Samu> it works
18:20:23  <Samu> TODO: Have yet to verify if it's working correctly when dealing with ship depots and locks.
18:21:08  <Wolf01> It's not false, you verified it works, remove it
18:23:14  <frosch123> andythenorth: <- i wanted to transfer that to your account, but gh said andy/firs already exists :p
18:39:12  *** gelignite has joined #openttd
18:49:19  *** m3henry has joined #openttd
18:51:47  <Samu> it's in a quote
18:52:38  <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick commented on pull request #6931: Change: Prevent town growth from blocking ships
18:55:00  <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports
18:57:40  <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports
18:59:27  *** andythenorth has quit IRC
19:05:11  <nielsm> Gabda: "*** b/src/town_cmd.cpp: No newline at end of file"
19:05:51  <Gabda> right
19:06:06  <Gabda> there will be one in the next push
19:10:18  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
19:11:05  <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports
19:17:10  <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7250: K-d tree data structure for spatial lookups
19:19:33  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
19:28:51  * peter1138 returns from Nando's
19:34:08  *** HerzogDeXtEr has quit IRC
19:38:20  <peter1138> Hmm, TileY(st->xy) = 8192. That seems wrong :/
19:40:21  <Samu> 4096, 8192
19:41:05  <DorpsGek_II> [OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area
19:42:01  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area
19:44:12  <DorpsGek_II> [OpenTTD/website] TrueBrain commented on issue #60: Can't select 1.8.0 as maximum openttd version
19:44:13  <DorpsGek_II> [OpenTTD/website] TrueBrain closed issue #60: Can't select 1.8.0 as maximum openttd version
19:47:19  <nielsm> TrueBrain: there is nowhere else to report bananas bugs, someone in here told him to report it there in lack of better
19:48:16  <TrueBrain> nielsm: lol; well, that is a bit of bad advise in my opinion, as the people who can act on it are not looking into those issues
19:48:25  <TrueBrain> when in doubt with bugs, I suggest we tell people to email info@
19:48:39  <TrueBrain> a much wider audience reads that :)
19:48:58  <TrueBrain> (and are easier forwarded to people who can deal with it, etc :D)
19:50:52  <TrueBrain> peter1138: ugh .. don't get my started about Nando's .. last time I was in Nando's, it took 30 minutes before our food was prepared .. that was not what we expected when we sat down for lunch .. *grumpy grumpy*
19:51:15  <TrueBrain> nielsm: in the bigger picture, BaNaNaS should be replaced :D But those things take time :)
19:51:26  <peter1138> Ah, this was dinner so we didn't mind.
19:51:33  <peter1138> It was a bit slow, but we had starters ;P
19:52:18  <nielsm> hmm I should find a solution to not have kdtree.hpp included in town.h
19:53:21  <TrueBrain> you really implemented another tree? :D Nice :D
19:53:24  <TrueBrain> what does this one solve?
19:53:33  <peter1138> That's an issue with complex classes and C++ :(
19:54:23  <nielsm> TrueBrain: spatial lookup, "find point nearest this one" and "all points inside rectangle"
19:55:11  <TrueBrain> has been a while since OpenTTD has seen a new algorithm (mathematical one, I mean), not? :D
19:56:51  <planetmaker> g'evening
19:57:01  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
19:57:24  <nielsm> this one requires quite a bit of care, as that latest commit shows :P
19:57:56  <TrueBrain> the more complex the trees ..... :)
19:58:06  <TrueBrain> we had many issues in the past too, so no worries :P That is normal :D
19:58:25  <TrueBrain> lot of hardcoded "% 2"
19:58:36  <TrueBrain> do I get it right it is forced in a space of 2 dimensions?
19:58:41  <TrueBrain> (or am I misunderstnding this tree :D)
19:59:27  *** andythenorth has joined #openttd
19:59:34  <nielsm> yeah it assumes 2D
19:59:47  <TrueBrain> possibly nice to make that at least a constant of some sort :)
19:59:49  <nielsm> and homogenous dimensions
19:59:53  <nielsm> it's not truly generic
20:00:41  <TrueBrain> but so first you lookup the X, than within that set the Y .. so in this case it is like a red/black tree in a red/black tree on each leaf of the first?
20:00:52  <TrueBrain> (just curious btw :D I like how trees are used in games)
20:01:23  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
20:01:57  <nielsm> yep, every level of the tree splits in a different dimension in turn
20:02:27  <andythenorth> yo TrueBrain
20:02:43  <TrueBrain> nielsm: nifty
20:02:45  <nielsm> it's like a BSP tree with implicit orientation of the splitting plane :)
20:02:46  <TrueBrain> andythenorth: yo
20:03:05  <TrueBrain> nielsm: also means it is fast in range checks, or only for specific leafs?
20:03:46  <nielsm> TrueBrain, you mean checks like "are any points within X distance to given one?"
20:04:26  <TrueBrain> nielsm: I mean, is there anything between X n .. y and Y w .. z
20:04:50  <nielsm> that's one of the operations implemented yes
20:04:55  <TrueBrain> cool :D
20:05:00  <nielsm> I haven't benchmarked it, but it should be fast-ish
20:05:04  <TrueBrain> this begs for UnitTests btw :P
20:05:11  <TrueBrain> OpenTTD so needs that :D
20:05:23  <nielsm> since it can discard any branch of the tree outside the rectangle
20:05:57  <TrueBrain> come to think of it, even if it wasn't, still O(log n * log m) .. so still a very low amount of complexity
20:06:02  <TrueBrain> even in worst cases
20:06:30  <nielsm> I think this also has potential for selecting visible viewport objects
20:06:32  <nielsm> (signs)
20:06:54  <nielsm> the hard part is building and updating the index in the right places
20:07:33  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7250: K-d tree data structure for spatial lookups
20:08:17  <Gabda> the only problem with signs is the width of the sign
20:08:35  <TrueBrain> well, anything that avoids iterating all Towns is a good step in the right direction in my book :P (at the cost of memory, ofc .. but memory limitations are much less likely these days)
20:08:46  <Gabda> if you have a max width, you can add that to the search rectangle
20:08:59  <Gabda> but is there a max width?
20:09:03  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups
20:09:16  <nielsm> TrueBrain, even more iterating all stations!
20:09:25  <TrueBrain> :D
20:09:30  <TrueBrain> means the game .. scales :P
20:09:37  * LordAro iterates TrueBrain
20:09:47  <nielsm> maybe 4096^2 maps will become viable???
20:10:03  <TrueBrain> NOOOOOO :P
20:10:08  <LordAro> ha
20:10:20  <TrueBrain> but yeah .. who to bribe to get UnitTests in OpenTTD? :)
20:10:28  <TrueBrain> proving it is correct is nicer than hoping it is :D
20:10:38  <nielsm> nnyby volunteered for unit tests earlier! :D
20:11:09  <Gabda> I still hope that my voronoi diagram and the sign filter can survive
20:11:22  <TrueBrain> isnt this complimentary to that?
20:11:24  <Gabda> or maybe one of them :)
20:12:02  <Gabda> yes
20:12:42  <DorpsGek_II> [OpenTTD/OpenTTD] TrueBrain commented on pull request #7250: K-d tree data structure for spatial lookups
20:14:35  <TrueBrain> really interesting work nielsm :) Nice :)
20:16:15  <nielsm> I hope the code is sufficiently clear too :)
20:16:26  <nielsm> and the use of lambdas is acceptable :D
20:16:44  <TrueBrain> it still makes me want to puke when I read it in C++ :P But that is just me :D
20:16:49  <peter1138> When does bananas get moved to github then?
20:17:03  <TrueBrain> peter1138: never, I think
20:17:06  <glx> I prefer lambdas to templates :)
20:17:09  <peter1138> When do I replace my middle monitor?
20:17:17  <TrueBrain> yesterday
20:17:20  <TrueBrain> package arrives tomorrow
20:17:21  <peter1138> Ah, it's just come back to life.
20:18:08  <Wolf01> Mmmh, novus is just a bit hostile
20:18:19  <andythenorth> when do we do [x]
20:18:19  <andythenorth> ?
20:18:26  <TrueBrain> before [y]
20:18:58  <TrueBrain> how is beta3 going btw? Are we still on target for 1st of April?
20:19:43  <nielsm> there haven't been a lot of talk about bugs, at least
20:19:57  <nielsm> but do we know how many have downloaded beta2 ?
20:20:12  <TrueBrain> hmm ... I can pull the nginx logs, and grep, I guess
20:20:34  <LordAro> beta3 or RC1?
20:20:39  *** synchris has quit IRC
20:20:52  <TrueBrain> if there are no bug reports, RC1 ofc
20:20:59  <TrueBrain> (and all the functionality is in)
20:21:18  <TrueBrain> 5 open for 1.9 ..
20:21:22  <nielsm>
20:21:24  <nielsm> yea
20:21:56  <LordAro> i suspect 6922 will slip
20:22:12  <TrueBrain> okay, downloading all the logs will take a bit of time :D File by file is a bit slooowwwwwwwwww
20:22:19  *** sla_ro|master has quit IRC
20:22:45  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on issue #7189: fluidsynth driver plays music too loudly
20:31:04  <TrueBrain> okay, taking guesses how often beta2 is downloaded .. it is out a week now
20:31:07  <TrueBrain> and it is a beta
20:31:09  <TrueBrain> keep that in mind
20:31:10  <TrueBrain> GO
20:31:53  <andythenorth> 3500
20:32:03  <TrueBrain> 3200 ... impressive andythenorth :D
20:32:25  <TrueBrain>     158 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-macosx.dmg
20:32:25  <TrueBrain>     178 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-windows-win32.exe
20:32:26  <TrueBrain>     678 /openttd-releases/1.9.0-beta2/
20:32:26  <TrueBrain>    1945 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-windows-win64.exe
20:32:43  * andythenorth sees newgrf downloads a lot, took a guess
20:32:45  <TrueBrain> 3 times more dmg downloads than zip, for OSX
20:32:59  <andythenorth> only wrong people would get the zip
20:33:03  <TrueBrain> we have had worse RCs, I can tell you :)
20:33:05  <andythenorth> zip is basically user error :P
20:33:15  <TrueBrain> we can remove the zip :)
20:33:18  <TrueBrain> if it is not useful
20:34:22  <peter1138> What is it for?
20:34:35  <peter1138> Oh, for people who don't want to install.
20:34:40  <peter1138> Call it the "portable" edition, I guess?
20:36:36  <andythenorth> on the mac, it's for people who don't know what a dmg is
20:36:50  <andythenorth> so, people who only use app store
20:37:19  <andythenorth> also I think we have about 10k active players, based on newgrfs
20:37:26  <andythenorth> so 3200 beta downloads is a lot
20:37:52  <TrueBrain> it is
20:38:01  <peter1138> Right, I think that's one bug fixed... just running this savegame for a while.
20:39:53  <peter1138> _dp_, so why does OpenTTD gobble lots of memory for you?
20:40:44  <frosch123> andythenorth: i remembered why we are not moving stuff away from devzone yet. eints :p
20:41:45  <_dp_> peter1138, dunno, I suspected std::list but that's not it
20:42:04  <_dp_> peter1138, how much memory does it take when you open that save?
20:42:16  <_dp_> it's 1.6GB for me
20:43:11  <peter1138> Which save, Wentbourne?
20:43:19  <_dp_> peter1138, no, the one I posted
20:44:21  <_dp_> it uses smth crazy like 30kb per station
20:44:25  <peter1138> O...
20:44:30  <peter1138> Waiting for it to load.
20:44:38  <peter1138> debug-level 3, and some debug printfs...
20:45:08  <peter1138> Yeah, 1.7GB
20:45:56  <_dp_> well, at least that's not a g++ fault I guess
20:46:16  <peter1138> Ooh, it crashed.
20:46:41  <peter1138> Hmm
20:46:56  <peter1138> And I wasn't in the debugger :(
20:47:16  <frosch123> core dumps!
20:48:17  <peter1138> Oh, I unpaused and it build more stations...
20:48:55  <_dp_> peter1138, build? are you sure those aren't just signs jumping around?
20:49:06  <_dp_> coz they do xD
20:49:10  <peter1138> Uhrm
20:49:38  <_dp_> some stations are on water and get flooded xD
20:50:52  <nielsm> it makes my kdtree branch crash too, so will have to debug that as well
20:50:59  <Gabda> nielsm: I checked your find nearest fix, on a random map your CalcNearestTownFromTile gives the same result as the old one for all the tiles.
20:51:05  <_dp_> xD
20:51:20  <nielsm> Gabda nice, thanks
20:51:49  <nielsm> takes a little while to load..
20:52:02  <peter1138> Yeah, in my effort to give it less work to do, I don't check st->rect enough.
20:52:30  <peter1138> I could perhaps make BitmapTileIterator handle an invalid catchment_tiles more gracefully.
20:52:43  <peter1138> But I think that would just hide other bugs.
20:52:58  <nielsm> hmm, it's spending a LOT of time with text layout code herre
20:53:34  *** Gabda has quit IRC
20:53:45  <_dp_> btw, does it cache sprites for station signs?
20:54:30  <peter1138> Station signs are text.
20:54:44  <andythenorth> frosch123: yes I was aware of eints problem :)
20:54:50  <nielsm> and now it's taking its time in RecomputeIndustriesNear
20:55:03  <andythenorth> but I'm about to start FIRS v4, and FIRS v3 has just had a translations release
20:55:13  <_dp_> peter1138, well, yeah, but you can either render text each time or cache the bitmap
20:55:15  <andythenorth> FIRS major releases take at least a year I guess
20:55:21  <nielsm> maybe I should make a kdtree for industries as well
20:55:22  <_dp_> I've no idea what openttd actually does there
20:55:32  <peter1138> Ah, no, it renders.
20:55:37  <peter1138> Well, "renders"
20:55:43  <peter1138> Each glyph is already a bitmap.
20:55:53  <frosch123> andythenorth: anyway, you need to delete andy/firs, so i can transfer ownership of frosch/firs
20:55:59  <andythenorth> yup
20:56:19  <_dp_> peter1138, ehm, don't think that would work for a freetype
20:56:54  <peter1138> You say that, but that is exactly how it works.
20:56:58  <andythenorth> frosch123: it's gone :)
20:57:06  <nielsm> ugh, it's taken a full minute for the first 12k stations
20:58:19  <peter1138> Damn, I didn't note the date when it crashed last time.
20:58:35  <peter1138> So we need to reduce the station limit? :D
20:59:08  <nielsm> eh optimise these CircularTileSearches away a bit?
20:59:18  <nielsm> and don't layout as many station signs?
20:59:23  <nielsm> (at a time)
20:59:26  <peter1138> Are you in non-rect-catchment?
20:59:26  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on issue #7159: Reverse at signal timeouts occur unexpectedly quickly, affects title game
20:59:31  <nielsm> nah kdtree
20:59:34  <peter1138> Ok.
20:59:39  <peter1138> Then it may already be gone :p
21:00:35  <_dp_> peter1138, I just remember there being some tricky stuff like rendering chars differently in different combinations
21:00:55  <_dp_> peter1138, but I guess freetype is a smart library, it can cache those as well
21:01:19  <nielsm> peter1138, did you update RecomputeIndustriesNear ?
21:01:31  <nielsm> (it looks like it does depend on catchment area so probably yes)
21:01:59  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7159: Reverse at signal timeouts occur unexpectedly quickly, affects title game
21:02:19  <peter1138> nielsm, yes, that's pretty core to my changes.
21:02:27  <peter1138> Okay, 8th Apr 2050.
21:02:33  <peter1138> I think that's after the crash.
21:02:49  <DorpsGek_II> [OpenTTD/OpenTTD] michicc opened pull request #7252: Fix #7159, e934f09: Waiting time at red one-way signals was too short.
21:02:55  <frosch123> andythenorth: well, you need to accept it :)
21:03:28  <_dp_> well, station limit is fine for master except for memory issue but that's separate
21:03:48  <frosch123> i wonder whether there is an api limit on how many repos you can dump on others
21:05:06  <nielsm> uh wth
21:05:35  <nielsm> the node_idx is valid, the debugger can look up the item in the nodes vector, but the value for n is invalid
21:05:42  <nielsm> that should not happen?
21:05:50  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
21:06:14  <michi_cc> _dp_: No, font glyphs are always rendered the same, but the mapping of code point to font glyph can change. This is the job of ICU or Unicows and not FreeType though.
21:06:46  <michi_cc> s/Unicows/Uniscribe/ Unicows does exists, but is something else :p
21:07:16  <nielsm> ahh, no, I know what happened
21:07:23  <nielsm> the vector was reallocated, of course
21:07:28  <peter1138> Oh, so this savegame still takes ages to load without my patch.
21:08:35  <_dp_> peter1138, don't worry too much it takes a while even in master xD
21:08:58  <peter1138> Hmm, performance with non-rect seems better.
21:09:04  <_dp_> nvm, I misread that
21:09:05  <peter1138> 1.7x game speed vs 2.1x
21:09:19  <peter1138> Also there are times when master pauses .
21:09:32  <peter1138> Ah, so did mine, just luck I guess.
21:10:40  <peter1138> Weird savegame. Performance is very variable.
21:11:31  <andythenorth> wow I had to use email to accept a repo :)
21:11:34  <andythenorth> how retro
21:11:51  <andythenorth>
21:12:05  <peter1138> Now I need to find out why my sorted-insert doesn't work.
21:12:16  <andythenorth> frosch123: thanks \o/
21:12:48  <frosch123> he, you had to confirm via email? i was suprised i did not have to confirm it at all
21:12:55  <frosch123> i expected a "repeat password" or so
21:12:57  <andythenorth> first thing is to find the hg scripts for version etc and migrate I guess
21:13:00  <DorpsGek_II> [OpenTTD/OpenTTD] michicc commented on pull request #7252: Fix #7159, e934f09: Waiting time at red one-way signals was too short.
21:13:08  <_dp_> peter1138, is it on github?
21:13:48  <frosch123> andythenorth:  do we need to remove it from eints? i guess so..
21:14:09  <frosch123> or do you want to pull translation changes from hg or something?
21:16:28  <peter1138> No.
21:16:46  <andythenorth> frosch123: not sure what's best, but incoming translations aren't useful when doing a major version
21:16:52  <andythenorth> there's a lot of churn
21:17:11  <andythenorth> but eh, I can work in a branch now anyway :)
21:17:41  <andythenorth> remove from eints, and lock the devzone repo I think
21:18:06  <peter1138> *** Error in `bin/openttd': malloc(): memory corruption (fast): 0x00000000087b0120 ***
21:18:09  <peter1138> :-)
21:18:29  <peter1138> This list cotains 29, 29, 32, 33, 34
21:18:37  <peter1138> Considering it's meant to be unique...
21:18:54  <_dp_> peter1138, well, ok, just make sure you're not overwriting the data you're moving, that's the most common mistake in such insert)
21:18:54  <glx> each 29 is unique :)
21:19:01  <peter1138> Writing crash savegame...
21:19:15  <peter1138> It hangs here :-)
21:19:37  <nielsm> welp, then the game decided it was time to build a new industry, and then it got back to recomputing nearest industries for all stations
21:19:46  <nielsm> but looks like I did fix that crash
21:20:09  <peter1138> nielsm, yeah, I really did rework all that stuff.
21:20:36  <andythenorth> frosch123: is it known how to remove FIRS from eints?
21:20:37  <peter1138> I think at this point you'd be giving me needless conflicts, or vice-versa.
21:20:40  <andythenorth> I can remove the user
21:21:00  <nielsm> I'm also running a debug build here, it's rather much faster in release :P
21:21:14  <frosch123> andythenorth: removing the user blocks eints from committing
21:21:21  <frosch123> i can delete the eints project manually
21:21:24  <glx> but release is so slow to build ;)
21:21:30  <frosch123> but we can also keep it running an make prs from it
21:21:35  <frosch123> every now and then
21:21:41  <andythenorth> ok
21:21:52  <andythenorth> not sure how to mark the devzone repo as deprecated
21:22:05  <andythenorth> I can put a message on devzone project page
21:22:07  <frosch123> put it into the description
21:22:08  <nielsm> glx exactly!
21:22:15  * andythenorth will miss devzone
21:22:22  <andythenorth> I prefer redmine to github in many places
21:22:23  <frosch123> not sure whether we did anything for nml and eitns
21:22:26  <peter1138> Is it slow to build? I don't notice much difference.
21:22:31  <peter1138> Oh, it is with MSVC.
21:22:40  <andythenorth> but I won't miss devzone crashes :P
21:22:44  <peter1138> I'm thinking about getting another SSD and having a native Linux install, like I used to use.
21:22:57  <peter1138> Hmm, or I could just remove Steam games I never play (most of them)
21:23:12  <nielsm> the release build slowness with msvc is mainly due to the LTCG
21:23:24  <andythenorth> there's never any downside to getting another SSD
21:23:34  <nielsm> link takes forever since that's where it actually generates most of the machine code
21:24:06  *** gelignite has quit IRC
21:24:13  <peter1138> When you add a printf and it no longer crashes :S
21:24:22  <nielsm> heisenbugs!
21:26:51  <peter1138> Oh, wrong save.
21:27:44  <peter1138> Okay, so it was meant to instead station 18 before 39.
21:27:54  <peter1138> But didn't... 39, 39, 40, 41, 43...
21:28:15  <glx> at least it inserted an element
21:28:17  <peter1138> I notice the numbers are different, but then again, if it's put the 18 somewhere different...
21:28:56  <_dp_> peter1138, can you just paste a code somewhere?
21:29:11  <_dp_> i got curious xD
21:29:42  <peter1138> I found it.
21:29:49  <andythenorth> ok so this needs ported for git eh
21:29:53  <peter1138> I was using SmallVector::Insert incorrectly.
21:30:17  <peter1138> Yeah, it only failed if it realloced.
21:30:46  <nielsm> reallocations, yeah!
21:30:59  <nielsm> best and worst part about dynamic arrays
21:31:11  <_dp_> you're just using too much pointers :p
21:31:44  <peter1138> I did think about switching to station IDs
21:32:02  <peter1138> Just a dereference away.
21:32:14  <peter1138> Well, 2.
21:32:29  <peter1138> Yeah, that's fixed it :D
21:32:50  <peter1138> Now I can improve performance by removing my printfs.
21:33:36  <_dp_> wait, does station pool reallocate as well?
21:33:53  <glx> if needed yes
21:34:07  *** frosch123 has quit IRC
21:34:29  <glx> I think
21:34:43  <peter1138> The pool itself will reallocate, the items within the pool do not.
21:34:50  <peter1138> Because it's not actually pool.
21:35:06  <peter1138> The "pool" is just an array of pointers.
21:35:18  <peter1138> Hmm...
21:35:21  <peter1138> Actually I lie.
21:35:39  <peter1138> Maybe each item is allocated from a block which is never moved.
21:36:52  <peter1138>                 item = (Titem *)MallocT<byte>(size);
21:36:55  <peter1138> Suspicious.
21:37:07  <nielsm> yes that's the idea behind the pools
21:37:21  <peter1138> Which?
21:37:23  <nielsm> it's basically an arena for each of the main game object types
21:37:42  <peter1138> It's somewhat terrible as it uses macros :(
21:38:10  <nielsm> it definitely violates some C++ standard things and/or depends on UD
21:38:26  <nielsm> can't remember the specifics but it has to do with POD types
21:38:34  <nielsm> (which most things are not)
21:38:38  <peter1138>                 inline void *operator new(size_t size)
21:38:41  <peter1138> Hmm.
21:39:28  <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector
21:39:43  <peter1138> So I'm not sure if it's allocating in big chunks and then sharing that out, or allocating individually.
21:40:30  * nielsm is staring at another crash
21:40:34  <nielsm> this one I can't explain
21:41:12  <nielsm> access violation getting the tile coordinate of a station, lookup by stationid
21:41:40  <nielsm> and it reaches page 0 so somehow a nullptr has snuck in?
21:42:12  <peter1138> GetIfValid()
21:42:29  <_dp_> this->data = ReallocT(this->data, new_size);
21:42:43  <nielsm> inline uint16 Kdtree_StationXYFunc(TownID tid, int dim) { return (dim == 0) ? TileX(BaseStation::Get(tid)->xy) : TileY(BaseStation::Get(tid)->xy); }
21:42:44  <_dp_> that looks like a pointer change to me
21:42:49  <nielsm> it's that function
21:42:55  <nielsm> used during sorting
21:42:57  <peter1138> _dp_, of the pool of pointers, not the items within.
21:43:19  <peter1138> nielsm, is a TownID a Station?
21:43:49  <glx> items are allocated individually it seems
21:43:57  <nielsm> uh StationID
21:44:07  <nielsm> it's supposed to be
21:44:17  <peter1138> So is your stationid valid?
21:44:20  <nielsm> both resolve to uint16 though
21:44:23  <peter1138> Yeah
21:44:30  <peter1138> If the station was removed, then...
21:44:52  <nielsm> I'm probably not housekeeping station removals correctly in the tree
21:45:05  <_dp_> oh, it stores pointers.. I read this->data[index]; three times and still got it wrong)
21:45:23  <peter1138> Hmm, should I try benchmarking sorted insert vs append + qsort?
21:46:16  * peter1138 loads gr0_50k again
21:48:05  <peter1138> Hmm, something causes freezes.
21:48:27  <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups
21:48:27  <Eddi|zuHause> hope it's not arnold
21:48:34  <glx> autosave ?
21:48:40  <nielsm> peter1138, try disabling industry creation
21:48:41  <peter1138> Nope, not autosave.
21:48:56  <nielsm> i.e. set industries density to "manual funding only"
21:49:04  <peter1138> Ok.
21:49:24  <m3henry> peter1138: insertion is O(n), qsort is O(n log n) IIRC
21:49:33  <nielsm> if that solves it, it's the recomputing of industries near all stations that's to blame
21:49:53  <Eddi|zuHause> m3henry: we're talking about special case where the list is almost sorted
21:50:05  <m3henry> I heard
21:50:20  <peter1138> Remind me what n vs n log n means?
21:50:31  <peter1138> nielsm, yeah that helps.
21:50:38  <Eddi|zuHause> peter1138: n is better than nlogn :)
21:50:42  <m3henry> ^
21:50:43  <peter1138> Ok.
21:50:54  <_dp_> Eddi|zuHause, qsort is still n log n even on sorted
21:51:18  <peter1138> I'll remove my QSort stuff.
21:51:28  <m3henry> TBH I would use a container adapter
21:51:44  <nielsm> for inserting a single element in a sorted list, a search+insertion is better
21:51:46  <peter1138> Calling the sorter function every time would add to its cost.
21:51:52  <Eddi|zuHause> _dp_: it's been a long time since i looked at the pathological cases of various sorting algorithms
21:52:07  <peter1138> nielsm, yeah, seeing as I have to search for the item in the list anyway to see if it's already there. I wasn't just appending before.
21:52:08  <nielsm> even something as simple as appending and then repeatedly swapping the new element down until it's in position would work
21:52:34  <nielsm> but a memmove likely has better constants
21:52:39  <Eddi|zuHause> heapsort is fun
21:52:41  <peter1138> nielsm, turns out SmallVector already has an Insert() which I use. Properly this time. Sorry m3henry .
21:52:55  <Eddi|zuHause> that's about what i remember :)
21:53:05  <m3henry> Insert is the next method on the chopping block
21:53:10  <m3henry> I just finished Append
21:53:13  <peter1138> Oh, and most of the time these lists are in the order of 3 or 4 items :p
21:53:19  <peter1138> It just happens a lot.
21:53:33  <m3henry> llvm::SmallVector would be  agood fit for that
21:54:27  <nielsm> for really small vectors, I think append-and-swap-down might have the best performance, but just guessing here
21:54:27  <nielsm> :P
21:54:45  <m3henry> Should be same as insertion
21:54:52  <nielsm> anyway, I should head to bed, work tomorrow (for real this time)
21:55:21  <nielsm> m3henry, memmove based insertion might benefit from block operations in a way repeated swapping can't
21:55:32  <nielsm> gn
21:55:36  <Eddi|zuHause> with swapping you're skipping the binsearch, but the swapping operations are slower than memmove, probably
21:55:36  <m3henry> True, especially with SIMD/Vector instructions
21:56:50  <_dp_> it's hard to tell what is faster for very small arrays, needs benchmarking
21:57:04  <m3henry> godsort?
21:57:24  <m3henry> O(0)
21:57:30  <peter1138> I'm wondering if I need the bounced checking in FindStationsAroundTiles now.
21:57:34  <_dp_> for large ones sure, binsearch+memcpu is so fast that it kinda separates insertion from the rest of n*n sorts
21:57:35  <LordAro> bogosort
21:57:44  <peter1138> Oh, maybe.
21:57:49  <peter1138> There's a loop that avoids.
21:57:59  <Eddi|zuHause> m3henry: so even faster than O(1)?
21:58:03  <m3henry> Yes
21:58:18  <m3henry> God would just have the items already sorted
21:58:20  <_dp_> but for small ones it may be better with linear search and just a loop move
21:58:31  <andythenorth> hmm
21:58:31  <_dp_> no idea what's better for cpu optimizations
21:59:07  <m3henry> _dp_: bubble sort is best for n == 2
21:59:10  <m3henry> xD
21:59:57  <_dp_> m3henry, for n=2 any sort is just operator< :p
22:00:19  <Eddi|zuHause> _dp_: i'm assuming sorting algorithms are hard for optimizers because there are data dependencies all over the place
22:00:21  <m3henry> exactly, bubble just has the lowest overhead of the generic algorithms
22:00:35  <andythenorth> oof so o/c, hg has numeric revs and git doesn't :) which means newgrf versions need re-designed :P
22:00:51  <m3henry> git can
22:01:12  <andythenorth> it can?
22:01:14  <m3henry> you can count the number of commits
22:01:15  <Eddi|zuHause> andythenorth: the makefile was at some point changed to use date instead
22:01:19  <_dp_> Eddi|zuHause, merge is kinda good for parallel sorting
22:01:30  <peter1138> Oh yeah, one reason for using StationID instead of Station * is I don't need to dereference it during the insert.
22:01:49  <Eddi|zuHause> _dp_: i think merge needs more memory?
22:01:50  <andythenorth> Eddi|zuHause: it was changed back (because of collisions iirc)
22:02:18  <andythenorth>
22:02:19  <peter1138> Hmm, just realised this sorted Include is now used every where in StationList, not just my parts.
22:02:25  <Eddi|zuHause> andythenorth: but i'm sure there's a git encantment to count the revs
22:02:29  <_dp_> Eddi|zuHause, yeah, but it's not a big issue usually
22:02:33  <andythenorth> well
22:02:36  <m3henry> running `git rev-list --count HEAD` on my OTTD repo puts it at r23284
22:02:50  <andythenorth> the branch name is in the file also, so the rev might be safe
22:03:13  <andythenorth> m3henry: that's neat, that might work thanks :)
22:03:23  <peter1138> 23349 for me. In a branch...
22:03:33  <peter1138> I don't have 65 commits.
22:03:35  *** nielsm has quit IRC
22:03:59  <Eddi|zuHause> 23301
22:04:15  <Eddi|zuHause> but i haven't updated in a while
22:04:17  <peter1138> Hmm, I might be being paranoid, maybe sorting isn't even needed.
22:04:37  <m3henry> KISS?
22:05:07  <planetmaker> hm, firs on github? :D
22:05:11  <peter1138> Well, I have this hunch it matters in network games if my lists are different orders.
22:05:18  <andythenorth> planetmaker: yup, frosch moved it ;)
22:05:25  <planetmaker> :)
22:05:29  <peter1138> andythenorth, congratulations, now I can contribute.
22:05:29  <andythenorth> we can use it to figure out how to port the others
22:05:56  <andythenorth> peter1138: by rebasing my git mess :P
22:05:57  <Eddi|zuHause> now i'm at 23345
22:05:59  <andythenorth> hiding merges?
22:06:12  <glx> 23334 here
22:06:15  <peter1138> If you rebase correctly you can make them disappear.
22:06:17  <glx> in clean master
22:06:30  <andythenorth> planetmaker: any idea if we can port bundles?
22:06:42  <Eddi|zuHause> who needs clean master :p
22:07:11  <planetmaker> not yet how
22:07:37  <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area
22:07:41  <planetmaker> the more interesting one actually is less bundles imho but the build service
22:07:50  <peter1138> master is always clean :D
22:08:08  <planetmaker> but they're linked and only together really make sense
22:08:16  <peter1138> Well, I had intended to start squashing this PR, not fixing bugs :/
22:08:16  <glx> unless you forgot to switch to branch before commit yes :)
22:08:21  <Eddi|zuHause> planetmaker: i think what he meant is make the build service compile from the github repo
22:08:39  <planetmaker> I don't think so :)
22:09:09  <planetmaker> accessing the build service from a github repo is no big issue
22:09:16  <andythenorth> the question is whether to keep devzone jenkins and just have it build from github
22:09:26  <andythenorth> or whether we need a new build service
22:09:34  * andythenorth prefers changing one thing at a time
22:09:37  <planetmaker> my idea is to mimic what openttd has. preferentially
22:10:25  <planetmaker> but it works as-is. And can be made to build from whatever repo. In principle
22:10:50  <andythenorth> I would be happy to not depend on people to maintain specific physical hardware, long term
22:10:54  <planetmaker> I haven't quite figured out the github hook needed to trigger it
22:11:02  <andythenorth> but short term, a step-by-step migration is good
22:11:11  <planetmaker> ^^
22:11:23  <peter1138> glx, I did that once when I was trying out git for the first time. I had no idea what to do so I ended up wiping out the clone and starting again :p
22:11:33  <andythenorth> planetmaker: is the build service actually just jenkins?
22:11:57  <planetmaker> I've no plan to discontinue the server. But I will be happy to have the service not depend on it... it's currently somewhat like a bus factor of 1.1
22:12:23  <andythenorth> +1
22:12:31  <glx> on github you have access to azure pipelines
22:12:48  <planetmaker> yeah. That's why I think I'll try to mimic openttd's way
22:13:14  <peter1138> I think switching from hg to git is a nice step.
22:13:25  <peter1138> Whenever I tried using hg it all went wrong.
22:13:31  <andythenorth> hmm can't log in to coop jenkins
22:13:41  <LordAro> s'ok, ottd's azure-pipelines is only bus fsctor 1.5ish
22:13:48  <LordAro> factor*
22:13:56  <andythenorth> only TB can press the magic button? :P
22:14:04  <peter1138> Ok, 3 pieces of Baklava is a fuck load of energy. :/
22:14:12  <andythenorth> it's all sugar?
22:14:18  <andythenorth> planetmaker I was going to look if we just need to configure Poll SCM to fetch from github
22:14:22  <peter1138> No, it's sugar AND fat :/
22:14:23  <planetmaker> LordAro, yes-ish. But if it requires only one thing to understand both services, it's an advantage to two different things
22:14:28  <peter1138> And tastes bloody great.
22:14:31  <andythenorth> dunno if Poll SCM is what coop jenkins uses
22:14:31  <LordAro> technically anyone can reproduce it, but currently only TB understands how :p
22:14:38  <peter1138> It was the better half's birthday today, so we had a treat.
22:14:41  <planetmaker> andythenorth, polling would surely work. But I'd not be fond of it
22:14:52  <andythenorth> you want to webhook it?
22:15:00  <planetmaker> yes
22:15:21  <planetmaker> I know that polling works ;)
22:15:30  <planetmaker> that worked for nml
22:15:31  <glx> the yaml part is easy
22:15:44  <peter1138> andythenorth, also it was from a local turkish takeaway, so very moist and juicy. Not like the rancid crap that Tesco sell.
22:15:59  <andythenorth> oic
22:16:02  <planetmaker> the interesing part is actually the version thing... currently jenkins gets told what to build...
22:16:16  <andythenorth> planetmaker: I just gave you access here
22:16:18  <peter1138> I had some of that once and it had a very strange bitter taste.
22:16:20  <planetmaker> polling means it needs to decide itself
22:16:25  <andythenorth> webhooks are in settings
22:16:28  <peter1138> Like rancid coconut fat or something.
22:16:42  <andythenorth> I have only had baklava from greek or cypriot shops
22:16:44  <glx> and if you can build using the windows image you don't have to use docker :)
22:16:44  <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector
22:16:49  <peter1138> _dp_, now you can see my sorted insert, but it's working now, heh.
22:17:08  <peter1138> _dp_, the non-working version was "Insert(it); *it = st;" which of course fails on realloc.
22:18:32  <planetmaker> andythenorth, I'm still away from home till next Monday; so I definitely cannot make promises before that.
22:18:48  <andythenorth> no rush
22:19:02  <andythenorth> I need to figure out porting the makefile revision script to git
22:19:05  <andythenorth> it will take some time
22:19:32  <Eddi|zuHause> is that more than 3 lines?
22:20:04  <andythenorth> 210 Eddi|zuHause
22:20:20  <glx> IIRC Makefile and andythenorth are not friends :)
22:20:30  <andythenorth> it got better, but yeah, that's fair
22:20:35  <andythenorth> this is just a python script though
22:20:41  <Eddi|zuHause> andythenorth: that looks hopelessly overengineered :p
22:20:57  <andythenorth> everything does at first glance
22:21:16  <planetmaker> do you have access to jenkins?
22:21:25  <andythenorth> planetmaker: apparently not
22:21:33  <andythenorth> Eddi|zuHause: Chesterton's Fence might apply
22:21:48  <planetmaker> let's change that...
22:22:09  <andythenorth> Eddi|zuHause I didn't write it, Alberth did, but it replaced things that were worse to read and worse to use
22:24:19  <andythenorth> OTOH this is too complex for me to quickly port to git :P
22:25:26  <peter1138> Woo, all checks have passed.
22:28:23  <peter1138> Ah yes, I was going to see if creating an industry was a problem.
22:28:57  <andythenorth> oic, this hg-info script can take shell args
22:29:02  <peter1138> Showing station signs seems to be :-)
22:31:47  <andythenorth> oof bed
22:32:14  <peter1138> Nn
22:32:19  *** andythenorth has left #openttd
22:39:56  *** Wormnest has quit IRC
22:40:09  <Eddi|zuHause> hm, i don't know what changed, but the "BFS randomly turns into DFS" problem seems to have magically disappeared
22:44:16  <peter1138> Hmm, RecomputeIndustriesNearForAll has just bitten the dust.
22:47:42  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #6507: Crash: corrupt savegame
22:48:31  <LordAro> oh hey, it's my bug
22:50:39  <peter1138> Hmm, station finder not working :S
22:53:03  <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #6605: Crash: loading savegame
22:57:59  *** Flygon has joined #openttd
22:59:17  <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator
23:02:37  <peter1138> Yeah, tile scan is clearly better than FOR_ALL...
23:03:31  *** m3henry has quit IRC
23:04:24  <peter1138> Oh, no, FindStationsAroundTiles is a FOR_ALL :/
23:12:25  *** Wolf01 has quit IRC
23:20:14  <_dp_> ok, I blame cargodist
23:20:34  <_dp_> map<..., map<...>>[NUM_CARGO] definitely looks like a RAM black hole :p
23:21:15  <peter1138> Hmm
23:25:25  *** Samu has quit IRC
23:36:06  <DorpsGek_II> [OpenTTD/OpenTTD] nikolas opened pull request #7253: Fix #7189: Fluidsynth volume gain too high
23:38:33  <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on issue #7189: fluidsynth driver plays music too loudly
23:40:41  <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7253: Fix #7189: Fluidsynth volume gain too high
23:41:53  <_dp_> sizeof(GoodsEntry) = 136 so each station gets NUM_CARGO * 136 = 8704 bytes of basically empty space
23:43:14  <_dp_> could probably be replaced with smth like map<pair<StationID, CargoID>, GoodsEntry>
23:44:08  <peter1138> Hmm
23:44:26  <peter1138> Yeah these fixed entries were okay when we only had 12 cargo types.
23:49:36  *** drac_boy has joined #openttd
23:49:49  <drac_boy> hi there .. any git fun tonight?
23:49:56  <peter1138> We're all gits.
23:52:18  *** Progman has quit IRC
23:59:39  <peter1138> Damn it. More optimizations and... scope :/

Powered by YARRSTE version: svn-trunk