Log for #openttdcoop.devzone on 7th September 2011:
Times are UTC Toggle Colours
05:07:44  <Brot6> OpenGFX+ Road Vehicles - Feature #2991: Use cargo_age_period with refrigerated trucks (Terkhen) @
05:34:01  <Terkhen> planetmaker: who did the chemicals sprite for ogfx-trains?
05:36:24  <Terkhen> hmm... it seems to be unused in the code
05:38:34  <Terkhen> planetmaker: ogfx-trains has railwagon_chemicals.png, but for chemicals it uses rail_refineryproducts_temperate instead, which is a copy of the oil sprites
05:44:34  <Brot6> OpenGFX+ Road Vehicles - Revision 112:dc9f8b5a047e: Feature #1880: Sprite support for Chemicals. (Terkhen) @
06:12:47  <Brot6> OpenGFX+ Road Vehicles - Revision 113:74489f109fb5: Feature #1880: Sprite support for Scrap Metal. (Terkhen) @
07:04:23  <planetmaker> Terkhen: which wagon do you talk of?
07:04:31  <planetmaker> tank or flatbed?
07:04:46  <Terkhen> sorry, tank :)
07:05:10  <planetmaker> iirc they're by molace
07:05:35  <planetmaker> maybe I should add a list of detailed credits :-)
07:06:19  <Terkhen> I have also stolen scrap metal, and now I'm borrowing petrol for the flatbed :P
07:06:48  <Terkhen> I have checked the task / commit log but I couldn't find who did what
07:08:07  <planetmaker> I don't mind at all... on the contrary :-)
07:10:32  <Terkhen> I'll probably finish cargo support for ogfx-rv today
07:11:41  <planetmaker> I'm impressed :-)
07:12:09  <planetmaker> that'll be really great to have all cargos specifically supported
07:12:42  <Terkhen> right now it is just missing a lot of flatbed cargos and oil seeds
07:12:59  <Terkhen> oh, and cement / plastic for the tanker
07:13:04  <planetmaker> hm... :-)
07:13:30  <Terkhen> I'll probably leave the tank truck alone, and I'll do as many flatbed cargos as I can
07:13:35  <Terkhen> after that... generic sprites for all :P
07:14:11  <planetmaker> :-)
07:14:29  <planetmaker> flatbed is the most tricky cargo type
07:14:54  <planetmaker> except green containers, yellow containers, blue containers with a 1px logo,... :-P
07:15:31  <Terkhen> I'll try to see if supplies / vehicles from trains fit in the trucks, otherwise boxes too :P
07:15:38  <planetmaker> though... hm... if the logo is not in CC or 2CC it could even be re-coloured wagons with logo...
07:15:43  *** ODM has joined #openttdcoop.devzone
07:15:57  <planetmaker> there are many more vehicle carrying wagons than used ingame
07:16:08  <planetmaker> some small ones should fit a not-too-small truck, too
07:16:32  <planetmaker> I've like 8 or 16 types
07:16:44  <planetmaker> they're by zephyris
07:17:58  <Terkhen> nice :)
07:18:04  <Terkhen> are they at the ogfx-trains repo?
07:18:07  <planetmaker> yes
07:18:16  <planetmaker> gfx/flatbed/ensp/
07:18:16  <Terkhen> great, I'll check them once I'm done with petrol
07:18:29  <planetmaker> there is one with a vehicle axis only
07:20:11  <planetmaker> it's 8 only. The wagons are different ;-)
07:23:23  <planetmaker> btw, Terkhen: oil seeds:
07:23:23  <planetmaker> l2-2l2l0&bav=on.2,or.r_gc.r_pw.&fp=6ab59871abf1c9c&biw=1223&bih=619
07:23:24  <Webster> Title: raps - Google Search (at
07:23:29  <planetmaker> uh...
07:26:02  <planetmaker> so for temperate I wonder whether pink is good...
07:26:23  <planetmaker> dunno which plant counts as oil seeds in tropic climate
07:26:47  <planetmaker> well... image search of 'oil seeds' :-)
07:27:18  <planetmaker>
07:27:19  <Webster> Title: Tradin Organic Agriculture BV - Organic Oilseeds - Organic products (at
07:28:43  <planetmaker> hm, the posting by MB about the colour indices is interesting
07:30:53  <planetmaker> I wonder, Terkhen... should we consider using a recolour sprite for some bulk stuff?
07:31:01  <planetmaker> Also just for the sake of exercise?
07:32:00  <planetmaker> I also wonder how well a custom recolour map would work with CC and 2CC.
07:32:02  <planetmaker> Probably not
07:43:41  <Terkhen> sorry, I'm back now :)
07:43:59  <Terkhen> regarding oil seeds: I was thinking on black too
07:44:18  <Terkhen> but he should know better than anybody the supposed colour for his cargos :P
07:44:37  <Terkhen> are those recolour sprites described anywhere?
07:44:42  <Terkhen> I don't know anything about them
07:45:47  <planetmaker>
07:46:22  <Terkhen> thanks
07:46:24  <planetmaker> and he gave in the linked posting the colours
07:46:58  <Terkhen> so it just moves colours around?
07:48:07  <Terkhen> then it's the same than what I'm already doing, but it is easier to do it visually :P
07:48:18  <planetmaker> mostly yes, I think
07:48:40  <planetmaker> Not, if you want to do it for a number of generational vehicles with several cargos ;-)
07:48:55  <Terkhen> xcf layers :P
07:49:10  <planetmaker> yes, but you still have to define each colour
07:49:20  <planetmaker> for each generation somewhat
07:49:26  <planetmaker> or vehicle type
07:49:29  <planetmaker> but yes :-)
07:50:19  <planetmaker> Btw... I yesterday discovered that I need X11 running or the gimp script doesn't work
07:50:40  <planetmaker> Dunno how it works on windows
07:51:49  <Terkhen> hmm
07:51:50  <Terkhen> strange
07:52:02  <Terkhen> right now I'm adding the flatbeds to the script
07:52:13  <Terkhen> maybe I should add the generated png files to the repository?
07:52:20  <planetmaker> might be the way gimp works on osx
07:52:32  <planetmaker> I don't think the newgrfs need that
07:52:44  <planetmaker> I'll keep it for opengfx itself, though
07:53:18  <Terkhen> but keeping the png would make compilation faster; they would only be updated when the xcf file is modified
07:53:21  <planetmaker> newgrfs are not built by distributions. Thus doing it the easy way is good
07:53:44  <planetmaker> Terkhen: what about differing clean and maintainer clean?
07:53:52  <planetmaker> would be better than storing all png IMHO
07:54:02  <Terkhen> what would that do?
07:54:09  <Terkhen> clean keeps png files?
07:54:13  <planetmaker> and currently pngs are not re-created either
07:54:25  <planetmaker> unless the xcf / psd changed
07:54:39  <planetmaker> thus I don't see the speed argument really
07:55:19  <planetmaker> but one could have a normal clean not clean the pngs
07:55:24  <Terkhen> I think they have been recompiled after changes to pnml files only, I'll keep an eye just in case it happens again
07:55:40  <Terkhen> I have not been paying much attention, so I might have used make clean
07:56:45  <planetmaker> hm. strange
07:56:56  <planetmaker> now it seems to work without x11 running
07:57:21  <Terkhen> :P
07:59:18  <planetmaker> and wrt unneeded re-generation... I cannot follow that.
07:59:33  <planetmaker> the xcf is easily changed, though. Even if nothing visually changes
07:59:44  <planetmaker> gimp marks a file changed also when you changed selection
08:00:40  <planetmaker> And I think we had this conversation identical a few weeks / months back ;-)
08:02:50  <planetmaker> btw... add *.scm and *.scr to the .hgignore?
08:03:09  <planetmaker> I might change the script extension... I think it currently doesn't use gimp default
08:03:20  <planetmaker> one is the 'correct' one
08:04:02  <planetmaker> or should I just commit the .hgignore change?
08:10:29  <Terkhen> I don't mind, either is fine :)
08:10:29  *** EmperorJake has joined #openttdcoop.devzone
08:10:48  <Terkhen> hi EmperorJake
08:11:00  <EmperorJake> hello
08:13:14  <planetmaker> good, then I pushed the .hgignore change
08:13:19  <planetmaker> I had it done anyway
08:13:22  <Brot6> OpenGFX+ Road Vehicles - Revision 114:1f30d65a3c96: Change: ignore gimp script files (planetmaker) @
08:14:14  <EmperorJake> planetmaker: have you looked at my problem yet?
08:15:08  <planetmaker> hi EmperorJake
08:15:17  <planetmaker> yes, I did. But I didn't yet find the cause
08:20:58  <Terkhen> what problem?
08:26:37  <planetmaker> the makefile framwork somewhat not working for his vactrains setup
08:27:18  <Terkhen> hmm... because of the placement of files?
08:28:22  <planetmaker> maybe. I really don't know yet
08:28:43  <planetmaker> it was nothing which sprang to my eye and I only could devote like half an hour to it yesterday
08:48:30  <planetmaker> EmperorJake, it is a directory issue...
08:48:46  <planetmaker> It works, if everything uses the default directories which I always use...
08:49:26  <planetmaker> it's intended to work differently, too, but I don't have the time today to track down where anything needs changing to that end
08:50:16  <EmperorJake> okay thanks
08:50:36  <planetmaker> i.e. what I changed: move all graphics files to src/gfx
08:51:47  <planetmaker> hm... there's still an issue then...
08:52:10  <EmperorJake> yes I've just done that
08:53:15  <Terkhen> planetmaker: <--- fails with this error:
08:53:25  <Terkhen> it seems correct to me...
08:54:12  <planetmaker> space in filename?
08:54:59  <planetmaker> from that I don't know what goes wrong, Terkhen
08:55:06  <planetmaker> this morning ogfx+rv built for me
08:55:22  <Terkhen> yes, that's a patch that enables gimp generation for flatbeds too
08:55:29  <Terkhen> the xcf files where there, but I never enabled them
08:55:32  <Terkhen> but it fails :P
08:55:48  <planetmaker> oh, I only saw the 2nd link ;-)
08:56:40  <Terkhen> it seems that I messed up with batteries in the pnml
08:57:08  <Terkhen> I was only looking at the png_source_list file :P
08:58:28  <planetmaker> EmperorJake, in you Makefile.config: Put the grfID into quotes
08:58:41  <planetmaker> that solves the last error
09:00:16  <planetmaker> Terkhen, thus... problem solved?
09:00:22  *** hanf has joined #openttdcoop.devzone
09:00:24  <Terkhen> yes, thanks :)
09:00:32  <planetmaker> ok :-) I'm relieved
09:00:52  <planetmaker> btw... did you try to use named layers instead of numbers?
09:00:58  <Terkhen> no
09:01:01  <planetmaker> I'm not sure it works with that version. But if, it is much nicer
09:01:06  <planetmaker> and you don't need to keep layer order
09:01:11  <planetmaker> just name them without spaces in the name
09:01:26  <planetmaker> before you change all, try with one :-)
09:01:27  <Terkhen> I have 2.6.10
09:01:36  <planetmaker> I don't mean gimp. I mean makefile ;-)
09:01:45  <Terkhen> oh, ok
09:01:52  <Terkhen> I'll try it after this commit
09:01:59  <Terkhen> if it does not work, I'll update the makefile
09:02:06  <planetmaker> I've done that already. But I don't quite recall whether I propagated that to repos
09:02:30  <planetmaker> test also with the newgrf makefile's repo
09:02:36  <planetmaker> I'm not sure... I just wondered
09:02:57  <planetmaker>  and currently the newgrf makefile repo broke in my attempt to make it cleaner. The packages have somewhat wrong dir order :S
09:03:10  <planetmaker> and I only noticed of course due to the CF...
09:03:50  <Brot6> OpenGFX+ Road Vehicles - Revision 115:5529ab79c46f: Codechange: Generate flatbed truck sprites fr... (Terkhen) @
09:03:58  <EmperorJake> planetmaker: I tried that, it did solve the last error, but it still isn't working
09:04:12  <Terkhen> what error are you getting?
09:04:38  <EmperorJake> no errors, but there is no resulting grf file
09:04:58  <Terkhen> :O
09:05:00  <Terkhen> strange
09:05:08  <Terkhen> make clean sometimes helps
09:05:34  <EmperorJake> actually it says: md5sum: vactrain.grf: No such file or directory
09:06:09  <EmperorJake> I tried make clean, still same error
09:06:25  <Brot6> Unrealistic Trainset - Feature #3002: Maglev Strong Series (V453000) @
09:06:49  <planetmaker> <-- works for me
09:10:45  <Terkhen> planetmaker: <--- with this diff, scr files are generated but I get no .gimp.png files for coal
09:10:50  <Terkhen> should I update the makefile framework then?
09:12:48  <planetmaker> Try by replacing the gimpscript with a new one
09:13:12  <EmperorJake> planetmaker: I get 403 forbidden
09:13:25  <planetmaker> I can't promise. If it works: good. If not: I shall look at that while fixing the makefile framework
09:14:03  <Terkhen> I get 403 too
09:14:22  <Terkhen> hmm... where is that new script?
09:14:31  <Terkhen> anyways, using named layers is not a big priority for me
09:14:35  <Terkhen> I don't mind the numbers :P
09:14:47  <planetmaker> try again
09:15:16  <Terkhen> yes, now it works
09:16:01  <planetmaker> I hope it packed everything...
09:18:02  <planetmaker> hm, it might have forgotten vactrain.pnml
09:18:49  <Terkhen> :P
09:19:10  <EmperorJake> IT WORKED!
09:19:21  <EmperorJake> Thank you so much everyone :)
09:19:31  <planetmaker> glad it helped :-)
09:19:46  <Terkhen> :)
09:24:44  <Terkhen> planetmaker: after I copied the new gimpscript, no images at all are generated :P
09:24:48  <Terkhen> I'll leave named layers for now
09:25:46  <planetmaker> ok :-)
09:26:33  <Brot6> Vactrain Set - Revision 0:4fd37aa04455: Initial upload of source (EmperorJake) @
09:27:07  <Terkhen> nice :)
09:27:32  <EmperorJake> hooray!
09:27:53  <planetmaker> sweet
09:34:53  <Brot6> Vactrain Set - Revision 1:1d7c66536f1e: Added devzone build files (EmperorJake) @
09:39:53  <Terkhen> planetmaker: when placed over jungle, FIRS oil wells use desert ground sprites
09:41:46  <Brot6> Dutch Road Furniture - Feature Request #3038 (New): hard shoulder check adjacent tile to decide s... (foobar) @
09:43:09  <Brot6> OpenGFX+ Road Vehicles - Revision 116:acea142bca52: Feature #1880: Sprite support for Petrol (fla... (Terkhen) @
10:16:14  <planetmaker> Terkhen, they also don't yet use proper snow afaik
10:16:22  <Terkhen> ok :)
10:16:32  <planetmaker> they can learn from ogfx+industries ;-)
10:19:18  <Terkhen> <--- the top one is inverted, the other isn't
10:19:43  <Terkhen> it is really a bug?
10:20:57  <planetmaker> what is inverted?
10:21:26  <planetmaker> the cabin's colours?
10:22:10  <planetmaker> I guess the upper one is somewhat better, but I'd not consider either one buggy
10:22:24  <planetmaker> it's a matter of how you envision the cabin to lok like
10:22:26  <planetmaker> *look
10:22:31  <Terkhen> sorry, image horizontally flipped
10:22:52  <Terkhen> the steel things on the back of the truck are not evenly separated in one of them
10:23:40  <planetmaker> hm... they should be equal for driving directions reversed
10:23:48  <Terkhen> then it is a bug
10:23:50  <planetmaker> as we look at the vehicle edge-on
10:24:01  <Terkhen> I'll solve it locally in ogfx-rv and make a bug report in opengfx
10:26:16  <Terkhen> meh, the same happens for steel
10:30:34  <planetmaker> I guess on closer inspection you might find more than this one bug :-)
10:32:53  <Terkhen> I hope not :P
10:33:27  <Terkhen> the next commit of ogfx-rv will have lumber and the wood fix (too messy right now to split it in two commits)
10:33:31  <Terkhen> and after that I'll fix steel
10:33:46  <Terkhen> I guess that the same sprites generated by opengfx+ rv can be backported to opengfx
10:35:11  <Terkhen> I only noticed this because the same lumber sprite didn't fit in both views
10:38:06  <planetmaker> :-)
10:38:29  <Terkhen> yet another similar bug with other views
10:39:06  <planetmaker> well... with other views it might be less relevant
10:57:35  <Terkhen> <--- sometimes this happens for me, that's why I got accustomed to hg purge instead
11:01:02  <planetmaker> I've never seen that
11:04:26  <Brot6> OpenGFX+ Road Vehicles - Revision 117:1a4e76b0c904: Feature #1880: Sprite support for Lumber (fla... (Terkhen) @
11:06:23  <Ammler> planetmaker (or whoever), maybe nml (pil) is able to read layer images too?
11:06:56  <Yexo> yes, PIL is able to do that
11:08:52  <Ammler> so instead this "workaround" with gimp, it could be possible to combine those images with nml directly
11:10:08  <Terkhen> it only works with psd files
11:10:52  <Terkhen>
11:10:53  <Webster> Title: Python Imaging Library Handbook (at
11:11:04  <Brot6> Vactrain Set - Code Review #3039 (Assigned): Cleanup of code (EmperorJake) @
11:11:59  <Ammler> Terkhen: no big deal to save gimp files as psd, is it?
11:13:24  <Ammler> the question is rather, is pil able to select layers
11:13:27  <Terkhen> I don't see the reason to use xcf when we have psd :)
11:13:35  <Terkhen> to use psd when we have xcf*
11:14:16  <Brot6> Vactrain Set - Feature #3040 (New): Generation 2 of vactrains (EmperorJake) @
11:14:46  <Ammler> Terkhen: gimp as build dependency is enormous, would be nice if you could do the same without, wouldn't?
11:15:27  <Terkhen> as soon as someone bothers with coding that application, yes
11:15:45  <Terkhen> I don't think that feature should be included in nml
11:15:57  <Ammler> it's not about someone coding it, it is about if it already exists
11:16:22  <Yexo> Ammler: PIL can read layers, but it'll need special syntax for nml
11:16:25  <Terkhen> we searched a lot before deciding on using gimp, we didn't find any alternative
11:16:39  <Terkhen> if such alternative exists, we can consider it
11:16:42  <Yexo> if you want to get rid of gimp you can write a small python program that uses PIL to do the same
11:16:43  <Ammler> Terkhen: did you think about PIL
11:16:47  <Brot6> Vactrain Set - Feature #3041 (New): Redraw Rail Graphics (EmperorJake) @
11:16:50  <Terkhen> PIL is a library, not a program :P
11:16:52  <Yexo> however as Terkhen said currently PIL only supports PSD files, not gimp files
11:17:03  <Ammler> Terkhen: so you didn't
11:17:17  <Yexo> Ammler: we did
11:17:26  <Terkhen> PIL is a library, hardly updated and only reads PSD -> let's use gimp instead
11:17:26  <Ammler> hmm
11:17:33  <Yexo> gimp is ready, we'd need to spend time writing a program in python and even than it doesn't read gimp files
11:17:51  <Terkhen> and we already had this discussion months ago :)
11:18:01  <Ammler> Yexo: the idea would be to use the psd file directly with nml
11:18:24  <Ammler> to get ride of the additional image source list
11:18:24  <Yexo> Ammler: but for that nml would need special syntax to select which layers are to be included
11:18:31  <Yexo> and even than it'd need support code in nml
11:18:42  <Ammler> and in pil, does pil support it?
11:18:44  <Yexo> it has been discussed and dismissed months ago
11:18:55  <Yexo> Ammler: PIL is a library, it does support it but it needs code calling that support
11:19:09  <Yexo> like nml has to say: read layer 1, read layer 2, merge both layers, etc.
11:19:11  <Ammler> oh well, never mind... :-P
11:20:50  <Terkhen> EmperorJake: once I'm done with opengfx+ road vehicles I can add those cost parameters to the repository if you want
11:20:51  <Ammler> Yexo: you think, it is more complicated as the current solution?
11:21:09  <Yexo> Ammler: from the current situation: yes.
11:21:14  <Yexo> current solution is already implemented
11:21:20  <Yexo> hence every change is more complicated
11:21:23  <Ammler> the gimp script isn't that short
11:21:30  <Yexo> but it's already written
11:21:53  <Ammler> ok, that is no reason to decline the idea already, but well...
11:22:08  <EmperorJake> Terkhen: I've already applied them
11:22:12  <Terkhen> oh, nice :)
11:22:15  <Yexo> I'm not declining the idea
11:22:40  <Yexo> the only thing I'm declining is to spend a lot of time on it when we already have something that works. NML has more than enough open issues already that need work and are more important
11:23:55  *** EmperorJake has quit IRC
11:25:42  <Brot6> OpenGFX+ Road Vehicles - Revision 118:d0d022b8e3a6: Fix: Flatbed trucks of the "steel" model were... (Terkhen) @
11:31:19  <planetmaker> Ammler, it's a big deal. Gimp can't write psd
11:31:33  <planetmaker> or I missed that so far
11:31:55  <planetmaker> but would be good
11:32:24  <Ammler> yes, you missed that
11:32:37  <Ammler> ps can't write xcf
11:33:08  <Ammler> that is why we once decided to save files as psd on opengfx, but the decision got lost :-)
11:33:46  <planetmaker> Ammler,  the gimp script is not long... it's about two, three dozen lines of code
11:33:53  <planetmaker> indeed, I can't recall that decision :-)
11:34:15  <Ammler> I guess, during the absense of foobar, it wasn't important anymore
11:34:54  <Ammler> and in the meantime, psd might be able to read xcf
11:34:59  <Ammler> ps*
11:35:07  <Brot6> Unrealistic Trainset - Feature #3025: Monorail ICE Series (V453000) @
11:39:11  <Brot6> OpenGFX+ Road Vehicles - Revision 119:c357a4392334: Fix #1676: Colour difference in paper truck s... (Terkhen) @
11:42:16  <Brot6> OpenGFX - Bug #3042 (New): Difference between symmetric views of flatbed trucks (Terkhen) @
11:58:19  <Brot6> OpenGFX+ Road Vehicles - Revision 120:30842f3759c7: Feature #1880: Sprite support for Chemicals (... (Terkhen) @
12:19:51  <Terkhen> planetmaker: <--- does this look good for PBI plastic? (I just changed chemicals to red)
12:19:52  <Terkhen> bbl
12:20:40  <planetmaker> looks nice. But I (currently) have no idea about how PBI cargos look like or should look like
12:34:09  *** FooBar has joined #openttdcoop.devzone
12:42:37  *** Lakie has joined #openttdcoop.devzone
13:00:27  <Brot6> Dutch Road Furniture - Feature Request #3038: hard shoulder check adjacent tile to decide slope o... (foobar) @
13:01:38  <Brot6> Dutch Road Furniture - Revision 25:1a050b9c6a48: Fix (r20): outside corners couldn't connect dire... (foobar) @
13:01:38  <Brot6> Dutch Road Furniture - Revision 26:4a2abafd5cfa: Codechange: higher bounding boxes may or may not... (foobar) @
13:01:38  <Brot6> Dutch Road Furniture - Revision 27:817641ff85c8: Fix: improve appearance of east/west inside corners (foobar) @
13:01:40  <Brot6> Dutch Road Furniture - Revision 28:abd144875142: Doc: prepare for release (foobar) @
13:01:44  <Brot6> Dutch Road Furniture - Revision 29:df6b891d05b6: Release: 0.2.1 (foobar) @
13:04:44  <Brot6> dutchroadfurniture: update from 0.2.0 to 0.2.1 done -
13:29:43  <Terkhen> well, plastic is a liquid / piece goods so small containers seem like a good solution :P
13:29:52  <Terkhen> I'll commit those then
13:30:32  <planetmaker> hm, looked like barrels
13:37:07  <Terkhen> yes, sorry, that's what I mean :)
13:39:02  <Terkhen> wow, that's a lot of ENSP sprites :)
13:39:41  <Terkhen> do they use the train's company colour or a random one?
13:39:58  <Terkhen> or maybe they all are yellow :P
13:41:27  <planetmaker> they're all yellow ;-)
13:41:43  <planetmaker> hm.. there's somewhere green FMSP, but I didn't quite find it this morning
13:41:56  <Terkhen> random recolour would be nice, but very low priority :P
13:42:29  <Terkhen> I think that most of those vehicles can fit in the flatbed truck, but maybe they would look "out of scale" in a truck
14:00:44  <Brot6> Belarusian Town Names - Bug #3000 (Closed): DevZone compile failed (Ammler) @
14:03:29  <Ammler> hmm, #2892 is assigned to me, but I can't do anything with, planetmaker any idea?
14:03:29  <Brot6> Ammler: hmm: #2892 is "sub-landscape - Bug #2892: DevZone compile failed - #openttdcoop Development Zone"
14:04:09  <planetmaker> boah... this Simons Smith is an arrogant piece of something
14:07:33  <Brot6> Central European Train Set - Bug #3043 (New): freight wagons (Eddi) @
14:10:17  <planetmaker> un-assign it, Ammler
14:10:58  <Terkhen> planetmaker: ignore him
14:11:25  <Ammler> planetmaker: I can't, that is the strange thing, but I have no clue why
14:11:42  <Terkhen> think of it as a healthy habit, good for your state of mind :P
14:11:49  <Brot6> Central European Train Set - Bug #3043: freight wagons (Eddi) @
14:13:41  <Ammler> maybe because non-members can't edit issues
14:15:22  <Ammler> yes, added the permission
14:15:47  <Ammler> hmm, not good :-(
14:16:04  <Ammler> now, I can also edit unrelated tickets...
14:16:19  <Ammler> I guess, it is a redmine bug...
14:17:47  <Yexo> not really, you've just been cheating by committing to a project you're not a member of
14:19:09  <Ammler> Yexo: yes, that might be the issue
14:19:37  <Ammler> via webui, you couldn't assign non-members
15:30:42  *** LordAro has joined #openttdcoop.devzone
15:32:02  <LordAro> planetmaker: any chance you could fix 'newgrf_makefile'? i'm thinking of using it for 32bpp-extra
15:33:40  <Yexo> LordAro: in what way is it broken?
15:33:41  <planetmaker> yes, there's a chance.
15:33:50  <planetmaker> I broke it while re-structuring it, Yexo
15:34:03  <Yexo> oh, was that the problem with vactrains yesterday?
15:34:08  <planetmaker> though the last release should work
15:34:11  <planetmaker> no, that's different
15:34:20  <planetmaker> it was *some* path issue
15:34:30  <planetmaker> seems I somewhere implicitly assume graphics to be in src/gfx
15:34:35  <planetmaker> dunno where, though
15:34:45  <LordAro> planetmaker: i want the 're-structuring' :)
15:34:59  <planetmaker> LordAro: for a project it doesn't matter really
15:35:12  <planetmaker> you can just use the latest "stable" release
15:35:19  <planetmaker> and update later. It won't change much
15:35:25  <planetmaker> it's mostly for how I can maintain it
15:35:34  <LordAro> meh, i like being OCD :3
15:35:36  <planetmaker> and it can be updated anytime
15:41:15  *** Lakie has quit IRC
15:43:41  <hanf> planetmaker: where are the coords for the templates for the engines in opengfx+ trains? can't seem to find them
15:44:38  <Terkhen> probably in a file called sprite_templates.pnml
15:45:04  <Terkhen> since all sprites of the same type use the same template, they also use the same coords in nml
15:45:13  <hanf> ah yeah I see it.
15:45:25  <hanf> thanks
15:45:31  <Terkhen> planetmaker:
15:45:32  <Webster> Title: man - xcf2png (1) - convert from GIMP xcf files to png format (at
15:45:49  <Terkhen> it seems to deal with layers too, I could swear this did not appear in my previous google searches
15:46:05  <Terkhen> <--- although the homepage is vaguely familiar to me
15:46:06  <Webster> Title: Henning Makholm's software (at
15:47:48  <Terkhen> I'll experiment with it once all sprites are done
15:48:58  <planetmaker> ok
15:49:08  <planetmaker> problem is: how portable is it?
15:49:33  <planetmaker> but it looks like it should be easy to compile
15:50:34  <Terkhen> ah
15:50:38  <Terkhen> I start to remember
15:50:41  <Terkhen> it failed on mingw :)
15:50:48  * Terkhen gives it another try
15:57:41  <Terkhen> yeah, compilation fails almost immediately on mingw
16:00:02  <planetmaker> fails with libiconv symbols here
16:01:04  <Terkhen> on debian it compiled after installing gettext
16:01:26  <Terkhen> mingw issue seems to be caused by something on the configure
16:01:31  <Terkhen> there is a enums.h file that is empty
16:01:41  <Terkhen> but on debian it isn't
16:01:49  <Terkhen> so it's probably not being generated correctly
16:03:38  <Terkhen> /bin/perl gimp/base-enums.h gimp/gimpbaseenums.h gimp/xcf-private.h > enums.h <--- indeed
16:07:13  <Terkhen> so there is probably something wrong with msys' perl
16:11:56  <Terkhen> strange, after a second try it was generated correctly...
16:12:18  <Terkhen> but now it fails on sys/wait.h, which is one of the unix files that mingw/msys does not use/port
16:12:42  *** Lakie has joined #openttdcoop.devzone
16:24:32  <Terkhen> planetmaker: <--- with random switches like those (identical to the ones used in ogfx-trains), the sprite sometimes changes if a fully loaded vehicle stops in a station and tries to load cargo
16:24:58  <planetmaker> not good :-)
16:25:00  <Terkhen> given the description of the trigger, this behavior is quite confusing :)
16:25:29  <Terkhen> The consist has unloaded all cargo (use with type 'SELF') <--- which is not true in this case, but still some randomization happens
16:25:34  <Terkhen> maybe something else that is not the trigger causes it?
16:28:15  <Hirundo> can random triggers be monitored via the newgrf debug gui?
16:28:23  * Terkhen checks
16:29:21  <Hirundo> if not, patch it :)
16:32:32  <Terkhen> <--- it only shows callbacks
16:32:42  <Terkhen> that 32day callback looks fishy
16:33:06  <Terkhen> I'm not using TRIGGER_VEHICLE_32_CALLBACK
16:36:59  <Hirundo> what's fishy about it?
16:38:21  <Terkhen> why is it enabled if I'm not using it?
16:38:46  <Hirundo> it's not masked, so always enabled
16:39:08  <Terkhen> hm, ok
16:39:21  <Hirundo> it might not be enabled in NML, but OpenTTD can't tell that
16:39:53  <Terkhen> I can try to add random triggers to the debug GUI, but a patch of that size will take a while
16:59:13  *** frosch123 has joined #openttdcoop.devzone
17:00:33  *** Zuu has joined #openttdcoop.devzone
17:04:25  <Terkhen> the random animation trigger code is pure magic :O
17:07:41  <V453000> hi guys, I have a normal blue sprite and it says at [x: 65, y: 0]: 22 of 440 pixels (5%) are pure white" which is exactly the first line of the sprite, but all of the pixels there are blue ... any ideas what the issue might be?
17:11:54  <Brot6> Unrealistic Trainset - Feature #3025: Monorail ICE Series (V453000) @
17:12:03  <V453000> ok the issue was that there was a white line in the bottom of the sprite :)
17:20:34  <Brot6> Vactrain Set - Bug #3044 (New): DevZone compile failed (compiler) @
17:21:40  <Brot6> dutchroadfurniture: update from r12 to r29 done -
17:24:27  <Brot6> ogfx-rv: update from r111 to r120 done -
17:24:57  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r252), narvs (r52), bros (r52), ogfx-industries (r123), firs (r2582), opengfx (r733), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r145), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r640), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1663), water-features (r51), 32bpp-extra (r40),
17:24:57  <Brot6> manindu (r7), newgrf_makefile (ERROR r313), ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), fish (r684), ogfx-landscape (r85), ttrs (r36), ogfx-trees (r51), swedishrails (r206), grfcodec (r833), ai-aroai (r49), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8),
17:24:59  <Brot6> indonesiantowns (r41), ailib-string (r29), airportsplus (r145), comic-houses (r71)
17:26:21  <Brot6> newgrf_makefile: compile of r313 still failed (#3037) -
17:27:07  <Brot6> vactrainset: compile of r1 still failed (#3044) -
17:41:42  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @
17:51:16  <Terkhen> hmm
17:51:29  <Terkhen> I was approaching random triggers in a wrong way
17:52:08  <Terkhen> they are not enabled/disabled like callbacks, they are activated when certain situations happen
17:52:11  <Terkhen> so it is not something static
17:52:24  <Terkhen> I don't know a nice way to show when they happen in the gui :)
17:56:58  <frosch123> hmm, should ottd print a warning if someone uses a vehicle random trigger and not usnig SELF scope?
17:58:26  <frosch123> hmm, could nml warn about that?
18:02:35  <planetmaker> are those bad?
18:02:48  <frosch123> they make no sense :p
18:02:51  *** andythenorth has joined #openttdcoop.devzone
18:09:33  * Terkhen fails to understand random triggers
18:09:49  <Terkhen> so no nice debug thingie for them
18:14:24  <Brot6> Unrealistic Trainset - Feature #3025: Monorail ICE Series (V453000) @
18:30:49  <andythenorth> ho
18:30:57  <andythenorth> FIRS has gained tickets :P
18:31:02  <andythenorth> that's not correct behaviour
18:41:58  *** JVassie has joined #openttdcoop.devzone
18:59:39  <andythenorth> anything to code?
18:59:50  <andythenorth> or shall I do blogging for my day job?
19:02:07  * planetmaker is coding... but not openttd-related
19:03:44  <Brot6> clientpatches: compile of r22903 still failed (#2964) -
19:09:02  <andythenorth> Terkhen: is today a good day to revisit FIRS templates?
19:09:53  <Brot6> openttd-vehiclevars: update from r22901 to r22903 done -
19:13:02  <Brot6> serverpatches: compile of r22903 still failed (#2966) -
19:13:56  *** Lakie has quit IRC
19:14:55  <Brot6> 32bpp-ez-patches: compile of r22903 still failed (#2446) -
19:25:10  <Terkhen> andythenorth:
19:25:23  <Terkhen> it is the only industry using them right now
19:25:36  <Terkhen> IMO we should only convert them when we need to change something
19:26:00  <Terkhen> the new format is more flexible and clear at the cost of taking up more space :)
19:28:20  <planetmaker> it's imho better readable :-)
19:30:24  <Terkhen> yup
19:35:42  <andythenorth> oh cool
19:35:49  <andythenorth> so grain mill could be converted?
19:36:13  <Brot6> Unrealistic Trainset - Feature #3025: Monorail ICE Series (V453000) @
19:37:26  * andythenorth attempts conversion
19:38:08  <planetmaker> if you're happy: convert all industries.
19:38:17  <planetmaker> with new ground tiles that makes even sense
19:39:01  * andythenorth ponders
19:39:55  <Terkhen> I checked grain mill but it wasn't clear what was needed
19:41:01  <Terkhen> I don't know where to place each thing :P
19:41:05  <andythenorth> he
19:41:19  <andythenorth> I organised the sprite layout so they're in a nice sequence
19:41:28  <andythenorth> but I should learn how to do this
19:41:46  <andythenorth> so far I broke my build :P
19:42:47  <Terkhen> did you keep a backup? :P
19:42:58  <andythenorth> might be able to type 'revert' :P
19:43:05  <andythenorth> hmm
19:43:16  <andythenorth> I was always a lazy coder, but recently I got lazier
19:43:23  <planetmaker> andythenorth: I usually keep a diff before I revert :-)
19:43:29  <planetmaker> then I can paste back single parts
19:43:33  <Terkhen> yup
19:45:52  <andythenorth>
19:46:25  <V453000> andythenorth: one can always get more lazy :p
19:47:23  <planetmaker> andythenorth: spritelayout5 should also get the templates
19:47:39  <planetmaker> instead of one of the middle one you can keep the animated building thingy
19:47:40  <planetmaker> as is
19:47:54  <Terkhen> spriteset_ground_overlay_normal / spriteset_ground_overlay_snow <--- in the builders yard, every tile used the same overlay
19:48:04  <Terkhen> but those are not defined in the grain mill
19:48:17  <Terkhen> from the layout of the sprite file, I suspect that every building tile has an associated ground layout, right?
19:48:59  <planetmaker> switch(FEAT_INDUSTRYTILES, PARENT, THIS_ID(layout), layout_num) { <-- the default case looks wrong
19:49:27  *** LordAro has quit IRC
19:50:00  <andythenorth> Terkhen: yes
19:50:19  <andythenorth> top row: ground layout.  Next row: associated building sprite
19:50:27  <andythenorth> I need to convert every spritesheet to that format
19:50:35  <Terkhen> I'd go with something like spriteset_ground_overlay_normal_1, spriteset_building_1
19:50:41  <Terkhen> and it seems like a nice format :)
19:52:34  <andythenorth> spriteset_ground_overlay_snow_1 ?
19:52:54  <Terkhen> or spriteset_ground_overlay_proper_name_for_the_sprite
19:52:56  <Terkhen> :P
19:53:05  * Terkhen is fond of long names
19:53:47  <andythenorth> why are two sprites defined identically in each spriteset
19:53:51  <andythenorth> ?
19:54:13  *** LordAro has joined #openttdcoop.devzone
19:54:14  *** Lord_Aro has joined #openttdcoop.devzone
19:54:18  <Terkhen> because of a limitation of spritelayouts
19:54:33  <Terkhen> the old template, for buildings, used a sprite for "normal" and another for "snow"
19:54:43  <andythenorth> made sense
19:54:45  <Terkhen> so you can access spriteset(0) -> normal and spriteset(1) -> snow
19:54:50  <andythenorth> so we need to keep that?
19:54:56  <Terkhen> but all spritesets in a single spritelayout need to have the same size
19:54:56  <planetmaker> 21:53 Terkhen is fond of long names <--- /me, too
19:55:06  <Terkhen> therefore, stuff like ground sprites must be duplicated
19:55:10  * andythenorth likes long names too :P
19:55:20  <Terkhen> because we are forced to have that size
19:55:24  <andythenorth> grr
19:55:26  <andythenorth> cruft :P
19:55:36  <andythenorth> makes the code harder to understand conceptually :)
19:55:40  <Terkhen> indeed :(
19:55:58  *** Lord_Aro has quit IRC
19:56:05  <Terkhen> I think that you can keep everything to 1 with the current templates
19:56:27  <Terkhen> but you will need to split the buildings in two, and hide each one accordingly
19:56:46  <planetmaker> Zuu: you should update your OpenGFX ;-)
19:56:48  <Terkhen> the old template did: sprite: building_spriteset(terrain_type == SNOW) or something like that
19:56:54  <andythenorth> hmm
19:56:56  <andythenorth> also
19:57:05  <andythenorth> we don't just define the filename once for the spritesets?
19:57:11  <andythenorth> and repeat them?
19:57:24  <Zuu> planetmaker: :-)
19:57:43  <planetmaker> you still got the old shores which are much worse than now ;-)
19:57:54  * andythenorth considers reintroducing the separate sprite action 1 templates, as per nfo FIRS
19:58:09  <andythenorth> as there is 2x repetition here, 3x if we provide tropic sprites
19:58:30  <planetmaker> not sure it's worth it
19:58:35  <Zuu> planetmaker: Well, I would need to start a stable OpenTTD to do that, so I guess that is why.
19:58:48  <planetmaker> hm
19:59:00  <Terkhen> andythenorth: but it is different, now you should be able to have a single spritelayout for each tile
19:59:10  <Zuu> As a trunk would crash in the main online content.
19:59:34  <andythenorth> Terkhen: I am thinking only the action 1 part would be templated
19:59:40  <planetmaker> yeah, you're right, Zuu
19:59:42  <planetmaker> :-(
19:59:44  <Terkhen> what's an action 1? :P
19:59:48  <Terkhen> definition of spritesets?
20:00:00  <planetmaker> spritesets, yes
20:00:11  <planetmaker> I don't see much gain to template that (more)
20:00:21  <andythenorth> boring repetition :P
20:00:31  <andythenorth> it's only twice though
20:00:40  <andythenorth> the rule is do it twice, *then* automate
20:00:58  <andythenorth> if we had tropic sprites also, I'd template
20:01:26  <Zuu> planetmaker: Hmm, stable don't let me upgrade OpenGFX. I guess it is because a version requirement in bananas?
20:01:36  <andythenorth>
20:01:42  <andythenorth> nmlc: "sprites/nml/industries/grain_mill.pnml", line 110: Unrecognized identifier 'grain_millspriteset_ground_overlay_normal' encountered
20:01:42  <andythenorth> make: *** [firs.grf] Error 1
20:01:42  <planetmaker> no...
20:01:55  <planetmaker> opengfx has no version limits
20:02:43  <Terkhen> spriteset_snow_3 <-- spriteset_building_snow_3 would be more clear IMO
20:03:08  <Terkhen> andythenorth: at the spritelayout definition, the overlays are missing the number
20:03:24  * andythenorth appends them
20:04:02  *** JVassie has quit IRC
20:04:08  <Ammler> Zuu: there is a bug in openttd afaik, it has issues to detect the right opengfx version
20:04:27  <andythenorth> nmlc: "sprites/nml/industries/grain_mill.pnml", line 112: 'grain_millspriteset_1' is not defined as a function.
20:04:48  <Ammler> or rather, if there exists multiple opengfx versions, it doesn not necessary use the newest
20:05:04  <Zuu> Okay
20:05:20  <Zuu> so I should hunt down all old versions :-)
20:05:29  <Ammler> well, the non-bananas at least
20:05:40  <Ammler> those without version
20:05:58  <Terkhen> andythenorth: spriteset_1 is now called spriteset_normal_1 or spriteset_snow_1
20:06:10  <planetmaker> Ammler: it should use newest as base sets are versioned
20:06:15  <andythenorth> where did I miss that
20:06:20  <andythenorth> oh
20:06:30  <Ammler> planetmaker: it should
20:06:46  <Ammler> hmm, I once discussed that issue with rubi
20:07:18  <Ammler> planetmaker: I guess, the versioning does not work (yet) with base sets
20:07:29  <Terkhen> andythenorth: <--- that template expects a spriteset with two sprites
20:07:55  <Terkhen> if you plan to split, you need to use two normal building entrances and prepare hide_sprite accordingly
20:08:05  <Rubidium> Ammler: what versioning are you talking about precisely?
20:08:08  <Ammler> the workaround I do for the suse packages is simply add version ot the path
20:08:22  <Ammler> Rubidium: different versions with same path
20:08:28  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @
20:08:53  <andythenorth> hmm
20:09:15  <Ammler> Rubidium: this happens if you have opengfx also from upstream
20:09:20  <Ammler> from distro*
20:09:45  <Ammler> or in ~/.openttd/data
20:09:53  <Rubidium> the bananas one will generally have a unique name, so I don't really see when it's troublesome
20:10:03  <Ammler> yep
20:10:05  <Rubidium> except when you manually change the name of files
20:10:24  <Ammler> that is afaik the reason, we don't "fix" it
20:10:27  <andythenorth> that now builds
20:10:31  <andythenorth> 10 billion white pixels :P
20:10:44  <Rubidium> in which case I can think of many other ways to make distro opengfx fail
20:10:57  <Rubidium> or at least make the version detection go haywire
20:11:24  <Ammler> well, it happened to me, dunno, if zuu has similar issue
20:11:46  <Ammler> (as said, I worked around by adding version to the path on the suse rpm)
20:14:19  <Ammler> Zuu: would be nice, if you can confirm
20:15:14  <andythenorth> so
20:15:38  <Zuu> I haven't been able to work around it yet. I've removed all versions but 3.5 in Documents\OpenTTD\content_download\data. I have checked my \Documents\OpenTTD\data for OpenGFX files but didn't find any.
20:15:50  <andythenorth> I have defined both normal and snow spritesets, but only the snow ones are used
20:15:53  <Zuu> I haven't looked in all installation specific data locations yet.
20:15:59  <andythenorth> which is possibly why there are no snow sprites?
20:16:34  <Terkhen> hmm? you are only using snow sprites but they don't appear?
20:16:45  <Ammler> Zuu: you have distro intallations?
20:16:53  <Ammler> /usr/share/openttd...
20:17:02  <Zuu> Nope, I run Windows 7.
20:17:02  <Ammler> or /usr/share/games/openttd...
20:17:23  <Ammler> were does the installer put the base sets?
20:17:23  <Zuu> All installations reside in \Documents\Installations\<install dir>\.
20:17:50  <Yexo> the installer places it in program files (if you install there)
20:17:57  <Zuu> I don't use the installer and I don't think I ever have used it on my own machine.
20:18:17  <andythenorth> hmm
20:18:19  <andythenorth> no ground sprites
20:18:24  <andythenorth> bit weird
20:18:32  <andythenorth> so I'm doing that wrong clearly
20:18:45  <Ammler> Zuu: but you are able to download opengfx 0.3.5 via bananas?
20:18:47  <andythenorth>
20:18:50  <Ammler> it just doesn't apear?
20:19:54  <Zuu> Oh, now it has resolved itself. I had issues that OpenGFX+ Airports didn't update in my NewGRF selection, but when I removed it and added it again to my list, it appeared in my game instead of old 2.1 (or 2.2?). At the same time, the correct OpenGFX was now loaded.
20:20:43  * Terkhen tests
20:21:03  <Ammler> silly :-)
20:21:08  <Terkhen> you have a lot of trailing whitespace
20:22:00  <Zuu> I found some on blank lines, but though they were from the patch format because they were that many and only fixed the whitespace on non-empty lines.
20:22:07  <Terkhen> :O
20:22:10  <Terkhen> that's strange
20:22:36  <Zuu> Well, all I did was: grep "\s$" *
20:22:37  <Terkhen> Zuu: sorry I'm talking to andythenorth :)
20:22:44  <Zuu> Terkhen: Oh..
20:22:59  <Terkhen> andythenorth: the template should be taking care of the ground sprite
20:23:03  <Terkhen> I don't understand why it glitches
20:23:40  <Terkhen> planetmaker: with that code, what could make the ground glitch?
20:23:59  <andythenorth> that trailing whitespace is because I copied from redmine diff :P
20:24:15  <Terkhen> oh :)
20:24:19  <planetmaker> glitch... in what way?
20:25:36  <Terkhen> in tropic the ground looks like jungle, when you scroll the window small lines look like desert
20:25:54  <Terkhen> only the ground, the overlay looks fine
20:26:41  <andythenorth> there is no ground tile drawn
20:27:47  <planetmaker> :-)
20:28:40  <planetmaker> right. the ground tile needs initialization
20:29:05  <Terkhen> ah, true :)
20:29:05  <planetmaker> hm... I wonder if one could not put that in a separate template instead of requiring initialization
20:29:16  <planetmaker> the template would be ugly, though
20:29:24  <Terkhen> how could that work? it would still need to chain the initialization to the graphics
20:29:46  <planetmaker> yes. Or all the ground tile calculation done during sprite assignment.
20:29:51  <planetmaker> An ugly long chain of things
20:30:53  <Terkhen> andythenorth: you should add GROUNDSPRITE_SWITCH(THIS_ID(ground_switch), THIS_ID(layout)) to the callbacks used by the industry tile and change the THIS_ID(layout); at the graphics block for THIS_ID(ground_switch);
20:30:53  <planetmaker> sprite: climate == arctic ? ... : (climate == temperate ? ... : tiletype == tiletype_desert ? 4512 : ...)
20:31:04  <Terkhen> that way it will initialize the sprite instead of using 0
20:31:09  <planetmaker> yep
20:31:30  <planetmaker> I'd like to call a procedure in the layout :-)
20:31:34  <Terkhen> sprite: LOAD_TEMP(var_default_ground) != 0 ? LOAD_TEMP(var_default_ground) : GROUNDSPRITE_NORMAL; \ <--- this demonstrates that you can't rely on temporal registers to provide sane values when they are not initialized :)
20:31:49  <planetmaker> hm... Terkhen... maybe we could template that similar with many hide_sprite sprites
20:33:00  <planetmaker> yes, there's a groundsprite template possible
20:33:00  <Terkhen> hmm... the initialization itself?
20:33:41  <andythenorth> nmlc: "sprites/nml/industries/grain_mill.pnml", line 202: Syntax error, unexpected token "switch"
20:34:00  <andythenorth> I added this: callback_flags:   bitmask(INDTILE_CBF_SLOPE_IS_SUITABLE, GROUNDSPRITE_SWITCH(THIS_ID(ground_switch), THIS_ID(layout)));
20:34:17  <planetmaker> Terkhen: how's the new template  file called?
20:34:31  <Terkhen> spritelayouts_groundaware
20:34:47  <Terkhen> andythenorth: callback_flags is deprecated
20:34:52  <andythenorth> hmm
20:34:58  <Terkhen> oh, the grain mill still has it :P
20:35:09  <Terkhen> I meant along with TILE_DISALLOW_NEARBY_CLASS and TILE_ALLOW_PLAYER
20:35:46  <andythenorth> k
20:36:15  <andythenorth> yay
20:36:18  <andythenorth> better
20:36:19  <planetmaker> Terkhen: we can skip this initialization
20:36:27  <Terkhen> how?
20:36:29  <planetmaker> I'll extend the template to remove that need
20:36:59  <planetmaker> <-- basically that way
20:38:16  <andythenorth> not really sure what the cause of this is :)
20:38:21  *** StepanBarth has joined #openttdcoop.devzone
20:38:27  <andythenorth> (transparency on)
20:38:42  <andythenorth> the lack of snow is *correct* - it's not in the graphics
20:39:01  <andythenorth> ho
20:39:08  <andythenorth> maybe it's bad x,y
20:40:20  <planetmaker> looks like
20:40:57  <andythenorth> and bad offsets
20:42:39  <andythenorth> hmm
20:42:41  <andythenorth> better
20:42:47  <andythenorth> but still wrong
20:43:16  <andythenorth>
20:43:39  *** LordAro has quit IRC
20:45:03  <andythenorth> puzzling
20:45:11  <andythenorth> one of the tiles needs a y offset of 2
20:45:15  <andythenorth> the others do not
20:46:17  <andythenorth> also, I don't need building sprites for 2 of the tiles
20:47:23  *** LordAro has joined #openttdcoop.devzone
20:47:43  <planetmaker> then don't add a building to that spritelayout
20:47:56  <planetmaker> no need to do so
20:48:01  <andythenorth> k
20:48:04  <andythenorth> seems to work
20:48:17  <andythenorth> avoids having to use empty sprites
20:48:38  <planetmaker> Terkhen: what do you say?
20:48:43  <andythenorth> hmm
20:48:49  <andythenorth> this is nearly working :)
20:48:59  <andythenorth> just need a ground tile
20:48:59  <Terkhen> :)
20:49:02  <Terkhen> planetmaker: let's see
20:49:33  <Terkhen> hmmm...
20:49:39  <Terkhen> what does OpenTTD do with hidden sprites?
20:49:54  <planetmaker> dunno?
20:49:57  <planetmaker> not draw them
20:50:04  <Terkhen> because if they need even a small processing this can increase drawing time a lot, that's a lot of sprites
20:50:29  <Brot6> FIRS Industry Replacement Set - Revision 2583:7281c0c323d9: Change: Grain Mill uses ground overla... (andythenorth) @
20:50:36  <Terkhen> on the bright side the code looks a lot clearer than the other template
20:50:43  <Terkhen> with these changes the old template is not required, right?
20:50:52  *** StepanBarth has quit IRC
20:51:12  *** StepanBarth has joined #openttdcoop.devzone
20:51:25  <frosch123> processing advanced spritelayouts takes more time
20:51:40  *** StepanBarth has quit IRC
20:51:41  <frosch123> but once it is an advanced layout, it does not really matter how advanced
20:51:58  *** StepanBarth has joined #openttdcoop.devzone
20:52:13  <andythenorth> so can we reduce the duplication?
20:52:13  <frosch123> resolving the action123 chain takes most time though
20:52:22  <andythenorth> and also, how do I add the ground tile?
20:52:32  <andythenorth> does it just need defining?
20:52:58  <planetmaker> andythenorth: if you want, you can do without ground tile ;-)
20:53:06  <andythenorth> I want a ground tile :P
20:53:11  <planetmaker> the template always has the usual ground
20:53:31  <andythenorth> I need ground :)
20:53:39  <planetmaker> Terkhen: looking at the code andy pasted earlier, IMHO it's a good decision to use adv. spritelayouts for ground sprites
20:53:48  <planetmaker> and not use hide yes/no there
20:53:56  <planetmaker> and for the other climate stuff then, too
20:54:13  <Terkhen> hmm
20:54:18  <planetmaker> it would need like 2/3/4 sprites per layout, depending on the conditions... hm... though
20:54:18  <Terkhen> do you mean regarding the ground sprite awareness?
20:54:20  * andythenorth still considers templating the action 1s....but we'll see
20:54:21  <planetmaker> the condition is nice
20:54:35  <planetmaker> no, the spritesets
20:54:53  * Terkhen is confused :P
20:55:24  *** Lord_Aro has joined #openttdcoop.devzone
20:55:26  <andythenorth> hmm
20:55:37  <andythenorth> the ground tile is defined as far as I can see
20:55:40  <andythenorth> why isn't it used?
20:56:11  <Terkhen> the code you pasted uses hide_sprite
20:56:25  <Brot6> FIRS Industry Replacement Set - Revision 2584:6b3396f7a1d8: Add: Move the ground awareness into t... (planetmaker) @
20:56:41  <andythenorth> oh
20:56:43  <andythenorth> where?
20:57:03  *** StepanBarth has quit IRC
20:57:07  <planetmaker> hm... Then I wonder whether we couldn't use even more hide_sprite. Actually for everything
20:58:02  *** StepaBarth has joined #openttdcoop.devzone
20:58:44  <Terkhen> why not?
20:58:59  <planetmaker> dunno :-) No adv. spritelayout then
20:59:09  <planetmaker> Except maybe in the cases where we really need it: slopes
20:59:13  <planetmaker> which is fine, I guess
20:59:20  <andythenorth> animation
20:59:27  <andythenorth> date sensitive graphics
20:59:43  <planetmaker> like that, yes
20:59:45  *** Lord_Aro has quit IRC
20:59:45  *** ODM has quit IRC
20:59:49  <planetmaker> hm, ok :-)
20:59:52  <frosch123> planetmaker: hide_sprite is an adv. spritelayout
21:00:00  <planetmaker> oh, it is?
21:00:01  <Terkhen> yup
21:00:04  <planetmaker> :-)
21:00:15  <Terkhen> whenever you use any condition, it is an advanced spritelayout
21:00:25  <Terkhen> then again, I don't know when nml decides to use an advanced spritelayout or a normal one
21:00:34  <Terkhen> so maybe it is always using them and we acomplish nothing :P
21:00:51  <planetmaker> anyway, I commited that hide_sprite spree for the ground tile
21:01:05  <planetmaker> thus no initialization needed anymore
21:01:11  <frosch123> Terkhen: ottd optimises away the adv. spritelayout if it uses no registers
21:01:25  <Terkhen> ah, ok :)
21:01:25  <Terkhen> that's nice
21:01:27  <frosch123> so, unless nml computes compiletime constants at runtime :p
21:01:40  <planetmaker> :-) cool
21:01:51  <Yexo> and nml will only write an advanced sprite layout when it's needed
21:02:03  <Terkhen> great :P
21:02:04  <frosch123> e.g. you can use recolour sprites from action1 with no addtional cost
21:02:12  <frosch123> even though they need adv.spr.layouts
21:02:38  *** LordAro has quit IRC
21:02:50  <Terkhen> planetmaker: make two versions of FIRS, one with and another one without
21:02:53  <Terkhen> then we can compare :)
21:03:59  <planetmaker> adv. spritelayouts you mean?
21:04:24  <planetmaker> it might be an interesting thing to do... but I'm not sure it's worth the extra work
21:04:41  <planetmaker> Because: when we're done, then the current stable will also read adv. spritelayouts ;-)
21:04:47  <Terkhen> I don't think it is, it was a joke :P
21:05:20  <Terkhen> go ahead with that code, it is nicer :)
21:09:01  * andythenorth goes to bed 
21:09:37  <Yexo> night andythenorth
21:09:58  <andythenorth> bye
21:10:09  <andythenorth> maybe ground tile will be fixed for grain mill when I wake up :)
21:10:15  *** andythenorth has quit IRC
21:11:24  *** StepaBarth has quit IRC
21:11:52  <planetmaker> hm... if he had pulled, he might have noticed it's fixed (or so I believe)
21:16:37  <Terkhen> :P
21:19:47  *** frosch123 has quit IRC
21:26:15  *** JVassie has joined #openttdcoop.devzone
21:29:49  *** FooBar has quit IRC
21:33:29  <Brot6> Unrealistic Trainset - Feature #3025: Monorail ICE Series (V453000) @
21:35:25  <Yexo> is this "unrealistic trainset" the same as NUTS?
21:35:34  <V453000> yes please
21:35:53  <V453000> the acronym stands for Nameless Unrealistic Train Set
21:36:02  <Yexo> ah, right :)
21:36:17  <V453000> why do you ask? :)
21:36:44  <Yexo> I've read the forum topic about nuts, seen several commits here to "unrealistic trainset" but wasn't sure if there were the same
21:36:54  <Yexo> curiosity, that's all
21:37:18  <V453000> :p
21:37:39  <V453000> it is just the fact that I was not too sure about the name when the devzone project was created
21:37:46  <V453000> as you can see in the overview page :)
21:38:00  <V453000> oh no
21:38:11  <V453000> it is in one of the issues geneal ideas, so a bit more hidden :)
21:38:12  <V453000> nevermind
21:38:28  <Yexo> brace for incoming spam
21:39:07  <V453000> ?
21:39:22  <Yexo> moving several AI projects over from to the devzone
21:39:34  <V453000> oh :)
21:39:53  <Ammler> you need svn?
21:39:59  <Yexo> nope, hg is fine
21:40:15  <Yexo> are they still created automatically?
21:40:25  <Ammler> yes, pm said something about svn, but I don't think it would work :-)
21:40:28  <Yexo> ie I just enable "repository" during project creating?
21:40:52  <Ammler> yes
21:41:11  <Ammler> just enable the module, do not configure it
21:41:21  <Yexo> ok, that's what I'm doing
21:41:32  <Ammler> 42 will tell
21:42:00  <V453000> anyway, good night :)
21:42:04  <Brot6> repository /home/hg/ai-wrightai registered in Redmine with url /home/hg/ai-wrightai
21:42:04  <Brot6> repository /home/hg/ai-wrightai created
21:42:04  <Brot6> repository /home/hg/lib-aystar registered in Redmine with url /home/hg/lib-aystar
21:42:04  <Brot6> repository /home/hg/lib-aystar created
21:42:04  <Brot6> repository /home/hg/lib-pathfinderrail registered in Redmine with url /home/hg/lib-pathfinderrail
21:42:07  <Brot6> repository /home/hg/lib-pathfinderrail created
21:42:09  <Brot6> repository /home/hg/lib-pathfinderroad registered in Redmine with url /home/hg/lib-pathfinderroad
21:42:12  <Brot6> repository /home/hg/lib-pathfinderroad created
21:42:21  <Ammler> hmm, not ailib?
21:42:56  <Yexo> copied the names from
21:43:06  <Yexo> they had "ai-" and "lib-" as prefixes there
21:43:25  <Ammler> ok, your other project on devzone had ailib, afaik
21:43:48  <Yexo> hmm, yes, except for "superlib"
21:44:16  <Ammler> might not really matter anyway...
21:45:31  <Yexo> how often are repositories created?
21:45:43  <Yexo> I've created 3 more projects
21:48:07  <Brot6> AI: WrightAI - Revision 7:96056d58f01b: update tags (convert-repo) @
21:48:58  <Brot6> Library: Graph.AyStar - Revision 8:fd151ad73333: update tags (convert-repo) @
21:49:04  <Brot6> repository /home/hg/lib-binaryheap registered in Redmine with url /home/hg/lib-binaryheap
21:49:04  <Brot6> repository /home/hg/lib-binaryheap created
21:49:04  <Brot6> repository /home/hg/lib-fibonacciheap registered in Redmine with url /home/hg/lib-fibonacciheap
21:49:04  <Brot6> repository /home/hg/lib-fibonacciheap created
21:49:04  <Brot6> repository /home/hg/lib-priorityqueue registered in Redmine with url /home/hg/lib-priorityqueue
21:49:07  <Brot6> repository /home/hg/lib-priorityqueue created
21:49:59  <Brot6> Library: Pathfinder.Rail - Revision 2:35d7b3db9b76: update tags (convert-repo) @
21:49:59  <Brot6> Library: Pathfinder.Road - Revision 5:c65c77fcf914: update tags (convert-repo) @
21:49:59  <Brot6> Library: Queue.BinaryHeap - Revision 2:f893d3b9c750: update tags (convert-repo) @
21:50:52  <Brot6> Library: Queue.FibonacciHeap - Revision 2:54b3ecdb907d: update tags (convert-repo) @
21:50:52  <Brot6> Library: Queue.PriorityQueue - Revision 3:4ce52a7de63c: update tags (convert-repo) @
21:51:11  <Yexo> done, that wasn't so bad :)
21:54:05  <Terkhen> :)
21:58:33  *** Lakie has joined #openttdcoop.devzone
22:05:52  <planetmaker> :-)
22:16:07  *** JVassie has quit IRC
22:35:21  <Terkhen> planetmaker: it seems that using TRIGGER_VEHICLE_NEW_LOAD as trigger solves the ENSP issue
22:35:40  <Terkhen> (instead of TRIGGER_VEHICLE_UNLOAD_ALL)
22:36:01  <planetmaker> Terkhen: also when I run around with 20% load and get additional cargo?
22:36:19  <planetmaker> that's iirc where that failed
22:36:27  <Terkhen> let's see
22:36:30  <planetmaker> but it's long ago I played with that
22:37:11  <Terkhen> it seems to work too
22:37:15  <Terkhen> what was the problem with that?
22:39:56  <planetmaker> I thought it re-randomized when taking additional cargo
22:40:26  <planetmaker> (and conceptionally I would not understand why 'unload all' doesn't work - but meh) :-)
22:41:06  <Terkhen> Vehicle gets new load of cargo (only after it was empty)
22:41:13  <Terkhen> unload all should work too
22:41:20  <Terkhen> The consist has unloaded all cargo (use with type 'SELF')
22:41:40  <Terkhen> but but somehow it doesn't :)
22:42:14  <Brot6> OpenGFX+ Road Vehicles - Revision 121:3b4679ec5700: Feature #1880: Sprite support for Plastics (f... (Terkhen) @
22:42:15  <Brot6> OpenGFX+ Road Vehicles - Revision 122:f995fc2072b5: Feature #1880: Sprite support for Engineering... (Terkhen) @
23:13:03  *** hanf has quit IRC
23:16:24  *** Zuu has quit IRC
23:29:37  *** michi_cc has quit IRC

Powered by YARRSTE version: svn-trunk