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) @ http://dev.openttdcoop.org/projects/joan/repository/revisions/fabcbd9e4a60 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> http://www.tt-forums.net/viewtopic.php?f=29&t=48544 11:15:45 <Webster> Title: Transport Tycoon Forums View topic - Dedicated server control - xShunter (at www.tt-forums.net) 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) @ http://dev.openttdcoop.org/issues/4063 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) @ http://dev.openttdcoop.org/issues/4063#change-11123 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> http://paste.openttdcoop.org/show/1549/ 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> http://paste.openttdcoop.org/show/1550/ 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> http://newgrf-specs.tt-wiki.net/wiki/NML:Alternative_sprites 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> http://paste.openttdcoop.org/show/1550/ 14:15:12 <planetmaker> ups. wrong link 14:15:17 <planetmaker> http://newgrf-specs.tt-wiki.net/wiki/NML:Replace_TTD_sprites 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> http://hg.openttdcoop.org/ogfx-trains/graph <-- 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/f55b6604292a 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> http://devs.openttd.org/~alberth/Unnamed-1945-01-01.png 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> http://devs.openttd.org/~alberth/zbase.nml 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> http://devs.openttd.org/~alberth/english.lng 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 http://dev.openttdcoop.org/sys/: 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 - http://bundles.openttdcoop.org/dutchtrains/nightlies/r629 17:30:49 <Brot6> metrotrackset: update from r92 to r94 done - http://bundles.openttdcoop.org/metrotrackset/nightlies/r94 17:32:12 <Brot6> fish: update from r750 to r780 done - http://bundles.openttdcoop.org/fish/nightlies/r780 17:33:17 <Brot6> debugveh: update from r6 to r10 done - http://bundles.openttdcoop.org/debugveh/nightlies/r10 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) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/43fe962b9b75 17:47:56 *** LordAro has joined #openttdcoop.devzone 18:29:33 <Brot6> make-nml: compile of r14 still failed (#4048) - http://bundles.openttdcoop.org/make-nml/nightlies/ERROR/r14 18:38:32 <Brot6> frenchtowns: compile of r6 still failed (#4058) - http://bundles.openttdcoop.org/frenchtowns/nightlies/ERROR/r6 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) @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/0cabf5a6146b 23:03:32 *** LordAro has quit IRC