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

---Logopened Sun Feb 03 00:00:48 2019
00:06-!-tokai [] has quit [Ping timeout: 480 seconds]
00:25-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has joined #openttd
00:25-!-keoz is "Grmph" on #openttd
02:20-!-cHawk [] has quit [Quit: Leaving]
02:26-!-cHawk [] has joined #openttd
02:26-!-cHawk is "realname" on #openttd
02:32-!-andythenorth [] has joined #openttd
02:32-!-andythenorth is "andythenorth" on #openttd
02:32<andythenorth>so....cargo aging period
02:43<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7049: Fix #6599: Can still click on buy button in vehicle selection window even if no vehicle is selected
02:45<andythenorth>so prop 2B
02:45<andythenorth>what's it do eh?
02:46<@peter1138>I... don't know
02:47<@peter1138>Should it be a cargo property not a vehicle property?
02:47<andythenorth>already got some of those
02:47<@peter1138>Well, it's our own custom thing, so only us to blame :p
02:48<andythenorth>I'll test it a bit more
02:48<andythenorth>it does affect payment, but eh
02:48<@peter1138>Well it is an old one, hmm.
02:49<andythenorth>did I mention how good this ffwd is?
02:49<andythenorth>for testing stuff like this :P
02:49<@peter1138>It's kinda too fast.
02:49<@peter1138>But never mind.
02:58<@peter1138>Should I make an HSV selector?
02:58<@peter1138>Scrollbars for R G B look dumb :/
03:00-!-nielsm [] has joined #openttd
03:00-!-nielsm is "Niels Martin Hansen" on #openttd
03:06<@peter1138>Hmm, actually -5 outside.
03:09<@peter1138>Fortunately I accidentally left the central heating on overnight, so it's comfortable inside.
03:09-!-Wolf01 [] has joined #openttd
03:09-!-Wolf01 is "Wolf01" on #openttd
03:10<andythenorth>lies nml
03:11<andythenorth>nml wiki says cargo_age_period can be 0 ... 65535
03:11<andythenorth>but it won't accept more than 65534
03:11<andythenorth>obiwan :P
03:12<@peter1138>So you can have special engines that make cargo pay differently. Hmm.
03:12<andythenorth>well it's the wagons I assume
03:12<@peter1138>Um, yeah, sorry, "Engine" in source-code speak.
03:14-!-sla_ro|master [] has joined #openttd
03:14-!-sla_ro|master is "slamaster" on #sla #openttd
03:15<andythenorth>it does work, I'm testing different values
03:15<andythenorth>I think it's running into a clamp somewhere
03:15-!-Pikka [] has joined #openttd
03:15-!-Pikka is "realname" on #openttd
03:15<andythenorth>there's nothing intuitive about the resulting profits :)
03:16<@peter1138>It'll change the days_in_transit type stuff?
03:16<andythenorth>yes, or something related there
03:18<@peter1138>Seems a very odd thing to have :-)
03:18<andythenorth>testing with different values
03:19<andythenorth>oops, there's a typo
03:19<@peter1138> (svn r22713) -Feature: [NewGRF] Per vehicle custom cargo ageing period.
03:20*andythenorth fixes the image
03:20<andythenorth>I haven't plotted it, but the increase from 185 > 373 > 65534 looks linear to me :P
03:20<andythenorth>which is...odd
03:21<andythenorth>I'd expect it to either be orders of magnitude different, or just clamped
03:22<@peter1138>There is a limit of 255 for cargo days in transit.
03:22<@peter1138>You may be hitting that.
03:22<Eddi|zuHause><andythenorth> so....cargo aging period <-- it's not a price factor, so you can't make prices above the original price of instant delivery.
03:22<@peter1138>Although you'd expect that to hit the lowest values, not the highest.
03:22<@peter1138>Yes, it's not a price factor.
03:23<Eddi|zuHause>it only has real effect over large distances
03:23<@peter1138>I'm not sure what it's for, though.
03:23<@peter1138>Simulating refridgerated wagons?
03:23<andythenorth>pretty much
03:23<Eddi|zuHause>peter1138: original intention was for things like refrigerated cars
03:24<andythenorth>I'm testing over 72 tiles crow distance
03:24<Eddi|zuHause>peter1138: or trains with dining cars
03:24<andythenorth>all of those things Eddi|zuHause
03:24<Eddi|zuHause>andythenorth: that is not long :p
03:24<@peter1138>Passengers age less on a dining car?
03:24<Eddi|zuHause>peter1138: more like "if there's a dining car in a train, they make longer journeys"
03:24<andythenorth>also my map is only 256 ^ 2 :P
03:25<@peter1138>So you can have a distance of ~ 500 easily.
03:25<andythenorth>let's see what 32 does
03:26<andythenorth>a straight payment multilplier would be more straightforward here :P
03:26<andythenorth>multilplier :P
03:26<andythenorth>whatever the cargo curve is, you get n * that
03:27<Eddi|zuHause>andythenorth: why would then anyone ever use the less expensive train?
03:27<andythenorth>tile density
03:28<Eddi|zuHause>andythenorth: i think the real use of cargo aging is shortening the period on tightly packed metro trains or busses where people stand
03:28<andythenorth>my tests are suggesting the same
03:28<andythenorth>it's a malus not a bonus
03:29<Eddi|zuHause>well, the bonus can make a difference if you're like driving 1000km without maglev
03:29<@peter1138>Hmm, that reminds me, there's a issue about overcrowding at stations.
03:30<Eddi|zuHause>peter1138: the issue is usually too low capacity (or too high generation)
03:30<Eddi|zuHause>and the transport rating is insufficient for regulating that
03:31<Eddi|zuHause>i mean, we could hide the problem with a flat limit of like 100 passengers/pieces of cargo per station tile
03:32<Eddi|zuHause>but it won't solve the underlying balance issues
03:33<andythenorth>tried 32
03:33<andythenorth>trying to find the inflection points
03:33<Eddi|zuHause>i think your math is off?
03:34<Eddi|zuHause>how is 373=2*185?
03:34<Eddi|zuHause>@calc 2*185
03:34<@DorpsGek>Eddi|zuHause: 370
03:34<@peter1138>It's too high generation
03:34<andythenorth>Eddi|zuHause: typo :)
03:34<andythenorth>I'll fix
03:35-!-Gabda [] has joined #openttd
03:35-!-Gabda is "realname" on #openttd
03:35<@peter1138>Hmm, but since we closed a load of issues I can't find it :p
03:35<andythenorth>not sure what I do with this next :)
03:36<andythenorth>generation is in nielsm's PR
03:36<Eddi|zuHause>andythenorth: now run the same test over twice, quad, etc. distance
03:36<andythenorth>yeah I need more time for that :P
03:36<andythenorth>or I need to make a standalone testing grf
03:36<andythenorth>horse compile times are far too long for this
03:37<@peter1138>Oh yes, it's not closed :-)
03:37<andythenorth>30 mins to just get these results :P
03:37<Eddi|zuHause>andythenorth: just duplicate the train with multiple values?
03:37<andythenorth>yes that's what I'd do
03:38<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #6965: Add: Four alternative town cargo generation methods
03:38*andythenorth wonders if a redesign of the grf is looming
03:39<andythenorth>I just assumed that 2 * cargo_age_period would be roughly twice the payment :D
03:39<andythenorth>give or take the cargo curve
03:40<Eddi|zuHause>not how it works :p
03:40<andythenorth>so I see :P
03:40<andythenorth>I now assume it just changes the slope of the curve :P
03:40<andythenorth>retrospectively more obvious
03:41<nielsm>...I should get a shower, put on some clothes, and find some breakfast, in one order or another
03:41<andythenorth>these are all things
03:42<andythenorth>some of those I need to do also
03:42<andythenorth>then a day of childrens football, parties, shopping :P
03:42<nielsm>and look at that PR again after I'm done with all of those
03:42<andythenorth>16 cargo nml? o_O
03:42<andythenorth>my branch was a merge mess, peter fixed it
03:42<nielsm>maybe that too
03:43<andythenorth>but some more of the commits could use a squash
03:43<andythenorth>I'm finding it hard to figure what's done or not, so I'm hoping we can squash down the working stuff to just a few commits
03:44<andythenorth>Eddi|zuHause: you don't fancy making a test grf, and running it over different distances for a day? :P
03:44<andythenorth>in the name of empiricism?
03:44<nielsm>the prod cb v2 does work
03:44<Eddi|zuHause>i don't think so
03:44<nielsm>so maybe it's actually done?
03:44<nielsm>except for maybe needing the new house props as well, not sure
03:45<andythenorth>I thought there was one more thing we were stuck on
03:45<andythenorth>or maybe it was docs
03:45<andythenorth>logs would know, but eh, breakfast
03:49<@peter1138>Oh wait, there is room. p1 isn't full.
03:54-!-Progman [] has joined #openttd
03:54-!-Progman is "Peter Henschel" on #openttd
03:56<andythenorth>so cargo age period will have a big impact for slow vehicles
03:57<andythenorth>but if I'm comparing Fast Train 1 to Very Fast Train 2, it's going to be marginal eh :P
03:57<andythenorth>30 day transit time, the bonus barely touches the sides
03:59<andythenorth>eh it's a relatively new feature, August 2011
04:00<@peter1138>TownAirports, eh?
04:00<andythenorth>first github result :P
04:00<andythenorth>so many forks
04:01<andythenorth>michi_cc can you remember the back story for train var 2B? :)
04:01<andythenorth>[and friends]
04:05<Eddi|zuHause>andythenorth: try comparing transit times of about 1 year?
04:06<Eddi|zuHause>andythenorth: anyway, i think the feature is working as intended :p
04:06<Eddi|zuHause>andythenorth: play bigger maps :p
04:07<andythenorth>I think it does work as intended
04:08<andythenorth>I just wondered what the intent was :P
04:09<andythenorth>my assumption was that it came from TTDP, but it's too new for that
04:13<andythenorth>eh, it's exposed to CB36 :P
04:14<@peter1138>Yup, something else to desync :)
04:14<andythenorth>'vehicle is old, passengers complain'
04:14<@peter1138>So we can't fix cargo generation because goal servers / gamescripts rely on it being broken?
04:14<andythenorth>we can't fix it allegedly without a setting
04:14<andythenorth>or some crap
04:14<andythenorth>but the quadratic thing is just a bug no?
04:15<@peter1138>Yes, clear and simple, I think.
04:15<andythenorth>2.0.0 semver major bump, API change
04:15<andythenorth>wavey hands
04:15<@peter1138>No way
04:15<@peter1138>I want it fixed before then, it's not enjoyable having a small town and 1000s of passengers waiting
04:16<andythenorth>nope it is not
04:16<andythenorth>cdist on?
04:17<@peter1138>Either way it fills up massively, it is easier to get rid off without cdist though.
04:17<nielsm>town cargogen, do the game setting I'm implementing in my PR, default old savegames to old algo, new games to new algo
04:17<andythenorth>it's not enjoyable
04:17*andythenorth wonders what vehicle vars could be abused for cargo age cb :P
04:17<andythenorth>probably none, it won't trigger usefully
04:18<@peter1138>nielsm, I don't think it should be a setting.
04:18<@peter1138>Old savegames don't need it.
04:18<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Four alternative town cargo generation methods
04:18<@peter1138>It's the custom goal servers that may need it, and we have never tried to support them.
04:18<@peter1138>They have *custom code*
04:18<@peter1138>They can revert the change if they want.
04:19<nielsm>so treat it as a 25 year old bug?
04:19<nielsm>(which has turned into a feature in the meantime)
04:20<andythenorth>it's a bug
04:20<@peter1138>I guess you already fired up TTD to compare the behaviour ?
04:20<andythenorth>goal servers can ship a fork :P
04:21<andythenorth>or fix it in content
04:21<@peter1138>Heh, true, if its server side only, it is easier for them to just change their requirements.
04:21<andythenorth>there's probably a newgrf houses way to get equivalently broken behaviour
04:22<DorpsGek_II>[OpenTTD/OpenTTD] PeterN opened pull request #7164: Fix #7108: Group livery command did not check its parameters properly.
04:22<nielsm>yes just reimplement the cargo prod cb for houses
04:22<andythenorth>just fake building populations to get the same statistical result
04:23*andythenorth wonders what to do about cargo aging then
04:23<Gabda>will 2.0.0 have backwards compatibility as well, or all the old save game conversion will be deleted, and it will start nice and clean?
04:23<andythenorth>Horse design is based on 'oops, wrong assumption' :P
04:24<nielsm>andythenorth nah, house pops are set in bytes
04:24<nielsm>and default houses already scrape the limit, I think the largest is 240 in the baseset
04:24<andythenorth>[wavey hands]
04:24<andythenorth>hmm, all these extra pax trains and wagons where the only difference is age period :P
04:24<andythenorth>delete? o_O
04:31<@peter1138>So my 555 town in TTD
04:31<@peter1138>passengers last month: 23, max: 69
04:31<@peter1138>my 555 town in OpenTTD
04:31<@peter1138>passengers last month: 2, max: 224
04:31<@peter1138>Well, the TTD town is shrinking :p
04:32<@peter1138>But that's cos its expanding
04:32<nielsm>this is very inconvenient :P
04:32<nielsm>missing a lot of keyboard shortcuts, and no ffwd
04:34<nielsm>at least it does have 1-2-3-4 for selecting rail build direction
04:34<@peter1138>I'm playing it on a dubious website as well, nothing to download.
04:34<nielsm>(I learned that back in 1999 or whenever)
04:37<andythenorth>yair so Horse, for a ~72 tile route, use the 100mph EMU, not the 140mph High Speed Train
04:37<andythenorth>much more money
04:38<andythenorth>eh it's 87mph EMU even
04:39<andythenorth>~£364k profit / year vs ~ £346k
04:40<@peter1138>EMU should be profitable for shorter routes
04:40<andythenorth>'but what are the costs andythenorth'
04:40<@peter1138>HST for longer routes
04:40<andythenorth>I can nerf the EMU costs, and give the HST more of a bonus
04:40<andythenorth>but scaling costs against route length :P
04:40<andythenorth>there's no factor relating the two
04:41<andythenorth>cost is per year, not per tile travelled or whatever
04:41<@peter1138>A faster train travels more tiles in a year, so...
04:41<andythenorth>I bet this would never be noticed in a game
04:42<andythenorth>I only noticed because I'm setting costs
04:42<@peter1138>nielsm, well my small test is inconclusive.
04:42<@peter1138>Just 2 bus stops :p
04:42<andythenorth>I could give the EMU an aging malus
04:42<@peter1138>ottd town is growing, slowly, ttd town is shrinking, slowly
04:42<@peter1138>But that could be anything.
04:42<andythenorth>but the tests show that the malus has much more significant effect than the bonus :P
04:42<andythenorth>so I could break EVERYTHING
04:43<nielsm>ahhhh, this version of dosbox has a turbo feature
04:43<nielsm>that makes the passage of time faster :D
04:43<nielsm>music sounds funny
04:43<andythenorth>Horse needs a Pacer....cargo_age_period 1
04:44<andythenorth>eh it's on a CB, I can set cargo aging to 1 for metro trains in July and August only
04:44<andythenorth>do we know what hemisphere the map is in?
04:45<nielsm>temperate is presumably england-like
04:45<nielsm>tropical is brazil-ish?
04:45<andythenorth>scale the cargo_age_period according to heat and cold?
04:46<nielsm>subarctic likely northern sweden/finland
04:46<andythenorth>different engines can supply different levels of heat or AC?
04:48<@peter1138>If you can't figure out what to do with it, just ignore that property :)
04:50<@peter1138>Can we build with that?
04:51<andythenorth>if I give EMUs a malus, to 32 days, I get a 'better' result
04:51<andythenorth>might need to scale it by vehicle speed
04:51<andythenorth>in black and white days, people loved sitting on slow trains all day?
04:52<andythenorth>that too
04:52<andythenorth>why isn't there black and white mode before 1950?
04:52<andythenorth>for the whole map?
04:52<andythenorth>also sepia before 1910
04:53<andythenorth>^ peter1138 RGB easter egg? :P
04:57<Eddi|zuHause>andythenorth: because the world wasn't in black and white back then?
04:57<Eddi|zuHause>andythenorth: there's black and white newspaper
04:58<nielsm>this matches pretty well with passenger growth on the square of pop:
05:02<andythenorth>eh so I need something like 'range' for pax trains
05:02<andythenorth>and if the range is exceeded, there's a cargo payment malus
05:02<andythenorth>probably about 32 tiles for 'normal' pax
05:03<andythenorth>so how many tiles / day for a given speed?
05:03<andythenorth>ignoring acceleration, deceleration, signal stops
05:03<@peter1138>Well, I dunno.
05:03<nielsm>good music
05:03<andythenorth>formular must be in source somewhere :P
05:04<@peter1138>So if everybody else is happy with an option, keep it an option I suppose.
05:05<andythenorth>'everybody else'
05:06<@peter1138>Maybe not everybody :p
05:08*andythenorth wonders how cargo aging worth with cdist
05:09<andythenorth>if pax stay on the vehicle are they aged?
05:09<andythenorth>seems a bit detailed
05:09<@peter1138>As it's a vehicle property, yes.
05:09<@peter1138>cargo age refers to the time it took, not how old mr and mrs tables are.
05:13<andythenorth>in cdist case, how does it count time? Just last leg? Or since loading point?
05:14<@peter1138>It's no different?
05:14<@peter1138>It's how long was it travelling for.
05:14<andythenorth>I will make a better question later :P
05:15<andythenorth>Tesco Time!
05:15<@peter1138>Are you Samuing me?
05:15<andythenorth>possibly :P
05:15<andythenorth>what do I need in Tesco?
05:15*andythenorth will sort that for self
05:15-!-andythenorth [] has quit [Quit: andythenorth]
05:21<Gabda>nielsm: what tool did you use to make the gif for PR #7120?
05:21<Gabda>I would like to have a new gif (of the new function) for that PR
05:22<Gabda>and I thought it would be better to ask for the method than to ask you to make a new one
05:31-!-Progman_ [] has joined #openttd
05:31-!-Progman [] has quit [Read error: Connection reset by peer]
05:31-!-Progman_ is "Peter Henschel" on #openttd
05:31-!-Progman_ is now known as Progman
05:39<nielsm>hmm, I don't think I ever noticed before how much of an improvement UU '37' really is over SH '8P'
05:39<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Feature: Town Voronoi diagram
05:40<nielsm>20% cheaper, 10% more power, almost 40% lighter, and around 15% lower running cost
05:40<nielsm>(and same speed)
05:41<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7120: Feature: Town Voronoi diagram
05:41<Gabda>nielsm: thanks, it worked :)
05:45-!-Samu [] has joined #openttd
05:45-!-Samu is "OFTC WebIRC Client" on #openttd
05:45<Samu>mirc expired :(
05:46<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 commented on pull request #7025: Add #6887: Option to show zone inside local authority boundary of towns
05:46<Wolf01><Samu> mirc expired :( <- delete the registry key
05:46<Samu>too late, uninstalled
05:47<Samu>back to webchat
05:47<Samu>until it doesn't work
05:49-!-Samu [] has quit []
05:49-!-gelignite [] has joined #openttd
05:49-!-gelignite is "gelignite" on #openttd
05:49-!-Samu [] has joined #openttd
05:49-!-Samu is "OFTC WebIRC Client" on #openttd
05:50-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
05:50-!-andythenorth_ is "andythenorth_" on #openttd
05:51<andythenorth_>eh can’t check src on my phone, but....
05:52<andythenorth_>what’s approxinate ratio of mph to tiles covered per tick?
05:52<Gabda>can I have your opinion on the content of the (second) gif in PR #7120 (
05:52<Samu>let me look
05:53<Samu>No url found for fh66E)
05:53<Samu>oh, i seee
05:53<Gabda>maybe I shouldn't have put it into brackets :)
05:54<Samu>oh, nice, is that for calc closest town?
05:54<Gabda>yes, it is
05:54<nielsm>peter1138: if only the new/fixed passenger gen algorithm is present, it'd also make trouble for all existing saves, since the networks in those would be dimensioned for the old algo, and would probably begin running at a huge loss
05:54<Samu>AIs could benefit from it
05:55<Samu>CalcClosestTown is one of the heaviest
05:55<nielsm>and I don't think players would appreciate their saves being broken in that way
05:55<Samu>and AIs use it intensively
05:55<Gabda>with this, the calc clsoest town calling will be almost free, even on 4096x4096 maps
05:56<DorpsGek_II>[OpenTTD/OpenTTD] alexanderweiss commented on pull request #7109: [OSX] Use high-precision scrolling properties for 2D scrolling
05:56<@peter1138>This is caching town ID for each tile?
05:56<@peter1138>When does it update?
05:57<Gabda>on load and town add/remove
05:57<Samu>what happens when a new town is created?
05:57<Samu>ah, cool
05:57<@peter1138>What happens when a town expands or shrinks?
05:57<Gabda>nothing, closest town doesn't care about that
05:57<@peter1138>Or does that not affect closest town.
05:57<Gabda>i mean the calc closes town
05:57<nielsm>that doesn't affect which tile is closest to town sign
05:58<@peter1138>Okay, so you still need the town ID stored in the map for house tiles, etc.
05:58<Gabda>but that is already in _m
05:58<@peter1138>But it means anything that uses closest town would be considerably faster?
05:58<@peter1138>Not just this feature.
05:58<@peter1138>TownID is what, 16 bits?
05:58<Gabda>this feature is only a demo, and not part of the PR
05:58<@peter1138>128KB on a normal map. That's ok.
05:59<Gabda>yeah, it is 16 bits
05:59<@peter1138>32MB on a stupid size map.
05:59<@peter1138>That's still nothing these days.
05:59<nielsm>yep ttd save import still works :)
05:59<Gabda>if you have a CPU that can handle the search for a stupid size map, you have the RAM as well
06:01<nielsm>and passenger generation for those towns in ottd master is very similar to that in ttd dos
06:01<Gabda>i just have to find the right places to initialize the map after load if I want to substitute the inside of the calcclosesttown with this
06:02<@peter1138>Gabda, quite. I have 32GB and that doesn't seem excessive these days.
06:03<@peter1138>Gabda, hmm, yes.
06:03<@peter1138>I suppose closesttown is used in afterload and other stuff.
06:03<andythenorth_>so given a 100mph pax vehicle, what cargo age period do I need to get an aging malus if the route > 32 tiles :p
06:03<@peter1138>You could perhaps make calcclosesttown check to see if the cache is valid
06:04<nielsm>how about filling the cache with a sentinel value, then in the regular tile loop calculate the closest town and cache it, if a tile has the sentinel value stored
06:04<nielsm>and if calcclosesttown finds then sentinel value when it checks the cache, it does the full calculation and updates the cache
06:05<Gabda>i calc the closest town with a different method, not comparing all the towns
06:05<Gabda>this is faster, and can fill the whole map
06:05<nielsm>but caching it gradually this way avoids having a separate algorithm and should result much less new code overall
06:06<nielsm>(perhaps 20 line patch total)
06:06<nielsm>(for the caching part)
06:06<Gabda>but you have to drop the whole thing is a new town is added
06:07*andythenorth_ needs a spreadsheet :p
06:07<nielsm>hm well yes, or invalidate the cache around the new or removed town
06:07<nielsm>which could be annoying
06:07<Gabda>but you don't know how far you have to invalidate
06:08<Gabda>of course you don't add a new town that often
06:09<@peter1138>Gabda, new town is very rare.
06:10<@peter1138>So, no issue.
06:10<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on pull request #6965: Add: Four alternative town cargo generation methods
06:10<Samu>what about scenario editor?
06:10<@peter1138>If it just needs the town coordinates, then you can calculate it early on when loading.
06:10<Samu>you add towns often, there
06:10<andythenorth_>hmmm....maybe I just set aging based on a play test, and never ever ever look at it again :)
06:11<@peter1138>Gabda, how long does it take to calculate?
06:11<Gabda>on what map size?
06:12<@peter1138>256x256, and 4096x4096?
06:12<@peter1138>Are we talking ms, seconds, or minutes?
06:12<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Four alternative town cargo generation methods
06:12<Samu>4096x4096 can generate about 13k towns max
06:13-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Quit: Leaving]
06:13<Gabda>i cannot really load a 4k x 4k map on the virtual machine i am working on :)
06:13<Gabda>for 1024x1024 map with 2260 towns it is 10 ms for me
06:14<nielsm>square of that is 100 ms, would probably not exceed that
06:14<nielsm>oh wait, no
06:14<nielsm>might need square of square for 1k to 4k edge size?
06:14<nielsm>in which case it'd be 10 sec
06:14<Gabda>256x256 and 166 towns is 0,45 ms
06:15<@peter1138>Wait, sub-milliseconds?
06:15<@peter1138>That's probably faster than an individual call to calcclosest? :P
06:15<Gabda>456 microsecond according to chrono
06:15<@peter1138>10ms for 1024x1024 is no issue.
06:16<@peter1138>So the time it takes to recalculate is no issue for the rare times add town/remove town is done.
06:16<Samu>can I test it?
06:16<@peter1138>Unless... does town generation on generating a map need it?
06:16<@peter1138>Updating every time a town is added could get expensive on a large map with lots of towns.
06:17<@peter1138>Although it already is.
06:17<@peter1138>I dunno if it uses it though.
06:17<Samu>gonna clone it, see what happens
06:17<Gabda>it seems I can generate a 4k map without industries
06:17-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has quit []
06:18*peter1138 off out now. bbl
06:18<nielsm>is.... is my bird trying to sing simon foster's tunes?
06:18<Gabda>4096x4096 map 1739 towns (not much) 48 ms
06:19<Gabda>adding a town is fast, it doesn't recalculate the whole map
06:20<Gabda>only recalculate on removing
06:20<Samu>1739 towns, that's a bit lowish
06:20<Samu>from what I'm used to se
06:21<Gabda>I don't know why, but town generation can only squeeze in <3000 towns
06:22-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
06:22-!-andythenorth_ is "andythenorth_" on #openttd
06:24<Samu>try english towns
06:24<Samu>just cloned
06:24<Samu>gonna see what's happening
06:24<Gabda>4096x409 map with 37000 town (scenario editor) 135 ms
06:25<Gabda>it think this town count is quite on the high side
06:26<Samu>the absolute max is 64000 i think, or 65535 not too sure
06:27<Samu>where do I start counting?
06:27<andythenorth_>ok so penalty lower bound is cargo specific
06:27<Gabda>it write the time to standard error
06:27<Gabda>(in linux)
06:28<Samu>this is interesting
06:28<Samu>towns were generated much faster than I used to experience
06:28<Gabda>that has no relation with my PR
06:30<andythenorth_>eh probably I need to control cargos then
06:31<andythenorth_>shall I make an industry set? o_O
06:31<Eddi|zuHause>probably not
06:31<Samu>are you sure? I'm either crazy, or something changed between 1.8.0 and your voronoi
06:32<Samu>generating 13k towns felt faster
06:32<Gabda>Samu: the calculation only starts when you use a tool with rectangle selection like landinfo tool
06:32<Eddi|zuHause><Gabda> I don't know why, but town generation can only squeeze in <3000 towns <-- running out of town names, usually
06:33<Gabda>Eddi: yes, now I changed it to English, Samu said the same
06:34<Samu>i need to compare with master
06:34<Samu>there's definitely an increase in town generation speed
06:34<Samu>from 1.8.0 to your voronoi, but maybe it's something that is also on master
06:34<Gabda>should be something in master
06:35-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
06:36<Gabda>I will try to put it into calc closest town after lunch, and we will see if town generation will be even better, or not
06:38<Samu>building master, gonna compare with 1.8.0
06:38<DorpsGek_II>[OpenTTD/OpenTTD] James103 commented on pull request #6965: Add: Four alternative town cargo generation methods
06:41<Samu>you're right, it's also faster on master
06:44<DorpsGek_II>[OpenTTD/OpenTTD] M3Henry opened pull request #7165: [core] Implement SmallVector using std::vector
06:49<Samu>voronoi was called
06:49<Samu>during town deletion
06:49<Gabda>yes, if you delete a town, it recalculates the whole thing
06:49<Gabda>to fill the tiles of the deleted town
06:50<Samu>world generator deletes towns
06:50<Samu>really cool, but im not sure how to time this
06:51<Gabda>come to think of it, the current version also calculates the whole voronoi on map generation, as towns are added to it one by one
06:52<Eddi|zuHause>it should be possible to keep the deleting of town less impactful, but that might depend on using euclidean norm
06:53<Eddi|zuHause>(have i mentioned yet that voronoi should use euclidean norm?)
06:53<Samu>what is euclidean norm
06:53<Gabda>the distance we are used to in the real life
06:53<Gabda>and not Manhattan distance
06:54<Gabda>Eddi: yes, you mentioned it :) but I have different opinion on this
06:55<Samu>distancesquare then?
06:55<Gabda>yes, sqrt(x^2 + y^2)
06:55<Gabda>that is the Euclidean
06:57<Gabda>I think you can define voronoi with almost any of the norms, as it only contains information for every point on what item they are the closest from a set of items
06:57<Gabda>of course, it is possible, that you don't have a dual for it
06:58<Gabda>but that is not important now
06:58<Samu>distancesquare doesn't sqrt
07:00<Gabda>yes, because sqrt is expensive, and comparing Euclidean distances have the same result when the values are squared
07:01<Eddi|zuHause>Gabda: but with euclidean it has a bunch of extended useful properties
07:01<Samu> duration 790173 __int64
07:02<Eddi|zuHause>Gabda: plus, it makes it more intuitive for players what they expect "closest town" to be
07:03<Gabda>Eddi: sure, but the game logic uses manhattan distance, and I only want to make the query faster. Changing the game logic is way above my head :)
07:04<Samu>in debug mode
07:05<Gabda>and there is even a bug in CalcClosestTownFromTile, but fixing it breaks savefile compatibility
07:05<Samu>a bug? what does it do?
07:10<Samu> duration 1167188 __int64 with 13k towns
07:11<Samu>how much is that in
07:11<Samu>meh, seconds?
07:11<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 opened issue #7166: Incosistency in closest town calculation with threshold
07:12<Gabda>Samu: this is the whole map generation?
07:12<Samu>no, i saved game
07:12<Samu>then loaded it
07:13<Samu>in debug mode
07:14<Samu>release mode is maybe faster
07:15<Samu>but i dont know how to measure this in release mode
07:16<Samu>Variable is optimized away and not available. :|
07:17<Gabda>if you start it from a cmd (I assume you use windows) maybe you can see the stderr there
07:19-!-frosch123 [] has joined #openttd
07:19-!-frosch123 is "frosch" on #openttd
07:21-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
07:21-!-andythenorth_ is "andythenorth_" on #openttd
07:21*andythenorth_ understands cargo age now
07:22<andythenorth_>the puzzle was why there is so little difference between 185 and 65534
07:24<andythenorth_>but that value is only used above the lower bound
07:24<andythenorth_>and is then multiplied by aging factor, which reduces rapidly
07:26<andythenorth_>at least, that’s what nml docs imply :p
07:26<Samu>ah, got it
07:26<Samu>Number of towns: 13308 Voroni build. dbg: [misc] [Town fill] 376885199 [avg: 376885199.0] 105921 microseconds. Voronoi initialized.
07:27<Samu>much faster in release mode
07:29<Samu>Voroni :)
07:33<andythenorth_>i think I’d rather have a multiplier to price factor :p
07:33<andythenorth_>default 1
07:34<andythenorth_>but eh stuff
07:34<Gabda>scenario editor / many random towns does not use CalcClosestTownFromTile. I wonder how does it work.
07:37-!-Thedarkb1-T60 [] has quit [Ping timeout: 480 seconds]
07:39<Samu>oh, start immediately is already mastered, heh cool thx
07:40<Samu>must remove from my ai gui
07:43<Samu>how come it rebased without conflicts?
07:45<Samu>ah, conflicts
07:45<Samu>took long
07:46<nielsm>andythenorth_, how about trains whose running costs increase massively when they run too far between stops at a station?
07:49<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick updated pull request #7084: Change: AI/GS Config GUI overhaul
07:49-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
07:50<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick updated pull request #7084: Change: AI/GS Config GUI overhaul
07:50-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
07:50-!-andythenorth_ is "andythenorth_" on #openttd
07:51<andythenorth_>nielsm variable running costs? o_O
07:52<+michi_cc>andythenorth_: The cargo ageing period affects how fast the payment point moves on the payment curve. The curve isn't linear, as such the ageing prop doesn't affect payment linearly either.
07:53<andythenorth_>afaict, it shortens or lengthens aging period 1 or 2
07:53<+michi_cc>As the payment curve is rather flat at the start, for short routes a bonus does almost nothing and only a malus can be seem. On long routes, a bonus has a more visible period.
07:54<+michi_cc>andythenorth_: No, it modifies how the age of a cargo packet is counted. The age is what is put into the payment calculations (i.e. the days in the payment graph). The ageing period defines after how many ticks the age counter is increased by one.
07:54-!-Thedarkb-T60 [] has joined #openttd
07:54-!-Thedarkb-T60 is "realname" on #openttd #oolite
07:55<andythenorth_>ok so the malus will run age counter up very quicly
07:56<+michi_cc>If you double the ageing period from its default (from 185 to 370), cargo that is transported for 20 days will be calculated as if it had only travelled 10 days for the same distance.
07:57<+michi_cc>Depending on where on the payment curve that ends up, it can be a small or a big difference in payment.
07:57<andythenorth_>ok that all matches the results I’m seeing
07:57<andythenorth_>it’s hard to explain in docs I think
07:58<+michi_cc>Some useful things to do with the prop are for example local and mainline passenger coaches. More capacity and faster ageing for locals, less capacity and slower ageing for mainline. On short routes, it makes the local carriage naturally better (cargo age mostly irrelevant), while long routes prefer the mainline carriage.
07:59<andythenorth_>i tried that :)
07:59<+michi_cc>Similar if you have refrigerated carriages and e.g. normal box cars that both can carry the same cargo.
07:59<andythenorth_>it technically works
07:59<DorpsGek_II>[OpenTTD/OpenTTD] PikkaBird commented on pull request #6965: Add: Four alternative town cargo generation methods
08:01<andythenorth_>the gameplay result is negligible though
08:01<+michi_cc>Anything with money is mostly negligible :)
08:04-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
08:09*peter1138 returns.
08:10<@peter1138>Gabda, so basically, as long as it doesn't need to recalculate every tick, performance is fine.
08:12<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened pull request #7167: Reset ai gs non anchored settings
08:12<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick commented on pull request #7167: Reset ai gs non anchored settings
08:16<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Four alternative town cargo generation methods
08:20-!-synchris [~synchris@] has joined #openttd
08:20-!-synchris is "Synesios Christou" on #openttd
08:20-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
08:20-!-andythenorth_ is "andythenorth_" on #openttd
08:22<andythenorth_>michi_cc so what’s a “long” route? factor of vehicle speed and cargo props?
08:24<+michi_cc>Anything on the right side of the cargo payment graph?
08:24<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on pull request #6965: Add: Four alternative town cargo generation methods
08:25<andythenorth_>I will set up a test map later and see :)
08:26<andythenorth_>the malus (< 185) definitely significant so far
08:26<andythenorth_>values above 185 are barely relevant all the way up to 65534
08:27<+michi_cc>I suspect you need a travel time of 120 days or more to see a noticeable result.
08:27<andythenorth_>yeah I’m down at 30 days or so
08:28<Gabda>peter1138: that is what I want to avoid with this cache
08:29<Gabda>as I plan to create some zoning display
08:29<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Four alternative town cargo generation methods
08:29<@peter1138>I'm just wondering what other features we've said we can't do due to performance...
08:29<@peter1138>railtype/roadtype varaction variables...
08:31<andythenorth_>yeah those
08:31<andythenorth_>splitting cargo to indistries when delivered to station
08:31<Gabda>what are those?
08:32<andythenorth_>the North tile industry station thing is so janky :)
08:33-!-Flygon [] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
08:35<andythenorth_>rubi told me that distributing cargo to n industries was not possible for performance reasons
08:35<andythenorth_>because newgrf industry makes it inpossible to cache
08:36<andythenorth_>or at least, far too expensive due to cache churn
08:39-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
08:39<DorpsGek_II>[OpenTTD/OpenTTD] ThomasdenH opened pull request #7168: Fix CompanyEconomy documentation
08:45<DorpsGek_II>[OpenTTD/OpenTTD] michicc requested changes for pull request #7168: Fix CompanyEconomy documentation
08:47-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
08:52<Samu>CRAP! assertion
08:52<Samu>List is empty
08:53<Samu>I forgot spectators also have goals
08:53<Samu>and story books
08:54<Samu>how to solve :|
08:59<@peter1138>How can they have goals and story books?
08:59<Samu>oh it's just the goals, apparenlty
09:00<Samu>story book is grayed out
09:00<Samu>it says Global Goals instead
09:01<@peter1138>So it means goals for everyone?
09:02<Samu> spectator can also have a story book
09:02<Samu>hmm this is complicating...
09:02<@peter1138>I... don't know what a story book is.
09:02<@peter1138>I've never heard of it.
09:02<Samu>the button next to general company information
09:03-!-Eddi|zuHause2 [] has joined #openttd
09:03-!-Eddi|zuHause2 is "Johannes E. Krause" on #openttd
09:03<Samu>Global Story Book
09:05<Samu>spectator story book option is only enabled when a company has a story?
09:05-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has joined #openttd
09:05-!-keoz is "Grmph" on #kernelnewbies #openttd
09:06<Samu>anyway... Spectator option must be present, or else the list asserts, because it is empty when i click the button
09:06<Samu>must fix
09:07-!-Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
09:07<Samu>I blame glx, he did not want spectator option
09:09<Pikka>Eddi|zuHause2, I have no problem with dismantling the entire concept of cargodist ;)
09:09-!-Eddi|zuHause2 is now known as Eddi|zuHause
09:09<Eddi|zuHause>i do :p
09:09<@peter1138>I like it.
09:10<@peter1138>I think I prefered cargo*dest* but...
09:10<@peter1138>Hmm, some of these new colours are just old colours renamed :p
09:10<DorpsGek_II>[OpenTTD/OpenTTD] ThomasdenH updated pull request #7168: Fix CompanyEconomy documentation
09:11<Samu>btw, Spectator should be white
09:11<Samu>or else, when selecting it becomes fully black
09:13<DorpsGek_II>[OpenTTD/OpenTTD] ThomasdenH commented on pull request #7168: Fix CompanyEconomy documentation
09:15<DorpsGek_II>[OpenTTD/OpenTTD] michicc commented on pull request #7168: Fix CompanyEconomy documentation
09:17<Samu>do i have to delete the string from the language files?
09:17<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7168: Fix CompanyEconomy documentation
09:17<Samu>could I actually rename BLACK to WHITE on the other language files?
09:18-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
09:18-!-andythenorth_ is "andythenorth_" on #openttd
09:19<+michi_cc>Hmm, actually, who knows about network code? There's a "p->Send_uint64(income);" with income being an OverflowSafeInt64. Is this supposed to work with negative income?
09:20<Samu>should be int64 no?
09:20<Samu>unless it really is an incom
09:21<Samu>i feel like fixing all language files, dunno if it's okay in this case
09:22<LordAro>Samu: as long as it's a separate commit, changing codes like that is fine
09:23-!-Thedarkb-T60 [] has joined #openttd
09:23-!-Thedarkb-T60 is "realname" on #openttd #oolite
09:24<@peter1138>Hmm, "Turquoise" is the same as "Light Blue"
09:24<+michi_cc>Okay, the C++ standard seems to define how this cast has to be performed. And the definition results in the same bits, so everything is alright.
09:25-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
09:25-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:81a4:515f:2900:5de:afb2] has quit [Ping timeout: 480 seconds]
09:26<nielsm> huh why did this fail
09:27-!-Taede_ [] has joined #openttd
09:27-!-Taede_ is "Taede Werkhoven" on #openttd #oftc #supybot #/r/openttd
09:27-!-Taede [] has quit [Quit: He who can look into the future, has a brighter future to look into]
09:27<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh approved pull request #7164: Fix #7108: Group livery command did not check its parameters properly.
09:29-!-Gustavo6046 [~Gustavo60@] has joined #openttd
09:29-!-Gustavo6046 is "Non dico nomen." on #openttd #oftc #moocows
09:31<Samu>the commit message, hmm
09:31<+michi_cc>nielsm: Probably because MacOS is listed as abandoned, even if I don't know what that means.
09:32<Samu>"Fix: Spectator could be white" ... too racist :(
09:32<Samu>i mean black, even worse
09:32<Samu>Spectator wasn't visible when highlighted?
09:32-!-Taede_ [] has quit []
09:34-!-Taede [] has joined #openttd
09:34-!-Taede is "Taede Werkhoven" on #openttd #oftc @#Turbulent #supybot @#Soapy #/r/openttd
09:34<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened pull request #7169: Fix: Spectator color
09:34<Samu>hope it's not sounding offensive that way
09:37<TrueBrain>15:26 <nielsm> huh why did this fail <- seems the MacOS ... failed? Weird :P
09:38<TrueBrain>I put a new one in the queue
09:40<Eddi|zuHause>"abandoned" sounds like "got lost in the mail"
09:41<TrueBrain>yeah ..
09:41<TrueBrain>I read other stories that the MacOS was being weird
09:41<TrueBrain>Azure had issues this week anyway
09:42<TrueBrain>it is free, what can I say. If we would pay for this, I might be more upset :P
09:43<+michi_cc>We're now a proprietary shop: MS GitHub, MS Azure, commerical CDN :p
09:43<TrueBrain>and I am so happy because of it :) Less maintenance .. so much less
09:44<LordAro>just works a bit less :p
09:44<TrueBrain>custom-build is always better in terms of "working" and "workflow", yup :)
09:44<Samu>github sells your code
09:45<TrueBrain>random quotes are random
09:46<+michi_cc>So why's our website not on e.g. ? :p
09:46-!-andythenorth_ [~andytheno@] has joined #openttd
09:46-!-andythenorth_ is "andythenorth_" on #openttd
09:46<TrueBrain>now he tells me!
09:46<Eddi|zuHause>why is our website not wordpress? :p
09:48<TrueBrain>"100 GB of Bandwidth per month" <- okay, that is not for us :P
09:48<TrueBrain>Eddi|zuHause: that we want to make things more "mainstream", doesn't mean we have to act stupid :P
09:48<+michi_cc>There is a pay option.
09:49<TrueBrain>"$0.1 per GB of Bandwidth"
09:49<TrueBrain>would cost us 400 dollar per month ..
09:49<TrueBrain>but yeah, zeit sounds nice for small websites :)
09:52<TrueBrain>okay ... turns out BaNaNaS mirroring is a bit broken :D
09:53<TrueBrain>utf-8 issues
09:53-!-andythenorth_ [~andytheno@] has quit [Remote host closed the connection]
09:55<DorpsGek_II>[OpenTTD/OpenTTD] flitzpiepe commented on pull request #7145: TBTR 2.0 (Template-based Train replacement)
09:55<TrueBrain>ah .. that was a sillymistake
09:59-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has joined #openttd
09:59-!-andythenorth_ is "andythenorth_" on #openttd
09:59<andythenorth_>mmm wordpress
09:59<milek7>why they are using 'serverless' to mean 'runs on some cloud service'?
09:59<TrueBrain>NO andythenorth_, NO :P
09:59<andythenorth_>free account
09:59<milek7>for me 'serverless' means something like 'clients download content through torrent with dht/ipfs' ;p
09:59<TrueBrain>milek7: dont you just love the word 'serverless' :D
10:00<andythenorth_>i saw a diagram
10:00<TrueBrain>I havent seen that definition, tbh
10:00<andythenorth_>how many servers are needed for serverless
10:00<andythenorth_>was about 27
10:00<@peter1138>Hmm, anyone know what the original colour maps are? :p
10:00<LordAro>sounds about right
10:00<@peter1138>Or do I have to... check?
10:00<TrueBrain>I love how people think 'serverless' means there is no server involved :)
10:01<andythenorth_>magic cloud
10:01<andythenorth_>runs on air
10:01<andythenorth_>haha with 5G it’s all going to ‘run in the network’
10:01<andythenorth_>whatever that means
10:07-!-andythenorth_ [~andytheno@2a01:4c8:b:bbbc:2ca7:61c4:8659:ed9e] has quit [Remote host closed the connection]
10:11<DorpsGek_II>[OpenTTD/OpenTTD] Eddi-z commented on pull request #7145: TBTR 2.0 (Template-based Train replacement)
10:27<Samu>no more crash due to lack of spectator
10:28<DorpsGek_II>[OpenTTD/OpenTTD] PeterN commented on pull request #7169: Fix: Spectator color
10:28<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7169: Fix: Spectator color
10:28<@peter1138>Samu, Haha
10:28<@peter1138>nielsm, haha
10:29-!-andythenorth [] has joined #openttd
10:29-!-andythenorth is "andythenorth" on #openttd
10:29<@peter1138>nielsm, maybe those exceptions are the rule for this? I dunno. Odd.
10:29<@peter1138>andythenorth, did you see my WIP?
10:29<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #7169: Fix: Spectator color
10:29<andythenorth>no :)
10:29<Samu>5 seconds apart
10:29<andythenorth>ha ha
10:30<@peter1138>Although some of them are duplicates.
10:30<andythenorth>is that just 'more'
10:30<andythenorth>grf defined? Or built in?
10:30<@peter1138>Because NewCC doesn't define 16 new colours, just 16 replacement colours.
10:30<@peter1138>Built in, at the moment.
10:30<@peter1138>We should sort the colour list by hue :p
10:30<andythenorth>'probably fine'
10:31<andythenorth>child #2 tipped them all out this morning
10:31<andythenorth>they are less ordered now :P
10:32<andythenorth>so I should make a test game for cargo age thing
10:32<andythenorth>flat, or with hills? :P
10:34-!-glx [] has joined #openttd
10:34-!-mode/#openttd [+v glx] by ChanServ
10:34-!-glx is "Loïc GUILLOUX" on +#openttd
10:34-!-Progman [] has quit [Remote host closed the connection]
10:36<Gabda>further testing of the Voronoi map: in scenario editor (4096x4096 map) adding the first 1280 random towns takes 1.9 sec, from this the 1280 separate update of the voronoi map took 18 microseconds overall.
10:37<Gabda>i forgot a 0, it took 180 microseconds
10:37<Gabda>still, adding a new town to the Voronoi map is quite cheap
10:38<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick updated pull request #7158: Add: Client setting gui.start_spectator
10:38<@peter1138>Does it need to update 1280 times, or can it do it once after the towns are placed?
10:38<@peter1138>I guess creating a town my need calcclosesttown.
10:38<Samu>can do it once
10:38-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
10:39<@peter1138>I don't want opinion, just facts:p
10:39<Samu>in my fact
10:40<Samu>do it once map is generated
10:40<Samu>then do it once each time a town is added
10:40<Samu>Gabda: may know better
10:40<Gabda>peter1138 even said why it is necessary to update it after every add
10:41<Gabda>if rerouted the IsCloseToTown function to CalcClosestTownFromTile, which calls the data from the voronoi map, so I need to update it after every new town
10:42<Gabda>but I think if you want to optimize something about the 1.9 seconds, it is not the best strategy to hack from the 180 microsecond part :D
10:43<@peter1138>Yeah, 1.9 seconds is fine.
10:43<@peter1138>It's nothing when generating a map.
10:43<Gabda>it is just generating 1280 towns to scenario editor
10:44<Gabda>I am kind of interested what is the slow part in it
10:44<Gabda>building up the individual towns?
10:44<+glx>1.9s is nothing if you are adding ECS industries after it ;)
10:44<Gabda>what is ECS?
10:45<+glx>a collection of newgrf
10:45<@peter1138>A set of newgrf industries with complex placement requirements.
10:45<@peter1138>That requirements make it... slow.
10:46<Gabda>can those requirements be cached beforehand? I am into caching nowadays :D
10:47<Samu>how does cherry-pick works when I make changes to the original?
10:47<nielsm>no, would not be realistic
10:47<Samu>will they get updated automatically?
10:47<nielsm>cherry-pick copies the commit you pick from
10:47<Samu>will need to re-cherry pick?
10:47<nielsm>it does not "link" it
10:47<Samu>too bad
10:48<Gabda>you even have to make the first cherry-pick disappear
10:48<Samu>that's what i'm gonna do
10:48<Samu>rebase -i drop
10:51<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick updated pull request #7084: Change: AI/GS Config GUI overhaul
10:52<DorpsGek_II>[OpenTTD/OpenTTD] PeterN merged pull request #7164: Fix #7108: Group livery command did not check its parameters properly.
10:56<Gabda>in case there are no windows open, why is there such a big difference in lag between MarkWholeScreenDirty() and scrolling the viewport?
10:56<@peter1138>Scrolling the viewport actually copies what was already there, moves it, and then only redraws what's new.
10:56<Gabda>scrolling the viewport should make the whole thing dirty as well
10:57<Gabda>oh, I see
10:58-!-Thedarkb-T60 [] has joined #openttd
10:58-!-Thedarkb-T60 is "realname" on #openttd #oolite
10:58<Samu>start date = 0 + spectator slot + fast forward + 15 ais in single player, oh the joy!!!
11:00-!-Wormnest [~Wormnest@] has joined #openttd
11:00-!-Wormnest is "Wormnest" on #openttd
11:02<Gabda>peter1138: do you also know why does it take longer to redraw the screen on a 4096x4096 map than a 512x512 map while fully zoomed out in both cases?
11:02<Gabda>the number of tiles displayed are the same
11:03<+glx>map size to filter the display
11:03<+glx>I think
11:03<TrueBrain>LordAro: still want to try a beta this weekend? Or are we going to try it again next? :)
11:03<+glx>probably a for all tiles, if visible draw it
11:04<+glx>(not verified)
11:04<LordAro>TrueBrain: not out of the question, what needs doing?
11:05<LordAro>is it just changelog & other docs?
11:05<TrueBrain>master needs to be prepared for it, mostly :)
11:05<TrueBrain>I really dont know what you normally do for it
11:05<TrueBrain>please don't tag just yet
11:05<TrueBrain>means I can test-run stuff before we do that
11:05*LordAro looks at frosch123
11:05<TrueBrain>I can already start a test-run ofc; not sure what we expect out of it currently :)
11:05<+glx>hmm there was a txt somewhere for releases I think
11:07<+glx>at minimum there's something to do in
11:07<TrueBrain>currently deb files are called 'openttd_1.8.0-0_i386.deb' for example
11:07<TrueBrain>that surely needs fixing :)
11:07<frosch123>kate changelog.txt known-bugs.txt readme.txt os/windows/installer/install.nsi os/debian/changelog src/script/api/ai_changelog.hpp src/script/api/game_changelog.hpp &
11:07<frosch123>^^ that's my alias
11:08*andythenorth lost in cargo aging tests
11:08<frosch123>maybe files got renamed to .md, or we removed those silly dates :p
11:08<andythenorth>I need a bigger screen
11:12<TrueBrain>LordAro: for this first run, I will not make it automatically trigger on tag; but that is something we can in the future (which might be nice :D)
11:12<Gabda>it seems like MarkWholeScreenDirty() gets worse with the total number of towns
11:12<Gabda>while the same thing is on the screen
11:13<andythenorth>so with default cargo aging, it needs a 256 tile route before the 'high speed' train (140mph) is the most profitabl
11:13<andythenorth>up to 128 tiles, the low-speed EMU is the most profitable by a long measure
11:14<LordAro>TrueBrain: i'll see what i can come up with
11:14*andythenorth runs a few more years to account for variation
11:15<LordAro>interesting, have we not had a beta since 1.5 ?
11:17<TrueBrain>we have not
11:17<@peter1138>Ok, 32 company colours mostly works.
11:19<Pikka>that's more than 16 :o
11:19<TrueBrain>less than 64 :(
11:19<andythenorth>goes to 11
11:19<andythenorth>TrueBrain: come up with names for 64 colours :P
11:19<@peter1138>Going above 254 would be problematic.
11:20<TrueBrain>sure: blue, light blue, light blueish, lightish blue, lisghtish blueish
11:20<TrueBrain>I can go on all day
11:20<@peter1138>And it's 32 only because I only had another list of 16 colours.
11:20<@peter1138>Although it turns out many of those were the same as default, so.. meh.
11:20<andythenorth>sometimes 'more' isn't more
11:21<TrueBrain>glx: "nsis - nsis v3.04 already installed." <- seems their images are finally updated :P
11:21<Gabda>the main viewport is an instance of the ExtraViewportWindow class as well?
11:21<TrueBrain>hmm .. there are currently language errors in master btw
11:22<@peter1138>Pikka, and still an AI can't pick any of them.
11:23<+glx>TrueBrain: nice
11:23<+glx>but I guess it doesn't include the extensions we need
11:24<TrueBrain>no :P
11:24<TrueBrain>"Warning : STR_LIVERY_CAPTION: Param idx #0 '<empty>' doesn't match with template command 'COMPANY' (warning)"
11:24<+glx>known, eints is "stupid"
11:24<TrueBrain>well, this is when you compile OpenTTD currently :)
11:25<+glx>it readds removed string if present in master
11:25<+glx>even if they are broken
11:25<TrueBrain>meh; this makes a beta a bit difficult :P
11:27<+glx> then
11:27<LordAro> pretty sure it's this issue, btw
11:28<TrueBrain>so fix it! :P
11:28<LordAro>i'm busy preparing a release :p
11:29<TrueBrain>a release with language warnings is a bad idea :)
11:29<+glx>hmm not exactly the same, but similar
11:29<andythenorth>michi_cc: any suggested values cargo age to give a bonus? o_O
11:29<andythenorth>I am trying 10 * default currently
11:30<TrueBrain>LordAro: <- preflight results btw; so all green from my side, with the exception of language warnings :)
11:33<+glx>is the .pdb stored somewhere too ?
11:33<DorpsGek_II>[OpenTTD/OpenTTD] Gabda87 updated pull request #7120: Feature: Town Voronoi diagram
11:35<+glx>ah yes seems it is 2019-02-03T16:25:29.9493162Z [BUNDLE] Creating openttd-20190203-master-gcca952d9-windows-win32.pdb.xz
11:36<+glx>but naming is not good (I know it's a test run and probably depends on something from the release commit)
11:37*andythenorth tries a malus
11:40<DorpsGek_II>[OpenTTD/OpenTTD] LordAro opened pull request #7170: Update: Changelog
11:41<LordAro>oh, i guess #7121 should probably happen before any actual release
11:41-!-Thedarkb1-T60 [] has joined #openttd
11:41-!-Thedarkb1-T60 is "realname" on #openttd #oolite
11:41<Samu>peter1138: theres something wrong with GSes, they're not updating that well
11:41<Samu>seems they're delayed
11:42<@peter1138>What does that even mean?
11:42-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
11:42<Samu>taking my Company Value GS
11:42<Samu>in 1.8.0 the update is instant
11:42<+glx>oh good point LordAro
11:42<Samu>in master, it's ... sluggish, delayed
11:43<Samu>easy to spot when multiple companies are playing (AIs)
11:43<Samu>the scoretable is updated instantly on 1.8.0
11:43<Samu>but not on master
11:43<@peter1138>I don't know what "the update" refers to.
11:44<Samu>the refreshing of data to the new values
11:44<Samu>the printing to screen in the goal list
11:44<@peter1138>Do you mean refreshing the window?
11:44<@peter1138>Are you using FFWD?
11:44<@peter1138>Then it's expected.
11:45<Samu>that's not expected
11:45<Samu>unless it is now
11:45<@peter1138>Maybe you need some invalidate calls.
11:46<Samu>uh invalidate calls from the GS?
11:46<@peter1138>Who knows :)
11:46<Samu>they dont have access to that
11:46<@peter1138>Which is the score window?
11:46<Samu>display goal list
11:46<nielsm>hmm, how about changing the svn revision in newgrf version number to 0x8000 and then manually increment it by 1 once in a while?
11:47<DorpsGek_II>[OpenTTD/OpenTTD] glx22 commented on pull request #7170: Update: Changelog
11:47<andythenorth>if you build a train in pause, the clone button doesn't appear on it until unpaused
11:47<Samu>doesnt refresh properly in normal speed either
11:48<+glx>increment by 1 after each stable release probably
11:49<LordAro>190000 , or is that too many bits?
11:49<@peter1138>There's no tick handler in the goal list.
11:49<nielsm>there's 19 bits available
11:49<nielsm>so 0x190000 fits
11:49<@peter1138>So unless the window is invalidated, there's no reason for it to be repainted.
11:49<+glx>but the highest bit means stable
11:49<nielsm>decimal 190000 should also fit
11:49<Samu>gs's dont invalidate
11:50<Samu>at least, not directly
11:50<@peter1138>Not directly.
11:50<nielsm>glx: that's bit index 19 (the 20th bit) that means stable
11:51<+glx>just incrementing current 'svn' version after stable release should be enough I think
11:52<Samu>not sure if it's only my GS that is affected
11:53<Samu>AIs seem to be doing fine, at least I don't spot anything wrong with them
11:54<DorpsGek_II>[OpenTTD/OpenTTD] LordAro updated pull request #7170: Update: Changelog
11:54<+glx>because next version needs to be higher than 28004
11:55<frosch123>LordAro: "#?"?
11:56<LordAro>frosch123: where i meant to look up the PR number but forgot :p
11:56<frosch123>we used to put all issue numbers at the end
11:57<LordAro>mm, i'm open to other suggestions
11:58<@peter1138>Can we have 7121 before beta?
11:58<@peter1138>7021, I mean.
11:58<LordAro>peter1138: i pressed the approve button, but apparently DorpsGek_II didn't notice
11:59<LordAro>i think all issues with it have been addressed?
11:59<+glx>but splitting the available revision bits in major, minor, build could work too
11:59<Samu>you broke my GS :(
12:00<Samu>that tick updater...
12:00<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh closed issue #7021: Version names truncated after move to git
12:00<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh merged pull request #7121: Fix #7021: Better revision strings for network and gamelog
12:00<nielsm>didn't notice before now, but #7121 closes #7021
12:00<nielsm>exactly 100 difference
12:00<Samu>let me test in a multiplayer game
12:01<nielsm>yay no more dumb warnings spamming the console
12:01<+glx>anyway the rev part was mostly used to check feature presence in nightlies
12:01<nielsm>yeah, as long as the svn rev doesn't decrease it should be fine
12:02<+glx>théorically we could have increased it for the 16 cargos
12:02<+glx>oups french slipped in
12:03<+glx>maybe we did, not checked
12:03<Samu>gonna try SCP turned off
12:04<Samu>SCP looks broken
12:04<@peter1138>What's SCP?
12:04<+glx>secure copy ?
12:04<Samu>script communication protocol
12:04<Samu>something from krinn,zuu
12:04<@peter1138>What's that?
12:04<nielsm>that? :)
12:05<Samu>ehm it's somewhere in the AI forum
12:06<andythenorth>after more tests
12:06<andythenorth>cargo age period bonus is useless in the 256 tile range
12:06<andythenorth>it's a low % difference
12:06<andythenorth>cargo age period malus is highly effective
12:06<andythenorth>so much so, that it needs care to set it, otherwise it's easy to get negative profit
12:07<andythenorth>the malus is visible on all routes, but only really kicks in hard for 128 or so
12:07<+glx>communication via signs IIRC
12:08<Samu>looks fine with SCP disabled
12:08<andythenorth>not sure what to next, I feel like I'm turning into Samu :)
12:08<andythenorth>to do *
12:08<Samu>well, RIP SCP
12:09<@peter1138>I'm not sure how a script would make the window not refresh.
12:09<Samu>the window wasn't updating because SCP was getting stuck somewhere
12:10<Samu>some of the recent changes broke SCP support
12:10<+glx>post a useful link when you can ;)
12:10<@peter1138>So ultimately your gamescript was not updating its goals, rather than the window update being laggy?
12:11<Samu>yes, my script, with SCP library into it, yes, i guess
12:11<Samu>I'm not the author of SCP, I don't know what to say about that
12:12<Samu>but it's what was causing the window not to update, it was being delayed by SCP
12:12<Samu>that delay isn't present in 1.8.0 though, something got broken
12:17<DorpsGek_II>[OpenTTD/OpenTTD] LordAro updated pull request #7170: Update: Changelog
12:19-!-andythenorth_ [~andytheno@] has joined #openttd
12:19-!-andythenorth_ is "andythenorth_" on #openttd
12:22-!-andythenorth_ [~andytheno@] has quit [Remote host closed the connection]
12:23<andythenorth>who was that :o
12:23<andythenorth>oh my phone
12:23<@peter1138>But the delay with SCP *isn't* causing the window to no update properly.
12:25<+glx>yeah the window works as it should
12:25<@peter1138>Not window-tick-factor :D
12:26<Samu>well, something broke scp that it now delays at doing its thing
12:26<Samu>which then delays execution of the rest of my code that does the updating
12:26<@peter1138>Maybe someone could report an issue about it, probably do the authors.
12:27<+glx>or someone could try to find when the problem started
12:27<@peter1138>bisect eh?
12:27-!-Thedarkb2-T60 [] has joined #openttd
12:27-!-Thedarkb2-T60 is "realname" on #openttd #oolite
12:28<@peter1138>I wonder about this sprite sorting issue. I thought sprite sorting happened after ViewportAddLnadscape()
12:28<@peter1138>Hmm, and it still does.
12:29<@peter1138>So calls to ViewportAddTile() shouldn't really do anything different regardless of the order they are in.
12:30<@peter1138>Hmm, unless ViewportAddLandscape is cropping too early.
12:31<Samu>i suspect tick stuff
12:31<Samu>gonna try an earlier than tick changes master
12:31<@peter1138>If it communicates via signs, then tick changes wouldn't alter that.
12:31-!-Thedarkb1-T60 [] has quit [Ping timeout: 480 seconds]
12:32<@peter1138>The tick changes were GUI only, and should not affect how the gameloop runs.
12:35<Samu>still gonna test
12:35<Samu>10th january
12:36<LordAro>Samu needs to learn the concept of git bisect
12:36<Samu>no idea what that is
12:37<LordAro>well how do you find out things you don't know about, in this day and age?
12:40<nielsm>hm pondering if I should remake the PR for town cargogen with a new branch name, or just stick to the dumb branch name (and same PR) I used initially
12:41<LordAro>nielsm: i'd prefer as few "closed" PRs as possible :)
12:41<LordAro>the branch name is ultimately irrelevant
12:41<TrueBrain>now I want to know what the branchname is :P
12:44<nielsm>TrueBrain, initially I used all of M8 to store some data between tile ticks on houses, hence "cargogen counter" :D
12:45<+glx>house-cargogen-counter is the name
12:46<+glx>maybe github supports branch renames
12:46<+glx>it's a git feature anyway
12:47<nielsm>as far as I can tell the web ui doesn't allow renames
12:47<+glx>seems it doesn't work
12:49<LordAro>indeed not
12:49<LordAro>which is why it's a bad idea to use your master branch to make a PR :p
12:49<+glx>like TBTR ?
12:49<LordAro>as an example, yes :p
12:50*peter1138 ponders switching to a WM that doesn't mess up moving/resizing OpenTTD.
12:51<+glx>windows works well ;)
12:54<Samu>forwarding to Commit 5ff0c249
12:54<Samu>let's test then
12:55<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #6965: Add: Four alternative town cargo generation methods
12:56<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh commented on pull request #6965: Add: Four alternative town cargo generation methods
12:57<Samu>looks fine, it wasn't the OnTick() stuff
12:57<Samu>well, what could it be now :(
13:01<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh opened issue #7171: determineversion.vbs never marks a version "clean"
13:03-!-Progman [] has joined #openttd
13:03-!-Progman is "Peter Henschel" on #openttd
13:03<LordAro>Samu: what was the state of 5ff0c249?
13:03<LordAro>oh, i see
13:03<Samu>it wasn't it
13:04<LordAro>Samu: well, go forward a few commits until you find the point at which it is broken
13:04<Samu>forwarding to before those afd88 stuff
13:04<LordAro>(this is the key part of git bisect - it performs the search for you)
13:04<nielsm> <- some of these need to go :)
13:05<@peter1138>Yeah, just 2 choices.
13:05<@peter1138>Origin, and whatever the best one is.
13:06<nielsm>I of course prefer my own binomial version because it's more simulation-ish
13:06<DorpsGek_II>[OpenTTD/OpenTTD] glx22 commented on pull request #7120: Feature: Town Voronoi diagram
13:07<DorpsGek_II>[OpenTTD/OpenTTD] michicc approved pull request #7118: Add #5006: Flag to hide rail type from construction.
13:07<@peter1138>A super-hacky hacked test.
13:07<milek7>make UI accept squirrel expression to calculate.. ;D
13:08<nielsm>would it be problematic if I consumed another random number in the town cargo gen? the original method consumes one 32 bit value, but I'd rather like to consume two
13:08<@planetmaker>nielsm, what exactly does the distribution refer to? Cargo generation for different towns?
13:09<@peter1138>nielsm, I don't see why it would be a problem.
13:09<nielsm>all town buildings use the same cargo gen algorithm, unless it's a newhouse and the grf has a cargo gen callback
13:09<+glx>of course you need to check town newgrf still works as intended ;)
13:10<nielsm>it's not a per town setting
13:11<nielsm>there's two "distribution"s involved, sort-of, one is how the overall amount of cargo generated scales with the population
13:11<@planetmaker>I see that it relates cargo generation to inhabitants. I'd not call it 'distribution' then. It's a relation
13:11<nielsm>the other is how the variance in amount between invidual generation events is
13:12<+glx>hmm I'm sure generate.vbs used to work, but maybe only for svn
13:13<@planetmaker>A distribution implies a frequency (how often what value occurs on the map). A relation hom much a value scales with another
13:13<Samu>still fine on Commit ed325ada
13:13<Samu>forwarding a bit past adf88
13:13<nielsm>I'll fix the terms used
13:13<+glx>well determineversion.vbs
13:19<andythenorth>what's the appetite for changing cargo payment algorithm? :P
13:21<Samu>still fine on Commit 36e299fb, that's past adf88 huge stuff
13:21<@planetmaker>andythenorth, only when it considers inter-company logistics :)
13:21<Samu>what else could it be
13:22<milek7>Samu: you know about bisect?
13:22<Samu>ah wait, no
13:22<Samu>it's bad , it's doing bad
13:22<Samu>adf88 busted?
13:23<LordAro>Samu: get an actual commit hash the broke it
13:23<LordAro>don't just guess
13:23<Samu>im trying...
13:24<nielsm>hmm is (1<<32)-1 well-defined for 32 bit unsigned integers in C?
13:25<@peter1138>1 << 32 is 0
13:25<nielsm>is that guaranteed or might a processor trap on it? :)
13:26<milek7>i think it is UB
13:27<@peter1138>Hmm, might end up with 1?
13:27<milek7> 6.5.7/3 [...] If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
13:28<nielsm>okay I'll protect against it
13:30<Samu>don't tell me it's Mail AI spamming signs and SCP reading them all
13:30<Samu>omg, gonna try current master again
13:31<Samu>yeah, reading 4000 signs ought to be slow
13:32<andythenorth>I am concerned that the only way cargo_age_period really works is to give a malus
13:32<andythenorth>so to get a 'bonus' for some vehicles, I need to malus everything else
13:32<andythenorth>'concerned' lol
13:32<@planetmaker>andythenorth, no, you can give a bonus as well
13:33<@planetmaker>there's a default value after which the cargo looses some value. And you can set it to a lower or a higher value
13:33<@planetmaker>via that very property
13:33<+glx>nielsm: hmm indeed determineversion is wrong, but wasn't an issue before because only modified state was checked
13:34<@planetmaker>Supported by OpenTTD 1.2 (r22713)1.2 This property specifies after how many ticks cargo is aged. Default value is 185. 74 ticks is equal to 1 day.
13:34<Samu>just made 1.8.0 delayed too, it's caused by Mail AI that thought it would be funny to spam the map with 'T' signs
13:35<Samu>testing master again just to confirm
13:35<Samu>current master
13:35<@planetmaker>andythenorth, so any value lower than 185 ticks is a malus, anything higher is a bonus
13:37<andythenorth>bonus is marginal
13:37<andythenorth>for pax cargo with ~default props
13:37<Samu>I thought SCP would only read the signs from one tile
13:37<andythenorth>it's low % difference whether you set 185 or 65534
13:37<Samu>apparently reads all signs in existance
13:37<@planetmaker>The effect of the bonus really depends. It is negligible for small maps and short distances. But so is the malus
13:38<@planetmaker>The effect is MUCH bigger for large maps, long delivery times
13:38<andythenorth>the malus is pretty effective
13:38<andythenorth>the bonus probably shows up a lot more for, e.g. ships
13:38<@planetmaker>for slow vehicles in particular
13:40<andythenorth>I have trains at 140mph over 256 tiles, at that speed for that distance, 185 or 65534, the difference to profit is basically a rounding error
13:40<andythenorth>kinda fine, but I should have tested this before designing horse
13:40<andythenorth>I only noticed it doesn't work because of note Snail made in French grf
13:40<@planetmaker>because it probably doesn't take more than 185/74 days to deliver the cargo
13:41<andythenorth>it's working correctly
13:41<andythenorth>I just mis-designed my grfs
13:41<andythenorth>and now have to decide how to fix that
13:42<@planetmaker>what is the intended behaviour?
13:42<Samu>sorry everyone, it was a false alarm
13:42<Samu>there is no issue
13:43<@planetmaker>independent of newgrf properties or stuff
13:43<Samu>confirmed with master
13:43<Samu>it was because MailAI had not started in 1.8.0 during my initial comparisons
13:43-!-Gabda [] has quit [Remote host closed the connection]
13:44<Samu>SCP takes time to read signs, and MailAI spams 4000+ 'T' signs everywhere, hence the delay
13:44<andythenorth>intended behaviour is to give a payment bonus to, e.g. refrigerated cars, luxury pax cars etc
13:44<DorpsGek_II>[OpenTTD/OpenTTD] glx22 opened pull request #7172: Fix #7171: incorrect modified status with determineversion.vbs
13:44<+glx>nielsm: ^^
13:45<@planetmaker>yes, you probably want to reduce the property for the non-luxury vehicles, I guess. If you target the 256 tiles... which is reasonable
13:45<@planetmaker>or you might add some scale depending on map size
13:45<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh approved pull request #7172: Fix #7171: incorrect modified status with determineversion.vbs
13:45<andythenorth>it requires a little more care to add a malus
13:45<andythenorth>but yes
13:45<andythenorth>bonus can't do much harm
13:46<andythenorth>the malus I'm testing, to have any impact, can make profits negative
13:46<andythenorth>if I do a safer malus, it has much less effect
13:47<+michi_cc>andythenorth: If your food as spoiled due to no refrigeration, a negative profit seems quite alright :)
13:52<+glx>oh it was working before
13:52<+glx>I think
13:52<andythenorth>green trains are 64 tile, yellow is 256
13:53<andythenorth>the EMU (most square one in each group) has malus 32 here
13:53<DorpsGek_II>[OpenTTD/OpenTTD] glx22 merged pull request #7172: Fix #7171: incorrect modified status with determineversion.vbs
13:53<DorpsGek_II>[OpenTTD/OpenTTD] glx22 closed issue #7171: determineversion.vbs never marks a version "clean"
13:53<andythenorth>the other two types are default, but the white one is faster
13:54<andythenorth>all have roughly same capacity, but different speeds and costs
13:56<@planetmaker>same route?
13:56<@planetmaker>you can basically only compare same route
13:57<andythenorth>same route
13:57<@planetmaker>hm... bad then :|
13:58<andythenorth>the colours are the same length route
13:58<andythenorth>there are 3 different lengths there though
13:58<andythenorth>64 / 128 /256
13:59<andythenorth>I think this _might_ be fine, it just smells wrong
13:59<@planetmaker>you see a 20% difference for the longer route
13:59<@planetmaker>actually. For *every* route length
14:00<LordAro>so... does anyone want to properly review #7170?
14:00<@planetmaker>comparing the white-head train to the one with a normal engine
14:00<@planetmaker>you want more than 20%?
14:01<@planetmaker>50% or 100% might be nicer
14:02<andythenorth>the white train is just faster :)
14:02<andythenorth>the cargo age period is default there, so that's just normal expected result
14:02<@planetmaker>yes. And that's what primarily affects cargo age stuff
14:03<andythenorth>the EMU with malus 32 is absolutely boss at 64 tiles
14:03<andythenorth>but drops off horribly somewhere after 64
14:03<@planetmaker>yep :)
14:03<@planetmaker>It absolutely serves its purpose then
14:06<andythenorth>this is with the EMU malus 64, which seems safer
14:06<andythenorth>and train capacity is normalised - they're all about equal pax capacity here
14:07<andythenorth>the EMU is still boss in red (16 tile)
14:07<andythenorth>and takes up a lot less space
14:07<andythenorth>at 32 tiles it's all equal
14:07<@peter1138>Hmm, working version:
14:07<@peter1138>Drawing tile 13ba, 13bb
14:07-!-Wormnest_ [~Wormnest@] has joined #openttd
14:07-!-Wormnest_ is "Wormnest" on #openttd
14:07<@peter1138>Non-working version:
14:07<@peter1138>Drawing tile 13bb, 13ba
14:09<nielsm> <- unreadable :D
14:09*nielsm should really get some food
14:09<@planetmaker>32 tile all equal is really short distance :)
14:10<andythenorth>I do a lot of those kind of distances
14:10<andythenorth>small maps
14:10<andythenorth>I usually play 256x256
14:10<andythenorth>I hate laying track :P
14:10<@peter1138>Ok but which is better, nielsm
14:10<+michi_cc>andythenorth: It's not really about the distance though, but the travel time. Early game with sub-100 mph trains and larger maps is the domain of ageing bonuses.
14:10<andythenorth>so that is my other concern about the malus :)
14:10<andythenorth>I have 6 generations of trains, with speed increments
14:11<andythenorth>if I malus the slow ones....might break
14:11<andythenorth>so I need to do it with care
14:11<andythenorth>(slow = early gen)
14:11<@planetmaker>my preferred size is like 256x1024 or so. Small. Yet place for some decent building and some long-haul stuff
14:11<andythenorth>ok so I need to swap all these trains for early ones
14:11<andythenorth>autoreplace time :P
14:11<@planetmaker>combining the local service with the long-distance one
14:11<andythenorth>did anyone finish train templates yet?
14:12<@peter1138>Hmm, so 479f13fc413 is at fault, because it assumes it can draw landscape tiles in any order.
14:12<@planetmaker>that's the 207-patch PR (which was redrawn for re-write)
14:12<+michi_cc>I guess you might want something along the lines of bonus at the start for mainline and slowly shifting to a malus for the local trains over time.
14:12<@planetmaker>well... as GH did it when he removed the first merge in it)
14:13<@peter1138>'Tweak ViewportAddLandscape so it no more relies on "go down as fast as possible"'
14:13<@peter1138>But I think this "go down" was necessary to get sprites in the right order.
14:14-!-Wormnest [~Wormnest@] has quit [Ping timeout: 480 seconds]
14:14<andythenorth>so I should test a bonus on same map with the slower train
14:15<andythenorth>I think it will be marginal effect still
14:15<andythenorth>for this default pax cargo
14:15<andythenorth>it won't take long enough to be delivered
14:15*peter1138 reverts and tests.
14:16<@peter1138>So yeah, fine without that commit.
14:16<@peter1138>Heh, JGR came to the same conclusion
14:18<andythenorth>this group liveries thing makes these tests so much easier :P
14:19<@peter1138>Yeah, reverting that fixes #7136 as well as #7133
14:19<@planetmaker>true that :) Easily discernible
14:22<DorpsGek_II>[OpenTTD/OpenTTD] PeterN opened pull request #7173: Revert 479f13fc41, Fix #7133, Fix #7136: "Codechange: Tweak ViewportAddLandscape so it no more relies on "go down as fast as possible" tile height model (Patch by adf88, #6583)"
14:23<LordAro>peter1138: how badly does it break viewport movement?
14:23<andythenorth>earlier gen
14:24<andythenorth>the malus here hurts the EMU more, it's only 60mph
14:24<andythenorth>so it's losing even on short routes
14:24<andythenorth>but the red group are all pretty even
14:24<andythenorth>and you get a lot more EMUs per tiles :P
14:29<DorpsGek_II>[OpenTTD/OpenTTD] michicc approved pull request #7173: Revert 479f13fc41, Fix #7133, Fix #7136: "Codechange: Tweak ViewportAddLandscape so it no more relies on "go down as fast as possible" tile height model (Patch by adf88, #6583)"
14:34<andythenorth>so for 'normal' freight wagons, cb 36 on refit, and malus if cargo is perishable? michi_cc :P
14:38<@peter1138>LordAro, doesn't affect it.
14:38-!-Wormnest_ [~Wormnest@] has quit [Ping timeout: 480 seconds]
14:38<@peter1138>LordAro, it's another "some unrelated changes" PR :/
14:38<LordAro>i see
14:39<@peter1138>If adf88 was around I'd check with him, but alas.
14:39<DorpsGek_II>[OpenTTD/OpenTTD] PeterN merged pull request #7173: Revert 479f13fc41, Fix #7133, Fix #7136: "Codechange: Tweak ViewportAddLandscape so it no more relies on "go down as fast as possible" tile height model (Patch by adf88, #6583)"
14:39<DorpsGek_II>[OpenTTD/OpenTTD] PeterN closed issue #7133: Graphics glitch with tunnels
14:39<DorpsGek_II>[OpenTTD/OpenTTD] PeterN closed issue #7136: Sprite sorting issue with FIRS
14:42<andythenorth>so for gen 1920s trains, the EMUs need a massive bonus, not a malus :P
14:44<nielsm>planetmaker: for just one new/fixed town cargo gen algorithm, whose main feature is that the amount of cargo generated is linear on house population, what names would you use in Settings?
14:48<+michi_cc>andythenorth: IMHO refrigerated and express should get a malus if transported in generic wagons, to increase the spread, the specialised wagons could get a bonus at the same time.
14:48<andythenorth>what could go wrong :)
14:48<andythenorth>apart from me forgetting to add the right cargos :)
14:48<@peter1138>nielsm, broken / improved ;p
14:48<nielsm>How much cargo houses in towns produce, relative to their size. The original method has quadratic growth, so a town with 2x the population produces 4x as many passengers. The new method keep the relationship linear, so double size causes double passenger production.
14:48<nielsm>Quadratic (original) / Linear
14:49<+michi_cc>No idea if you can test cargo classes in a varact2, but if yes that would be ideal I guess.
14:49<@peter1138>Too much / About right
14:49<andythenorth>@calc 100 * 185
14:49<@DorpsGek>andythenorth: 18500
14:49<@peter1138>So, er, if I cache the ship's previous position, I can get rid of the glitch.
14:50<andythenorth>maybe I should set up a 4096x4096 map
14:50<andythenorth>and build a diagonal train line across it
14:50<@planetmaker>hm, let's see, niels
14:51<@peter1138>And... I think it doesn't need to be saved, because if you are just loading a save, you won't see the previous location.
14:52<@planetmaker>got the PR number for me?
14:52<nielsm>planetmaker: haven't pushed latest changed yet
14:53*andythenorth requests an additional cargo bonus mechanic :P
14:55<@planetmaker>ok. Town cargo generation scaled by population
14:55<@planetmaker>but that's lengthy :)
14:56<nielsm>planetmaker: isn't the point of the help text to allow lengthy explanations?
14:56<@planetmaker>yes. That's why I was asking for the PR number to actually see the strings
14:57<@planetmaker>or can you paste the strings?
14:57<@planetmaker>that suffices
14:58<nielsm>I just did
15:01<@planetmaker>should we reference it really as 'old' and 'new' (even when it is)?
15:02<nielsm>well, it's sufficiently original that it exists in the game chris sawyer had published 25 years ago
15:03<nielsm>so I think it makes sense to point out which option to choose if you want to be closest to that
15:05*andythenorth wonders about just scaling cargo prop 12 (pricefactor), prefereably in low % increments / decrements
15:05<andythenorth>per vehicle
15:05<andythenorth>I think cargo_age_period addresses different concerns to mine
15:05<nielsm>and btw 5000 tile ticks is about 47 years
15:06<@planetmaker>it's a bit bike shedding: May I suggest that 'linear' is the "upper" value in the UI? From a sorting it feels above quadratic
15:07<@planetmaker> @ nielsm
15:07<@planetmaker>the {} adds line breaks
15:08-!-synchris [~synchris@] has quit [Quit: yeeha!]
15:09<nielsm>hm is there any good way to swap their position in the gui list without changing their numeric values? >_>
15:10<@planetmaker>I don't think so.
15:11<@planetmaker>Well, that's more bike shedding. If they are not swapped, swap the order of explanations in my version of the help text compared (like you had it before)
15:12<@planetmaker> like that
15:13<@planetmaker>I'm unsure to use twice and four times over 2x and 4x. But if using 2x and 4x, it should also be used 2x and 2x in the other string. Usually writing it is the way considered to look nicer
15:15<nielsm>I kind of want to add colour to the option names in the help text
15:16<nielsm>but nothing else does that
15:16<@planetmaker>ah, hm.
15:21<@planetmaker>what colour would make sense? Light blue as for 'Settings type' and 'Default value'?
15:21<nielsm>yeah that's my thought
15:22<@planetmaker>I see why and how that would make sense and the string better readable
15:25<@planetmaker> <-- does that actually work?
15:26<@peter1138>How do you handle making a default setting be different for old savegames?
15:27<frosch123>we have some code in afterload for that
15:27<frosch123>dynamic_engines is an example
15:28-!-sla_ro|master [] has quit []
15:45-!-Thedarkb2-T60 [] has quit [Remote host closed the connection]
15:56-!-Thedarkb-T60 [] has joined #openttd
15:56-!-Thedarkb-T60 is "realname" on #openttd #oolite
15:57<Samu>town shrink
15:59-!-gelignite [] has quit [Quit: Good fight, good night!]
15:59<nielsm> <-- yeah still seems to work
16:01<DorpsGek_II>[OpenTTD/OpenTTD] PeterN opened pull request #7174: Fix #7199: When rotating a ship, apply an additional offset to avoid movement glitch.
16:02-!-Thedarkb-T60 [] has quit [Read error: Connection reset by peer]
16:02-!-Thedarkb-T60 [] has joined #openttd
16:02-!-Thedarkb-T60 is "realname" on #openttd #oolite
16:02<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh updated pull request #6965: Add: Four alternative town cargo generation methods
16:03<nielsm>planetmaker: ^^
16:03<Samu>Text layout in engine preview dialogue windows was
16:03<Samu>..... was.....
16:04<DorpsGek_II>[OpenTTD/OpenTTD] glx22 commented on pull request #7174: Fix #7199: When rotating a ship, apply an additional offset to avoid movement glitch.
16:05<@peter1138>nielsm, is it still addin g4? Maybe it wants a title adjustment?
16:05<+michi_cc>peter1138: 7199??
16:05<@peter1138>I know right.
16:06<+glx>Samu: click on the + button and tell it there :)
16:06<@peter1138>Where did I get that from?
16:06<@peter1138>7119 :)
16:07<DorpsGek_II>[OpenTTD/OpenTTD] PeterN updated pull request #7174: Fix #7199: When rotating a ship, apply an additional offset to avoid movement glitch.
16:09<@peter1138>I'm aware it's some kinda of cheaty hack :/
16:15-!-drac_boy [~oftc-webi@] has joined #openttd
16:15-!-drac_boy is "OFTC WebIRC Client" on #openttd
16:15<drac_boy>hi there
16:20<Samu>was this forgotten?
16:20<Samu>i've been waiting :|
16:23<drac_boy>hi samu ... and hmm I dunno, never had any shipping problems I guess sorry
16:24<drac_boy>samu just curious but which ships do you like using? (grfwise)
16:24<Samu>default ships
16:25<@peter1138>Samu's an AI watching kinda guy
16:27<drac_boy>samu so vanilla .. mm fair enough :)
16:27<@planetmaker>nielsm, town_cmd.cpp: is that the correct random call which takes care of not desyncing?
16:27*drac_boy has always used newship.grf anyway (with newshipw.grf copy on hand for some other computers at times too)
16:28<nielsm>planetmaker: it's the same Random used earlier in the function
16:29<@planetmaker>ah, yes. Thus should be safe
16:31<drac_boy>anyway have to go sort out the supper food..but I'll try remember to check back at least one more time tho :)
16:31-!-drac_boy [~oftc-webi@] has left #openttd []
16:34<Samu>I wonder what have you done to fast forward, it's better, even with 15 AIs
16:34<Samu>i mean, 14
16:36<@planetmaker>nielsm, looks fine to me. The title / commit message still needs to be changed though to reflect the actual change. Luckily it will be squashed
16:39<nielsm>yeah I know, busy atm
16:42<Samu>peter1138: are you still interested in improving fps performance? I got a really mean savegame here
16:42<Samu>4 fps on my system with some stalls of 10 seconds from time to time
16:46<@peter1138>I can't do much with a screenshot.
16:47<Samu>ok, where to i put at?
16:47<@peter1138>No, just link a file :p
16:48<Samu>hmm where do I upload
16:48<nielsm>where did you get it from?
16:48<nielsm>your own game?
16:49<Samu>gonna post on the forum
16:49<Samu>actually, i think i got it posted there
16:49<Samu>let me find
16:49-!-tokai [] has joined #openttd
16:49-!-mode/#openttd [+v tokai] by ChanServ
16:49-!-tokai is "Christian Rosentreter" on +#openttd
16:51<Samu>nop, im making a new topic
16:51-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:54<Samu>sorry I'm kinda slow
16:55<Samu>just had a 21 second stall
16:56<andythenorth>meh, costs, aging, blah blah :D
16:56<@peter1138>Procrastination, eh?
16:56-!-tokai|noir [] has quit [Ping timeout: 480 seconds]
16:57<andythenorth>well more like, change, wait for compile, reload, run ffwd, decide it's all hopeless, repeat :D
16:57*andythenorth listening to some KLF thing on radio 4
16:57<@peter1138>Spend weeks fixing the build time.
16:57<andythenorth>rebuild the grf to make it fast to compile
16:57<@peter1138>Hmm, takes ages to load.
16:58<andythenorth>I've rebuilt grfs a few times to optimise compile :P
16:58<andythenorth>seems mad, but eh
16:58<@planetmaker>not worse than spending sunday nights on optimizing a 20-year-old computer game :P
17:01-!-Lejving [] has joined #openttd
17:01-!-Lejving is "realname" on @#openttdcoop.pz #mashinky #factoriocoop #/r/openttd #openttd
17:02<Samu>btw, in that savegames there is no more pool space for orders
17:02<Samu>AI's can't insert more orders :|
17:03<Samu>I reported it, but it was closed
17:04<@peter1138>Sheer number of vehicles.
17:05<@peter1138>Hmm, does 'Find missing content online' not work for AIs?
17:06<Samu>just download them all
17:09<Samu>there should be a way to see which AI is causing the most slowdowns
17:14<@planetmaker>good night
17:17<DorpsGek_II>[OpenTTD/OpenTTD] George-VB commented on issue #6907: Cargo capacity should be recalculated on TRIGGER_VEHICLE_NEW_LOAD
17:33<@peter1138>andythenorth, tell me what colours to remap and we'll do 3cc? :p
17:34<@peter1138>Hmm, game hung on exit :/
17:34<@peter1138>100% cpu.
17:35<@peter1138>Hurm, appears to be SDL waiting for PulseAudio. Huh./
17:35<andythenorth>peter1138: the purples 136-143, or 170-177 are useless for vehicles :)
17:36<@peter1138>Oh shit, you actually did :/
17:36<andythenorth>although I use them both in sprite generation, so I'd have to change ~everything :P
17:37<@peter1138>I was gonna say, what about the water colours, but you might use them on a ship.
17:37<@peter1138>Although, all that purple, is that the windows palette instead of dos?
17:38<andythenorth>no, it's DOS :)
17:38<andythenorth>can't choose blue or green, too hard to draw alongside 1CC and 2CC
17:39<@peter1138>What's 215+ then?
17:39<andythenorth>40-47 is also good contrast, and I also use those for sprite generation :P
17:39<andythenorth>215 are the magic weird pinks
17:39<@peter1138>Yeah, but if they're remapped to another range then they are no longer pink
17:39<andythenorth>there is that yes
17:39<@peter1138>You'd need to faff with palettes to edit I suppose.
17:39<andythenorth>yes, but that's possible
17:40<Samu>seems to be some valuator
17:40<Samu>by dictatorAI
17:41*andythenorth wonders what the pinks were ever for
17:41<@peter1138>nielsm, was it not possible to show performance data for AIs?
17:41-!-Progman [] has quit [Remote host closed the connection]
17:41<nielsm>peter1138, uh maybe...
17:41<nielsm>it'd need some rejiggering, maybe
17:42<@peter1138>Hmm, right, using the purples is awkward cos they move depending on palette :/
17:42<Samu>xtree is causing the huge stalls
17:43<Samu>but that's a visual studio file, not openttd
17:43<Samu>doing some delete and free
17:45-!-Flygon [] has joined #openttd
17:45-!-Flygon is "Flygon" on #openttd
17:48<@peter1138>Garry finds another bug in more cargos. This one looks ... tricky.
17:48<andythenorth>what about AA-B1 o_O
17:48<andythenorth>actually cargos more important :P
17:49<@peter1138>Yeah, crash bug.
17:49<@peter1138>Hmm, actually
17:49<@peter1138>is 8
17:49<@peter1138>I don't think 256 companies is a thing.
17:56<andythenorth>'not needed'
17:56<@peter1138>Hmm, CargoMonitorID is saved :/
17:56<@peter1138>So this is going to need some munging.
18:01<@peter1138>I don't know what this data is though.
18:03<Eddi|zuHause>i'm not sure why, but i have DBSetXL with 3 different MD5 and i don't know which one is the original one or what i could possibly have changed
18:04<Samu>that is for game scripts like busybee
18:05<Samu>yes, if I'm not mistaken
18:05<@peter1138>So I'm doing a savegame bump for data that nobody really uses? :p
18:06<Samu>it's to keep track of cargo a company has transported to some town or industry, isn't it?
18:06<@peter1138>I really don't know what it's for.
18:06<@peter1138>If it's GS related no wonder.
18:08<Samu>try busybee
18:08<Samu>let me see where that CargoMonitorID is at
18:09<Samu>yes, it is
18:09<Samu>BusyBee uses that
18:10<Samu>i even reported a bug
18:10<Samu>let me find
18:10<@peter1138>Oh really.
18:12<@peter1138>That predates 64 cargo types, so no.
18:12-!-keoz [~keikoz@2a01:e35:2fd5:51e0:d790:795d:2cc7:b53d] has quit [Ping timeout: 480 seconds]
18:13<Samu>well if you updated to 64 cargo types now, cargomonitor also needs updating
18:13<Samu>what was it before?
18:13<Samu>rip cargomonitor
18:13<@peter1138>Not really.
18:13<Samu>not sure how many types it can handle
18:13<@peter1138>Obviously nobody's been using it because this is the first report of this crash.
18:13<@peter1138>It can handle 32.
18:14<@peter1138>There's no silent working fortunately, as there's an assert.
18:14<@peter1138>I'd say nobody uses this feature then, but nightlies are pretty new.
18:14<Samu>busybee is used a lot on st2 servers
18:15<@peter1138>Yeah, but they won't be using nightlies with 64 cargo types!
18:16<@peter1138>That's what I meant by my comment, can't really judge the lack of reports.
18:16<@peter1138>So anyway, I have a fix, but I need to replicate the crash :/
18:16<andythenorth>samu likes testing :)
18:17<@peter1138>andythenorth, can i get a firs with > cargos?
18:17*andythenorth looking
18:17<andythenorth>we need fricking reference.grf
18:17<@peter1138>We have one, called FIRS.
18:17<@peter1138>It's too hard to actually play ;)
18:17-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:17<andythenorth>it's also triangular dependency :P
18:18<DorpsGek_II>[OpenTTD/OpenTTD] michicc approved pull request #7174: Fix #7119: When rotating a ship, apply an additional offset to avoid movement glitch.
18:18<andythenorth>peter1138: ^
18:18<andythenorth>it's a bit broken mind
18:19<andythenorth>I can't make a proper 64 cargo FIRS until nml is done :P
18:20<@peter1138>So... does it work?
18:20<@peter1138>It's just 16-in-out missing, right?
18:21<andythenorth>think so yes
18:21<Eddi|zuHause>peter1138: it's andy, it's fractally broken anyway :p
18:21<andythenorth>Eddi|zuHause make a reference.grf :P
18:21<andythenorth>we lack test cases
18:22<andythenorth>so we end up relying on patched community grfs
18:22<@peter1138>Hmm, doesn't even appear in my NewGRF list...
18:22<Eddi|zuHause>peter1138: there's a setting to hide duplicate/older versions of the same grfid
18:26<@peter1138>Well, failing to crash master :/
18:28-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
18:37<@peter1138>14 years, not crashing. Hmm.
18:37<@peter1138>Maybe I need his NewGRF.
18:39<andythenorth>I need my bed :|
18:39<andythenorth>nearly Monday
18:39<Samu>time for me to delete branches
18:39<andythenorth>also I haven't pulled upstream for like...a day
18:39<andythenorth>and there are so many changes
18:39<Samu>those that became part of the game
18:39<@peter1138>Yay, it crashed.
18:39<@peter1138> Message: Assertion failed at line 63 of /home/petern/Projects/OpenTTD/src/cargomonitor.h: ctype < (1 << CCB_CARGO_TYPE_LENGTH)
18:40<@peter1138>That's the one.
18:46<Samu>5 branches deleted
18:46<Samu>down to 27 :|
18:46<Samu>because... you close everything
18:46<Samu>that's why I have so many
18:48<LordAro>27 is a huge nuber
18:48<LordAro>don't fret too much
18:48<LordAro>or at all, really
18:49-!-Samu [] has quit [Quit: Page closed]
18:51-!-Samu [] has joined #openttd
18:51-!-Samu is "OFTC WebIRC Client" on #openttd
18:51<Eddi|zuHause>"Ihr Branch ist 33 Commits hinter 'origin/master', und kann vorgespult werden."
18:51-!-Samu [] has quit []
18:52-!-Samu is "OFTC WebIRC Client" on #openttd
18:52-!-Samu [] has joined #openttd
18:53<LordAro>also, "5 branches deleted" "down to 27" and "you close everything" really don't match at all
18:54<LordAro>some things aren't appropriate for OTTD
18:54<LordAro>there have been many, many rejected patches
18:54<LordAro>you are not special in that regard
18:55<Eddi|zuHause>did i get no mails today or is my mail program broken?
18:56<Eddi|zuHause>i think it was broken
18:56<@peter1138>Hmm, should I shrink the 8 bits for Company down to 4?
18:57<Eddi|zuHause>now i got 13 mails, 12 from openttd github
18:58<Eddi|zuHause>you need 5 bits if you also include town/none owner
18:58<@peter1138>It stores c->index, so cannot ever be greater than MAX_COMPANIES
18:58-!-Thedarkb-T60 [] has joined #openttd
18:58-!-Thedarkb-T60 is "realname" on #openttd #oolite
18:58<LordAro>peter1138: any particular reason?
18:59<LordAro>(to reduce it)
18:59<@peter1138>LordAro, because shrinking it from 8 to 7 seems a bit odd :p
18:59<@peter1138>LordAro, I need an extra bit for cargo!
18:59<@peter1138>32 -> 64 "lol"
18:59<Samu>towns can't transport cargo
18:59<Samu>i think 4 bits is enough
19:03<andythenorth>yeah bed
19:03-!-andythenorth [] has left #openttd []
19:04<Samu>looking at my cargomonitor fix
19:04<Samu>it's a svn patch
19:04<Samu>fails to patch :(
19:04<Samu>failed hunk
19:04<@peter1138>patch -p0
19:04<Samu>no, it's a conflict
19:05<@peter1138>Oh, well that's not a surprise.
19:05<Samu>conflicts with something in industry
19:05<Samu>gonna try resolve
19:09<Samu>wow... DeliverGoodsToIndustry has gone through massive changes
19:10<Samu>or maybe not, I'm blind
19:11<Samu>ind->last_cargo_accepted_at[cargo_index] = _date; this line didn't exist at the time I made the patch, must check what it does
19:12<DorpsGek_II>[OpenTTD/OpenTTD] PeterN opened pull request #7175: Fix #6803: CargoMonitorID bit packing updated to handle 64 cargo types.
19:14<Samu>6 months ago, heh
19:17<@peter1138>That's what I mean about a not very used feature :p
19:18<Samu> Date last_cargo_accepted_at[INDUSTRY_NUM_INPUTS]; ///< Last day each cargo type was accepted by this industry
19:19<Samu>okay, it's not related to cargo monitor
19:19<DorpsGek_II>[OpenTTD/OpenTTD] PeterN merged pull request #7174: Fix #7119: When rotating a ship, apply an additional offset to avoid movement glitch.
19:19<DorpsGek_II>[OpenTTD/OpenTTD] PeterN closed issue #7119: Ships turning around pixel alignment
19:22<nielsm>okay trying to add AI measurements to the framerate UI
19:22<@peter1138>Good luck :D
19:22<Samu>I will appreciate
19:22<Samu>if it's done per AI
19:22<nielsm>it is
19:22<Samu>wanna find out who's slowing down
19:22<nielsm>(and also doing gamescript)
19:23<Samu>much ty
19:24<Samu>hmm tortoise svn has a different line ending than github desktop
19:24<nielsm>pretty big :P
19:25<nielsm>I want to add the AI script name to each of them, and only include those that actually have active AI players on
19:25<@peter1138>Needs a scrollbar :p
19:26<Samu>looking good
19:26<@peter1138>Are they not counted under gameloop?
19:27<@peter1138>Cos I saw a very high gameloop but the ticks didn't add up
19:28<nielsm>they do count under game loop yes
19:39<Samu>Commit message, hmm okay
19:42<Samu>Fix #6633: Cargo monitor industry delivery now accounts for which IndustryID the cargo was delivered to
19:42<Samu>good english?
19:44<Samu>well, uh I'll post it
19:45<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened pull request #7176: Fix #6633: Cargo monitor industry delivery now accounts for which IndustryID the cargo was delivered to
20:01<Samu>Save Game
20:01<Samu>is that AI 1?
20:04<nielsm>uh how do I force recalculation of a window's size...
20:05<Samu>i dont know
20:05<Samu>I worked on ai gui and yet I don't know
20:06<Samu>didn't need to touch window resizes..
20:07<nielsm>maybe I should use the Matrix widget instead :s
20:10<nielsm>ah, w->ReInit() does it
20:13<+glx>yes ReInit() is the right way
20:19<Samu>tried to create a server game and it's hanging
20:20<Samu>gonna try again
20:21<Samu>it hangs right after generating world, when starting a server
20:22<Samu>gonna try release build
20:24-!-Thedarkb-X40 [] has joined #openttd
20:24-!-Thedarkb-X40 is "realname" on #openttd #/r/openttd #oolite
20:25<nielsm>hmm I'm getting hanging/infinite loop on "Allow multiple AIs to possibly start in the same tick"
20:26<Samu>oh no :|
20:26<Samu>because... ais dont start in that tick in multiplayer
20:26<nielsm>this is not multi
20:28<Samu>i dont have a problem in single player
20:28<Samu>gonna try multi
20:28<Samu>hands in multiplayer
20:28<Samu>bah... rip my patch
20:29<nielsm>ahh, hmm
20:29<nielsm>maybe because I was holding shift (to ffwd) while it tried to send commands to start AI's?
20:29<Samu>gonna investigate
20:29<nielsm>and for some reason that was interpreted as "check costs only"
20:30<nielsm>yep DoComandP sets estimate_only based on local shit key state
20:30<nielsm>so it's probably not safe to use there
20:31<nielsm>anyway, got names on:
20:31-!-Thedarkb-T60 [] has quit [Ping timeout: 480 seconds]
20:33<Samu>this returns true, but queues the command on the server
20:33<Samu>AI CheckStartNext can't be used in a loop then :(
20:33<Samu>can't start them all in the same tick, rip
20:34<nielsm>if you're holding the shift key while that DoCommandP is being called, it does nothing, except pop up an "Estimated cost: £0" box
20:34-!-Wormnest [~Wormnest@] has joined #openttd
20:34-!-Wormnest is "Wormnest" on #openttd
20:34<Samu>let me make sure my claim is correct
20:38<Samu>bah... confirmed NetworkSendCommand(tile, p1, p2, cmd & ~CMD_FLAGS_MASK, callback, text, _current_company);
20:38<Samu>command is queued
20:41<Samu>gonna see 1 tick is enough
20:41<Samu>at least they could start in 15 ticks
20:44<Samu>1 tick is sufficient
20:53<Samu>ok, i'm making a pr about it
21:01<DorpsGek_II>[OpenTTD/OpenTTD] SamuXarick opened pull request #7177: Fix: AI companies can't start in the same tick in multiplayer
21:02<Samu>so now they start in 15 ticks
21:03<DorpsGek_II>[OpenTTD/OpenTTD] nielsmh opened pull request #7178: Add AI and GS to framerate window
21:04-!-Wormnest [~Wormnest@] has quit [Quit: Leaving]
21:09-!-nielsm [] has quit [Ping timeout: 480 seconds]
21:15<Samu>already testing it, really great!
21:27<Samu>AroAI is in the red
21:28<Samu>SimpleAI is the one who was creating huge stalls
21:28<Samu>this is simply amazing!
21:28<Samu>i can get right to the problem
21:28<Samu>frame rate window, best window
22:17-!-Samu [] has quit [Quit: Page closed]
22:40-!-debdog [~debdog@2a00:79c0:610:300:7a24:afff:fe8a:d04d] has joined #openttd
22:40-!-debdog is "Wowbagger" on #openttd #bitlbee
22:43-!-D-HUND [~debdog@2a00:79c0:665:4c00:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:49-!-glx [] has quit []
22:53-!-Pikka [] has quit [Quit: Leaving]
23:19-!-Thedarkb-X40 [] has quit [Ping timeout: 480 seconds]
23:19-!-HerzogDeXtEr1 [] has quit [Read error: Connection reset by peer]
---Logclosed Mon Feb 04 00:00:49 2019