Log for #openttdcoop.devzone on 23rd May 2012:
Times are UTC Toggle Colours
00:00:14  <Brot6> OpenGFX+ Trains - Revision 534:4c4aa8ed5a22: Fix: Spelling mistake on vehicles (Xotic750) @
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) @
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) @
11:06:50  <Brot6> Makefile for NewGRFs: Common part - Revision 11:de22bd16f573: Change: Rename all Makefile parts so t... (planetmaker) @
11:06:50  <Brot6> Makefile for NewGRFs - Revision 12:eb7638080710: Change: Rename all Makefile parts so that they don'... (planetmaker) @
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) @
11:15:49  <Brot6> Makefile for NewGRFs - Revision 13:3acbfa6ba3dc: Fix: Reference the correct graphics dependency file... (planetmaker) @
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
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 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;  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>
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>
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<;>.  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<;>.  Exit value/signal: 18/0
11:55:21  <Ammler> so it was not fw
11:56:38  <Ammler> munin:/etc/munin # ping
11:56:40  <Ammler> PING ( 56(84) bytes of data.
11:56:41  <Ammler> 64 bytes from ( 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) @
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) @
12:16:25  <Brot6> OpenGFX+ Trains - Revision 538:d47771564d5f: Change: [Makefile] Rewrite with removal of code depende... (planetmaker) @
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>
12:28:07  <Webster> Title: Old Coal Wagon | Flickr - Photo Sharing! (at
12:28:32  <Xotic750> very losley of course :)
12:29:09  <planetmaker> may I suggest some 8bpp sprites (6/8 length, though)?
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) @
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>
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) @
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?
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> <- that matches the experienced 60 seconds
13:50:31  <Webster> Title: HttpFastcgiModule (at
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>
14:00:59  <Webster> Title: HttpProxyModule (at
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
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:
14:14:50  <Ammler> afaik, bitbucet uesnginx toooo
14:14:52  <Webster> Title: Xotic750 / ogfx-trains / overview Bitbucket (at
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> <- 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://
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) @
15:20:00  <Brot6> GRFCodec - Revision 935:8ef3b890381e: Fix: Print appropiate error message when trying to decode unsu... (frosch) @
15:20:00  <Brot6> GRFCodec - Bug #3942 (Closed): Corrupt encoding of container version 2 GRF (frosch) @
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> <-- right on the main page
15:25:56  <Webster> Title: Mercurial SCM (at
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, 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) @
17:05:27  <Brot6> OpenGFX+ Trains - Revision 540:5f81897227a1: Fix: Temporary output filename, was missing underscore (Xotic750) @
17:07:28  <Brot6> OpenGFX+ Trains - Revision 541:ed81284394ec: Add: Blender file, short bulk wagon for year dependancy... (Xotic750) @
17:09:51  <Brot6> OpenGFX+ Trains - Revision 542:2962c722a3e2: Add: Blender models for monorail bulk wagons (Xotic750) @
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> <-- 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: <--- 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) @
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: <-- 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: "" Local: ""
18:03:31  <^Spike^> 2012/05/23-20:00:11 [29437] Denying connection from:
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^>
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) @
19:36:35  <Brot6> OpenGFX+ Trains - Revision 545:0cd3cc6883f6: Fix: [Makefile] Building failed under certain condition... (planetmaker) @
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:
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) @
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) @
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) @
21:58:01  <Brot6> OpenGFX+ Trains - Revision 547:3ca05a93f25a: Add: Blender models for monorail flatbed wagons (Xotic750) @
22:16:50  <Brot6> OpenGFX+ Trains - Revision 548:6986b84c1f93: Fix: Moved chassis to correct parent (Xotic750) @
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) @
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) @
22:29:00  <Brot6> OpenGFX+ Trains - Revision 551:6c6278d043ab: Add: Blender models for monorail goods, livestock and r... (Xotic750) @
22:35:56  <Brot6> OpenGFX+ Trains - Revision 552:68a54b0d05b9: Add: Render run of all monorail bulk wagons (Xotic750) @
22:36:53  <Brot6> OpenGFX+ Trains - Revision 553:fa19e66ed38e: Add: Post-processed run of all monorail bulk wagons (Xotic750) @
23:00:17  <Brot6> OpenGFX+ Trains - Revision 554:c808db727ed1: Add: Blender models for monorail passenger, armoured an... (Xotic750) @
23:07:32  <Brot6> OpenGFX+ Trains - Revision 555:e4a8f792c1f2: Fix: Revert accidental overwrite (Xotic750) @
23:07:32  <Brot6> OpenGFX+ Trains - Revision 556:1824a5395ac9: Add: Blender models for monorail passenger, armoured an... (Xotic750) @
23:35:35  <Brot6> OpenGFX+ Trains - Revision 557:681bb66b73f3: Add: Render run of all monorail goods, livestock and re... (Xotic750) @
23:36:45  <Brot6> OpenGFX+ Trains - Revision 558:985a7bf4d1cd: Add: Post-processed run of monorail goods, livestock an... (Xotic750) @
23:45:32  *** orudge` has joined #openttdcoop.devzone
23:46:33  *** orudge has quit IRC

Powered by YARRSTE version: svn-trunk