Times are UTC Toggle Colours
00:00:14 <Brot6> OpenGFX+ Trains - Revision 534:4c4aa8ed5a22: Fix: Spelling mistake on vehicles (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/4c4aa8ed5a22 06:12:38 *** Zuu has joined #openttdcoop.devzone 06:57:01 <Brot6> Dutch Trains 2 - Feature Request #3990 (New): Extended cargo definitions for wagons (foobar) @ http://dev.openttdcoop.org/issues/3990 07:18:19 *** Zuu has quit IRC 07:21:48 *** Nat_AFK is now known as NataS 09:04:31 *** NataS is now known as Nat_AFK 10:47:08 <Brot6> OpenGFX+ Trains - Revision 535:d9d718b459ee: Add: Model, Render and Post-process run of bulk sugar b... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/d9d718b459ee 11:06:50 <Brot6> Makefile for NewGRFs: Common part - Revision 11:de22bd16f573: Change: Rename all Makefile parts so t... (planetmaker) @ http://dev.openttdcoop.org/projects/make-nml-common/repository/revisions/de22bd16f573 11:06:50 <Brot6> Makefile for NewGRFs - Revision 12:eb7638080710: Change: Rename all Makefile parts so that they don'... (planetmaker) @ http://dev.openttdcoop.org/projects/make-nml/repository/revisions/eb7638080710 11:14:33 *** frosch123 has joined #openttdcoop.devzone 11:15:49 <Brot6> Makefile for NewGRFs: Common part - Revision 12:58f48fd0f45a: Fix: Reference the correct graphics de... (planetmaker) @ http://dev.openttdcoop.org/projects/make-nml-common/repository/revisions/58f48fd0f45a 11:15:49 <Brot6> Makefile for NewGRFs - Revision 13:3acbfa6ba3dc: Fix: Reference the correct graphics dependency file... (planetmaker) @ http://dev.openttdcoop.org/projects/make-nml/repository/revisions/3acbfa6ba3dc 11:16:42 <Ammler> Xotic750: so it looks like the render server works? 11:17:09 <Ammler> then we just have to monitor, how it influences the rest of our system 11:17:14 <Xotic750> yep, I tested just a single render and post-processing and everything seems fine 11:17:35 <Xotic750> I will do a full run on it sometime so that it can be monitored 11:17:36 <Ammler> ah ok, when you plan to render a "big" amount? 11:17:50 <Xotic750> I can run it any time as a test 11:18:00 <Xotic750> but I just finished a full run on my machines 11:18:29 <Xotic750> I can do a render now if you want to watch 11:18:48 <Ammler> ^Spike^: are there munin-node packages for centos? 11:19:40 <Ammler> Xotic750: how long do you expect the render will take? 11:20:04 <Xotic750> no idea on the vm 11:20:23 <Xotic750> oh btw I have munin available now, I added an extra repo to centos 11:20:34 <Ammler> oh ok, you already installed? 11:20:38 <Xotic750> not yet 11:20:53 <Ammler> ping me so I can add it to our munin server 11:21:03 <Xotic750> Available Packages 11:21:03 <Xotic750> munin.noarch 1.4.7-3.el6 epel 11:21:03 <Xotic750> munin-common.noarch 1.4.7-3.el6 epel 11:21:03 <Xotic750> munin-java-plugins.noarch 1.4.7-3.el6 epel 11:21:05 <Xotic750> munin-node.noarch 1.4.7-3.el6 epel 11:21:10 <Xotic750> these are what are available 11:21:37 <Xotic750> do I need all of them? 11:22:07 <Ammler> just munin-node 11:22:13 <Xotic750> ok, will add now 11:22:37 <Ammler> long ago we setup munin, I need to check myself ;-) 11:23:20 <Xotic750> I had to do a kernel update for blender but haven't rebooted yet, I guess it is ok to reboot? 11:23:42 <Xotic750> actually it was a dependancy 11:23:43 <planetmaker> Xotic750: it might be an idea to nice the process sufficiently 11:23:56 <planetmaker> (the render process) 11:24:16 <Xotic750> what nice level do you want? 11:24:48 <planetmaker> dunno :-) I'd probably nice it all the way. And it'll still grab all it can while giving other server stuff priority 11:25:22 <Xotic750> normally blender uses a max of around 80% of my cycles when rendering 11:25:51 <planetmaker> well. Nice doesn't limit the % usage. But it only changes priority if there's other demand for cpu 11:26:04 <Xotic750> yep 11:26:21 <Xotic750> Ammler: munin-node is installed 11:26:30 <planetmaker> but I guess we shall try without first. And see its effect on the system 11:26:36 <Xotic750> so, what about the reboot for the kernel? 11:26:48 <planetmaker> no problem to reboot your VM 11:26:57 <Xotic750> ok, will do it now 11:27:59 <Xotic750> ok, reboot went fine 11:28:19 <Xotic750> so, I'm ready to do a render run once you are set Ammler 11:28:32 <Ammler> [13:28] <planetmaker> [13:23:43] Xotic750: it might be an idea to nice the process sufficiently <-- I wouldn't do such thing beforehand 11:28:44 <planetmaker> yeah, let's first see the impact 11:28:45 <Ammler> let us first check, how it works out 11:29:05 <Xotic750> do you need to do the munin stuff first or shall I begin? 11:29:14 <Ammler> i would rahter like to limit it on container level if needed 11:29:19 <planetmaker> would be nicer to setup munin first 11:29:27 <planetmaker> it's the direct monitor after all 11:29:34 <planetmaker> Ammler: yes, that's better 11:30:20 <Xotic750> do I need to do anything on the vm for munin other than install it? 11:31:34 <Ammler> I guess not by default 11:31:44 <Ammler> spike will tell, if needed 11:32:14 <Xotic750> ok, just say when to start the render 11:33:30 <Ammler> well, check if service munin-node is running 11:33:58 <Ammler> we will see it working, if in around 5 mins, render is listed on munin.openttdcoop.org 11:35:01 <Xotic750> munin-node is stopped 11:35:14 <Ammler> then of course, you can enable/install plugins for what you like to monitor 11:35:22 <Ammler> please add it as service 11:35:41 <Ammler> (autostart on boot) 11:37:30 <Xotic750> munin-node 0:off 1:off 2:on 3:on 4:on 5:on 6:off 11:37:49 <Ammler> fine 11:37:58 <Xotic750> munin-node (pid 678) is running... 11:38:24 <planetmaker> but... it needs adding to http://munin.openttdcoop.org/ Ammler? 11:38:31 <Ammler> yes, done 11:38:48 <Xotic750> anything else or start render? 11:39:26 <planetmaker> I still don't see it, Ammler 11:42:44 <Ammler> pm, I have no clue how to run those things manually 11:42:49 <planetmaker> hm... making the grf via nml -> nfo -> grf results in a much smaller file... 11:42:59 <Ammler> so I would just wait the 5 mins from the time he enabled munin 11:43:08 <planetmaker> ah, ok, that's the update freq 11:43:20 <Ammler> but also if munin doesn't work, you can watch most things via openvz monitor 11:43:33 <planetmaker> what's the node's name? 11:43:39 <Ammler> render 11:43:52 <Ammler> 2012/05/23 11:40:21 [INFO] No old data available for failed worker openttdcoop.org;render.openttdcoop.org. This node will disappear from the html web page hierarchy 11:43:52 <planetmaker> not there as of :41h 11:44:13 <planetmaker> hu? 11:45:00 <Ammler> http://munin.openttdcoop.org/openttdcoop.org/haydn.openttdcoop.org/index.html#openvz 11:47:03 <Ammler> Xotic750: the vm does not have any silly fw running or so? 11:47:19 <Ammler> ah well, never mind, we just wait 11:47:34 <Ammler> we have a munin/centos pro, no need to guess around 11:48:48 <Xotic750> Table: mangle 11:48:48 <Xotic750> Chain PREROUTING (policy ACCEPT) 11:48:48 <Xotic750> num target prot opt source destination 11:48:48 <Xotic750> Chain INPUT (policy ACCEPT) 11:48:48 <Xotic750> num target prot opt source destination 11:48:50 <Xotic750> Chain FORWARD (policy ACCEPT) 11:48:51 <Xotic750> num target prot opt source destination 11:48:55 <Xotic750> Chain OUTPUT (policy ACCEPT) 11:48:57 <Xotic750> num target prot opt source destination 11:48:59 <Xotic750> Chain POSTROUTING (policy ACCEPT) 11:49:01 <Xotic750> num target prot opt source destination 11:49:03 <Xotic750> Table: filter 11:49:05 <Xotic750> Chain INPUT (policy ACCEPT) 11:49:07 <Xotic750> num target prot opt source destination 11:49:11 <Xotic750> Chain FORWARD (policy ACCEPT) 11:49:13 <Xotic750> num target prot opt source destination 11:49:17 <Xotic750> Chain OUTPUT (policy ACCEPT) 11:49:19 <Xotic750> num target prot opt source destination 11:49:29 <Ammler> as said, I hope it is _not_ running 11:49:44 <Ammler> fw just sucks 99% of the time ;-) 11:51:09 <Xotic750> [root@render ogfx-trains]# chkconfig iptables off 11:51:09 <Xotic750> [root@render ogfx-trains]# chkconfig --list iptables 11:51:09 <Xotic750> iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off 11:51:09 <Xotic750> [root@render ogfx-trains]# service iptables stop 11:51:09 <Xotic750> iptables: Flushing firewall rules: [ OK ] 11:51:10 <Xotic750> iptables: Setting chains to policy ACCEPT: mangle filter [ OK ] 11:51:12 <Xotic750> iptables: Unloading modules: 11:51:28 <planetmaker> paste services for the win ;-) 11:51:49 <planetmaker> http://paste.openttdcoop.org 11:52:00 <Ammler> ok, next date 13:55 11:52:14 <planetmaker> for munin update 11:52:16 <planetmaker> ? 11:52:20 <Ammler> yes :-) 11:52:34 <Ammler> 2012/05/23 11:50:05 [INFO] Reaping Munin::Master::UpdateWorker<openttdcoop.org;render.openttdcoop.org>. Exit value/signal: 18/0 11:53:28 <Ammler> if that fails, still, we wait for ^Spike^ :-P 11:53:32 <Xotic750> back soon, need coffee :) 11:54:42 <planetmaker> *slurp* 11:55:17 <Ammler> 2012/05/23 11:55:06 [INFO] Reaping Munin::Master::UpdateWorker<openttdcoop.org;render.openttdcoop.org>. Exit value/signal: 18/0 11:55:21 <Ammler> so it was not fw 11:56:38 <Ammler> munin:/etc/munin # ping render.openttdcoop.org 11:56:40 <Ammler> PING render.openttdcoop.org (10.10.101.113) 56(84) bytes of data. 11:56:41 <Ammler> 64 bytes from render.openttdcoop.org (10.10.101.113): icmp_req=1 ttl=64 time=0.035 ms 11:56:46 <Ammler> host is reachable 11:57:10 <Ammler> as said, no clue anymore 11:57:24 <Ammler> but if you want, feel free to run the test 11:57:33 <Ammler> or just wait, if it doesn't matter 11:57:45 * Ammler is afk 11:58:55 <Xotic750> does centos use selinux? 11:59:02 <Xotic750> maybe a cause 12:00:16 <planetmaker> not afaik... 12:00:51 <planetmaker> Xotic750: Just FYI, I'm about to commit Makefile change. (Thus don't commit now, if you don't want to merge ;-) ) 12:01:44 <Xotic750> I have only 1 commit pending, the addition of bulk sugar beet to the pnml, should be fine 12:01:55 <planetmaker> well... push it now then 12:01:59 <Xotic750> it was only the moving of the directory that affected me 12:02:02 <planetmaker> if it's committed already 12:02:06 <planetmaker> if not, then it's no issue 12:02:43 <planetmaker> well, I guess this pull will take another few minutes... to update my repo anyway 12:02:51 <Xotic750> :) 12:03:17 <Brot6> OpenGFX+ Trains - Revision 536:809844f35ca9: Feature: Make use of 32bpp sprites for bulk sugar beet (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/809844f35ca9 12:03:20 <planetmaker> We seriously need the largefile extension ;-) 12:03:35 <planetmaker> I guess that's my next project. And re-create the whole repo, using that extension 12:03:49 <Xotic750> I've disbaled selinux now too 12:04:00 <planetmaker> oh 12:06:20 <Xotic750> I don't know what I am looking for to see if there is any change with munin though 12:07:28 <Xotic750> btw, I started a game running with firs and it seems that scrap metal is using bulk coal sprites for some reason 12:09:13 <planetmaker> yes. Coal is the fallback sprite, if no dedicated graphics are used 12:09:24 <Xotic750> I'm guessing it may be to do with not picking the cargo type in the switch and defaulting through to coal 12:09:31 <planetmaker> There's two different scrap metal labels meanwhile, maybe the new one is not yet in the code 12:09:50 <planetmaker> *in the code of the bulk wagon for sprite display at least 12:10:29 <Xotic750> the one in the switch is SCRP 12:10:47 <planetmaker> indeed. I'll add it along with my next push 12:10:58 <planetmaker> it's a trivial addition really 12:11:44 <Xotic750> has there been any change with the munin monitor? 12:12:39 <planetmaker> there's not been, last update 1 minute ago 12:12:56 <Xotic750> ok, so I huess not fw and not selinux then :) 12:13:02 <Xotic750> *guess 12:13:04 <planetmaker> don't worry now. Just start rendering... We'll see via the hypervisor anyway ;-) 12:13:13 <Xotic750> ok, will start it now 12:14:21 <Xotic750> damn, forgot to run screen and time 12:14:33 <Xotic750> maybe I'll start it again 12:15:20 <Xotic750> ok, it's off 12:15:46 <planetmaker> testing the render time? :-) 12:15:55 <planetmaker> I shall be interested in the result, too 12:16:25 <Brot6> OpenGFX+ Trains - Revision 537:fc1fa1d4bd65: Change: Support also FIRS' new scrap metal label with t... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/fc1fa1d4bd65 12:16:25 <Brot6> OpenGFX+ Trains - Revision 538:d47771564d5f: Change: [Makefile] Rewrite with removal of code depende... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/d47771564d5f 12:18:46 <Xotic750> I'm guessing around 12 hours for the render :) 12:19:02 <Xotic750> any other bets :P 12:21:16 <planetmaker> dunno, what is your laptop's cpu and time? 12:21:59 <Xotic750> I was using 3 laptops in a farm :) 12:22:29 <Xotic750> but about 2 days for the rendering only 12:23:01 <Xotic750> and about 2 days more for post-processing 12:23:22 <Xotic750> then about 30 mins compile 12:24:09 <Xotic750> and during that time I was unable to do any modeling 12:24:13 <planetmaker> hm, then I bet ... 8 hours :-) 12:24:19 <Xotic750> so this is going to be a huge benefit 12:24:46 <Xotic750> well ... for me that is :) 12:25:04 <planetmaker> for everyone playing OpenTTD :-) 12:25:43 <Xotic750> I saw you put some placeholder code in for the tender 12:26:09 <planetmaker> We specifically decided to setup this server to run the DevZone with the intention to make it an offer for OpenTTD add-on development. If its CPU can be used this way, it's a very good use 12:26:11 <Xotic750> I need to get a short vehicle into the game so we can have some offsets 12:26:52 <planetmaker> yes, I didn't yet add sprites... got distracted and didn't immediately find the 8bpp sprites which I needed for testing 12:27:28 <Xotic750> I'm working on an old bulk wagon just now 12:27:41 <Xotic750> once done I will have a fast run of load types for it 12:28:05 <Xotic750> basing it on this 12:28:06 <Xotic750> http://www.flickr.com/photos/graemecurran/4772061406/ 12:28:07 <Webster> Title: Old Coal Wagon | Flickr - Photo Sharing! (at www.flickr.com) 12:28:32 <Xotic750> very losley of course :) 12:29:09 <planetmaker> may I suggest some 8bpp sprites (6/8 length, though)? http://dev.openttdcoop.org/issues/3590 12:29:17 <planetmaker> it would be politically nice to use them :-) 12:30:13 <planetmaker> hm, that wagon you link *really* looks ancient :-) 12:31:06 <Xotic750> yep, that's the kind of look that I want to achieve for the short, old bulk 12:31:20 <planetmaker> hm, I just see... those are not full sprite sets in that issue I linked... 12:31:35 <Xotic750> then I can do the 3/4 (6/8) length bulk 12:31:38 <planetmaker> so not that relevant... let's see the tt-forums topic though 12:33:29 <planetmaker> added link to his tt-forums posting in the issue 12:33:40 <Brot6> OpenGFX+ Trains - Feature Request #3590: earlier waggons (planetmaker) @ http://dev.openttdcoop.org/issues/3590#change-10881 12:33:48 <planetmaker> but tbh, I'd not mind an appropriate old-style look re-draw in 8bpp, either 12:35:43 <planetmaker> Xotic750: it's right that all blender files and blender output is in ./sprite-source right? 12:35:51 <planetmaker> http://paste.openttdcoop.org/show/1419/ 12:35:57 <Xotic750> I'm not much of a pixel art man, is there someone that can fill in the required 8bpp stuff? 12:36:09 <Xotic750> yep 12:36:13 <planetmaker> Thus it would work to declare that dir as "largefiles" only? 12:36:20 <planetmaker> great 12:36:25 <Xotic750> they are large for sure :) 12:36:35 <planetmaker> Xotic750: yes... I'm hoping to convince this Yoshi to do the 8bpp work 12:37:01 <planetmaker> I'm not asking you to do that :-) 12:37:21 <Xotic750> phew! :P 12:37:28 <planetmaker> if we don't get any hand-crafted sprites, I understand that there's always the 8bpp output of the render scripts 12:37:45 <Xotic750> of course I can convert my models to 8bpp but they are not the same as the pixel art 12:37:53 <Xotic750> yep 12:37:54 <planetmaker> of course not. 12:38:11 <Xotic750> that still needs some work, as I have been worrying about the 32bpp stuff 12:38:29 <planetmaker> we shall see 12:39:00 <planetmaker> Xotic750: tbh, I'd put thus priority on sprites for all existing trains and wagons which we have, though. Instead of now starting with completely new, early vehicles 12:39:11 <planetmaker> e.g. also doing the monorail and maglev engines 12:39:15 <planetmaker> and wagons 12:39:46 <planetmaker> it would leave less loose ends in this newgrf and would make a "more round" release 12:39:53 <Xotic750> I can concentrate on those 12:40:05 <planetmaker> and leave us a great feature for the 2nd next major release 12:40:18 <frosch123> man, grfcodec sucks so much 12:40:33 <planetmaker> frosch123: yes. It doesn't build this grf from the nfo :-( 12:40:36 <frosch123> but due to nml there is no real reason to improve it 12:40:57 <frosch123> anyway, i now succeeded somewhat in decoding ogfx+trains 12:41:16 <frosch123> i disabled a sanity check in grfcodec, and decoding finishes 12:41:23 <Xotic750> temperate is getting close to completed 12:41:26 <frosch123> several sprites are considered corrupt, but the rest looks fine 12:41:31 <Xotic750> just need the steamers really 12:41:36 <frosch123> so, currently it looks like a nml bug 12:42:08 <Ammler> Xotic750: forget about kernel on the container, you don't have one :-) 12:42:10 <planetmaker> frosch123: checkout Makefile:60 in ogfx-trains (tip) 12:42:28 <frosch123> i was no reencoding the decoding grf, but it reloads the complete 32bpp and 8bpp pngs for every sprite, i.e. it takes ages :p 12:42:31 <planetmaker> uncommenting that line and commenting out Makefile:59 results in a grf w/o the 32bpp... but I don't exactly see why 12:43:01 <planetmaker> but I'm not even 100% sure it's not also (at least partially) the nfo output of nmlc 12:43:14 <planetmaker> and I have other things to worry about now... like largefiles ;-) 12:44:07 <frosch123> planetmaker: add the -g 2 option to grfcodec 12:44:22 <frosch123> by default it encodes in container format 1, i.e. without 32bpp 12:44:29 <frosch123> though i wonder whether that is intentional :p 12:44:43 <frosch123> i would have expected that it uses container 2 if it encounters nfo 32 12:45:06 <planetmaker> hm, I'll try that, thx 12:48:06 <planetmaker> he... src/gfx/engines/passenger/gui/blank32.png: Cannot read 32bpp PNG files without alpha layer! 12:48:30 <frosch123> haha, grfcodec is still encoding ... so nml is infact faster :p 12:48:44 <planetmaker> nice :-) 12:49:48 <frosch123> somewhen i had the intention to completely trash grfcodec and rewrite it... but since nml it feels even more like a waste of time :p 12:51:19 <planetmaker> :-) yeah... I agree 12:51:35 <Brot6> Makefile for NewGRFs: Common part - Revision 13:72b256075211: Change: Use container format 2 when us... (planetmaker) @ http://dev.openttdcoop.org/projects/make-nml-common/repository/revisions/72b256075211 12:51:42 <planetmaker> that time probably is better invested in NML improvement / completion 12:52:00 <frosch123> hmm, though argueably, if the nml->nfo->grfcodec way becomes the standard way, it would make sense again 12:52:09 <planetmaker> iff 12:52:15 <planetmaker> it won't, if it is not faster 12:52:32 <planetmaker> and as I just pasted above... it does not work for this newgrf due to missing alpha layer 12:52:40 <frosch123> planetmaker: you can make grfcodec so fast that nml won't stand a chance 12:52:46 <planetmaker> (something which iirc is not required) 12:52:48 <frosch123> there is no limit on parallelizing encoding 12:52:53 <frosch123> well, disk speed 12:52:59 <planetmaker> can't that be done in NML, too? 12:53:26 <frosch123> it was said that python effectively cannot multithread anything important 12:53:38 <planetmaker> hm, right. I heart that, too 12:53:50 <planetmaker> In that case, it will make sense to keep grfcodec for that purpose 12:53:56 <frosch123> ah, finished ... 15 minutes 12:54:06 <planetmaker> 12 minutes build time surely are something I'd like to see cut down ;-) 12:54:52 <frosch123> planetmaker: this is the buildtime for encoding the grfcodec-decoded grf 12:55:05 <frosch123> i.e. encoding from two huge pngs containing all the sprites 12:55:06 <planetmaker> in any case, should you feel like needing a test case, ogfx-trains has all it needs to directly compare. Just switch lines 59 and 60 in the Makefile 12:55:30 <planetmaker> oh, I see. 12 minutes is my build time for ogfx-trains with NML alone 12:57:15 <planetmaker> Xotic750: can you refrain from pushing to the ogfx-trains repo for the next hour or so (until notice)? I'd like to try converting to the largefile extension 12:58:05 <Xotic750> no problem 13:02:14 <frosch123> he, how many mb did you push since yesterday :p i just pulled yesterday, and it takes again ages to pull today 13:02:48 <frosch123> 9000 files changes :p 13:03:29 <Xotic750> :) 13:03:45 <Xotic750> lots more models and full render and post-process 13:04:18 <frosch123> [Tuesday 22 May 2012] [22:04:38] <frosch123> ogfx-trains is at 670 MB 13:04:28 <frosch123> today its 888 MB :p 13:04:42 <frosch123> 200 MB in 17 hours :) 13:05:02 <planetmaker> easy to do, yes 13:05:06 <Xotic750> yeah, that the new models, about 15 or so 13:05:59 <planetmaker> I'll enable globally the largefiles extension for sprite_source/* and files > 5 megabytes 13:06:07 <Xotic750> I'm guessing by the time we have everything done it will be 4GB or more 13:06:08 <planetmaker> thus they're only transmitted afterwards upon pull 13:06:20 <planetmaker> when needed 13:07:38 <planetmaker> of course it won't reduce the repo size server-side. But make it much lighter for users to pull, I think 13:08:10 <Xotic750> there must be something wrong on the server though 13:08:24 <Xotic750> as https works on bitbucket for ogfx-trains 13:09:15 <planetmaker> yes, it's the configuration of the web server which needs adjustment 13:19:31 <Xotic750> is there a problem with nightly builds, the last one appears to be the 14/5? 13:27:18 <planetmaker> Ammler: when you have time... could you look at the https issue with pulls? http://paste.openttdcoop.org/show/1421/ 13:28:16 <planetmaker> hg lfconvert still running server-side... 13:35:25 <frosch123> planetmaker: nml+nfo+grfcodec is approaching 30 minutes buildtime, and it was no make clean :p 13:35:40 <planetmaker> for ogfx-trains? 13:35:43 <Ammler> planetmaker: and what you expect me to do, or do I miss something in that paste? 13:35:47 <frosch123> sure, what else? 13:36:10 <Ammler> basically you sell openttd to the hg devs, whih is nice :-P 13:36:11 <planetmaker> Ammler: configure the webserver such that a pull via http does not fail 13:36:33 <planetmaker> the hint I was given is that it needs 13:37:06 <Ammler> oh well, yes, of course, obvious that is not new to me, I still have no clue, what to do :-P 13:37:58 <planetmaker> the hint is controlling the timeouts for cgi scripts. Not sure it makes sense 13:38:45 <planetmaker> but yes, selling openttd to hg devs :-P 13:39:16 <Ammler> as said, config someting like tat is obvious, but I would need to know how 13:40:19 <planetmaker> yep. Please find out :-) 13:40:47 <planetmaker> maybe also the hg people know more. But you know that stuff much better than me. So you can also ask the better questions 13:42:12 <frosch123> what webserver are you running? 13:44:43 <planetmaker> nginx with gunicorn 13:47:24 <frosch123> approaching 40 minutes 13:47:42 <planetmaker> :-O 13:48:05 <planetmaker> my "hg lfconvert" for the ogfx-trains repo is also still running... 13:50:30 <frosch123> http://wiki.nginx.org/HttpFastcgiModule#fastcgi_read_timeout <- that matches the experienced 60 seconds 13:50:31 <Webster> Title: HttpFastcgiModule (at wiki.nginx.org) 13:52:19 <frosch123> oh, "fastcgi_connect_timeout" cannot exceed 75 seconds 13:52:35 <frosch123> so, if it's that setting, hg would generally fail with nginx 13:53:42 <planetmaker> where's that limitation mentioned? 13:53:54 <frosch123> there are various timeout settings 13:54:13 <frosch123> read_timeout, connect_timeout, ... 13:54:24 <frosch123> not sure which applies :p 13:56:01 <frosch123> hmm, oh, i think it did not even start encoding 13:56:19 <frosch123> make seems to be trapped in some dependency loop 13:56:49 <frosch123> top displays no activity whatosever 13:57:03 <frosch123> so, hg purge --all and restart :s 13:57:18 <Ammler> frosch123: I don't think, we use fcgi, but I need to check 13:58:36 <Ammler> we don't, we use unicorn via proxy_pass 13:58:45 <Ammler> or gunicorn 13:59:02 <frosch123> it mentions also various proxy timeout 13:59:56 <frosch123> proxy_connect_timeout 14:00:09 <frosch123> also limited to 75s 14:00:09 <planetmaker> frosch123: you tried ogfx-trains with the Makefile_nmlnfogrf ? 14:00:15 <frosch123> yes 14:00:27 <frosch123> it fails in the depend stage 14:00:34 <frosch123> just hangs with 0% cpu :s 14:00:36 <planetmaker> hm... maybe I did not add the -g 2 in scripts/Makefile_def ? 14:00:36 <frosch123> even after purge 14:00:42 <frosch123> i added it 14:00:42 <planetmaker> err... there's no dep stage? 14:00:47 <planetmaker> what rev do you build? 14:00:58 <Ammler> http://wiki.nginx.org/HttpProxyModule#proxy_read_timeout 14:00:59 <Webster> Title: HttpProxyModule (at wiki.nginx.org) 14:01:01 <frosch123> i pulled when you started largefile 14:01:01 <Ammler> maybe 14:01:10 <frosch123> 538:d47771564d5f 14:01:18 <planetmaker> hm, try rm *.dep && rm .version 14:01:27 <frosch123> i did purge --all 14:01:46 <planetmaker> frosch123: the pull currently should still work. The repo is not modified (I convert it to a different folder and will move paths later) 14:02:08 <Ammler> Xotic750: possible the error was timeout (1min)? 14:02:22 <planetmaker> it's possible, yes, Ammler 14:02:31 <planetmaker> just try clone it via http yourself and you'll see 14:02:41 <planetmaker> easy to reproduce 14:02:43 <Ammler> ah ok 14:03:13 <frosch123> maybe put a "time" in front, so you get some number as hint 14:03:36 <frosch123> e.g. if it changes from 60 to 75 :p 14:03:37 <planetmaker> :-) 14:04:22 <Ammler> omg 14:04:35 <Ammler> it would need 30 mins here :-o 14:04:49 <planetmaker> :-) 14:04:52 <Xotic750> :) 14:04:52 <frosch123> 800 MB :p 14:05:36 <planetmaker> lfconvert still running... 14:05:52 <planetmaker> without visible progress tbh. But the destination repo exists already... 14:06:11 <frosch123> planetmaker: if i comment out "-include Makefile_gfx.dep", i get " No rule to make target `gfx', needed by `ogfx-trains.grf'. Stop." 14:06:34 <Ammler> rised timeout to 10min and check 14:07:00 <Ammler> no, it is something else 14:07:10 <frosch123> Ammler: when did it time out for you? 14:07:16 <Ammler> imo, the crash happens before 1min 14:08:29 <Ammler> I am very suprised, hg has no solution for this, how does git handle it? 14:08:50 <Ammler> hmm, 1min exactly 14:08:58 <frosch123> i only used git over git, not http 14:09:18 <planetmaker> Ammler: obviously there *is* a solution as bitbucket works ;-) 14:09:21 <frosch123> however, what feels silly about hg is that it cannot do this stuff incremental itself 14:09:35 <frosch123> if it times out, it revers everything 14:09:53 <planetmaker> yup, that's not good 14:10:07 <Ammler> planetmaker: any url there? 14:10:07 <planetmaker> for ...? 14:10:14 <frosch123> planetmaker: maybe it does not use ngynx? 14:10:15 <planetmaker> bitbucket? 14:10:16 <Ammler> to test bigbucket 14:10:34 <planetmaker> xotic posted the ogfx-trains backup URL earlier... 14:10:53 <Ammler> ah ok 14:10:59 <Ammler> th one from hgm.openttdcoop.org? 14:11:17 <frosch123> Ammler: for me it looks like 75s timeout 14:11:26 <frosch123> can you set it to some lower value like 30 now? 14:11:31 <frosch123> then we can check whether it is the right setting 14:11:41 <frosch123> and the ngynx limit of 75s causes the fail 14:12:34 <Ammler> the connect timeout is also 60s 14:12:42 <Ammler> 75 is the max 14:12:50 <frosch123> the connect timeout looks more relevant than the read timeout 14:13:04 <frosch123> connect is for total timeout, while read is only between packets or so 14:13:10 <Ammler> but we are screwed if it is so 14:13:17 <frosch123> but, since hg is transfering continously, the read timeout has no effect 14:13:20 <Ammler> hmm 14:14:50 <planetmaker> Ammler: https://bitbucket.org/Xotic750/ogfx-trains 14:14:50 <Ammler> afaik, bitbucet uesnginx toooo 14:14:52 <Webster> Title: Xotic750 / ogfx-trains / overview Bitbucket (at bitbucket.org) 14:16:54 <Ammler> it looks like the issue is on gunicorn 14:23:49 <frosch123> planetmaker: no idea what's different on my machine compare to yours, but unmodified ogfx trains head completely fails to build 14:23:58 <frosch123> i am going to an older revision now 14:24:17 <planetmaker> hm, strange 14:24:46 <planetmaker> frosch123: you could simply define the 'gfx' target as dummy target 14:24:51 <planetmaker> it should be such anyway 14:25:00 <planetmaker> within this newgrf 14:25:24 <frosch123> i removed the dependency on that target, and it failed on nfo 14:25:46 <planetmaker> in what way? 14:26:37 <Ammler> I guess, that hg is that much faster as git is becuase of that stupid bundling 14:26:39 <frosch123> http://paste.openttdcoop.org/show/1422/ <- wrong paths or so 14:26:50 <frosch123> r537 seems to build 14:27:01 <planetmaker> hm 14:27:09 <frosch123> at least nml is now working on generating the grf 14:27:46 <planetmaker> well, r537 has the old makefile stuff with deps and alike 14:30:05 <planetmaker> hm, I see... 14:35:27 <frosch123> hmm, "src/gfx/engines/passenger/gui/blank32.png: Cannot read 32bpp PNG files without alpha layer!" :( 14:35:44 <frosch123> i cannot even count the number of bugs/problems anymore 14:37:35 <frosch123> haha, how many blank32.png are there? :p 14:43:12 <Xotic750> 1 for each model, only needs 1 for all but haven't got around to modifying the template to deal with that 14:43:12 <Xotic750> it's a 1x1 black image 14:43:12 <frosch123> wrote a bash script to fix them all for grfcodec 14:43:12 <Xotic750> I'm not even sure if they are needed 14:43:12 <frosch123> though i guess these might also be those sprites which fail for nml 14:43:40 <frosch123> what? ... the nml->nfo->grf grf is twice as big as the nml->grf grf 14:43:49 <frosch123> oh, cropping i guess 14:44:44 <frosch123> still 2MB bigger 14:45:13 <planetmaker> nml optimized the compression 14:45:52 <frosch123> and grfcodec throws similiar errors when decoding its own output like when decoding the nml output 14:47:52 <frosch123> oh, now i actually understand the bug in grfcodec 14:50:05 <Xotic750> I now have my first monorail model, the empty bulk :) 14:53:09 <frosch123> \o/ grfcodec can decode its own output 14:53:33 <frosch123> it fails for nml because nml seems to encode rgb without alpha for the blank sprites 14:53:38 <frosch123> which grfcodec cannot handle 14:54:52 <frosch123> let's try whether it works with pure rgba 14:56:12 <Xotic750> I can use a 1x1 black png and add the alpha channel if it makes it easier for you? 14:56:37 <frosch123> that's what i have done locally 14:56:58 <frosch123> but it should either work, or print a proper error message :) 14:57:42 <Xotic750> it's upto you, it is just 1 file to change and then when the next post-process run happens then they will all change 14:58:13 <frosch123> it seems to work for nml 14:58:30 <frosch123> but if you want to use the nml->nfo->grfcodec approach, you likely have to add the alpha channel 14:58:40 <frosch123> as grfcodec can only handle rgba 14:59:01 <Xotic750> ok, I'll add an alpha channel to the png source 15:09:42 <planetmaker> hm... 15:10:01 <planetmaker> my connection closed, I didn't use screen, and hg lfconvert was probably not finished :S 15:11:41 <Xotic750> :) 15:12:45 <planetmaker> lol. frosch123, I think I know why nml->nfo->grf failed with the new makefile 15:12:59 <planetmaker> I only echo the command to stdout instead of executing it ;-) 15:13:05 <planetmaker> which generates the nfo ;-) 15:13:26 <Xotic750> any visibility on munin with the render running? 15:14:06 <Xotic750> haven't heard any cries of dispair :) 15:14:36 <planetmaker> server did not yet become unresponsive in any way. Or at least I didn't really notice... except maybe my failed ssh connection ;-) 15:16:21 <planetmaker> Xotic750: in your .hgrc, you'll need to enable the largefiles extension. Under [extensions]: 15:16:22 <planetmaker> largefiles = 15:16:29 <planetmaker> and create a new section: 15:16:41 <planetmaker> [largefiles] 15:16:41 <planetmaker> minsize = 5 15:16:41 <planetmaker> patterns = sprite_source/* 15:17:00 <planetmaker> you'll need mercurial 2.0 or newer 15:17:45 <planetmaker> I've not yet switched the official repo. The largefiles repo is available from hg clone ssh://ottdc@mz.openttdcoop.org/hg-repos/lf.ogfx-trains 15:18:57 <Xotic750> ok, added to hgrc 15:19:27 <planetmaker> don't use that test repo though for work yet. I'm still verifying whether it works... might need to convert it anew. 15:19:36 <Xotic750> hmm 15:19:38 <Xotic750> Mercurial Distributed SCM (version 1.9.3) 15:19:52 <planetmaker> when it works, the URL of the repo won't change 15:20:00 <Brot6> GRFCodec - Revision 934:705e415b886b: Fix #3942: Decoding of regular encoded 32bpp sprites failed. (frosch) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/705e415b886b 15:20:00 <Brot6> GRFCodec - Revision 935:8ef3b890381e: Fix: Print appropiate error message when trying to decode unsu... (frosch) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/8ef3b890381e 15:20:00 <Brot6> GRFCodec - Bug #3942 (Closed): Corrupt encoding of container version 2 GRF (frosch) @ http://dev.openttdcoop.org/issues/3942#change-10882 15:20:12 <Xotic750> fedora 16 official release 15:20:48 <planetmaker> hm. Since 2.0 the largefiles is an official extension. It might exist earlier, but it might also work differently 15:21:24 <Xotic750> and on the render server 15:21:25 <Xotic750> Mercurial Distributed SCM (version 1.4) 15:21:32 <planetmaker> he 15:22:15 <planetmaker> we got to hack that then, I guess. 15:22:29 <frosch123> planetmaker: what size is .hg now? 15:22:47 <planetmaker> frosch123: dunno. On the server of course the same... 15:22:59 <Xotic750> I guess that means downloading source and compiling mercurial on my machines and the render server 15:23:04 <Xotic750> :( 15:23:46 <planetmaker> Xotic750: you should be able to just download the binary package 15:23:47 <Xotic750> unless the development repo has >v2 15:24:07 <Xotic750> ok, they supply it on their site? 15:24:11 <planetmaker> sure 15:24:24 <Xotic750> I wonder if they have an rpm repo 15:24:35 <Xotic750> so I can just yum update 15:24:42 <planetmaker> they might not have that, not sure. As that needs to be very specific to a distro 15:25:02 <planetmaker> but they do have generic binary distributions 15:25:28 <Xotic750> I will have to have a poke around their site 15:25:46 <Xotic750> I guess I won't be able to push without >2 ? 15:25:54 <Xotic750> or is it just pulling? 15:25:55 <planetmaker> http://mercurial.selenic.com/ <-- right on the main page 15:25:56 <Webster> Title: Mercurial SCM (at mercurial.selenic.com) 15:26:13 <planetmaker> of course it's also pushing 15:26:40 <planetmaker> hm... 15:26:49 <planetmaker> they provide osx and windows, but not linux? 15:28:01 <frosch123> planetmaker: did you find the autorefit issue yesterday? 15:31:13 <frosch123> haha, some translators translate the "trains" in the grfname, some don't :p 15:32:48 <Xotic750> don't see any repo's available or any binaries 15:38:56 <planetmaker> Xotic750: I fear you're right. There's no linux binaries. I find that surprising :-) 15:39:27 <Xotic750> there not even one in --enablerepo=updates-testing 15:39:27 <planetmaker> frosch123: no, I did not yet. But I did not get over more than 20 minutes of head scratching why possibly r445 breaks it 15:39:51 <planetmaker> (after testing several revisions along with terkh3n 15:39:52 <planetmaker> ) 15:40:15 <Xotic750> looks like a build it yourself job 15:40:38 <planetmaker> :-( 15:40:53 <planetmaker> Xotic750: somehow ammler updated the version on devzone within seconds... 15:41:24 <Xotic750> what's the server running? 15:41:29 <Xotic750> os wise 15:44:05 <Xotic750> I have 4 monorail bulk wagons modeled now :) 15:47:39 <planetmaker> I'm currently not even sure which distro it runs... 15:48:05 <planetmaker> I *think* centos 15:48:35 <Xotic750> so he may have a client for the render server 15:50:58 <Xotic750> 2.1 is available for fedora 17, it may work for me 15:51:51 <Xotic750> and also for rhel6 15:52:02 <Xotic750> which may work for centos 15:53:30 <planetmaker> ammler basically maintains a suse build service on this server (which also works for fedora,...). Thus it might be self-built. 16:00:49 <Ammler> I will always use suse, if possible 16:01:16 <Ammler> it has by far the best software support 16:04:03 <planetmaker> Xotic750: ok, the conversion to the lf repo did not yet work. I'll play around locally some more. Feel free to continue committing to the existing repo under the existing URL 16:04:33 <planetmaker> I just pulled a repo which - including checkout - is of a size of 1.2 Gigabytes... 16:04:47 <Xotic750> ok 16:12:54 <Xotic750> well, just built it on my main laptop, Mercurial Distributed SCM (version 2.2.1) 16:14:58 *** ODM has joined #openttdcoop.devzone 16:19:51 <planetmaker> it has a nice thing: hg commit --amend 16:20:06 <planetmaker> it allows to extend the last commit, if it has not been pushed yet :-) 16:20:24 <planetmaker> I like that when I fix stuff 16:24:00 <michi_cc> So hg is slowly gaining all the git functions? :-P 16:25:08 <planetmaker> there's been the hg qrefresh before (and still there is) 16:25:40 <frosch123> michi_cc: yeah, it just makes them more proper 16:25:46 <frosch123> just like ottd vs ttdp :p 16:25:52 <planetmaker> but this is more convenient if you don't want to start a patch queue but have a single patch 16:30:39 <Xotic750> compiled and installed on the render server 16:31:50 <Xotic750> how is this going to work for the general public that don't have it though? 16:32:23 <planetmaker> have mercurial 2.0+? 16:32:54 <planetmaker> they'll have to get it or grab a source tar ball which we provide for releases 16:33:21 <planetmaker> I see no big issue with that tbh 16:35:17 <Ammler> there are also source tarballs on hg.opnttdcoop.org, thse work, riht? 16:35:42 <Ammler> or do hey have same issue as the hg clone? 16:36:10 <planetmaker> I never tested :-) 16:36:24 <planetmaker> I wasn't even aware of that option 17:04:12 <Brot6> OpenGFX+ Trains - Revision 539:9825e35c2b95: Fix: Added alpha channel for grfcodec compatability (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/9825e35c2b95 17:05:27 <Brot6> OpenGFX+ Trains - Revision 540:5f81897227a1: Fix: Temporary output filename, was missing underscore (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/5f81897227a1 17:07:28 <Brot6> OpenGFX+ Trains - Revision 541:ed81284394ec: Add: Blender file, short bulk wagon for year dependancy... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/ed81284394ec 17:09:51 <Brot6> OpenGFX+ Trains - Revision 542:2962c722a3e2: Add: Blender models for monorail bulk wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/2962c722a3e2 17:16:22 <Terkhen> planetmaker: autorefit works in r396, but it is broken in r400 17:16:27 <Terkhen> r398 does not compile 17:16:39 <planetmaker> hu?! 17:16:57 <Terkhen> I've repeated it three times already :P 17:17:27 <Terkhen> can you confirm it? 17:17:41 <Terkhen> (as there is nothing between those revision besides graphics) 17:17:51 <Terkhen> meanwhile I'm testing r399 17:21:13 <planetmaker> I need a bit time. I'm currently running a hg lfconvert which eats most ressources 17:21:15 <Terkhen> 399 works :O 17:21:19 <Terkhen> ok 17:21:53 <planetmaker> Terkhen: try r400 and undo the hunk which makes use of the GUI distinction 17:22:02 <Terkhen> ok, let's see 17:23:08 <planetmaker> http://hg.openttdcoop.org/ogfx-trains/rev/264af453d69f <-- 1.119 / 1.20 17:23:12 <planetmaker> *1.120 17:34:55 <Terkhen> planetmaker: autorefit is still broken with that change, after undoing 1.136, 1.1.37 it still does not work 17:35:37 <Terkhen> maybe it is because of the misc flags addition? 17:35:57 <Terkhen> it's the only thing missing besides sprite definitions, let's see 17:36:39 <planetmaker> would be strange. But maybe 17:39:55 *** andythenorth has joined #openttdcoop.devzone 17:41:06 <Terkhen> planetmaker: http://devs.openttd.org/~terkhen/patches/index.php?source=flatbed_autorefit_r400.diff <--- that diff makes autorefit work for the flatbed in r400 17:41:16 <Terkhen> with the misc_flags it does not work 17:41:22 <Terkhen> that's... unexpected :) 17:41:35 <Terkhen> I'll test my ogfx-rv code, IIRC all of my road vehicles make use of misc_flags 17:42:36 <Brot6> OpenGFX+ Trains - Revision 543:cb26b46cbeaf: Change: Added monorail infrastructure for shadows (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/cb26b46cbeaf 17:42:57 <Terkhen> nope, they don't 17:51:46 <Terkhen> huh... I'm stupid 17:52:30 <Terkhen> ogfx-rv wasn't compiling, I'm getting an error while generating the pngs 17:52:43 <planetmaker> uh. what kind? 17:53:06 <Terkhen> /bin/sh: line 1: 8613 Bus error gimp -i -b - < src/gfx/flatbed_truck/flatbed_truck_3_paper.gimp.scm > /dev/null 17:53:39 <planetmaker> that's gimp failing 17:54:06 <planetmaker> try a make -j1 (or at least less than you used) 17:55:23 <Terkhen> ok :) 17:55:26 <Terkhen> thanks 17:58:14 <planetmaker> Xotic750: https://dev.openttdcoop.org/projects/area51/wiki/Munin <-- should show how to get munin working on that container 17:58:24 <^Spike^> he can't access it? 17:58:28 <^Spike^> it's our a51? 17:58:53 <^Spike^> as far as i know only members have access there 17:59:43 <planetmaker> oh 17:59:43 <^Spike^> for obvious reasons seeing the wiki pages 17:59:44 <planetmaker> yes 17:59:45 <Xotic750> yep, not autorised :) 18:00:24 * planetmaker assigns task to ^Spike^ to activate munin on render container :-P+ 18:01:14 * ^Spike^ picks up calculator... 18:01:22 <^Spike^> according to my boss... that will be......... 18:01:30 * planetmaker blocks own computer with yet another parameter set of hg lfconvert 18:01:30 <^Spike^> pm i woud like my donation back atleast then ;) 18:01:37 <planetmaker> :-D 18:02:50 <^Spike^> check again in 5-10 mins 18:03:16 <Terkhen> meh, I have no idea why my code does nothing in ogfx-rv 18:03:19 <Terkhen> it seems that I'll have to check it again :O 18:03:31 <^Spike^> cause pm / Xotic750 it's not like logging told you guys the problem: 18:03:31 <^Spike^> 2012/05/23-20:00:11 CONNECT TCP Peer: "10.10.101.126:60302" Local: "10.10.101.113:4949" 18:03:31 <^Spike^> 2012/05/23-20:00:11 [29437] Denying connection from: 10.10.101.126 18:03:37 <planetmaker> hm 18:05:23 <Xotic750> if I need to do something, other than stop fw and disable selinux, let me know :) 18:06:26 <^Spike^> should be fixed already 18:06:30 <^Spike^> :) 18:06:47 <^Spike^> only problem with a plugin but i know solution for that 18:14:17 <^Spike^> http://munin.openttdcoop.org/openttdcoop.org/render.openttdcoop.org/index.html 18:14:20 <^Spike^> hey it works.... 18:15:46 *** Zuu has joined #openttdcoop.devzone 18:15:49 <Xotic750> looks very empty :) 18:15:56 <^Spike^> it just started so :) 18:25:31 *** Nat_AFK is now known as NataS 18:25:38 <Terkhen> planetmaker: refit_cost: return 0 | CB_RESULT_AUTOREFIT; <--- adding that to my graphics block should force autorefit to work, right? 18:26:01 <planetmaker> uhm... to the callback block 18:26:15 <planetmaker> oh, you mean no distinction, just always? Yes 18:26:37 <Terkhen> oh, I found where I have my misc_flags, let's see what happens without them 18:41:55 <Xotic750> planetmaker: there seems to be a big difference in the monorail bulk wagon compared to the standard, is it meant to be like that or it's just that monorail has been neglected? 18:46:45 <planetmaker> what do you mean with "standard"? 18:47:04 <planetmaker> ofc monorail is supposed to be different than rail 18:47:36 <planetmaker> or do you mean cargo support? 18:47:46 <planetmaker> that's negligence 18:47:49 <Xotic750> I mean the supported cargo types 18:48:05 <planetmaker> they actually do support the same cargos. Just not by sprites 18:48:28 <Xotic750> I've made monorail bulk wagons for all the same as in the standard rail 18:48:37 <planetmaker> :-) 18:48:45 <planetmaker> sounds awesome 18:48:50 <Xotic750> :P 18:50:15 <Xotic750> not sure if I need more or different ones for tropical though 18:50:23 <Xotic750> and how they all will fit in 18:50:34 <Xotic750> but the sprites will be done tonight 18:50:44 <planetmaker> hehe 18:50:46 <Xotic750> for the smae loads as standard rail 18:51:42 <planetmaker> Generally my idea is to distinguish climates and to have special sprites for each cargo (as much as applicable) for each wagon 18:52:06 <planetmaker> obviously there's not much one can do about containers except changing some fictious company logo or so on its sides 18:54:33 <Xotic750> what is the difference between arctic coal and temperate coal for example :) 18:56:25 <Xotic750> maybe I'll just move on past the nml and get the monorail flatbeds done :P 18:57:51 *** andythenorth has quit IRC 18:59:07 <planetmaker> arctic coal and temperate coal - iirc - have a different wagon colouring 18:59:13 <Terkhen> planetmaker: ogfx-trains issue with autorefit is probably the redefinition of misc_flags 18:59:32 <planetmaker> let's see 18:59:32 <Terkhen> you must be defining TRAIN_FLAG_AUTOREFIT somewhere else 18:59:46 <Terkhen> and it gets redefined by the new code in r400 (in the case of the flatbed) 18:59:55 <Terkhen> because of the addition of the 2CC flag 19:00:12 <Terkhen> I was doing something similar in ogfx-rv, I'm currently trying to fix my mess :P 19:00:37 <planetmaker> indeed Terkhen! Excellent find. Thanks a lot 19:03:17 <Terkhen> yw :) 19:03:30 <planetmaker> all the 2CC additions killed it 19:03:40 <Terkhen> my code was completely broken, I somehow lost the latest version of it 19:03:53 <Terkhen> luckily I pasted the vehicle_definitions file to show it to you 19:04:09 <planetmaker> :-) 19:08:37 <planetmaker> oh, I like the wording "Lade veränderte Binärriesen herunter" especially "Binärriesen" :-) 19:16:20 <planetmaker> Xotic750: with the introduction of all the 2CC for the wagons the misc_flags were defined twice, killing the previous deinition, thus killing refit 19:17:00 <planetmaker> don't define that property for the wagons; it's (now) part of the template used by (nearly) all wagons 19:17:11 <planetmaker> well. now. very soonish :-) 19:26:12 <Terkhen> planetmaker: my code is working now, with the new vehicle_definitions file 19:26:16 <Terkhen> any ideas for a better name? 19:26:57 <planetmaker> in ogfx-trains it's still called cargo_definitions.pnml 19:27:21 <Terkhen> that's also the current name in ogfx-rv, until I commit :) 19:27:24 <planetmaker> even adding the refit switches there, I think it needs not renaming 19:27:30 <Xotic750> ok 19:27:34 <Terkhen> it includes cargo definitions, refit definitions and refit callbacks 19:27:43 <Terkhen> I don't mind keeping the old name 19:27:51 <planetmaker> yeah, it's basically your file which I have here :-) 19:28:04 <planetmaker> well, I don't know a better name really. 19:28:14 <Terkhen> ok :P 19:28:18 <planetmaker> vehicle_definitions is too general. I've several files which define larger parts of vehicles 19:28:28 <Terkhen> I'll keep cargo_definitions 19:28:30 <planetmaker> like templates_wagons.pnml and similar 19:28:48 <Terkhen> drop me a line when you adapt the new file to ogfx-trains (I mean the _MU_ thing) 19:29:07 <planetmaker> hm, it *is* 19:29:28 <planetmaker> checkout the tip of ogfx-trains. 19:29:30 <planetmaker> it should have that addition already 19:29:56 <planetmaker> even your tip. I basically committed that when you suggested it and said that your tests were successful 19:30:18 <Terkhen> oh, ok :P 19:30:37 <planetmaker> impation blag here :-P 19:30:52 <Terkhen> indeed, I did not test that code until 15 minutes ago when it started working :P 19:31:00 <Terkhen> all of my problems where in other files, though 19:31:09 <Terkhen> so it *should* have no changes 19:31:14 <Terkhen> but... I don't remember :) 19:31:14 <planetmaker> :-D 19:32:04 <Terkhen> besides 32bpp and autorefit, do you have any other shiny new features? 19:36:35 <Brot6> OpenGFX+ Trains - Revision 544:a4824a8f2921: Fix: Refit was broken due to double definition of the m... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/a4824a8f2921 19:36:35 <Brot6> OpenGFX+ Trains - Revision 545:0cd3cc6883f6: Fix: [Makefile] Building failed under certain condition... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/0cd3cc6883f6 19:37:16 <planetmaker> hm... I should have tested r544... 19:37:45 <Terkhen> probably :P 19:38:07 <planetmaker> We shall see in 15 minutes. Build initiated... 19:38:57 <Terkhen> planetmaker: if there are no other relatively new features I'll probably release soon :) 19:39:24 <Terkhen> after the usual (fruitless) call for nightly testing and for additional translations 19:40:03 <planetmaker> :-) 19:40:22 <planetmaker> translations is not necessarily fruitless. Though ogfx+rv should be mostly done, I guess? 19:40:40 <planetmaker> and... do you want to wait for this build system I currently test-run on ogfx-trains? 19:40:50 <planetmaker> or shouldn't we care about that for a release? 19:40:56 <planetmaker> I guess it doesn't matter there at all 19:41:09 <planetmaker> and could as well be added afterwards 19:42:16 <Ammler> Xotic750: http://paste.openttdcoop.org/show/1424/ 19:42:35 <planetmaker> Ammler: ... but it's working already 19:43:47 <Xotic750> not needed? 19:44:02 <planetmaker> ^Spike^: already did that afaik 19:46:49 <Xotic750> yep, that is definately in there 19:53:32 <Terkhen> with fruitless I meant the testing :P 19:53:50 <Terkhen> and yes, having the new build system would be nice, but not critical for release 20:13:40 *** NataS is now known as Nat_AFK 20:16:56 *** Nat_AFK is now known as NataS 20:19:33 <planetmaker> autorefit seems to work again, Terkhen! :-) 20:19:45 <planetmaker> the misc_flags was indeed something I totally didn't have my eyes on 20:23:18 <Terkhen> perfect :) 20:25:49 <Brot6> OpenGFX+ Road Vehicles - Revision 145:a984f5ba3b6d: Feature: Autorefit at road stops (many parts bor... (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/a984f5ba3b6d 20:26:21 <Terkhen> and now it works in ogfx-rv too 20:26:25 <Terkhen> next: readme 20:29:22 *** frosch123 has quit IRC 20:31:02 <planetmaker> :-) 20:33:00 <Brot6> OpenGFX+ Road Vehicles - Revision 146:019744abd825: Doc: New readme format. (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/019744abd825 20:45:45 *** andythenorth has joined #openttdcoop.devzone 20:57:45 *** ODM has quit IRC 21:11:37 *** andythenorth has quit IRC 21:20:09 <Xotic750> 11 more monorail flatbed wagons to go, phew 21:55:39 <Brot6> OpenGFX+ Trains - Revision 546:22659e759233: Fix: Removed some leftover traces of the material ancho... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/22659e759233 21:58:01 <Brot6> OpenGFX+ Trains - Revision 547:3ca05a93f25a: Add: Blender models for monorail flatbed wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/3ca05a93f25a 22:16:50 <Brot6> OpenGFX+ Trains - Revision 548:6986b84c1f93: Fix: Moved chassis to correct parent (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/6986b84c1f93 22:17:55 *** Dr_Tan has joined #openttdcoop.devzone 22:18:01 *** Dr_Tan is now known as Nat_aS 22:18:08 <Brot6> OpenGFX+ Trains - Revision 549:b6886aa611c8: Add: Blender models for monorail tank wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/b6886aa611c8 22:18:09 *** Zuu has quit IRC 22:25:12 *** NataS has quit IRC 22:27:50 <Brot6> OpenGFX+ Trains - Revision 550:22f2bc19aeff: Fix: Removed some leftover traces of the material ancho... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/22f2bc19aeff 22:29:00 <Brot6> OpenGFX+ Trains - Revision 551:6c6278d043ab: Add: Blender models for monorail goods, livestock and r... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/6c6278d043ab 22:35:56 <Brot6> OpenGFX+ Trains - Revision 552:68a54b0d05b9: Add: Render run of all monorail bulk wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/68a54b0d05b9 22:36:53 <Brot6> OpenGFX+ Trains - Revision 553:fa19e66ed38e: Add: Post-processed run of all monorail bulk wagons (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/fa19e66ed38e 23:00:17 <Brot6> OpenGFX+ Trains - Revision 554:c808db727ed1: Add: Blender models for monorail passenger, armoured an... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/c808db727ed1 23:07:32 <Brot6> OpenGFX+ Trains - Revision 555:e4a8f792c1f2: Fix: Revert accidental overwrite (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/e4a8f792c1f2 23:07:32 <Brot6> OpenGFX+ Trains - Revision 556:1824a5395ac9: Add: Blender models for monorail passenger, armoured an... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/1824a5395ac9 23:35:35 <Brot6> OpenGFX+ Trains - Revision 557:681bb66b73f3: Add: Render run of all monorail goods, livestock and re... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/681bb66b73f3 23:36:45 <Brot6> OpenGFX+ Trains - Revision 558:985a7bf4d1cd: Add: Post-processed run of monorail goods, livestock an... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/985a7bf4d1cd 23:45:32 *** orudge` has joined #openttdcoop.devzone 23:46:33 *** orudge has quit IRC