Digitalfox NML Questions!

[Eddi]

yes, it's very much a decision of personal taste, and i like the multiple-ID approach because it allows the individual vehicle parts to be very self-contained in which data they check. a wagon doesn't have to magically turn into a steering wagon just because it happens to be at the end of the train.

furthermore, i can then go ahead and generate stuff. i can generate a bunch of wagons from table entries, and i also can generate the articulated parts callback from a regular(-ish) expression. these two parts are suddenly independent from each other. i can even use the same wagon in different chains, depending which front engine is purchased. so i can make chains of length 3, 5, 8 and 13, by having 4 front engines, 1 middle wagon and 1 end wagon. just by writing "abc", "a3bc", "a6bc" and "a11bc" into the table.

[FooBar]

I do not want to know how the Dutch Trainset code would need to look like if it would work with different IDs for the articulated parts.

A bit like this: http://dev.openttdcoop.org/projects/dut ... phics.pnml

[Digitalfox]

Thanks for the discussion guys! I learn a lot

So you can have more callbacks using only 1 item or you can have less callbacks and multiple items for a tram.

But I'm curious, when you have a thousand trams running, would in theory be any difference in CPU usage by choosing one method over the other? Or let me put it this way, is one method more heavy in CPU usage than the other on the long run? Or it doesn't matter?

[FooBar]

But I'm curious, when you have a thousand trams running, would in theory be any difference in CPU usage by choosing one method over the other?

Less switch blocks is better, but from a recent discussion I've gathered that you'll only notice a big improvement between "zero" and "one or more" switch blocks. Since you cannot make anything fancy without switch blocks, I'd not worry too much about it.

[Digitalfox]

Thanks Foobar!

So I'm now recreating LV4/5 in NML, after is done I'll send it to George!

But I want to make sure I'm doing right from the start.

My code:

Code: Select all

//---------------------------------------------------------------------------------------//
// Start Opel Blitz 3.6 Box van
//---------------------------------------------------------------------------------------//

//Purchase Sprites
spriteset(spriteset_purchase_opel_blitz_3_6, "graphics/lv4.png") 
{
	[ 34, 200, 26, 16, -13, -10 ]
}

//Mail Sprites
spriteset(spriteset_mail_opel_blitz_3_6, "graphics/lv4.png") 
{
	[ 594,  200,   10,   26,   -4,  -14]
	[ 610,  200,   23,   24,  -15,  -12]
	[ 642,  200,   26,   16,  -13,  -11]
	[ 674,  200,   23,   24,   -8,  -13]
	[ 706,  200,   10,   26,   -4,  -14]
	[ 722,  200,   23,   24,  -13,  -13]
	[ 754,  200,   26,   16,  -13,  -10]
	[   2,  248,   23,   24,   -6,  -12]
}

// Diamonds, Gold and Valuables Sprites
spriteset(spriteset_diamonds_gold_valuables_opel_blitz_3_6, "graphics/lv4.png") 
{
	[ 226,  248,   10,   26,   -4,  -14]
	[ 242,  248,   23,   24,  -15,  -12]
	[ 274,  248,   26,   16,  -13,  -11]
	[ 306,  248,   23,   24,   -8,  -13]
	[ 338,  248,   10,   26,   -4,  -14]
	[ 354,  248,   23,   24,  -13,  -13]
	[ 386,  248,   26,   16,  -13,  -10]
	[ 418,  248,   23,   24,   -6,  -12]
}

//Food and Fruit Sprites
spriteset(spriteset_food_fruit_opel_blitz_3_6, "graphics/lv4.png") 
{
	[ 690,  248,   10,   26,   -4,  -14]
	[ 706,  248,   23,   24,  -15,  -12]
	[ 738,  248,   26,   16,  -13,  -11]
	[ 770,  248,   23,   24,   -8,  -13]
	[   2,  296,   10,   26,   -4,  -14]
	[  18,  296,   23,   24,  -13,  -13]
	[  50,  296,   26,   16,  -13,  -10]
	[  82,  296,   23,   24,   -6,  -12]
}

//Start Livestock Livery
spriteset(opel_blitz_3_6_not_loaded_livestock, "graphics/lv4.png") 
{
	[ 386,  344,   10,   26,   -4,  -14 ]
	[ 402,  344,   23,   24,  -15,  -12 ]
	[ 434,  344,   26,   16,  -13,  -11 ]
	[ 466,  344,   23,   24,   -8,  -13 ]
	[ 498,  344,   10,   26,   -4,  -14 ]
	[ 514,  344,   23,   24,  -13,  -13 ]
	[ 546,  344,   26,   16,  -13,  -10 ]
	[ 578,  344,   23,   24,   -6,  -12 ]
}
    
spriteset(opel_blitz_3_6_loading_livestock, "graphics/lv4.png") 
{
	[ 610,  344,   10,   26,   -4,  -14 ]
	[ 626,  344,   23,   24,  -15,  -12 ]
	[ 658,  344,   26,   16,  -13,  -11 ]
	[ 690,  344,   23,   24,   -8,  -13 ]
	[ 722,  344,   10,   26,   -4,  -14 ]
	[ 738,  344,   23,   24,  -13,  -13 ]
	[ 770,  344,   26,   16,  -13,  -10 ]
	[   2,  392,   23,   24,   -6,  -12 ]
}

spriteset(opel_blitz_3_6_loaded_livestock, "graphics/lv4.png") 
{
	[  34,  392,   10,   26,   -4,  -14 ]
	[  50,  392,   23,   24,  -15,  -12 ]
	[  82,  392,   26,   16,  -13,  -11 ]
	[ 114,  392,   23,   24,   -8,  -13 ]
	[ 146,  392,   10,   26,   -4,  -14 ]
	[ 162,  392,   23,   24,  -13,  -13 ]
	[ 194,  392,   26,   16,  -13,  -10 ]
	[ 226,  392,   23,   24,   -6,  -12 ]
}

//Join the different states of cargo loaded
spritegroup opel_blitz_3_6_graphics_livestock 
{
	loading:
			[
				opel_blitz_3_6_not_loaded_livestock,
				opel_blitz_3_6_loading_livestock, 
				opel_blitz_3_6_loaded_livestock
			];
	loaded: 
			[
				opel_blitz_3_6_not_loaded_livestock,
				opel_blitz_3_6_loading_livestock, 
				opel_blitz_3_6_loaded_livestock
			];
}
//End Livestock Livery

//Define graphics for each cargo livery
switch(FEAT_ROADVEHS, SELF, switch_opel_blitz_3_6_cargo_selection, cargo_type_in_veh) {
 MAIL: spriteset_mail_opel_blitz_3_6;
 VALU: spriteset_diamonds_gold_valuables_opel_blitz_3_6;
 GOLD: spriteset_diamonds_gold_valuables_opel_blitz_3_6;
 DIAM: spriteset_diamonds_gold_valuables_opel_blitz_3_6;
 FRUT: spriteset_food_fruit_opel_blitz_3_6;
 FOOD: spriteset_food_fruit_opel_blitz_3_6;
 LVST: opel_blitz_3_6_graphics_livestock;
}

item (FEAT_ROADVEHS, opel_blitz_3_6_truck) {
	property {
		name						: string(STR_NAME_OPEL_BLITZ_3_6);
		climates_available			: ALL_CLIMATES;
		sprite_id					: SPRITE_ID_NEW_ROADVEH;
		visual_effect         		: visual_effect(VISUAL_EFFECT_DIESEL, 0);
		misc_flags					: bitmask(ROADVEH_FLAG_2CC);
		running_cost_base			: RUNNING_COST_ROADVEH;
		refittable_cargo_classes	: bitmask(CC_BULK);
		non_refittable_cargo_classes: 0; 
		cargo_allow_refit			: [MAIL, GOOD, VALU, FOOD, GOLD, FRUT, DIAM, COAL, IORE, CORE, GRAI, OIL_, WOOD, LVST, STEL, WDPR, PAPR, RUBR, WATR]; 
		cargo_disallow_refit		: [PASS];
        default_cargo_type			: MAIL;
		cargo_age_period            : 300;
		refit_cost					: 5;
		loading_speed				: 30;
		tractive_effort_coefficient	: 0.3;
		air_drag_coefficient		: 0; 
		reliability_decay			: 20;
		introduction_date			: date(1935,1,1);
		model_life					: 20;
		vehicle_life				: 20;
		speed						: 64 km/h;
		power						: 200 hp;
		weight						: 13 ton;
		cargo_capacity				: 250;
		cost_factor					: 50;
		running_cost_factor			: 90;
		length						: 8;
	}
	graphics {
		purchase					: spriteset_purchase_opel_blitz_3_6;
		default						: switch_opel_blitz_3_6_cargo_selection;
	}
}

So if the sprites are always the same for the cargo, say mail, there's no point in having states of loading and loaded right, just create a spriteset and boom done right?

And also on cargo livestock with different states of loading, is that code what you think is the proper one? I mean is there something I might be missing that in the future could bite me?

[FooBar]

So if the sprites are always the same for the cargo, say mail, there's no point in having states of loading and loaded right, just create a spriteset and boom done right?

Correct.

I mean is there something I might be missing that in the future could bite me?

In switch_opel_blitz_3_6_cargo_selection there's no default result. What should happen if a different cargo is in the vehicle?

Also, you may want to invest some time in reading up on refittable/non refitabble cargo classes and types. In this particular case: if you only allow bulk, you don't need to disallow passengers, or disallow all known cargo types. The latter is what I do. I specifically allow and disallow all currently known cargo types, such that the cargo classes only define what to do with new cargoes that are invented in the future.

Lastly, try to use templates for the graphics. I see a lot of repetition in the offset and position in the spritesets. You can significantly decrease code length by using templates.

[Digitalfox]

So if the sprites are always the same for the cargo, say mail, there's no point in having states of loading and loaded right, just create a spriteset and boom done right?

Correct.

I mean is there something I might be missing that in the future could bite me?

In switch_opel_blitz_3_6_cargo_selection there's no default result. What should happen if a different cargo is in the vehicle?

Also, you may want to invest some time in reading up on refittable/non refitabble cargo classes and types. In this particular case: if you only allow bulk, you don't need to disallow passengers, or disallow all known cargo types. The latter is what I do. I specifically allow and disallow all currently known cargo types, such that the cargo classes only define what to do with new cargoes that are invented in the future.

Lastly, try to use templates for the graphics. I see a lot of repetition in the offset and position in the spritesets. You can significantly decrease code length by using templates.

Thank you, great feedback

In switch_opel_blitz_3_6_cargo_selection there's no default result. What should happen if a different cargo is in the vehicle?

It's still work in progress. I usually define all cargoes [MAIL, GOOD, VALU, FOOD, GOLD, FRUT, DIAM, COAL, IORE, CORE, GRAI, OIL_, WOOD, LVST, STEL, WDPR, PAPR, RUBR, WATR].

Also, you may want to invest some time in reading up on refittable/non refitabble cargo classes and types. In this particular case: if you only allow bulk, you don't need to disallow passengers, or disallow all known cargo types. The latter is what I do. I specifically allow and disallow all currently known cargo types, such that the cargo classes only define what to do with new cargoes that are invented in the future.

Ok, so I did some reading as you suggested. While it's still a bit confusing I'm looking at some of your nml grfs to have a better understanding!

Templates, point taken, after I have more confident on my code I'll give it a shot

[FooBar]

This is what the Dutch Trainset does: http://dev.openttdcoop.org/projects/dut ... efits.pnml
I'm not suggesting to use defines or anything, but it gives a nice overview of different types of vehicles and their cargo definitions. You'll notice that there are many more cargoes than the ones you listed. Your vehicle is probably most comparable to the GONDOLA vehicle type in my file.

It's still work in progress. I usually define all cargoes [MAIL, GOOD, VALU, FOOD, GOLD, FRUT, DIAM, COAL, IORE, CORE, GRAI, OIL_, WOOD, LVST, STEL, WDPR, PAPR, RUBR, WATR].

Bear in mind that there is no definition of "all cargoes". If tomorrow I make an industry set with a new cargo, your vehicle is broken. So always define the most generic graphics as default.

[Digitalfox]

Wow, very nice, thank you Foobar

[Transportman]

Some minor points from my side, not really big breaking things, you might even consider it nitpicking, but things that you might want to keep in mind.

1 - Naming of spritesets/spritegroups/items. In your Livestock spritesets, you drop the spriteset_ from the identifier, while in the other spritesets you included the spriteset_ part. Same goes for the spritegroup and your item. While it is not mandatory to do it, if your set becomes larger or more complex, it makes it easier to walk through the code. In your current code it doesn't really matter as the rest is consistently named, but if you do it with more things it can become messy as it increases the chances of mistakes.
2 - Could you show the graphics you are using to make this vehicle? I find the used x,y a bit strange, as if the used graphics are not templated themselves. Maybe you got them as an export from another GRF, as I think most (if not all) artists at least template their sprites and most coders only include things that are templated.

[Digitalfox]

Some minor points from my side, not really big breaking things, you might even consider it nitpicking, but things that you might want to keep in mind.

I'm extremely grateful for all the feedback I've been getting from this topic.
I've learned a lot and keep learning every-time you guys give me advice, so "nitpicking"? Please do so

1 - Naming of spritesets/spritegroups/items. In your Livestock spritesets, you drop the spriteset_ from the identifier, while in the other spritesets you included the spriteset_ part. Same goes for the spritegroup and your item. While it is not mandatory to do it, if your set becomes larger or more complex, it makes it easier to walk through the code. In your current code it doesn't really matter as the rest is consistently named, but if you do it with more things it can become messy as it increases the chances of mistakes.
2 - Could you show the graphics you are using to make this vehicle? I find the used x,y a bit strange, as if the used graphics are not templated themselves. Maybe you got them as an export from another GRF, as I think most (if not all) artists at least template their sprites and most coders only include things that are templated.

1 - You are absolutely correct, I've corrected that

2 - The graphics are based on Lv4.grf, since there's no source available, I've decoded the lv4.grf and I'm using the decoded nfo and png as base.
George only provided the the lv5 trucks graphics source, but those files don't include (as far as I could see) all the sprites for the different cargoes.
I also don't want to use the lv5 trucks graphics for this particular vehicle, the Opel Blitz, I don't think such a small truck should be articulated!
From now on I'll be using lv5 graphics and all trucks are articulated!

[Digitalfox]

Hi

So I'm having some doubts over retire_early property!

Code: Select all

introduction_date				: date(1848,1,1);
       model_life				: 25;
	//retire_early				: ;
     vehicle_life				: 40;

So this is my code for a train!

As you can see it get's introduced in 1848 and is available to purchase for 25 years, so (ignore for now the random introduction and retirement in OpenTTD http://newgrf-specs.tt-wiki.net/wiki/NM ... life_cycle ).

So my idea is to have it no longer available in 1874, because at this point there other train engines available!

So how do I set retire_early property?

I've read http://newgrf-specs.tt-wiki.net/wiki/NM ... life_cycle and understand the randomness in vehicles to some degree, but It is a bit confusing!

So should it be set at (model_life - 8 years)?

Thanks guys

[PikkaBird]

You want it to be available in 1848, and you want it to no longer be available in 1874? Since the vehicle_life is 40 years, you presumably want it to be useful up until, say 1900?

I'd set the values as follows:

model_life = 60 - Introduction_date + model_life - 8 determines when maximum reliability will start to drop. 1848 + 60 - 8 = 1900.
retire_early = 26 - Introduction_date + model_life - 8 - retire_early determines when the vehicle will be removed from the purchase list. 1848 + 60 - 8 - 26 = 1874.

[Transportman]

Normally, the vehicle is removed from the purchase menu at the and of phase 3. However if you set the retire_early property, it will be retired this many years before (or after, if the value is negative) the end of phase 2.

If you set the retire_early property, the vehicle will no longer be available after (model_life - 8 - retire_early) years. If you don't set it, it will be removed after (model_life + something between 2 and 12.5) years.

[Digitalfox]

Thanks for answering guys, much appreciated

Transportman: Yes that was more or less my understanding of it!

PikkaBird: Thanks for the example! I'll be honest the way it works seems confusing/not friendly, but maybe it's just my brain CPU that needs a upgrade.
I'll play with it a bit and see if I can somehow get a "template of it in brain" and lose less time than I'm currently wasting calculating each vehicle, I hope I can make sense of it

[Eddi]

i generally set retire_early to (vehicle_life-4), and then adjust model_life to fit the timeframe i want the vehicle to be available, which is (last_available-first_available+vehicle_life)

[Digitalfox]

So here is my test code:

Code: Select all

introduction_date			: date(1848,1,1);
 model_life				   : 40;
retire_early				  : 10;
vehicle_life				  : 40;

So I took the example of Pikka:

introduction_date : date(1848,1,1);

model_life : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/; // Determines when maximum reliability will start to drop.

retire_early : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/ -10/*retire_early*/; //Determines when the vehicle will be removed from the purchase list.

vehicle_life : 40; //Time before vehicle gets OLD

Using reloadnewgrfs on multiple years from 1870 to 1880, I verify that only after 1875 does it really becomes unavailable on purchase list! Is this expected 5 years of randomness?

[PikkaBird]

model_life : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/; // Determines when maximum reliability will start to drop.

retire_early : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/ -10/*retire_early*/; //Determines when the vehicle will be removed from the purchase list.

Eek.

If I'm reading this correctly, you appear to be setting the model_life to 1,880 years, and retire_early to 1,870 years. I should probably have solved my formulae for x to make it less confusing.

Try this:

model_life = <year when reliability starts to drop> - <introduction year> + 8
retire_early = <year when reliability starts to drop> - <year when vehicle removed from list>

[Digitalfox]

model_life : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/; // Determines when maximum reliability will start to drop.

retire_early : 1848/*Intro_date*/ +40/*model_life*/ -8/*Always 8*/ -10/*retire_early*/; //Determines when the vehicle will be removed from the purchase list.

Eek.

If I'm reading this correctly, you appear to be setting the model_life to 1,880 years, and retire_early to 1,870 years. I should probably have solved my formulae for x to make it less confusing.

Try this:

model_life = <year when reliability starts to drop> - <introduction year> + 8
retire_early = <year when reliability starts to drop> - <year when vehicle removed from list>

Lol, no Pikka my code is this, I'm not using something like retire_early: 1880; :

Code: Select all

introduction_date			: date(1848,1,1);
 model_life				   : 40;
retire_early				  : 10;
vehicle_life				  : 40;

The other quote is just something I have on my notepad to better understand and more quickly calculate numbers until it get's memorized

[Digitalfox]

Good afternoon!

How can you overcame the Train Power HP limit of 65***?


For example I have a Maglev and I've been trying to have a total of 70000 or 80000HP, I've been trying multiple shot's like for example a switch:

Code: Select all

//Join both Engines sprites
switch (FEAT_TRAINS, SELF, switch_maglev_articulated, extra_callback_info1) {  
	0: return item_maglev_front;
	1: return item_maglev_back; 
	return CB_RESULT_NO_MORE_ARTICULATED_PARTS;
}

On this shot, I have two items and have power on both at 40000, doesn't work, it only gives me 40000HP, it only reads the first item power and doesn't add, like 40000+40000=80000.


I've also tried to use a switch on graphics field with only one item with dualhead = 1, but couldn't figure how my switch should look like, to say engine 0 = 40000 and engine 1=40000.


Can you decipher what I'm trying to say and do?