IRC logs for #openttd on OFTC at 2019-05-19
⏴ go to previous day
00:00:52 <arikover> Eddi|zuHause: I can make them look serious enough...
00:03:13 <arikover> Eddi|zuHause: ...but probably a bad idea, yes.
00:34:47 <Wolf01> Plate wagon might be an open one with little sides, flat cars are different kind of open wagons with flat surfaces, even a car transporter, but only he might know what he meant
00:51:55 *** gnu_jj_ has joined #openttd
00:52:55 *** gnu_jj__ has joined #openttd
01:28:56 *** SimYouLater has joined #openttd
02:06:44 *** kiwitree has joined #openttd
02:09:09 <Eddi|zuHause> usually the low sides can be flipped so it's completely flat
02:45:23 *** ircer[m] has joined #openttd
02:50:13 *** josef[m] has joined #openttd
03:00:46 *** snail_UES_ has joined #openttd
03:27:33 *** Wormnest has joined #openttd
03:39:03 *** Supercheese has joined #openttd
06:30:55 <Corns[m]> Patch idea: during world gen, roads connect towns, like in simutrans
06:34:24 <Corns[m]> Q: which files are responsible for handling world gen?
06:37:29 *** HerzogDeXtEr has joined #openttd
08:06:13 *** tokai|noir has joined #openttd
08:06:13 *** ChanServ sets mode: +v tokai|noir
08:09:20 *** Supercheese has joined #openttd
08:25:32 *** sla_ro|master has joined #openttd
09:03:27 *** andythenorth has joined #openttd
09:57:14 *** gelignite has joined #openttd
10:16:02 *** andythenorth has joined #openttd
10:19:22 * andythenorth wonders about vehicles setting a multiplier to prop 12
10:19:57 <andythenorth> maybe that has horrible performance though
10:41:54 *** Progman has joined #openttd
11:16:10 <andythenorth> I love seeing newgrfs working in OpenTTD :D
11:16:34 <andythenorth> I know I complain a lot, but making things for OpenTTD is really fun
11:49:19 *** frosch123 has joined #openttd
11:54:40 *** andythenorth_ has joined #openttd
12:09:02 *** andythenorth_ has joined #openttd
12:10:15 <andythenorth_> maybe a compile time flag to drop all cargo sprites etc in Horse?
12:10:43 <andythenorth_> might save 10 seconds or so
12:18:28 *** andythenorth has joined #openttd
12:24:36 *** andythenorth_ has joined #openttd
12:31:51 <andythenorth_> split Horse into separate grfs?
12:32:09 <andythenorth_> engines grf, wagons grf, etc
12:36:47 <frosch123> debug and release builds?
12:43:03 <andythenorth_> frosch maybe yes
12:43:30 <andythenorth_> shame we can’t nest grfs
12:48:33 <andythenorth_> diff the nml, use some cached nfo & grfcodec if the nml is unchanged
12:49:31 <frosch123> grfcoded has no spritecache
12:49:43 <frosch123> so, encoding will be slower
12:49:58 <frosch123> you are probably better off to generate multiple nml and grf files
12:53:05 <Eddi|zuHause> ... didn't he already have provisions for "only make one vehicle"?
13:05:52 *** andythenorth_ has joined #openttd
13:07:27 *** andythenorth has joined #openttd
13:07:59 <andythenorth> frosch123: the grfcodec encode of Horse is about 3 seconds
13:08:21 <andythenorth> although that's based on a -d decode, with only 9 spritesheets
13:09:15 <Corns[m]> Grfs can have dependencies, right?
13:12:39 <frosch123> andythenorth: you can also disable cropping
13:12:56 <frosch123> but with same settings, nml encoding should not be slower than grfcodec
13:13:46 <andythenorth> the nmlc encoding is now fast, because I no longer throw away the sprite cache
13:13:55 <andythenorth> but the parse and preprocessing steps are slow
13:14:28 <andythenorth> the specific case I think will be faster with grfcode is changes to only realsprites
13:15:13 * andythenorth tries to remember how to grfcodec :P
13:17:28 <andythenorth> 4s or so for grfcodec
13:17:45 <andythenorth> it's expecting a 'sprites' path though, so I'd have to refactor the generated directory structure
13:18:17 <andythenorth> iron-horse.nml -> nmlc -> grf ~30s average
13:18:29 <andythenorth> iron-horse.nfo -> grfcodec -> grf 5s average
13:19:05 <andythenorth> so if iron-horse.nml diffs as unchanged, I might as well branch to grfcodec
13:19:18 <Eddi|zuHause> if you were using makefile, inserting grfcodec would be quite simple
13:19:56 <Eddi|zuHause> add switch to nmlc to generate nfo instead of grf
13:20:04 <andythenorth> trying to work out the overhead
13:20:14 <Eddi|zuHause> add entry to make grf from nfo via grfcodec
13:20:19 <andythenorth> in cases where the nml file *has* changed, this adds a 5 second overhead to every compile
13:20:30 <Eddi|zuHause> remove sprites as dependency from the nmlc stage, and add them to the grfcodec stage
13:20:41 <andythenorth> so working with e.g. vehicle properties will be much slower
13:20:50 <andythenorth> but drawing pixels will be much faster
13:21:15 <Eddi|zuHause> overhead will be less than that
13:21:25 <Eddi|zuHause> because nmlc does not process sprites anymore
13:21:35 <Eddi|zuHause> so should be quicker
13:22:13 <andythenorth> I'm not convinced by that yet
13:24:36 <andythenorth> ok it's marginal
13:24:49 <andythenorth> averaging 33 seconds for nmlc -> grf
13:24:56 <andythenorth> averaging 31 seconds for nmlc -> nfo
13:25:05 <andythenorth> fully primed nml cache
13:25:48 <andythenorth> 25s gain for changes that only touch realsprites, vs. 2s loss in cases where props etc have changed
13:31:36 <andythenorth> frosch123: presuming nmlc builds some tree in memory, is there any mileage in pickling that, and passing it back to nmlc if they nml is unchanged?
13:31:59 <andythenorth> pickle is slow, but eh
13:35:27 <frosch123> i have some old numbers, when i tried
13:35:39 <frosch123> writing the cache is +50% to parsing time
13:35:56 <frosch123> readnig the cache is 20% of parsing time
13:36:21 <frosch123> cache file size is 7x to 10x the nml source size
13:38:20 <andythenorth> tradeoff doesn't look winning
13:38:25 <frosch123> overall you needed to compile 5 times with valid cache to make up the time for creating the cache
13:51:49 <andythenorth> dropping the cargo graphics
13:52:13 <andythenorth> cuts the nmlc time from about 30 seconds to about 10 seconds
13:52:25 <andythenorth> and the grfcodec time from about 5s to 0.5s
14:01:38 <andythenorth> so I can maybe knock up to 40s off a 70s compile
14:07:04 <andythenorth> sys.argv is a bit limited eh
14:09:11 <_dp_> hi, what is the max amount of layouts industry can have? 256?
14:11:14 <andythenorth> Eddi|zuHause: optional args aren't trivial with sys.argv afaict
14:11:22 <andythenorth> doesn't matter, it works
14:11:36 <Eddi|zuHause> andythenorth: you'd usually use a configparser?
14:12:01 <andythenorth> what I have is really rudimentary
14:12:10 <Eddi|zuHause> also, if you're using make, then maybe env would be better than argv?
14:12:58 <Eddi|zuHause> make SKIP_CARGO=true
14:13:32 <Eddi|zuHause> and then in python check whether env contains SKIP_CARGO?
14:13:41 <andythenorth> that might be better
14:13:51 <andythenorth> I'll make it work, and then link to the comimt
14:14:01 <andythenorth> the args have been too crude for years
14:19:48 <andythenorth> well that saves about 55% in cases where it can be used
14:21:00 <andythenorth> Eddi|zuHause: ^ that includes the crap argv parsing I'm doing
14:21:19 <_dp_> there is argparse for any real applications
14:21:20 <andythenorth> it was 'good enough' about 8 years ago :P
14:21:26 <_dp_> argv is just for debugging
14:22:02 <andythenorth> might be better to switch to env, I never figured out how to pass args when running a specific python script
14:22:21 * andythenorth happy to take pull requests :P
14:23:44 <Eddi|zuHause> i haven't done configparser in a while
14:24:20 <andythenorth> now let's combine that with grfcodec
14:24:29 * andythenorth will inevitably have make questions :P
14:52:33 *** arikover has joined #openttd
14:56:21 <nakki> reading the reviews, apparently the thing they're giving away for free now isn't the full license
14:57:01 <andythenorth> Eddi|zuHause: make a game!
14:58:13 <andythenorth> Eddi|zuHause: L81 or so, nmlc runs always, how do I stop that? :)
14:58:30 <andythenorth> oh that's the wrong rev, silly redmine
14:59:01 <Eddi|zuHause> andythenorth: remove "$(GRAPHICS_DIR)", put that on the grfcodec part?
15:00:48 <andythenorth> I gave you the wrong url the first time
15:01:02 <Eddi|zuHause> remove it from the nmlc part
15:01:10 <Eddi|zuHause> have it only on the grfcodec part
15:02:08 <andythenorth> hmm that doesn't work yet
15:02:30 <andythenorth> probably the docs
15:03:07 <Eddi|zuHause> remove the docs there as well
15:03:34 <Eddi|zuHause> that dependency seems to be nonsense
15:05:56 <andythenorth> wouldn't surprise me
15:06:18 <andythenorth> anyway, that's a 10 second compile if I'm only changing sprites, and I drop all cargo sprites
15:06:45 <andythenorth> much better payoff than me trying to rewrite nmlc myself :(
15:08:06 <andythenorth> now the docs render after the nml
15:08:12 * andythenorth will come back to that
15:08:45 <andythenorth> 13 seconds if the cargo sprites are enabled
15:09:23 <andythenorth> Eddi|zuHause: so the docs...what should I be doing?
15:09:30 <andythenorth> I need the docs built early in the compile
15:09:51 <Eddi|zuHause> why would anything depend on the docs?
15:10:00 <andythenorth> because the compile is so slow that I can often open the docs, check the result, and ctrl-c the compile if the result is bad
15:10:29 <andythenorth> but if the result is good, I let the compile continue
15:10:55 <Eddi|zuHause> if they're independent tasks, make -j12 should figure it out
15:13:16 <andythenorth> both the docs and the grf are co-dependent on the graphics,
15:13:26 <andythenorth> but docs are parallel to grf
15:13:35 <andythenorth> how do I express that in make rules
15:16:19 <Eddi|zuHause> if they're dependent, you put it in the dependency, if they're not, you leave it out
15:17:57 <andythenorth> wait, so I already have 'default: html_docs grf'
15:19:43 <andythenorth> hmm doesn't trigger if graphics change
15:20:31 <andythenorth> I don't hate make, I just don't understand it
15:24:48 <andythenorth> what's the .PHONY doing in this case?
15:38:51 <arikover> andythenorth: Hello. Sorry to bother again, I'm translating Iron Horse and need some insights on some new freight cars.
15:39:18 <andythenorth> tell me, I'll find pictures
15:39:24 <arikover> andythenorth: So: What is the difference between a plate car and a flatcar?
15:40:18 <FLHerne> andythenorth: I hear you should be using Meson now :P
15:40:23 <arikover> andythenorth: Someone(s) already found pictures for this one yesterday, but I don't understand exactly the difference: are the sides not removable on the plate cars?
15:40:51 <andythenorth> some are, some aren't
15:41:02 <andythenorth> I considered using 'low-side open car'
15:41:41 <andythenorth> 'plate car' is a very specific UK use, not used anywhere else I could find
15:42:18 <arikover> andythenorth: "Low-side open car" <- maybe I could translate that instead? Yeah, I couldn't find any references of plate cars outside UK.
15:42:50 <andythenorth> Europe calls them flat wagons, because the sides are removable
15:42:56 <andythenorth> and the US doesn't seem to have them
15:44:46 <arikover> I could find something approaching, like "low-side open car" then. OK.
15:45:03 <arikover> andythenorth: ...and the second one: what is the difference between an aggregate hopper and a standard hopper?
15:45:46 <andythenorth> I've turned aggregate hoppers off in current Iron Horse
15:45:53 <arikover> andythenorth: Is it supposed to transport special cargo (like not-coal)?
15:45:54 <andythenorth> I'm not convinced about the names
15:46:45 <arikover> andythenorth: But you already drew the sprites?
15:46:52 <andythenorth> yeah, but I've removed them
15:47:14 <andythenorth> they're just graphical options, but the names are confusing
15:47:48 <andythenorth> I want to put them back
15:47:54 <andythenorth> but I don't know how to name them
15:48:35 <arikover> andythenorth: Do you have any photos I could base myself on?
15:49:38 <andythenorth> one type is silver, and used primarily for coal
15:49:48 <andythenorth> the other type is company colour, and used primarily for stone, sand etc
15:50:22 <andythenorth> there are other differences in real life, but too boring to feature in game
15:51:10 <arikover> What are they? (it could maybe help for the translation)
15:51:35 <FLHerne> arikover: From a real-life perspective, rock aggregates and ores are /much/ denser than coal
15:52:46 <FLHerne> So a coal hopper filled to the brim with rock would be *far* too heavy
15:53:02 <andythenorth> also the doors on coal hoppers are open / closed
15:53:05 <andythenorth> they flood unload
15:53:22 <andythenorth> the doors on agg hoppers have variable opening, for controlled rate
15:53:56 <FLHerne> In the UK, since coal traffic fell off a cliff several companies have been converting coal hoppers to carry aggregate by essentially cutting out 1/3 of the length
15:59:51 <arikover> FLHerne andythenorth: So the aggregate hopper are designed to carry denser loads (shorter design), and have a more subtle unloading process (in a -rough- nutshell)?
16:00:32 <arikover> Okay. Thank you very much for your answsers!
16:00:47 <andythenorth> if you come up with a name let me know :P
16:01:09 <andythenorth> I have turned them off until I'm satisfied with the name
16:01:29 <FLHerne> I don't see what's wrong with "aggregate hopper" tbh
16:01:36 <andythenorth> or maybe I should name 'hopper' as 'coal hopper' even though it refits other things
16:01:38 <FLHerne> They're hoppers for aggregate
16:01:52 <andythenorth> they do refit coal and stuff, because no point limiting gameplay
16:02:01 <andythenorth> but they default to stone etc if present in the game
16:06:40 <andythenorth> I absolutely don't understand make
16:08:10 <andythenorth> I need to trigger rebuilding the docs if any .png files in src have changed
16:08:22 <andythenorth> or if anything has changed in generated/graphics
16:08:56 <andythenorth> in fact the .png files are irrelevant, generated/graphics would catch the case
16:09:04 <andythenorth> but it stubbornly does not work
16:11:54 <andythenorth> html_docs is in the default target
16:12:02 <andythenorth> it has $(GRAPHICS_DIR) as a dept
16:33:15 <nielsm> so did anything interesting happen over the weekend?
16:39:15 <arikover> FLHerne andythenorth: Heavy Load Hopper? But Aggregate Hopper is perfectly fine. I just wanted to know the difference for the translation.
16:43:17 <arikover> andythenorth: Maybe hoppers' capacity for coal could be a bit lower compared to other aggregates, as it has a lower density? But that would be "realistic", and not really fun...
17:11:21 <juzza1> andythenorth: if i do "touch generated/graphics" and then make, it rebuilds the docs
17:12:05 <juzza1> changing a png does not update the directory timestamp though, so i guess you need the actual generated pngs as dependency as well?
17:15:37 *** Wormnest has joined #openttd
17:30:47 <Eddi|zuHause> andythenorth: how does the stuff in generated/graphics get created?
17:34:05 <Eddi|zuHause> andythenorth: you might want to also generate a .dep file
17:37:24 <Eddi|zuHause> ... it takes 4 more minutes to update my iron horse checkout
17:38:34 *** snail_UES_ has joined #openttd
17:43:54 <andythenorth> the stuff in generated/graphics is created by render_graphics.py
17:44:15 <andythenorth> the GRAPHICS_DIR target appears to pick up all the deps reliably
17:45:16 <andythenorth> I could learn about the nmlc -M option for deps, but it seems to require learning something for no benefit :P
17:49:34 <andythenorth> 'make' causes the docs to build
17:49:37 <andythenorth> 'make install' does not
17:50:34 <andythenorth> I just paste $(HTML_DOCS) in even more places
17:51:23 <andythenorth> pasting things to more places seems to be how make works
17:52:41 <peter1138> En-route pork pies, eh?
17:58:57 <LordAro> peter1138: just the minisnack ones i brought with me
18:02:12 <peter1138> I didn't have any energy or food enroute today, but I was by myself again.
18:02:50 <peter1138> In which case I slow down without noticing/causing others to wait.
18:25:45 <andythenorth> lol 13 second Horse compiles
18:25:53 * andythenorth will stop moaning for a bit
18:26:02 <andythenorth> this is happy emoji time
18:35:25 <Eddi|zuHause> i don't think i see what you think is right/wrong
18:35:57 *** sla_ro|master has joined #openttd
18:37:48 <andythenorth> I'm unfortunately throwing away the benefit of the nmlc spritecache
18:38:11 <Eddi|zuHause> make a grfcodec spritecache
18:38:12 <andythenorth> but I have implicit and explicit options for compiles to go faster in common cases
18:39:23 <andythenorth> this addresses the most boring case, which is waiting 1m to see a few pixels difference in game
18:39:31 <Eddi|zuHause> for some reason my youtube suggestions are full of (old) ESC content
18:39:38 <andythenorth> and the second most boring case, which is tweaking costs etc
18:39:46 <andythenorth> oof the power of suggestion
18:39:58 *** sla_ro|master has joined #openttd
18:40:31 <Eddi|zuHause> not the new stuff, stuff like "watch this song from 1975"
18:47:41 * andythenorth wonders about teaching nmlc that the input .nml hasn't changed
18:47:59 <andythenorth> if it made a .nml.bak file at the end of the compile, it could compare on next run
18:54:23 <Eddi|zuHause> same way as with the graphics, you output to a .nml.new file, and if cmp says no differences, you leave the .nml untouched, otherwise overwrite it
18:55:09 <Eddi|zuHause> make will then recognize that the file date was not changed, and skip some further processing
18:55:24 <Eddi|zuHause> (assumes proper dependencies)
18:55:42 <andythenorth> I was thinking about a PR for actual nmlc
18:55:50 <andythenorth> but it won't have any structure to encode
18:56:07 <Eddi|zuHause> this is pure makefile stuff
18:56:19 <andythenorth> yes, I have that working
18:56:27 <andythenorth> that's why I wondered if it can be generalised :P
18:56:40 <andythenorth> bundle grfcodec with nmlc? :P
18:56:58 <Eddi|zuHause> if you go on, you land on my ignore list
18:57:28 <andythenorth> I wasn't trolling that one :P
18:57:57 <andythenorth> grfcodec is a pretty good tool
18:59:09 <andythenorth> some of the suggestions for nml speed have revolved around 'rewrite in C++'
18:59:40 <andythenorth> meanwhile frosch has tested disk caching the nmlc tree structure and it's a poor tradeoff
18:59:55 <andythenorth> but nfo is a perfect intermediate format, and we already have the encoder
19:00:20 <andythenorth> and it's very very fast
19:00:58 <Eddi|zuHause> but both are fine standalone tools, there is no need to "bundle" them
19:05:54 <andythenorth> people who need the nmlc.exe won't be able to get grfcodec?
19:06:00 <andythenorth> I have no idea actually
19:07:14 <Eddi|zuHause> you're just making compiling and distributing more complicated for no benefit
19:07:30 <Eddi|zuHause> people who can install nmlc.exe can also install grfcodec.exe
19:07:41 <andythenorth> ok so it would just be a dep
19:08:04 <Eddi|zuHause> grfcodec is not a dep of nmlc
19:08:19 <Eddi|zuHause> your makefile just has two deps
19:08:34 <andythenorth> I just find it depressing that the general case doesn't get improved
19:08:41 <andythenorth> I do things to make my compiles faster
19:08:45 <andythenorth> but nobody else benefits
19:08:56 <andythenorth> it always comes back to 'rewrite nmlc properly'
19:09:05 <andythenorth> but there's nobody even maintaining the docs right now
19:09:08 <andythenorth> so that's not gonna happen
19:10:33 <andythenorth> I just wondered how many lines it would be to add an arg, so that grfcodec is the encoder
19:10:49 <andythenorth> and have nmlc do a diff on the .nml file before parsing
19:11:14 <andythenorth> it was surprisingly quick to do for me in my compile, and I wish I'd thought of it before :P
19:11:46 <andythenorth> python subprocess is a bit of a faff though
19:19:07 <Eddi|zuHause> andythenorth: no, that is out of scope for a compile tool
19:21:58 <andythenorth> I'll just keep solving my own problems then
19:22:23 <andythenorth> that might be fine, nobody else seems to have nmlc problems
21:45:34 <andythenorth> did you finish Doom yet?
21:58:08 *** Supercheese has joined #openttd
22:08:06 <peter1138> Which Doom? I've been playing WADs for Doom II, and also the 2016 remake.
22:17:18 <Eddi|zuHause> i don't think i had lunch
22:20:44 *** natmac[m] has joined #openttd
22:20:57 <frosch123> you should be amout done with the late dinner, and prepare for the midnight snack
22:31:43 * andythenorth wonders if newgrf vehicles could modify cargo price factor
22:31:55 * andythenorth assumes that might have performance issues
22:32:35 <Eddi|zuHause> the industry set can define custom price calculation, afair
22:34:53 <andythenorth> there is a cb for custom profit yes
22:35:07 <andythenorth> I am a bit wary of diverging too far from the cargo payment graphs
22:35:47 <andythenorth> I did try to make vehicle aging period 'work' on small maps by setting aggressive t1, t2 decay periods on some cargos
22:36:08 <andythenorth> but it makes very little difference until about 128 tiles (subject to vehicle speed)
22:36:27 <Eddi|zuHause> that seems like the intended purpose
22:38:26 <andythenorth> I tested quite a few things, but concluded that 'make cargo age periods work' isn't going in Horse 2.0.0
22:38:51 <andythenorth> obvs. they do work, just Horse was designed against a misunderstanding of them
23:18:04 *** sla_ro|master2 has joined #openttd
23:36:33 *** grossing has joined #openttd
23:46:55 *** sla_ro|master2 has quit IRC
continue to next day ⏵
