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. https://git.io/fhd39 00:06:14 <DorpsGek_II> [OpenTTD/OpenTTD] michicc merged pull request #7246: Fix #7244 #7226: OPF doesn't take 90 deg turns into account. https://git.io/fhd3v 00:06:21 <DorpsGek_II> [OpenTTD/OpenTTD] michicc closed issue #7244: OPF ships locked in a reverse-loop https://git.io/fhdOR 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 https://git.io/fhd3e 00:28:15 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened issue #7247: With lots of vehicles, PerformanceAccumulator large performance impact itself https://git.io/fhd3p 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 https://git.io/fhd3h 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://github.com/OpenTTD/OpenTTD/commit/f496970482a8456de26351b636d5589ce19fd0f1 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 https://git.io/fhdst 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 https://git.io/fh5s1 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. https://git.io/fhdsM 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. https://git.io/fhdsD 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> https://fuzzle.org/~petern/ottd/splitticks.png 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> https://fuzzle.org/~petern/ottd/splitticks2.png 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> https://fuzzle.org/~petern/ottd/splitticks3.png 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 https://git.io/fhdG0 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 https://git.io/fhdG6 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 https://git.io/fhdGQ 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. https://git.io/fhdGN 02:48:25 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1 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. https://git.io/fhdZf 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 https://git.io/fh5s1 03:12:04 <DorpsGek_II> [OpenTTD/OpenTTD] James103 commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself https://git.io/fhdZt 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 https://git.io/fhdZ3 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. https://git.io/fhdcu 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. https://git.io/fhdGN 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. https://git.io/fhdCl 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> https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:kdtree 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> https://en.wikipedia.org/wiki/Integer_square_root 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. https://git.io/fhdl6 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 https://git.io/fhdli 10:00:52 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7245: Remove: OPF https://git.io/fhdlP 10:03:11 <DorpsGek_II> [OpenTTD/OpenTTD] Eddi-z commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself https://git.io/fhdlM 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 https://git.io/fhdl7 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. https://git.io/fhd8q 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. https://git.io/fhd83 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. https://git.io/fhd8Z 10:31:47 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhd8E 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 https://git.io/fhd8g 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 https://git.io/fh5n2 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> http://bundles.openttdcoop.org/firs/push/LATEST/docs/html/cargos.html#pig_iron 10:56:47 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhd4Y 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> https://0x0.st/ziQV.png 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> https://newgrf-specs.tt-wiki.net/wiki/CargoTypes#Cargo_Labels 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> https://0x0.st/ziQg.jpg 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> https://0x0.st/ziQE.png <- 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 https://git.io/fhd4b 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 https://git.io/fhdBs 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? http://noai.openttd.org/api/1.8.0/classAIOrder.html#2b2c000cd8c8ce03e546c0c0bbce7fd3 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 https://0x0.st/zi1c.png 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 https://git.io/fhd4b 14:15:46 <DorpsGek_II> [OpenTTD/OpenTTD] SamuXarick opened pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle. https://git.io/fhdED 14:16:13 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh approved pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle. https://git.io/fhdEy 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. https://git.io/fhdED 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 https://git.io/fhdzR 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> fuzzle.org 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 https://git.io/fhZJq 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> https://github.com/OpenTTD/OpenTTD/pull/6931 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: https://github.com/frosch123/firs <- 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 https://git.io/fhdrQ 18:55:00 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fhdr5 18:57:40 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5iB 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 https://git.io/fhdoI 19:11:05 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5iB 19:17:10 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdoG 19:19:33 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdoC 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 https://git.io/fhdod 19:42:01 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdop 19:44:12 <DorpsGek_II> [OpenTTD/website] TrueBrain commented on issue #60: Can't select 1.8.0 as maximum openttd version https://git.io/fhdKe 19:44:13 <DorpsGek_II> [OpenTTD/website] TrueBrain closed issue #60: Can't select 1.8.0 as maximum openttd version https://git.io/fh5y4 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 https://git.io/fhd4b 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 https://git.io/fhdK8 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 https://git.io/fhdK0 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 https://git.io/fhdKE 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 https://git.io/fhdKa 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> https://github.com/OpenTTD/OpenTTD/milestone/1 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 https://git.io/fhdKX 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/openttd-1.9.0-beta2-windows-win64.zip 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 https://git.io/fhd63 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 https://git.io/fhd6n 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. https://git.io/fhd6W 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 https://0x0.st/zi24.png 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 https://git.io/fh5s1 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> https://github.com/andythenorth/firs 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. https://git.io/fhd6E 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 https://github.com/andythenorth/firs/blob/master/bin/hg-info 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 https://git.io/fhSz0 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 https://git.io/fhd4b 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> https://github.com/andythenorth/firs/blob/master/bin/hg-info#L71 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 https://git.io/fh5s1 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 https://github.com/andythenorth/firs/ 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 https://developer.github.com/webhooks/#events 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 https://git.io/fhSz0 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 https://github.com/andythenorth/firs/blob/master/bin/hg-info 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 https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence 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 https://git.io/fhdPu 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 https://git.io/fhdP2 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 https://git.io/fhHN6 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 https://git.io/fhdXI 23:38:33 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas commented on issue #7189: fluidsynth driver plays music too loudly https://git.io/fhdXt 23:40:41 <DorpsGek_II> [OpenTTD/OpenTTD] nikolas updated pull request #7253: Fix #7189: Fluidsynth volume gain too high https://git.io/fhdXI 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 :/