Log for #openttdcoop.devzone on 16th July 2012:
Times are UTC Toggle Colours
08:22:09  *** Nat_aS has quit IRC
08:22:24  *** Nat_aS has joined #openttdcoop.devzone
09:17:53  <Brot6> Java OpenTTD Admin Library - Revision 98:fabcbd9e4a60: Add: Methods to get a readable string from th... (dih) @
09:18:50  <planetmaker> hm, I like seeing commits on these projects, dihedral :-)
09:19:05  <dihedral> :-)
09:19:11  <dihedral> thank you :-)
09:21:18  <planetmaker> obviously there *do* exist implementations for the admin ports. But all those people keep it as closed source. To keep their servers and "advantage".
09:21:29  <planetmaker> Stupid frigging egoists :S
09:21:51  <dihedral> :-P
09:21:54  <dihedral> yep
09:21:58  <planetmaker> it really saddens me
09:22:12  <dihedral> i do not see the benifit in that to be honest, appart from the fact that i'll have the only open project :-D
09:22:19  <planetmaker> everything is provided for free to them. And they give nothing back
09:22:55  <dihedral> some do - with feature requests or bug reports
09:22:59  <dihedral> that already is good
09:23:28  <dihedral> and also, i guess some people to not feel very secure showing their code :-P
09:23:38  <dihedral> they probably would feel... exposed :-D
09:25:46  <planetmaker> well, I talked to xOR some time ago. And he said just that "I keep it closed as my 'clients' want to keep an edge". (clients = selected server owners). Oh well
09:28:02  <dihedral> the general code should always be public
09:28:19  *** Alberth has joined #openttdcoop.devzone
09:28:24  <planetmaker> o/ Alberth
09:28:24  <Alberth> moin
09:28:25  <dihedral> the plugins, etc. - i do not care about them, but the basic code should always be public
09:28:27  <dihedral> hello Alberth
09:37:04  <dihedral> planetmaker, perhaps he gets paid for it?
09:37:05  <dihedral> :-P
10:44:41  <Ammler> xOR sounds like .NET crap, that is even worse as java
10:54:27  <Alberth> so much hate against Java :(
10:56:22  * Alberth only finds ^ operator references :(
11:14:25  <planetmaker> Alberth, some not very active guy. And I might slightly mis-spell the name. I think he's behind n-ice servers or so
11:15:44  <planetmaker>
11:15:45  <Webster> Title: Transport Tycoon Forums View topic - Dedicated server control - xShunter (at
11:21:39  <Alberth> right, not very useful thus :)
11:24:41  <planetmaker> he told me that he and some other servers use it. But that rather want him not release it to keep their edge. Oh well... makes him feel special and fanned, I guess
11:25:57  <Ammler> would you use it, if you could?
11:26:08  <Ammler> there is no lost imo
11:26:19  <Alberth> looking never hurst
11:26:22  <Alberth> *hurts
11:26:55  <Ammler> well, in this case, it wastes time
11:26:57  <Alberth> the whole idea of open source is many eyes, many improvements -> good quality
11:26:57  <planetmaker> Ammler, maybe? Hard to tell, if one can't have a look
11:27:29  <Ammler> best .NET software is still worse as worst other software :-)
11:27:37  <planetmaker> ah, yes. It was also like "I first want to change x, y and z before I release it"
11:27:44  <Alberth> even if you decide it is crap, he has figured out stuff which you can copy in concept
11:28:00  <planetmaker> exactly, alberth ^
11:28:24  <planetmaker> I don't think it's crap. Even when I don't like the framework
11:28:35  <Ammler> well, as said, you still would need time to view it
11:28:38  <planetmaker> might even be very suitable for people who run windows servers
11:28:50  <planetmaker> Ammler, so? Does that hurt?
11:28:58  <Ammler> yes, you waste time
11:29:01  <planetmaker> IMHO _any_ OSS solution is better than none
11:29:14  <Alberth> Ammler: there are very few sane alternatives to C# from a windows perspective
11:29:38  <planetmaker> and it's imho quite bad to cry around like "bad, bad" just because the language and maybe the style another person uses on his own projects doesn't match your preferences.
11:29:45  <Ammler> [13:27] <Ammler> best .NET software is still worse as worst other software
11:29:56  <planetmaker> quite wrong imho
11:30:17  <planetmaker> badly portable maybe. But... that doesn't make it bad.
11:30:40  <planetmaker> One may say time is spent better on the same in another language or so. But... that's personal choice
11:30:46  <planetmaker> Doesn't make the result bad
11:30:52  <Alberth> c# as a language is actually quite good
11:30:55  <planetmaker> just not as useful (to you and me) as we might wish
11:31:40  <Alberth> at least it's moving forward, unlike Java
11:31:54  <planetmaker> Ammler, and... why is it bad if someone works with .NET or C#?
11:32:06  <planetmaker> any reason other than that it comes from MS?
11:32:08  <Ammler> did I say that?
11:32:17  <Alberth> planetmaker: ok, I am starting to undestand what needs to be done :)
11:32:35  <planetmaker> hu?
11:32:39  <planetmaker> oh. :-)
11:32:48  <Alberth> ie I just got what you meant with "per sprite template" :)
11:32:58  <planetmaker> yeah :-)
11:33:21  <planetmaker> it might be good to have one template for the plain, flat sprite. One for the SE half-slope, etc. For each of the 19 ground tile types
11:33:58  <planetmaker> and possibly one which combines them in one template with 19 filenames as parameter. But maybe it can just be one filename stem or so
11:34:07  <Alberth> wooow  :)    I just arrived at the realization of what to do for one sprite :D
11:34:15  <planetmaker> :-)
11:35:28  <planetmaker> Alberth, what I might like maybe more (and we should ask that possibly Zephyris) to provide the same thing as 8bpp sprite (1x) too
11:35:44  <planetmaker> Might simplify coding a bit. And even increase the uniformity of the looks
11:36:09  <planetmaker> and not like providing the 8bpp somewhen. But run the conversion right then when he also adds the 32bpp
11:36:31  <planetmaker> But... maybe it#s also easier to just keep or use the existing 8bpp opengfx
11:36:37  <planetmaker> I'm unsure
11:36:39  <Alberth> it makes sense to also generate the other sprites from the same source indeed
11:37:02  <Alberth> I'll do the latter first anyway
11:37:23  <planetmaker> did you merge already? ;-)
11:42:13  <planetmaker> Alberth, I made you manager of the (pseudo-)project OpenTTD. That allows you to create new projects on your own. In case you have a repo and want to share it :-)
11:43:13  <Alberth> no, I was thinking among the lines of  #define OPENGFX /home/.../opengfx   first until I understand what I am doing :)
11:43:14  <planetmaker> e.g. to present some ideas or so
11:43:39  <planetmaker> well. repos come for free. You can create projects. And we can delete them again, if they're not needed anymore
11:43:53  <planetmaker> just saying. Not implying that you need to use it :-)
11:44:23  <planetmaker> For my part I would first want to show to Zephyris what my idea looks like. Which is best done in a new repo imho
11:44:32  <planetmaker> which then can be deleted when he likes it
11:44:48  <planetmaker> (or also when he doesn't :-P )
11:45:08  <planetmaker> just wanted to give you this toy at hand. Nothing more really
11:46:00  <Alberth> thanks, but I need some time to understand this stuff first, I just downloaded a 22000 files or so, it takes some time to see structure :)
11:46:43  <planetmaker> of course. I understand
12:09:00  <dihedral> java may not be moving forward at the moment
12:09:18  <dihedral> yet it still is widely spread and has a wide range of supported operating systems
12:09:30  * Alberth nods
12:09:43  <dihedral> i really enjoy coding in java
12:10:02  <dihedral> and by the way: i have some concepts too - it's still open source
12:10:31  <dihedral> i've built an entire yet simple plugin system based on spi
12:10:34  <Alberth> but not against Eclipse APIs, I hope; they are a nightmare :)
12:11:09  <dihedral> Alberth, i did not see the worth of using osgi (over 1MB in size) for an app which can work with less than 200KB
12:11:44  <Alberth> at work we hook into the text editor stuff
12:12:01  <Alberth> with error markers, etc etc
12:12:49  <Alberth> we also have a lot of plugins for various parts of the languages that we make or transform
12:13:16  <Alberth> but that's a different scale than 200KB :)
12:13:54  <dihedral> ok, grapes itself is 69KB
12:14:00  <dihedral> the bundle is 783K
12:16:59  <dihedral> bundled IRC plugin is 169K, and bundled (beginning of the) rhino plugin is 1.1M
12:20:51  <dihedral> \o/ joan has 33.7% comment ratio of a pure 2188 lines of code
12:22:14  * Terkhen likes coding in java too
12:22:22  <dihedral> \o/
12:29:02  * Alberth likes C++ more, but it's my age, probably
12:37:35  <dihedral> the only contact i have with c++ is openttd :-P
12:45:25  <Brot6> NewGRF Meta Language - Bug #4063 (New): NML crash "AttributeError: 'unicode' object has no attribute... (Alberth) @
12:46:10  <Alberth> Java feels so bulky when you know Python :p
13:14:28  <Brot6> NewGRF Meta Language - Bug #4063: NML crash "AttributeError: 'unicode' object has no attribute 'incl... (Alberth) @
13:26:34  <dihedral> I do not feel like writing joan and grapes in a language i am unfamiliar with, or while i am learning the language :-P
13:32:00  <Alberth> did someone ask you that ?
13:33:51  <planetmaker> I might have once said that I'd like a python implementation better :-P
13:41:55  <Alberth> Just copied sprites/terrain/base-3924-terrain.pnml to zbase (and the templates pnml), and trying to build that, but get
13:41:55  <Alberth> nmlc: Sprite number 3924 given in base_graphics-block, but it doesn't match output sprite number 3
13:42:20  <Alberth> does this mean I have to add 3921 other sprites first ?
13:43:24  <planetmaker> yes and no :-)
13:43:35  <planetmaker> do you have all 8bpp sprites coded?
13:43:45  <planetmaker> i.e. take opengfx? Or started completely anew?
13:43:55  <planetmaker> In the latter case: you have to have 3921 sprites first
13:43:58  <Alberth>
13:44:04  <planetmaker> or make a newgrf
13:44:22  <planetmaker> ah, so you DO make a newgrf
13:44:34  <planetmaker> newgrf != base grf
13:44:42  <Alberth> right :)
13:44:44  <planetmaker> you can't use base_sprite in a newgrf
13:44:48  <planetmaker> iirc
13:44:56  <Alberth> makes sense :)
13:45:10  <planetmaker> there you need to use like replace(id, ...)
13:45:40  <planetmaker> instead of base_sprite(id,...)
13:46:19  <planetmaker> but... for replace(id,...) and also base_sprite(id,...) you *need* to supply the 8bpp. The 32bpp MUST be supplied always in the alternative_sprites(id, ...) block
13:46:25  <planetmaker> which matches the 8bpp block by id
13:46:42  <planetmaker> irrespective of newgrf or base grf
13:46:57  <Alberth> replace works
13:47:15  <Alberth> I linked to the 8bpp gfx from the opengfx project, so it can find those
13:47:24  <planetmaker> aye
13:48:25  <Alberth> next step,  the alternative sprites
13:48:31  <planetmaker> :-)
13:55:21  <dihedral> <planetmaker> I might have once said that I'd like a python implementation better :-P <- thankfully it does not matter where you run grapes from :-P
13:55:37  <dihedral> so you could run your bots from a windows computer somewhere at home :-P
13:56:11  <dihedral> i should however once start checking what the bandwidth use is of the bot for that case :-P
13:56:32  <planetmaker> Alberth, as zephyris so far mostly provides landscape sprites: May I suggest you canibalize opengfx+landscape?
13:56:47  <planetmaker> it has basically everything to implement most of the zbase sprites as newgrf
13:57:43  <planetmaker> or at least parts of its code (for the single climates, without the specials like company land and wind turbine) will come in very handy
13:58:23  <planetmaker> and you have already also a climate parameter - which you'll need either as internal or external parameter when working as NewGRF on the climate replacement
13:58:45  <planetmaker> dihedral, indeed it doesn't matter. And that's nice :-)
13:59:08  <planetmaker> but... I'd not be worried about bandwidth. The 'heavy' stuff would run locally anyway. At least in the coop use cases
14:06:15  <dihedral> i'd love to know though what the traffic stats would be :-P
14:08:37  <planetmaker> dihedral, do you want a test server? Please feel free to use our stable server for that
14:08:57  <dihedral> well, right now i just use a local server
14:09:08  <planetmaker> that's not a 'real' game :-)
14:09:24  <planetmaker> I give you full ssh... no problem
14:09:46  <planetmaker> the 'stable' server is anyway just an OpenTTD debug server :-P
14:09:55  <dihedral> :-D
14:09:56  <dihedral> lol
14:10:06  <planetmaker> that's what I created it for... :-)
14:10:33  <planetmaker> it became just much more popular than I ever thought it would get
14:10:38  <dihedral> all i need is the port for the admin port and the admin port password
14:11:35  <Alberth>  how to refer to a sprite in the alternative sprite block?
14:12:16  <planetmaker> Alberth, it needs a name (not just the sprite number)... let me look how it must look like :-)
14:13:00  *** Xotic750 has joined #openttdcoop.devzone
14:13:23  <Alberth>    defines the name instead of the number, which is useless to me
14:13:28  <planetmaker> Alberth, replace(name, sprite#, imagefile) { ... }
14:13:39  <planetmaker> and use that name :-)
14:13:48  * Alberth guessed as much :)
14:13:51  <planetmaker> the name is an optional first parameter
14:14:13  <planetmaker> hm, no
14:14:20  <Xotic750> hi all
14:14:24  <planetmaker> replace blockname(id, filename) {...}
14:14:29  <planetmaker> ^^  that's the syntax
14:14:39  <dihedral> planetmaker, i guess the server is not listening on port 3977 or the firewall is not allowing access :-P
14:14:48  <Alberth> yeah it bounces on 3 parameters
14:14:59  <Alberth> so where to leave the sprite number then?
14:15:08  <planetmaker>
14:15:12  <planetmaker> ups. wrong link
14:15:17  <planetmaker>
14:15:29  <planetmaker> replace name(spritenumber, filename) { ... }
14:16:00  <planetmaker> alternative_sprites (blockname, zoom_level, type, filename, mask_filename) { ... }
14:16:13  <planetmaker> name=blockname :-P
14:16:25  <Alberth> I see :)
14:17:32  <Alberth> that works, now my parameters are wrong :)  nmlc: "terrain/base-3924-terrain.pnml", line 36: Read beyond bounds of image file 'terrain/terrain_temperate/64_0001.png'
14:17:46  <planetmaker> he
14:18:26  <planetmaker> but that's "just" a wrong filename reference or even "only" wrong width, height or positioning of real sprite
14:20:10  <Alberth> [0, 0] works, but that may be a grossly wrong offset :p
14:20:22  <planetmaker> can you quote the line?
14:20:27  <planetmaker> or block?
14:20:51  <Alberth> [1, 1, 64, 31, -31, 0]
14:21:08  <planetmaker> Alberth, [0, 0, 64, 31, -31, 0]
14:21:19  <planetmaker> it's 0-based
14:21:37  <planetmaker> thus you obviously read beyond the EOF
14:21:57  <Alberth> that works too
14:22:31  <planetmaker> :-)
14:23:07  <planetmaker> dihedral, I'll have to investigate that in more detail. Hopefully later today. But not from work ;-)
14:23:26  <dihedral> don't worry
14:23:32  <dihedral> no rush at all ;-)
14:23:56  <Terkhen> hi Xotic750
14:24:04  <Xotic750> hi :)
14:26:50  <Xotic750> planetmaker, I created a branch but before committing the code to it I wanted to make sure that I did it correctly?
14:29:39  <planetmaker> <-- that looks like all the commits are in the proper branch. So I think, yes
14:30:39  <Xotic750> great, I'm going to commit my initial code then :)
14:31:26  <planetmaker> :-) fantastic
14:32:14  <Xotic750> I hope that I created the grf.spec file correctly, would be good to check when you have time
14:33:23  <planetmaker> Looks ok to me
14:34:00  <planetmaker> after all, the only real change wrt opengfx should be the requirement to add m4, thus line 20 only needs a change. afaik :-)
14:35:20  <Xotic750> I guess we will see once automated nightlies begin again :)
14:36:02  <planetmaker> :-) yeah
14:36:19  <planetmaker> though I wonder whether the CF automatically works on branches...
14:36:30  <planetmaker> that'll need finding out or maybe bugging Ammler, if not :-P
14:39:51  <Brot6> OpenGFX+ Trains - Revision 709:f55b6604292a: Codechange: Initial commit of m4 preprocessed experimen... (Xotic750) @
14:40:46  <Xotic750> Well, there you have it :)
14:43:09  <Xotic750> Hopefully will be able to do some more modeling again soon
14:45:46  <planetmaker> :-)
15:10:27  *** LordAro has joined #openttdcoop.devzone
15:41:02  <Alberth> well, I do have a newgrf, it's just not working :)
15:43:10  <planetmaker> hey, nice :-)
15:47:01  <Alberth>    as long as you don't have sprites that I replaced, it works :)
15:47:35  <Alberth> nothing seems to be drawn at those spaces
15:50:37  *** frosch123 has joined #openttdcoop.devzone
15:53:10  <Rubidium> Alberth: looks arti, though maybe use 8bpp-debug ;)
15:54:38  <Alberth> ?
15:55:06  <Alberth> oh some -d flag probably :p
15:55:59  <Rubidium> no, a blitter
15:56:12  <Rubidium> but it seems to have met the AXE effect
16:02:01  <Alberth> right, it just seems to skip all sprites
16:03:25  <Rubidium> where's the code?
16:19:25  *** ODM has joined #openttdcoop.devzone
16:44:10  <Alberth>  here
17:04:03  <Rubidium> that doesn't look that difficult that it'd do something odd
17:04:58  <Alberth> can the offsets be wildly wrong?
17:05:02  <Rubidium> I reckon just checking out the zbase repository gives me the right pngs
17:05:35  <Alberth> about 21000 of them :)
17:05:41  <Rubidium> Alberth: compile it with one sprite that's not used that often, but a reasonable amount of times
17:05:47  <Rubidium> then load the grf
17:06:06  <Rubidium> with the sprite aligner you can check whether the offsets are wrong (or fix the offsts)
17:06:32  <Alberth> good idea
17:06:47  <Rubidium> it's taking quite a while ;)
17:07:29  <Alberth> It's 180MB, I could not pull it with http
17:07:43  <Rubidium> got it
17:07:48  <Rubidium> missing the lang file
17:08:12  <Alberth>
17:08:29  <Alberth> and I use the opengfx sprites too
17:09:12  <Rubidium> guess I need a newer nml
17:09:32  <Alberth> cd zbase;  ln -s sprites/../opengfx/sprites
17:09:47  <Alberth> r1912, newer is broken on errors
17:11:06  <Alberth> hmm, my 'ln' command is not good, it's   ln -s ../opengfx/sprites  .
17:12:39  <Rubidium> the sprites seem completely chopped
17:14:37  <Alberth> yeah :(
17:15:38  <Alberth> perhaps nml does not understand the alpha channel
17:17:43  <Alberth> let's see what Xotic does here
17:18:12  <Rubidium> one sprite works fine without the 32bpp sprites
17:18:19  <Rubidium> when I add one 32bpp sprite it goes wrong
17:18:56  <Rubidium> ah...
17:21:22  <Rubidium> the 32bpp sprites are square
17:21:28  <Rubidium> so 64x64 (in the png)
17:21:37  <Rubidium> but you only get roughly 64x32
17:21:55  *** LordAro has quit IRC
17:21:55  <Rubidium> only problem is that the bottom 32 pixels and not the top 32 pixels are used
17:22:09  <Rubidium> so you're effectively cutting out the transparent top half instead of the bottom half with the actual sprite
17:22:14  <Brot6> Unable to connect to execution expired
17:22:17  <Alberth> :o   that explains a lot!
17:22:47  <Alberth> so offsets are wrong but not in openttd :D
17:29:38  <Brot6> dutchtrains: update from r626 to r629 done -
17:30:49  <Brot6> metrotrackset: update from r92 to r94 done -
17:32:12  <Brot6> fish: update from r750 to r780 done -
17:33:17  <Brot6> debugveh: update from r6 to r10 done -
17:35:28  <Alberth> Rubidium: that works, it still needs some better tuning, but at least it is working enough to see what you are doing.
17:45:20  <Brot6> Metro Track Set - Revision 95:43fe962b9b75: Fix: improve signal alignment (foobar) @
17:47:56  *** LordAro has joined #openttdcoop.devzone
18:29:33  <Brot6> make-nml: compile of r14 still failed (#4048) -
18:38:32  <Brot6> frenchtowns: compile of r6 still failed (#4058) -
18:48:35  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 129404), firs (2 warnings) (Diffsize: 43339), opengfx (Diffsize: 26), foobarstramtracks (Diffsize: 28769), bandit (1 warnings) (Diffsize: 7930), cets (195 warnings) (Diffsize: 27765), friss (Diffsize: 1332), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), rust (15 warnings) (Diffsize: 7633), dutchtramset (21 warnings)
18:48:35  <Brot6> (Diffsize: 24503), swisstowns (Diffsize: 51), britrains (10 warnings) (Diffsize: 62948), dutchroadfurniture (Diffsize: 203668), spanishtowns (Diffsize: 8), ogfx-rv (Diffsize: 8301), dutchtracks, ogfx-landscape (2 warnings) (Diffsize: 1314), swedishrails (Diffsize: 1836), german-townnames (Diffsize: 5042), dach (104 warnings) (Diffsize: 30898), belarusiantowns (Diffsize: 72), indonesiantowns (1 warnings) (Diffsize: 350), airportsplus
18:48:38  <Brot6> (Diffsize: 6970)
20:37:41  *** ODM has quit IRC
21:04:05  *** Xotic750 has quit IRC
21:09:19  *** Alberth has left #openttdcoop.devzone
21:41:22  *** frosch123 has quit IRC
22:51:47  <Brot6> zBase - Revision 10:0cabf5a6146b: Add: Improved monorail sprites, with more depth. (zephyris) @
23:03:32  *** LordAro has quit IRC

Powered by YARRSTE version: svn-trunk