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: https://jenkins.openttdcoop.org/job/ecs/53/ 16:48:54 <DevZone> Project Dutch Trainset build #193-push: SUCCESS in 1 min 20 sec: https://jenkins.openttdcoop.org/job/dutchtrains/193/ 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> https://paste.openttdcoop.org/show/3468/ 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> http://devs.openttd.org/~alberth/diffs/1_c_lex.patch 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> https://paste.openttdcoop.org/show/3469/ 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> http://paste.openttdcoop.org/show/3470/ 19:21:22 <andythenorth> the actual json http://paste.openttdcoop.org/show/3471/ 19:22:05 <andythenorth> patched iron horse render_nml.py, I’m sure I’m doing it all wrong, but yeah 19:22:06 <andythenorth> http://paste.openttdcoop.org/show/3472/ 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> http://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced <-- 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> http://newgrf-specs.tt-wiki.net/wiki/ActionD and this is the other page 19:45:16 <planetmaker> yeah, I just read those :P 19:47:13 <frosch123> https://dev.openttdcoop.org/projects/manindu/repository/entry/src/manindu.pnml <- 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> http://www.tt-wiki.net/wiki/NMLTutorial/Callback_and_switch <- 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