Log for #openttdcoop.devzone on 13th May 2011:
Times are UTC Toggle Colours
00:10:18  *** KenjiE20 has quit IRC
01:51:49  *** Lakie has quit IRC
07:51:17  *** andythenorth has joined #openttdcoop.devzone
08:13:43  *** andythenorth has quit IRC
08:23:53  <Brot6> FIRS Industry Replacement Set - Revision 1990:a2f5e713d49c: Fix #2614: Translations sometimes had... (planetmaker) @
08:23:53  <Brot6> FIRS Industry Replacement Set - Bug #2614 (Closed): Translation framework broken when not all tex... (planetmaker) @
08:27:46  <planetmaker> ^ Yexo
08:28:13  <planetmaker> (sorry, I forgot yesterday about it)
09:38:24  *** andythenorth has joined #openttdcoop.devzone
10:31:46  *** andythenorth has quit IRC
10:43:03  *** KenjiE20 has joined #openttdcoop.devzone
10:58:02  <Brot6> OpenGFX+ Trains - Bug #2464 (Closed): Alignment error with T.I.M and AsiaStar (planetmaker) @
11:01:35  <Brot6> OpenGFX+ Trains - Revision 240:aaef62bea1dc: Doc: Update changelog (planetmaker) @
11:01:35  <Brot6> OpenGFX+ Trains - Revision 241:78960e678d6c: Added tag 0.2.5 for changeset aaef62bea1dc (planetmaker) @
11:01:50  <Brot6> ogfx-trains: update from 0.2.4 to 0.2.5 done -
11:56:56  <Ammler> planetmaker: will the other (also nice) trees be still available somehow?
11:58:31  <Ammler> maybe via ogfx-land?
11:59:38  <Ammler> and what is the sense of ogfx+trees now?
12:08:47  <planetmaker> not much sense for them then. But which other nice trees?
12:09:43  <planetmaker> I'm pondering to add some option for tree modifications to ogfx+landscape, but not urgent either. If the trees within OpenGFX will be renewed
12:10:02  <planetmaker> So far I have a complete rewamp of the arctic trees.
12:10:45  <planetmaker> And I'm mostly done with the temperate ones. Three(? four?) need their growth and decay stages drawn
12:10:51  <planetmaker> then they're done, too
12:11:10  <planetmaker> Tropical will have to be seen, but they're not that bad as temperate and arctic
12:11:28  <planetmaker> ^ Ammler
12:12:38  <planetmaker> has a somewhat recent status of the tree work
12:12:38  <Webster> Title: Transport Tycoon Forums View topic - [8bpp] Graphics Replacement Project - OpenGFX (at
12:14:09  <Ammler> ah ok, so you don't like the current ogfx tress, I see
12:14:42  <Ammler> I think those are more ttdish :-)
12:15:31  <planetmaker> he, well, even zephyris, who drew them, wants to see them replaced ;-)
12:16:09  <Ammler> I think, there are other things like maglev tracks, which need redrawing...
12:16:16  <planetmaker> yes, also
12:16:32  <planetmaker> I still ponder replacing them by smits ;-)
12:16:57  <planetmaker> but more important IMHO, houses need some touch
12:17:06  <Ammler> yeah, there I have same opinion as with the trees
12:17:14  <planetmaker> they're have a very large colour noise
12:17:28  <Ammler> I would like those better drawn in ttd style then completely new
12:18:56  <planetmaker> Air planes could also need continued replacement by the new models :-)
12:19:00  <Ammler> ogfx+trees should be renamed
12:19:05  <planetmaker> hard to do
12:19:28  <Ammler> as it only makes sense to use it without ogfx :-)
12:22:21  <planetmaker> :-)
12:22:39  <planetmaker> will be, yes
12:22:48  <planetmaker> opengfx trees ;-)
12:23:25  <planetmaker> and... it could in principle also then incorporate the current trees, if you like. Do you want to maybe take over that grf and update correspondingly?
12:25:27  <planetmaker> an update might be worthwhile irrespective of whether the existing OpenGFX trees are added or not. As I drew  / will draw additional growth stages for trees within that set
12:26:04  <Ammler> I don't code something for teh original set
12:26:25  <Ammler> that would be quite waste of my time :-)
12:26:55  <Ammler> I would rather add the current ogfx tress to ogfx+landscape
12:27:18  <Ammler> mäh again s/tress/trees/
12:28:35  <Ammler> well, the only code I would participate there is renaming :-)
12:28:48  <planetmaker> Well, I'd suggest that the current trees go into OpenGFX trees :-)
12:29:07  <Ammler> not worth a own grf, imo
12:29:16  <planetmaker> that's why they could go there
12:29:29  <Ammler> I might be the only one who prefer those
12:29:31  <planetmaker> and then using opengfx(+) trees would make sure all can use the same trees ;-)
12:30:55  <Ammler> maybe it is also because I have 99% of the time trees disabled
12:31:07  <planetmaker> :-)
12:31:16  <Ammler> the only place I see trees is on the ps webcam
12:33:20  <planetmaker> he... well. I usually have everything visible. But by 'x' everything transparent or invisible which helps me building. Like industries, trees, houses, bridges invisible then. Signs are constantly transparent
12:33:40  <planetmaker> without complete visibility one cannot do proper grf testing ;-)
12:33:55  <planetmaker> and I learnt the hard way that I shouldn't disable full details and full animation either ;-)
12:35:14  <Ammler> hehe, true
12:36:00  <planetmaker> and on the other hand: half the time I'm connected to any server, I just browse the map and enjoy watching the game ;-)
12:36:07  <planetmaker> so another reason to hide nothing ;-)
12:36:44  <planetmaker> same actually is true when I play SP. Which rarely happens, though
13:08:59  <planetmaker> Ammler, did you ever play with Zephyris' building generator
13:09:00  <planetmaker> ?
13:09:31  <V453000> what that is? :)
13:12:12  <planetmaker> a script which draws buildings for you ;-)
13:12:19  <Yexo> see
13:12:20  <Webster> Title: Transport Tycoon Forums View topic - Zephyris' Procedural Buildings Tool (at
13:12:53  <V453000> :D
13:13:16  <planetmaker> he, yexo was faster :-)
13:14:02  <planetmaker> you just tell a few parameters, like "I want 3 houses with 2 storeys" and you'll get it ;-)
13:14:22  <planetmaker> and with that small extension which yexo wrote, you'll get it straight as newgrf ;-)
13:14:42  <planetmaker> all you need is imageJ and nml
13:16:00  <Ammler> J=java?
13:16:39  <Ammler> I thought, it is a windows tool
13:17:10  <planetmaker> it's platform independent. It's java, yes
13:17:19  <planetmaker> and open-source
13:17:34  <Ammler> but zeph wrote on that thread about windows only, didn't he?
13:17:46  <planetmaker> dunno.
13:17:58  <planetmaker> if he did, I ignored it as I knew imageJ before ;-)
13:18:05  <Ammler> ok
13:18:10  <planetmaker> it works on both my linux and my osx
13:19:10  <Yexo> it definitely also works on windows, as I wrote my script when using it
13:19:23  <planetmaker>
13:19:24  <Webster> Title: ImageJ (at
13:29:41  <Ammler> yes, imagej is availabe from obs
13:29:59  <Ammler> so if you like to use it here, devzone can use it :-)
13:36:16  <planetmaker> he, sweet :-)
13:45:13  <Brot6> OpenGFX+ Road Vehicles - Bug #2274 (Closed): DevZone compile failed (Terkhen) @
14:01:01  <Brot6> OpenGFX+ Road Vehicles - Bug #2412 (Closed): verify that cement can be transported with ECS 1.0 v... (Terkhen) @
14:01:01  <Brot6> OpenGFX+ Road Vehicles - Revision 81:147256c48637: Fix #2412: Update cargo definitions to the one... (Terkhen) @
14:01:31  <Terkhen> I wasn't aware of that bug report
14:01:54  <Terkhen> it is easy to fix, given that we use the same cargo definitions :)
14:02:30  <planetmaker> Did you test actually?
14:03:10  <Terkhen> yes
14:03:21  <planetmaker> ok :-)
14:03:26  <Terkhen> cement was missing, now it is not :)
14:03:28  <planetmaker> <-- that's why I wondered :-P
14:03:49  <Terkhen> huh
14:04:25  <Terkhen> yes, after checking the diff I saw that plastic was removed from the flatbeds, but it made sense so I committed that too
14:04:25  <planetmaker> I'm actually not sure anymore whether it's valid :-)
14:04:37  <planetmaker> But I don't dare close it before I spend some time really investigating
14:05:00  <Terkhen> flatbeds were refittable to plastic in ogfx-rv, but now they are not :P
14:05:07  <planetmaker> but seems now you solved it the other way around ;-)
14:05:16  <Terkhen> given that they don't have sprites anyways, I prefer it
14:05:21  <planetmaker> he :-)
14:06:37  <Terkhen> I'm wondering if I should try to change the colours of existing sprites with my non existent graphical skills for supporting a few more cargos
14:06:52  <Terkhen> I have waited long enough already
14:07:53  <planetmaker> just replacing colours is easy. Though not necessarily done in no time. you have gimp, right?
14:07:57  <Brot6> OpenGFX+ Trains - Feature #1895: Adjust cargo definitions to match OpenGFX+ RV (planetmaker) @
14:08:59  <planetmaker> what I'd do is this: open the file of the existing vehicle and save it as a gimp file.
14:10:01  <planetmaker> Then add a new, transparent layer, give it the name of the new cargo.
14:10:16  <planetmaker> Make the background with the existing vehicle the active one again (from the layer selction window)
14:11:07  <planetmaker> use the colour-picker tool (shift+o) now:
14:12:10  <planetmaker> select the first pixel from the cargo. then ctrl+select the other colours of the cargo, too until you have a selection which is only the cargo.
14:12:31  <planetmaker> copy this selection (ctrl+c) and switch the active plane to the new cargo's plane
14:12:39  <planetmaker> insert the copied cargo
14:13:06  <planetmaker> (if you didn't change the selection it should be in the very same place, visually nothing changed, though)
14:13:36  <planetmaker> Now start to actually replace the colours: use ctrl+o to select pixels of one colour.
14:13:57  <planetmaker> use a big brush (17px or so) and overpaint all pixels by the new desired colour
14:14:03  <planetmaker> repeat until all cargo is replaced
14:14:28  <planetmaker> if you want another re-colour: you can now just duplicate this plane and repeat the recolour process alone
14:15:15  <Terkhen> thank you, let's see what I manage to do :)
14:15:16  <planetmaker> in order to get the sprites: use 'save copy as' with the relevant layers visible and save that as png for each cargo once
14:16:07  <planetmaker> 'n' is the shortcut for the normal brush ;-)
14:17:14  <planetmaker> hm... might be that it's ctrl+o for the colour-select-region tool instead of shift+o. Don't recall
14:17:28  <planetmaker> probably shift, though. ctrl+o will be 'open file'
14:18:59  <planetmaker> ah, another important thing: set the colour-sensitivity of the colour-picker tool to the lowest possible value
14:19:06  <planetmaker> you want it to pick that exact colour only
14:19:19  <Terkhen> ok :)
14:19:21  <planetmaker> you do that in gimp's main window
14:24:16  <planetmaker> Terkhen, have possibly a look at how I arranged the road tiles within opengfx +landscape for how conceptually the layer solution will work ;-)
14:25:26  <planetmaker>
14:26:07  <planetmaker> I've not yet done it for vehicles... I only really learnt this work flow recently
14:27:19  <Terkhen> hintergrund N29 has a white pixel inside the blue square
14:27:56  <Terkhen> do you keep the xcf file for easier editing or do you actually get the png files from it during compilation?
14:28:18  <Terkhen> s/white/grey-ish/
14:35:28  <Terkhen> I must be doing something wrong; when clicking with the select by color tool anywhere, nothing happens
14:35:49  <Terkhen> the new transparent layer for the cargo is disabled, I'm working only with the original graphic
14:36:03  <Terkhen> other selection tools seem to work fine
14:36:40  <Terkhen> select by color fails to select anything even after modifying the threshold
14:37:11  <planetmaker> I add the xcf files to the repo as graphics source
14:37:24  <planetmaker> and the pngs, of course, too.
14:38:01  <planetmaker> you use the shift+o tool, not just o?
14:38:31  <planetmaker>
14:38:32  <Webster> Title: 2.6. Select By Color (at
14:38:35  <planetmaker> ^  that tool
14:38:56  <planetmaker> if it has no effect, the wrong layer may be selected
14:39:29  <planetmaker> because the new, transparent layer will have all the same pixels and you'd select everything
14:40:19  <Terkhen> it was the layer... I assumed that hiding it would be enough to make sure I selected the current one but by doing that I left it selected
14:40:48  <planetmaker> nope, that's not enough :-)
14:41:03  <planetmaker> that's a behaviour which can be quite confusing
14:41:46  <planetmaker> but it can be considered advantageous, too
14:42:23  <planetmaker> as it allows you to continue working on a layer and switch on/off layers which are below or above it
14:43:09  <planetmaker> and of course you can have like 100 simultaneously visible layers
14:46:41  <planetmaker> like, if you have a two-part truck, you could keep the driver cabin for several versions and have the different cargo holds in different layers, and their respective cargo representations in yet another
14:47:16  <planetmaker> Thus for the complete vehicle you'd need two (empty) or three (with cargo) layers active
14:48:51  <planetmaker> alternatively to using the brush tool for replacing colours, you can use the paint bucket (shift+b) and then fill the whole selection with that colour by means of ctrl+click
14:50:35  <Terkhen> a huge brush worked fine :)
14:50:51  <Terkhen> I think I have bauxite graphics now (I picked the colours from opengfx+ trains)
14:50:56  <Terkhen> let's see if it works
14:51:02  <planetmaker> :-)
14:51:24  <Terkhen> and yes, keeping a xcf file with all cargos as layers is IMO a good idea
14:51:55  <planetmaker> of course :-) it makes modifications later on SO much easier and quicker
14:53:02  <planetmaker> especially if the modification only affect the vehicle and not the cargo.
14:53:18  <planetmaker> just saving n times is then sufficient while the modification work is done only once
14:58:11  <planetmaker> I think in terms of programming the .png can then rather be considered the object fine than the source file - if one started with layered graphics
15:00:51  <Terkhen> I think I can have a layer for each truck generation to simplify the work even further
15:02:55  <planetmaker> yes, if the cargo hold is the same: definitely
15:03:38  <planetmaker> like for road / rail in ogfx-landscape I have only one file. With all possible ground tiles. And with grid lines in separate layers
15:05:49  <Terkhen> it works :)
15:08:26  *** ODM has joined #openttdcoop.devzone
15:11:58  <planetmaker> :-)
15:22:00  <Brot6> OpenGFX+ Road Vehicles - Revision 82:c7db51edfe45: Feature #1880: Sprite support for Bauxite. (Terkhen) @
15:29:43  *** Lakie has joined #openttdcoop.devzone
15:49:03  *** Lakie` has joined #openttdcoop.devzone
15:54:19  *** Doorslammer has joined #openttdcoop.devzone
15:54:33  *** Lakie has quit IRC
15:54:41  *** Lakie` is now known as Lakie
16:20:27  <Brot6> OpenGFX+ Road Vehicles - Revision 83:ba4cbf665662: Change: Rename the file for truck templates. (Terkhen) @
16:20:27  <Brot6> OpenGFX+ Road Vehicles - Revision 84:ba6add414004: Feature #1880: Sprite support for Clay. (Terkhen) @
16:20:27  <Brot6> OpenGFX+ Road Vehicles - Revision 85:394f6769838d: Feature #1880: Sprite support for Stone/Fertil... (Terkhen) @
16:22:36  <Terkhen> planetmaker: opengfx+ trains uses the default graphics (coal) for FICR, is that a known issue, or not an issue at all?
16:22:45  * Terkhen does not know what that cargo represents
16:24:33  <Terkhen> LIME is in the same situation
16:30:51  <Yexo> FICR = Fibre crops, LIME = Lime stone
16:32:35  <Terkhen> thanks, but what I meant is that I don't know what are Fibre crops and how are they supposed to look
16:32:39  <Terkhen> maybe they are completely black :P
16:32:45  <Terkhen> but probably not
16:34:05  <Yexo> according to "fibre crops" is a common name for multiple fibers, like jute, flax and hemp
16:34:06  <Webster> Title: Fiber crop - Wikipedia, the free encyclopedia (at
16:34:26  <Yexo> even cotton apparently
16:34:58  <Terkhen> hmm... okay, then opengfx+ trains lacking an sprite for it is an issue after all
16:36:06  <Yexo> makes me wonder why FICR has "piece goods" as cargo class
16:36:57  <Terkhen>
16:37:15  <Terkhen> I'll give it a white colour :)
16:37:47  <Yexo> for limestone you could use the coal graphics converted to light gray colors
16:39:21  <Terkhen> ok :)
16:47:16  *** Doorslammer has quit IRC
17:08:06  <Brot6> grfcodec: update from r828 to r829 done -
17:15:02  *** Ruudjah has joined #openttdcoop.devzone
17:18:41  <Brot6> firs: update from r1989 to r1990 done -
17:19:07  <Brot6> ogfx-industries: update from r94 to r95 done -
17:19:19  <Brot6> ogfx-rv: update from r80 to r85 done -
17:19:33  <Brot6> ogfx-trains: update from r239 to r241 done -
17:19:40  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r73), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r138), comic-houses (r71), fish (r626), frenchtowns (r6), german-townnames (r33), grfcodec (r829), grfpack (r279), heqs (r605),
17:19:40  <Brot6> indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r285), nml (r1334), nutracks (r186), ogfx-landscape (r67), ogfx-trees (r42), opengfx (r663), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r671)
17:27:12  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:28:51  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (6 errors), 32bpp-extra (2 errors), basecosts, bros (1 errors), chips (1 errors), comic-houses (3 errors) (Diffsize: 22), fish, heqs, metrotrackset (Diffsize: 1), newgrf_makefile, nutracks, ogfx-trees, opengfx (Diffsize: 7), smts (Diffsize: 8), snowlinemod, transrapidtrackset (Diffsize: 12), ttrs (7 errors) (Diffsize: 1324),
17:28:51  <Brot6> worldairlinersset (Diffsize: 11)
17:37:11  <Brot6> OpenGFX+ Road Vehicles - Revision 86:78881eb8b5dd: Feature #1880: Sprite support for Lumber/Wood ... (Terkhen) @
17:55:13  *** frosch123 has joined #openttdcoop.devzone
18:38:03  <Brot6> OpenGFX+ Industries - Revision 96:8b73c2cba691: Fix: Give Shops a more appropiate fund cost multi... (Terkhen) @
18:46:44  <Terkhen> planetmaker:
20:14:36  *** frosch123 has quit IRC
20:30:06  <planetmaker> [22:29]	Terkhen	[18:22:36] planetmaker: opengfx+ trains uses the default graphics (coal) for FICR, is that a known issue, or not an issue at all? <-- probably somewhat known, but not really
20:30:23  <planetmaker> Coal cargo sprites is the default when no dedicated sprites are available for the bulk wagon
20:31:02  <Terkhen> ok :)
20:31:11  <Terkhen> new issue, or comment to #1528?
20:31:11  <Brot6> Terkhen: #1528 is "OpenGFX+ Trains - Feature #1528: Support for additional cargos - #openttdcoop Development Zone"
20:32:53  <planetmaker> smaller issues are more satisfying to work on ;-)
20:33:14  <Terkhen> ok :)
20:36:15  <Brot6> OpenGFX+ Trains - Feature #2628 (New): Sprite support for Fibre Crops and Lime Stone. (Terkhen) @
20:45:21  <Terkhen> do you think that any other industries should get the "single industry per town" template?
20:45:50  <planetmaker> other than?
20:46:02  <planetmaker> banks should
20:46:10  <planetmaker> maybe shop
20:46:15  <Terkhen> shop, bank and water tower are right now in the patch
20:46:39  <planetmaker> Terkhen: could it rather be one per 5000 inhabitants?
20:46:47  <Terkhen> hmm...
20:46:57  <Terkhen> I have no idea :P
20:47:06  <planetmaker> One water tower in the middle of a huge city is... a nuisance
20:47:21  <Terkhen> now we can get the number of industries of a given type in a town
20:47:30  <Terkhen> if we can get the town population somehow then it should be possible
20:47:34  <planetmaker> we can get the population or # of houses?
20:47:52  <Terkhen> but you have a valid point
20:48:06  <Terkhen> I usually don't play with gigantic cities :P
20:48:21  <planetmaker> hm... towns (not implemented yet)
20:48:39  <Terkhen> in nml?
20:48:47  <planetmaker> that's what the doc says
20:48:50  <planetmaker> of nml
20:49:01  <Terkhen> I'm checking the varaction2 vars for industries on the specs
20:50:27  <Terkhen> I don't find anything related to town population
20:52:04  <Terkhen> <--- I was searching for towns :)
20:52:43  <Terkhen> I guess that var 82 should give us the town population
20:54:32  <Terkhen> case 0x82: return industry->town->index; <---- this is the OpenTTD code for that var... it does not seem to do what it should
20:55:54  <planetmaker> doesn't look like the size indeed
20:56:10  <planetmaker> that should be 0x41
20:56:37  <planetmaker> but honestly, var B6 is more interesting :-)
20:56:53  <planetmaker> population is highly grf-dependent, the house # less so
20:57:40  <Terkhen> it looks like it is not implemented
20:58:03  <planetmaker> woot, we don't have B6?
20:58:30  <Terkhen> unless it is handled somehow in other part of the code, no
20:58:49  <Terkhen> the switch of IndustryGetVariable ends with 0xB4
20:59:08  <planetmaker> I meant town variable b6
20:59:44  <Terkhen> hmm... I'm understanding this the wrong way, isn't it? :P
20:59:52  <planetmaker> you must look in newgrf_town.cpp
21:00:00  *** andythenorth has joined #openttdcoop.devzone
21:00:03  <planetmaker> there we also have the correct 82
21:00:23  <Terkhen> but how can we access those from an industry?
21:00:25  <planetmaker> and b6 as num houses
21:00:28  <planetmaker> as PARENT scope
21:01:30  <Terkhen> that's something new for me... and very interesting :)
21:01:58  <Terkhen> sorry about the confusion :P
21:02:33  <Terkhen> ok, it can be done then
21:02:37  <planetmaker> <-- see there
21:03:15  <planetmaker> I knew that concept from trains :-)
21:03:16  <Terkhen> yes, I was checking that table and starting to understand how to do all of that magic with articulated vehicles
21:03:35  <Terkhen> the problem I see now is... what error message do we give?
21:03:48  <planetmaker> town too small
21:04:04  <planetmaker> for {NUM} shops
21:04:20  <planetmaker> I wonder if that works ;-)
21:04:26  <Terkhen> that's what I was wondering... can we use parameters in error messages from a callback?
21:04:53  <planetmaker> hm...
21:04:58  <planetmaker> I don't know
21:15:18  <Terkhen> I don't find anything
21:15:24  <Terkhen> not that I know where to look about this in the specs either
21:40:31  <planetmaker> Terkhen: I think it's feasible
21:40:41  <planetmaker> error messages can display parameter values
21:40:50  <planetmaker> and... a parameter can be modified
21:41:26  <Terkhen> all the examples of error messages I found on the nml specs use predefined parameters
21:41:36  <Terkhen> I couldn't found syntax for setting them
21:41:41  <Terkhen> s/found/find/
21:43:27  <planetmaker> hm... we want an error shown when building an industry, right ? Ho, hum... I looked at all the wrong places...
21:45:55  *** andythenorth has quit IRC
21:49:26  <planetmaker> "Since TTDPatch r1755, you can use the text reference stack for your error messages, similarly to callback 3A. The only difference is that only 4 registers are copied instead of 6 because error messages support 20 bytes of reference stack only, and two of those bytes may be used by TTD."
21:49:33  <planetmaker> suggest that you probably can
21:49:48  <planetmaker> that's copied from the industry location permissibility CB description
21:51:43  <planetmaker> ah... variables 0x100 ... 0x103 are used
21:52:08  <Terkhen> oh :)
21:52:17  <Terkhen> 4 parameters is more than enough IMO
21:52:28  *** andythenorth has joined #openttdcoop.devzone
21:52:54  <planetmaker> yep :-)
21:54:04  <Terkhen> so something like... "... town is too small for {NUM} industries of this type", where num is "num of industries of this type in the town + 1"
21:54:43  <planetmaker> yep, something like that is what I thought
21:55:24  <planetmaker> We should add an info on the shops/houses ratio, though :-)
21:55:35  <Terkhen> where?
21:55:42  <planetmaker> in that error message :-)
21:56:17  <planetmaker> "... (there can be only 1 shop for each 500 houses)"
21:56:46  <Terkhen> hmm... ok :)
21:58:48  <planetmaker> btw... totally unrelated: which hg version do you use?
22:01:08  <Terkhen> 1.8.3, it was updated recently IIRC
22:02:17  <planetmaker> ok. I'm still pondering the opengfx graphics (sub) repo
22:02:23  <planetmaker> that needs >= 1.7
22:02:58  <Terkhen> I suppose that there are distros still running 1.6
22:04:00  <planetmaker> well. Do they then need to build a newer opengfx*?
22:04:56  <planetmaker> I currently see much duplication in our graphics. Which is... tedious, boring and inconsistency-prone
22:05:53  <planetmaker> it'd be nicer to update one graphic and all opengfx* grfs which use it can be updated on the next commit to their repo when they update the graphics sub-repo
22:06:35  <Terkhen> debian squeeze uses 1.6.4, ubuntu 11.04 uses 1.7.5
22:06:50  <planetmaker> like many opengfx vehicles and all landscape tiles. Now industry tiles
22:06:54  <Terkhen> I agree with that, a single repo would be better :)
22:07:32  <Terkhen> but I find how opengfx files are organized very chaotic, the first thing I did with opengfx+ road vehicles was sorting the sprites in a way I could use them
22:08:00  <planetmaker> I fully agree. It's currently in a not good shape
22:08:47  <planetmaker> many of opengfx' graphics organization is legacy... it still shows there much that it was thrown together from many different preliminary newgrfs
22:09:16  <Terkhen> as long as the reorganization keeps the sprites of opengfx+ in the way they are now I don't mind it :P
22:09:34  <planetmaker> And... one of the other advantages would then be: the work on opengfx+ could help to clean it for opengfx, too.
22:10:15  <planetmaker> well... organization would probably slightly change... as the many graphics repos need merging *somehow*
22:10:21  <planetmaker> how would you organize the sprites?
22:10:32  <Terkhen> I have no idea :P
22:10:52  <Terkhen> for opengfx+ I like small files with sprites for a single entity
22:10:53  <planetmaker> ok... what do you like about the opengfx+ sprite sorting?
22:11:03  <planetmaker> yes, I like that, too
22:11:09  <Terkhen> but probably that approach would not be good for something as big as opengfx
22:11:17  <planetmaker> well... why not?
22:11:39  <Terkhen> opening that many files probably takes a toll on execution time... but I would be willing to wait :P
22:12:01  <planetmaker> hm, maybe. I never thought about that
22:12:17  <planetmaker> but then, I've always been trying to cut down the large files to smaller ones
22:12:30  <planetmaker> when I touched and changed things
22:13:09  <planetmaker> still... all wagons of one climate in one file. But... that can be big or small. Depending on view ;-)
22:13:15  <planetmaker> both has pros and cons
22:13:28  <Terkhen> the extra time is probably not that big
22:13:28  <planetmaker> but the landscape or infrastructure files... ugly
22:14:17  <planetmaker> and another step then would, of course, be to share the sprite templates.
22:15:07  <planetmaker> thus I wonder whether it should not rather be opengfx-common with templates, graphics and graphics-source
22:15:25  <planetmaker> though... maybe graphics-source should not be separate. Dunno. What do you think?
22:16:09  *** andythenorth has left #openttdcoop.devzone
22:16:47  <Terkhen> what do you mean with graphics-source?
22:18:24  <planetmaker> for example the .xcf files
22:18:40  <planetmaker> or psd
22:20:00  <Terkhen> hmm... I don't know
22:20:34  <Terkhen> graphics for bauxite make little sense in a opengfx repo
22:22:16  <planetmaker> well, they do. OpenGFX+ trains, rv, maybe stations can all use them
22:23:07  <planetmaker> not directly opengfx, but then it will have of course more graphics than every single grf has now
22:23:16  <planetmaker> nothing too bad about that, I think
22:23:35  <Terkhen> that's true, yes
22:24:40  <planetmaker> but more so: all the vehicles you have, they'd not need being in both opengfx and opengfx+rv
22:24:54  <planetmaker> only once for both (and in the better order as found in the rv newgrf ;-) )
22:25:01  <Terkhen> but then the graphics-source files should follow some naming rules for layers for keeping everything clearly labelled
22:25:34  *** ODM has quit IRC
22:25:53  <planetmaker> yes... that's the responsibility of the people creating the layers. But it's not that easy
22:26:19  <Terkhen> well, we just started, we could write some guidelines before they get messier :)
22:26:24  <planetmaker> i.e. the road / rail infrastructure: I have the rail tracks there, I have the terrain there, I have the grid there
22:26:41  <planetmaker> and the roads
22:27:18  <planetmaker> I gave them the appropriate names what they are. But it doesn't relate directly to any filenames - though I made them verbose, too
22:27:49  <planetmaker> but there's no easy way to know which xcf file to look at... that's IMHO the most interesting thing to know when trying to fix a certain sprite
22:28:19  <planetmaker> same filename stem?
22:28:50  <planetmaker> infra.xcf --> infra_road_temp_grid.png, infra_road_desert_grid.png, infra_road_desert_nogrid.png,... ?
22:29:44  <planetmaker> all in a common graphics 'source' folder?
22:30:01  <Terkhen> I have bulk_truck.xcf -> bulk_truck_1_grain, bulk_truck_3_coal...
22:30:15  <planetmaker> same pattern :-)
22:30:45  <Terkhen> for me "source" means something that is used to compile, but these files are not (or at least not directly)
22:30:45  <planetmaker> but what are 1 or 3? The generation?
22:30:48  <Terkhen> yes
22:31:02  <Terkhen> I keep them all in the same file because they can reuse the cargo layer
22:31:34  <planetmaker> ok, suggest another word than 'source'. :-) I know unfortunately no better and share your resentment, though
22:32:01  <planetmaker> though you could probably script gimpe and ... :-P
22:32:03  <planetmaker> -e
22:34:49  <Terkhen> would it be worth the effort?
22:35:17  <planetmaker> the scripting?
22:35:30  <Terkhen>
22:35:31  <Webster> Title: GIMP - Basic Perl (at
22:35:33  <Terkhen> looks like it exists
22:35:35  <planetmaker> I've no idea about the effort needed
22:35:48  <planetmaker> only that it's most probably possible
22:36:26  <Terkhen> hmm... no, this page looks more like something to create plugins
22:38:32  <planetmaker>
22:38:33  <Webster> Title: GIMP - Batch Mode (at
22:38:48  <Terkhen> I just found it too :)
22:39:24  <planetmaker> :-)
22:39:33  <Terkhen> so in principle it is possible to do it
22:41:39  <Terkhen> the problem is that it will need rules tailored to each xcf file to generate the pngs
22:41:58  <Terkhen> no generic approach, tedious rule editing
22:43:22  <Terkhen> anyways, it is already too late :)
22:43:24  <Terkhen> good night
22:46:52  <planetmaker> good night you, too. I'll probably be back only late(r) Sunday
23:46:02  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk