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