Log for #openttdcoop.devzone on 14th December 2011:
Times are UTC Toggle Colours
00:38:12  *** SnowDragon has quit IRC
07:55:23  *** Zuu has joined #openttdcoop.devzone
08:55:56  *** Zuu has quit IRC
09:13:25  *** ODM has joined #openttdcoop.devzone
09:28:51  <Brot6> Dutch Trains 2.0 - Bug #3363 (New): r88 and previous r's misalignments (Voyager1) @
10:06:12  <planetmaker> Yexo, will we backport things like the range property for planes? (IMHO no, need but...)
10:06:59  <planetmaker> I'm asking as I added an NML version template to the wiki. If we decide to not backport new stuff, we might want to start indicating it with the {{nml|0.3}} tag then
11:04:21  *** SnowDragon has joined #openttdcoop.devzone
11:07:24  *** ODM has quit IRC
11:51:44  <Brot6> Swedish Rails - Revision 227:5cf802fcc327: Add: String with URL to project website (planetmaker) @
11:55:17  <Brot6> OpenGFX+ Road Vehicles - Revision 141:0e6269f2cfa2: Add: String with URL to project website (planetmaker) @
11:57:48  <Brot6> ogfx-rv: compile of r141 still failed (#3356) -
12:00:00  <Brot6> OpenGFX+ Airports - Revision 148:84da48424310: Add: String with URL to project website (planetmaker) @
12:02:50  <Brot6> airportsplus: compile of r148 still failed (#3358) -
12:21:09  <Yexo> don't see a need to backprot the range property
12:21:21  <Yexo> I've backported a few of the new constants so the conversion is easier
12:21:33  <Yexo> and yes, a template for the version is useful
12:21:51  <planetmaker> hm... we need to re-write large parts of ogfx+airports :S
12:22:29  <planetmaker> ok. If we keep the range to 0.3, I'll add such info there
12:22:40  <planetmaker> I agree with that decision
12:22:43  *** SnowDragon has quit IRC
12:23:54  <Yexo> why do we need to rewrite large parts of it?
12:25:13  <planetmaker> it uses the old-style thing for animation callback
12:25:26  <planetmaker> and doing it properly means to re-do that stuff to use adv. spritelayouts
12:25:48  <planetmaker> which then could be used the same way also for the ground awareness
12:26:08  <Yexo> switching to new-style callbacks is very easy
12:26:10  <planetmaker> it shows in that part quite well that there was a learning curve.
12:26:17  <planetmaker> And a development in NewGRF features
12:26:21  <Yexo> switching to advanced spritelayouts is more work, but that doesn't have to be done immediately
12:26:29  <planetmaker> yes, probably true
12:27:26  <planetmaker> I just looked at the code and I found it all ugly
12:27:32  <planetmaker> Yes, I know, I mostly wrote it myself
12:27:41  <planetmaker> though I'd like to deny ;-)
12:33:16  <Yexo> if we're aiming for a release together with 1.2 we still have quite some time left to update it
12:45:45  <planetmaker> yes, of course
12:46:25  <planetmaker> I'm thinking of whether we might want to release a FIRS 0.7 beta and ogfx+trains in a week or so
12:46:37  <planetmaker> to get especially with FIRS some feedback on the current state
12:46:43  <planetmaker> and for trains some wrt autorefit
12:46:45  <planetmaker> thoughts?
12:47:04  <planetmaker> So that people can test it with 1.2 beta
12:47:08  <Yexo> seems fine
12:47:20  <planetmaker> might need some convincing of andy :-)
12:47:22  <Yexo> but get andy's input on the FIRS release
12:47:29  <planetmaker> of course
12:48:07  <Brot6> Dutch Trains 2.0 - Feature #3336: Old pax coaches (Voyager1) @
13:55:56  <planetmaker> hm... I wonder if blender can be integrated in the makefile just the same as gimp ;-)
13:57:11  *** SmatZ has quit IRC
13:58:05  *** SmatZ has joined #openttdcoop.devzone
15:24:26  <Yexo> planetmaker: how are we going to document things like the aircraft range property?
15:24:41  <Yexo> nml 0.3 already implies openttd 1.2, so is the openttd 1.2 part needed there?
15:28:33  <planetmaker> Well. IMHO it's easiest to document it the same way as the nfo specs, thus with the OpenTTD revision
15:28:53  <planetmaker> I added the openttd tag in that case as that revision is later than 23166
15:28:59  <Yexo> ok
15:29:07  <planetmaker> which I gave as the version which implements all "important" grf v8
15:30:37  <Yexo> fixed a small error in the template usage as the revision didn 't show
15:30:50  <planetmaker> nml revision?
15:30:55  <planetmaker> or openttd one?
15:30:59  <Yexo> openttd one
15:31:13  <Yexo> {{ottdp|1.2|no|ottdrev=r23504}} instead of {{ottdp|1.2|no|r23504}}
15:31:38  <Yexo> ship properties use {ottd|1.2|r22639}}
15:31:39  <planetmaker> oh. thx
15:31:49  <Yexo> perhaps we should use that template everywhere in the nml documentation?
15:31:55  <Yexo> as ttdpatch isn't really tested
15:31:56  *** ODM has joined #openttdcoop.devzone
15:32:49  <planetmaker> I guess you have a point. And it's not going to change
15:33:25  <planetmaker> refit_cost callback uses the ottdp template, though
15:33:32  <planetmaker> Thus it's ... inconsistent
15:34:19  <Yexo> yes, hence my proposal to use the ottd one from now one
15:34:28  <Brot6> NewGRF Meta Language - Revision 1761:d9720e778a81: Change: snowline_height is in tiles in NML 0.3 (yexo) @
15:38:29  <Brot6> NewGRF Meta Language - Revision 1762:cdb7883783c1: Change: canal variable 'tile_height' now retur... (yexo) @
15:39:45  <Yexo> FIRS is going to need some updates to fix the snow detection code
15:40:16  <planetmaker> did you revert my mis-placed height level adjustments?
15:40:35  <planetmaker> otherwise it assumes step-one heights already
15:41:24  <planetmaker> <-- still there
15:42:02  <Yexo> ((nearby_tile_height(0, 0) < (snowline_height + 8)) || (nearby_tile_height(0, 0) >= (snowline_height + 16))); \ <- that's not right
15:42:22  <Yexo> the +8 and +16 should be replaced by +1 and +2
15:43:49  <planetmaker> hm, I made it to the wrong branch. I'll transplant it.
16:01:16  <Yexo> several firs industries don't use the proper template yet
16:03:44  <Yexo> planetmaker: is there a reason the half-snow sprites don't have "always_draw: 1;" set?
16:04:19  <planetmaker> yes, I checked for the +8 and + 8 and similar.
16:04:27  <planetmaker> especially fruit_plantation and forest
16:04:44  <planetmaker> I'm still checking, though
16:04:56  <Yexo> that was not the point
16:05:07  <planetmaker> I know, that was the always_draw
16:05:14  <planetmaker> but I have no answer to that yet
16:05:20  <Yexo> always_draw is to make sure the sprite is drawn even when transparancy is on
16:05:57  <planetmaker> I guess it should get that, yes. Seems like an oversight
16:06:17  <Brot6> OpenGFX+ Industries - Revision 127:c2ebcdff9903: Add: groundaware template from FIRS (yexo) @
16:07:27  <planetmaker> you surprised. I thought for 5 seconds I'll have merge work to do ;-)
16:08:23  <Yexo> you can merge opengfx+industries r128 back to FIRS ;)
16:08:29  <Brot6> OpenGFX+ Industries - Revision 128:04f5104091a9: Fix: set always_draw for the ground sprite overlays (yexo) @
16:10:34  <planetmaker> I guess I didn't add it as I thought it was inherited by the child sprites from the ground sprite
16:10:50  <Yexo> makes sense :)
16:13:06  <Brot6> FIRS Industry Replacement Set - Revision 2653:2ee495087d0f: Change: Height levels have a granular... (planetmaker) @
16:13:06  <Brot6> FIRS Industry Replacement Set - Revision 2654:91b51f5dbec1: Fix: Always draw all ground sprites, ... (planetmaker) @
16:46:20  <Brot6> OpenGFX+ Industries - Revision 129:9634eb2cc15b: Fix: don't use temp storage register 0xFF, it's ... (yexo) @
17:09:57  <Yexo> r130 is another one we might want to port to FIRS. Oil well animation is broken there too: some tiles will never animate
17:10:10  <Brot6> OpenGFX+ Industries - Revision 130:4ab79a334f81: Fix: oil well animation was broken (yexo) @
17:11:51  <Brot6> nml: update from r1754 to r1762 done -
17:13:02  <Brot6> ogfx-industries: update from r126 to r130 done -
17:14:46  <Brot6> Dutch Trains 2.0 - Bug #3363 (Confirmed): r88 and previous r's misalignments (Voyager1) @
17:14:46  <Brot6> Dutch Trains 2.0 - Bug #3363 (Confirmed): r88 and previous r's misalignments (foobar) @
17:15:59  <Brot6> Dutch Trains 2.0 - Feature #3336: Old pax coaches (foobar) @
17:21:23  <Brot6> firs: update from r2648 to r2654 done (24 warnings) -
17:23:37  <Brot6> swedishrails: update from r226 to r227 done -
17:25:44  <Brot6> narvs: compile of r57 still failed (#3353) -
17:28:15  <planetmaker> Yexo: if you don't plan to port it now, it might be better to make a ticket
17:28:16  <Brot6> bandit: compile of r26 still failed (#3303) -
17:29:36  <Ammler> hmm, is this again CF issue?
17:31:14  <Brot6> FIRS Industry Replacement Set - Bug #3364 (New): oil well animation is broken (yexo) @
17:31:15  <Yexo> narvs fails because it uses old-style callbacks, which are no longer supported in nml trunk
17:33:08  <Ammler> downwards compatibilty is one of the most important things of such tools, very sad, you do not care
17:34:35  <Yexo> it can keep using nml 0.2, nothing wrong with that
17:35:29  <Ammler> not what I mean with downwards compatibility :-P
17:37:08  <Ammler> I wonder, how we can solve the issue if you will release 0.3
17:37:19  <Ammler> when*
17:37:38  <planetmaker> by upping opengfx' minimum openttd requirement
17:38:03  <Ammler> well, this isn't about ogfx
17:38:13  <planetmaker> given that many NewGRFs will start to be OpenTTD 1.2.0+ it won't matter. Just a feeling, though
17:38:28  <planetmaker> but?
17:38:59  <Yexo> Ammler: old-style callbacks have been deprecated for several months now
17:39:13  <Yexo> if at the time 0.3 is released they're still using them, they'll be stuck using nml 0.2
17:39:27  <Yexo> I really couldn't care less about unmaintained sets
17:39:46  <Ammler> yexo, that's ok, I just wonder, if we shall support that
17:40:08  <planetmaker> <-- that's all changes
17:40:18  <planetmaker> it's not that much work to update a single set
17:40:22  <Ammler> planetmaker: I guess, you do not get the issue I talk about
17:40:58  <planetmaker> you mean old nml code?
17:41:00  <Ammler> currenty, the CF can use releases or nightlies, but not special release versions
17:41:29  <Ammler> I wonder, if we need to support that or simply in this case disable building for such project
17:41:44  <Yexo> we'll see when the time is there, imo if they're that outdated we can disable building
17:41:54  <planetmaker> I think it's fine, if a project requires "last stable" or "nightly"
17:42:09  <planetmaker> other options are tmwftlg
17:42:24  <planetmaker> and if they arise... we can think about it then
17:42:51  <Brot6> North American Road Vehicle Set - Bug #3353: DevZone compile failed (Ammler) @
17:42:51  <planetmaker> arguably, we should be careful with the amount of required changes as in that link.
17:43:01  <planetmaker> But... progress sometimes has its price
17:43:59  <planetmaker> i.e. I cannot even run anymore the old openttd binaries (<0.3.5) on my machine
17:44:10  <planetmaker> except when I get an old system. maybe
17:44:20  <Ammler> I never was able to
17:44:30  <Brot6> dutchtramset: compile of r87 still failed (#3355) -
17:44:31  <Ammler> also on my first openttd days :-)
17:44:41  <planetmaker> :-)
17:45:06  <Ammler> 0.3.5 was the first version which was able to run on linux afaik
17:45:21  <Ammler> or which was able to build, dunno anymore
17:47:11  *** andythenorth has joined #openttdcoop.devzone
17:47:15  <planetmaker> :-D
17:47:21  <andythenorth> that made my mac beep
17:47:22  <andythenorth> how odd
17:47:29  <planetmaker> hehe :-)
17:47:42  <planetmaker> andythenorth: I wondered about our release schedules today...
17:47:56  <andythenorth> ...?
17:47:59  <planetmaker> I know you want "the big release day" with openttd 1.2.0
17:48:09  <planetmaker> but... what about a beta of FIRS for christmas.
17:48:20  <andythenorth> on bananas?
17:48:21  <planetmaker> Just tagging what we have to get some feedback on what we changed so far?
17:48:22  <planetmaker> yes
17:48:30  <andythenorth> hmm
17:48:34  <planetmaker> people could then test with the beta
17:48:48  <andythenorth> I started a game with 0.6.4 the other day - to see what was different
17:48:50  <Brot6> ogfx-rv: compile of r141 still failed (#3356) -
17:48:53  <andythenorth> the answer is....a lot changed
17:48:58  <planetmaker> yes
17:49:00  <planetmaker> exactly
17:49:12  <planetmaker> and... it might also be motivating for all authors :-P
17:49:13  <andythenorth> we're blocked by bananas though ...
17:49:27  <planetmaker> do we care when we have 1.2.0-beta available?
17:49:33  <Brot6> ogfx-landscape: compile of r110 still failed (#3357) -
17:49:38  <andythenorth> less so
17:49:44  <planetmaker> exactly
17:50:09  <planetmaker> I mean... it might be a good test. For many things. The grf, some ideas, for OpenTTD
17:50:12  <planetmaker> it's all beta
17:50:22  <andythenorth> I have no objections ;)
17:50:24  <planetmaker> so like FIRS 0.7-beta2 or whatever we want to call it
17:51:02  <andythenorth> or 0.8.0 or whatever
17:51:09  <planetmaker> I'd give it a beta name
17:51:19  <andythenorth> there was some good sound reason for 0.8.x-beta being next
17:51:20  <planetmaker> If we kinda "just tag it", it really will be beta
17:51:37  <planetmaker> yes, if it's 0.8.0-beta, I don't mind
17:51:45  <planetmaker> though we never had a 0.7.0
17:51:45  <andythenorth> matches the roadmap ;)
17:51:50  <andythenorth> no
17:51:54  <planetmaker> thus ... we might stick with 0.7.0-beta2
17:52:02  <andythenorth> we had an 0.7.0-RC, which tested the nml conversion
17:52:09  <planetmaker> no
17:52:16  <planetmaker> I just checked tags
17:52:18  <andythenorth> oh
17:52:20  <planetmaker> it only has one 0.7.0-beta1
17:52:24  <Yexo> we had 0.6.5, right?
17:52:24  <andythenorth> ok
17:52:26  <planetmaker> yes
17:52:34  <andythenorth> tbh the argument is lost in the mists of time
17:52:38  <andythenorth> it made sense when we agreed it
17:52:45  <andythenorth> but it's not a religious point
17:52:59  <andythenorth> the issue tracker is working to 0.8.0 currently
17:53:00  <planetmaker> indeed.
17:53:00  <andythenorth> but that could be changed
17:53:14  <planetmaker> well, if it's working for 0.8... let it work for 0.8
17:53:17  * andythenorth suggests this might be bikeshedding :D
17:53:36  <planetmaker> We might meanwhile make a 0.7.0 which doesn't get everything 0.8 will get ;-)
17:53:47  <andythenorth> could be
17:53:49  <Brot6> airportsplus: compile of r148 still failed (#3358) -
17:53:51  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains, foobarstramtracks (Diffsize: 37132), cets (220 warnings), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 12), dutchtrains, rust (Diffsize: 188), ogfx-biggui (Diffsize: 30), swisstowns (Diffsize: 43), dutchroadfurniture (Diffsize: 8632), spanishtowns (Diffsize: 8), frenchtowns (Diffsize: 21), german-townnames (Diffsize: 51), dach
17:53:51  <Brot6> (Diffsize: 10855), belarusiantowns (Diffsize: 64), indonesiantowns (1 warnings) (Diffsize: 29)
17:53:53  <planetmaker> we could branch again ;-)
17:54:00  <andythenorth> I'd like to do something for April which is "bang, here's new stuff"
17:54:11  <andythenorth> rather than "pfss - here's stuff you've seen before"
17:54:19  <planetmaker> Ok
17:54:30  <planetmaker> I suggest that being economies
17:54:34  <planetmaker> And the supply change
17:54:40  <planetmaker> I won't have it done by christmas
17:54:42  <andythenorth> and animation
17:54:44  <planetmaker> but by April I will
17:54:59  <planetmaker> But we could need feedback on what works and how current state is received
17:55:06  <andythenorth> and maybe basic (dumbed down) construction states
17:55:09  <planetmaker> as we changed a lot of under the hood
17:55:17  <planetmaker> thus... would be good
17:56:07  <Yexo> instead of publicing a beta on the forum we could run a more limited test in a .dev game?
17:56:23  <planetmaker> you mean beta of the current state?
17:56:37  <planetmaker> Well. Gamewise not really that many dramatic changes were made so far
17:56:41  <planetmaker> since the last beta
17:56:46  <andythenorth> have we played a game with current trunk?
17:56:51  <planetmaker> no
17:56:57  <andythenorth> could be time soon
17:56:59  <planetmaker> at least I haven't
17:57:14  <andythenorth> I'd like to start 1870, it points up some gameplay problems
17:57:36  <planetmaker> not sure that's an issue we can solve till April
17:57:36  <andythenorth> although my playing time is highly limited right now, and is about to get worse :o
17:57:41  <planetmaker> It's mostly your call, though
17:57:59  <andythenorth> I like to find issues and ticket them
17:58:01  <planetmaker> I'd stick with ~1900, the rest is extra
17:58:19  <planetmaker> animation, economies and supply rework are big changes
17:58:36  <andythenorth> I am not sure we'll complete economies by April?
17:58:38  <planetmaker> actually... rather construction changes than much animation ;-)
17:58:52  <andythenorth> I planned from start how to add construction states
17:58:55  <planetmaker> no, I'd not bet on everything being done from that list for all industries
17:59:08  <planetmaker> but we can get some things going
17:59:08  <andythenorth> there are generic tiles for construction - we can code with those
17:59:17  <andythenorth> then graphics can be added later
17:59:26  <planetmaker> well...
17:59:37  <planetmaker> yes, for some tiles that may work
17:59:47  <andythenorth> more complete snow support I should work on too
17:59:59  <andythenorth> I got baffled by the spritelayouts for snow support
18:00:07  <andythenorth> there are at least two methods in use
18:00:09  <andythenorth> afaik
18:00:35  <andythenorth> also I needed to learn how to fence industries :)
18:00:47  <andythenorth> todo: learn how to code FIRS :P
18:01:05  <andythenorth>
18:02:08  <planetmaker> ah, fencing. Yes. I've good news there
18:02:13  <planetmaker> I asked around a lot for fences
18:02:29  <planetmaker> I've permission to use all of VAST many fences
18:02:36  <andythenorth> :)
18:02:53  <andythenorth> #855 0 seems small - but is actually really irritating to me
18:02:54  <Brot6> andythenorth: #855 is "FIRS Industry Replacement Set - Feature #855: Industries don't randomise production on construction. - #openttdcoop Development Zone"
18:03:23  <planetmaker> yes...
18:05:48  <planetmaker> created a ticket so that fences are not forgotten ;-)
18:06:08  <Brot6> FIRS Industry Replacement Set - Feature #3365 (New): Fences (planetmaker) @
18:06:34  <andythenorth> most of the tickets are graphics
18:06:39  <andythenorth> they won't be done for Christmas :D
18:06:44  <andythenorth> not even with a miracle on earth
18:06:56  <planetmaker> well, fences "just" need being gathered and then coded
18:07:04  <Brot6> FIRS Industry Replacement Set - Feature #3365: Fences (planetmaker) @
18:07:20  <planetmaker> "just" ;-)
18:07:40  <andythenorth> I would quite like to do a sprint on unifying the spritelayouts - and naming them explicitly
18:07:52  <andythenorth> it would help me a lot when adding snow, ground detail, construction and animation
18:08:19  <andythenorth> I have been trying to motivate myself to do it alone, but....meh
18:08:42  <planetmaker> I'm not quite sure how much time I'll have between the years... but if I do have time, my plan is to dedicate some to FIRS
18:08:56  <andythenorth> my plan is to have a newborn baby and a toddler :P
18:10:36  <planetmaker> :-D
18:10:56  <planetmaker> With a bit of luck it will be 24th ;-)
18:13:23  <andythenorth> with a bit of luck it will be sooner than that
18:29:16  *** frosch123 has joined #openttdcoop.devzone
18:35:16  <Brot6> Dutch Trains 2.0 - Feature #3336: Old pax coaches (Voyager1) @
18:42:42  <planetmaker> I'll keep my thumbs crossed :-)
19:03:15  <Brot6> clientpatches: compile of r23512 still failed (#2964) -
19:05:13  <Brot6> serverpatches: compile of r23512 still failed (#2966) -
19:07:19  <Brot6> 32bpp-ez-patches: compile of r23512 still failed (#2446) -
19:59:46  *** JVassie has joined #openttdcoop.devzone
20:48:33  <V453000> planetmaker: how exactly do I use #include in NML please? I just wrote it into my .pnml file like #include "gfx/railhoppers.pnml" but compile says unexpected #
20:48:52  <planetmaker> #include only works with gcc
20:48:56  <planetmaker> nmlc doesn't understand it
20:49:38  <V453000> but how does it work here
20:49:51  <planetmaker> it uses gcc. And on its result nmlc
20:49:53  <V453000> does that mean there should be a file with only #include  ?
20:50:06  <V453000> can I ask what gcc is? :D
20:50:09  <planetmaker> need not. But if you use #include, you must use gcc
20:50:15  <planetmaker> the c/c++ compiler
20:50:28  <V453000> o
20:50:44  <planetmaker> s/the/a/
20:51:06  <V453000> guess I will just copy paste it into the main pnml file for now :D let the mess spread
20:51:27  <planetmaker> V453000: and that's why all these projects have a makefile. You just call 'make' and it does everything needed in sequence
20:51:37  <V453000> I see
20:51:43  <V453000> I am just trying it locally at the moment :)
20:51:47  <planetmaker> but you need a unix-like environment for that. or mingw
20:51:57  <V453000> right :)
20:51:57  <planetmaker> so? Locally that works the same
20:52:04  <V453000> sure but I am on windoze :)
20:52:56  <planetmaker> Yes, you'll need to write everything in one file, if you don't use a pre-processor
20:53:33  <V453000> lets see how crazy will that get :o
20:59:43  <V453000> how could this shout "unrecognized identifier AORE please =(
21:00:36  <V453000> is there supposed to be the cargo label on that spot? taken from
21:00:39  <planetmaker> you haven't declared it in your cargo translation table
21:00:56  <V453000> OH, I forgot that ... I once even thought about it :))
21:00:56  <planetmaker> you can only use cargos found in your CTT
21:00:57  <V453000> thanks
21:01:03  <V453000> yes I know now :)
21:01:29  <V453000> why are the most tedious mistakes always the most stupid ones :-D
21:08:29  <V453000> hm this gets interesting I guess, Parameters of bitmask cannot be greater than 31 ... does that mean I can only have 31 cargoes refittable per wagon? I have 33 there :)
21:10:30  <andythenorth> V453000: prepared to commit yourself to ottd nightlies only?
21:10:35  <andythenorth> there are new properties...
21:10:40  <andythenorth> forget the masks
21:10:52  <andythenorth> also - sounds like you're overlooking classes?
21:11:17  <V453000> I dont care about stable :)
21:11:39  <V453000> and I suppost that by the time the newgrf is complete, there will already be a stable release of this :)
21:11:50  <V453000> I didnt toy with classes yet
21:12:43  <planetmaker> V453000: you want a CTT and then define refittability by refittable_cargo_classes, non_refittable_cargo_classes and for specific cargos via cargo_allow_refit and cargo_disallow_refit
21:12:43  <frosch123> V453000: in that case: do not use "refittable_cargo_types"
21:12:48  <planetmaker> forget refit masks
21:13:35  <andythenorth> pretend you never saw them
21:13:39  <andythenorth> they don't make you happy
21:13:41  <V453000> right :D
21:14:39  <planetmaker> yeah, refit masks lead to hate, hate leads to fight and fight leads to suffering. Or something along those lines ;-)
21:15:20  <V453000> everything leads to beer? :)
21:16:54  <V453000> anyway, so looking at cargo classes, there are CC_BULK for example, right? The shows some things like 0010 Bulk, that is just for nfo, and for me currently that means that it is bulk and therefore i use CC_BULK like on yes? :)
21:17:11  <frosch123> [22:15] <V453000> everything leads to beer? :) <- yeah, but the question is who gets the beer :p
21:17:25  <V453000> frosch123: everyone \o/ :D
21:19:45  <andythenorth> beer = BEER
21:19:54  <andythenorth> I can't remember the classes for that
21:20:21  <V453000> :D :D :D
21:20:46  <planetmaker> andythenorth: oversized
21:20:55  <planetmaker> (for the head next morning :-P )
21:22:14  <frosch123> may not be covered?
21:22:40  <V453000> but be careful, your brain might look like piece goods in the end
21:23:10  <V453000> hm, right, question: When I have rubber as CC_LIQUD, how do I exclude oil and water?
21:24:03  <planetmaker> V453000: explicit cargo refit is done via the last two properties I quoted
21:24:39  <andythenorth> V453000: stay out of the madness
21:25:14  <andythenorth> if you think that way, you're next question becomes "how do I exclude future unknown cargo" :P
21:25:21  <andythenorth> you're / your
21:25:34  <planetmaker> V453000: only use classes by the type of thing you want to transport
21:25:59  <planetmaker> use the explicit cargo types for what you in detail want to transport of the cargos you know and those which you don't want there
21:30:05  <V453000> so I best use CC_LIQUID and use non-refittable cargo types of oil and water, correct?
21:30:22  <V453000> to make the rubber cargo classed to work with ogfx+ industries for example
21:31:11  <planetmaker> V453000: you need to learn to distinguish cargo classes and cargo types
21:31:21  <planetmaker> that's crucial. For any conversation on that topic
21:31:36  <V453000> I hoped I do
21:31:47  <planetmaker> class = general category
21:31:51  <V453000> yes
21:31:53  <planetmaker> type = one specific cargo
21:31:59  <V453000> understood
21:31:59  <planetmaker> there's no "rubber class"
21:32:12  <V453000> no but CC_LIQUID is the only class where rubber belongs
21:32:31  <planetmaker> stupid. but might be true.
21:33:13  <V453000> yarr. So when I have my hopper wagon and want it to transport rubber, what do I do? While I do not want it to transport other cargoes which belong to CC_LIQUID like oil or water?
21:33:39  <andythenorth> enable rubber as a cargo
21:33:43  <andythenorth> but not the class
21:34:01  <andythenorth> using prop number...(?)
21:34:03  * andythenorth looks
21:34:04  <planetmaker> hopper is bulk
21:34:04  <V453000> refittable_cargo_types:       bitmask(RUBR);
21:34:10  <V453000> like this andy?
21:34:17  <planetmaker> thus enable bulk class.
21:34:26  <V453000> I did
21:34:27  <planetmaker> don't use that property
21:34:40  <planetmaker> it leads to suffering
21:34:46  <V453000> that is what confuses me
21:34:50  <andythenorth> I don't know how it's done in nml, but ignore that prop :)
21:34:53  <planetmaker> ignore that one completely
21:34:54  <andythenorth> it's newly replaced
21:35:06  <planetmaker> it's complicated and... nasty
21:35:08  <V453000> so cargo_types never ever anywhere
21:35:09  <andythenorth> following 8 days of painful disucussing
21:35:12  <V453000> I understand that
21:35:39  <planetmaker> 22:12 planetmaker: V453000: you want a CTT and then define refittability by refittable_cargo_classes, non_refittable_cargo_classes and for specific cargos via cargo_allow_refit and cargo_disallow_refit
21:35:56  <V453000> oh
21:35:59  <V453000> those 1.2 thingies :)
21:36:02  <andythenorth> V453000 it's not easy first time around
21:36:25  <V453000> andythenorth: I know, I expected the cargoes etc. to be hard :)
21:36:48  <andythenorth> I would go like this: first set the classes that apply to the vehicle
21:36:59  <andythenorth> this would support future unknown cargos
21:37:17  <andythenorth> then add labels for any cargos you want to include that aren't covered by the classes
21:37:34  <V453000> yes I understand that, I just thought that the cargo_allow_refit is only for the autorefit thing
21:37:35  <andythenorth> then if you find you have cargos you don't want refitting, add labels for excluding them
21:37:53  <planetmaker> no, not at all
21:38:06  <andythenorth> interesting conclusion though
21:38:13  * andythenorth can see how that happened
21:38:15  <V453000> right :D lets see
21:38:17  <planetmaker> autorefit is best defined via the related callback
21:39:35  <V453000> I will leave autorefit for later for now I think :p
21:40:25  <planetmaker> yes. not a good thing to start wiht
21:42:30  <V453000> hm, minor syntax error, what apprentices do I put there? cargo_allow_refit			  RUBR; [RUBR] shouts wrong, (RUBR) as well, and {RUBR} too
21:44:33  <V453000> apprentices = parenthesis :D engrish
21:47:53  <planetmaker> are you missing a colon?
21:48:17  <planetmaker> cargo_allow_refit: [RUBR, BLAH, BLUH]
21:48:31  <planetmaker> iirc
21:48:37  <planetmaker> and I'm missing a semicolon
21:49:13  <V453000> I am probably super stupid, blind, or something
21:49:16  <V453000> there wasnt :
21:49:18  <V453000> .. :d
21:50:02  <V453000> works! =)
21:50:13  <V453000> thank you guys, I put your patience to a real test :P
21:50:37  <planetmaker> it's alright
21:51:36  <V453000> no way, it works :D
21:51:45  <V453000> I even got the spritegroups right :D
22:07:29  <V453000> hm that is interesting, andythenorth: bulk includes scrap metal, doesnt it? I have bulk but scrap metal isnt there. I even added SCMT and it does not work somehow :o
22:07:56  <andythenorth> don't go there :P
22:07:57  <andythenorth> that's where it all started :P
22:08:15  <V453000> hell, it cant get much worse with me :P
22:08:23  <andythenorth> V453000: which FIRS version?
22:08:34  <V453000> r2604
22:08:38  <V453000> probably a bit outdated
22:08:48  <andythenorth> try newere
22:08:51  <V453000> okay
22:09:07  <andythenorth> SCMT doesn't exist in r2604 probably
22:09:32  <V453000> oh :) ..
22:09:41  <V453000> it sure does in the latest, I looked in junkyard code
22:10:05  <andythenorth> it was SCRP until some recent version
22:10:13  <andythenorth> the history of that change is full of stupidity
22:10:55  <V453000> I read that in the bottom of the cargoes page
22:11:39  <V453000> superb :)
22:11:41  <V453000> works now
22:19:23  <planetmaker> good night
22:19:29  <andythenorth> good night too
22:19:31  *** andythenorth has quit IRC
22:44:19  <Yexo> <- spam on the devzone.
22:44:39  <Yexo> perhaps we could get irc notifications about comments that are added to news messages?
22:54:51  <Yexo> <- locked those 5 users for posting spam to news messages
22:55:18  <Yexo> Ammler: irc notification of comments to news would help catch this a lot sooner
22:58:09  *** frosch123 has quit IRC
23:28:13  *** JVassie has quit IRC
23:33:14  <Brot6> NewGRF Meta Language - Revision 1763:63fd519f8d1a: Fix: arguments to sprite layouts were broken (yexo) @
23:33:17  *** ODM has quit IRC

Powered by YARRSTE version: svn-trunk