Digitalfox NML Questions!

[Digitalfox]

Hi

Instead of creating topic after topic with questions, I'm going to just use this topic and prevent me spamming this forum section


Question:

I have a bank.

It accepts Diamonds, Gold and Valuables.

It produces Valuables.

It should use the Diamonds, Gold and Valuables it receives to produce Valuables.


My NML code (heavily based on OpenGFX+ Industries original code):

Code: Select all

//Valuables
 item(FEAT_CARGOS, cargo_valuables, 0x0A) {
  property {
   type_name: 0x0019; unit_name: 0x0019 + 0x20; units_of_cargo: 0x0019 + 0x40; items_of_cargo: 0x0019 + 0x60; type_abbreviation: 0x0019 + 0x80; is_freight: 1;
   sprite: 4307;
   number: 0x0A;
   cargo_label: "VALU";
   cargo_classes: bitmask(CC_ARMOURED);
   weight: 0.125; // 2 / 16
   penalty_lowerbound: 1;
   single_penalty_length: 32;
   price_factor: (8509 * 10.0 * 20 * 255) / (1 << 21);
   station_list_colour: 0xBF;
   cargo_payment_list_colour: 0xCA;
   town_growth_effect: TOWNGROWTH_NONE;
   town_growth_multiplier: 0;
  }
 }

Code: Select all

//------------------- 
// Bank
//-------------------

item(FEAT_INDUSTRYTILES, bank_tile_1) {
 property {
  substitute: 0x3A;
  override: 0x3A; // Temperate bank
 }
}

item(FEAT_INDUSTRYTILES, bank_tile_2) {
 property {
  substitute: 0x3B;
  override: 0x3B; // Temperate bank
 }
}

 item(FEAT_INDUSTRYTILES, bank_tile_1) {
  property {
   accepted_cargos: [[VALU, 8], [GOLD, 8], [DIAM, 8]];
  }
 }

 item(FEAT_INDUSTRYTILES, bank_tile_2) {
  property {
   accepted_cargos: [[VALU, 8], [GOLD, 8], [DIAM, 8]];
  }
 }

And then:

Code: Select all

switch (FEAT_INDUSTRIES, PARENT, industry_bank_num_houses_check_switch, [STORE_TEMP(LOAD_TEMP(0), 0x100), STORE_TEMP(150, 0x101), var[0xB6] - 150 * LOAD_TEMP(0)]) { 0..0xFFFF: return CB_RESULT_LOCATION_ALLOW; return string(STR_ERR_TOWN_TOO_SMALL); } 
switch (FEAT_INDUSTRIES, SELF, industry_bank_location_check_switch, STORE_TEMP(industry_town_count(0x0C, -1), 0)) { 0: return CB_RESULT_LOCATION_ALLOW; industry_bank_num_houses_check_switch; }

item(FEAT_INDUSTRIES, industry_bank, 0x0C) { 
 property { substitute: 0x0C; override: 0x0C;
  accept_cargo_types: [cargotype("DIAM"), cargotype("GOLD"), cargotype("VALU")];
  prod_cargo_types: [cargotype("VALU")];
  prob_random: 0; //When generating the Map
  prob_in_game: 0; //Game generates playing new Industries, disable it
  spec_flags: bitmask(IND_FLAG_ONLY_IN_TOWNS);
 }
 graphics {  
  location_check: industry_bank_location_check_switch;
 }
}

Result: It's accepting Diamonds, Gold and Valuables. Great. It's producing Valuables. Awesome.

The Bad part, it's producing Valuables just like a normal Bank(like a mine) not based on the cargo it receives. It should produce cargo based on Diamonds, Gold and Valuables (Yes valuables should also count to it) it receives.


What am I missing?

[Digitalfox]

Ok, after taking a look at FIRS NML code and reusing a part of it, it's working

I'm sure I'm over using too much code, but I'll try to learn from it and then optimizations will come

Code: Select all

produce (bank_simple_produce, waiting_cargo_1, waiting_cargo_2, waiting_cargo_3,
   LOAD_PERM(4) / 8 / 1 * LOAD_PERM(1) +
   LOAD_PERM(5) / 8 / 1 * LOAD_PERM(2) +
   LOAD_PERM(6) / 8 / 1 * LOAD_PERM(3),

   LOAD_PERM(4) / 8 / 1 * LOAD_PERM(1) +
   LOAD_PERM(5) / 8 / 1 * LOAD_PERM(2) +
   LOAD_PERM(6) / 8 / 1 * LOAD_PERM(3),
   [
   /* Remove any remainder */
   STORE_PERM( LOAD_PERM(4) % (8 * 1), 4),
   STORE_PERM( LOAD_PERM(5) % (8 * 1), 5),
   STORE_PERM( LOAD_PERM(6) % (8 * 1), 6),
   0
   ]
);

switch (FEAT_INDUSTRIES, SELF, bank_produce,
   [
   /* Update the 'last delivery date' for the three input cargos */
   STORE_PERM( max(LOAD_PERM(10),(waiting_cargo_1 > 0) * current_date), 10),
   STORE_PERM( max(LOAD_PERM(11),(waiting_cargo_2 > 0) * current_date), 11),
   STORE_PERM( max(LOAD_PERM(12),(waiting_cargo_3 > 0) * current_date), 12),
   /* Reset the closure countdown */
   STORE_PERM( (waiting_cargo_1 == 0 && waiting_cargo_1 == 0 && waiting_cargo_3 == 0) * LOAD_PERM(15), 15),

   /* Store the delivered cargo permanently (for debugging purposes only, reset at beginning of month) */
   STORE_PERM( LOAD_PERM(7) + waiting_cargo_1, 7),
   STORE_PERM( LOAD_PERM(8) + waiting_cargo_2, 8),
   STORE_PERM( LOAD_PERM(9) + waiting_cargo_3, 9),

   /* Check whether the cargos were delivered within the time frame to be considered delivered concurrently */
   STORE_TEMP( (current_date - LOAD_PERM(10)) <= 30, 0),
   STORE_TEMP( (current_date - LOAD_PERM(11)) <= 30, 1),
   STORE_TEMP( (current_date - LOAD_PERM(12)) <= 30, 2),

   /* Calculate current production ratios for the individual cargos */
   STORE_PERM( 2 +
               LOAD_TEMP(1) * 2 +
               LOAD_TEMP(2) * 4,
       1
   ),
   STORE_PERM( 2 +
               LOAD_TEMP(0) * 2 +
               LOAD_TEMP(2) * 4,
       2
   ),
   STORE_PERM( 4 +
               LOAD_TEMP(0) * 2 +
               LOAD_TEMP(1) * 2,
       3
   ),

   /* Add the remainder to the current leftover cargos */
   STORE_PERM( LOAD_PERM(4) + waiting_cargo_1, 4),
   STORE_PERM( LOAD_PERM(5) + waiting_cargo_2, 5),
   STORE_PERM( LOAD_PERM(6) + waiting_cargo_3, 6),

   1
   ]) {
 bank_simple_produce;
}

[Digitalfox]

I have a silly question, but I just have to admit it, Masks? I don't get it.

Why use masks in OpenTTD?

I mean say I have this png:

811_z1.png (11.11 KiB) Viewed 6607 times

And there's the mask file:

811_z1m.png (967 Bytes) Viewed 6607 times

What does it do to the picture? I don't see a effect to the picture, it looks just fine to me without the mask.

I'm sure every computer artist in the planet (and maybe in the universe) is laughing about my silly question, but since I'm a 0 at the left when it comes to drawing, maybe that's why I don't get it :\

[Eddi]

masks handle recolouring, like for company colours, or in this case the eye colours. it basically says "these areas are to be changed, the other ones untouched". the game can then make the eyes blue, green, red, magenta or lava-sparkling... from the same sprite.

[Digitalfox]

masks handle recolouring, like for company colours, or in this case the eye colours. it basically says "these areas are to be changed, the other ones untouched". the game can then make the eyes blue, green, red, magenta or lava-sparkling... from the same sprite.

Ah ok, that makes sense, thank you Eddi

[Digitalfox]

I've noticed something that I would like to better understand.

Every time I overwrite a GRF while OpenTTD is open after a while it crashes.

Now that it crashes makes perfect sense, I'm messing with sprites and code and a crash is expected.

But I thought that after OpenTTD was started and new game started or savegame loaded most nfo code and sprites were put in memory and Open didn't need to touch the GRF anymore.

So what happens is that if take it of pause it doesn't crash instantly, only after a while 5 or 10 seconds.

So my question is, does OpenTTD load the same GRF multiple times when running? Only some parts or it reads all the NFO code everytime it accesses the GRF?

Thank you

[Transportman]

I think that depends on the action you do. Just changing files on your file system should not have any effect, unless you try to load a new game without rescanning your NewGRFs, as you got an invalid configuration at that moment. Updating in a running game (and using a rescan to get the new version in that game) can have all kinds of results, from just updating to crashing, even after longer periods of time.

The moment you start a game with a NewGRF (or update the configuration in a running game) the complete NewGRF becomes part of that game.

[planetmaker]

The NewGRF defines parts of the game state. If save the game, then you change the NewGRF (and make the bitwise matching one (same md5sum) unavailable) it will look on load of the savegame for a NewGRF which looks similar to the one it's looking for. If it is not actually compatible (despite you declaring it being compatible), OpenTTD may crash. Thus if you develop a NewGRF and you constantly overwrite the NewGRF with new versions while not keeping your changes compatible in a way that e.g. all IDs are maintained with basically the same vehicles, houses or industries and their properties and availability change, then OpenTTD may well crash upon map load as the savegame is in an inconsistent state. It's the same effect as modifying NewGRFs during the game - and by enabling the NewGRF developer tools you acknowledged that you're aware of the dangers which come with it.

[Eddi]

you guys are all missing the point.

this is not about "changing newgrfs of a savegame". this is "modifying the file while the game is running"

and i don't know what you change, but when i do that with a vehicle, and forget to run "reload_newgrfs", then it crashes instantly after unpausing. the game only caches the real-sprites of the GRF, anything like callbacks are read from the file, and if you change the file, invalid data will be executed, causing crashes.

[Digitalfox]

Thank you guys, but I was looking the answer Eddi give.

Thank you!!!

[frosch]

Not sure whether Eddi said that or the reverse: Anyway, OTTD reads everything except the images from the NewGRF on game start. The images are read upon first usage and stored in the sprite cache. The sprite cache only has limited space, so after some time images are dropped and later read from disk again.

Using "reload_newgrfs" reloads everything: Images, image meta data, and also the non-image content like properties and callbacks.

[Digitalfox]

...

Ok, but after the inicial loading are "non-image content like properties and callbacks" read again from the GRF during a game?

From the answer Eddi gave, I read that yes, but after your answer I'm in doubt again.!

[Digitalfox]

Hi, I'm going nuts and need help please!!!

I had my Track GRF working perfectly, but today I decided that my "Low Speed" track would not be electric.

So now Very and Low Speed are not electric!

Medium, High and Very High are electric.

Very low is working showing only steam and diesel trains.

Low Speed doesn't show any trains (ANY).

Medium, High and Very High are showing steam, diesel and electric.

What am I missing so that Low Speed shows trains just like Very Low?

I've messed multiple times with "compatible", "powered" and "alternative" items just now, trying to figuring what could be wrong, so they might look insane

Code: Select all

railtypetable {
  "RAIL", "LSTR", "ELRL", "HSTR", "VHST"
}

Code: Select all

//--------------------------------------------------
//  Starts Very Low Speed Track
//--------------------------------------------------

item(FEAT_RAILTYPES, rail, 0) {
 property {
         label: "RAIL";
  introduction_date: date(1850,1,1);
  name: string(STR_TRACK_TYPE_VLST);
  toolbar_caption: string(STR_CONSTRUCTION_VLST);
  menu_text: string(STR_CONSTRUCTION_VLST);
  build_window_caption: string(STR_VEHICLE_CONSTRUCTION_VLST);
  autoreplace_text: string(STR_AUTOREPLACE_VLST);
  new_engine_text: string(STR_NEW_ENGINE_VLST);
  compatible_railtype_list: ["RAIL", "LSTR"];
  powered_railtype_list: ["ELRL", "HSTR", "VHST"];
  alternative_railtype_list: ["RAIL", "LSTR"];  
  construction_cost: 56;
  maintenance_cost: 56 / 4;
  railtype_flags: bitmask(RAILTYPE_FLAG_NO_LEVEL_CROSSING);
  speed_limit: param_speed_very_low km/h;
  acceleration_model: ACC_MODEL_RAIL;
  sort_order: 00;
 }
}

//--------------------------------------------------
//  Ends Very Low Speed Track
//--------------------------------------------------



//--------------------------------------------------
//  Starts Low Speed Track
//--------------------------------------------------

item(FEAT_RAILTYPES, lstr, 1) {
 property {
         label: "LSTR";
  introduction_date: date(1919,1,1);
  name: string(STR_TRACK_TYPE_LSTR);
  toolbar_caption: string(STR_CONSTRUCTION_LSTR);
  menu_text: string(STR_CONSTRUCTION_LSTR);
  build_window_caption: string(STR_VEHICLE_CONSTRUCTION_LSTR);
  autoreplace_text: string(STR_AUTOREPLACE_LSTR);
  new_engine_text: string(STR_NEW_ENGINE_LSTR);
  compatible_railtype_list: ["RAIL", "LSTR"];
  powered_railtype_list: ["ELRL", "HSTR", "VHST"];
  alternative_railtype_list: ["RAIL", "LSTR"];    
  construction_cost: 2.75 * 56;
  maintenance_cost: 2.75 * 56 / 4;
  railtype_flags: bitmask(RAILTYPE_FLAG_NO_LEVEL_CROSSING);
  speed_limit: param_speed_low km/h;
  acceleration_model: ACC_MODEL_RAIL;
  sort_order: 01;
 }
}

//--------------------------------------------------
//  Ends Low Speed Track
//--------------------------------------------------



//--------------------------------------------------
//  Starts Medium Speed Track (Electric)
//--------------------------------------------------

item(FEAT_RAILTYPES, elrl, 2) {
 property {
         label: "ELRL";
  introduction_date: date(1947,1,1);
  name: string(STR_TRACK_TYPE_MSTR);
  toolbar_caption: string(STR_CONSTRUCTION_MSTR);
  menu_text: string(STR_CONSTRUCTION_MSTR);
  build_window_caption: string(STR_VEHICLE_CONSTRUCTION_MSTR);
  autoreplace_text: string(STR_AUTOREPLACE_MSTR);
  new_engine_text: string(STR_NEW_ENGINE_MSTR);
  compatible_railtype_list: ["RAIL", "LSTR", "ELRL", "HSTR", "VHST"];
  powered_railtype_list: ["ELRL", "HSTR", "VHST"];
  alternative_railtype_list: ["ELRL", "HSTR", "VHST"];  
  construction_cost: 2.75 * 2.75 * 56 + 2.75 * 2.75 * 1 * 56;
  maintenance_cost: 2.5 * 2.75 * 56 / 4 + 2.75 * 2.75 * 1 * 56 / 4;
  railtype_flags: bitmask(RAILTYPE_FLAG_CATENARY, RAILTYPE_FLAG_NO_LEVEL_CROSSING);
  speed_limit: param_speed_medium km/h;
  acceleration_model: ACC_MODEL_RAIL;
  sort_order: 02;
 }
}

//--------------------------------------------------
//  Ends Medium Speed Track (Electric)
//--------------------------------------------------


//--------------------------------------------------
//  Starts High Speed Track (Electric)
//--------------------------------------------------

item(FEAT_RAILTYPES, hstr, 3) {
 property {
         label: "HSTR";
  introduction_date: date(1972,1,1);
  name: string(STR_TRACK_TYPE_HSTR);
  toolbar_caption: string(STR_CONSTRUCTION_HSTR);
  menu_text: string(STR_CONSTRUCTION_HSTR);
  build_window_caption: string(STR_VEHICLE_CONSTRUCTION_HSTR);
  autoreplace_text: string(STR_AUTOREPLACE_HSTR);
  new_engine_text: string(STR_NEW_ENGINE_HSTR);
  compatible_railtype_list: ["RAIL", "LSTR", "ELRL", "HSTR", "VHST"];
  powered_railtype_list: ["ELRL", "HSTR", "VHST"];
  alternative_railtype_list: ["ELRL", "HSTR", "VHST"];
  construction_cost: 2.75 * 2.75 * 2.75 * 56 + 2.75 * 2.75 * 2.75 * 1 * 56;
  maintenance_cost: 2.75 * 2.5 * 2.75 * 56 / 4 + 2.75 * 2.75 * 2.75 * 1 * 56 / 4;
  railtype_flags: bitmask(RAILTYPE_FLAG_CATENARY, RAILTYPE_FLAG_NO_LEVEL_CROSSING);
  speed_limit: param_speed_high km/h;
  acceleration_model: ACC_MODEL_RAIL;
  sort_order: 03;
 }
}

//--------------------------------------------------
//  Ends High Speed Track (Electric)
//--------------------------------------------------



//--------------------------------------------------
//  Starts Very High Speed Track (Electric)
//--------------------------------------------------

item(FEAT_RAILTYPES, vhst, 4) {
 property {
         label: "VHST";
  introduction_date: date(2003,1,1);
  name: string(STR_TRACK_TYPE_VHST);
  toolbar_caption: string(STR_CONSTRUCTION_VHST);
  menu_text: string(STR_CONSTRUCTION_VHST);
  build_window_caption: string(STR_VEHICLE_CONSTRUCTION_VHST);
  autoreplace_text: string(STR_AUTOREPLACE_VHST);
  new_engine_text: string(STR_NEW_ENGINE_VHST);
  compatible_railtype_list: ["RAIL", "LSTR", "ELRL", "HSTR", "VHST"];
  powered_railtype_list: ["ELRL", "HSTR", "VHST"];
  alternative_railtype_list: ["ELRL", "HSTR", "VHST"];
  construction_cost: 2.75 * 2.75 * 2.75 * 2.75 * 56 + 2.75 * 2.75 * 2.75 * 2.75 * 1 * 56;
  maintenance_cost: 2.75 * 2.75 * 2.5 * 2.75 * 56 / 4 + 2.75 * 2.75 * 2.75 * 2.75 * 1 * 56 / 4;
  railtype_flags: bitmask(RAILTYPE_FLAG_CATENARY, RAILTYPE_FLAG_NO_LEVEL_CROSSING);
  speed_limit: param_speed_very_high km/h;
  acceleration_model: ACC_MODEL_RAIL;
  sort_order: 04;
 }
}

//--------------------------------------------------
//  Ends Very High Speed Track (Electric)
//--------------------------------------------------

Where am I screwing this up?

[Transportman]

You need to add RAIL/LSTR to the LSTR/RAIL powered_railtype_list.

The compatible_railtype_list only says that the vehicle can run on the other track but that it is not powered, for that you also need to add the other track to the powered_railtype_list

[Digitalfox]

You need to add RAIL/LSTR to the LSTR/RAIL powered_railtype_list.

The compatible_railtype_list only says that the vehicle can run on the other track but that it is not powered, for that you also need to add the other track to the powered_railtype_list

Ah that was my confusion. It's working


Transportman I love you

[Digitalfox]

On WAS there's this piece of code on each plane, defining the various speeds:

Code: Select all

//Define the speeds at every stage, like in flight and on ground
switch (FEAT_AIRCRAFT, SELF, Boeing_707_320_speed, (var[0xE2, 0, 0xFF]))
{
  12..13: return int(233*5/64); // airplane waiting for take-off clearance, airplane taking off
      15: return int(427*5/64); // airplane climbing after take-off
      18: return int(999*5/64); // heading for tower contact point
  16..20: return int(402*5/64); // in flight
  21..22: return int(193*5/64); // airplane landing, airplane braking after touchdown
          return int(201*5/64);
}

And also the purchase speed:

Code: Select all

purchase_speed: int(999*5/64);

How does it work? On screen the plane is running at full at 1003KM/h. I understand the different needs for multiple speeds, like in flight, landing, on runway, etc...

But how is the math being made? What value is being multiplied or other operation to the result say for example of purchase_speed (1003KM's in game)?

[Supercheese]

Speed in units of 8 mph, that is: property = (speed in mph) / 8

So,

int(999*5/64) = int(78.046875) = 78 = (speed in mph) / 8

speed in mph = 78*8 = 624 mph

[Digitalfox]

Speed in units of 8 mph, that is: property = (speed in mph) / 8

So,

int(999*5/64) = int(78.046875) = 78 = (speed in mph) / 8

speed in mph = 78*8 = 624 mph

Ok, got it.

So since I prefer KM/h, I'm going to use (speed in kmh) / +/- 12,...

[Digitalfox]

How do you in NML declare that a GRF should use the Windows (Legacy) Palette?

For example I'm using a mix of WAS and AV8 sprites in my planes GRF.

By default it always goes to DOS palette, and while WAS sprites look normal the AV8 don't.

If I use the toggle button it goes to legacy and the WAS sprites are not affected but the av8 sprites show properly.

[FooBar]

I believe NML is supposed to do this automatically. If you have a combination of files this is converted to either one (I think the DOS one, because this has more colours), provided the individual graphic files have a valid palette applied.