Log for #openttdcoop.devzone on 22nd July 2012:
Times are UTC Toggle Colours
00:18:24  *** LordAro has quit IRC
02:26:39  *** Dr_Tan has quit IRC
02:26:47  *** Dr_Tan has joined #openttdcoop.devzone
02:43:57  *** Dr_Tan has quit IRC
02:58:06  *** Nat_aS has joined #openttdcoop.devzone
06:06:36  <Brot6> FISH - Revision 788:ddb7ba65bf0c: Change: work in progress on auto-refit support XandythenorthX @
06:46:10  <Brot6> FISH - Revision 789:b206996e7792: Change: use cargo_classes instead of cargo_classes_in_consist XandythenorthX @
06:46:10  <Brot6> FISH - Revision 790:da1106bcaa94: Change: autorefit more or less works now XandythenorthX @
07:55:18  *** LordAro has joined #openttdcoop.devzone
08:22:29  *** Alberth has joined #openttdcoop.devzone
08:22:42  <Alberth> wiep
08:23:53  <planetmaker> wop
08:31:24  <dihedral> blupp
08:31:54  <Rubidium> those must be bits of K3 songs
08:32:13  <dihedral> Question for you guys ;-)
08:32:25  <dihedral> regarding lines on the console starting with #
08:32:30  <dihedral> they are treated as comments
08:32:52  <dihedral> would the idea of passing comments to connected bots be feasable?
08:33:32  <Alberth> comments with semantics defeat the concept 'comment' imho
08:34:05  <dihedral> they do not cause any interaction in the game, and would be an ideal option to be handled by bots without the report from openttd 'command not found' :-P
08:35:15  <dihedral> was just a thought i had, to which i wanted feedback - feedback i have got now :-) thank you Alberth - and i do agree with you
08:35:32  <Alberth> :)
08:39:26  <dihedral> then it would probably be better to have bots register a prefix character which then gets treated by openttd specially and only sent to the bots that registered the char in question
08:39:34  <dihedral> in order to keep it correct
08:39:44  <dihedral> which is not something i shall to for now :-P
08:39:54  <Alberth> yeah or some prefix command or so
08:40:49  <Alberth> but it's a dangerous area; two programs getting the same input, and then react differently
08:41:07  <Alberth> it makes life very complicated
08:41:27  <Alberth> in particular as the 'ignored' commands say something about the commands to come
08:41:35  <Alberth> s/as/if/
08:41:35  <Brot6> Alberth meant: "in particular if the 'ignored' commands say something about the commands to come"
08:42:19  <dihedral> no need to make stuff more complicated :-P
08:42:24  * planetmaker thinks that it's common case that two programmes react differently to the same input. I react with "yummi" to Mousse au chocolat while a friend of mine curiously with "meeh"
08:43:56  <Alberth> which explains why debugging real world problems is so complicated :p
08:49:01  <dihedral> however, i do not feed your friend with mousse au chocolat when trying to get it into your mouth :-P
08:49:05  <Rubidium> planetmaker: but it's not the same input. It's like me telling you not to say something and you then telling it to someone else regardless
08:49:52  <planetmaker> is it? It was the same bowl of mousse last time ;-)
08:50:07  <dihedral> you eat out of your friends mouth...
08:50:10  <dihedral> ?
08:50:11  <Rubidium> planetmaker: it'd be like me complaining that NML does not output the comments I make in the NML into the NFO ;)
08:50:52  <planetmaker> dihedral: you got a wiered phantasy :-P
08:51:07  <dihedral> but that is what i was thinking of doing
08:51:55  <dihedral> putting something on openttd console which openttd does not ... digest and after finding that out passes the same info on to the bot, and the bot happily eats whatever it gets
08:55:07  *** Lord_Aro has joined #openttdcoop.devzone
08:55:37  *** LordAro is now known as Guest276
08:55:38  *** Lord_Aro is now known as LordAro
08:57:24  <Alberth> perhaps you really want a separate channel for the bot
08:58:18  <Alberth> instead of piggy-backing it onto something that happens to exist already
09:01:12  *** Guest276 has quit IRC
09:03:28  *** frosch123 has joined #openttdcoop.devzone
09:06:45  <planetmaker> Hirundo: <-- do you think the wiki would profit to use definition lists like I added there for the train's misc_flags property?
09:09:04  <Brot6> NewGRF Meta Language - Revision 1933:a275dd203ab9: Fix: refit_cost callback may also be called from ... XHirundoX @
09:11:15  <Hirundo> planetmaker: I think it certainly does for cases like misc_flags, where each flag has a different meaning that requires explanation
09:12:22  <planetmaker> of course not for every single one (RUNNING_COST_XXX would not warrant it really). Though also in that case it would be a nicer list, I think.
09:12:27  <planetmaker> I'll give it a shot on that page
09:14:08  <Hirundo> FYI, first indication is that caching gives roughly a 6-7x speedup for zBase
09:14:54  <planetmaker> wow.That's considerable
09:14:56  <Hirundo> But there are still some diffs in the output that I need to fix, so I can't commit yet
09:20:19  *** Lord_Aro has joined #openttdcoop.devzone
09:20:27  *** LordAro is now known as Guest278
09:20:27  *** Lord_Aro is now known as LordAro
09:25:14  *** Guest278 has quit IRC
09:36:44  <Brot6> zBase - Bug #4085: 'jitter' in the bricks of the copper ore mine animation XzephyrisX @
09:40:12  <dihedral> <Alberth> instead of piggy-backing it onto something that happens to exist already <- are you referring to this irc channel?
09:41:09  <frosch123> Hirundo: <- in case you didn't notice
09:41:12  <Alberth> no, to your wish to add extra commands to  a channel with a bot which are not interpreted by the console
09:42:02  <Rubidium> just talk to the server; it will not handle anything of it ;)
09:42:07  <Hirundo> frosch123: does 1.2.2 exist yet?
09:42:15  <frosch123> no, but it was backported yesterday
09:42:21  <frosch123> so, it's in 1.2 branch
09:43:22  <dihedral> It was just a wild idea when i saw that comments existed on the console
09:43:44  <dihedral> my bot has its own console (which is currently unhandled)
09:43:56  <dihedral> at least the input is unhandled :-P
10:06:30  <Hirundo> whoa! Another 3-fold decrease in zbase build time, down to 1m11 (it was roughly 4 minutes with caching and 28 without)
10:07:02  <planetmaker> :-O
10:08:00  <Hirundo> It turns out (not really surprising) that splitting a data stream (=string) into a list of characters and then recombining is quite a major timesink
10:08:56  <Brot6> FISH - Lindton Transport, 15-06-2012.sav XandythenorthX @,%2015-06-2012.sav
10:10:55  <Brot6> FISH - fish.grf XandythenorthX @
10:16:21  <planetmaker> he, indeed a bit unsurprising :-)
10:18:45  <Hirundo> Such things only pop up, though, after other time-sinks (in this case, compiling image data into real sprites) have been eliminated
10:19:15  <Alberth> yeah, one bottleneck at a time :)
10:19:39  <Brot6> FISH - XandythenorthX @
10:20:33  <planetmaker> so overall you sped up nmlc by a factor of 30. Quite considerable :-)
10:20:39  <planetmaker> kudos
10:20:55  <Alberth> that's worthwhile to spend time on :)
10:21:10  <dihedral> X<user>X is somewhat confusing :-P
10:23:02  <Alberth> haven't you met my double X twin ?   he is doing all the work, very nice chap :)
10:34:07  <Brot6> NewGRF Meta Language - Bug #4086 (New): Use variable 7B for passing constants > 255 to 60+x variable... XHirundoX @
10:34:35  <planetmaker> oh, that's the function call?
11:07:02  <Hirundo> hmmm... building ogfx_toyland takes 6 minutes first time, 5 seconds second time
11:07:35  <planetmaker> :-D
11:07:47  <Hirundo> though that's with profiler enabled, which skews results
11:09:37  <Hirundo> when encoding sprites some built-in functions/operations are called millions of times, each time incurring profiler overhead
11:25:52  <LordAro> can i upload to directly?
11:26:06  <LordAro> e.g. svn diff >
11:26:10  <LordAro> or something similar
11:26:17  <LordAro> it'd make things a lot easier :L
11:26:24  <planetmaker> :-)
11:26:33  <Alberth> I know there exist applications for that
11:26:48  <planetmaker> I fear not feasible as I don't know an app for that. But in principle...
11:27:00  <Alberth> doesn't your package manager list a few?
11:27:50  <Alberth> whether they work with is another matter though, perhaps they use some API that's not implemented everywhere
11:28:15  <planetmaker> it needs a app dedicated to that particular paste bin software, I'd recon.
11:30:15  <planetmaker> LordAro:
11:30:16  <Webster> Title: lodgeit lodgeitlib v0.6 documentation (at
11:31:30  <Ammler>
11:32:21  <Ammler> planetmaker: you don't know that script?
11:32:35  <planetmaker> Ammler: no, I didn't
11:33:10  <Ammler> ok, just around the tenth time I mention it :-P
11:33:32  <Alberth> I think it needs another 10 times :p
11:33:46  <planetmaker> I remember 0 times. And Alberth certainly is right :-D
11:34:27  <planetmaker> but my memory is bad. And my pain to use without that script wasn't really high either :-)
11:34:47  <planetmaker> as in case I just have cpottd script which puts the file there :-P
11:35:02  <Ammler> it is quite nice, either FILE or echo "hello" | lodgeit
11:35:17  <Ammler> also multiple files is possible
11:35:18  <planetmaker> well. Now I downloaded it :-)
11:43:54  *** LordAro has quit IRC
12:55:21  <Brot6> FISH - Revision 791:8472b1c46658: Change: set all ships to use 'refit any' autorefitting XandythenorthX @
13:19:47  <planetmaker> Hirundo: where actually is the sprite cache of nml?
13:34:46  <Brot6> FISH - fish_buy_menu_2.png XandythenorthX @
13:38:35  <Brot6> FISH - freighter.png XandythenorthX @
13:43:14  *** Brot6 has quit IRC
13:43:54  *** Brot6 has joined #openttdcoop.devzone
13:48:10  <Alberth> planetmaker:
13:48:10  <Alberth> (20:20:27) Alberth: Hirundo: where do you store the cache?
13:48:10  <Alberth> (20:20:48) Hirundo: Currently next to the grf
13:48:10  <Alberth> (20:21:02) Hirundo: as foo.grf.cache and foo.grf.cacheindex
13:48:10  <Alberth> (20:21:19) Hirundo: .cacheindex contains the meta-data as JSON, .cache the raw sprite data
13:48:12  <Alberth> (20:22:18) Alberth: sounds good
13:49:22  <planetmaker> oh, thx :-)
14:15:16  <Brot6> zBaseBuild - Revision 18:b938f6242cba: Add: arctic papermill, animated goldmine shaft wheel XAlberthX @
14:18:38  <Hirundo> <noob mode>I have downloaded the latest grfcodec version from the ottd website, what is the right place (tm) to put it in linux?</noob mode>
14:21:42  <frosch123> in case you ask seriously: make a hg checkout in your favorite folder in your home directory
14:21:56  <frosch123> and make a symbolic link from /usr/local/bin to the compiled binary in your home directory
14:23:20  <planetmaker> :-)
14:23:36  <planetmaker> that's the dev approach, I guess, frosch123
14:23:39  <frosch123> anyway, /usr/local is the place for stuff installed not using a package manager
14:24:01  <Alberth> or in $HOME/bin
14:24:19  <frosch123> planetmaker: i don't know whether Hirundo was quoting from the forums (considering the topic in #openttd) or whether he was asking for himself
14:24:35  <frosch123> considering "himself" i gave him the dev answer ofc :)
14:24:41  <planetmaker> :-)
14:40:05  *** ODM has joined #openttdcoop.devzone
14:40:11  <planetmaker> this is for dihedral:
14:40:14  <Webster> Title: open-the-jar.jpg -" target="_blank"> 0.06 - Wir bohren einfach weiter (at" target="_blank">
15:02:57  *** LordAro has joined #openttdcoop.devzone
15:08:43  <Hirundo> I was not quoting the forums/#openttd, I myself encountered the problem as grfcodec 1.0.0 doesn't work with grfv2
15:09:08  <Hirundo> And debian's software center offered nothing newer
15:16:26  <planetmaker> yeah. Then best way is to not install (or de-install) with package manager. And symlink the binary in your repos to /usr/local/bin
15:16:53  <planetmaker> works for me with nml, grfcodec, nforenum, osie
15:17:43  <planetmaker> at least that's what I found least hassle for me. Just hg pull -u && make
15:17:52  <planetmaker> and then I've got the latest tip binary in my path
15:18:57  <planetmaker> ^ Hirundo
15:19:52  <planetmaker> might even write a script like "update_all" ;-)
15:20:39  <Alberth> the only conceptual problem is that /usr/local is for system-wide installs, and not everybody can read your $HOME
15:21:10  <planetmaker> yes. It's not a good idea for multi-user systems
15:21:54  <planetmaker> But then... who of us has other people use that machine regularily? I don't
15:22:08  <planetmaker> (and you could set the read permissions such that reading is allowed)
15:23:09  <Alberth> I have the user bin  $HOME/bin in my PATH (many linuces have that), and add symlinks there
15:23:33  <planetmaker> yes, of course also feasible
15:24:24  <planetmaker> OSX does not. Though I could have added that, sure enough
15:25:21  <Alberth> Apple is always strange
15:25:32  <planetmaker> :D yeah
15:25:41  <planetmaker> local bin path is cleaner
15:25:47  <planetmaker> (your solution)
15:26:08  <Alberth> I work too long with unix systems to even consider other solutions :)
15:32:44  <Hirundo> Alberth: Does zbasebuild crop sprites?
15:35:09  <planetmaker> Hirundo: it should by default do that. As the makefile has -c as default parameter to nmlc
15:35:28  <planetmaker> (it uses opengfx' one there)
15:38:30  <Brot6> FISH - Feature #4087 (New): Provide a depot view sprite for each vehicle XandythenorthX @
16:00:07  *** LordAro has quit IRC
16:02:01  *** LordAro has joined #openttdcoop.devzone
16:06:50  <Hirundo> planetmaker: You removed all house variables from the documentation, that's probably not intended ?
16:37:28  <Alberth> I copied build files from opengfx, almost without modifications
16:38:30  <Alberth> the only bigger changes are adding of 'make score' and template expansion with a python script, which still needs to be replaced with a nml template
17:07:37  <Alberth> what's the purpose of NOCROP in the foundations file?  sprites/toyland/toyland-0543-foundations.pnml
17:08:41  <frosch123> the terrain is drawn as child sprite of the foundation
17:08:57  <frosch123> that is: at a fixed position relative to the topleft of the foundation graphic
17:09:10  <frosch123> thus cropping misaligns the terrain
17:10:59  <frosch123> in general, this is the reason NOCROP exists at all :)
17:18:16  <Alberth> makes sense to draw foundations first :)
17:19:21  <frosch123> it would be easier if cs had just decided to draw childsprites relative to the same reference spot as the parent sprite, instead of picking the topleft corner :)
17:31:20  <Brot6> NewGRF Meta Language - Revision 1934:ff7e81e58e72: Codechange: Prepare the grf output for working wi... XHirundoX @
17:31:21  <Brot6> NewGRF Meta Language - Revision 1935:f8e7fef96637: Codechange: Create a new function for recomputing... XHirundoX @
17:32:31  <Brot6> NewGRF Meta Language - Revision 1936:df92630b38b6: Feature: Cache real sprites when building a GRF, ... XHirundoX @
17:32:31  <Brot6> NewGRF Meta Language - Revision 1937:b55283b7e613: Add: Command-line parameter '--no-cache' (-n) to ... XHirundoX @
17:32:31  <Brot6> NewGRF Meta Language - Revision 1938:82e836e877c3: Codechange: Speedup sprite writing by outputting ... XHirundoX @
17:32:33  <Brot6> NewGRF Meta Language - Revision 1939:5e02f29e9ce3: Codechange: Use map() instead of a generator expr... XHirundoX @
17:32:56  <Hirundo> Alberth: Here you go ^^
17:33:15  <Alberth> \o/
17:33:58  <Alberth> so now it's ready before I type nmlc ?  :)
17:34:32  <Hirundo> If you use my VM system clock, then yes ;-) (it has slipped into the future again)
17:35:52  <Hirundo> Actually I have one more possible speedup, which is to cache open image files instead of reloading them each time
17:36:26  <Hirundo> But that requires some more thought to avoid using lots of memory
17:36:27  <Alberth> probably not worth the trouble
17:36:48  <Alberth> disk cache is quite quick :)
17:37:02  <Hirundo> Disk cache might be, but I'm not too sure about PIL
17:39:25  <frosch123> Alberth: considering grfcodecs behaviour, caching the decompressed png can speed up a lot in certani cases
17:39:40  <frosch123> if you use grfcodec to decode and reencode a 32bpp grf it takes an hour
17:40:05  <Hirundo> Hmmm now I remember, I should have looked at the -u flag before committing
17:40:06  <Alberth> I use NML
17:40:44  <Hirundo> Currently NML ignores the -u (uncompressed, ie no LZ77) flag when looking at the cache
17:41:05  <Hirundo> That's probably bad.... not sure though
17:41:11  <frosch123> decoding a 32bpp grf with grfcodec results in a huge 8bpp and a huge 32bpp png. when reencoding from that it reopens both files altenating for every single sprite
17:42:01  <Alberth> joy :)
17:42:21  <Alberth> first run; filling the cache :p
17:43:06  <Hirundo> What I want NML to do is first count how often each image file is used (something similiar is done already)
17:43:25  <Hirundo> Then open an image file on first use, and close after it has been used N times
17:43:57  <Alberth> with max X images open, perhaps
17:44:16  <frosch123> maybe an easier medium way would be keeping the last 10 files open
17:45:04  <Alberth> don't you know the coordinates of the sprites? then you can do all sprites for each file
17:45:05  <frosch123> not sure whether first considering all files is worth the effort
17:45:25  <Hirundo> frosch123: That is being done already, so adding that is not really difficult
17:45:58  <Hirundo> s/that/this feature
17:46:00  <Alberth> file IO is very fast compared to pixel and compression, probably
17:46:24  <frosch123> Hirundo: so you already cache files?
17:46:33  <Hirundo> No
17:46:50  <Hirundo> currently it first compiles a list (a set, actually) of used image files
17:46:59  <Hirundo> then it checks the existence of all those files
17:47:17  <frosch123> ah, that is the part that is already done
17:47:29  <Hirundo> then it discards all that information and encodes the sprites one-by-one
17:49:16  <Hirundo> Keeping a list of e.g. 10 open would give better worst-case, but slightly worse common-case behaviour, methinks
17:50:36  <Alberth> does the cache survive several nmlc programs running in the same directory at the same time?
17:51:33  <Hirundo> As long as they don't try to build the same .grf file, yes
17:52:11  <Alberth> that'd be interesting :)
17:53:18  <Hirundo> Even then you should be fine as long as file reads/writes can be considered atomic
18:01:14  <Hirundo> With both caching and LZ77 disabled, caching image files (for ogfxc_arctic.nml) cuts compilation time from 59 to 30 seconds
18:04:18  <Hirundo> (with caching, it's 3 seconds)
18:08:20  <Alberth> so it is really image processing that kills the performance
18:08:39  <Hirundo> After you ignore LZ77, yes
18:11:42  <Alberth> hmm, there are no standard compression programs that you can use as a child program to do the compression for you?
18:12:21  <Hirundo> And then, there's tile compression and sprite_compress (which converts a list of numbers into a fake-compressed string) which both take around 11 seconds
18:13:10  <Rubidium> I'm not sure how many operating systems like 40k spawned processes for ogfx1_base (3 32bpp, 1 8bpp sprite * 5000 sprites * 2 (to try both compressions)
18:14:04  <Hirundo> AFAIK python can work reasonably well with modules written in C
18:14:12  <Alberth> good point
18:15:34  <Alberth> Hirundo: it can indeed. The biggest trouble is that you need the same C compiler as what Python was built with (afaik),  at the target platform to compile the module
18:16:19  <Hirundo> hmmm *senses trouble*
18:17:03  <Alberth> well, computer systems without a compiler as part of the standard install are not worth considering anyway :D
18:17:49  <Alberth> alternatively, use Jython, and write a java module :)
18:18:06  <Hirundo> write once, debug everywhere ?
18:18:38  <Alberth> another alternative could be cython, A hybrid python/C language. Never played with it though
18:19:31  <Hirundo> Just stay away from LZ77 until you're going to upload to bananas :-)
18:19:34  <Alberth> the advantage of compression and pixels is that you have very little IO, except perhaps files, which work quite well everywhere :)
18:31:55  <Brot6> FISH - Revision 792:e8ee0d769ed3: Change: add various extra ships to nml conversion XandythenorthX @
18:31:55  <Brot6> FISH - Revision 793:b5c3c73be8c8: Cleanup: remove some redundant files XandythenorthX @
18:34:37  <Brot6> FISH - fish_buy_menu_7.png XandythenorthX @
18:41:20  <Brot6> FISH - Revision 794:a9464c82b755: Fix: convert some palettes to DOS XandythenorthX @
19:00:01  <Brot6> FISH - Revision 795:c34d41f3d8ba: Change: add Island Trader to nml conversion XandythenorthX @
19:28:18  <Brot6> zBaseBuild - Revision 19:15f99d34ed06: Add: toyland terrain/foundations XAlberthX @
19:37:08  <Rubidium> Alberth: what do you think of ?
19:38:39  * Alberth wonders why you ask me that :)
19:39:16  <Alberth> I may be coding 32bpp, but that's more out of frustration of nobody else doing anything than it is for the love of 32bpp
19:39:18  <Rubidium> I don't like committing something in someone else's repository without them seeing it ;)
19:39:52  <Rubidium> what the diff does is make the obg say: I'd like the 32bpp blitter, so I don't have to change my config file for testing this ;)
19:39:58  <Alberth> oh, not openttd repo :)
19:40:10  <Alberth> in that case, +1  :)
19:41:02  <Alberth> it would be a bit useless to make nice 32bpp graphics and have a default of not using it :)
19:42:03  <Rubidium> the sea looks very white-ish though
19:42:20  <Alberth> the sae is not yet done is it?
19:42:38  <Alberth> oh, perhaps I just did that too while doing toyland stuff
19:42:48  <Brot6> zBaseBuild - Revision 20:b35eceba2cf9: Change: let this base set request the 32bpp blitter XRubidiumX @
19:43:34  <Rubidium> guess you committed that by accident
19:44:32  <Alberth> I don't really pay much attention to it, I am the only committer, and they are all 'add's
19:50:16  <Alberth> good night
19:50:19  *** Alberth has left #openttdcoop.devzone
20:23:51  *** frosch123 has quit IRC
20:24:39  *** LordAro has quit IRC
20:26:21  <Brot6> zBase - Bug #4088 (New): wrongly sloped rail and tunnel entrance XRubidiumX @
20:28:05  <Brot6> zBaseBuild - Patch #4089 (New): temperate rail XRubidiumX @
20:41:51  *** LordAro has joined #openttdcoop.devzone
21:03:37  <Brot6> NewGRF Meta Language - Revision 1940:0c8772654682: Codechange: Cache open image files when writing a... XHirundoX @
21:11:44  *** ODM has quit IRC
23:15:52  *** LordAro has quit IRC

Powered by YARRSTE version: svn-trunk