IRC logs for #openttd on OFTC at 2019-03-06
⏴ go to previous day
00:28:51 *** Thedarkb-X40 has joined #openttd
00:33:40 *** michi_cc has joined #openttd
00:33:40 *** ChanServ sets mode: +v michi_cc
00:36:29 *** michi_cc has joined #openttd
00:36:29 *** ChanServ sets mode: +v michi_cc
00:40:55 *** michi_cc has joined #openttd
00:40:55 *** ChanServ sets mode: +v michi_cc
00:48:49 *** supermop_work_ has quit IRC
00:55:32 <Eddi|zuHause> Beerbelott: that seems pretty pedantic... we're probably not striving for bitwise reproducible binaries :p
01:00:48 <milek7> there is global trend for that
01:38:54 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhpUQ
02:09:04 <Samu> on a 4096x4096 map, what takes most time to advance in 1 tick?
02:20:40 <peter1138> Try asking a sensible question.
02:22:08 <ST2> [01:20:40] <@peter1138> Try asking a sensible question. <<-- maybe asking Samu on what map size he thinks when he touches himself :D
02:23:21 <ST2> nevermind... was too sensible :D
02:25:00 <Eddi|zuHause> (i don't think i want to know)
02:28:00 <Beerbelott> Eddi|zuHause: pedantic?
02:28:18 <Beerbelott> sry just catching up w/ IRC
02:29:57 <Samu> was checking if it was trees or houses
02:30:26 <peter1138> There's too many unspecified variables, Samu.
02:30:53 <peter1138> You can generate a 4096x4096 map without trees, without houses, without industries, without vehicles...
02:33:47 <peter1138> Forget about %ages.
02:37:40 <Samu> house tiles waste most time with StationFinder
02:38:13 <peter1138> Try that with non-rect-catchment :-)
02:43:09 <Samu> Blitter_32bppOptimized is heavy
02:44:15 <Samu> let me try non-rect-catchment
02:51:37 <peter1138> On a fresh 4kx4k map, high towns, all cities * 10...
02:52:20 <peter1138> world ticks for master is 16ms/t, non-rect-catchment is 13ms/t
02:55:05 <peter1138> Not bad considering I was doing it for functionality, not performance.
03:06:07 *** supermop_Home has joined #openttd
03:06:57 <supermop_Home> whenever i use a real heightmap, it's always so noisey - particularly in valleys - that rivers cannot form
03:07:08 <supermop_Home> nor is there any room for rails
03:07:54 <supermop_Home> then i spend like 2 hours dendritically trying to fix all the valleys
03:08:57 <supermop_Home> there are always just tones of pot holes etc that block the valley floor.
03:09:19 <Samu> it took more time actually
03:09:30 <Samu> it was about 7%, raised to 9%
03:09:56 <supermop_Home> also all of my down town Honolulu is under water, and most of my pearl harbor is dry land
03:10:20 <Samu> those was the test non-rect-catchment results
03:10:30 <Samu> gotta go, cyas goodnight
03:18:26 <supermop_Home> i guess i can process these a bit in photoshop
03:19:46 <supermop_Home> on max height 40, the tallest mountain on Oahu is level 28, which seems pretty good
03:22:36 *** Supercheese has joined #openttd
03:33:26 *** Beerbelott has left #openttd
04:01:58 <supermop_Home> even reducing noise in photoshp doesn't help the noisiness issue
04:40:35 *** Supercheese has joined #openttd
04:52:45 *** tokai|noir has joined #openttd
04:52:45 *** ChanServ sets mode: +v tokai|noir
08:06:50 <peter1138> And that's the issue with only caring about %ages :)
08:17:02 <peter1138> Hmm, Wentbourne drops from 1.55ms/t to 1.30ms/t for world tricks. Not much but not slower.
08:20:36 <peter1138> Cargo handling increases from 1.75ms/t to 1.80ms/t though.
08:43:52 <peter1138> 2 days faster after over 40 minutes :p
09:06:27 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fhptO
09:10:50 *** Supercheese has joined #openttd
09:46:42 <DorpsGek_II> [OpenTTD/OpenTTD] rsn8887 opened issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhpqq
09:46:44 <DorpsGek_II> [OpenTTD/OpenTTD] GabdaZM commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhpqm
09:59:22 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhpqE
10:00:31 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhpqu
11:30:27 *** Gustavo6046 has joined #openttd
11:32:30 <peter1138> Hmm, why would vcenter not give me the option to migrate a VM's CPU & storage at the same time? :S
11:58:10 <DorpsGek_II> [OpenTTD/nml] PeterN commented on pull request #15: Industries: support 16 cargos in / 16 cargos out https://git.io/fhpY2
12:25:41 *** sla_ro|master has joined #openttd
12:27:13 <DorpsGek_II> [OpenTTD/nml] nielsmh commented on pull request #15: Industries: support 16 cargos in / 16 cargos out https://git.io/fhpOI
13:29:33 <DorpsGek_II> [OpenTTD/nml] planetmaker commented on pull request #15: Industries: support 16 cargos in / 16 cargos out https://git.io/fhp3X
14:31:30 *** Beerbelott has joined #openttd
14:42:42 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7235: Change: Non-rectangular sparse station catchment area https://git.io/fh5s1
14:57:38 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN updated pull request #7289: Add: Configurable ship curve penalties (YAPF) https://git.io/fhN1H
15:11:18 *** supermop_work has joined #openttd
15:13:33 *** supermop_work_ has joined #openttd
15:53:26 <Samu> arctic landscape, with 2 hovercrafts
15:53:42 <nielsm> the competition for 1.9.0 title screen is not over yet
15:55:11 <Samu> another guy who sets plane_crashes to none
15:57:26 <peter1138> Planecrashes on the intro screen provide a bit of interest ;p
16:02:55 <peter1138> Why do OpenGFX vehicle offsets suck? :S
16:14:19 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh updated pull request #7250: K-d tree data structure for spatial lookups https://git.io/fhd4b
16:18:32 <nielsm> oh no, next on the plate is nmlc :D
16:23:30 <nielsm> hmm if I make more commits to my indcargonum nml branch, then I should PR those to your 16-in-out branch peter1138, so they can end up in the main PR?
16:25:03 <peter1138> Is it the same branch?
16:25:30 *** sla_ro|master has joined #openttd
16:25:31 <peter1138> Or a load of new features?
16:25:46 <nielsm> same branch I think...
16:26:12 <peter1138> Then you can just push to 16-in-out, right?
16:26:42 <peter1138> I don't know what changes need to be made
16:50:00 <Samu> funny, this was about to be my entry to intro screen lol
16:56:46 *** Wormnest has joined #openttd
17:00:22 <peter1138> At a guess it's because aqueducts are a single segment, but this is the only place where ships have this.
17:00:35 <peter1138> Means the fix is the same as for the RV path cache.
17:00:54 <peter1138> Actually it might be simpler.
17:04:01 <planetmaker> do you know that it is somewhat pointless to compress savegames, Samu? :)
17:04:26 <planetmaker> default settings use a better compression than zip
17:04:49 <peter1138> You'd think he would because he spent time on it.
17:05:21 *** m3henry has joined #openttd
17:06:46 <nielsm> github won't let you upload .sav files so you have to pack it in an archive regardless
17:16:47 <Eddi|zuHause> how would i isolate my changes from nml hg and put them onto a github clone?
17:37:08 *** synchris has joined #openttd
17:45:59 *** Progman has joined #openttd
17:54:03 <Samu> is it intended that cactus trees create semi-grass-semi-desert in the adjacent tiles?
18:00:33 <nielsm> maybe related to that trees on coast is still water tile fix
18:17:02 <Eddi|zuHause> can't imagine how that happens
18:22:45 *** HerzogDeXtEr has joined #openttd
18:30:26 <DorpsGek_II> [OpenTTD/OpenTTD] rsn8887 commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhplx
18:33:45 <Samu> this night I had a dream about subsidies
18:33:57 <Samu> make them more appealing
18:36:46 <DorpsGek_II> [OpenTTD/OpenTTD] nielsmh commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhp8J
18:42:19 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhp8Y
18:42:41 <peter1138> Make them work with cargodist on :/
18:43:19 <nielsm> peter1138: iirc fluidsynth has some slightly annoying deps on glib and others
18:45:29 <peter1138> So? Getting that working on his/her port would be better than having unmaintained code on our side :)
18:45:41 <peter1138> "OpenTTD for Switch v1.0"
18:46:05 <peter1138> Using a different version number :/
18:47:11 <peter1138> nielsm, hmm, seems to be a lot of unrelated stuff in that PR?
18:47:14 <DorpsGek_II> [OpenTTD/OpenTTD] rsn8887 commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhp8C
18:48:04 <Gwyd> So I heard that OpenGFX is having a slow down in development. What actually needs doing?
18:48:31 <peter1138> Gwyd, it's not really.
18:48:45 <peter1138> OpenGFX is effectively *complete*
18:48:54 <peter1138> It doesn't need any changes.
18:49:07 <peter1138> So nobody is creating graphics for it.
18:49:30 <peter1138> The only time it needs an update it when OpenTTD adds some of its own new sprites.
18:49:51 <peter1138> This happens very rarely so you wouldn't notice.
18:50:04 <peter1138> Gwyd, yes it needs to be updated for this.
18:50:34 <DorpsGek_II> [OpenTTD/OpenTTD] rsn8887 commented on issue #7333: Libtimidity could be trivially enabled to play music through mixer.cpp https://git.io/fhp8R
18:50:37 <Gwyd> But things like trams have been around for a while
18:50:40 <peter1138> Gwyd, but to say opengfx is "ahving a slow down in development" is wrong, when it was not being developed because it was, up until now, complete.
18:51:35 <peter1138> It just needs someone to set up and create the additional sprites. And then that's it.
18:52:51 <milek7> hm, didn't nintendo had very restrictive NDA for switch sdk?
18:52:58 <milek7> or it is unofficial homebrew?
18:54:00 <peter1138> It's homebrew, yes.
18:55:30 <nielsm> incompatible branches more or less
18:55:49 <nielsm> my original indcargonum branch and your somewhat modified 16-in-out branch based on mine
18:55:52 <peter1138> Yeah, mine had been rebased to get rid of all the merges.
18:56:11 <peter1138> So the old syntax was not working, hence it is being removed?
18:56:21 <nielsm> so now I just checked out your branch anew and cherry picked the changes
18:56:26 <peter1138> Got to admit, I know nothing about nml :D
18:56:33 <peter1138> Yeah, that often works out easier.
18:56:36 <nielsm> planetmaker recommends removing old syntax
18:56:55 <peter1138> Breaking existing nml files. Hmm.
18:56:57 <nielsm> nml is apparently supposed to only support the latest and greatest of syntax
18:57:07 <nielsm> in both nfo/grf and its own language
18:57:13 <peter1138> That kinda makes sense.
18:57:20 <peter1138> Means you don't have to maintain old cruft around forever.
18:57:44 <nielsm> maybe someone needs to write a quick migration guide from the old syntax to new
18:58:20 <Eddi|zuHause> i recently made the old production callback syntax work, but it turned out andy had to completely change his GRF in other places as well
18:58:32 <Samu> mail subsidies when towns produce 1 mail a month... is there a way to fix this?
18:58:50 <Eddi|zuHause> so not sure how useful that part is
18:59:06 <peter1138> Samu, what needs fixing?
18:59:18 <Samu> not that it's wrong, but it's so unrewarding, it's not worth it
18:59:28 <peter1138> Isn't the point of a subsidy to support unprofitable routes?
18:59:30 <Samu> it could subsidize other stuff instead
18:59:44 <peter1138> I think 1 mail a month is a pretty good candidate
19:00:22 <peter1138> This is why I mentioned intra-town subsidies last week. They're generally less profit due to being short distance, so ideal for subsidies.
19:00:23 <nielsm> FindSubsidyTownCargoRoute() checks if (town_cargo_produced == 0) return false;
19:00:53 <peter1138> Eddi|zuHause, if the aim of nml is to only have 1 syntax, then fixing the old syntax is pointless.
19:01:30 <peter1138> Unless nmlc also has a "deprecated feature" migration plan
19:01:36 <Eddi|zuHause> but whether that was the aim was a bit unclear then
19:01:39 <peter1138> Like support the old method for 1 release with a warning.
19:02:00 <peter1138> But, if it keeps cruft around, meh.
19:02:23 <Eddi|zuHause> i haven't actually looked any deeper than that
19:02:45 <Eddi|zuHause> i just silenced andy's "i don't know how a parser works" complaints :p
19:04:36 <peter1138> This Switch port is fairly up to date, that's good.
19:05:20 <Samu> I'm thinking of SUBSIDY_CARGO_MIN_POPULATION
19:05:32 <Samu> for town cargoes other than passengers
19:05:42 <nielsm> Samu, consider that the town is offering a subsidy _because_ it's small
19:06:20 <Samu> small is fine, but 1 a month is really a waste
19:06:38 <nielsm> you're free to not take it
19:06:45 <peter1138> Gwyd, btw, not sure what trams have to do with it?
19:08:38 <peter1138> Hmm, hope I can fix this bug without a savegame bump.
19:10:23 <peter1138> Backporting makes that awkward.
19:11:49 *** supermop_work_ has quit IRC
19:13:14 <peter1138> Ok yeah, just don't consume the cache when on a bridge tile.
19:14:31 *** supermop_work has joined #openttd
19:15:43 *** supermop_work_ has joined #openttd
19:15:45 <peter1138> Hmm, not quite. It's not consumed already.
19:16:50 <peter1138> I should check RV bridges as well.
19:17:32 <Samu> I just realized SUBSIDY_CARGO_MIN_POPULATION isn't used anywhere
19:20:27 *** supermop_work__ has joined #openttd
19:20:55 *** andythenorth has joined #openttd
19:21:53 *** supermop_work___ has joined #openttd
19:22:38 *** supermop_work has joined #openttd
19:22:52 <peter1138> Hmm, okay, I need to pop one entry off the ship path cache.
19:23:24 <peter1138> I can either do that, or I can attempt to not add it in the first place. But to do that means the path finder needs to check all the tiles in the path to see if it's bridge tile.
19:23:58 <peter1138> Whereas if I pop it off while the ship is on the bridge, well, it already knows it's on the bridge and can just do it.
19:24:13 <peter1138> More efficient, but technically less correct? o_O
19:25:58 *** supermop_work____ has joined #openttd
19:26:06 <LordAro> i'd prefer more technically correct :p
19:26:14 <LordAro> can't make that much of a difference
19:26:15 <peter1138> It's still correct.
19:26:30 <peter1138> It means you need to check *every* tile in the path to see if it's bridge.
19:26:35 <peter1138> For every path find.
19:26:48 <peter1138> Vs... just popping off the stack if the ship is already on a bridge.
19:27:15 *** octernion has joined #openttd
19:27:34 *** supermop_work_ has quit IRC
19:27:41 <peter1138> Also it means you need to invalidate the path cache on old games because it's wrong.
19:28:29 *** supermop_work__ has quit IRC
19:29:54 *** supermop_work___ has quit IRC
19:30:31 <Eddi|zuHause> so, i found a glowing orb thing that i can't compress, and when i put it in the front of my large rover, the game crashes when i start the drill :/
19:33:42 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN opened pull request #7335: Fix #7334: Ship lost after crossing bridge due to path cache not being consumed while on final bridge end. https://git.io/fhp4Y
19:35:07 <Samu> cool, will test later, now I'm on subsidies
19:38:06 <Samu> testing subsidies scalled by map size, wht wwill happen
19:39:12 <Samu> the distance, and the number
19:45:42 <Samu> what would it be on 4096x4096 maps?
19:47:01 <glx> I think subsidies can be managed by GS
19:57:04 *** Arveen2 has joined #openttd
19:58:03 *** gelignite has joined #openttd
20:03:29 <Samu> well, acceptable i suppose
20:07:13 <Samu> there can be a max of 12 subsidies running at the same time, if I'm not wrong
20:26:04 <Samu> a maximum possible number of 204 subsidies in 4096x4096, what u think?
20:26:42 <nielsm> impossible to get an overview of
20:26:54 <nielsm> it would need a lot of UI improvements
20:27:25 *** frosch123 has joined #openttd
20:30:44 <peter1138> glx, GS can't fix subidies with cargodist.
20:31:24 <DorpsGek_II> [OpenTTD/OpenTTD] stale[bot] commented on issue #5208: Console: make console commands 'ls' and 'load' work with scenarios https://git.io/fhp4h
20:34:43 <nielsm> andythenorth: can you check if that PR still builds FIRS?
20:38:38 <peter1138> Urgh, that big bucket had some very stagnant water in it :/
20:41:05 <peter1138> Hmm, how do we do backports now?
20:41:26 <peter1138> I could make a PR again the 1.9 branch but...
20:41:34 <nielsm> make a PR against the 1.9 branch
20:41:47 <andythenorth> I haven't been keeping up
20:42:02 <nielsm> it doesn't fix the parser, it rips all the old syntax out :)
20:42:06 <peter1138> andythenorth, no, it's unnecessary.
20:43:31 <andythenorth> my advice, don't move FIRS to github in the midst of an nml change and a FIRS rewrite
20:43:50 <andythenorth> one thing at a time :P
20:43:59 <peter1138> Isn't it already moved?
20:44:09 <andythenorth> so the compile is all broken now
20:44:41 <andythenorth> this looking correct?
20:44:42 <andythenorth> (bin35) firs(master)$ nmlc --version
20:44:43 <andythenorth> 2019-03-06-g1f6c7725
20:44:50 <andythenorth> currently failing to compile
20:44:55 <andythenorth> just checking I have correct rev
20:45:03 <Wolf01> * andythenorth tests <- I just published the cloud app without a minimal testing, if it works it works
20:45:29 <andythenorth> not sure how hashes compare between forks :(
20:46:03 <andythenorth> nmlc ERROR: "generated/firs.nml", line 7342: Syntax error, unexpected token "waiting_cargo_1"
20:46:15 <andythenorth> not sure I have the correct version of PR here though
20:48:44 <nielsm> hmm those are supposed to be valid vars
20:49:20 <nielsm> although it looks like the new vars that cover all cargoes aren't implemented... maybe
20:49:55 <nielsm> those are separate from the non-parameterised vars
20:50:38 <nielsm> instead of waiting_cargo_1 try incoming_cargo_waiting('COAL')
20:50:48 <nielsm> I think the syntax should be
20:52:42 <andythenorth> does this break the old production cb?
20:53:05 <nielsm> the old produce syntax is no longer valid
20:53:13 <andythenorth> yes that makes sense
20:53:17 <andythenorth> but FIRS still declares it
20:53:21 <andythenorth> so it shouldn't compile
20:54:12 <nielsm> maybe it just reports the bad syntax in a bad way
20:55:24 <nielsm> yeah, it's expecting a "[" where it finds "waiting_cargo_1"
20:55:32 <nielsm> and the error reporting is bad :P
20:56:28 <nielsm> Samu yeah I would want to filter/sort that by cargo, source, destination, expiry date, and possibly more
20:56:39 <nielsm> when the count is that large
20:57:07 <andythenorth> I suppose detecting the old syntax requires parsing it?
20:57:16 <andythenorth> so issuing a deprecation warning is TMWFTLB?
20:59:15 <nielsm> it might be possible to get it to report better without doing that
20:59:33 <nielsm> but that requires learning more about the parser library than I'm prepared for at this time
21:00:40 <Samu> that's on a 4096x4096 sized map. The number of subsidies is scaled by map
21:01:09 <Samu> do you think it's worth doing a filter?
21:03:52 <Samu> i guess it wouldn't hurt
21:06:17 <Samu> simpleai is an ai that enjoys subsidies, let's test it
21:18:03 <peter1138> Hmm, should towns build bridges over incompatible road types?
21:19:18 <planetmaker> nielsm, "traditionally" nml indeed only supported the latest grf versions. You cannot use it to write old grfs. For existing code it is easy to maintain a legacy branch so that a NeWGRF with old production code can still use NML. Just not NML master
21:19:38 <planetmaker> We did that as well when we changed callback syntax
21:19:48 <Eddi|zuHause> good error reporting in a compiler is difficult...
21:19:49 <peter1138> I think it makes sense not to maintain old parts.
21:20:33 <planetmaker> Yes... it otherwise easily gains ... crust and stains and becomes even more a burden to maintain
21:21:08 <planetmaker> and backporting non-breaking changes and additions to a legacy branch for some time is easy.
21:21:33 <planetmaker> just cherry-pick and be done and release both
21:22:32 <Eddi|zuHause> dunno, difficult to judge beforehand which one is easier to maintain
21:22:34 <DorpsGek_II> [OpenTTD/OpenTTD] M3Henry updated pull request #7165: [core] Implement SmallVector using std::vector https://git.io/fhSz0
21:22:39 <andythenorth> so how do we handle the failure demand?
21:23:11 <peter1138> Document how to update your code.
21:23:29 <Eddi|zuHause> 1) migration guide, 2) useful error message
21:23:38 <nielsm> I guess the old waiting_cargo_[123] etc. variables should also be removed
21:23:42 <Eddi|zuHause> 2) error message pointing to the migration guide
21:24:08 <peter1138> Whoops, my game crashed
21:24:25 <peter1138> Boo, wasn't a debug build, nor in a debugger :(
21:25:02 <planetmaker> what happened to newgrf wiki? It's awefully slow... with the tls handshake with aws
21:25:57 <Eddi|zuHause> getting the handshake stall as well
21:26:48 <andythenorth> Eddi|zuHause: yeah (2) was really the point of my question
21:26:54 <Eddi|zuHause> planetmaker: yes, so we need a changes 0.4 to 0.5
21:27:01 <andythenorth> and the 0.3 migration guide is pretty good eh
21:27:20 <andythenorth> are 16-cargo houses done?
21:27:20 <planetmaker> and like that is what I envision for 0.4 to 0.5 as well
21:27:34 <andythenorth> nml does not have any hygiene about tickets right now
21:27:39 <Eddi|zuHause> planetmaker: it's a good start, but the error message really needs refining
21:27:46 <andythenorth> we didn't add any because there was an idea to migrate old devzone issues
21:27:49 <planetmaker> and that makes it easy to just do one thing in NML and continue cleanly
21:27:50 <andythenorth> so we'd get ID colissions
21:28:06 <planetmaker> andythenorth, you know how to migrate them? :|
21:28:31 <andythenorth> the issues are a hygiene factor
21:28:45 <Eddi|zuHause> so it would be a bad idea to open a PR against NML?
21:28:49 <andythenorth> I was going to manually copy-paste, but frosch pointed out we need a process to migrate all
21:28:54 <andythenorth> Eddi|zuHause: I've opened one
21:29:07 <Eddi|zuHause> PRs and tickets share a number space
21:29:41 <planetmaker> hm, there's actually... migration scripts in the internet
21:30:15 <planetmaker> on my own nml copy first
21:30:24 <nielsm> hmm just noticed there aren't any replacements for variables production_rate_[12]
21:31:19 <DorpsGek_II> [OpenTTD/OpenTTD] stale[bot] commented on issue #6381: Game Script: method to change company rating in town https://git.io/fhpRE
21:31:20 <nielsm> and transported_last_month_pct_[12] aren't remade either, but that can be calculated
21:33:04 <frosch123> planetmaker: i can give you the scripts that i have
21:33:14 <frosch123> anyway, i never wanted to keep the issue numbers
21:33:18 <planetmaker> oh, you have one already? :)
21:33:26 <planetmaker> no, the issue numbers... don't need to be kept
21:33:43 <frosch123> devzone numbered issues over all projects, so creating 8k issues for nml with 7.9k dummies is silly
21:33:49 <planetmaker> though we did with openttd... issue numbers in redmine are global... so... 6k issues or so is stupid
21:34:04 <andythenorth> ok so we'd need to renumber anyway
21:36:10 <planetmaker> shouldn't that be more issues?
21:36:36 <frosch123> i only did 2 for testing different layouts
21:36:49 <frosch123> but apparently there is also an api limit, so you cannot create all at once
21:37:42 <DorpsGek_II> [OpenTTD/nml] nielsmh commented on pull request #15: Industries: support 16 cargos in / 16 cargos out https://git.io/fhpRK
21:38:16 <Eddi|zuHause> the "Type:" thing sounds like nonsense
21:38:54 <Eddi|zuHause> the [901] needs some context
21:40:08 <Eddi|zuHause> not sure it needs to be in the title at all
21:41:31 *** m3henry has joined #openttd
21:42:02 <Eddi|zuHause> also, in OpenTTD migration, the posts were made using quotes (">"), which may make it clearer that the post was not written by the poster
21:42:48 <peter1138> Bah, the crash save didn't crash :p
21:43:07 <Eddi|zuHause> also, IIRC that import script kept the post dates.
21:44:42 <planetmaker> but frosch's link looks more elaborate.
21:45:57 <peter1138> nielsm, these variables are already replaced, yes?
21:46:30 <frosch123> i can send you two modified files for layout adjustments
21:46:40 <frosch123> and the already completed export from redmin
21:49:16 <peter1138> ileType GetTileType(TileIndex): Assertion `tile < MapSize()' failed.
21:51:38 *** Supercheese has joined #openttd
21:52:26 *** agentw4b has joined #openttd
21:56:10 <supermop_work____> hi andythenorth
21:57:27 <peter1138> I'm going to assume they're correct.
21:58:41 <nielsm> I have very little basis for testing and checking this
21:59:19 *** Thedarkb-T60 has joined #openttd
22:03:30 <peter1138> Well it's a PR into a PR so no biggie.
22:04:10 <Samu> subsidies just next door, what do you think of these?
22:04:31 <Samu> transporting like 10-15 tiles away
22:04:44 <peter1138> Long distance doesn't need subsidizing.
22:05:07 <Samu> about long distance ones, I was thinking perhaps a bit more time
22:05:22 <Samu> 12 months is a little bit short
22:05:33 <Samu> if it can now be at most 1120 tiles away
22:06:21 <peter1138> Subsidy max distance is 70 tiles.
22:06:35 <peter1138> There's no need for a subsidy to be 1120 tiles away.
22:06:36 <Samu> Im modifying it to scale by map size
22:06:49 <peter1138> I think you are confusing what subsidies are.
22:07:02 <Samu> return (DistanceManhattan(tile_src, tile_dst) <= max(SUBSIDY_MAX_DISTANCE, ScaleByMapSize1D(SUBSIDY_MAX_DISTANCE)));
22:07:08 <peter1138> nrt-block passed CI, shall we merge it? :p
22:08:45 <Samu> another thing I thought would be, transport type
22:09:16 <Samu> transport passengers from here to there, using transport type rail, road, air, water
22:22:47 <planetmaker> what level of access do I have to grant a github access token in order to create issues?
22:23:38 <andythenorth> peter1138: 1.10 :P
22:24:14 <andythenorth> is 1.9 now branched away from master?
22:24:36 <andythenorth> NRT -> nightlies then
22:24:39 <andythenorth> needs nml support
22:24:55 <Samu> well, they talk about airports, so i don't consider that short distances
22:25:13 <Samu> that article is too much real world
22:25:43 <andythenorth> that repo needs work
22:25:50 <peter1138> Yeah, those flags don't exist.
22:25:53 <andythenorth> it's an old import of the hg repo by me
22:26:02 <andythenorth> it's not a fork of Openttd/nml
22:26:20 <andythenorth> peter1138: that's the wrong branch no?
22:26:29 <andythenorth> or I made a git error :P
22:27:02 <peter1138> Oh, no those flags do exist.
22:27:14 <peter1138> ALLOW_HOUSES is not correct
22:27:20 <andythenorth> wtf, that's a month ago, I have no recollection of that at all
22:27:27 <peter1138> No, it's 13 months ago.
22:27:39 <peter1138> It's NO_HOUSES for both road and tram types.
22:27:59 <andythenorth> anyway, it's a crappy commit history
22:28:05 <andythenorth> but it did appear to work and make grfs
22:28:21 <peter1138> People are probably using it.
22:28:37 <peter1138> Anyway, yes, 1.9 was branched.
22:28:55 <peter1138> Btw, 1.9 was branched, in case you didn't know.
22:29:20 <peter1138> ROTSG_reserved1, ///< Placeholder, if we need specific tunnel sprites.
22:29:28 <peter1138> ROTSG_reserved1, ///< Placeholder, if we need specific tunnel sprites.
22:29:38 <peter1138> These can be implemented after though.
22:30:28 <peter1138> Hmm, there's a SmallVector in there...
22:31:04 <peter1138> Good idea to replace that before it's merged
22:32:13 <LordAro> m3henry: do you have a highlight on smallvector now? :p
22:32:28 <peter1138> Urgh, there's no contains for std::vector is there...
22:32:34 <LordAro> depends on irc client, but usually
22:34:58 <nielsm> nope, std::vector doesn't have contains, you have to find() and compare to end()
22:36:30 <m3henry> I'm glad flat_map and flat_set are in for C++20
22:36:48 <nielsm> ah, they're adding "stupid" maps/sets
22:37:18 <m3henry> But it's good to keep in mind
22:38:03 <peter1138> Yeah, they'd be useful for us.
22:39:25 <m3henry> I was thinking of replacing SmallMap with a container adapter, but now it makes more sense to use std::map, and then switch to std::flat_map when that becomes available
22:39:53 <LordAro> what are the differences?
22:40:38 <m3henry> std::map: tree structure vs std::flat_map: array structure
22:41:29 <nielsm> std::map will typically cause lots of small allocations on the heap, one for each element, while std::flat_map will have a single big allocation
22:41:31 <m3henry> depending on the data usage, one will be faster
22:42:08 <nielsm> std::map has asymptotically better performance, but in practice for small-ish amounts of data a flat_map will often perform better because of CPU cache
22:42:44 <frosch123> LordAro: people say, for performance always use std::vector
22:44:48 <m3henry> I do wonder if the llvm::SmallVector and llvm::TinyPtrVector might be useful
22:51:09 <frosch123> m3henry: where did you read that flap_map is in c++20? or did you only express your hope?
22:56:11 <DorpsGek_II> [OpenTTD/OpenTTD] PeterN commented on pull request #7000: Some NewGRF variables concerning railtypes https://git.io/fhpEB
22:57:16 <peter1138> Interesting, because nrt is andythenorth's PR, I can approve it...
22:57:33 <andythenorth> but are you gonna?
22:57:43 <andythenorth> we used to do much worse things?
22:57:52 <peter1138> We did used to, yes.
22:57:56 <andythenorth> but what will the shareholders say!
22:58:28 <peter1138> Probably should squash a bit more.
23:04:19 <Samu> completing a subsidy 1120 tiles away in 12 months... only possible with aircraft
23:04:31 <Samu> maybe this is not necessary
23:05:03 <Samu> was thinking of scalling months
23:08:35 * m3henry wonders how far from approval #7165 is
23:21:12 <Eddi|zuHause> only significant update since then was for python3 support
23:21:50 <Eddi|zuHause> and the devzone builds haven't worked for years
23:37:51 <Beerbelott> Man, that was a hell of a rebasing...
23:38:39 <Beerbelott> preprocessor calls removed in a section I edited... ofc diff was lost
23:40:15 <Eddi|zuHause> how do you lose a diff?
23:42:43 <Beerbelott> it was inserting #if !defined(_WIN32) at the wrong place since that section I edited in one of my commits
23:43:01 <Beerbelott> and it still had the AMIGA & stuff preprocessor call in there
23:44:07 <Beerbelott> that's because it was removing the content of trunk to put the content of the commit on top of it in the proposed changes
23:44:39 <Beerbelott> anyway user error in the end, I suppose
23:47:56 *** Smedles has joined #openttd
continue to next day ⏵