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

01:53<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
01:53<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
02:43<LordAro>presumably will want a release of ogfx before 1.9.0
02:56<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
03:03<@peter1138>Just needs a colour icon on the OpenGFX version of the group icons ;D
03:20-!-nielsm [~nielsm@176-23-103-56-cable.dk.customer.tdc.net] has joined #openttd
03:20-!-nielsm is "Niels Martin Hansen" on #openttd
03:24-!-Gabda [~yaaic@254C3A2C.nat.pool.telekom.hu] has joined #openttd
03:24-!-Gabda is "Gabda" on #openttd
03:29<nielsm>morning
03:35<Gabda>morning
03:37-!-WWacko1976-work [~IceChat9@ip-80-113-66-42.ip.prioritytelecom.net] has joined #openttd
03:37-!-WWacko1976-work is "YO!" on #openttd #/r/openttd
03:45<Gabda>nielsm: did you read my message yesterday about the IsCloseToTown function?
03:47<nielsm>yes
03:51<nielsm>not like it's actually use anywhere important :)
03:52<Gabda>only on town placing
03:53<Gabda>did you look for a function like this, or I misunderstood your queston?
03:53<nielsm>it is functions like that yes
03:55<Gabda>this kd tree will be really good :)
03:58<nielsm>I think viewport signs (town names, station names, player signs) wouldn't also be a good candidate
03:58<nielsm>those aren't map coordinates but view coordinate, that should work just as well
03:59<Gabda>so they would be a good candidates or wouldn't?
03:59<Gabda>-a
04:01<nielsm>they could make the UI more responsive on large games, perhaps :)
04:04<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
04:08<@peter1138>nielsm, every single bit of cargo produced scans the map looking for nearby stations, so that isn't right.
04:08<@peter1138>nielsm, however! That isn't the case with the non-rect PR, so don't spend time on that :)
04:09<nielsm>yeah I looked a bit at it and saw it would be troublesome to attempt improving with just a kdtree
04:09<nielsm>because of station spread settings that can change over time
04:10<nielsm>right now looking at UpdateTownRating, and I can't seem to find anywhere storing the town zone radii non-squared
04:12<Eddi|zuHause>why do you need the nonsquared radius?
04:12<nielsm>I want the rectangle encosing the circle
04:12<Eddi|zuHause>is that ever used anywhere else in the game?
04:12<nielsm>to look just stations inside that rect as candidates for the circular test
04:12<nielsm>I think not...
04:16<Eddi|zuHause>anyway, the town pool not a good enough storage?
04:17<nielsm>I'm experimenting with using a spatial tree to look up towns and stations near a tile/tile area
04:17<nielsm>possibly improving performance
04:17<Gabda>is there a maximum possible with for town/station names, and sign texts?
04:18<_dp_>nielsm, have you actually profiled the game to find slow places or are you just picking up random ones?
04:18<Gabda>if we don't cosider zoom, font and font size
04:18<nielsm>_dp_ I'm just doing everything! :)
04:18<nielsm>literally searching for FOR_ALL_STATIONS and FOR_ALL_TOWNS and seeing if they are a spatial lookup
04:19-!-Westie [~oftc@176.31.53.128] has quit [Quit: ZNC - http://znc.in]
04:19-!-kiwitree [uid223914@id-223914.tooting.irccloud.com] has joined #openttd
04:19-!-kiwitree is "kiwitree" on #openttd.dev #openttd
04:19<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
04:19<_dp_>k-d tree is good but aimlessly putting it everywhere can easily make things slower
04:20<_dp_>nielsm, yeah, FOR_ALL_ loops are good candidates for replacement
04:20<_dp_>but things like tile scan probably aren't
04:21<_dp_>at least I'd try to optimize tile scan first if it seems slow
04:21<_dp_>btw, it would be nice to have some collection of savegames and a way to automatically benchmark a change on all of them
04:21<Eddi|zuHause>nielsm: i think for this you should use a more crude upper bound than "current radius non-squared" of each town.
04:21<Gabda>by tile scan you mean tiles in a rectangle, or just a set if tiles?
04:22<Gabda>*of
04:22<_dp_>Gabda, yeah, in rectangle, don't think random scan is used anywhere in the game
04:23<nielsm>okay, looks like squared_town_zone_radius is not calculated as a number squared, but directly...
04:23<nielsm>so I'd actually have to take the root of that
04:23<nielsm>ugh
04:23<Eddi|zuHause>we have the "-v null:ticks=1000" thing, can that output the times at the end?
04:24<Eddi|zuHause>nielsm: integer root doesn't sound like a trivial thing
04:24-!-Westie [~oftc@176.31.53.128] has joined #openttd
04:24-!-Westie is "oftc" on #openttd
04:24<nielsm>yeah this sucks :(
04:25<nielsm>let's go with a worse estimate and just take the squared radius divided by 2
04:26<_dp_>nielsm, does your k-d tree use manhattan? you'll need more than just root then as it's longer on diagonals
04:26<nielsm>it should still be fewer towns visited
04:26<nielsm>it uses manhattan, and I'm using it to search orthogonal tile areas
04:27<nielsm>https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:kdtree
04:27<_dp_>aren't there a function for integer root already
04:28<_dp_>btw, it seems you need sqrt(2r) for manhattan radius if I did the math right
04:28<Eddi|zuHause>https://en.wikipedia.org/wiki/Integer_square_root
04:28<Eddi|zuHause>but we might need one that rounds up
04:29<_dp_>Eddi|zuHause, IntSqrt() + 1 ;)
04:29<Eddi|zuHause>_dp_: not quite the same :p
04:30<_dp_>Eddi|zuHause, good enough :p
04:30<Eddi|zuHause>nielsm: you could make a lookup table for the first 20 or so values
04:32<_dp_>Eddi|zuHause, just storing an already squared value in town would probably be faster
04:33<Eddi|zuHause>_dp_: what? the problem posed was that we currently only have the squared values available.
04:34<_dp_>Eddi|zuHause, oh, I meant already square-rooted
04:35<_dp_>Eddi|zuHause, or mb I should call them non-squared but they are calculated directly as squared so...
04:36<nielsm>pushed some more code to the above branch, of course untested (it compiles!)
04:53<Eddi|zuHause>turns out we really already have IntSqrt(uint) in math_func.cpp
04:58<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
04:59<@peter1138>Wrong issue :p
04:59<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself https://git.io/fhdli
05:00<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7245: Remove: OPF https://git.io/fhdlP
05:03<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
05:07-!-WWacko1976-work [~IceChat9@ip-80-113-66-42.ip.prioritytelecom.net] has quit []
05:08<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on issue #7247: With lots of vehicles, PerformanceAccumulator has a large performance impact itself https://git.io/fhdl7
05:21<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
05: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
05:26<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
05:31<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhd8E
05:32-!-andythenorth [~andytheno@89.105.111.75] has joined #openttd
05:32-!-andythenorth is "andythenorth" on #openttd
05:32<@peter1138>andythenorth is here.
05:33<andythenorth>yo
05:33<nielsm>this is troublesome, when I ffwd ottd I get electrical noise in my speakers
05:34<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhd8g
05:36<andythenorth>remove original land generator next? o_O
05:37<Eddi|zuHause>andythenorth: only if you also rewrite TGP
05:37<andythenorth>river-native TGP
05:37<nielsm>release post title, "OpenTTD 1.9.0: The Revolution"
05:37<andythenorth>we let the water carve the landscape
05:38<Eddi|zuHause>nielsm: NoOpenTTD?
05:38<andythenorth>so do rivers shape the land, or does the land shape where rivers go? o_O
05:38<andythenorth>NotOpenTTD
05:38<nielsm>OpenNoTTD
05:38<Eddi|zuHause>NotOpenNoTTD
05:41<andythenorth>hmm
05:45<DorpsGek_II>[OpenTTD/website] Eddi-z updated pull request #58: Monthly Dev Post of March 2019 https://git.io/fh5n2
05:51-!-Thedarkb1-T60 [~Thedarkb-@86-40-230-189-dynamic.agg3.kny.prp-wtd.eircom.net] has quit [Read error: Connection reset by peer]
05:51<Eddi|zuHause>andythenorth: the problem is, both, and you need to simulate a few million years of plate tectonics in a few seconds :)
05:52<andythenorth>if only the map had a variety distribution :P
05:54<nielsm>should really fix GetClosestDeletedStation again
05:56*andythenorth still wondering whether to split Pig Iron or not :P
05:56<andythenorth>http://bundles.openttdcoop.org/firs/push/LATEST/docs/html/cargos.html#pig_iron
05:56<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhd4Y
05:57<andythenorth>the Foundry casts engine blocks etc, which uses cast iron (grey iron) rather than pig iron
05:57<andythenorth>and in all my test games I never ship pig iron to the foundry, it all goes into steel chain
05:58<andythenorth>now that the 2-cargo-out restriction is removed, this can be adjusted :P
05:58<andythenorth>eh there's no cargo flag for 'this cargo is molten'
06:01<andythenorth>oof
06:01<andythenorth>renaming cargos upsets people in forums though :(
06:01<_dp_>inserting few values into a sorted list is better done with just insertion as in insertion sort
06:01<_dp_>I think some sort implementations even use insertion sort for a small arrays
06:02<andythenorth>and I used IRON cargo label for Pig Iron :(
06:02*andythenorth wonders if a complete spec would help for FIRS
06:02<andythenorth>*all* of everything worked out in advance
06:02<_dp_>I mean binsearch + memmove type insertion btw
06:02<andythenorth>including all planned and future changes in OpenTTD
06:03<andythenorth>with scheduled release dates
06:04<nielsm>https://0x0.st/ziQV.png what did I do??
06:05<nielsm>(spoiler: nothing strange, the real station sign is hidden behind the gray one)
06:07<@peter1138>_dp_, yes, I was considering adding that instead.
06:07<@peter1138>We already do MemMove when removing items, should be too much bother to do the same when adding.
06:09<_dp_>peter1138, though keep in mind you need bacwards memmove for insertion
06:12<andythenorth>it's nice that we have a FROG cargo now :)
06:12<andythenorth>https://newgrf-specs.tt-wiki.net/wiki/CargoTypes#Cargo_Labels
06:12<nielsm>conceptual at least?
06:14<nielsm>everyone likes making jokes with cargo labels :P
06:15<nielsm>BOOM, CHSE, JAVA
06:19<andythenorth>T800 is Terminator
06:19<andythenorth>and we have Kill Bill cargo also
06:19<andythenorth>KBLL
06:20<nielsm>I wonder if I should just make a PR of my kdtree now?
06:20<nielsm>it seems to work :P
06:21-!-Samu [~Ricardo@pa4-84-91-142-34.netvisao.pt] has joined #openttd
06:21-!-Samu is "realname" on #openttd
06:21<nielsm>should make a release build and one of the master I based it on, and compare perf
06:22*andythenorth should figure out what's left to do on 16-cargo industry nml :P
06:22<andythenorth>and then get a clean merge into nml master
06:23<andythenorth>:)
06:24<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
06:24<nielsm>at least it seems to produce functioning GRF for the new callbacks
06:24<nielsm>and new props
06:25<andythenorth>I suspect the main issue is just having clean commits
06:25<andythenorth>and updating the docs :P
06:25<@peter1138>Didn't we do the clean commits? Or was it just a rebase?
06:26<andythenorth>you rebased
06:26<andythenorth>and cleaned a few
06:26<@peter1138>Ah, okay.
06:26<@peter1138>Yes, you had a merge IIRC.
06:26<andythenorth>what makes logical atomic commits, dunno
06:26<@peter1138>Yeah, about that.
06:26<andythenorth>I'd like to be sure it's actually working before worrying about the history :D
06:26<@peter1138>My non-rect-catchment branch is starting to suffer there.
06:26<@peter1138>As I changed implementation details mid way.
06:26<andythenorth>things that touch everything are hard to make atomic
06:27<@peter1138>I'm wondering if my BitmapTileArea could be useful elsewhere.
06:27<andythenorth>this is why we need long-run branches sometimes :P
06:27<andythenorth>maybe with the builds
06:27<andythenorth>then things can brew for a bit
06:28<@peter1138>Peter1138sPatchPack?
06:28<@peter1138>With variants, multi-stop docks and unicorns.
06:28<andythenorth>you need a recursive bacronym
06:28<andythenorth>but yeah
06:28<andythenorth>I have been playing NRT + a few other things
06:28<andythenorth>but I'm not shipping a PP :P
06:28<andythenorth>hmm, time to go
06:28<@peter1138>Other than the conceptual issue of splitting road and tram types, it seems to work okay.
06:29<andythenorth>seems to work fine
06:29<andythenorth>BBL
06:29-!-andythenorth [~andytheno@89.105.111.75] has quit [Quit: andythenorth]
06:29<@peter1138>But solving that is a rewrite, and means dumping all the existing NewGRFs, so not going to happen.
06:29<@peter1138>Bye.
06:30<nielsm>https://0x0.st/ziQg.jpg
06:30<crem2>Rewrite is usually the most fun.
06:31<nielsm>barely any difference :)
06:31<Eddi|zuHause>jpg?
06:31<crem2>Why is it two pictures side by side? Is it a version for 3D glasses?
06:31<Eddi|zuHause>crem2: "we put 12 errors in this picture, can you spot them?"
06:32<nielsm>crem2: notice the title bar at the top
06:32<nielsm>it's two different branches
06:32<nielsm>left is master, right is my experimental kdtree branch
06:32<nielsm>which might or might not improve performance
06:33<nielsm>Eddi|zuHause: jpg because that's what sharex decided on, can't bother to tune it :P
06:35<nielsm>https://0x0.st/ziQE.png <- the spike is smaller in kdtree!
06:35-!-Thedarkb-X40 [~beno@86-40-230-189-dynamic.agg3.kny.prp-wtd.eircom.net] has quit [Ping timeout: 480 seconds]
06:36<nielsm>I should let it run for a while to look for desyncs
06:39-!-Samu [~Ricardo@pa4-84-91-142-34.netvisao.pt] has quit [Read error: Connection reset by peer]
06:42<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh opened pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhd4b
06:44<nielsm>hm the kdtree branch seems to be falling behind... it might just be a bit slower overall :(
06:45<_dp_>nielsm, try it with zoning patch to feel the difference xD
06:49<nielsm>hmm I should factor out ForStationsNearTile(TileIndex tile, int threshold, Func callback)
06:50<nielsm>and derive ForStationsNearTown from that
06:50<Gabda>nielsm: typo in use kdtree:remove for towns commit msg, one less :
06:51<nielsm>oops :P
06:51<Gabda>(I did not want to make a review comment just on this :) )
06:51<nielsm>well it'll probably get squashed at some point
06:51<nielsm>right now it's just a dev diary commit log
06:52<Eddi|zuHause>i probably shouldn't try to play astroneer again before they fixed the entering-vehicle-bug
06:52<Gabda>that was going to be my next question, if you plan to squash the fixes later
06:52<nielsm>hmm regressions fail, interesting
06:54<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdBs
06:54-!-sim-al2 [~sim-al2@c-75-65-196-171.hsd1.tn.comcast.net] has joined #openttd
06:54-!-sim-al2 is "sim-al2" on #openttd
06:58-!-Flygon [~Flygon@114-198-109-17.dyn.iinet.net.au] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
07:15-!-Progman [~progman@p4FD6671F.dip0.t-ipconnect.de] has joined #openttd
07:15-!-Progman is "Peter Henschel" on #openttdcoop.dev #openttd
07:20<nielsm>I don't understand how this has broken ScriptVehicleList_Station
07:36-!-Samu [~Ricardo@pa4-84-91-142-34.netvisao.pt] has joined #openttd
07:36-!-Samu is "realname" on #openttd
07:37<Samu>hi
07:52<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?
07:52-!-Thedarkb-T60 [~Thedarkb-@86-40-230-189-dynamic.agg3.kny.prp-wtd.eircom.net] has joined #openttd
07:52-!-Thedarkb-T60 is "realname" on #openttd #oolite
08:00<Gabda>are they considered to visit another station instead?
08:01<nielsm>I'm not sure
08:05<nielsm>but the GetClosestTown() ListDump result is correct at least
08:15<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
08:22<nielsm>InsertConditionalOrder and ditto append don't seem to actually have a way of specifying the jump condition?
08:25<Samu>i think it is cleared
08:25<Samu>the UnshareOrders question
08:25<nielsm>if you know the answer, a quick PR to fix it would be good :)
08:29<nielsm>well at least I can inspect this now https://0x0.st/zi1c.png
08:32-!-octernion [~octernion@toroon015yw-lp130-04-70-31-5-220.dsl.bell.ca] has joined #openttd
08:32-!-octernion is "octernion" on #openttd
08:35<nielsm>okay it's probably a difference in station numbering somehow
08:38<nielsm>yeah, it is
08:38-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
08:38-!-snail_UES_ is "Jacopo Coletto" on #openttd
08:49<nielsm>why are station signs missing in this regression run...
08:49<nielsm>well only of the AI player
08:51<Samu>sorry, was having lunch. I don't know if that's the intention
08:51-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
08:51-!-andythenorth is "andythenorth" on #openttd
08:52<Samu>unsharing orders, clears the orders list
08:52<nielsm>it doesn't matter what the intention is
08:52<nielsm>document what actually happens
08:52<nielsm>right now there is no intention because there is no documentation
08:53<Samu>Don't know how other AIs use that function
08:53<Samu>what they expect
08:53<nielsm>if any AI uses it and expects that orders become a copy, well that AI is buggy
08:53<nielsm>since that goes against the actual behaviour
08:54<nielsm>most likely everyone has just tested what happens (or read the code)
08:54<nielsm>but document it and it becomes correct behaviour by definition and anyone assuming otherwise were buggy all along
08:55<Samu>makes sense
09:00<Samu>I'm not great at english, but will try
09:01-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
09:07<Samu>* @note This also clears the orders list from the given vehicle.
09:08<Samu>good english?
09:08<nielsm>"After unsharing orders, the orders list of the vehicle is empty." and just part of the normal description text, not a note
09:09<nielsm>and I found the reason for the bug
09:09<nielsm>regression failure
09:10<Samu>what bug, sorry I wasn't paying attention
09:11<nielsm>regressions failing in my kdtree branch
09:11<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhd4b
09:15<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle. https://git.io/fhdED
09:16<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh approved pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle. https://git.io/fhdEy
09:19-!-sim-al2 [~sim-al2@c-75-65-196-171.hsd1.tn.comcast.net] has quit [Ping timeout: 480 seconds]
09:20-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has quit [Quit: andythenorth]
09:24<supermop_work>took me an hour to get to work on my two stop commute
09:25<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh merged pull request #7251: Doc: [AI] UnshareOrders empties the orders list of the vehicle. https://git.io/fhdED
09:26<supermop_work>what
09:26<supermop_work>i don't want stop sharing orders to work that way
09:26<nielsm>for AI's
09:26<nielsm>it's been working that way all the time
09:27<nielsm>when an AI does it
09:39<@peter1138>I suggest adding a parameter to decide if it should wipe or copy.
09:39<@peter1138>Then add the appropriate compat stuff.
09:40<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
09:44-!-octernion [~octernion@toroon015yw-lp130-04-70-31-5-220.dsl.bell.ca] has quit [Ping timeout: 480 seconds]
09:59<Samu>dont know what's kdtree supposed to do
09:59<Samu>too jargon for me
10:01<nielsm>faster lookup of stations and towns near some tile area
10:05<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
10:05<nielsm>not quite as big as the voronoi patch, but still pretty good
10:12<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdzR
10:14<Samu>looks like error-prone?
10:15<nielsm>it's tricky since it needs to update an index every time the indexed objects are added, removed, or change position
10:15<nielsm>so there is some risk of forgetting an update somewhere
10:35<Samu>what about the overused circular tile search?
10:36-!-andythenorth [~andytheno@81.171.232.172] has joined #openttd
10:36-!-andythenorth is "andythenorth" on #openttd
10:37<nielsm>whatever needs to be searched for needs to be indexed first, and creating the index can be expensive
10:38<nielsm>so it's only useful for things that don't move very much, and aren't created/removed all the time
10:38<nielsm>industries or industrytiles may also be a candidate but not sure
10:40<_dp_>wow, even master eats 2Gb with 60k stations
10:40<_dp_>I'm not opening that with non-rect patch :p
10:40<@peter1138>What savegame?
10:41<_dp_>peter1138, wait a sec, I'll make one with less stations
10:41<@peter1138>No, that's fine, I have 32GB RAM :p
10:42<_dp_>yeah but I don't and I still want to see the effect :p
10:42<_dp_>and not just dead pc kind of effect xD
10:45<@peter1138>I wonder how much extra memory non-rect uses now.
10:45<@peter1138>I've not been measuring that at all
10:47<Samu>an ai that uses many stations, buoys included?
10:47<Samu>shipai
10:47<Samu>nocab with ships
10:47<@peter1138>Buoys don't have catchment.
10:47<Samu>oh
10:47<@peter1138>Also the catchment memory is dynamic, so a 1x1 station uses less than 64x64.
10:47<Samu>maybe admiralai with buses
10:48<Samu>my ai doesn't mass much stations
10:48<Samu>brb let me look at my tests
10:49<@peter1138>A 1x1 bus stop should use 7 bytes for the bitmap data, and 8+4+4+4 for the metadata about the bitmap.
10:49<@peter1138>Hmm, I could make that 8+4+2+2 thinking about it.
10:49<@peter1138>16 bytes would be neater than 20 bytes.
10:49<@peter1138>Actually!
10:49<@peter1138>It already yes.
10:50<@peter1138>Oh, another 16 bytes to store capacity and count of the data.
10:50<@peter1138>size_t :/
10:51<@peter1138>The bitmap data would be around 800 bytes for the largest station size
10:52<_dp_>surprisingly non-rect doesn't use more memory... I must be doing smth wrong xD
10:53<Samu>Nonocab
10:53<_dp_>guess 1x1 stations are big part of it
10:53<Samu>simleai
10:53<Samu>simpleai
10:53<Samu>admiralai
10:53<Samu>but they don't reach any close to 64k stations
10:53<Samu>about 2.7k
10:53<@peter1138>Hmm, yes, wentbourne is faster on my i5 @ 3.3 GHz than my i7 @ 4.5 GHz
10:53<@peter1138>So hyperv is quite a performance hit.
10:53<Samu>what is this wentbourne i keep hearing
10:54<@peter1138>A CPU heavy savegame.
10:54<Samu>oh where is i
10:54<Samu>t
10:54<@peter1138>I linked to it in my issue about frame rate performance performance.
10:55<@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
10:55<@peter1138>Well that's interesting.
10:57<Samu>fuzzle.org does not respond
10:57<Samu>ah, got it
10:58<_dp_>I wonder what uses so much memory in master, could it be std::list?
10:58-!-Wormnest [~Wormnest@35.136.176.177] has joined #openttd
10:58-!-Wormnest is "Wormnest" on #openttd
10:58<@peter1138>Probably the number of orders ;p
10:58<@peter1138>Should we add a memory profile window? ;)
10:58<_dp_>but I don't have any vehicles
10:59<@peter1138>It was a joke.
10:59<@peter1138>There's also the sprite cache.
10:59<Samu>wow that's slow :p
11:00<Samu>5 fps
11:01<@peter1138>Hmm, prozone 13 has some very large catchment areas.
11:01<Samu>how do you have over 5000 road vehicles
11:02<@peter1138>RVs is the performance killer in that save.
11:02<@peter1138>Constantly pathfinding.
11:02<@peter1138>I started to adapt the ship path cache to rvs last night, but it didn't quite work :-)
11:04<Samu>switched to NPF, duplicated ms
11:08<Samu>too many roads
11:08<Samu>why wouldn't cache work for road vehicles?
11:10<nielsm>they run on fixed tracks, not quite the same as open water
11:18<@peter1138>Samu, it does work, but I had a bug.
11:18<@peter1138>And it was 3am, so I went to bed.
11:19<@peter1138>It dropped ms/t for RVs from 60ms to 25ms.
11:19<@peter1138>And that was with it broken.
11:19<DorpsGek_II>[OpenTTD/OpenTTD] pi1985 updated pull request #7029: #6315 Rail fences in snow or desert https://git.io/fhZJq
11:22<nielsm>well, that was an attempt
11:22<nielsm>but it failed
11:22<nielsm>couldn't rebase onto master
11:25<@peter1138>Certainly a git history fail.
11:30-!-Gabda [~yaaic@254C3A2C.nat.pool.telekom.hu] has quit [Ping timeout: 480 seconds]
11:32-!-Gabda [~Gabda@catv-80-98-39-136.catv.broadband.hu] has joined #openttd
11:32-!-Gabda is "realname" on #openttd
11:35-!-glx [kvirc@000128ec.user.oftc.net] has joined #openttd
11:35-!-mode/#openttd [+v glx] by ChanServ
11:35-!-glx is "Loïc GUILLOUX" on +#openttd
11:37-!-sla_ro|master [~sla.ro@84.117.88.126] has joined #openttd
11:37-!-sla_ro|master is "slamaster" on #sla #openttd
11:38-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd
11:38-!-Gja is "Martin" on #ceph #bcache #openttd
11:41<@peter1138>Uhm... crash in squirrel? :S
11:42<Samu>you get 60 ms? i get 130 ms, trash cpu :|
11:43<@peter1138>Hmm, why would Realloc fail on 32 items?
11:43<@peter1138>32 bytes, in fact.
11:43<+glx>OOM ?
11:44<Samu>out of mana?
11:45<Samu>what the heck
11:45-!-kiwitree [uid223914@id-223914.tooting.irccloud.com] has quit []
11:48<@peter1138>Could be some AI regression with non-rect-catchment, I guess.
11:48<Samu>heh, you have lost ships in that savegame, because towns blocked passage
11:50<@peter1138>I've never played that game.
11:50<@peter1138>It's just a savegame I use for stress testing.
11:51<andythenorth>imagine the stress those ships are feeling
11:51<andythenorth>eh can we give vehicles an emotional quotient? o_O
11:52<andythenorth>'this vehicle is happy'
11:52<andythenorth>'this vehicle is sad'
11:52-!-Gja [~Martin@93-167-84-102-static.dk.customer.tdc.net] has quit []
11:52<andythenorth>'this vehicle has existential dread'
11:52<andythenorth>'this vehicle took uppers and is travelling at double the safe speed'
11:54<Samu>when will you do something about prevent town block pr?
11:54<@peter1138>When we feel like it.
11:54<Samu>ok
11:54<Samu>https://github.com/OpenTTD/OpenTTD/pull/6931
11:55<Samu>now
11:55<Samu>:P
11:55<@peter1138>No, when We feel like it, not when you feel like it.
11:56<@peter1138>Hmm, okay, so my insert algorithm is wrong.
11:56<andythenorth>it's a very uninteresting problem, that probably does need solved one day samu
11:56<@peter1138>I guess that is corrupting memory.
11:56<andythenorth>but 'one day' is probably not 'today' on any given day
11:58<andythenorth>so...errr....k-d tree for storing cargo payment rates that vary by map location? o_O
12:01<@peter1138>No?
12:06<andythenorth>figured
12:06<andythenorth>k-d tree for storing trees? o_O
12:06<andythenorth>pin a random tree seed to one in 16 tiles or something
12:06*andythenorth BS ideas
12:24<nielsm>so, we should really have a unit test framework too, not just the integration test that the current regressions are
12:25-!-Pikka [~Albert@193-116-87-247.tpgi.com.au] has quit [Quit: Leaving]
12:29-!-HerzogDeXtEr [~farci@dslb-188-103-131-188.188.103.pools.vodafone-ip.de] has joined #openttd
12:29-!-HerzogDeXtEr is "purple" on #openttd
12:34*andythenorth has wondered about that
12:34<andythenorth>unit tests are massive investment of time
12:34<andythenorth>but when they do start catching regressions, they're your best friend
12:50<Eddi|zuHause>unit tests are hard to put together afterwards
12:51<Eddi|zuHause>because you must first split the program into units that can be tested
12:51<nnyby>there are many standalone functions in openttd that could definitely be unit tested as is
12:51<nnyby>i've been meaning to try setting something up for that
12:52<nielsm>first unit testing question: reinvent the wheel or import a huge library for it?
12:53<andythenorth>unit tests have some kind of coverage-related negative approach initially
12:53<Eddi|zuHause>probably go with the library (the user shouldn't be bothered with this, right?)
12:53<nnyby>my first stab would be to use a testing library, ideally a small one instead of a huge one
12:53<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
12:54<andythenorth>there's a critical mass of tests needed before thye're productive
12:54<andythenorth>they're *
12:54<nnyby>if the functions you're testing are reasonably simple, you'll never get false positives
12:55-!-Sacro [~ben@000127ee.user.oftc.net] has quit [Server closed connection]
12:55-!-Sacro [~ben@ns364742.ip-94-23-0.eu] has joined #openttd
12:55-!-Sacro is "Ben Woodward" on #simsig #openttd
12:55<Eddi|zuHause>are the simple functions really worth testing, though?
12:58<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
13:00<nielsm>core/ parts, blitters, pathfinder cores, are some of the lower hanging fruit presumably
13:03<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
13:04<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
13:08<Gabda>today I've learned what is the difference between vector resize and reserve... and I've learned it the hard way.
13:08-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
13:08-!-Wolf01 is "Wolf01" on #openttd
13:09<Wolf01>o/
13:10-!-synchris [~synchris@139.138.202.72] has joined #openttd
13:10-!-synchris is "Synesios Christou" on #openttd
13:15-!-frosch123 [~frosch@00013ce7.user.oftc.net] has joined #openttd
13:15-!-frosch123 is "frosch" on +#openttd.dev #openttd
13:20<Samu>this TODO is false
13:20<Samu>it works
13:20<Samu>TODO: Have yet to verify if it's working correctly when dealing with ship depots and locks.
13:21<Wolf01>It's not false, you verified it works, remove it
13:23<frosch123>andythenorth: https://github.com/frosch123/firs <- i wanted to transfer that to your account, but gh said andy/firs already exists :p
13:39-!-gelignite [~gelignite@55d4eeb8.access.ecotel.net] has joined #openttd
13:39-!-gelignite is "gelignite" on #openttd
13:49-!-m3henry [~m3henry@host-212-139-212-35.static.as9105.net] has joined #openttd
13:49-!-m3henry is "realname" on #openttd
13:51<Samu>it's in a quote
13:52<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick commented on pull request #6931: Change: Prevent town growth from blocking ships https://git.io/fhdrQ
13:55<DorpsGek_II>[OpenTTD/OpenTTD] GabdaZM commented on pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fhdr5
13:57<DorpsGek_II>[OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5iB
13:59-!-andythenorth [~andytheno@81.171.232.172] has quit [Quit: andythenorth]
14:05<nielsm>Gabda: "*** b/src/town_cmd.cpp: No newline at end of file"
14:05<Gabda>right
14:06<Gabda>there will be one in the next push
14:10<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdoI
14:11<DorpsGek_II>[OpenTTD/OpenTTD] GabdaZM updated pull request #7242: Codechange: Improve performance of town name refresh on viewports https://git.io/fh5iB
14:17<DorpsGek_II>[OpenTTD/OpenTTD] GabdaZM commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdoG
14:19<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdoC
14:28*peter1138 returns from Nando's
14:34-!-HerzogDeXtEr [~farci@dslb-188-103-131-188.188.103.pools.vodafone-ip.de] has quit [Read error: Connection reset by peer]
14:38<@peter1138>Hmm, TileY(st->xy) = 8192. That seems wrong :/
14:40<Samu>4096, 8192
14:41<DorpsGek_II>[OpenTTD/OpenTTD] ldpl commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdod
14:42<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdop
14:44<DorpsGek_II>[OpenTTD/website] TrueBrain commented on issue #60: Can't select 1.8.0 as maximum openttd version https://git.io/fhdKe
14:44<DorpsGek_II>[OpenTTD/website] TrueBrain closed issue #60: Can't select 1.8.0 as maximum openttd version https://git.io/fh5y4
14:47<nielsm>TrueBrain: there is nowhere else to report bananas bugs, someone in here told him to report it there in lack of better
14:48<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
14:48<TrueBrain>when in doubt with bugs, I suggest we tell people to email info@
14:48<TrueBrain>a much wider audience reads that :)
14:48<TrueBrain>(and are easier forwarded to people who can deal with it, etc :D)
14:50<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*
14:51<TrueBrain>nielsm: in the bigger picture, BaNaNaS should be replaced :D But those things take time :)
14:51<@peter1138>Ah, this was dinner so we didn't mind.
14:51<@peter1138>It was a bit slow, but we had starters ;P
14:52<nielsm>hmm I should find a solution to not have kdtree.hpp included in town.h
14:53<TrueBrain>you really implemented another tree? :D Nice :D
14:53<TrueBrain>what does this one solve?
14:53<@peter1138>That's an issue with complex classes and C++ :(
14:54<nielsm>TrueBrain: spatial lookup, "find point nearest this one" and "all points inside rectangle"
14:55<TrueBrain>has been a while since OpenTTD has seen a new algorithm (mathematical one, I mean), not? :D
14:56<@planetmaker>g'evening
14:57<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhd4b
14:57<nielsm>this one requires quite a bit of care, as that latest commit shows :P
14:57<TrueBrain>the more complex the trees ..... :)
14:58<TrueBrain>we had many issues in the past too, so no worries :P That is normal :D
14:58<TrueBrain>lot of hardcoded "% 2"
14:58<TrueBrain>do I get it right it is forced in a space of 2 dimensions?
14:58<TrueBrain>(or am I misunderstnding this tree :D)
14:59-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has joined #openttd
14:59-!-andythenorth is "andythenorth" on #openttd
14:59<nielsm>yeah it assumes 2D
14:59<TrueBrain>possibly nice to make that at least a constant of some sort :)
14:59<nielsm>and homogenous dimensions
14:59<nielsm>it's not truly generic
15:00<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?
15:00<TrueBrain>(just curious btw :D I like how trees are used in games)
15:01<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdK8
15:01<nielsm>yep, every level of the tree splits in a different dimension in turn
15:02<andythenorth>yo TrueBrain
15:02<TrueBrain>nielsm: nifty
15:02<nielsm>it's like a BSP tree with implicit orientation of the splitting plane :)
15:02<TrueBrain>andythenorth: yo
15:03<TrueBrain>nielsm: also means it is fast in range checks, or only for specific leafs?
15:03<nielsm>TrueBrain, you mean checks like "are any points within X distance to given one?"
15:04<TrueBrain>nielsm: I mean, is there anything between X n .. y and Y w .. z
15:04<nielsm>that's one of the operations implemented yes
15:04<TrueBrain>cool :D
15:05<nielsm>I haven't benchmarked it, but it should be fast-ish
15:05<TrueBrain>this begs for UnitTests btw :P
15:05<TrueBrain>OpenTTD so needs that :D
15:05<nielsm>since it can discard any branch of the tree outside the rectangle
15:05<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
15:06<TrueBrain>even in worst cases
15:06<nielsm>I think this also has potential for selecting visible viewport objects
15:06<nielsm>(signs)
15:06<nielsm>the hard part is building and updating the index in the right places
15:07<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdK0
15:08<Gabda>the only problem with signs is the width of the sign
15:08<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)
15:08<Gabda>if you have a max width, you can add that to the search rectangle
15:08<Gabda>but is there a max width?
15:09<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdKE
15:09<nielsm>TrueBrain, even more iterating all stations!
15:09<TrueBrain>:D
15:09<TrueBrain>means the game .. scales :P
15:09*LordAro iterates TrueBrain
15:09<nielsm>maybe 4096^2 maps will become viable???
15:10<TrueBrain>NOOOOOO :P
15:10<LordAro>ha
15:10<TrueBrain>but yeah .. who to bribe to get UnitTests in OpenTTD? :)
15:10<TrueBrain>proving it is correct is nicer than hoping it is :D
15:10<nielsm>nnyby volunteered for unit tests earlier! :D
15:11<Gabda>I still hope that my voronoi diagram and the sign filter can survive
15:11<TrueBrain>isnt this complimentary to that?
15:11<Gabda>or maybe one of them :)
15:12<Gabda>yes
15:12<DorpsGek_II>[OpenTTD/OpenTTD] TrueBrain commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhdKa
15:14<TrueBrain>really interesting work nielsm :) Nice :)
15:16<nielsm>I hope the code is sufficiently clear too :)
15:16<nielsm>and the use of lambdas is acceptable :D
15:16<TrueBrain>it still makes me want to puke when I read it in C++ :P But that is just me :D
15:16<@peter1138>When does bananas get moved to github then?
15:17<TrueBrain>peter1138: never, I think
15:17<+glx>I prefer lambdas to templates :)
15:17<@peter1138>When do I replace my middle monitor?
15:17<TrueBrain>yesterday
15:17<TrueBrain>package arrives tomorrow
15:17<@peter1138>Ah, it's just come back to life.
15:18<Wolf01>Mmmh, novus is just a bit hostile
15:18<andythenorth>when do we do [x]
15:18<andythenorth>?
15:18<TrueBrain>before [y]
15:18<TrueBrain>how is beta3 going btw? Are we still on target for 1st of April?
15:19<nielsm>there haven't been a lot of talk about bugs, at least
15:19<nielsm>but do we know how many have downloaded beta2 ?
15:20<TrueBrain>hmm ... I can pull the nginx logs, and grep, I guess
15:20<LordAro>beta3 or RC1?
15:20-!-synchris [~synchris@139.138.202.72] has quit [Quit: yeeha!]
15:20<TrueBrain>if there are no bug reports, RC1 ofc
15:20<TrueBrain>(and all the functionality is in)
15:21<TrueBrain>5 open for 1.9 ..
15:21<nielsm>https://github.com/OpenTTD/OpenTTD/milestone/1
15:21<nielsm>yea
15:21<LordAro>i suspect 6922 will slip
15:22<TrueBrain>okay, downloading all the logs will take a bit of time :D File by file is a bit slooowwwwwwwwww
15:22-!-sla_ro|master [~sla.ro@84.117.88.126] has quit []
15:22<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on issue #7189: fluidsynth driver plays music too loudly https://git.io/fhdKX
15:31<TrueBrain>okay, taking guesses how often beta2 is downloaded .. it is out a week now
15:31<TrueBrain>and it is a beta
15:31<TrueBrain>keep that in mind
15:31<TrueBrain>GO
15:31<andythenorth>3500
15:32<TrueBrain>3200 ... impressive andythenorth :D
15:32<TrueBrain> 158 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-macosx.dmg
15:32<TrueBrain> 178 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-windows-win32.exe
15:32<TrueBrain> 678 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-windows-win64.zip
15:32<TrueBrain> 1945 /openttd-releases/1.9.0-beta2/openttd-1.9.0-beta2-windows-win64.exe
15:32*andythenorth sees newgrf downloads a lot, took a guess
15:32<TrueBrain>3 times more dmg downloads than zip, for OSX
15:32<andythenorth>only wrong people would get the zip
15:33<TrueBrain>we have had worse RCs, I can tell you :)
15:33<andythenorth>zip is basically user error :P
15:33<TrueBrain>we can remove the zip :)
15:33<TrueBrain>if it is not useful
15:34<@peter1138>What is it for?
15:34<@peter1138>Oh, for people who don't want to install.
15:34<@peter1138>Call it the "portable" edition, I guess?
15:36<andythenorth>on the mac, it's for people who don't know what a dmg is
15:36<andythenorth>so, people who only use app store
15:37<andythenorth>also I think we have about 10k active players, based on newgrfs
15:37<andythenorth>so 3200 beta downloads is a lot
15:37<TrueBrain>it is
15:38<@peter1138>Right, I think that's one bug fixed... just running this savegame for a while.
15:39<@peter1138>_dp_, so why does OpenTTD gobble lots of memory for you?
15:40<frosch123>andythenorth: i remembered why we are not moving stuff away from devzone yet. eints :p
15:41<_dp_>peter1138, dunno, I suspected std::list but that's not it
15:42<_dp_>peter1138, how much memory does it take when you open that save?
15:42<_dp_>it's 1.6GB for me
15:43<@peter1138>Which save, Wentbourne?
15:43<_dp_>peter1138, no, the one I posted
15:44<_dp_>it uses smth crazy like 30kb per station
15:44<@peter1138>O...
15:44<@peter1138>Waiting for it to load.
15:44<@peter1138>debug-level 3, and some debug printfs...
15:45<@peter1138>Yeah, 1.7GB
15:45<_dp_>well, at least that's not a g++ fault I guess
15:46<@peter1138>Ooh, it crashed.
15:46<@peter1138>Hmm
15:46<@peter1138>And I wasn't in the debugger :(
15:47<frosch123>core dumps!
15:48<@peter1138>Oh, I unpaused and it build more stations...
15:48<_dp_>peter1138, build? are you sure those aren't just signs jumping around?
15:49<_dp_>coz they do xD
15:49<@peter1138>Uhrm
15:49<_dp_>some stations are on water and get flooded xD
15:50<nielsm>it makes my kdtree branch crash too, so will have to debug that as well
15:50<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.
15:51<_dp_>xD
15:51<nielsm>Gabda nice, thanks
15:51<nielsm>takes a little while to load..
15:52<@peter1138>Yeah, in my effort to give it less work to do, I don't check st->rect enough.
15:52<@peter1138>I could perhaps make BitmapTileIterator handle an invalid catchment_tiles more gracefully.
15:52<@peter1138>But I think that would just hide other bugs.
15:52<nielsm>hmm, it's spending a LOT of time with text layout code herre
15:53-!-Gabda [~Gabda@catv-80-98-39-136.catv.broadband.hu] has quit [Quit: Leaving]
15:53<_dp_>btw, does it cache sprites for station signs?
15:54<@peter1138>Station signs are text.
15:54<andythenorth>frosch123: yes I was aware of eints problem :)
15:54<nielsm>and now it's taking its time in RecomputeIndustriesNear
15:55<andythenorth>but I'm about to start FIRS v4, and FIRS v3 has just had a translations release
15:55<_dp_>peter1138, well, yeah, but you can either render text each time or cache the bitmap
15:55<andythenorth>FIRS major releases take at least a year I guess
15:55<nielsm>maybe I should make a kdtree for industries as well
15:55<_dp_>I've no idea what openttd actually does there
15:55<@peter1138>Ah, no, it renders.
15:55<@peter1138>Well, "renders"
15:55<@peter1138>Each glyph is already a bitmap.
15:55<frosch123>andythenorth: anyway, you need to delete andy/firs, so i can transfer ownership of frosch/firs
15:55<andythenorth>yup
15:56<_dp_>peter1138, ehm, don't think that would work for a freetype
15:56<@peter1138>You say that, but that is exactly how it works.
15:56<andythenorth>frosch123: it's gone :)
15:57<nielsm>ugh, it's taken a full minute for the first 12k stations
15:58<@peter1138>Damn, I didn't note the date when it crashed last time.
15:58<@peter1138>So we need to reduce the station limit? :D
15:59<nielsm>eh optimise these CircularTileSearches away a bit?
15:59<nielsm>and don't layout as many station signs?
15:59<nielsm>(at a time)
15:59<@peter1138>Are you in non-rect-catchment?
15:59<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on issue #7159: Reverse at signal timeouts occur unexpectedly quickly, affects title game https://git.io/fhd63
15:59<nielsm>nah kdtree
15:59<@peter1138>Ok.
15:59<@peter1138>Then it may already be gone :p
16:00<_dp_>peter1138, I just remember there being some tricky stuff like rendering chars differently in different combinations
16:00<_dp_>peter1138, but I guess freetype is a smart library, it can cache those as well
16:01<nielsm>peter1138, did you update RecomputeIndustriesNear ?
16:01<nielsm>(it looks like it does depend on catchment area so probably yes)
16:01<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on issue #7159: Reverse at signal timeouts occur unexpectedly quickly, affects title game https://git.io/fhd6n
16:02<@peter1138>nielsm, yes, that's pretty core to my changes.
16:02<@peter1138>Okay, 8th Apr 2050.
16:02<@peter1138>I think that's after the crash.
16:02<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
16:02<frosch123>andythenorth: well, you need to accept it :)
16:03<_dp_>well, station limit is fine for master except for memory issue but that's separate
16:03<frosch123>i wonder whether there is an api limit on how many repos you can dump on others
16:05<nielsm>uh wth https://0x0.st/zi24.png
16:05<nielsm>the node_idx is valid, the debugger can look up the item in the nodes vector, but the value for n is invalid
16:05<nielsm>that should not happen?
16:05<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
16:06<+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.
16:06<+michi_cc>s/Unicows/Uniscribe/ Unicows does exists, but is something else :p
16:07<nielsm>ahh, no, I know what happened
16:07<nielsm>the vector was reallocated, of course
16:07<@peter1138>Oh, so this savegame still takes ages to load without my patch.
16:08<_dp_>peter1138, don't worry too much it takes a while even in master xD
16:08<@peter1138>Hmm, performance with non-rect seems better.
16:09<_dp_>nvm, I misread that
16:09<@peter1138>1.7x game speed vs 2.1x
16:09<@peter1138>Also there are times when master pauses .
16:09<@peter1138>Ah, so did mine, just luck I guess.
16:10<@peter1138>Weird savegame. Performance is very variable.
16:11<andythenorth>wow I had to use email to accept a repo :)
16:11<andythenorth>how retro
16:11<andythenorth>https://github.com/andythenorth/firs
16:12<@peter1138>Now I need to find out why my sorted-insert doesn't work.
16:12<andythenorth>frosch123: thanks \o/
16:12<frosch123>he, you had to confirm via email? i was suprised i did not have to confirm it at all
16:12<frosch123>i expected a "repeat password" or so
16:12<andythenorth>first thing is to find the hg scripts for version etc and migrate I guess
16:13<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
16:13<_dp_>peter1138, is it on github?
16:13<frosch123>andythenorth: do we need to remove it from eints? i guess so..
16:14<frosch123>or do you want to pull translation changes from hg or something?
16:16<@peter1138>No.
16:16<andythenorth>frosch123: not sure what's best, but incoming translations aren't useful when doing a major version
16:16<andythenorth>there's a lot of churn
16:17<andythenorth>but eh, I can work in a branch now anyway :)
16:17<andythenorth>remove from eints, and lock the devzone repo I think
16:18<@peter1138>*** Error in `bin/openttd': malloc(): memory corruption (fast): 0x00000000087b0120 ***
16:18<@peter1138>:-)
16:18<@peter1138>This list cotains 29, 29, 32, 33, 34
16:18<@peter1138>Considering it's meant to be unique...
16:18<_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)
16:18<+glx>each 29 is unique :)
16:19<@peter1138>Writing crash savegame...
16:19<@peter1138>It hangs here :-)
16:19<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
16:19<nielsm>but looks like I did fix that crash
16:20<@peter1138>nielsm, yeah, I really did rework all that stuff.
16:20<andythenorth>frosch123: is it known how to remove FIRS from eints?
16:20<@peter1138>I think at this point you'd be giving me needless conflicts, or vice-versa.
16:20<andythenorth>I can remove the user
16:21<nielsm>I'm also running a debug build here, it's rather much faster in release :P
16:21<frosch123>andythenorth: removing the user blocks eints from committing
16:21<frosch123>i can delete the eints project manually
16:21<+glx>but release is so slow to build ;)
16:21<frosch123>but we can also keep it running an make prs from it
16:21<frosch123>every now and then
16:21<andythenorth>ok
16:21<andythenorth>not sure how to mark the devzone repo as deprecated
16:22<andythenorth>I can put a message on devzone project page
16:22<frosch123>put it into the description
16:22<nielsm>glx exactly!
16:22*andythenorth will miss devzone
16:22<andythenorth>I prefer redmine to github in many places
16:22<frosch123>not sure whether we did anything for nml and eitns
16:22<@peter1138>Is it slow to build? I don't notice much difference.
16:22<@peter1138>Oh, it is with MSVC.
16:22<andythenorth>but I won't miss devzone crashes :P
16:22<@peter1138>I'm thinking about getting another SSD and having a native Linux install, like I used to use.
16:22<@peter1138>Hmm, or I could just remove Steam games I never play (most of them)
16:23<nielsm>the release build slowness with msvc is mainly due to the LTCG
16:23<andythenorth>there's never any downside to getting another SSD
16:23<nielsm>link takes forever since that's where it actually generates most of the machine code
16:24-!-gelignite [~gelignite@55d4eeb8.access.ecotel.net] has quit [Quit: Good fight, good night!]
16:24<@peter1138>When you add a printf and it no longer crashes :S
16:24<nielsm>heisenbugs!
16:26<@peter1138>Oh, wrong save.
16:27<@peter1138>Okay, so it was meant to instead station 18 before 39.
16:27<@peter1138>But didn't... 39, 39, 40, 41, 43...
16:28<+glx>at least it inserted an element
16:28<@peter1138>I notice the numbers are different, but then again, if it's put the 18 somewhere different...
16:28<_dp_>peter1138, can you just paste a code somewhere?
16:29<_dp_>i got curious xD
16:29<@peter1138>I found it.
16:29<andythenorth>ok so this needs ported for git eh https://github.com/andythenorth/firs/blob/master/bin/hg-info
16:29<@peter1138>I was using SmallVector::Insert incorrectly.
16:30<@peter1138>Yeah, it only failed if it realloced.
16:30<nielsm>reallocations, yeah!
16:30<nielsm>best and worst part about dynamic arrays
16:31<_dp_>you're just using too much pointers :p
16:31<@peter1138>I did think about switching to station IDs
16:32<@peter1138>Just a dereference away.
16:32<@peter1138>Well, 2.
16:32<@peter1138>Yeah, that's fixed it :D
16:32<@peter1138>Now I can improve performance by removing my printfs.
16:33<_dp_>wait, does station pool reallocate as well?
16:33<+glx>if needed yes
16:34-!-frosch123 [~frosch@00013ce7.user.oftc.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:34<+glx>I think
16:34<@peter1138>The pool itself will reallocate, the items within the pool do not.
16:34<@peter1138>Because it's not actually pool.
16:35<@peter1138>The "pool" is just an array of pointers.
16:35<@peter1138>Hmm...
16:35<@peter1138>Actually I lie.
16:35<@peter1138>Maybe each item is allocated from a block which is never moved.
16:36<@peter1138> item = (Titem *)MallocT<byte>(size);
16:36<@peter1138>Suspicious.
16:37<nielsm>yes that's the idea behind the pools
16:37<@peter1138>Which?
16:37<nielsm>it's basically an arena for each of the main game object types
16:37<@peter1138>It's somewhat terrible as it uses macros :(
16:38<nielsm>it definitely violates some C++ standard things and/or depends on UD
16:38<nielsm>can't remember the specifics but it has to do with POD types
16:38<nielsm>(which most things are not)
16:38<@peter1138> inline void *operator new(size_t size)
16:38<@peter1138>Hmm.
16:39<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
16:39<@peter1138>So I'm not sure if it's allocating in big chunks and then sharing that out, or allocating individually.
16:40*nielsm is staring at another crash
16:40<nielsm>this one I can't explain
16:41<nielsm>access violation getting the tile coordinate of a station, lookup by stationid
16:41<nielsm>and it reaches page 0 so somehow a nullptr has snuck in?
16:42<@peter1138>GetIfValid()
16:42<_dp_>this->data = ReallocT(this->data, new_size);
16:42<nielsm>inline uint16 Kdtree_StationXYFunc(TownID tid, int dim) { return (dim == 0) ? TileX(BaseStation::Get(tid)->xy) : TileY(BaseStation::Get(tid)->xy); }
16:42<_dp_>that looks like a pointer change to me
16:42<nielsm>it's that function
16:42<nielsm>used during sorting
16:42<@peter1138>_dp_, of the pool of pointers, not the items within.
16:43<@peter1138>nielsm, is a TownID a Station?
16:43<+glx>items are allocated individually it seems
16:43<nielsm>uh StationID
16:44<nielsm>it's supposed to be
16:44<@peter1138>So is your stationid valid?
16:44<nielsm>both resolve to uint16 though
16:44<@peter1138>Yeah
16:44<@peter1138>If the station was removed, then...
16:44<nielsm>I'm probably not housekeeping station removals correctly in the tree
16:45<_dp_>oh, it stores pointers.. I read this->data[index]; three times and still got it wrong)
16:45<@peter1138>Hmm, should I try benchmarking sorted insert vs append + qsort?
16:46*peter1138 loads gr0_50k again
16:48<@peter1138>Hmm, something causes freezes.
16:48<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhd4b
16:48<Eddi|zuHause>hope it's not arnold
16:48<+glx>autosave ?
16:48<nielsm>peter1138, try disabling industry creation
16:48<@peter1138>Nope, not autosave.
16:48<nielsm>i.e. set industries density to "manual funding only"
16:49<@peter1138>Ok.
16:49<m3henry>peter1138: insertion is O(n), qsort is O(n log n) IIRC
16:49<nielsm>if that solves it, it's the recomputing of industries near all stations that's to blame
16:49<Eddi|zuHause>m3henry: we're talking about special case where the list is almost sorted
16:50<m3henry>I heard
16:50<@peter1138>Remind me what n vs n log n means?
16:50<@peter1138>nielsm, yeah that helps.
16:50<Eddi|zuHause>peter1138: n is better than nlogn :)
16:50<m3henry>^
16:50<@peter1138>Ok.
16:50<_dp_>Eddi|zuHause, qsort is still n log n even on sorted
16:51<@peter1138>I'll remove my QSort stuff.
16:51<m3henry>TBH I would use a container adapter
16:51<nielsm>for inserting a single element in a sorted list, a search+insertion is better
16:51<@peter1138>Calling the sorter function every time would add to its cost.
16:51<Eddi|zuHause>_dp_: it's been a long time since i looked at the pathological cases of various sorting algorithms
16:52<@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.
16:52<nielsm>even something as simple as appending and then repeatedly swapping the new element down until it's in position would work
16:52<nielsm>but a memmove likely has better constants
16:52<Eddi|zuHause>heapsort is fun
16:52<@peter1138>nielsm, turns out SmallVector already has an Insert() which I use. Properly this time. Sorry m3henry .
16:52<Eddi|zuHause>that's about what i remember :)
16:53<m3henry>Insert is the next method on the chopping block
16:53<m3henry>I just finished Append
16:53<@peter1138>Oh, and most of the time these lists are in the order of 3 or 4 items :p
16:53<@peter1138>It just happens a lot.
16:53<m3henry>llvm::SmallVector would be agood fit for that
16:54<nielsm>for really small vectors, I think append-and-swap-down might have the best performance, but just guessing here
16:54<nielsm>:P
16:54<m3henry>Should be same as insertion
16:54<nielsm>anyway, I should head to bed, work tomorrow (for real this time)
16:55<nielsm>m3henry, memmove based insertion might benefit from block operations in a way repeated swapping can't
16:55<nielsm>gn
16:55<Eddi|zuHause>with swapping you're skipping the binsearch, but the swapping operations are slower than memmove, probably
16:55<m3henry>True, especially with SIMD/Vector instructions
16:56<_dp_>it's hard to tell what is faster for very small arrays, needs benchmarking
16:57<m3henry>godsort?
16:57<m3henry>O(0)
16:57<@peter1138>I'm wondering if I need the bounced checking in FindStationsAroundTiles now.
16:57<_dp_>for large ones sure, binsearch+memcpu is so fast that it kinda separates insertion from the rest of n*n sorts
16:57<LordAro>bogosort
16:57<@peter1138>Oh, maybe.
16:57<@peter1138>There's a loop that avoids.
16:57<Eddi|zuHause>m3henry: so even faster than O(1)?
16:58<m3henry>Yes
16:58<m3henry>God would just have the items already sorted
16:58<_dp_>but for small ones it may be better with linear search and just a loop move
16:58<andythenorth>hmm
16:58<_dp_>no idea what's better for cpu optimizations
16:59<m3henry>_dp_: bubble sort is best for n == 2
16:59<m3henry>xD
16:59<_dp_>m3henry, for n=2 any sort is just operator< :p
17:00<Eddi|zuHause>_dp_: i'm assuming sorting algorithms are hard for optimizers because there are data dependencies all over the place
17:00<m3henry>exactly, bubble just has the lowest overhead of the generic algorithms
17:00<andythenorth>oof so o/c, hg has numeric revs and git doesn't :) which means newgrf versions need re-designed :P
17:00<m3henry>git can
17:01<andythenorth>it can?
17:01<m3henry>you can count the number of commits
17:01<Eddi|zuHause>andythenorth: the makefile was at some point changed to use date instead
17:01<_dp_>Eddi|zuHause, merge is kinda good for parallel sorting
17:01<@peter1138>Oh yeah, one reason for using StationID instead of Station * is I don't need to dereference it during the insert.
17:01<Eddi|zuHause>_dp_: i think merge needs more memory?
17:01<andythenorth>Eddi|zuHause: it was changed back (because of collisions iirc)
17:02<andythenorth>https://github.com/andythenorth/firs/blob/master/bin/hg-info#L71
17:02<@peter1138>Hmm, just realised this sorted Include is now used every where in StationList, not just my parts.
17:02<Eddi|zuHause>andythenorth: but i'm sure there's a git encantment to count the revs
17:02<_dp_>Eddi|zuHause, yeah, but it's not a big issue usually
17:02<andythenorth>well
17:02<m3henry>running `git rev-list --count HEAD` on my OTTD repo puts it at r23284
17:02<andythenorth>the branch name is in the file also, so the rev might be safe
17:03<andythenorth>m3henry: that's neat, that might work thanks :)
17:03<@peter1138>23349 for me. In a branch...
17:03<@peter1138>I don't have 65 commits.
17:03-!-nielsm [~nielsm@176-23-103-56-cable.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds]
17:03<Eddi|zuHause>23301
17:04<Eddi|zuHause>but i haven't updated in a while
17:04<@peter1138>Hmm, I might be being paranoid, maybe sorting isn't even needed.
17:04<m3henry>KISS?
17:05<@planetmaker>hm, firs on github? :D
17:05<@peter1138>Well, I have this hunch it matters in network games if my lists are different orders.
17:05<andythenorth>planetmaker: yup, frosch moved it ;)
17:05<@planetmaker>:)
17:05<@peter1138>andythenorth, congratulations, now I can contribute.
17:05<andythenorth>we can use it to figure out how to port the others
17:05<andythenorth>peter1138: by rebasing my git mess :P
17:05<Eddi|zuHause>now i'm at 23345
17:05<andythenorth>hiding merges?
17:06<+glx>23334 here
17:06<@peter1138>If you rebase correctly you can make them disappear.
17:06<+glx>in clean master
17:06<andythenorth>planetmaker: any idea if we can port bundles?
17:06<Eddi|zuHause>who needs clean master :p
17:07<@planetmaker>not yet how
17:07<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
17:07<@planetmaker>the more interesting one actually is less bundles imho but the build service
17:07<@peter1138>master is always clean :D
17:08<@planetmaker>but they're linked and only together really make sense
17:08<@peter1138>Well, I had intended to start squashing this PR, not fixing bugs :/
17:08<+glx>unless you forgot to switch to branch before commit yes :)
17:08<Eddi|zuHause>planetmaker: i think what he meant is make the build service compile from the github repo
17:08<@planetmaker>I don't think so :)
17:09<@planetmaker>accessing the build service from a github repo is no big issue
17:09<andythenorth>the question is whether to keep devzone jenkins and just have it build from github
17:09<andythenorth>or whether we need a new build service
17:09*andythenorth prefers changing one thing at a time
17:09<@planetmaker>my idea is to mimic what openttd has. preferentially
17:10<@planetmaker>but it works as-is. And can be made to build from whatever repo. In principle
17:10<andythenorth>I would be happy to not depend on people to maintain specific physical hardware, long term
17:10<@planetmaker>I haven't quite figured out the github hook needed to trigger it
17:11<andythenorth>but short term, a step-by-step migration is good
17:11<@planetmaker>^^
17:11<@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
17:11<andythenorth>planetmaker: is the build service actually just jenkins?
17:11<@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
17:12<andythenorth>+1
17:12<+glx>on github you have access to azure pipelines
17:12<@planetmaker>yeah. That's why I think I'll try to mimic openttd's way
17:13<@peter1138>I think switching from hg to git is a nice step.
17:13<@peter1138>Whenever I tried using hg it all went wrong.
17:13<andythenorth>hmm can't log in to coop jenkins
17:13<LordAro>s'ok, ottd's azure-pipelines is only bus fsctor 1.5ish
17:13<LordAro>factor*
17:13<andythenorth>only TB can press the magic button? :P
17:14<@peter1138>Ok, 3 pieces of Baklava is a fuck load of energy. :/
17:14<andythenorth>it's all sugar?
17:14<andythenorth>planetmaker I was going to look if we just need to configure Poll SCM to fetch from github
17:14<@peter1138>No, it's sugar AND fat :/
17:14<@planetmaker>LordAro, yes-ish. But if it requires only one thing to understand both services, it's an advantage to two different things
17:14<@peter1138>And tastes bloody great.
17:14<andythenorth>dunno if Poll SCM is what coop jenkins uses
17:14<LordAro>technically anyone can reproduce it, but currently only TB understands how :p
17:14<@peter1138>It was the better half's birthday today, so we had a treat.
17:14<@planetmaker>andythenorth, polling would surely work. But I'd not be fond of it
17:14<andythenorth>you want to webhook it?
17:15<@planetmaker>yes
17:15<@planetmaker>I know that polling works ;)
17:15<@planetmaker>that worked for nml
17:15<+glx>the yaml part is easy
17:15<@peter1138>andythenorth, also it was from a local turkish takeaway, so very moist and juicy. Not like the rancid crap that Tesco sell.
17:15<andythenorth>oic
17:16<@planetmaker>the interesing part is actually the version thing... currently jenkins gets told what to build...
17:16<andythenorth>planetmaker: I just gave you access here https://github.com/andythenorth/firs/
17:16<@peter1138>I had some of that once and it had a very strange bitter taste.
17:16<@planetmaker>polling means it needs to decide itself
17:16<andythenorth>webhooks are in settings https://developer.github.com/webhooks/#events
17:16<@peter1138>Like rancid coconut fat or something.
17:16<andythenorth>I have only had baklava from greek or cypriot shops
17:16<+glx>and if you can build using the windows image you don't have to use docker :)
17:16<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
17:16<@peter1138>_dp_, now you can see my sorted insert, but it's working now, heh.
17:17<@peter1138>_dp_, the non-working version was "Insert(it); *it = st;" which of course fails on realloc.
17:18<@planetmaker>andythenorth, I'm still away from home till next Monday; so I definitely cannot make promises before that.
17:18<andythenorth>no rush
17:19<andythenorth>I need to figure out porting the makefile revision script to git
17:19<andythenorth>it will take some time
17:19<Eddi|zuHause>is that more than 3 lines?
17:20<andythenorth>210 Eddi|zuHause https://github.com/andythenorth/firs/blob/master/bin/hg-info
17:20<+glx>IIRC Makefile and andythenorth are not friends :)
17:20<andythenorth>it got better, but yeah, that's fair
17:20<andythenorth>this is just a python script though
17:20<Eddi|zuHause>andythenorth: that looks hopelessly overengineered :p
17:20<andythenorth>everything does at first glance
17:21<@planetmaker>do you have access to jenkins?
17:21<andythenorth>planetmaker: apparently not
17:21<andythenorth>Eddi|zuHause: Chesterton's Fence might apply https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
17:21<@planetmaker>let's change that...
17:22<andythenorth>Eddi|zuHause I didn't write it, Alberth did, but it replaced things that were worse to read and worse to use
17:24<andythenorth>OTOH this is too complex for me to quickly port to git :P
17:25<@peter1138>Woo, all checks have passed.
17:28<@peter1138>Ah yes, I was going to see if creating an industry was a problem.
17:28<andythenorth>oic, this hg-info script can take shell args
17:29<@peter1138>Showing station signs seems to be :-)
17:31<andythenorth>oof bed
17:32<@peter1138>Nn
17:32-!-andythenorth [~andytheno@cpc87219-aztw31-2-0-cust178.18-1.cable.virginm.net] has left #openttd []
17:39-!-Wormnest [~Wormnest@35.136.176.177] has quit [Ping timeout: 480 seconds]
17:40<Eddi|zuHause>hm, i don't know what changed, but the "BFS randomly turns into DFS" problem seems to have magically disappeared
17:44<@peter1138>Hmm, RecomputeIndustriesNearForAll has just bitten the dust.
17:47<DorpsGek_II>[OpenTTD/OpenTTD] James103 commented on issue #6507: Crash: corrupt savegame https://git.io/fhdPu
17:48<LordAro>oh hey, it's my bug
17:50<@peter1138>Hmm, station finder not working :S
17:53<DorpsGek_II>[OpenTTD/OpenTTD] James103 commented on issue #6605: Crash: loading savegame https://git.io/fhdP2
17:57-!-Flygon [~Flygon@114-198-109-17.dyn.iinet.net.au] has joined #openttd
17:57-!-Flygon is "Flygon" on #openttd
17:59<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6
18:02<@peter1138>Yeah, tile scan is clearly better than FOR_ALL...
18:03-!-m3henry [~m3henry@host-212-139-212-35.static.as9105.net] has quit [Quit: Leaving]
18:04<@peter1138>Oh, no, FindStationsAroundTiles is a FOR_ALL :/
18:12-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
18:20<_dp_>ok, I blame cargodist
18:20<_dp_>map<..., map<...>>[NUM_CARGO] definitely looks like a RAM black hole :p
18:21<@peter1138>Hmm
18:25-!-Samu [~Ricardo@pa4-84-91-142-34.netvisao.pt] has quit [Quit: Leaving]
18:36<DorpsGek_II>[OpenTTD/OpenTTD] nikolas opened pull request #7253: Fix #7189: Fluidsynth volume gain too high https://git.io/fhdXI
18:38<DorpsGek_II>[OpenTTD/OpenTTD] nikolas commented on issue #7189: fluidsynth driver plays music too loudly https://git.io/fhdXt
18:40<DorpsGek_II>[OpenTTD/OpenTTD] nikolas updated pull request #7253: Fix #7189: Fluidsynth volume gain too high https://git.io/fhdXI
18:41<_dp_>sizeof(GoodsEntry) = 136 so each station gets NUM_CARGO * 136 = 8704 bytes of basically empty space
18:43<_dp_>could probably be replaced with smth like map<pair<StationID, CargoID>, GoodsEntry>
18:44<@peter1138>Hmm
18:44<@peter1138>Yeah these fixed entries were okay when we only had 12 cargo types.
18:49-!-drac_boy [~oftc-webi@72.1.195.4] has joined #openttd
18:49-!-drac_boy is "OFTC WebIRC Client" on #openttd
18:49<drac_boy>hi there .. any git fun tonight?
18:49<@peter1138>We're all gits.
18:52-!-Progman [~progman@p4FD6671F.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
18:59<@peter1138>Damn it. More optimizations and... scope :/
19:00<Eddi|zuHause>fixing that cargodist mess is probably good for a separate PR
19:00<@peter1138>Separate to what?
19:00-!-Supercheese [~Superchee@50-37-112-121.mscw.id.frontiernet.net] has joined #openttd
19:00-!-Supercheese is "Supercheese" on #openttd
19:00<Eddi|zuHause>to all the other PRs
19:01<@peter1138>Yes. Why wouldn't it be?
19:01<@peter1138>_dp_ isn't Samu :-)
19:01<@peter1138> /* New town doesn't happen very often so recomputing all stations should be fine. */
19:01<Eddi|zuHause>_dp_ has so many names, how can you be sure one of them isn't Samu?
19:01<@peter1138>Time to test founding a town in _dp_'s save.
19:02<@peter1138>Eddi|zuHause, that would be clever social manipulation.
19:02<@peter1138>This one appears to know "a little" more.
19:03-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
19:03-!-mode/#openttd [+v tokai] by ChanServ
19:03-!-tokai is "Christian Rosentreter" on +#openttd
19:04<@peter1138>Hmm, how to get the location and size of a town :/
19:04<drac_boy>:)
19:04<@peter1138>t->xy + radius?
19:05<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
19:06<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhdXl
19:09-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
19:10<@peter1138>Yeah, FOR_ALL_STATIONS() { FOR_ALL_TOWNS() { ...
19:11<@peter1138>No wonder it sucks.
19:20-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has quit [Quit: No Ping reply in 180 seconds.]
19:21-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has joined #openttd
19:21-!-Smedles is "Paul Smedley" on #openttd
19:22-!-Ammler [~ammler@188.cimarosa.openttdcoop.org] has quit [Server closed connection]
19:22-!-Ammler [~ammler@188.cimarosa.openttdcoop.org] has joined #openttd
19:22-!-Ammler is "Marcel Gmür" on #openttd
19:23-!-Supercheese [~Superchee@50-37-112-121.mscw.id.frontiernet.net] has quit [Remote host closed the connection]
19:23-!-Supercheese [~Superchee@50-37-112-121.mscw.id.frontiernet.net] has joined #openttd
19:23-!-Supercheese is "Supercheese" on #openttd
19:35-!-drac_boy [~oftc-webi@72.1.195.4] has left #openttd []
19:45-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has quit [Ping timeout: 480 seconds]
19:46-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has joined #openttd
19:46-!-Smedles is "Paul Smedley" on #openttd
20:06-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has quit [Ping timeout: 480 seconds]
20:07-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has joined #openttd
20:07-!-Smedles is "Paul Smedley" on #openttd
20:10<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6
20:10<Eddi|zuHause>that last change was probably more crazy than the crazy hack :p
20:10-!-HerzogDeXtEr [~farci@dslb-188-103-131-188.188.103.pools.vodafone-ip.de] has joined #openttd
20:10-!-HerzogDeXtEr is "purple" on #openttd
20:11<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6
20:13<Eddi|zuHause>uhm, was that my force push that broke the build?
20:15<Eddi|zuHause>ah, i think i caught it in some intermediate stage where it was not yet picking up the new one
20:15<Eddi|zuHause>hm... no, weird
20:18<Eddi|zuHause>i can't figure out what's wrong with the build
20:19-!-supermop_Home [~user@pool-71-105-225-37.nycmny.fios.verizon.net] has joined #openttd
20:19-!-supermop_Home is "Guest" on #openttd
20:27<+glx>not the first time this error happens
20:29<+glx>https://dev.azure.com/openttd/OpenTTD/_build/results?buildId=1141&view=results <-- this one had a similar fail
20:30-!-TrueBrain_ii [~truebrain@home.truebrain.nl] has quit [Server closed connection]
20:31-!-TrueBrain_ii [~truebrain@home.truebrain.nl] has joined #openttd
20:31-!-TrueBrain_ii is "Patric Stout" on #dorpsgek #openttd
20:34<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z updated pull request #7213: Feature: BFS-based river generator https://git.io/fhHN6
20:35<Eddi|zuHause>glx: i'm pretty sure it's a race condition between trying to fetch the PR and invalidating the build due to updated PR
20:35<+glx>possible
20:35<dwfreed>fun fact, git has a flag to push to avoid accidentally force-pushing over somebody's push you don't know about
20:36<dwfreed>--force-with-lease
20:36<Eddi|zuHause>dwfreed: i'm fairly confident that nobody else pushed to my fork :p
20:37-!-supermop_Home [~user@pool-71-105-225-37.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
20:37<+glx>indeed commit 9fa29a7ed9c7a3a2dac7a812d84632a0ef9cbe68 seems wrong in the log
20:38<+glx>well maybe it was correct, but I can't check since you force pushed again :)
20:39<Eddi|zuHause>there's no 9fa2... in my reflog, so i can't verify that either
20:40<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
20:41<@peter1138>+575-114 :/
20:42<Eddi|zuHause>600loc is only like a full week of work :p
20:43<@peter1138>5 days, so yes.
20:44-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has quit [Quit: No Ping reply in 180 seconds.]
20:44<Eddi|zuHause>even a bit more, if you assume 10 lines per hour and 8 hours per day
20:45-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has joined #openttd
20:45-!-Smedles is "Paul Smedley" on #openttd
20:47<Eddi|zuHause>(which comes out at 400 loc)
20:54-!-supermop_Home_ [~user@pool-71-105-225-37.nycmny.fios.verizon.net] has joined #openttd
20:54-!-supermop_Home_ is "Guest" on #openttd
20:59-!-Gustavo6046 [~Gustavo60@189.6.240.114] has quit [Ping timeout: 480 seconds]
21:04-!-Supercheese [~Superchee@50-37-112-121.mscw.id.frontiernet.net] has quit [Quit: Valete omnes]
21:19<@peter1138>I... was going to have an early night. Shit.
21:33-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has joined #openttd
21:33-!-snail_UES_ is "Jacopo Coletto" on #openttd
21:36<DorpsGek_II>[OpenTTD/OpenTTD] nikolas opened pull request #7254: Codechange: introduce a few unit tests https://git.io/fhdMU
22:03<supermop_Home_>hmm
22:06-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has quit [Ping timeout: 480 seconds]
22:07-!-Smedles [~quassel@61-245-155-93.3df59b.adl.nbn.aussiebb.net] has joined #openttd
22:07-!-Smedles is "Paul Smedley" on #openttd
22:14<DorpsGek_II>[OpenTTD/OpenTTD] nikolas updated pull request #7254: Codechange: introduce a few unit tests https://git.io/fhdMU
22:23-!-debdog [~debdog@2a00:79c0:652:0:7a24:afff:fe8a:d04d] has joined #openttd
22:23-!-debdog is "Wowbagger" on #bitlbee #openttd
22:25-!-Thedarkb-X40 [~beno@86-40-230-189-dynamic.agg3.kny.prp-wtd.eircom.net] has joined #openttd
22:25-!-Thedarkb-X40 is "realname" on #openttd #/r/openttd #oolite
22:27-!-D-HUND [~debdog@2a00:79c0:625:0:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:29-!-supermop_Home_ [~user@pool-71-105-225-37.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
22:44-!-glx [kvirc@000128ec.user.oftc.net] has quit []
23:04-!-HerzogDeXtEr [~farci@dslb-188-103-131-188.188.103.pools.vodafone-ip.de] has quit [Read error: Connection reset by peer]
23:23-!-Thedarkb-X40 [~beno@86-40-230-189-dynamic.agg3.kny.prp-wtd.eircom.net] has quit [Ping timeout: 480 seconds]
23:44-!-snail_UES_ [~snail_UES@cpe-98-14-137-148.nyc.res.rr.com] has quit [Quit: snail_UES_]
---Logclosed Wed Feb 20 00:00:11 2019