Times are UTC Toggle Colours
00:08:09 *** LordAro has quit IRC 01:15:13 *** Nat_aS has joined #openttdcoop.devzone 01:22:43 *** Dr_Tan has quit IRC 01:35:37 *** NataS has joined #openttdcoop.devzone 01:43:04 *** Nat_aS has quit IRC 02:58:35 *** Dr_Tan has joined #openttdcoop.devzone 03:05:29 *** NataS has quit IRC 05:04:46 *** Diablo has joined #openttdcoop.devzone 05:05:02 *** Diablo has left #openttdcoop.devzone 06:12:47 *** ODM has joined #openttdcoop.devzone 07:09:36 *** LordAro has joined #openttdcoop.devzone 07:51:35 *** Alberth has joined #openttdcoop.devzone 07:51:56 <Alberth> I was missing a window ;) 08:18:30 *** frosch123 has joined #openttdcoop.devzone 08:28:36 <Rubidium> nml takes quite a bit of time with ogfx1_base in zbasebuild 08:38:06 <Alberth> yep, with only around 300 32bpp sprites added so far 08:38:52 <Alberth> mess a bit with sprites, type "make", do something else for 15 minutes :) 08:43:11 <Rubidium> almost easier to test code first with newgrf and then just dump it in the zbase (and build+test with lots of sprites at once) 08:43:45 <Rubidium> nml -u instead of nml -c might help a bit 08:44:09 <Rubidium> about 4 minutes instead of 10 09:30:58 <Brot6> zBase - Bug #4083 (Resolved): depot too big / not even thick walls XAlberthX @ http://dev.openttdcoop.org/issues/4083 09:30:58 <Brot6> zBase - Bug #4083 (Resolved): depot too big / not even thick walls XAlberthX @ http://dev.openttdcoop.org/issues/4083#change-11172 09:33:39 <Alberth> How can you close a ticket?? #4083 doesn't close; the status only has 'resolved' in its list, but that apparently does not imply closed. 09:33:40 <Brot6> Alberth: #4083 is http://dev.openttdcoop.org/issues/show/4083 "Bug #4083: depot too big / not even thick walls - zBase - #openttdcoop Development Zone" 09:34:01 <Alberth> Bleh Brot6 09:35:21 <Alberth> oh, access rights of course :p 09:35:50 <Alberth> does it make sense to allow setting to 100% done then? 09:41:04 <Hirundo> Alberth: I have been and am working on making NML faster by caching real sprites 09:41:41 <planetmaker> moin 09:42:00 <Hirundo> What do I need to use zBase for testing? 09:42:10 <Hirundo> zBase, zBaseBuild and opengfx ? 09:42:19 <Hirundo> moin 09:42:30 <planetmaker> yes 09:42:42 <planetmaker> and they need to be named just like that 09:43:44 <planetmaker> lrwxr-xr-x 1 ingo staff 16 19 Jul 21:49 terrain -> ../zbase/terrain 09:43:49 <planetmaker> zbase actually 09:44:19 <Alberth> moin planetmaker Hirundo 09:44:31 <Alberth> Hirundo: nice, that should help :) 09:44:47 <planetmaker> Alberth: only developers and managers of a project can close issues 09:45:09 <planetmaker> should I make you one of zbase? I guess 09:45:11 <Alberth> yeah, I figured as much 09:45:48 <Alberth> oh, no problem, one of the zbase devs can close it when they feel like it :) 09:45:58 <planetmaker> made you dev of it 09:46:07 <Alberth> bummer :) 09:46:13 <planetmaker> there's only one zbase dev till then. Now two :-P 09:46:52 <Alberth> thanks :) 09:47:45 <Brot6> zBase - Bug #4083 (Closed): depot too big / not even thick walls XAlberthX @ http://dev.openttdcoop.org/issues/4083 09:47:45 <Brot6> zBase - Bug #4083 (Closed): depot too big / not even thick walls XAlberthX @ http://dev.openttdcoop.org/issues/4083#change-11174 11:28:24 <Brot6> NewGRF Meta Language - Revision 1931:8eaf5047d94e: Remove: Now-unused command-line parameter 'sprite... XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8eaf5047d94e 12:07:10 *** LordAro has quit IRC 12:07:35 *** LordAro has joined #openttdcoop.devzone 12:08:18 *** LordAro has quit IRC 12:08:44 *** LordAro has joined #openttdcoop.devzone 12:11:32 *** LordAro has quit IRC 12:12:00 *** LordAro has joined #openttdcoop.devzone 12:12:37 <Alberth> Hirundo: http://paste.openttdcoop.org/show/1567/ <-- to prevent generation of 'parsetab.py' on each run. 12:13:45 <Hirundo> Does it do that o_0? I thought it was cached 12:14:27 <Alberth> yeah, in that file :p 12:14:42 <Alberth> or are special things done during install ? 12:14:54 <Alberth> I am running trunk, uninstalled basically 12:15:05 <Hirundo> same here 12:16:26 <Alberth> rm regression/parsetab.py ; make -C regression 001_action8 ; ls regression/parsetab.py 12:16:31 *** LordAro has quit IRC 12:17:08 *** LordAro has joined #openttdcoop.devzone 12:18:58 <Hirundo> My parsetab.py dates back to february 12:19:48 <Alberth> it builds that file on the first run, or when you touch the rules, I guess 12:20:52 <Hirundo> regression/parsetab.py may be removed by the regression makefile (if using 'clean') 12:22:03 <Alberth> I get the file in zbasebuild, ie the directory where nml is running 12:24:08 <Alberth> ply will build the tables in memory each time if it cannot load this file, but I think it's fine, as the grammar is not that large 12:46:01 <Brot6> zBaseBuild - Revision 16:92b697b93be9: Add: road, monorail, maglev depots, fixed (mostly) rail depot... XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/92b697b93be9 13:01:20 *** LordAro has quit IRC 13:03:24 *** LordAro has joined #openttdcoop.devzone 13:16:32 <Brot6> zBase - Bug #4084 (New): depot blender challenges XAlberthX @ http://dev.openttdcoop.org/issues/4084 13:38:22 <Ammler> planetmaker: installed rhodecode on port 5000 (needs ssl tunnel) 13:39:00 <planetmaker> oh :-) 13:39:12 <Ammler> looks like we sould also need ldap to share the accounts easiest 13:40:27 <Ammler> hmm, let me try to clone a big repo :-) 13:42:12 <Ammler> hmm cloning of ogfx-trains needs 30min 13:42:22 <Ammler> when does it usually brak? 13:42:41 <Alberth> before the end? :) 13:43:34 <Ammler> well, I thought, it is always same time 13:43:36 * Alberth is bored of zbase coding 13:43:47 <Ammler> same amount of bytes downloading 13:44:16 <Alberth> would probably be route dependent 13:44:38 <Alberth> as well as time of day and/or week and/or year 13:50:43 <Ammler> nono 13:50:59 <Ammler> well, I could try myself but I just wait :-P 13:51:17 <Ammler> hmm, download now 40mins :-P 14:03:22 <Ammler> marcel@xps:~/test> hg clone http://admin@localhost:5000/ogfx-trains 14:03:24 <Ammler> destination directory: ogfx-trains 14:03:25 <Ammler> requesting all changes 14:03:27 <Ammler> adding changesets 14:03:28 <Ammler> adding manifests 14:03:30 <Ammler> adding file changes 14:03:31 <Ammler> added 728 changesets with 119741 changes to 45149 files 14:03:33 <Ammler> updating to branch default 14:03:34 <Ammler> 20043 files updated, 0 files merged, 0 files removed, 0 files unresolved 14:03:36 <Ammler> marcel@xps:~/test> du -sh ogfx-trains/ 14:03:37 <Ammler> 2.2G ogfx-trains/ 14:04:10 <Ammler> so it's an issue of nginx or gunicorn 14:20:02 <dihedral> Alberth, are you familiar with using osgi? 14:20:29 <Alberth> unfortunately, somewhat 14:20:43 <Alberth> I use it at work 14:22:06 <dihedral> unfortuantely? 14:22:16 <dihedral> is there something else you prefer? 14:23:14 <Alberth> no, I just hate Eclipse 14:23:32 <dihedral> you do not need to go the eclipse way :-P 14:24:03 <Alberth> please explain that to my co-workers :p 14:24:07 <dihedral> eclipse uses equniox, there is also felix for example 14:24:12 <dihedral> :-D 14:24:20 <dihedral> well, let me explain my main issue 14:24:30 <Alberth> oh, osgi in its own is quite useful 14:25:04 <dihedral> currently i use a single classloader, adding an extra url (./plugins) to look for further .jar files, and to load them, and by making use of spi I load classes 14:26:03 <dihedral> jar1 is loaded by default and does all the spi stuff, jar2 is loaded separately 14:26:48 <dihedral> if jar 2 now tries to this.getClass().getClassLoader().getResourceAsStream("some/file.txt"); 14:27:09 <dihedral> and exactly this file path exists in jar1, the file from jar1 is read, not the file from jar2 :-P 14:27:47 <dihedral> is it a) better to use a separate classloader for each jar? or would it make sense to stop trying to increase the use of spi and hop on to the boat of osgi? 14:28:14 <dihedral> s/or would/or b) would/ 14:28:14 <Brot6> dihedral meant: "is it a) better to use a separate classloader for each jar? or b) would it make sense to stop trying to increase the use of spi and hop on to the boat of osgi?" 14:28:22 <Alberth> wouldn't an absolute path work ? 14:28:48 <dihedral> with /home/blah/dev/plugins/jar2.jar!/some/file.txt ? 14:28:51 <dihedral> tried that 14:28:55 <dihedral> does not seem to find the file 14:29:21 <dihedral> and as long as everything is still in a jar file, i do not know how to access it other than getResourceAsStream() 14:30:16 <Alberth> there isn't much else you can do with a txt file :) 14:30:18 <dihedral> or do i not need the exclamation mark? 14:31:05 <dihedral> :-P 14:31:27 <dihedral> i mean with new File(...) for example 14:31:28 <Alberth> iirc there was a special character, not sure whether you need it or whether it is ! There are several subtle different ways of pointing to a file 14:31:45 <dihedral> hmm 14:31:51 <Alberth> some are url-ish, other are file-system-ish 14:34:00 <Alberth> osgi (the little I know about from plugin development) completely separates packages. You cannot ask what other projects exist or get some entry point 14:34:23 <Alberth> but perhaps that's eclipse doing weird things :( 14:35:34 <dihedral> so you have no chance of plugin dependencies?? that cannot be correct, as even plugins in eclipse can depend on functions provided by other plugins 14:36:14 <Alberth> oh you can have plugins, but there is an import list 14:36:44 <Alberth> and an export list too (expose these packages to other plugins) 14:37:08 <Alberth> so you can only import code from projects on the import list 14:37:47 <dihedral> currently osgi makes my head explode :-P 14:37:56 <Alberth> yeah 14:38:01 <dihedral> i fail to see how i could drop all my spi stuff and use osgi instead 14:38:09 <Alberth> too abstract too generic and not well documented at all 14:38:54 <Alberth> basically you have to read internet blog and articles to get an understanding, afaik 14:39:05 <dihedral> i'm fucked! 14:39:07 <dihedral> :-D 14:39:19 <Alberth> welcome to java, dihedral :) 14:40:00 <Alberth> although the various web frameworks in Python are also very good in this 14:40:35 <Alberth> but maybe I am getting too old :) 14:41:18 <dihedral> even in the java irc channel i got bashed and told all the time to use osgi, and only pointed to the official tutorials which imo suck 14:41:42 <dihedral> spi on the other hand + reflections make things a lot more easier 14:41:55 <dihedral> at least in my little world 14:42:08 <Alberth> until you hit a limit, like some/file.txt :p 14:43:00 <dihedral> yep 14:43:13 <dihedral> if i remove the directory and file from jar1 i have no issue though :-P 14:43:44 <dihedral> it's just that i found out that it will load the first file it finds, undless i find a way to specify a fixed jar file to look inside :-P 14:43:48 <Alberth> Probably a lot of my confusion comes from eclipse tbh, but I find it all too much to grasp 14:46:03 <dihedral> i am happy not to be the only one :-P 14:47:21 <Alberth> http://devel.se.wtb.tue.nl/trac/cif/browser/cif2/branches/chi3-typechecker-196-7/src/common/nl.tue.app.framework/src/nl/tue/app/framework/javacompiler/JarClassLoader.java 14:47:22 <Webster> Title: /cif2/branches/chi3-typechecker-196-7/src/common/nl.tue.app.framework/src/nl/tue/app/framework/javacompiler/JarClassLoader.java – CIF (at devel.se.wtb.tue.nl) 14:49:06 <Alberth> that's what we use to get a 'main' class from a jar file 14:49:53 <Alberth> don't know whether it is of any use to you 14:50:32 <dihedral> http://dev.openttdcoop.org/projects/grapes/repository/show/src/main/java/org/openttdcoop/dev/grapes/plugin 14:50:34 <dihedral> :-D 14:52:42 <Alberth> not, judging by the imports :) 14:53:04 <dihedral> hehe 14:54:23 <dihedral> IF i create a separate classloader for each jar file, my problem will be, plugins interacting with eachother, as no plugin will be able to know the other 14:54:46 <dihedral> simply by there being no chance of knowing the class definition 14:55:53 <Alberth> tbh, I think plugins are more trouble than they are worth 14:56:26 <dihedral> how else is one going to be able to create a modular app? 14:56:43 <Alberth> euhm, how do they interact if they don't know each other? 14:57:11 <Alberth> since when is it good that a module does not know what other modules it talks to? 14:57:18 <dihedral> my aim is/was that grapes mainly do nothing else than plugin handling, and everything else being handled by plugins 14:57:37 <dihedral> Alberth, that is why i only use ONE classloader 14:57:47 <dihedral> as otherwise i cannot know the other plugins 14:58:50 <Alberth> sounds to me like you conflicting requirements 14:58:56 <Alberth> +have 14:59:22 <Alberth> you want plugins to know each other, but not interfer in any way 15:01:37 <dihedral> no, i want a way that inside jar2 i can access a resource located in jar2 15:01:54 <dihedral> no matter if jar1 has a resource unter the same path 15:02:01 <dihedral> relative path of course 15:02:30 <dihedral> and the special char is '!' so /path/to/jar.jar!/path/to/resource.txt 15:02:42 <dihedral> however, it cannot be used with the File class 15:04:57 <Alberth> make a separate classloader for each with a parent to some code that allows querying class loaders of other plugins? 15:05:22 <Alberth> although that sounds an awful lot like some osgi-ish thing 15:06:05 <dihedral> :-D 15:06:38 <dihedral> there must be a more simple way to force accessing a file inside a very specific jar 15:07:52 <dihedral> and then i'll simply create a wrapper method somewhere 15:08:08 <dihedral> or i write my own classloader :-D 15:10:30 <dihedral> well, own classloader would cause more issues than relieve 15:20:09 <dihedral> this.getClass().getProtectionDomain().getCodeSource().getLocation() this gives me the path of the jar file that the code is executed in 15:20:45 <dihedral> specifically it ran from a password plugin jar file and returned /home/nathanael/Development/grapes/../berries/plugins/password-0.1-SNAPSHOT.bundle.jar 15:21:25 <Alberth> and such nested objects don't scare you? 15:22:36 <Hirundo> I have trouble downloading zbase, connections get interrupted -> transactions rollback 15:22:57 <Alberth> Ammler: ^^ test-person 15:23:41 <Alberth> yeah, zbase is too big for http 15:23:59 <Alberth> you could try loading only a few revisions at a time 15:25:01 <planetmaker> Hirundo: you can try via ssh. Your key is installed on the server 15:25:23 <Hirundo> Alberth: I'm doing just that at the moment 15:25:31 <dihedral> too big for http?? 15:25:44 <dihedral> i download gigabytes via http ... :-P 15:26:00 <Alberth> dihedral: either that or too many interactions between server and client 15:28:10 <dihedral> uh - found a very nasty workaround :-P 15:29:04 <Hirundo> planetmaker: I don't know if my private key survived several reinstalls and switching from cygwin to a VM 15:29:33 <planetmaker> that I don't know either ;-) 15:35:11 <dihedral> Alberth, :-D 15:35:13 <dihedral> \o/ 15:35:18 * dihedral jumps for joy 15:35:30 <dihedral> this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI().resolve("jar:" + this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI() + "!/dictionaries/words6.txt").toURL(); 15:44:50 <dihedral> ops even simpler :-P 15:45:05 <dihedral> new URL("jar:" + this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI() + "!/dictionaries/words6.txt); 16:18:11 <Brot6> Berries - Revision 33:87d98202b8fc: Fix: only read the passwords file inside this jar file (fixes #2... XdihX @ http://dev.openttdcoop.org/projects/berries/repository/revisions/87d98202b8fc 16:18:11 <Brot6> Berries - Bug #2327 (Closed): Read passwords file only from own plugins jar XdihX @ http://dev.openttdcoop.org/issues/2327#change-11175 16:23:14 <dihedral> Alberth, http://dev.openttdcoop.org/projects/grapes/repository/diff/src/main/java/org/openttdcoop/dev/grapes/plugin/PluginDescriptor.java?rev=706dcdf51cb9&rev_to=4fb883f4255a 16:23:41 <Brot6> Grapes - Revision 152:a181f945126b: Change: ingore XdihX @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/a181f945126b 16:23:41 <Brot6> Grapes - Revision 153:83294c8ece6c: Change: knowing which plugin causes an Exception while its init(... XdihX @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/83294c8ece6c 16:23:41 <Brot6> Grapes - Revision 154:706dcdf51cb9: Add: Methods to get URL / InputStream Objects from a resource lo... XdihX @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/706dcdf51cb9 16:25:19 <Alberth> dihedral: nice ! quite simple 16:25:40 <dihedral> indeed 16:25:57 <dihedral> why is it not documented anywhere - i googled for this issue quite a few times 16:26:17 <dihedral> and where could i document it without opening a blog myself :-P 16:27:20 <Alberth> in the java file? :) 16:49:08 <Brot6> zBase - Bug #4085 (New): 'jitter' in the bricks of the copper ore mine animation XAlberthX @ http://dev.openttdcoop.org/issues/4085 16:51:15 <Brot6> zBaseBuild - Revision 17:2134a4302bd7: -Add: copper ore mine, diamond mine, fixed coal mine. XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/2134a4302bd7 16:54:18 <dihedral> Alberth, if google reads that :-P 16:54:54 <Alberth> it does probably, but it does not return it to you :p 16:57:12 <dihedral> iirc they have stopped reading publicly available source files, or rather they do not show them in the results anymore 16:58:10 <Alberth> makes sense, there is little information in them, except for a few 16:58:36 <Alberth> but extracting the information is way too complicated 17:06:44 <dihedral> google codesearch was lovely :-P 17:07:23 <Alberth> oh, that actually existed? Never knew that :) 17:09:27 <dihedral> you could search for language, etc. 17:09:37 <dihedral> they now only provide that for projects on google code 17:10:28 <dihedral> if in java you needed examples of certain packages being used it was very helpful :-P 17:10:39 <Alberth> I can imagine :) 17:11:30 <Alberth> hmm, one whole day of work, just about 60*3 new sprites added 17:12:10 <Rubidium> Alberth: that sucks :( 17:12:22 <Rubidium> did you try nmlc -u instead of nmlc -c for a speedup? 17:12:58 <Rubidium> that leaves out cropping and compressing the sprites, which yielded a ~60% speed up last time I tried 17:13:30 <Alberth> no, but I haven't build many times, i was mostly messing with the sprite aligner for each depot 17:14:27 <Alberth> and the computations ran in parallel with my natural breaks, like lunch, coffee, and dinner :) 17:15:52 <Alberth> we should make a file with sprite offsets that you can edit from within openttd with the sprite aligner :p 17:19:39 <Brot6> nml: update from r1930 to r1931 done - http://bundles.openttdcoop.org/nml/nightlies/r1931 17:51:11 <planetmaker> it might speed up things considerably, if opengfx sprites were converted to DOS. Then we could use grfcodec instead of nmlc 17:52:26 <Alberth> I was somewhat pondering to attach a small program to nml to do the heavy calculation stuff 17:53:01 <Alberth> except 17:53:18 <Alberth> I have so many other things to do already :p 17:58:53 <planetmaker> which calculation, Alberth? 18:00:29 <Alberth> whatever nml is doing after deciding what to generate, mostly 18:01:05 <Alberth> Python is bad at byte/bits pushing, you should do that in C or cython or so 18:03:44 <Alberth> ie the experiment by RB suggests it spends 6 minutes on compressing/cropping images 18:06:16 <Rubidium> Alberth: simpler would be generate the nfo, let grfcodec do the compressing/cropping 18:06:20 <planetmaker> ah. You mean to out-source the sprite processing 18:06:49 <planetmaker> Rubidium: yes. That approach requires opengfx to have only DOS-paletted sprites, though. It doesn't have that atm 18:07:06 <Alberth> planetmaker: better extend grfcodec then 18:07:08 <planetmaker> nmlc on the other hand detects the palette and auto-converts to DOS 18:08:50 <Hirundo> I'm still working on adding caching to nml 18:08:54 <Alberth> theoretically, nml could build an AST like what grfcodec uses, and then call grfcodec as a library to do its processing 18:09:45 <Alberth> Hirundo: does that work on compile farms? 18:10:03 <Alberth> which build everything one time from scratch, every day 18:10:11 <Hirundo> Alberth: I don't know 18:10:26 <Hirundo> If it creates a completely clean environment, probably not 18:10:57 <Alberth> for newgrf developers it would help a lot, I think 18:11:45 <Hirundo> I hope so, I can't test until I have the bugs ironed out 18:12:03 <Alberth> Hirundo: where do you store the cache? 18:12:24 <Hirundo> Currently next to the grf 18:12:39 <Hirundo> as foo.grf.cache and foo.grf.cacheindex 18:12:55 <Hirundo> .cacheindex contains the meta-data as JSON, .cache the raw sprite data 18:13:55 <Alberth> sounds good 18:14:05 <planetmaker> Alberth: such thing would work on our CF. And the caching would work, too. But there it's not that important 18:14:39 <planetmaker> thus starting with clean would give no bonus. But... really it matters for us at home when dev'ing 18:15:39 <Alberth> sure, and it is an order of magnitude simpler to cache results than to speed up these calculations 18:15:59 <Alberth> especially if you don't want to lose cross-platform operation 18:16:18 <Hirundo> the only way to achieve a real speedup is to use C/C++, either as some module or via grfcodec 18:17:41 <Alberth> eventually, you could merge nml and grfcodec so you don't need to generate text that grfcodec parses again 18:17:51 <Alberth> but that's even more complicated 18:19:49 <Rubidium> doesn't sound like a sane solution 18:20:20 <Rubidium> because that requires massive grfcodec changes, and it's not a codebase I'd like to add another input format to 18:22:02 <Alberth> grfcodec would become somewhat of a backend library 18:22:32 <Alberth> I don't think you'd keep much of the current grfcodec structure 18:22:32 <Rubidium> at that moment it doesn't resemble grfcodec anymore 18:22:57 <Alberth> indeed, it get split in many pieces 18:23:21 <Alberth> it's more more likely in such a case that you add nfo as input format to nml 18:23:27 <Hirundo> You might as well rip out the image loading / sprite writing code (it's GPL, right?) and let that write the 'sprite section' of the grf, while NML writes the 'data section' 18:24:14 <Rubidium> image loading is very nasty code 18:24:51 <Hirundo> nasty in what way? 18:24:53 <Alberth> another option is to make a somewhat higher level format. Basically, nml should tell what to generate, not actually do the generation 18:25:44 <Rubidium> 1) DaleStan code 18:25:49 <Hirundo> that format exists already as nfo 18:26:22 <Alberth> Rubidium: it may be easier to rewrite the current nml code to C 18:26:28 <Rubidium> 2) massive sharing with sprite writing code 18:26:54 <Alberth> Hirundo: partial compilation? 18:27:15 <Rubidium> 3) lots of similarly named/functioning functions, but slightly different. The only way to know which one gets actually ran is by running it in a debugger 18:27:43 <Rubidium> 4) spent weeks trying to get the sprite reading/writing code to actually function when adding 32bpp support 18:28:00 <Rubidium> 5) still don't understand the code or what I did to that code 18:28:10 <Hirundo> :o that's baad 18:29:00 <Hirundo> Alberth: Could you explain? partially compiling what? 18:29:13 <Rubidium> the sprite writing code is slightly better are it was mostly rewritten, but heavily intertwined with writing the actual data 18:29:21 <Alberth> Hirundo: compile each .pnml file separately 18:29:36 <Alberth> then 'link' 18:30:45 <Hirundo> Alberth: That's really tricky, NML was not designed with that in mind 18:31:54 <Hirundo> It may be possible, but with restrictions (e.g. no cross-referencing action2s) 18:32:00 <Alberth> currently you don't even have a format to express the information you need during linking. In fact, I wouldn't know what you need to know at that stage 18:32:42 <Alberth> but most of the action/sprite/xyz number assignments would move out of nml 18:33:19 <Alberth> unfortunately, it is probably tmwftlb 18:34:00 <Hirundo> Alberth: How long does building zbasebuild take for you? 18:34:17 <Alberth> which revision? 18:34:26 <Rubidium> I think that such a pnml should work together with the cached compiled real sprites. Then you store the nml AST that you optimised as much as possible (replacing static stuff), and build the sprites. When linking you load the ASTs, link them together, run another optimisation run and emit everything with the cached real sprites 18:34:53 <Brot6> FISH - subtypes_5.png XandythenorthX @ http://dev.openttdcoop.org/attachments/download/3136/subtypes_5.png 18:34:58 <Rubidium> Hirundo: few revisions ago it was 10 minutes for me (or 4 with -u and without -c) 18:35:14 <Alberth> for a baseset it should be really simple 18:35:42 <planetmaker> for the 5 base grfs yes. The extra is just a normal newgrf 18:35:44 <Hirundo> Indeed (ignoring the extra grf) 18:35:49 <planetmaker> though simple mostly, too 18:36:12 <Alberth> Hirundo: I can measure it if you want, I have seen 13 minutes execution time, but I did not time it 18:36:35 <Hirundo> It's done with the first two now, so I expect it to finish soon 18:36:45 <Hirundo> (ish) 18:39:31 <Rubidium> Hirundo: did you do -jN ? 18:40:14 <Rubidium> if so, then everything seems to be done except the base one, and it still takes probably more time than it took to build the others 18:40:21 <Alberth> or in general, expect several nml's running concurrently :) 18:42:18 <Hirundo> I did not do -jN, but I don't know if it helps inside a VM 18:42:51 <planetmaker> depends on the config, whether it can use severa cores 18:43:01 <Hirundo> CPU usage is a little above 50% (dual core machine) 18:46:24 <Rubidium> how much time is spent in Windows -> DOS palette conversion? 18:47:12 <Rubidium> i.e. might it be feasible to convert the palette and use grfcodec for creating the actual GRFs? 18:47:49 <Rubidium> although... you might just try it with grfcodec right now and ignore the wrong colours for the non 32bpp sprites 18:48:04 <Rubidium> for development that might help 18:48:24 <Rubidium> (don't know how long building such a grf with grfcodec would take though) 18:55:27 <Hirundo> Currently I'm doing 'time make' with caching enabled and cache files present, so we'll see... 18:55:59 <planetmaker> o_O. Still building 18:57:48 <Hirundo> No, rebuilding 18:57:57 <Hirundo> caching only works the second time :-) 18:58:47 <Alberth> it works the first time too, but you get 100% cache misses :p 18:58:50 <planetmaker> I'm talking of my 'time make' :-P 18:59:10 <Alberth> although, if you use the same sprite more than once? 19:00:16 <Brot6> FISH - Revision 782:dee171bda336: Change: cargo subtypes work across more cases of 'class is present... XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/dee171bda336 19:04:04 <Brot6> FISH - subtypes_6.png XandythenorthX @ http://dev.openttdcoop.org/attachments/download/3137/subtypes_6.png 19:05:15 <Brot6> FISH - subtypes_7.png XandythenorthX @ http://dev.openttdcoop.org/attachments/download/3138/subtypes_7.png 19:05:19 <Hirundo> Using the same sprite more than once will make use of the cache 19:22:55 <Alberth> Hirundo: make 1697.61s user 12.85s system 99% cpu 28:32.28 total <-- 'time make' after 'make clean' 19:23:39 <Alberth> ie full rebuild 19:25:25 <Rubidium> Hirundo: w.r.t. reuse, what if you use -c and one has nocrop and the other (same image) doesn't have nocrop? 19:27:28 <Alberth> good night 19:28:01 *** Alberth has left #openttdcoop.devzone 19:36:37 <Brot6> FISH - Revision 783:7ba80670d9d5: Change: make subtype strings light blue XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/7ba80670d9d5 19:56:15 <Brot6> FISH - Revision 784:1db266c09212: Change: make subtypes simpler, don't bother with special cases XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/1db266c09212 20:01:56 <Brot6> FISH - Revision 785:e327988cbd4e: Change: set subtype strings according to graphics template used XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/e327988cbd4e 20:17:53 <Brot6> FISH - Revision 786:afca17115676: Codechange: unify some autorefit stuff XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/afca17115676 20:27:46 <Brot6> FISH - Revision 787:642b2209c01a: Change: partial completion of autorefit; also remove some incorrec... XandythenorthX @ http://dev.openttdcoop.org/projects/fish/repository/revisions/642b2209c01a 20:52:54 *** LordAro has quit IRC 20:57:17 *** frosch123 has quit IRC 21:16:37 *** LordAro has joined #openttdcoop.devzone 21:38:05 *** ODM has quit IRC 22:53:05 <Hirundo> Rubidium: Cropping yes/no is part of the 'key' used for the cache, so a cropped sprite won't be reused for a non-cropped one 23:07:00 <Brot6> zBase - Revision 24:a760531c8c8b: Add: Paper mill. XzephyrisX @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/a760531c8c8b 23:20:57 <Brot6> NewGRF Meta Language - Revision 1932:8e4ef7518f2b: Add: Constant CB_RESULT_REFIT_COST_MASK XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8e4ef7518f2b 23:26:04 <Brot6> zBase - Revision 25:fb26e835fa47: Add: Updated power station working files (unfinished). XzephyrisX @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/fb26e835fa47