Scripters cove

[montana05]

I'm having problems getting the desired escorts for a Boa 2...

For simple escorts you can use

escort_role (the role of the ship) or
escort_ship (the key of the ship).

Combining it with escorts and a number might be useful.

escort_roles offers you a variable number of escorts, you can assign only 1 ship (role) with min and max so that in more dangerous systems more escorts will be assigned.

Neither
escort_role (the role of the ship) nor
escort_ship (the key of the ship)
...seem to work.

Where there is supposed to be 1 escort ship-type, I'm seeing Geckos, Mambas, Sidewinders, Cobra 1's and 3's, etc!

I am using a separate line of:
escorts = 4;
...To define how many escorts to have.

The ships I'm trying to make escorts exist, as I can spawn them separately using this line:

Code: Select all

system.addGroup("navy-asp", 4, [0,0,0], 30E3);

Strange, I will run some tests tomorrow. However, please try this one:

Code: Select all

escort_roles = 
(
    { role = "navy-asp"; min = -2; max = 4; }
);

You should get between 2 and 4 escorts of your desired role.

EDIT: Do you use a core-Boa2 ? If you reference to this ship you have escorts already defined, means you need to neutralize or overwrite them.

[Cholmondely]

I've updated the wiki a bit to hopefully explain things a bit more. It's a bit tricky: as you say earlier, I find it easy to understand, but I'm a programmer. It's hard to know where exactly to add descriptions, without writing an OXP for every function! (Although, perhaps, in fairness, an OXP for every function is what is needed for non-programmers to get their heads around it).

Thanks for doing this.

Is there any chance you could just include a mention of an .oxp which does the sort of thing which you are talking about (or, perhaps, show an example of it).

[Old Murgh]

I've updated the wiki a bit to hopefully explain things a bit more. It's a bit tricky: as you say earlier, I find it easy to understand, but I'm a programmer. It's hard to know where exactly to add descriptions, without writing an OXP for every function! (Although, perhaps, in fairness, an OXP for every function is what is needed for non-programmers to get their heads around it).

Yes, thanks for this. Super helpful to be able to look up examples working templates that are less complicated to modify.

One such I've been looking around to find is a more meaty example than this little snippet for my rustyShips

Code: Select all

this.allowSpawnShip = function(shipKey)
{
  // your code here
  return bool;
}

with language to specify only communist and feudal systems, and no higher than TL 5.. That would be great in the wiki.

[Switeck]

Strange, I will run some tests tomorrow. However, please try this one:

Code: Select all

escort_roles = 
(
    { role = "navy-asp"; min = -2; max = 4; }
);

You should get between 2 and 4 escorts of your desired role.

EDIT: Do you use a core-Boa2 ? If you reference to this ship you have escorts already defined, means you need to neutralize or overwrite them.

Yes, I did use a like_ship reference to it. Here's an abbreviated portion of my code:

"navy-boa2" =
{
like_ship = "boa-mk2";
accuracy = 10;
aft_weapon_type = "WEAPON_MILITARY_LASER";
forward_weapon_type = "WEAPON_MILITARY_LASER";
escorts = 4;
// "escort_role" = "navy-asp";
"escort_ship" = "navy-asp";
roles = "navy-frigate(99) navy-boa2";
};

So it's "inheriting" boa-mk2's escort_roles ...but shouldn't defining escorts override that?

[montana05]

So it's "inheriting" boa-mk2's escort_roles ...but shouldn't defining escorts override that?

Well, it should, but it doesn't. What you can try is

Code: Select all

"escort_roles" = " ";
"escorts" = 4;
"escort_role" = "navy-asp";

I didn't test it, but I hope it will work.

[montana05]

I've updated the wiki a bit to hopefully explain things a bit more. It's a bit tricky: as you say earlier, I find it easy to understand, but I'm a programmer. It's hard to know where exactly to add descriptions, without writing an OXP for every function! (Although, perhaps, in fairness, an OXP for every function is what is needed for non-programmers to get their heads around it).

Yes, thanks for this. Super helpful to be able to look up examples working templates that are less complicated to modify.

One such I've been looking around to find is a more meaty example than this little snippet for my rustyShips

Code: Select all

this.allowSpawnShip = function(shipKey)
{
  // your code here
  return bool;
}

with language to specify only communist and feudal systems, and no higher than TL 5.. That would be great in the wiki.

Code: Select all

this.allowSpawnShip = function(shipKey)
{
   var gov = system.info.government;
   var tech = system.info.techLevel;
   
   switch (shipKey) 
   {
	case "my_ship_01":
	case "my_ship_02":
		
           if((gov === 2 || gov === 4) && tech < 6)
              return true;

         break;
               
         default:
            return false;
            break;   
    }
}

The internal variables are for performance and switch offers you to check multiple ships. Not tested and only typed on the board, so no editor check as well. However, I hope it will work.

[Switeck]

So it's "inheriting" boa-mk2's escort_roles ...but shouldn't defining escorts override that?

Well, it should, but it doesn't. What you can try is

Code: Select all

"escort_roles" = " ";
"escorts" = 4;
"escort_role" = "navy-asp";

I didn't test it, but I hope it will work.

Code: Select all

"escort_roles" = " ";
"escorts" = 4;
"escort_role" = "navy-asp";

...Doesn't work, navy-boa2 has NO escorts as a result.

No escorts also with:

Code: Select all

"escort_roles" = ();

Code: Select all

"escort_roles" = (	{}	);

...results in random escort types, like I experienced earlier.

Code: Select all

"escort_roles" = (	{	role = " ";	}	);

...results in no escorts again.

Code: Select all

"escort_roles" = (	{	role = "navy-asp"; min = 4; max = 4;	}	);

...results in absolute weirdness!
4 Navy Asps act as escorts of the Navy Boa 2.

[Old Murgh]

Code: Select all

this.allowSpawnShip = function(shipKey)
{
   var gov = system.info.government;
   var tech = system.info.techLevel;
   
   switch (shipKey) 
   {
	case "my_ship_01":
	case "my_ship_02":
		
           if((gov === 2 || gov === 4) && tech < 6)
              return true;

         break;
               
         default:
            return false;
            break;   
    }
}

The internal variables are for performance and switch offers you to check multiple ships. Not tested and only typed on the board, so no editor check as well. However, I hope it will work.

Great, thanks. Will try.
Must first figure a smart way to test for it.

Code: Select all

"escort_roles" = (	{	role = "navy-asp"; min = 4; max = 4;	}	);

...results in absolute weirdness!
4 Navy Asps act as escorts of the Navy Boa 2.

This isn't what you wanted?

[Switeck]

It is what I wanted.
4 Navy Asps escorting each Navy Boa 2 Light Cruiser.

...But it's been a frustrating trip to get there.

I'm watching both the Boa 2 and the Asp escorts sit-and-spin while they are getting slaughtered by Thargoids.
Or they get really twitchy with very short pulses of injectors for no useful reason...burning up their limited fuel.
Even though I bumped their accuracy to 6-10, they still seldom shoot their lasers...and miss a lot against Thargoid invaders/warships, cruisers, and battleships.
...despite giving them aggressive AI.plist files.

[montana05]

Strange, I will run some tests tomorrow. However, please try this one:

Code: Select all

escort_roles = 
(
    { role = "navy-asp"; min = -2; max = 4; }
);

Finally, back on a real screen, so I actually could see what I am copying. The min = -2 should have been min = 2, my apologies. However, It is strange that it seems you can't neutralize escort_roles you need to overwrite it. Maybe Admiral phkb knows a solution.

[Old Murgh]

Code: Select all

this.allowSpawnShip = function(shipKey)
{
   var gov = system.info.government;
   var tech = system.info.techLevel;
   
   switch (shipKey) 
   {
	case "my_ship_01":
	case "my_ship_02":
		
           if((gov === 2 || gov === 4) && tech < 6)
              return true;

         break;
               
         default:
            return false;
            break;   
    }
}

The internal variables are for performance and switch offers you to check multiple ships. Not tested and only typed on the board, so no editor check as well. However, I hope it will work.

Confusion stopped me dead in the tracks. This is maybe already more advanced than an example suited for the wiki?

But great, for my own personal ambition: Since I was poised to use shipdata that introduced the ships with their limited appearance range, I was set to experiment with boosting their role odds to have them selected in the systems where they were eligible. The code above sets up a "switch" however, which seems like a more thorough approach, but leaves me confused as to how, and what it demands of having multiple ships use the script..

I see the possibility of interpreting multiple ships in two senses: One script I can apply to the whole entire shipset, or one script to apply to each core ship that can fork to multiple variants?

Code: Select all

	case "my_ship_01":
	case "my_ship_02":

will this list need to cover every ship that will have the script applied? Would "my_ship_01" be she ship key name of the ship replaced or the ship replacer? Or is that respectively 01 and 02?

For now I would gladly start with just an Adder. I want the regular Adder to be replaced by 1 of 3 possible variants. Lets call them RA_adder_brown, RA_adder_green and RA_adder_white.

For my stage 1 learning experience I wouldn't mind arriving at a script that I could apply to the ships that would follow.

(For my stage 5 ambitions, of course I would love to know how to arrive at conditions for variant_brown are only TL1-3 1 with "Poor" in system description, variant_green are TL 2-4, variant_white TL 3-5.. But I'm getting ahead of myself.)

Since I can't wrap my head around it, this is looking messy, but I guess the script in its simplest form would be best to stick to for now.

[Slartibartfast]

Hello

=>TL99

@phkp

sorry for late answer

That line is unnecessary. "context" is passed into the function by the core code when it's checking the equipment item. If you were encountering situations that made that line of code necessary, then something else is happening, and we'd need a bit of context to help out.

..it works as you described // i don't know why, i had that error in my first test ( maybe the well known "not setted brick" )

matthias

[phkb]

I see the possibility of interpreting multiple ships in two senses: One script I can apply to the whole entire shipset, or one script to apply to each core ship that can fork to multiple variants?

The switch allows you to make choices per ship data key. And it is the ship data keys you have in your shipdata.plist file where the condition script has been added.

If you want to apply something to all ship keys where the condition script is applied, then the switch is unnecessary. Just have the "if" statement and you're good to go.

If you want to keep the switch, then there are certain rules you need to follow.

A switch statement is structured like this:

Code: Select all

    switch (thing_to_switch_on) { // "thing_to_switch_on" is the data element you want to base your switch on
    	case "type 1": // this is the first possible option
    		// ...code specific to type 1
    		break; // you must "break" out of the switch after executing switch code
    	case "type 2": // this is the second possible option 
    		// ...code specific to type 2
    		break;
    	case "type 3": //
    	case "type 4": // we're combining these 2 options
    		// ...code specific to types 3 and 4
    		break;
    	default: // if none of the above were found, this is the "catch any other type" part of the switch
    		// .. code for any other type
    		break; // technically this isn't needed here, but it's useful for ease of understanding and consistency
    }

In montana05's example, the "thing_to_switch_on" is the ship's data key (in the code, defined as "shipKey"). He has defined the switch for two ship keys, and the structure means the same code will apply to both.

Now, if you were to add this condition script to other ship keys in shipdata.plist, in it's current form, they would always be prevented from spawning, because the "default" part of the switch would come into effect, and that code always returns "false". If you wanted to use the same rules for the new ship as are used for "my_ship_01" and "my_ship_02", then you would just add that key immediately under the existing ones, like this:

Code: Select all

		case "my_ship_01":
		case "my_ship_02":
		case "my_ship_03":

If, however, you wanted a different set of rules to apply, you'd need to define a new section in the switch, and put the rules in there.
For example:

Code: Select all

		case "my_ship_03":
			if (gov == 3 && tech < 4)
				return true;
			break;

Hopefully that helps a bit in understanding the code.

[phkb]

However, It is strange that it seems you can't neutralize escort_roles you need to overwrite it. Maybe Admiral phkb knows a solution

That's pretty much what I had to do in Station Dock Control. Here's an example:

Code: Select all

	"dock_anaconda" = {
		like_ship = "anaconda";
		escort_roles = (
			{role = ""; min = 16; max = 16;}
		);
		roles = "dockonly";
	};

I needed a version of an Anaconda that didn't have any escorts assigned, as I would be adding escorts manually via code.

[Old Murgh]

..Hopefully that helps a bit in understanding the code.

Great, thank you for the pedagogic elaboration.
This should keep me engrossed for quite for a while.