Log for #openttdcoop.devzone on 26th June 2014:
Times are UTC Toggle Colours
01:23:28  *** Supercheese has quit IRC
01:55:17  *** Supercheese has joined #openttdcoop.devzone
07:53:22  *** Supercheese has quit IRC
11:53:46  *** yorick has joined #openttdcoop.devzone
13:46:39  *** LSky` has joined #openttdcoop.devzone
13:51:56  <Ammler> which package is to prefer for nml? python-imaging or python-Pillow
14:41:53  *** tycoondemon has quit IRC
15:10:57  *** Alberth has joined #openttdcoop.devzone
15:49:48  *** frosch123 has joined #openttdcoop.devzone
15:51:48  <frosch123> Ammler: pillow for python3 and nml 0.4, imaging for python2 and nml 0.3
15:52:48  <Alberth> pillow probably also works for python2, if you have a python2 version
15:52:59  <Alberth> it's designed to be a drop-in replacement for imaging
15:53:21  <Alberth> hai btw :)
15:54:26  <frosch123> hola :)
15:55:33  <Ammler> thanks, trying to get nml working on old suse, but good to know :-)
15:56:17  <planetmaker> hi hi :)
15:57:20  <planetmaker> Ammler, tendentially you probably want pillow as it's the fork of PIL which is still being developed
15:58:42  <planetmaker> Ammler, all which might suffice if you get python3.2+ and pip installed. Then you can install ply and pillow using pip
15:59:27  <planetmaker> e.g. on Debian wheezy that's necessary as there's no python3-imaging (yet). The same might go for some other distributions and versions
16:01:31  <Alberth> depends on how old suse is :)
16:01:43  <Ammler> well, it was an error of chose, it usually will be defined from distro
16:06:52  <Ammler> if you need pip on suse, it is a bad sign :-)
16:07:05  *** LSky` has quit IRC
16:07:37  <Ammler> well, at least if you need it for one of the packages I maintain
16:09:29  <Ammler> I need to build python just to build nml to build opengfx :-)
16:10:43  <Alberth> build nml?  just run from the checkout :)
16:10:53  *** oskari89 has joined #openttdcoop.devzone
16:12:13  <Alberth> can we draw any conclusions from my C-scanner experiment?
16:13:02  <planetmaker> hm, I didn't do any profiling yet
16:13:52  <planetmaker> one conclusion we can draw is IMHO that's definitely feasible. And it's not much hassle either, so also viable from that POV
16:14:05  <Ammler> Alberth: well, it still needs python2.7
16:14:17  <planetmaker> Ammler, how? where?
16:14:42  <Ammler> nml for opengfx
16:15:00  <planetmaker> well, nml-0.3.x is still python2.7, yes
16:15:12  <Alberth> why would you want to use that?
16:15:24  <planetmaker> Alberth, for distros you usually ship releases :)
16:15:27  <Ammler> to get same md5
16:15:56  <Alberth> oh, ok, I thought you were building for yourself
16:16:26  <Alberth> what's with "old suse" then?
16:16:38  <planetmaker> what is 'old suse'?
16:16:42  <Ammler> sle-11
16:16:59  <Alberth> (17:55:33) Ammler: thanks, trying to get nml working on old suse, but good to know :-)  <-- that 'old suse'
16:17:03  <Ammler> they use py2.5 or lower
16:17:18  <planetmaker> aua. sorry, py2.5 is not supported anymore
16:17:37  <planetmaker> nml 0.3.x needs, iirc, at least 2.6
16:17:45  <Ammler> 2.7
16:17:57  <Alberth> and 2.6 might give you loads of errors
16:18:20  <Ammler> well, if I build python myself, I use the same version I have locally
16:19:30  <Alberth> tbh, it doesn't make a lot of sense to me
16:21:15  <planetmaker> some systems simply are too old
16:21:15  <Ammler> it is not really important, I was just wondering if it is possible at all
16:21:37  <Ammler> I like to support most available distros if possible
16:22:12  <planetmaker> Python 2.5 was released on September 19th 2006 <-- so 8 years ago
16:22:49  <planetmaker> and even 2.5.6 is 3 years old
16:22:55  <Ammler> does centos 6 have py2.7?
16:23:17  <Taede> 2.6.6
16:23:48  <Taede> 2.7 available via epel, needs to be installed alongside 2.6 though
16:23:49  <planetmaker> and 2.5.6 is source-only. Last binary was 2.5.4
16:27:52  <Taede> actually, im wrong. centos only has 2.6. if you want 2.7 or 3.x you need to manually install that alongside 2.6
16:29:34  <Alberth> yeah, you buy an operating system with batteries included, but they are all too old to be useful, so you build all batteries again yourself
16:29:34  <Alberth> now that is a useful purchase :p
16:30:08  <Taede> at least the price is right
16:30:38  <Ammler> there are people around who prefer old (stableish) stuff
16:30:41  <Alberth> even for that amount of money there are better alternatives :p
16:31:30  <Ammler> but then you need to buy every year again
16:32:10  <Ammler> so if battery gets old after a year, you can already buy old ones
16:32:14  <Alberth> old stuff is useful for your core services that do not ever change, not for development tools that compile a language that constantly changes
16:33:23  <Ammler> well, the issue is you also need the developemnt tools to build it
16:35:19  <Ammler> most important is that you can still build openttd
16:35:23  <planetmaker> you build dev tools always with dev tools
16:35:37  <Ammler> the rest could be updated via bananas :-)
16:38:00  <planetmaker> well, the important thing is if it works on the OS our players use
16:38:52  <Ammler> that is comercial view :-P
16:39:12  <Ammler> I have the idealism view ;-)
16:39:32  <Alberth> planetmaker: actually, that may not be the case :p
16:40:05  <Alberth> mobile is way bigger than desktop
16:40:12  <planetmaker> true :)
16:40:19  <Ammler> the android tablet version was done quite nicely, is that native openttd or patched?
16:40:59  <planetmaker> there is no unpatched android
16:41:12  <planetmaker> afaik. You need to ask the author / uploader
16:41:24  <planetmaker> iirc it's even a faked version number
16:41:33  <Ammler> anyway good work and up2date
16:42:05  <Ammler> he splitted the toolbar into 2 on left and right
16:42:15  <Ammler> might use big-gui
16:42:22  <planetmaker> does, afaik
16:42:37  <Alberth> looks like it, from the screen shots
16:42:58  <Ammler> added buttons to simulate ctrl and other things
16:43:43  <Ammler> hmm, did not try if it is able to join servers
16:45:12  <Ammler> I am a bit confused what the lowmem version means
16:46:50  <planetmaker> for low memory devices
16:47:04  <planetmaker> some other/additional hacks
16:48:23  <DevZone> Project ecs build #53-push: SUCCESS in 29 sec:
16:48:54  <DevZone> Project Dutch Trainset build #193-push: SUCCESS in 1 min 20 sec:
16:57:57  <Ammler> he, looks good opengfx might get to build again on old suse :-P
17:01:04  <planetmaker> Ammler, it might even happen that NML result depends on python version :P
17:01:45  <planetmaker> for instance we had windows python sort differently than linux python
17:02:11  <Alberth> it might even change between runs, I think
17:03:27  <planetmaker> even that? nice :P
17:04:13  <planetmaker> I'll try to gather some more comprehensive timing data from my collection of nml files
17:06:12  <planetmaker> hm, interesting difference for ogfx-biggui, Alberth
17:06:37  <planetmaker>
17:07:14  <planetmaker> nml-default is w/o the c-parser patch, nmlc is with the c-parser patch
17:07:51  <Alberth> it looks like a solved problem to me
17:08:39  <planetmaker> let me check...
17:09:30  <Alberth>     def t_error(self, t):
17:09:30  <Alberth>         print("Illegal character '{}' (character code 0x{:02X}) at {}, column {:d}".format(t.value[0], ord(t.value[0]), t.pos, t.column))
17:09:30  <Alberth>         sys.exit(1)
17:09:30  <Alberth> /me bets planetmaker cannot find "lineno" in this function
17:09:39  <planetmaker> one rev was missing
17:09:58  <planetmaker> but same issue with nml tip
17:11:05  <Alberth> what are you talking about exactly, there are 2 errors in that paste
17:11:17  <planetmaker> can you remind me what was the solution?
17:11:56  * Alberth tries to remember where the lexyacc patch was posted
17:12:08  <planetmaker> at your dev space iirc
17:12:14  *** gelignite has joined #openttdcoop.devzone
17:13:22  <Alberth> indeed, and it has the t_error fix
17:13:43  <Alberth>
17:14:20  <Alberth> now, what are you talking about with nml tip?
17:14:59  <planetmaker> I compared the output of patched (probably with a previous version of that patch) and unpatched nmlc. To compare timings
17:15:22  <planetmaker> but as the unpatched complains correctly...
17:15:34  <Alberth> makes sense to compare those :)
17:17:49  <planetmaker> ok, same error now :)
17:18:00  <Alberth> always useful :)
17:18:22  <Alberth> don't want planetmakers to get confused which error should be solved :p
17:18:31  <planetmaker> :P
17:55:53  *** LSky` has joined #openttdcoop.devzone
17:56:39  *** andythenorth has joined #openttdcoop.devzone
18:31:40  <planetmaker> hm... nml'c caching is significant...
18:31:48  <planetmaker> 2nd runs often are faster by more than 50%...
18:32:04  <Alberth> yep, quite :)
18:32:24  <planetmaker> the nml version I tested first thus looses by a big margin :P
18:43:47  <andythenorth> ho
18:44:04  <andythenorth> anyone care to help with my lang question? o_O
18:44:44  <Alberth> I wouldn't know what to answer
18:45:11  <planetmaker>
18:45:22  <andythenorth> I could ask a different question
18:46:21  <andythenorth> maybe
18:46:24  <planetmaker> Alberth, so we gain roughly 7%, give or take 7%, depending on NewGRF. And probably random fluctuations
18:46:35  <planetmaker> good enough to continue this path?
18:47:00  <Alberth> not so much
18:47:28  <Alberth> for NML compiles < 1 minute, it's not worth the mess
18:47:43  <andythenorth> what are you poking at?
18:47:43  <Alberth> also, I don't see useful further steps down this path
18:47:57  <Alberth> nml scanner speedup
18:48:23  <planetmaker> hm... k
18:48:43  <planetmaker> so we keep this patch around as a thought in the background...
18:48:44  <Alberth> ie the logical next step is the parser
18:48:52  <andythenorth> if we had partial compiles, most individual files would be significantly less than 1 min :)
18:48:54  <andythenorth> I reckon
18:49:01  <andythenorth> assuming 1 file per vehicle / house / industry etc
18:49:02  <Alberth> which gives you at most 16 seconds for firs
18:49:21  <Alberth> but it's a non-trivial change
18:49:40  <Alberth> the amount of python stuff you have to drag along grows very fast
18:49:42  <planetmaker> do you consider this a trivial change? (honest question)
18:49:54  <planetmaker> this = this patch I tested
18:50:04  <Alberth> not exactly trivial, but certainly not difficult
18:50:19  <Alberth> you read data from file, and push it into python
18:50:45  <Alberth> the parser takes data from python, shuffles it into new lists, and gives it back
18:50:57  <Alberth> according to the production rules
18:51:42  <Alberth> and you need to call python from C
18:52:38  <Alberth> but ultimately, at max 16 seconds gain, you're just under a minute, instead of just above it
18:53:04  <Alberth> after that comes a crapload of python
18:53:26  <Alberth> you basically have to take out the expression classes, and rewrite them in C, I think
18:53:43  <planetmaker> that sounds non-trivial indeed
18:54:09  <planetmaker> what about the partial compiles and #include directly handled?
18:54:58  <Alberth> since most code in nml is about expressions, changing them will have an impact, I think
18:55:45  <Alberth> but you're not left with much aside a set of data tables, the language system, and the sprite handling, I think :)
18:56:21  <Alberth> partial compiles should work, as you only compile the changed parts.
18:56:55  <Alberth> under the assumption that you write the collection stuff that makes it a working grf in C or so
18:57:19  <Alberth> or you're still dead in file IO :)
18:57:23  <planetmaker> how do you mean "working grf in C"?
18:57:45  <Alberth> partial compile gives you a heap of partially compiled pieces
18:57:54  <Alberth> you need to combine them to make it working
18:58:19  <planetmaker> sure. And you say that python is too slow in doing so?
18:58:22  <Alberth> ie read all pieces, decide on ID numbers etc, and write everything out to disk
18:58:51  <Alberth> depends on the file format
18:59:10  <Alberth> so not sure, tbh
18:59:41  <Alberth> but a piece does need to have meta data what IDs it needs, where to put them, what to name them, etc
18:59:52  <Alberth> so you need some form of parsing the data
19:00:01  <andythenorth> that’s what’s been troubling me in my attempt
19:00:10  <andythenorth> I can generate json from my code generator
19:00:14  <Alberth> it's probably faster than parsing text as in nml source, though
19:00:24  <andythenorth> but eddi is telling me that a proper solution has to parse all the nml to get the constants
19:00:34  <andythenorth> if the parser is the slow part, I don’t see the gain :P
19:01:00  <Alberth> cache the answer?
19:01:28  <andythenorth> I don’t know how to identify if a constant has been redefined
19:01:29  <Alberth> planetmaker: #include, hmm, you don't reduce the amount of input with #include
19:01:42  <planetmaker> no, it's two different things, for sure
19:01:42  <andythenorth> I guess you have to track where the definition was, and check the file modification
19:01:43  <Alberth> you touched the lang file?
19:02:03  <Alberth> planetmaker: so I fail to see how it speeds up things
19:02:13  <planetmaker> though I don't see how partial compiles work, if I can't tell NML how I split a file :)
19:02:30  *** Supercheese has joined #openttdcoop.devzone
19:02:36  * Alberth doesn't know either currently
19:03:08  <Alberth> I am not sure you should tell nml about it
19:03:48  <Alberth> template instantiation inside NML should have an effect, since you can do it after scanning and parsing
19:04:19  <Alberth> but you need to extend nml AST with templates then, and create a template instantiation mechanism inside NML
19:05:11  <andythenorth> partial compiles should be of already split nml files
19:05:24  <Alberth> why?
19:05:30  <andythenorth> because I understand that :P
19:05:37  * andythenorth has no compiler theory
19:05:52  <Alberth> it's relatively easy to understand I agree
19:06:01  <planetmaker> there's a few things which need being deferred to the final, total compilation:
19:06:03  <andythenorth> there is an advantage in keeping this easy to understand
19:06:11  <andythenorth> we have few maintainers
19:06:42  <andythenorth> but I am quite happy to be told I am trying to use string and glue to do something where proper science exists :)
19:06:58  <planetmaker> assignment of IDs for action0, action1, action2, action3 and action4. And the possibility to indicate some parameters being global rather than local
19:08:06  <planetmaker> so maybe it could look like nmlc -o mygrf.o mygrf.nml
19:08:15  <planetmaker> for generating an intermediate format
19:08:35  <Alberth> sure
19:08:41  <andythenorth> how do c++ partial compiles work?  Should I even ask?  :P
19:08:42  <planetmaker> and nmlc --grf mygrf.grf mygrf1.o mygrf2.o mygrf3.o mygrf4.o
19:09:04  <planetmaker> and then IDs are assigned in the order I give the object files
19:09:27  <Alberth> andythenorth: almost just like pm is saying for nml
19:09:39  <planetmaker> re-using the same for those which are declared global. And otherwise re-using the old ones over for those which are not declared global
19:10:01  <Alberth> indeed
19:10:25  <andythenorth> fwiw, my nml->nfo->grfcodec partial compile is working apart from lang
19:10:29  <Alberth> unfortunately, it involves some pieces of code that doesn't exist currently :)
19:10:34  <andythenorth> so the gaffer tape solution is provable
19:10:36  <planetmaker> ok... basically then the task is to define a 4th output method. And actually a 2nd input method
19:11:04  <planetmaker> hm... action4 (lang) is always global, by definition
19:11:11  <planetmaker> as is action0
19:11:12  <Alberth> planetmaker: and the .o file format, and telling nml not to fill in IDs
19:11:38  <planetmaker> well, yes, that's what I meant with defining to read/write an additional in/output format
19:11:44  <Alberth> kk :)
19:12:02  <planetmaker> the nml output format doesn't do that either
19:12:11  <andythenorth> not filling in IDs <- that’s kind of where I wanted to get to with lang
19:13:24  <andythenorth> sorry if I’m not adding anything here, just thinking out loud :P
19:15:01  <planetmaker> I'm not adding anything yet either. I'm trying to understand the problem and cut it down into pieces which I might try to understand :)
19:15:18  <andythenorth> do you want my gaffer tape version? :P
19:15:25  <andythenorth> I could push branches or something
19:15:27  <andythenorth> it’s horrible
19:17:13  <andythenorth> maybe I just put here what I’ve found
19:17:33  <andythenorth> - it’s quite trivial to extend global_constants to pick up author-defined constants
19:17:45  <andythenorth> so we could read those, cache them and whatever
19:18:15  <andythenorth> - I have an ugly thing that reads modification dates of my src files and only tries to call nmlc for those modified
19:18:33  <Alberth> it's called make :)
19:18:39  <andythenorth> yeah yeah I know
19:18:46  <andythenorth> andythenorth doesn’t use the tools properly
19:18:53  <andythenorth> - I’m writing out a dir of nfo and then concatenating with python, then calling grfcodec
19:19:17  <andythenorth> - lang has me stuck right now, but I could probably find an ugly solution if I tried for an hour
19:19:39  <andythenorth> after the first compile, it is *substantially* faster
19:20:41  <Alberth> you'd hope so :)
19:20:55  <andythenorth> json constants reader - could be binned and replaced with something that reads a cache file
19:20:56  <andythenorth>
19:21:22  <andythenorth> the actual json
19:22:05  <andythenorth> patched iron horse, I’m sure I’m doing it all wrong, but yeah
19:22:06  <andythenorth>
19:22:39  <andythenorth> L29 is the ‘andy won’t learn make’ dep check
19:23:01  <andythenorth> l36 is the ‘render nfo per nml file’ function
19:23:11  <Alberth> not even that long
19:25:40  <andythenorth> it’s a bit weird that it distinguishes nml header stuff and nml vehicle stuff
19:25:57  <planetmaker> that is required for every partial compilation, imho
19:26:03  <planetmaker> header = global. vehicle = local
19:26:05  <andythenorth> that’s specific to my set though, and I would change it if I pursued this route
19:26:08  <andythenorth> hmm maybe planetmaker
19:26:17  <andythenorth> dunno, I think *my* treatment of it is odd
19:26:35  <planetmaker> there can only be one header per grf. but many vehicles. Thus one has to take some care there
19:27:08  <andythenorth> would we ever want to guide authors with a structure?
19:27:28  <andythenorth> some stuff, e.g. cargotable, leans towards saying ‘always just put this in cargotable.nml'
19:27:29  <andythenorth> imo
19:27:35  <andythenorth> but I don’t know if we want to do that
19:28:51  <Alberth> as first guide it's not so bad to give structure
19:28:53  <planetmaker> I would not force that. But the final compilation has to check for them to not be there twice (or at least warn then).
19:29:05  <planetmaker> but some structure... possibly
19:29:20  <Alberth> but you should distinguish between 'must' and 'is one way to do it'
19:29:39  <andythenorth> I honestly wonder about providing an extra program, as a wrapper around raw nmlc
19:29:41  <planetmaker> one could possibly force things to be in some order, like all global definitions coming in front of the usual action 0/1/2/3
19:29:53  <andythenorth> like a tiny framework that works with certain named files and dirs
19:30:02  <andythenorth> Alberth: what did we use for eints?  Bottle or flask?
19:30:18  <Alberth> btw am I right in thinking there are 2 kinds of expressions,  action 2 and action D ?
19:30:32  <Alberth> andythenorth: not flask
19:30:35  <planetmaker> in NML? No. But in nfo: yes
19:30:50  <planetmaker> No, as in it looks the same for the user. Internally, yes
19:31:14  <Alberth> where are these expressions in nml source?
19:31:26  <Alberth> I mean in a .nml file
19:31:52  <Alberth> or does nml detect automagically which one you use?
19:32:13  <andythenorth> probably bottle, but anyway, my point is that I have used *big* web frameworks, and I have used *small* ones.  And this is quite a small problem
19:32:15  <planetmaker> switch
19:32:29  <planetmaker> it detects what is needed depending on the variable name
19:32:33  * andythenorth isn’t proposing using a web framework btw :P
19:32:55  <planetmaker> though some actionD are also like if (...) { (...) }
19:32:57  <planetmaker> hm...
19:33:55  <Alberth> andythenorth: I am quite lost on what you're trying to do :)
19:33:57  <andythenorth> wtf is andythenorth talking about
19:34:09  <andythenorth> sorry, doing too many things at once
19:34:13  <andythenorth> I’ll eat food and come back :P
19:34:23  <Alberth> kk, enjoy the foods :)
19:34:27  <andythenorth> you can talk sensibly without me
19:34:38  <Alberth> like we ever do that :p
19:35:34  <Alberth> so "switch" is one, which is the other? or is that also "swtich" ?
19:38:53  <andythenorth> yum, bacon
19:39:54  <Alberth> nah, that's not a keyword in nml :p
19:39:59  <planetmaker> let me investigate before I talk nonsense, Alberth :)
19:40:16  <Alberth> I wouldn't notice :)
19:40:36  <andythenorth> so wtf is andythenorth talking about?
19:40:37  <planetmaker> sooner or later, you would :P
19:40:45  <andythenorth> I’m not sure it’s even a problem, but...
19:40:49  <Alberth> :)
19:40:51  <andythenorth> I was wondering about:
19:41:02  <planetmaker> Alberth, so, actionD definitely is used in all those variable manipulations
19:41:06  <andythenorth> - nmlc carries on as now, you pass it [whatever.nml] and it just compiles it all, fast or slow
19:41:19  <planetmaker> thus everytime we have a more complicated argument in a switch
19:41:27  <andythenorth> - if you follow some directory and filename conventions, and pass a flag, it uses that for partial compiles
19:41:30  <planetmaker> or even go for the [ ... ] thing in the switch
19:41:57  <Alberth> as soon as you use param[] perhaps?
19:42:12  <andythenorth> so author can do my_big_file.nml, or vehicles/vehicle_1.nml etc
19:42:20  <andythenorth> meh, it’s probably a non-problem
19:42:30  <planetmaker> Alberth, not only param[]
19:42:34  <planetmaker> STORE_TEMP etc
19:42:42  <planetmaker> also like a + b
19:43:02  <planetmaker> switch(FEAT_TRAINS, id, switch_name, var_a > var_b) { }
19:43:12  <planetmaker> it's a comparison which requires actionD
19:43:26  <Alberth>   <-- maybe ask the other way around, when is this used?
19:43:44  <planetmaker> hm...
19:44:03  <planetmaker> possibly I just told wrongly. meh
19:44:13  <Alberth>  cmp  seems to be compare too
19:44:33  <planetmaker> so yes, param[] is it definitely
19:45:05  <Alberth>  and this is the other page
19:45:16  <planetmaker> yeah, I just read those :P
19:47:13  <frosch123> <- all conditions in there are action7/9/D
19:47:37  <Alberth> difference between kind of static parameter calculations (which also seems to use action 6 to write the results), and callback which are more dynamic would make sense
19:47:43  <frosch123> i.e. the "if" stuff and all conditions in "property"
19:48:14  <frosch123> action 7/9/D uses grf parameters and constants
19:48:25  <frosch123> everything else uses switches and action2
19:48:54  <planetmaker> so... if --> 7/9/D
19:49:00  <Alberth> and this 7/9/D is just a one-time calculation
19:49:01  <planetmaker> switch --> VA2
19:49:03  <Alberth> ?
19:49:15  <frosch123> yes, it's initialisation
19:49:23  <frosch123> only run once on game start/load
19:49:46  <Alberth> nice, it starts to make some what sense :)
19:50:03  <Alberth> although of course you need 2 forms of expressions in one language :p
19:51:09  <frosch123> thus it may only use grf parameters and constants, which includes stuff like "cargotype_available", "railtype_available", checking for other grfs, "reserve_sprites" and some more
19:51:39  <Alberth> yeah, nml as a "supports_D" flag
19:51:49  <Alberth> *has
19:52:07  <frosch123> neither is a subset of the other
19:52:26  <frosch123> some vars are available to both D and 2, some only to 2, but some also only to D
19:52:33  <Alberth> :)
19:52:38  <frosch123> though with D+6 you can put it into a 2
19:53:08  <Alberth> you do that in nml with a store_perm or so?
19:53:39  <frosch123> no, nml does that on its own
19:54:07  <frosch123> if you use "palette_2cc" within a switch, nml implicitly constructs D+6+2
19:54:46  <Alberth> ah, you just write an expression, and nml decides what can be executed one time
19:54:57  <Alberth> nice
19:58:39  <frosch123> 6/7/9/D can be compared with a dynamic linker, which attaches shared libraries to a program on start
19:59:02  <frosch123> unknown at compile time, but constant at run time
20:00:39  <Alberth> so you want to do as much as possible there, and then you have to do whatever remains in action 2
20:00:59  <frosch123> kind of, but do not only "want to", sometimes you even "have to"
20:01:30  <frosch123> action 2 just cannot access everything directly
20:01:37  <Alberth> due to limitations in what you can used in D or 2
20:03:15  <frosch123> yes, but the limitations of D are in it's nature (as in run upon grf load), while the 2 restrictions are arbitrary without an actual reason
20:03:42  <Alberth> as in OpenTTD doesn't support it :p
20:05:21  <Alberth> so basically a grf is a set of tables with vehicle properties, or industry properties etc, and you use D and 2 expressions to choose what to use
20:05:37  <planetmaker> we could change the "does not support it" part, if it would help a lot, I guess
20:05:59  <frosch123> planetmaker: no, it does not help particulary much
20:06:08  <Alberth> based on static parameters or dynamic game situation
20:06:36  <frosch123> you need the d+6 stuff anyway, so it does not matter if you need to use it for more stuff
20:11:42  <Alberth> switches seem a bit weird in nml, don't they?  they do not obviously belong to some vehicle, or it's not immediately clear what they are used for
20:12:05  <Alberth> it's defined just by the variables???
20:12:07  <frosch123> same as with procedures in c :)
20:13:12  <Alberth> I don't remember mentioning a switch name near an industry as callback or so, could be wrong though
20:13:36  <Alberth> I'll have to check that
20:14:10  <frosch123> hmm?
20:14:42  <frosch123> you just put the top-level switch into the "item"
20:15:11  <Alberth> ah, the switch itself has the link
20:16:13  <frosch123> <- there is an example in the middle
20:16:31  <frosch123> the "graphics" block within the "item" block links to "switch" blocks
20:17:02  *** tycoondemon has joined #openttdcoop.devzone
20:18:57  <Alberth> callback_to_switch:      switch_identifier;   <-- that "switch_identifier" is <ID> in the switch    switch (<feature>, (SELF|PARENT), <ID>, <expression>) {
20:19:11  <Alberth> right :)
20:19:27  <frosch123> yup
20:21:43  <Alberth> ok, thanks for the short crash course nml/nfo :)
20:21:56  <andythenorth> it’s easily learnt
20:22:00  <andythenorth> it only took me about 4 years
20:22:17  <Alberth> I shall read stuff again with this in mind, hopefully things will fall into place
20:24:12  <Alberth> the entire problem with actions is that everybody talks about action X, but no explanation how they relate, or what their purpose is in the goal of newgrfs
20:24:42  *** tycoondemon has quit IRC
20:24:56  <Alberth> even the nml code has variables "acts6" which no doubt contains action 6-es, but no clue what they actually do :)
20:25:09  <planetmaker> 0->3->2->1 for each feature
20:25:31  <planetmaker> action6 is a self-modifying code, changing the subsequent sprite, thus allowing parametrizing things
20:25:32  <Alberth> see?  all numbers :)
20:25:42  <planetmaker> yeah :)
20:25:51  <planetmaker> 4 is textID <-> text
20:25:52  <Alberth> no worries, I'll figure it out
20:26:23  <Alberth> 51, 36, and some 67 will do
20:26:30  <planetmaker> :)
20:27:04  <planetmaker> 0->3->2->1 is in NML like item->graphics block->switches->spritesets
20:27:06  <andythenorth> it helps if you had to write a lot of nfo :P
20:27:48  <planetmaker> action4 is the lang file along with the places where a string is used
20:28:07  * Alberth makes notes
20:28:08  <planetmaker> actually without those places
20:28:23  <planetmaker> action4 really is only textID <-> actual text.
20:29:19  <planetmaker> action5 is new sprites like the OpenTTD GUI sprites, everything which is needed for basesets, but not in original TTD (openttd.grf contents in largest parts)
20:29:45  <planetmaker> action7 and 9 are conditional jumps
20:30:13  <planetmaker> action8 is clear, I think. It defines the grf, the grfID
20:30:37  <Alberth> the hgher number have a clearer meaning
20:30:38  <planetmaker> actionA is simple sprite replacement for the TTD baseset sprites
20:31:11  <planetmaker> yeah. As usual. the higher / newer things are, the easier and better-defined
20:31:36  <Alberth> ok, thanks
20:31:45  <Alberth> it will need time to sink in :)
20:32:36  <planetmaker> it does. I understand that :)
20:32:44  <Alberth> and probably an experiment or two in making nml, or a compiler or so, not sure what the best approach is
20:32:50  <planetmaker> I guess those are just fuzzy memories from the pre-nml era :)
20:33:35  <planetmaker> syntactically I can write simple nfo grfs. But my vocabulary is practically non-existant :P
20:33:37  <Alberth> perhaps making a compiler for manindu :p
20:34:37  <planetmaker> my problems with nfo start when it comes to variable manipulation or when I have to know a property or variable number :)
20:35:07  <planetmaker> or know what actions > action8 do :P
20:35:28  <Alberth> yeah, you don't want to write expressions manually, a compiler can do that much quicker and better
20:37:57  <Alberth> one advantage with computer programming, you don't need to know details, just where to find them if you need it
20:38:11  <Alberth> also, a computer is much better at doing repetitive work :p
20:38:45  <planetmaker> yeah, indeed
20:38:54  <planetmaker> we have computers so that we can be lazy
20:38:58  <planetmaker> at least on my part ;)
20:39:13  <Alberth> yeah, but being lazy is hard work :P
20:39:15  <andythenorth> I miss nfo sometimes
20:39:27  <andythenorth> it taught me some useful basic principles
20:39:46  * Alberth gives andythenorth a few pages of random hex bytes
20:40:05  *** oskari89 has quit IRC
20:40:27  <Alberth> I can see the value in knowing what's happening
20:40:38  <Alberth> I prefer to know that too
20:41:09  <Alberth> as it makes explaining weirdnesses at a higher level much easier
20:42:00  <planetmaker> the problem really is the necessary expression generator needed. That adds to so much expansion it's hard to follow :)
20:42:00  <Alberth> also, for code generation, you really need to understand what you have to generate
20:42:27  <planetmaker> already for simple stuff it's really amazing to see the needed nfo
20:43:13  <Alberth> code generators are usually much more stupid than manual coding
20:43:25  <Alberth> ie you get more output
20:43:40  <Alberth> also, your notion of "simple" shifts
20:44:25  <Alberth> just compare average stuff you do nowadays with a computer, with what you did say 5 or 10 years ago
20:45:03  <planetmaker> yes... but the operations in nfo are very simple. And possibly my understanding of what constitutes a "simple expression" is skewed by me working with such things daily at work :P
20:46:17  <Alberth> you can write amazingly complex expressions in one line :p
20:46:41  <Alberth> you wouldn't dream of doing that if you had to write the nfo yourself
20:46:59  <Alberth> you'd be more careful in selecting variables, and values
20:47:55  <planetmaker> absolutely
20:48:29  <planetmaker> the 5-line terrain-awareness I use, that expands to dunno, several dozen lines of NFO
20:49:03  <Alberth> nml allows you to concentrate on the problem you want to solve instead
20:49:16  <Alberth> at the cost of more nfo output, and bigger grf files
20:49:26  <Alberth> and slower execution probably
20:50:36  <Alberth> if you read the actionD python file, it's amazing what tricks get pulled to make it appear you can use any operator you like instead of just the few you actually have :)
20:50:54  <planetmaker> yeah, that's complex
20:50:59  <planetmaker> quite complex
20:51:59  <Alberth> I do such rewrites more often at work, it didn't scare me, it was quite fun to read :)
20:52:51  <Alberth> kk, time to go to bed
20:53:14  <Alberth> good night
20:54:00  *** Alberth has left #openttdcoop.devzone
21:06:16  *** andythenorth has quit IRC
21:35:54  *** frosch123 has quit IRC
22:10:25  *** LSky` has quit IRC
22:11:04  *** gelignite has quit IRC
23:13:59  *** yorick has quit IRC

Powered by YARRSTE version: svn-trunk