IRC logs for #openttd on OFTC at 2014-06-08
⏴ go to previous day
00:08:11 <planetmaker> whatever fits the situation :)
00:08:22 <planetmaker> with two cities, I'll do full load in the bigger one
00:08:51 <planetmaker> with three, I'll have trains going ABCB back and forth
00:08:55 <UukGoblin> kinda what I did... but then hardly any (mail) appears in the other one ;-)
00:08:59 <planetmaker> again with full load in the biggest
00:09:17 <planetmaker> I don't transport mail. At least not with the same trains as passengers
00:09:28 <UukGoblin> no, I have separate trains for mail
00:09:34 <UukGoblin> but mail is failing for me much more than passengers are
00:10:16 <planetmaker> it's naturally less than pax
00:10:33 <planetmaker> and depends on which house set (if any) you use
00:11:34 <UukGoblin> I don't think I use any... all looks like classic TTD
00:12:39 <planetmaker> well. And adopt the mail capacity to the actual supply. so that the full load doesn't take ages
00:12:54 <planetmaker> if it does, then the rating in the other towns would be too bad to be profitable
00:16:42 <UukGoblin> I'll steer away from mail for now ;-)
00:16:46 <UukGoblin> coal is much easier ;-)
01:22:19 *** Flygon_ has joined #openttd
02:06:24 *** Hazzard_ has joined #openttd
03:53:56 *** pthagnar has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
05:31:50 *** sla_ro|master has joined #openttd
06:40:44 *** Progman has joined #openttd
06:49:38 *** Orborde has joined #openttd
06:49:52 <Orborde> What mod are most of the public City Builder servers running?
07:01:05 <Supercheese> Perhaps they're using GameScripts?
07:06:04 <Orborde> Supercheese: When I googled for city builder, I found that, but I when I ran it, it didn't seem to work the same as most of the multiplayer servers on the internet.
07:07:17 <Supercheese> Well, that may be, I don't play multiplayer
07:07:24 <Supercheese> that was what popped to mind, though
07:22:19 <planetmaker> there are way more than one city builder script around. The servers might also use scripts which are not publicly available. Some might additionally use modified servers
07:22:58 <planetmaker> but the easiest way might be to ask the owner of the server
07:35:34 *** Dan9550 has joined #openttd
07:39:24 *** Pensacola has joined #openttd
07:52:33 *** Phreeze has joined #openttd
08:23:23 *** Myhorta has joined #openttd
08:47:30 *** HerzogDeXtEr has joined #openttd
09:14:04 *** andythenorth has joined #openttd
09:25:32 *** frosch123 has joined #openttd
09:27:15 *** SylvieLorxu has joined #openttd
09:35:24 *** Aristide has joined #openttd
09:51:50 *** HerzogDeXtEr1 has joined #openttd
09:58:30 *** Alberth has joined #openttd
09:58:30 *** ChanServ sets mode: +o Alberth
10:03:59 *** andythenorth has joined #openttd
10:06:01 <andythenorth> should nml be rewritten, not-in-python?
10:07:22 <Alberth> I don't know what the slow part actually is
10:07:51 <Alberth> in my experience, you can guess the cause, but you're always wrong
10:08:00 <Phreeze> that it takes nearly 0.1s to compile? :D
10:08:03 <Alberth> guessing the cause is a fun game though :p
10:08:58 <andythenorth> Snail: is m4nfo fun to use?
10:09:19 <Alberth> Phreeze: as in, what part of the nml compile is the bottleneck
10:11:32 <Alberth> andythenorth: I agree something should be done, but I don't know what
10:11:35 * andythenorth wonders if we should use a general purpose pre-processor instead of a scripting language
10:11:50 <Alberth> rewriting nml from scratch feels like a blunt sledgehammer solution
10:12:19 <Alberth> have fun with m4 then
10:13:32 <andythenorth> I wonder what the net time would be
10:13:39 <andythenorth> compile time versus programming time
10:14:12 <Alberth> but 90+% of the nml code is fine, the puzzle is finding what the 10% part is, and how to eliminate that bottleneck
10:14:43 <Alberth> also, I currently don't have the room to take on another big project
10:15:04 <andythenorth> usually I totally ignore ‘python is slow’ comments
10:15:23 <Alberth> did you measure the time of all the various stages in a make run?
10:15:24 <Eddi|zuHause> Alberth: in my tests, there were two parts that were extremely slow, first, the ply part that reads in the souzrce, which also uses extremely huge parts of memory, and then the evaluation of (constant) expressions
10:15:26 <andythenorth> because usually my concern is programmer speed, not code execution performance
10:15:56 <andythenorth> much easier (and *much* cheaper) to buy more CPU than buy more good programmers
10:17:34 <Alberth> Eddi|zuHause: ply builds on re, which requires the entire input string to be in memory
10:17:36 <Eddi|zuHause> the third part that was slow was that the makefile did this stuff twice, for the very questional result of a dependency graph. but afair that was removed...
10:18:11 <Eddi|zuHause> Alberth: but if the entire input string is 4MB, it's not a justification for python to use 1GB of memory
10:19:31 <Eddi|zuHause> this memory consumption is the main reason i split into partial compiles
10:20:42 * andythenorth wonders how much memory is used by FIRS compile
10:21:51 <Eddi|zuHause> just run "top", type ">", and watch while running a compile
10:23:42 <andythenorth> what does > do? I can’t find it in docs
10:24:01 <andythenorth> anyway, it’s climbed to 1.5GB so far
10:24:31 <andythenorth> I’ll have to run it again
10:24:45 <Alberth> virtual doesn't mean a lot, programs tend to over-allocate memory and never use it
10:26:24 <andythenorth> hmm my top doesn’t work like others
10:26:28 <Alberth> Eddi|zuHause: how much space do you have, ie could it be that Python decides not to do garbage collection?
10:26:48 <Alberth> LordAro: moin, and wrong python for trunk ;)
10:26:55 <andythenorth> seems that sorting processes by memory usage on OS X top is not a documented feature
10:27:25 <Eddi|zuHause> ">" moves the sort to the next column
10:27:33 <Eddi|zuHause> "<" moves it back
10:27:35 <LordAro> python docs are v nice
10:27:44 <Alberth> I suggested running some profiling a few days ago too
10:28:14 <andythenorth> Eddi|zuHause: I have some kind of crippled top
10:28:40 <Alberth> andythenorth: it's called "the BSD version" :)
10:29:52 <andythenorth> the OS X UI tool is better, let’s see
10:30:07 <Alberth> GNU software tends to get expanded with more features than the more traditional BSD software
10:33:15 <Eddi|zuHause> "within the last year, encrypted traffic in europe quadrupled from 1.5% to 6.1% of total"
10:34:34 <Phreeze> which is still not 100%
10:35:19 <Phreeze> 1) Apple 2) no RAM. RAM starts at 8gigs
10:36:05 <Alberth> the next question is what's in that memory
10:36:33 <andythenorth> I can sample the process
10:36:46 <andythenorth> but it’s just a crapload of python calls and mallocs :P
10:37:03 <andythenorth> (what else would it be? :P)
10:37:32 <Alberth> yeah, it needs to be more detailed, as in, how many objects of each class, and total size per class, or so
10:37:52 <andythenorth> wish I knew where yexo’s profiling runs were
10:38:42 <Alberth> hmm, Python doesn't throw anything away, I think
10:38:57 <andythenorth> is it as simple as wrapping a cprofile call around the nml entry point?
10:39:18 <Alberth> at least, I never encountered code that explicitly drops data
10:39:53 <Wolf01> stupid weather, I'm melting :|
10:41:44 <andythenorth> oh I have nml 2 still
10:41:53 <andythenorth> we don’t want results from old nml I guess
10:42:05 * andythenorth stares into a day of fighting PIL
10:43:11 <Alberth> oh, doesn't change that much, I guess
10:43:28 <Alberth> but I don't have a file with results :(
10:43:55 <andythenorth> should we just put build a profiling flag into nml?
10:52:45 *** gelignite has joined #openttd
10:55:17 <Alberth> ie confirmation of what Eddi already said
10:55:17 <LordAro> aw, i was just doing that :LK
10:55:39 <Alberth> try another project than firs :)
10:55:54 <Alberth> never hurts to have a few different projects measured
10:56:23 <Alberth> I guess if you throw away the graphics cache, the bottleneck will shift
10:57:05 <LordAro> which is another large grf?
10:59:19 <Alberth> landscape is pretty big, but mostly graphics, probably
10:59:57 <andythenorth> can we profile calls instead lex.py?
11:00:02 * andythenorth is a profiling newbie
11:01:16 <LordAro> uh, what was the "AttributeError: 'NoneType' object has no attribute 'days'" issue?
11:02:14 <andythenorth> can we map-reduce it and use multiprocessing? :P
11:02:21 <andythenorth> break into 4k chunks or something
11:06:39 <Alberth> yes, if you break it at the right point
11:08:02 <andythenorth> we have a not-very-strict format that lets authors get started easily
11:08:15 <andythenorth> I wouldn’t have a problem using a stricter format
11:09:07 <andythenorth> what (roughly) does lex.py do?
11:10:13 <andythenorth> I don’t seem to have it in nml src
11:10:23 <Alberth> splitting the big text-file into elementary things like "number (with a value)", "whitespace", "switch keyword", etc
11:15:47 *** oskari89 has joined #openttd
11:15:56 * andythenorth is being dense, where is that in nml repo? :)
11:16:43 <Alberth> oh, sorry, wrong name, it's nml/tokens.py
11:20:46 *** tokai|mdlx has joined #openttd
11:27:58 <andythenorth> nml supports includes? :o
11:29:28 <Alberth> some users like to use cpp, and still have errors reported in the right file ;)
11:30:06 <andythenorth> I should stop concatenating them myself :P
11:33:41 *** Supercheese has joined #openttd
11:37:28 <andythenorth> I’m kind of wondering what % speed up is achieved simply by removing dead lines etc
11:39:14 <Alberth> use the --nml option?
11:39:48 <Alberth> that should generate a usable file, without empty line stuff, I think
11:45:10 <Alberth> profiling suggests it speeds up
11:45:30 <Alberth> but it needs a non-profile run to check
11:46:33 <andythenorth> ok back in 5 mins or
11:46:44 <LordAro> funny how such a simple change can make a difference :)
12:05:27 <andythenorth> might be ~15s faster
12:06:20 <andythenorth> but I’m not sure if my patched nmlc is the one actually being used
12:08:17 <andythenorth> I can’t figure out if the makefile has a patch to nmlc, or just uses whichever is current
12:09:09 <Alberth> just run path/to/nmlc --grf=firs.grf firs.nml after generating the nml file one time
12:09:25 <Alberth> or rather time path/to/nmlc --grf=firs.grf firs.nml
12:20:38 <andythenorth> I think it’s faster in the ~10s range
12:20:45 <andythenorth> hard to tell with just a few runs
12:21:06 <andythenorth> with the patch, it’s around 1m 50s over 3 runs
12:21:20 <andythenorth> without the patch it’s ~2m 0s over 3 runs
12:24:04 <Alberth> ogfx-landscape shows no change worth mentioning
12:25:06 <Alberth> it's within the margin of error in measurements
12:26:17 <Alberth> ah well, patch won't hurt either
12:27:11 <krinn> hi guys, question: is it safe to assume memcopy(t, s, len); will pad t with \0 when t size > s size ?
12:28:20 <__ln__> no. how would it even know what's the size of t and s?
12:28:59 <krinn> they were define before: just assume values, say size t = 11 and s = 3
12:29:28 <krinn> is then safe to assume t will be fill with s content + \0 upto t size end
12:29:47 <krinn> in openttd so i suppose c++ (i sucks at c or ++)
12:29:50 <Alberth> no, t ands have no length
12:29:59 <__ln__> not only not safe, but completely wrong to assume.
12:30:21 <Alberth> it copies data that's it
12:30:52 <Alberth> if s and t overlap it will mess up too
12:32:01 <krinn> if last == null it will alloc tmp with (sizeof len+1) and then memcpy(tmp, s, len) so it copy less than the *tmp buffer size by 1 (assuming last char is \0 always)
12:33:17 <Alberth> Calloc clears memory, yes
12:34:12 <krinn> all fine so? clear == \0 (that's null char in C?)
12:34:13 <Alberth> but there is still no length associated with data pointers; it all depends on your careful calculation of "len"
12:35:42 <andythenorth> hmm, optimised nml compiles no faster
12:36:03 <Alberth> it's fine due to Calloc, and strcpy not overwriting the final byte, if that's what you mean
12:36:31 <Alberth> andythenorth: lex is just a lot of RE calls
12:37:13 <Alberth> you first do lex + yacc .py, and then everything else, but the first lex+yacc eats a lot of time
12:37:44 <krinn> Alberth, i see now calloc clear memory when assigning it
12:38:39 <andythenorth> Alberth: I never built an understanding of what nml is doing internally - does it then create a huge object representation of all the actions, or does it do something simpler?
12:39:22 <Alberth> it starts with loading your input file, which it scans and parses (tokens.py and parser.py)
12:39:36 <Alberth> that gives you an ast (nml/ast/*.py)
12:40:02 <Alberth> that is checked for errors, and converted to actions (nml/actions/*.py)
12:40:33 <Alberth> and finally written out to grf/nfo/nml nml/output_*.py
12:41:17 <andythenorth> so there are first class objects for all the actions
12:41:42 * andythenorth is just enquiring out of interest
12:42:27 <Alberth> not sure about the "first class", but yeah, each action in the grf is a ActionZ object before
12:42:51 * andythenorth wonders if FIRS can be made faster simply by coding it better
12:43:05 <andythenorth> given that the nml file is 8.6MB
12:44:53 <Alberth> scanning is roughly linear in the size of the input
12:45:14 <andythenorth> FIRS potentially repeats a lot of item blocks
12:45:29 <andythenorth> the number of some blocks grows ~linearly with the number of economies
12:45:37 <Alberth> one problem may be that cpp cannot perform calculations
12:46:56 <Alberth> so expressions get duplicated as text, rather than just the answer
12:50:26 <andythenorth> I wonder if FIRS should be split
12:50:52 <Alberth> implement partial compile? :)
12:52:59 <andythenorth> I think we all know the limits of my skills :P
12:53:58 *** Myhorta has joined #openttd
13:05:25 <krinn> what do ~ do on function? (ie : blah::toc then blah::~toc)
13:05:26 <Alberth> yet you talk about partial compilation
13:05:53 <Alberth> krinn: I hope blah::~blah then :)
13:06:06 <Alberth> in that case, it's the desctructor
13:06:34 <krinn> ah ok (i would add google that to not bug any, but seriously ~ would be hard to find)
13:06:39 <andythenorth> I can partial compile the newgrf, resulting in a less complete newgrf :)
13:07:00 <andythenorth> but adding a linker requires comp sci understanding I never got :P
13:07:36 <Alberth> oh definitely not doable in any short time
13:08:01 <Alberth> but given the problem is in scanning and parsing, I am not so convinced it adds much
13:08:11 <Alberth> since your input text doesn't get smaller
13:09:11 <Alberth> krinn: it's pretty much fundamental in c++ classes, any c++ book will do :)
13:10:49 <krinn> i'm sure, but must be reading a book to find it, but searching for it would get nearly impossible
13:25:07 <Alberth> andythenorth: what if a template expansion was added after scanning (relatively easy) or after parsing (more complicated), ie how is the ratio source text / expanded cpp output text ?
13:26:24 <Pikka> andythenorth, which newgrf be these?
13:27:19 <andythenorth> Pikka: all of they
13:27:53 <andythenorth> Alberth: not sure, I don’t really understand the CPP stuff beyond the use of constants
13:28:15 <andythenorth> I’m removing it where it’s worth the effort, leaving it alone otherwise
13:28:35 <Pikka> what are you currently working on, I meant
13:28:50 <Pikka> or are you just putting all your effort into tinkering with the build environment
13:29:48 <Alberth> andythenorth: cpp just expands #defines. You can also do that after scanning. That would reduce the amount of text that needs to be scanned. I wonder whether it is worth the effort
13:30:22 <andythenorth> Pikka: I got bored of slow
13:30:40 <andythenorth> Alberth: I am -1 to using cpp, making nml support it directly doesn’t float my boat :)
13:31:15 <andythenorth> if I could actually understand the file format of a newgrf, I’d try writing a linker
13:31:22 <andythenorth> it would be redneck and stupid
13:31:40 <andythenorth> but it can’t be impossible, even for me
13:31:55 <Alberth> for experimenting, nfo would do fine
13:32:06 <andythenorth> surely it’s just a bunch of bytes followed by more bytes?
13:32:28 * andythenorth ponders EvilLinker
13:32:35 <andythenorth> randomly changes significant bytes
13:33:50 <andythenorth> hasn’t Eddi already solved most of the nfo-based linker?
13:33:57 <andythenorth> and we’re just studiously ignoring his patch?
13:34:38 <Alberth> afaik he uses action C to find points in the output to cut
13:35:08 <Alberth> and with assumptions on available actionIDs, he pastes stuff together again
13:35:36 <Alberth> which no doubt works for his newgrf, but not in general
13:39:10 <andythenorth> 3s for grfcodec to compile FIRS nfo :O
13:39:19 <andythenorth> that’s so fast I’m not sure it’s correct
13:40:25 *** MTsPony is now known as Guest12976
13:40:25 *** MTPony is now known as MTsPony
13:42:15 *** MTPony is now known as MTsPony
13:44:11 <Alberth> compiled c/c++ code is bloody fast :)
13:44:21 <Alberth> in particular when it isn't doing much
13:46:05 <andythenorth> ‘compiled’ is probably too strong a term for nfo -> newgrf?
13:46:43 <andythenorth> I think I’m going to try a redneck partial compile of my own, like eddi's
13:46:50 <Alberth> basically you convert "XY " to 1 byte
13:47:54 <andythenorth> currently partial compiles fail in FIRS because some switches check across other industries
13:48:01 <andythenorth> which I wanted to solve anyway
13:49:13 <andythenorth> they are proximity checks, and they’re borked in most economies because they’re not economy specific
13:49:31 <andythenorth> there should be something like tables of incompatible industries in global_constants
13:50:21 <andythenorth> which means some kind of set reduction algorithm that I won’t be clever enough to figure out :P
13:51:47 <V453000> andythenorth: still thinking about making the trading economy scheme I made for you? (:
14:10:02 <andythenorth> ok so the current problem I have with FIRS partial compiles: switches that check distance to other industries, but can’t resolve identifier for those industries becuase they’re not in the nml
14:12:08 <andythenorth> “industry_type is either the ID of an industry.”
14:12:31 *** MTsPony has joined #openttd
14:15:51 <andythenorth> I can substitute numeric ID
14:16:02 <andythenorth> that bit of wiki needs a fix :)
14:17:04 <andythenorth> Alberth: so I’ve been assuming the sensible minimum unit for a partial compile is one industry, one house, one vehicle etc
14:17:16 <andythenorth> that assumption may be flawed, dunno yet
14:17:26 <andythenorth> does it sound plausible, or archaic?
14:17:47 <planetmaker> that's very plausible, andy
14:17:55 <Alberth> sounds like a good starting point to me
14:18:01 <andythenorth> what about when you want to recompile just the action 14 or such?
14:18:16 <andythenorth> shouldn’t a linker be able to re-compile ‘whatever is in a given source file'
14:18:20 <Alberth> theoretically, you could recompile a single switch or so
14:19:01 <Alberth> sure, a single NFO sprite would be the smallest sane unit imho
14:19:16 *** MTsPony has joined #openttd
14:19:32 <planetmaker> just the action14 could work all on itself. Though it defines parameters to some extend. So... can pull a tain of subsequent needed changes in other parts, when using subsequent IDs
14:19:38 <andythenorth> so I think we need a symbol table
14:19:43 <andythenorth> I can work around that for now
14:19:59 <andythenorth> my compile can get the IDs off _my_ python objects during pre-process
14:20:07 <andythenorth> which is a starting point
14:20:23 <planetmaker> for the industries. But for the switches and parameters?
14:20:39 <andythenorth> switches I don’t know
14:20:45 <andythenorth> I’m learning by doing :)
14:20:51 <planetmaker> the latter are the most interesting thing and the limiting factor
14:21:01 <andythenorth> can I substitute numeric IDs in switches?
14:21:06 <andythenorth> with an escape or such?
14:21:34 <planetmaker> nml does not allow assignment of numeric IDs to single switches
14:21:48 <planetmaker> the language. The compiler of course does at some stage
14:21:58 <andythenorth> I’ll ignore it now
14:22:10 <andythenorth> it’s not significant for compiling a complete single industry
14:27:31 <andythenorth> nml - does it suppot action C comments?
14:30:13 *** Myhorta has joined #openttd
14:32:05 <Alberth> no, there is a patch in the issue tracker
14:32:42 <Alberth> imho it doesn't make sense to allow comments in generated code
14:34:42 <andythenorth> I have two equally good ways to do something, and I have to choose one :P
14:34:52 <andythenorth> unrelated to comments :)
14:35:19 <Alberth> if they are equally good, it doesn't matter which you pick
14:35:20 * andythenorth chooses the encapsulated route, even though it means more object crap
14:35:24 <planetmaker> andythenorth, eddi's nml version allows that - that's basically its only change. But ... it's a bit... well, not universal for sure
14:35:54 <andythenorth> it’s not necessary
14:36:05 <andythenorth> I can stick in spurious trains and split on those
14:36:49 *** Flygon_ is now known as Flygon
14:37:05 <Flygon> MUs that can split from eachother at stations to go on seperate routes
14:37:17 <Flygon> 'course, running more trains does the same thing
14:37:51 <Alberth> context is a little different :)
14:39:15 <andythenorth> well it’s ugly :P
14:39:17 <andythenorth> CHECK_INCOMPATIBLE(${industry.get_another_industry('quarry').get_numeric_id()}, 16, CB_RESULT_LOCATION_DISALLOW, ${industry.id}_${industry.get_another_industry('coal_mine').get_numeric_id()})
14:39:24 <andythenorth> but I can fetch the numeric IDs that way
14:39:37 <andythenorth> I could look them in global_constants too, simpler, but less future-proof
14:40:10 <andythenorth> this means the existing single-industry compile works in all cases (once I’ve moved all industries to use above)
14:41:28 <andythenorth> make TEST_INDUSTRY=lime_kiln
14:42:03 <andythenorth> if I output that as nfo, with something reliable to split on
14:42:31 <andythenorth> then add a step to rejoin and encode the nfo
14:42:42 <andythenorth> then partial compiles -> full newgrf
14:43:07 <andythenorth> if I add a dep check on the front end (I have an ugly one in Iron Horse)
14:43:13 <andythenorth> then that’s a redneck linker
14:44:01 <andythenorth> and once that’s working, I (we?) can use it to find the edge cases and problems with ids
14:58:52 *** Hazzard has joined #openttd
15:01:46 *** Blaguvest has joined #openttd
15:12:47 *** LaPingvino has joined #openttd
15:17:55 <LaPingvino> I'm curious, how many of you are playing with CargoDist options on now?
15:18:37 <LaPingvino> and to date I have only seen some Polish servers with CargoDist on, as well as a CZ server that has CargoDist in the name but not activated...
15:19:23 <planetmaker> dunno. I would think it's probably more used in single player than in multi player. But... no idea
15:19:25 <Alberth> I usually do, but it mostly makes transport more complicated rather than more fun
15:19:48 <planetmaker> you could try making a statistic, LaPingvino by downloading savegames and checking them for the setting and generating statistics from that
15:19:58 <planetmaker> tt-forums and our bug tracker might be good places to get an idea :)
15:20:02 <planetmaker> and the necessary savegames
15:20:05 <LaPingvino> I tend to stick with passenger transport under CargoDist
15:20:14 <LaPingvino> because you keep linking destinations
15:20:16 <planetmaker> would actually be interesting statistics
15:20:41 <LaPingvino> whereas in B.Cd. games, you make a route and go on...
15:21:24 <LaPingvino> well, as long as you stick to unconnected goods routes, it will function the same as before, right?
15:21:48 <planetmaker> yes. but how boring is that?
15:22:11 <LaPingvino> but I just say, if you get it more complicated, it's because you choose to do so ;)
15:22:18 <Alberth> train sets just aren't designed to handle all kinds of cargoes on the same network
15:22:54 <LaPingvino> that's true... CargoDist works best for passengers and mail. But well, you can turn it on only for those anyway ;)
15:23:37 <andythenorth> I am using CargoDist, using a version Fonso gave me which I am not sure whether it is in trunk or not
15:23:55 <LaPingvino> from 1.4.0 it's in trunk
15:24:10 <LaPingvino> so if you use a custom build, I don't think you're compatible ;)
15:24:38 <Alberth> trunk is not compatible anyway :)
15:25:06 <Alberth> except with previous trunk versions
15:25:21 <planetmaker> well, trunk is also compatible with stable versions :)
15:25:32 <planetmaker> but it's no bijection
15:25:34 <LaPingvino> ah, I'm one of the two creators of Esperanto Town Names, and I saw a huge number of Downloads... is it normal to download about everything or do some of you actually use it ;) :P
15:25:51 <Alberth> it is? /me would just love to continue my current game in say 1.0 :p
15:26:10 <planetmaker> Alberth, that's the reverse direction :)
15:26:41 <LaPingvino> I just downloaded TTO from Abandonia today and created a game to load in to test the compatibility
15:27:00 <planetmaker> that *should* work, LaPingvino
15:27:05 <LaPingvino> apart from another name for the bus type, that's effing cool to be possible ;)
15:27:40 <LaPingvino> apart from that I had to load it with openttd -g nameofthefile, because it does show but grays out the load button in 1.4.1
15:27:51 <LaPingvino> and doubleclick doesn't work either
15:28:05 <LaPingvino> but with openttd -g it works just fine :)
15:28:11 <frosch123> does it give a message why it is greyed out?
15:28:26 <LaPingvino> and it doesn't give an error on loading from the command line
15:28:48 <LaPingvino> I can pass the savegame if you wish, so you can test
15:28:48 <LaPingvino> it's really simple
15:30:10 <frosch123> nah, i can reproduct it
15:30:26 <frosch123> apparently noone loads tto/ttd games, resp. has newgrf dev tools enabled :p
15:30:26 <LaPingvino> saves some bytes over the wire ;)
15:30:40 <LaPingvino> it seems so, yes...
15:30:52 <LaPingvino> pity I cannot test it with 1.4.0 any more...
15:31:08 <frosch123> actually you just need to select a different save first :p
15:31:11 <LaPingvino> (I run Arch, always the latest stuff :P)
15:31:22 <frosch123> once the "load" button is enabled, you can select the ttd game :)
15:31:38 <LaPingvino> so it's probably a very tiny GUI trigger issue...
15:32:02 <LaPingvino> nevertheless good that we triggered it ;)
15:33:19 <LaPingvino> anyway, I'm one of the few that got into TT with the World Editor edition... but cannot find THAT one back any more :(
15:34:04 <LaPingvino> the moment a classmate told me he had TTD, and what was new in there... pure bliss ;)
15:35:18 *** Blaguvest has left #openttd
15:35:33 <LaPingvino> I discovered the merge of CargoDist because I taught OpenTTD to a friend of mine, and he is very much into realism
15:36:04 <LaPingvino> so after some time, he told me about CargoDist, Shared Orders and Conditional GoTo jumps
15:36:18 <LaPingvino> which is already a completely new way to play
15:36:32 <LaPingvino> the last one is useful together with the first one, actually...
15:37:19 <LaPingvino> anyway, should I file a bug for the TTO load issue?
15:37:45 <LaPingvino> or did frosch123 already file one?
15:38:50 <LordAro> Belugas & V453000 can teach you a thing or 2 about realism ;)
15:38:52 <LaPingvino> the cool thing of TT is that the time goes fast enough to get more types of vehicles over time, but the vehicles go slow enough that they don't fly over the screen ;)
15:40:57 *** sla_ro|master has joined #openttd
15:43:23 <Pikka> what a pleasant and useful discussion that was
15:43:59 <Alberth> and the fun part is that non-reality of V and B are not the same either :)
15:46:37 <LaPingvino> that's why although not as realistic, CargoDist is a better fit than the SimuTrans system of having a destination before you go ;)
15:48:12 <Alberth> people will disagree with you :)
15:48:37 <Alberth> cdist just makes it more difficult for you as player to have more destinations
15:48:57 <Alberth> ergo, it is an advantage not to spread to different destinations at all
15:49:47 <Alberth> they want a cdist mode where you are forced to connect to more destinations
15:50:00 <DorpsGek> Commit by frosch :: r26634 trunk/src/fios_gui.cpp (2014-06-08 15:49:54 UTC)
15:50:01 <DorpsGek> -Fix: 'Load' button was not properly enabled/disabled for old savegames without NewGRF information.
15:50:09 <frosch123> LaPingvino: no need for a report :)
15:50:15 <Alberth> or you just don't get enough cargo to make a profit
15:50:44 <Alberth> a first implementation of this is YACD
15:54:05 <LaPingvino> frosch123: cool :) you just fixed it?
15:54:43 <LaPingvino> Alberth: I know people will disagree, but as long as you can choose between dist and dest, I'm happy ;)
15:54:55 <LaPingvino> and maybe some day dest can be a nice challenge as well
16:03:10 *** pthagnar has joined #openttd
16:03:36 <LaPingvino> I see so much "regearing" in that thread that it drives me curious...
16:04:02 <LaPingvino> but I suppose I shouldn't be? :P
16:06:09 * Alberth never understood the finer points of regearing
16:08:15 <LaPingvino> is there some reading about it?
16:17:57 <Pikka> regearing was a cargo used to refit locomotives, to change their top speed and TE
16:18:24 <Pikka> breaks a lot of industry sets, breaks full-load orders
16:18:27 <planetmaker> category: BAD FEATURE [TM]
16:20:34 <LaPingvino> in other words, double locs is a much better way to get the same? ;)
16:21:13 <Pikka> well, you can achieve sim'lar using passengers and cb36 to set the capacity to 0
16:21:20 <LaPingvino> so you used cargo in an active way instead of passive as it usually is, right?
16:21:22 <planetmaker> that. Or there are other ways to achieve the same
16:21:24 <Pikka> but it's still a bit of a silly idea and I don't know of anyone else who's done it
16:34:56 <LaPingvino> frosch123: now that we are on the bug road anyway: I have some (common) input method issues on Linux: dead keys don't work (but accents that are reachable under AltGr do work) and ibus doesn't work for me...)
16:35:52 <LaPingvino> frosch123: do you know if those are reported already?
16:36:56 <frosch123> no idea, everyone uses a no-dead-keys keyboard layout
16:37:56 <frosch123> you can configure capslock to act a compose, if you really need ḟȧṅċẏ characters
16:38:45 <frosch123> it's the best usecase of capslock after all
16:38:59 <frosch123> though i am still searching for a usecase for the win and onctext menu keys
16:39:20 <frosch123> the print screen key, scroll lock and pause at least have *some* use
16:39:29 <frosch123> though i cannot remember using them the last time :)
16:40:26 <LaPingvino> I use xmonad, the winkey is my modifier key
16:41:02 <Alberth> switching to previous and next desktop
16:41:07 <LaPingvino> context menu key is actually useful sometimes in e.g. xbmc, otherwise that's also a quick choice for me as a compose key
16:41:18 <LaPingvino> you could then put ctrl on the capslock
16:41:28 <LaPingvino> ctrl for emacs users, esc for vi users ;)
16:41:54 <LaPingvino> and actually, ctrl for openttd-players as well, there are some things to do with ctrl-click
16:42:23 <frosch123> Alberth: i have two screens, i do not need to switch desktops :)
16:42:28 <frosch123> i switch screens instead
16:43:04 <frosch123> maybe i should map \ { } on those keys
16:43:13 <frosch123> but i won't actually get used to them likely
16:43:31 <LaPingvino> but yeah, I am 9-lingual, and I usually use portuguese, and with my Dvorak-keyboard dead keys are the common way to type words like ação and Esperanto words.
16:44:30 <LaPingvino> and I can imagine brazilians getting frustrated, as their common keyboard layout has dead keys for the same as well
16:46:43 <LaPingvino> but well, I suppose it does work well on Windows, so most won't complain...
16:47:03 <LaPingvino> and there are more issues with dead keys than only in OpenTTD, unfortunately :(
17:03:56 * andythenorth wonders if FIRS has any global action IDs
17:04:57 <planetmaker> sure it does for checking compatibility
17:05:11 <Eddi|zuHause> with "global" you mean feature 08 or something that stays alive for the whole file?
17:05:34 <andythenorth> I mean varaction 2 where the author has explicitly chosen to not redeclare the ID so it can be re-used across multiple industries
17:06:05 <planetmaker> probably that not
17:06:17 <planetmaker> though it could be done. e.g. with some location checks
17:06:28 <Eddi|zuHause> in nml you can't explicitly choose varaction2 ids
17:06:52 <Eddi|zuHause> so the first definition and the last use define the lifetime of the ID
17:06:52 <planetmaker> I wonder whether it would be sane to allow for that. Not sure
17:07:07 <Eddi|zuHause> planetmaker: i see no use case
17:07:26 <Alberth> writing an industry newgrf against an existing one?
17:07:27 <Eddi|zuHause> planetmaker: unless you want headerless partial compiles
17:07:44 <Eddi|zuHause> Alberth: can't refer to varaction2 of another grf
17:07:55 <Eddi|zuHause> or to industries, for that matter
17:08:01 <andythenorth> mmm, headerless partial compiles...
17:08:59 <Alberth> andy is descending into the deep slippery paths of partial compilation.... :)
17:09:17 <andythenorth> Eddi|zuHause: I am replicating for myself your solution
17:09:21 <Eddi|zuHause> he heard that it might speed up compike time
17:10:09 <andythenorth> I liked the compike version tbh
17:11:30 <LaPingvino> I like the Rob Pike version ;)
17:11:49 <andythenorth> writing foo.nml -> foo.nfo using nmlc is faster than I expected
17:12:07 <andythenorth> I thought it would be ~same as foo.nml -> foo.grf
17:12:17 <andythenorth> give or take 10s
17:12:29 <Alberth> graphics copying is slow
17:12:40 <planetmaker> the delta w/o reference timing does not tell me much :)
17:13:09 <Eddi|zuHause> what's a rob pike?
17:14:07 <Eddi|zuHause> andythenorth: for nml->nfo you skip all the pil calls/graphics conversions
17:14:08 <Alberth> wasn't there a Pike in ST?
17:14:24 <LaPingvino> Rob Pike is one of the designers of UTF-8, and of the Go programming language
17:14:25 <Eddi|zuHause> andythenorth: but those parts are cached, so subsequent calls may not show the same effects
17:14:33 <LaPingvino> he works at Google
17:14:55 <Alberth> figures, if he invented the Go language :)
17:14:57 <Eddi|zuHause> Alberth: yes, pike is kirks boss
17:15:07 <andythenorth> actually firs.nml -> grf and firs.nml -> nfo are about the same
17:15:18 <andythenorth> cache is primed though
17:15:53 <Eddi|zuHause> Alberth: not that kirk ever listens to any boss :p
17:16:09 <Alberth> obviously, he's the star of the show :)
17:16:52 <andythenorth> 3-4s for nml -> nfo or nml -> grf
17:16:59 <LaPingvino> can someone explain me the Citybuilder online games?
17:17:06 <andythenorth> 18s for makefile version, with 3s of python pre-processing
17:17:19 <andythenorth> dunno how long the make and cpp bits are taking
17:17:28 <andythenorth> also whether it does more lang processing
17:19:17 <andythenorth> planetmaker: if you’re interested, single industry compile is “time make TEST_INDUSTRY=lime_kiln”
17:19:21 <andythenorth> np if not interested :)
17:21:34 <andythenorth> nml’s nfo output respects the order of items in the original nml source?
17:21:39 <andythenorth> it doesn’t move things around?
17:22:14 <Eddi|zuHause> usually, but it's not guaranteed
17:22:31 <Eddi|zuHause> main reason why my actionC patch wasn't included
17:23:19 <Eddi|zuHause> what does this mean?
17:23:23 <Eddi|zuHause> [NML] src/headers.nfo
17:23:24 <Eddi|zuHause> Illegal character '#' (character code 0x23) at "<command-line>", line 1, column 1
17:23:25 <Eddi|zuHause> make[1]: *** [src/headers.nfo] Fehler 1
17:24:06 <andythenorth> yeah, moving stuff around is a game-over event for splitting on delimiters :(
17:25:07 * andythenorth wonders about teaching nml to compile fragments which are non-valid for a grf
17:25:20 <planetmaker> andythenorth, that needs no teaching
17:25:34 <planetmaker> just look at nml's regression tests. you can compile grf parts without problem
17:25:42 <planetmaker> it needs not even be a grf
17:25:55 <andythenorth> so it just does input -> output parsing
17:26:04 <andythenorth> no attempt to sanity check or validate?
17:26:37 <Eddi|zuHause> andythenorth: problem with that is IDs that need to stay the same over the whole grf, like texts
17:28:28 <andythenorth> yeah, I was just looking at the lang stuff
17:28:49 <planetmaker> yeah, stringIDs need to be global
17:29:16 <Eddi|zuHause> second problem with that is nmlc "optimizes out" strings that are not used
17:29:32 <Eddi|zuHause> so you need to reference every string in every partial grf
17:30:04 <planetmaker> Eddi|zuHause, I can imagine to change that by means of a cli parameter
17:30:23 <planetmaker> default shouldn't change there, but a 'debug' option for that...
17:30:56 <Eddi|zuHause> planetmaker: maybe, but it would not simplify CETS significantly
17:31:34 <andythenorth> so splitting output is game-overed
17:31:46 <andythenorth> and outputting only fragments is hard
17:31:59 <andythenorth> the splitting route is ugly anyway
17:32:23 <andythenorth> stringIDs need to be global...
17:32:26 <planetmaker> Eddi|zuHause, no. And it has issues. Some strings would normally not get an ID even (like STR_GRF_NAME etc)
17:32:31 <Eddi|zuHause> andythenorth: it's really not THAT hard, i have "dummy code" that references every string-id and every global action2
17:32:41 <planetmaker> and the STR_IDs ranges are not necessarily known
17:32:43 <andythenorth> I just wonder how we used to do that ‘hard’ problem in nfo :P
17:33:00 <planetmaker> especially if you mix features. So that will be somewhat terrible, too. Not 100% sure it can be done actually
17:33:31 <planetmaker> andythenorth, there we basically would write several grf. And just throw them on top of eachother
17:33:35 <andythenorth> I can’t provide a stringID table to nml?
17:34:06 <planetmaker> that probably needs knowledge of the overall code
17:34:16 <planetmaker> but maybe that can be done separately
17:34:29 <planetmaker> you know from their context which IDs they are. And maybe that can be cached
17:34:53 <andythenorth> what’s the issue? We want some things that are compile-time determined to become constants?
17:34:59 <planetmaker> and re-used as long as the string names are unmodified in the lang file(s)
17:35:38 <Eddi|zuHause> the file is autogenerated
17:36:19 <Eddi|zuHause> the vehicle names are not part of that list, because they do not get string-ids
17:36:19 <andythenorth> Eddi|zuHause: and the problem with that file is…? (I had that kind of thing in mind)
17:36:32 <Eddi|zuHause> andythenorth: no problem.
17:37:18 <Eddi|zuHause> STR_AUTO_<n> are things read from the tracking table, like axle scheme
17:37:58 <Eddi|zuHause> and the other things are strings that get referenced somewhere
17:38:20 <Eddi|zuHause> the generate script collects that data somewhere
17:40:32 * Alberth wonders how difficult it is to generate nfo-like output, with symbolic IDs
17:40:44 <andythenorth> I’m not really following the stringID issue
17:40:56 <andythenorth> we want stringIDs to be constant for all fragments of a grf?
17:41:30 <Eddi|zuHause> andythenorth: yes, like if your industry window pushes a string-id to the text stack, that ID must be known
17:41:30 <planetmaker> Alberth, that pretty much would already be the 'object file format', no?
17:41:42 <planetmaker> in some sense at least
17:41:54 <Alberth> it's a form of object file format indeed
17:42:09 <Eddi|zuHause> Alberth: i wondered about generating an NML syntax tree directly, instead of writing out the file for it to be parsed again
17:42:28 <andythenorth> I wondered about that
17:42:32 <andythenorth> but I am not smart enough
17:42:38 <andythenorth> I have objects :P
17:42:42 <andythenorth> then I write them into nml
17:42:47 <andythenorth> then nml slowly writes them into grf
17:43:12 <andythenorth> I considered a python -> nfo compiler
17:43:19 <Alberth> Eddi|zuHause: given that scanning and parsing is slow, it would help, but where do you store what you need to build?
17:43:21 <andythenorth> but I’m not a good programmer, I’d be slow
17:43:36 <Alberth> andythenorth: it's called nmlc? :)
17:43:54 <Eddi|zuHause> Alberth: either i pickle it, or i just call nmlc internals directly
17:44:18 <Eddi|zuHause> no idea about the performance of pickle
17:44:31 <Eddi|zuHause> but being implemented in C it might not show the same issues as ply
17:44:32 <Alberth> how do you know what internals to call in the latter case?
17:44:58 <Eddi|zuHause> Alberth: reading nmlc's code to see what's done after parsing :p
17:45:16 <DorpsGek> Commit by translators :: r26635 trunk/src/lang/finnish.txt (2014-06-08 17:45:10 UTC)
17:45:17 <DorpsGek> -Update from WebTranslator v3.0:
17:45:18 <DorpsGek> finnish - 2 changes by jpx_
17:45:40 <Eddi|zuHause> possibly replacing that parse function with some other input function
17:45:41 <Alberth> Eddi|zuHause: right, thus the AST -> Action code :)
17:46:40 <Alberth> a simple approach would be to replace the scanner by a C implementation, but it would break ease of use of nml in the general case
17:46:55 <Alberth> ease of installation, perhaps is a better word
17:47:05 <Eddi|zuHause> Alberth: if nmlc is constructed anything like they taught me in compiler construction class, the semantical analysis would be next
17:47:58 <Alberth> nml/ast/*.py is full with checking, and conversion to action/*.py objects
17:48:08 <Eddi|zuHause> thingie that takes the bare AST and calculates attributes (like constant evaluation)
17:48:33 <Alberth> Expression class does evaluation
17:49:20 <Eddi|zuHause> but i was never bored enough to learn the structure of the AST
17:51:38 <Alberth> are these numbers important other than they should stay the same across all parts of a grf?
17:52:27 <Alberth> ie can you jumble them up completely the next day, when you build a new grf?
17:52:51 <andythenorth> savegames get a bit sad if you do
17:53:08 <andythenorth> I dunno, changing string IDs used to be the primary cause of crashing ottd
17:53:25 <andythenorth> but then not everybody changes grfs on a running game like me
17:53:51 <Alberth> kk, you're building a new grf with a new id if you're precise, when changing stringid numbers
17:55:15 <andythenorth> Alberth: I’m not sure if it’s actually significant for savegames
17:55:53 <andythenorth> I know the results of changing it on a running game, I assumed I was leaving ottd with bad pointers to existing strings or such
17:56:04 <planetmaker> that will be a similar result, I think
17:56:49 <andythenorth> I wouldn’t really care about having to manage string IDs
17:57:05 <andythenorth> I’d just make a static table of identifiers (from lang files) to the actual hex IDs
17:57:22 <andythenorth> it’s high on admin though
17:59:18 <andythenorth> pass the location of the table in as a compile time parameter to nmlc
18:00:34 <planetmaker> hm... like something --with-static-strings and nmlc then reading a string_table.o ?
18:00:42 <andythenorth> yes, that kind of thing
18:01:11 * andythenorth needs to try compiling fragments of nml to see if it’s worth it
18:01:18 <andythenorth> got the kids in the bath right now though ;)
18:01:32 <planetmaker> there you surely can compile a foam party :P
18:01:58 <andythenorth> or water-on-the-floor-shorts-out-the-electrics party
18:02:51 <andythenorth> lang consumes 4s of an 18s compile right now
18:03:12 <andythenorth> residual current device
18:03:59 <Eddi|zuHause> there allegedly was an inctance in the 1980s when we were moving to a bigger flat (because abundance of kids), and first they assigned us some unmodernised old buildings, and the first time the kids took a bath, the water leaked through the floor to the downstairs neighbours
18:04:39 <Eddi|zuHause> i don't think FI was around back then :p
18:05:03 * andythenorth did *not* know that an RCD won’t help you if you bridge the terminals on a light fitting
18:05:15 <andythenorth> which is probably the most common way to get a shock imo :P
18:05:18 <planetmaker> it can only detect leakage
18:05:36 <planetmaker> but if you bridge it, there is leakage to the ground. So it will still work
18:06:00 <planetmaker> *you bridge it by current going through you
18:06:10 <Eddi|zuHause> andythenorth: just shorting out the 2 main wires won't trigger it
18:06:26 <Eddi|zuHause> andythenorth: shorting out a wire with the ground will
18:06:37 <planetmaker> unless you manage to be in thin air and in contact with nothing else while being the conducting element
18:06:52 <Eddi|zuHause> so if you wear gummy shoes and take a wire in one hand and the other in the other end, you lose
18:07:15 <planetmaker> the question is what you'll loose :P
18:08:12 <Eddi|zuHause> i'm not a doctor, but i'd imagine the heard muscle tightens under electric power
18:08:58 <planetmaker> possibly. It's a strange feeling to be the bridge from power to ground :P
18:09:11 * planetmaker once tested. I removed the wrong fuse :P
18:10:39 <Eddi|zuHause> i only "tested" cow fences :p
18:11:04 <Eddi|zuHause> it actually sends short impulses rather than constant power
18:13:21 <planetmaker> yes. That I tested much earlier. Probably between age 4 and 6 :P
18:19:12 <Eddi|zuHause> makes me wonder: were the systems used for cow fences the same in east and west?
18:23:04 <planetmaker> Eddi|zuHause, there's no need for that. They only serve one meadow at a time
18:24:49 <andythenorth> I found out how grass conducts electricity using a cow fence
18:25:20 <planetmaker> yeah, quite well :P
18:31:22 <andythenorth> planetmaker: so in the regressions, a grf block is still present
18:31:26 <andythenorth> is that optional?
18:31:37 <planetmaker> andythenorth, in some it is. In some it isn't
18:32:00 <planetmaker> some have it to actually test it ingame :)
18:32:01 <andythenorth> bad lucky dip so far :P
18:32:33 <planetmaker> well, not during regression, but to allow for it
18:42:36 <andythenorth> planetmaker: I am testing with Iron Horse as it’s cleaner than FIRS
18:42:53 <andythenorth> it already generates nml files per vehicle in generated/nml
18:43:11 <andythenorth> so far, the following would need constants: strings, parameters, cargo labels
18:43:25 <andythenorth> railtype label seems not to, but maybe because RAIL is a built in constnat
18:43:58 <Eddi|zuHause> yes, there is a default RTT
18:44:07 <Eddi|zuHause> if you don't override it
18:47:18 <andythenorth> so we already have a CTT and RTT
18:47:30 <andythenorth> I’d need a string table and a parameters table
18:47:46 <andythenorth> although parameters works on numeric substitution, which I can do without a table
18:49:15 <Eddi|zuHause> i just put the grf block in every partial grf
18:49:40 <Eddi|zuHause> then i split it off in the combining step
18:51:01 <andythenorth> I wanted to avoid the splits
18:51:06 <andythenorth> because they look ugly
18:51:31 <andythenorth> although I can imagine them working ~most of the time
18:52:14 <Eddi|zuHause> but you can't provide the parameter ids without it...
18:52:33 <andythenorth> the ones that are subsituted by numbers?
18:53:07 <Eddi|zuHause> and then you have to change the numbers on every parameter change?
18:53:37 <andythenorth> I just put them in global_constants
18:53:45 <andythenorth> maybe you’ve spotted an issue I haven't
18:54:09 <Eddi|zuHause> maybe it works...
18:54:21 <andythenorth> unless we can do it by analysis, only one way to find out...
18:54:25 <Eddi|zuHause> mostly i don't know what exaclty you're doing
18:54:37 <andythenorth> neither do I yet
18:54:44 <andythenorth> learning by doing...
18:56:43 *** Myhorta has joined #openttd
19:04:42 <andythenorth> if I could just give nml a location for a set of extra python modules….
19:05:00 <andythenorth> with a manifest, or standard set of module names
19:05:13 <andythenorth> and then check those for constants
19:28:56 <andythenorth> python can do conditional imports?
19:30:09 <Alberth> sure if foo: import x
19:30:36 <andythenorth> it would need to add to the module search path
19:30:52 <planetmaker> try: import X; except: something else
19:31:22 <Alberth> please advice except ImportError: in such cases
19:32:20 <Xaroth|Work> what Alberth said
19:34:04 <LordAro> what planetmaker said </rebel>
19:35:18 <andythenorth> this is one of those ‘everything at once’ hacks :P
19:35:27 <andythenorth> I have to patch nml, and a newgrf
19:36:36 <andythenorth> afaict I effectively want to extend constant_numbers in global_constants.py
19:37:04 <andythenorth> so constant_numbers.append(i) for i in my_constants
19:37:18 <Xaroth|Work> from bla import global_constants
19:37:21 <andythenorth> or zip or whatever the funky python way to do it is
19:37:40 <Xaroth|Work> global_constants.constant_numbers.extend(my_constants)
19:45:41 *** Myhorta has joined #openttd
19:47:00 <andythenorth> so copying my constants into nml’s global_constants works
19:47:04 <andythenorth> so the theory is good
19:49:14 <andythenorth> as does stuffing cargo mappings into cargo_numbers in global_constants
19:49:32 <andythenorth> so that looks plausible
19:52:13 <andythenorth> ho ho Illegal character '#' (character code 0x23) at "generated/nml/box_car_brit_gen_1.nml", line 1, column 0
19:52:49 <andythenorth> doesn’t like the include
19:54:12 <Alberth> use // for comment :)
19:56:33 <andythenorth> I assumed includes would be like with cpp
19:56:41 <andythenorth> doesn’t matter, don’t need them
19:57:26 <andythenorth> Alberth: is it plausible / wise to pass the location of a module to nml?
19:57:34 <andythenorth> untrusted input etc :P
19:57:55 <Alberth> if a user gives it, why not
19:58:14 <andythenorth> I am trying to work out exactly what’s needed
19:58:18 <Alberth> oh you mean blindly import it?
19:58:47 <andythenorth> the cargo table would be fine in nml format, the existing parse just needs to be given the file I imagine
19:58:49 <Alberth> ie make it part of the nml input
19:59:20 <andythenorth> I’d like to be able to have input that is dropped from output
19:59:48 <andythenorth> I just remembered a pattern from elsewhere
19:59:56 <andythenorth> less is a macro language for compiling css
20:00:08 <andythenorth> it has the capability to import files as ‘reference only'
20:00:38 <andythenorth> so all their constants etc are available, but there is no output
20:01:02 <Eddi|zuHause> what you actually want is a difference between declaration and definition
20:01:19 <andythenorth> similarly the chameleon template language has a ‘nocall’ option for functions
20:01:25 <Eddi|zuHause> you want the cargo table defined only once, but declared in many places
20:04:20 <andythenorth> is it a good interface to declare things like that in the nml file I want to compile?
20:04:43 <andythenorth> like an import directive or such
20:04:55 <andythenorth> or is it better to pass it to nml as a compile-time flag?
20:06:43 <Eddi|zuHause> i'd rather like an import-ish statement
20:07:05 <andythenorth> I find it much more familiar for this kind of problem
20:07:13 <andythenorth> but that’s due to my experience :P
20:07:52 <Eddi|zuHause> the linker will then make sure that the stuff in the included file will only be written out once in the combined grf
20:09:57 <andythenorth> at the moment, the linker would be andythenorth :P
20:10:01 <andythenorth> this is a redneck hack
20:10:57 <andythenorth> I need to see if I can get the CTT parsed in, but not written out :P
20:11:09 <Eddi|zuHause> well my linker is an awk script embedded into a shell script
20:11:17 <Eddi|zuHause> actually, two awk scripts
20:11:47 <andythenorth> maybe there’s a compiler stage where I can dump in a boolean flag
20:12:23 <andythenorth> the joy of having no idea what you’re doing is not knowing what’s stupid :P
20:12:31 *** bdavenport has joined #openttd
20:13:07 <Alberth> it's long time ago that I could program like that :)
20:13:32 <andythenorth> there’s a horribly 7-10 year follow up stage
20:13:38 <Eddi|zuHause> just remember, the more joy you feel the more pain i feel watching you :p
20:13:40 <andythenorth> where you know what’s stupid, but not what’s good
20:13:47 <Alberth> it's a fun mode to be in, but terribly inefficient :)
20:13:56 <andythenorth> Eddi|zuHause: you don’t have kids, right?
20:14:30 <Eddi|zuHause> you're definitely not my kid .p
20:14:47 <andythenorth> I am probably somewhat too old
20:15:08 <Alberth> nobody is too old to be a kid, especially here :)
20:15:39 <andythenorth> I’m just trying to imagine Eddi|zuHause watching his kids learn stuff :P
20:16:16 <andythenorth> it’s very hard being patient with them
20:16:20 <Eddi|zuHause> i don't think that'll be an actual issue
20:19:36 <andythenorth> a general purpose import with some kind of ‘no-output’ would be more useful than special casing the cargo table :P
20:20:06 <andythenorth> then for example, industry count variable could be prevented from failing more easily :P
20:20:24 <andythenorth> otoh, parsing too many imports destroys the gain from parsing less stuff
20:25:43 <andythenorth> parsing for constants would be much slower than just providing the relevant python data structures directly?
20:27:50 <Eddi|zuHause> parsing is the same for any kind of output
20:28:40 <Eddi|zuHause> you have to do lexical and syntactic analysis anyway, you maybe can leave out some steps in the semantical analaysis, but most things you have to do as well
20:29:54 <Eddi|zuHause> anyway, the header processing takes a siginificant time for cets, but if you combine it with make -j <n> then you still make a net gain
20:30:44 <andythenorth> so parsing the ctt versus importing equivalent python dict?
20:45:31 <andythenorth> constant_numbers already contains ottd string IDs
20:46:12 <andythenorth> wonder if it’s possible / wise to append grf-specific string IDs
21:02:28 <Alberth> you definitely want to have checks you're not re-using anything that already exists
21:02:52 <Alberth> as well as letting nml know it should not use some values for its own string stuff
21:04:17 * andythenorth looks for the string stuff
21:14:46 *** andythenorth has joined #openttd
21:15:37 *** KWKdesign has joined #openttd
21:16:09 <andythenorth> I just invented a system which patches and compiles nml as part of every newgrf compile
21:16:27 <andythenorth> and it’s moderately plausible
21:16:37 <andythenorth> because obviously modifying the compiler before the compile is wise
21:16:41 <andythenorth> all the best people do it :P
21:17:40 <planetmaker> well, I can't do that on the CF as it's setup now. I can rather support an nml fork
21:18:04 <planetmaker> unless... you get a separate checkout of nml, too
21:19:58 <andythenorth> do you think this is a sign?
21:20:02 <andythenorth> there might be a better way :P
21:21:15 <planetmaker> no, I actually think it's a shortcoming of the CF. You should be able to do whatever weired things you want to do
21:21:33 <planetmaker> without me having to worry :
21:21:50 <andythenorth> but still, patching nml during the compile is batshit crazy
21:23:44 <andythenorth> I might try and extend nml to read additional constants
21:23:54 <andythenorth> passing it a json file seems like a quick route to try
21:24:18 <andythenorth> that should cover named parameters, ctt and rtt
21:25:00 <andythenorth> strings I’m not sure, I read the nml string handling src, but none the wiser on how identifiers are resolved reliably to newgrf string IDs
21:28:57 <Eddi|zuHause> i have an nml fork
21:29:24 <Eddi|zuHause> but i'm scared of updating because i can't find a python3-pillow package
21:31:05 <andythenorth> I am scared of updating too, for similar reason
21:33:19 <Eddi|zuHause> you should be banned for even thinking of putting those words together
21:46:20 <planetmaker> Eddi|zuHause, but if there were no python3-pillow we'd not have been able to do the conversion
21:46:32 <planetmaker> it's readily available.
21:47:19 <planetmaker> python3-pillow.x86_64 : Python 3 image processing library
21:47:52 *** glx is now known as Guest13004
21:48:15 <Eddi|zuHause> # zypper search python3-pillow
21:48:17 <Eddi|zuHause> No packages found.
21:48:34 <planetmaker> then pip install it
21:49:51 <Xaroth|Work> most python packages work better when installed through pip tbqfh
21:50:29 <Xaroth|Work> (most distros using outdated versions etc)
21:51:32 <planetmaker> seems I pip installed it on devzone, too
22:02:36 *** gelignite has joined #openttd
22:30:39 *** Myhorta has joined #openttd
22:48:17 *** Progman has joined #openttd
23:02:23 *** iamtakin1iteasy has quit IRC
23:15:42 <DorpsGek> planetmaker: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound)
23:20:31 *** zeknurn has joined #openttd
23:53:07 *** luaduck_zzz has joined #openttd
23:53:28 *** luaduck_zzz is now known as luaduck
continue to next day ⏵
