Log for #openttdcoop.devzone on 13th October 2010:
Times are UTC Toggle Colours
00:09:41  *** KenjiE20 has quit IRC
00:42:24  *** fanioz has joined #openttdcoop.devzone
09:45:43  *** Webster has joined #openttdcoop.devzone
09:50:38  *** ODM has quit IRC
09:52:33  <Brot6> OpenGFX+ Trains - Revision 66:3516ce5ae113: Change: Add cargo-specific refit capacities to flatbe... (planetmaker) @
10:14:25  <Brot6> OpenGFX+ Trains - Revision 67:4eb5b8ecbe11: Change: Add cargo-specific refit capacities to piece ... (planetmaker) @
10:17:38  <planetmaker> wooo. My first callbacks defined and used :-)
10:52:24  *** KenjiE20 has joined #openttdcoop.devzone
11:09:27  <Brot6> FIRS Industry Replacement Set - Revision 1478:9acf9fc67c81: Fix: Lime Kiln graphics broken (actio... (andythenorth) @
11:09:27  <Brot6> FIRS Industry Replacement Set - Bug #1637 (Confirmed): Lime kiln graphics (planetmaker) @
12:01:28  <Brot6> FIRS Industry Replacement Set - Bug #1637 (Closed): Lime kiln graphics (planetmaker) @
12:01:28  <Brot6> FIRS Industry Replacement Set - Bug #1637 (Closed): Lime kiln graphics (planetmaker) @
12:35:42  <Brot6> FIRS Industry Replacement Set - Revision 1479:8ea93d72ab75: Change: update changelog (andythenorth) @
12:35:42  <Brot6> FIRS Industry Replacement Set - Revision 1480:e355d3e0c22d: Added tag 0.5.2 for changeset 8ea93d7... (andythenorth) @
12:36:07  <Brot6> firs: update from 0.5.1 to 0.5.2 done (1 errors) -
13:31:10  *** avdg has joined #openttdcoop.devzone
14:18:44  *** DJNekkid has joined #openttdcoop.devzone
14:19:15  <DJNekkid> hi DJNekkid :D
14:40:50  *** KenjiE20 has quit IRC
14:46:46  *** Levi has joined #openttdcoop.devzone
14:52:09  *** KenjiE20 has joined #openttdcoop.devzone
15:07:01  *** Levi has quit IRC
15:14:31  <Hirundo> planetmaker: "Otherwise it's save and recommended to disable the unneeded default wagons (default setting)." <- s/save/safe ?
15:15:34  <planetmaker> yes
15:15:35  *** V453000 is now known as Guest2603
15:15:40  <planetmaker> thanks :-)
15:17:04  <Hirundo> is the piece goods wagon a simple closed wagon?
15:17:22  <planetmaker> that's a copy of the goods wagon basically, yes
15:17:40  <planetmaker> I'm considering to skip the "covered" part
15:17:49  <planetmaker> it's a bit stupid
15:18:19  <planetmaker> rather it makes sense to add a covered bulk wagon
15:21:46  *** frosch123 has joined #openttdcoop.devzone
15:24:26  <planetmaker> Hirundo, is there a way in NML to do something like
15:25:24  <planetmaker> for i=0,45 do item(FEAT_TRAINS... i) { property { climates_available: CLIMATE_ARCTIC } } endfor
15:27:04  <Hirundo> param[x] = 0; while (param[x] < 45) {   item(FEAT_TRAINS... param[x]) { property { climates_available: CLIMATE_ARCTIC } } param[x] = param[x] + 1; }
15:27:25  <planetmaker> that works?
15:27:43  <Hirundo> there's only one way to find out :)
15:27:48  <planetmaker> :-D
15:27:58  <planetmaker> let's see
15:30:44  <planetmaker> hm, there's a problem: the FEAT_TRAINS requires an identifier...
15:30:55  <planetmaker> But I guess I could work through that using gcc
15:31:12  <Hirundo> does 'foo' as identifier hurt?
15:31:28  <planetmaker> no. But it needs x=0,45 different foos
15:31:39  <planetmaker> as a function of param[x]
15:31:40  <Hirundo> does it?
15:31:48  <planetmaker> each item needs a unique id
15:32:01  <Hirundo> does NML complain about it?
15:32:01  <planetmaker> or I re-define the same thing. But I need different ones
15:32:20  <planetmaker> usually it complains about double IDs. At least for varaction2
15:32:24  <planetmaker> not sure about action0
15:32:36  <Hirundo> I'll see what happens :)
15:32:40  * Hirundo tests
15:34:50  <Hirundo> I guess, NML does not (yet) eat variable ids
15:35:39  <planetmaker> something for >0.1 as well :-)
15:37:12  <Hirundo> Indeed, implementation is far from trivial
15:37:27  <Brot6> 2cc train set - Revision 616:d8363a19396e: Fix: Minor errors in r615, close #1538 (DJNekkid) @
15:37:27  <Brot6> 2cc train set - Revision 617:72a84570f1ea: Fix: Updated the Taurus GFX provided by Voyager1, clos... (DJNekkid) @
15:37:27  <Brot6> 2cc train set - Bug #1538 (Closed): r615 new engines missing or wrong (DJNekkid) @
15:37:28  <Brot6> 2cc train set - Feature #1604 (Closed): Corrected Taurus graphics (DJNekkid) @
15:43:17  <Yexo> planetmaker: did you test that while loop? nml compiles it fine, so it should work
15:44:15  <planetmaker> not yet
15:44:32  <planetmaker> but as I said, I need it to work on a different ID each
15:45:06  <Yexo> oh, nvm
15:45:23  <Yexo> at some point in the past that worked, now nml needs a constant for the id
15:45:34  <planetmaker> he
15:57:23  <Brot6> 2cc train set - Revision 618:ff8fca1ae516: Add: GWR Class 4900, Close #1450 (DJNekkid) @
15:57:23  <Brot6> 2cc train set - Feature #1450 (Closed): Harry Potter's Hogwarts Express (DJNekkid) @
15:57:58  *** ODM has joined #openttdcoop.devzone
15:58:16  *** thgergo has joined #openttdcoop.devzone
16:13:03  <Brot6> 2cc train set - Feature #1638 (New): EF500 (Voyager1) @
16:20:12  <Brot6> 2cctrainset: update from r615 to r618 done (7 errors) -
16:21:07  <Brot6> firs: update from r1473 to r1480 done (1 errors) -
16:21:55  <Brot6> ogfx-trains: update from r62 to r67 done (1 errors) -
16:22:12  <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r39), ai-admiralai (r68), airportsplus (r63), basecosts (r22), belarusiantowns (r7), comic-houses (r71), fish (r394), frenchtowns (r4), grfcodec (r772), heqs (r380), indonesiantowns (r37), metrotrackset (r56), newgrf_makefile (r219), nml (r837), nutracks (r117), ogfx-trees (r41), opengfx (r550), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r45), swedishrails (r182),
16:22:12  <Brot6> swisstowns (r20), transrapidtrackset (r15), ttdviewer (r26), ttrs (r23), worldairlinersset (r664)
16:26:10  *** andythenorth_ has joined #openttdcoop.devzone
16:27:21  <andythenorth_> hi hi
16:27:37  <planetmaker> ho
16:30:37  *** avdg has quit IRC
16:31:01  <andythenorth_> Hirundo: I can't replicate #1636
16:31:02  <Brot6> andythenorth_: Hirundo: #1636 is "FIRS Industry Replacement Set - Bug #1636: bug in brick works text? - #openttdcoop Development Zone"
16:31:05  <andythenorth_> where am I looking?
16:31:22  <Hirundo> click on a brick works
16:32:00  *** avdg has joined #openttdcoop.devzone
16:32:33  *** avdg has quit IRC
16:33:36  *** avdg has joined #openttdcoop.devzone
16:42:02  <Hirundo> andythenorth_: suggestion: Let the starting production of industries vary somewhat, but generally increasing with time
16:42:57  <Hirundo> Currently there's nothing that can match the profit of >100t coal/iron/... mines when playing before 1900
16:43:41  <Hirundo> It'd be nice if starting output of a mine would increase from (average) 50 to 120t between 1850 and 2000
16:46:04  <andythenorth_> so newly built industries have (on average) higher output than older industry of same type?
16:50:53  <Brot6> FIRS Industry Replacement Set - Revision 1481:9eb21c11d11e: Fix: Brickworks had wrong production ... (andythenorth) @
16:50:54  <Brot6> FIRS Industry Replacement Set - Bug #1636 (Closed): bug in brick works text? (andythenorth) @
16:52:19  <Hirundo> yes
16:53:16  <andythenorth_> interesting idea
16:53:32  <andythenorth_> I need to deal with setting initial production for industry anyway
16:53:40  <andythenorth_> adjusting it by date might be possible
16:53:59  <planetmaker> seems like a very good idea indeed
16:54:01  <Hirundo> older industries (should) have already been boosted using supplies
16:54:18  <planetmaker> More interesting might indeed be, though, to vary the initial production by a factor of two or four or so
16:54:45  <andythenorth_> I think there's a ticket for that somewhere already
16:54:51  <Hirundo> why not do both ?
16:54:54  <andythenorth_> frosch told me how it can be done
16:55:13  <planetmaker> Hirundo, I didn't argue against both :-) Just for priorities :-)
16:55:23  <Brot6> FIRS Industry Replacement Set - Feature #1639 (New): Initial production could vary by date? (andythenorth) @
16:57:36  <Hirundo> initial_production = (prod_min + (_date - date_min) * (prod_max - prod_min) / (date_max - date_min)) * (GB(Random(), 0, 8) + 128) / 255;
16:59:23  *** fanioz has joined #openttdcoop.devzone
16:59:35  <Hirundo> hmpf, that needs a clamp on _date somewhere
16:59:43  <andythenorth_> what would date min and date max be? :P
16:59:55  <andythenorth_> how do I do that without imposing a starting date on players?
17:00:04  <andythenorth_> that's my only real concern with this
17:00:37  <planetmaker> min(date-date_min,0) and max(date_max-date,0) is needed, though
17:00:51  <planetmaker> min(date-date_min,1) and max(date_max-date,1) actually
17:01:16  <andythenorth_> if you figure it out, add comments to the ticket ;)
17:01:23  <andythenorth_> I'm not thinking about new FIRS code at the moment
17:01:29  <andythenorth_> I'm going to fix bugs and have a break
17:03:44  <Brot6> FIRS Industry Replacement Set - Feature #1639: Initial production could vary by date? (Hirundo) @
17:07:38  * Hirundo is exercising (alert: Dutchism) Study Evading Behaviour
17:08:46  <planetmaker> eh?
17:10:24  <Hirundo> doing other 'useful' stuff instead of studying
17:11:29  <Hirundo> <- I believe this is the actual English term
17:11:30  <Webster> Title: Procrastination - Wikipedia, the free encyclopedia (at
17:11:50  <planetmaker> ah. Procrastination is what you look for / exercise, Hirundo ;-)
17:38:48  *** andythenorth_ has quit IRC
18:01:15  *** fanioz has quit IRC
18:09:20  *** andythenorth_ has joined #openttdcoop.devzone
18:09:29  <Brot6> 32bpp-ez-patches: update from r20918 to r20920 done -
18:11:19  *** Levi has joined #openttdcoop.devzone
18:18:17  <Brot6> clientpatches: update from r20916 to r20920 done -
18:22:11  <andythenorth_> planetmaker: how should people provide FIRS translations (forum question)
18:22:13  <andythenorth_> ?
18:22:31  <planetmaker> I'd attach the English file
18:23:01  <andythenorth_> is it worth having a thread for FIRS translations?
18:23:08  <andythenorth_> would keep it all together
18:24:40  <planetmaker> I'd keep it in the FIRS development thread
18:25:11  <planetmaker> just maybe amend the title of the thread to like "FIRS development & translations" and alike
18:26:38  <Brot6> serverpatches: update from h5ed234b4 to h3c9c9690 done (2 errors) -
18:34:32  * frosch123 wonders how he became "developer" of opengfx
18:34:54  <andythenorth_> unlucky
18:35:08  <andythenorth_> now you have responsibility :P
18:35:41  <frosch123> i am not manager :)
18:35:54  <andythenorth_> ha
18:36:03  <andythenorth_> I owe you a test of that RV patch still :(
18:36:32  <frosch123> np, if i can trade that vs. fields :p
18:36:57  <andythenorth_> maybe we don't need fields
18:37:01  <andythenorth_> then you don't have to code them
18:37:07  <andythenorth_> and I don't have to draw and code them
18:38:01  <andythenorth_> maybe it's a pony too far :)
18:38:11  <Hirundo> What about FS4124?
18:42:42  <frosch123> hehe, another project :) somewhere we got stuck between: do we want to add two ship classes, or should there be newgrf-definable livery classes. and though the latter is way better, it is so much work, that there should be some 1) which is extensible fluently towards 2)
18:47:56  <andythenorth_> I was happy just adding a couple of classes
18:48:08  <andythenorth_> I had a solution to 'diesel ships'
18:48:27  <andythenorth_> ships are Sailing Ships, Steam Ships (SS), or Motor Vessels (MV)
18:48:30  <andythenorth_> or "Other"
18:48:40  <andythenorth_> and if it's other, pot luck
18:49:03  <andythenorth_> if you extend ship liveries to be newgrf definable, you'll find that train people want the same
18:49:28  <andythenorth_> so they can have livery for grain, livery for bricks, livery for dogs and cats
18:49:34  <andythenorth_> it's dumb and pointless
18:49:54  <andythenorth_> livery classes (not liveries)
18:51:22  <Hirundo> newgrf-definable classes are much work for very little benefit, IMHO
18:52:00  <andythenorth_> just give me four classes, I'm happy
18:52:05  <andythenorth_> someone wants more, let them submit a patch
18:52:57  <Hirundo> fourth = 'other' ?
18:53:04  <andythenorth_> yup
18:53:09  <andythenorth_> or is that a bit lame?
18:53:15  <Hirundo> What ships would be in that class? Example?
18:53:27  <andythenorth_> nuclear icebreaker?
18:53:29  <andythenorth_> hovercraft?
18:53:34  <andythenorth_> anything I specify as newgrf author
18:53:36  <frosch123> Hirundo: yes, but adding sailing and steam feels so arbitrary :) so if it would be extensible for some livery translation table with some defaults...
18:53:54  <Rubidium> don't forget the nuclear wessels
18:54:09  <frosch123> why do you concentrate on the engine?
18:54:12  <andythenorth_> wessels is how my indian in-laws would say it
18:54:17  <frosch123> why not small/large ships
18:54:21  <andythenorth_> frosch123: I'm going by real life
18:54:26  <andythenorth_> no that's wrong actually
18:54:31  <frosch123> containerships vs. small boats
18:54:44  <andythenorth_> basically, ship colours changed at some point in history
18:54:58  <andythenorth_> I don't know if it was paint technology, or visibility at sea, but they stopped being black
18:55:02  <Hirundo> You can always set your own colour maps via callback
18:55:13  <andythenorth_> not in a sane way with 2CC
18:55:31  <frosch123> that wouild be fixed by the grf for a start :)
18:56:54  <Hirundo> If you want all your ships to be black before 1850, or using (cc + 1) mod 16 as colour, that's possible without too much work.
19:02:26  <andythenorth_> I want to offer players option to have some ships black, and some ships coloured
19:02:31  <andythenorth_> it should be up to player really
19:02:55  <planetmaker> refit?
19:03:17  <andythenorth_> AV8 stye?
19:03:21  <andythenorth_> could be
19:03:32  <planetmaker> via VEH_CB_COLOUR_MAPPING
19:04:15  <andythenorth_> I'm not sure I like complicated refit menus
19:05:12  <planetmaker> andythenorth_, then a refit for 'black' and '2CC'
19:05:35  <andythenorth_> maybe
19:05:48  <planetmaker> though I don't quite see the need for 'black' then. a player could probably fine-tune the 2CC settings that they look just that way
19:06:13  <andythenorth_> but only really useful if there are ship classes?
19:07:00  <planetmaker> hm. maybe
19:07:10  <andythenorth_> why do trains have steam / diesel colour classes?
19:07:12  <planetmaker> and if they could have different settings there?
19:07:22  <planetmaker> I guess: because they can
19:07:35  <andythenorth_> just hanging off the existing type for smoke effects etc?
19:08:31  <planetmaker> STEAM | DIESEL | ELECTRIC | MONORAIL | MAGLEV <-- probably, yes
19:09:35  <Hirundo> I intend(ed) to write the smoke effects part as well, I just didn't get to it yet
19:09:43  <andythenorth_> :)
19:10:15  <frosch123> planetmaker: thanks, you remind me about the main point of livery classes
19:10:34  <frosch123> there are monorail and maglev liveries, which just do not make any sense since new railtypes
19:11:13  <planetmaker> hm... don't they?
19:11:30  <Hirundo> they don't from a coding perspective
19:11:44  <frosch123> you want "metro" livery and stuff
19:12:29  <frosch123> or high speed train livery
19:13:18  <frosch123> i.e. liveries are a combination of tracktype, traktion type, cargos and other stuff
19:14:01  <planetmaker> yes. They should become parts of the re-designed group feature ;-)
19:14:41  <frosch123> :p
19:15:11  <planetmaker> so, yes, you convinced me. The arguments are quite valid
19:17:38  <planetmaker> there's visual effect, engine class, cost_base, running_cost_base, track_type...
19:17:59  <planetmaker> all use differently steam, diesel, ...
19:22:00  <Hirundo> perhaps, CB 10 support for RVs/ships is more useful than any number of  'livery classes'
19:23:36  <andythenorth_> equally for ships, livery could be as well based on "RIVER" "CANAL" "COASTAL" "OCEAN"
19:23:52  <andythenorth_> it makes as much sense as the power type
19:23:59  <andythenorth_> which I guess means newgrf-defined labels
19:24:05  <andythenorth_> but it could be TMWFTLB
19:24:15  <andythenorth_> and I can forsee some horrible gameplay effects
19:24:23  <frosch123> livery and visual effect should definitely get defined separetly :)
19:24:29  <planetmaker> yep
19:24:30  <Hirundo> make a 3D matrix containing pax/freight, ship type and engine type and the number of combinations gets pretty large
19:24:52  <frosch123> Hirundo: just store those which have at least one vehicle
19:24:58  <frosch123> the gui does that now
19:25:04  <andythenorth_> if we have arbitrary labels, it means newgrf authors can make horribly long GUI menus
19:25:08  <andythenorth_> and they will
19:25:16  <andythenorth_> and players will request it, incessantly
19:26:22  <andythenorth_> they'll want to be able to set colour for every kind of subtype and power type and every other thing
19:26:29  <andythenorth_> it's cargo labels ^ 10
19:26:42  <Hirundo> i.e. tie the colour stuff to vehicle groups instead
19:26:42  <andythenorth_> but hey ho :)
19:27:02  <andythenorth_> colour stuff by group makes more sense
19:27:07  <andythenorth_> especially in single player
19:50:33  *** Guest2603 is now known as V453000
20:14:36  *** Levi has quit IRC
20:59:32  <planetmaker> Hirundo: Yexo can you give me a hint how I could use the vehicle properties callback?
20:59:53  <Hirundo> CB 36? that's a bitch :)
20:59:54  <planetmaker> I have no problem using the others, but that seems to require a parameter...
21:00:19  <Hirundo> you'll have to check for the callback_param1 being equal to the nfo property number you want to set
21:00:47  <planetmaker> How do I give it a parameter?
21:01:48  <planetmaker> switch (FEAT_TRAINS, SELF, piecegoods_wagon_cb_property_switch(0xWHATEVER), cargo_type_in_veh) {
21:01:55  <planetmaker> with WHATEVER=newgrf property?
21:04:09  <Hirundo> parameter is just another variable that can be read
21:04:45  <planetmaker> uh...
21:05:21  <Hirundo> variable = 'callback_param1' (IIRC)
21:05:30  <planetmaker> switch (FEAT_TRAINS, SELF, piecegoods_wagon_cb_property_switch, 0x10) { property_weight: weight_switch ... }
21:06:12  <planetmaker> I'll check. But I need it... or I can't simulate the original wagons ;-)
21:06:54  <Hirundo> s/0x10/callback_param1 (or var[0x10])
21:07:11  <Hirundo> planetmaker: what part of the wagons can't be done using action0?
21:07:18  <planetmaker> weight
21:07:25  <planetmaker> needs to differ by cargo
21:07:47  <planetmaker> as the capacity
21:07:50  <planetmaker> but that's done
21:07:57  <Hirundo> You want the empty weight to be equal to the original empty weight?
21:08:02  <planetmaker> yes
21:08:15  <planetmaker> and I want this set to be a demonstation set, too :-)
21:08:26  <planetmaker> So... stretching the limits is some part of the endeavour, too
21:08:52  <planetmaker> like swedishrails for railtypes, this can then show what vehicles can do
21:09:00  <planetmaker> and trains are the most complicated ones
21:09:40  <planetmaker> like... I should make it a ticket: weight works wrongly with units
21:09:53  <planetmaker> like 4x if tons is specified
21:10:02  <planetmaker> or 3x
21:11:16  <Brot6> NewGRF Meta Language - Bug #1640 (New): wagon weight wrongly with units (planetmaker) @
21:11:40  <Hirundo> you mean, train weight or powered wagon weight?
21:11:55  <planetmaker> weight
21:11:59  <planetmaker> w/o power
21:13:14  *** frosch123 has quit IRC
21:14:22  <Hirundo> I see, both trains and RVs have weight in different units
21:15:42  *** andythenorth_ has quit IRC
21:15:54  <planetmaker> yes, they do
21:16:11  <planetmaker> it seems to use the RV thing then. Those have more fine-grain control
21:16:24  <planetmaker> now that you mention that :-)
21:17:24  *** andythenorth_ has joined #openttdcoop.devzone
21:17:27  <Hirundo> I have a fix, ready, running regression now
21:17:35  <planetmaker> k
21:18:48  <Hirundo> pushed, please test
21:18:59  <Brot6> NewGRF Meta Language - Revision 838:0458e1364c80: Fix: Weight units for trains were wrong. (Hirundo) @
21:20:12  *** andythenorth_ has quit IRC
21:22:06  <planetmaker> hm...
21:23:26  <planetmaker> it seems that now always the wrong weight is used
21:23:31  <planetmaker> whether I use units or not
21:23:39  <planetmaker> (x-1)*4
21:23:43  <planetmaker> instead of x
21:23:54  <planetmaker> units = tons
21:25:03  <planetmaker> hold on...
21:25:20  <Hirundo> you're sure? I stripped out all the conversion factors that should affect train weight
21:25:28  <planetmaker> no, I'm not
21:25:43  <planetmaker> it just didn't change when it must have had changed
21:27:04  <planetmaker> :-O the vehicle property weight callback tipped me off ;-)
21:27:10  <planetmaker> it works
21:28:27  <planetmaker> now... it works inconsistent wrt the refit callback: that is called only for refit, but not for the first refittable cargo...
21:29:37  <planetmaker> looks good, Hirundo
21:29:51  <planetmaker> thanks :-)
21:29:59  <planetmaker> also for the hint with the CB :-)
21:30:06  <planetmaker> especially the CB variable
21:30:21  <planetmaker> probably it needs mentioning somewhere in the vehicle vars... at least a link
21:36:01  <planetmaker> juhu :-)
21:36:39  <planetmaker> But it will in > 0.1 need some more abstraction. And I ponder whether it'll be sensible to introduce some constants for the properties which can be defined by the CB. Sensible?
21:37:07  <planetmaker> like PROPERTY_TRAIN_WEIGHT 0x16
21:49:12  *** ODM has quit IRC
21:50:58  <Hirundo>  w.r.t. the refit callback: can't help you here
21:51:11  <Hirundo> implementing both CB36-> capacity and CB15 may help
21:51:37  <Hirundo> planetmaker: can #1640 be considered fixed?
21:51:37  <Brot6> Hirundo: planetmaker: #1640 is "NewGRF Meta Language - Bug #1640: wagon weight wrongly with units - #openttdcoop Development Zone"
21:51:55  <planetmaker> I think so
21:52:13  <planetmaker> adding tons didn't make a difference for trains now
21:52:19  <planetmaker> ton. not tons
21:52:28  <planetmaker> we might make it an alias, though
21:52:35  <Hirundo> w.r.t. abstraction: #1555 :)
21:52:35  <Brot6> Hirundo: #1555 is "NewGRF Meta Language - Feature Request #1555: Explicitly define callbacks - #openttdcoop Development Zone"
21:53:17  <planetmaker> oh yes :-)
21:53:49  <planetmaker> the graphics block might then be wrongly called, though
21:53:54  <planetmaker> s/called/named/
21:54:57  <Hirundo> I pondered splitting it in a graphics and callbacks block, but that opens up a new can of works
21:55:04  <Hirundo> s/works/worms
21:55:22  <planetmaker> both actually :-P
21:55:30  <Brot6> NewGRF Meta Language - Bug #1640 (Closed): wagon weight wrongly with units (planetmaker) @
21:55:31  <Brot6> NewGRF Meta Language - Bug #1640 (Closed): wagon weight wrongly with units (Hirundo) @
21:56:23  <Hirundo> I'm open to suggestions to rename 'graphics' to something else
21:56:47  <planetmaker> I don't have a good one yet.
21:58:17  <planetmaker> what would be the backdraw of using a separate thing like callbacks?
21:58:26  <planetmaker> hm... no
22:00:09  <planetmaker> maybe behaviour instead of graphics?
22:05:09  <planetmaker> lol. The most heavy version of the flatbed wagon is... behold: the bubble wagon. Usual weight is 16t or 18t. But the bubble wagon version weighs 21t.
22:17:55  <Brot6> OpenGFX+ Trains - Revision 68:3c294c457550: Change: Add default cargo-dependent wagon weights (planetmaker) @
22:20:18  <planetmaker> even if it's not perfect in this aspect, it's MUCH easier than NFO for this :-)
22:20:40  <planetmaker> Not sure the same can be done in 1800 lines in nfo either :-)
22:27:22  <Hirundo> planetmaker: the problem arises when graphics are defined at location A, while callbacks are (perhaps conditionally) defined at location B
22:27:52  <planetmaker> hm, yes
22:28:00  <planetmaker> something I actually do already ;-)
22:28:10  <planetmaker> or nearly
22:28:31  <Hirundo> Currently, you define a single (atomic) graphics block as 'entry point'
22:28:33  <planetmaker> like maglev using its own chain. but using fallback the railwagons
22:29:35  <planetmaker> hm, yes; the problem would be how to sort that
22:29:50  <Hirundo> action 3 can't be split :)
22:29:58  <planetmaker> :-)
22:31:47  <planetmaker> hm: is that to be that way:
22:32:04  <planetmaker> CB 0x36 sets the property always, for all cargos
22:32:29  <planetmaker> CB refit capacity sets the property for all cargos except the first refittable (=default cargo)
22:32:47  <planetmaker> it's a bit annoying actually, the latter
22:33:17  <planetmaker> or would you consider that behaviour an OpenTTD bug?
22:33:36  <Hirundo> It's a (mis)feature
22:39:35  <planetmaker> well... I'll open an issue nevertheless
22:40:47  <Hirundo> an NML issue?
22:40:59  <planetmaker> I don't think
22:41:04  <planetmaker> I reported to OpenTTD
22:41:27  <Hirundo> It requires (the infamous) grf version 8 to change, I fear
22:41:37  <planetmaker> do you think so?
22:41:50  <planetmaker> what would break to change the CB 0x15 behaviour to work always?
22:42:30  <Hirundo> nvm
22:42:35  <planetmaker> I really don't see where it would make a difference, but I miss it probably :-)
22:44:06  <Hirundo> the scary word is 'capacity multipliers' in this case
22:44:39  <Hirundo> their handling differs between CB 36 and CB 15 :)
22:45:46  <Hirundo> you'd have to test with MB's/pikka's/oztrans' grfs to be sure
22:46:28  <Hirundo> esp. DBset and Canset may have quirks, they abuse nfo quirks mere mortals don't even know about
22:46:52  <planetmaker> :-)
22:46:57  <planetmaker> indeed they do
22:47:13  <planetmaker> capacity multiplier... that's the cargo weight?
22:48:17  <michi_cc>
22:49:11  <planetmaker> o_O
22:49:13  <planetmaker> thanks
22:50:50  <michi_cc> and probably (no idea how current they are, you'd have to ask frosch about the details)
22:51:47  <planetmaker> the cargo magic is quite current, not older than a month
22:52:35  <Hirundo> planetmaker: <- your versioning idea got implemented :)
22:52:37  <Webster> Title: Transport Tycoon Forums • View topic - Heading for grf version 8 (at
22:53:40  <planetmaker> not quite
22:54:53  <planetmaker> well. versions yes. but not yet minimum compatible version ;-)
22:57:19  <planetmaker> but indeed, versions are very helpful :-)
22:59:32  <Hirundo> goodnight :)
23:00:34  <planetmaker> good night Hirundo
23:07:06  *** avdg has quit IRC
23:15:25  <Brot6> OpenGFX+ Trains - Revision 69:c4aae11c87ed: Change: Adjust capacities of tank wagon to defaults (planetmaker) @
23:57:53  *** KenjiE20 has quit IRC

Powered by YARRSTE version: svn-trunk