Bug, or...?

[Paradox]

To make a long story short(er), in attempting to "hard code" a set number of "un-sellable" passenger berths into a ship using the shipyard.plist and Smivs script from his YellOo Cabs oxp, I assigned 4 berths using the following block in the plist:

Code: Select all

		standard_equipment = 
			{
				extras =             
				( 
				"EQ_PASSENGER_BERTH",
				"EQ_PASSENGER_BERTH",
				"EQ_PASSENGER_BERTH",
				"EQ_PASSENGER_BERTH"
				); 
			forward_weapon_type = "EQ_PULSE_PULSE_LASER";
			missiles = 4;
			};

This worked as expected. However, after buying the ship, I purchased an additional berth, then tried to sell the extra berth, and was unable to. This means that any additional berths a player buys, they are stuck with! This is a scripting issue and I am communicating with Smivs to address this right now.

However I began to also wonder if I could then restrict the purchase of any additional berth altogether by removing them from the ""optional_equipment" =" section of the list, which now appears thus:

Code: Select all

		"optional_equipment" =
			(
			"EQ_ADVANCED_COMPASS",
			"EQ_CARGO_BAY",
			"EQ_DOCK_COMP",
			"EQ_ECM",
			"EQ_ENERGY_BOMB",
			"EQ_ENERGY_UNIT",
			"EQ_ESCAPE_POD",
			"EQ_FUEL_INJECTION",		
			"EQ_FUEL_SCOOPS",
			"EQ_GAL_DRIVE",
			"EQ_HEAT_SHIELD",
			"EQ_MULTI_TARGET",
			"EQ_NAVAL_ENERGY_UNIT",
			"EQ_NAVAL_SHIELD_BOOSTER",
			"EQ_SCANNER_SHOW_MISSILE_TARGET",
			"EQ_SHIELD_BOOSTER",
			"EQ_WEAPON_BEAM_LASER",
			"EQ_WEAPON_PULSE_LASER",
			"EQ_WEAPON_MILITARY_LASER",
			"EQ_WEAPON_MINING_LASER"
			);

And this is why I am here now! };] After making that change and restarting Oolite ( I use the hard coded cache flush) I found the ship for sale (lucky first try!), purchased it, then went to the F3 screen to outfit it. Here's where things get odd because, there for sale was the option to purchase additional passenger berths?!? I was able to buy it, then unable to sell it (as expected for now). Shouldn't taking it out of the optional equipment remove it from the F3 screen despite assigning them as standard equipment?

[cim]

Shouldn't taking it out of the optional equipment remove it from the F3 screen despite assigning them as standard equipment?

Not in this case, because EQ_PASSENGER_BERTH has

Code: Select all

			available_to_all = true;

which means that it can be fitted to any ship without needing to explicitly be on that ship's optional equipment list.

[Paradox]

Shouldn't taking it out of the optional equipment remove it from the F3 screen despite assigning them as standard equipment?

Not in this case, because EQ_PASSENGER_BERTH has

Code: Select all

			available_to_all = true;

which means that it can be fitted to any ship without needing to explicitly be on that ship's optional equipment list.

Ah! okay that explains that then! };] Thanks Cim! So I guess I either track that setting down and change it, or see if Smivs comes up with tweaks for his script.

[Paradox]

This is why I. Do. Not. Code!
Tracked down the passenger berth in the equipment.plist... changed the line mentioned above so that it now reads thus:

Code: Select all

	( /* Passenger Compartment, like missiles this can be bought multiple times */
		5, 8250, "Passenger Berth - takes up 5t of cargo space",
		"EQ_PASSENGER_BERTH",
		"Provides life support, entertainment and comfort for a single passenger.",
		{
			available_to_all = false;
			available_to_NPCs = false;
			condition_script = "oolite-conditions.js";
			requires_cargo_space = 5;
			damage_probability = 0;

Started Oolite (hard coded cache flush), bought the ship, made sure it still shows 4 pre-installed berths, hit F3... and the option to buy more is still there... Keyboard keys are now embedded in my forehead...
Where do I look next?

[cim]

Ah. Passenger berth additional and removal is a special case in the code (indeed, the entire passenger berth is a special case: it only looks like it's equipment but it isn't really). Normal equipment conditions like "available_to_all" are therefore not checked. However, you can get it with a condition script.

Set

Code: Select all

condition_script = "myoxp-conditions.js";

on both the berth and the removal.
Then a new file Scripts/myoxp-conditions.js has:

Code: Select all

this.name = "Passenger berth conditions";

this.allowAwardEquipment = function(equipment, ship, context)
{
	// OXP hook to allow stations to forbid specific equipment
	if (context == "purchase" && player.ship.dockedStation && player.ship.dockedStation.scriptInfo["oolite-barred-equipment"])
	{
		if (player.ship.dockedStation.scriptInfo["oolite-barred-equipment"].indexOf(equipment) != -1)
		{
			return false;
		}
	}

	if (context == "purchase" && ship.dataKey == "myoxpship-player")
	{
		return false;
	}

	// otherwise allowed
	return true;
}

Replace "myoxp" in the script name with something more suited to your own OXP, and replace "myoxpship-player" in the script file with the shipyard key for your ship. The ship will then not be able to change its number of passenger bays, but other ships will still be able to buy and sell them as normal.

[Paradox]

Ah. Passenger berth additional and removal is a special case in the code (indeed, the entire passenger berth is a special case: it only looks like it's equipment but it isn't really). Normal equipment conditions like "available_to_all" are therefore not checked. However, you can get it with a condition script.

Set

Code: Select all

condition_script = "myoxp-conditions.js";

on both the berth and the removal.
Then a new file Scripts/myoxp-conditions.js has:

Code: Select all

this.name = "Passenger berth conditions";

this.allowAwardEquipment = function(equipment, ship, context)
{
	// OXP hook to allow stations to forbid specific equipment
	if (context == "purchase" && player.ship.dockedStation && player.ship.dockedStation.scriptInfo["oolite-barred-equipment"])
	{
		if (player.ship.dockedStation.scriptInfo["oolite-barred-equipment"].indexOf(equipment) != -1)
		{
			return false;
		}
	}

	if (context == "purchase" && ship.dataKey == "myoxpship-player")
	{
		return false;
	}

	// otherwise allowed
	return true;
}

Replace "myoxp" in the script name with something more suited to your own OXP, and replace "myoxpship-player" in the script file with the shipyard key for your ship. The ship will then not be able to change its number of passenger bays, but other ships will still be able to buy and sell them as normal.

Dizzy...! I was so excited when I first read this. Cut and paste! I can do that!
However... ( ) I started to think... (don't even go there...)

Code: Select all

condition_script = "myoxp-conditions.js";

You are saying to change this in the equipment.plist correct? I do remember there being a "condition_script =" setting there for the passenger berths as well as the removal of same. If so, then this isn't really a "fix", as this would require everyone to go in and make that change... No, I am missing something here... Does that perhaps go in the shipdata.plist? Can you make a "condition_script =" call in there??? Or do I need an equipment.plist override of some kind? I haven't had to get into this stuff before because CODING! };] But an override would "override" the default plist and affect all ships again, so that can't be it... ? (ouch... brain hurting now...)
Sorry Dizzy, you gonna have to explain this one in "Coding for Inbred Troglodytes" terms ('cuz I don't think Coding for Dummies is gonna cut it in my case!).

[Diziet Sma]

Dizzy...!
...
Sorry Dizzy,

Umm.. this was cim's work.. not mine..

[Paradox]

Dizzy...!
...
Sorry Dizzy,

Umm.. this was cim's work.. not mine..

How did I make that mistake? Sorry to both you and Cim!
(I thought it was odd that Dizzy was suddenly spouting code like a pro! I mean after all, it is Dizzy we are talking about here!};])
So please take out all the "Dizzy" references in the above post, and insert Cim instead. Thank you.

[Diziet Sma]

(I thought it was odd that Dizzy was suddenly spouting code like a pro! I mean after all, it is Dizzy we are talking about here!};])

Oh, I can code, albeit rustily.. and in several languages, at that.. but Objective C and Javascript (or any other scripting language, for that matter) ain't amongst 'em!

[cim]

You are saying to change this in the equipment.plist correct? I do remember there being a "condition_script =" setting there for the passenger berths as well as the removal of same. If so, then this isn't really a "fix", as this would require everyone to go in and make that change...

If you have an entry in your OXPs equipment.plist with the same equipment key as the entry in the core equipment.plist, the OXP entry will override the core one for as long as the OXP is installed.

The first half of the "allowAwardEquipment" function is to duplicate the core condition script's effects on passenger berths to avoid affecting other OXPs, so there shouldn't be any compatibility issues from doing so (unless you want to install two OXPs which make different changes to the passenger berth conditions, of course)

[Paradox]

You are saying to change this in the equipment.plist correct? I do remember there being a "condition_script =" setting there for the passenger berths as well as the removal of same. If so, then this isn't really a "fix", as this would require everyone to go in and make that change...

If you have an entry in your OXPs equipment.plist with the same equipment key as the entry in the core equipment.plist, the OXP entry will override the core one for as long as the OXP is installed.

The first half of the "allowAwardEquipment" function is to duplicate the core condition script's effects on passenger berths to avoid affecting other OXPs, so there shouldn't be any compatibility issues from doing so (unless you want to install two OXPs which make different changes to the passenger berth conditions, of course)

Okay, I think I am beginning to understand. I am going to create an equipment.plist, which contains only the 2 sections that concern passenger berths and removal of same. Then I change just the line that references the "condition_script =" , and point it to my script that I will be cutting and pasting from your previous post };] And the line in the script that reads:

Code: Select all

this.allowAwardEquipment = function(equipment, ship, context)

Is the one that ensures this only affects this particular ship. Am I close or still as clueless as I feel? }:] If I am right, can I then simply reuse this same script and override on other ships as well without them conflicting (I assume I will need to rename them for each oxp)?

[cim]

Okay, I think I am beginning to understand. I am going to create an equipment.plist, which contains only the 2 sections that concern passenger berths and removal of same. Then I change just the line that references the "condition_script =" , and point it to my script that I will be cutting and pasting from your previous post };]

That's correct.

Code: Select all

this.allowAwardEquipment = function(equipment, ship, context)

Is the one that ensures this only affects this particular ship. Am I close or still as clueless as I feel? }:] If I am right, can I then simply reuse this same script and override on other ships as well without them conflicting (I assume I will need to rename them for each oxp)?

This is where it gets slightly tricky. That line tells the rest of the function which piece of equipment, which ship, and which "context" (is it a new ship, an NPC, shipyard purchase, etc) the attempt to add the equipment to the ship is happening in.

The problem with using the same script in other OXPs is that only one version of the equipment.plist can take effect for any given item - so you could only bar one ship from buying and selling this way. If you want to have multiple ship OXPs which all have a fixed number of passenger cabins, you can still do it this way, but the scripting has to be slightly different. In that case, use this slight modification (which is probably better anyway, having thought about it):

Code: Select all

this.name = "Passenger berth conditions";

this.allowAwardEquipment = function(equipment, ship, context)
{
   // OXP hook to allow stations to forbid specific equipment
   if (context == "purchase" && player.ship.dockedStation && player.ship.dockedStation.scriptInfo["oolite-barred-equipment"])
   {
      if (player.ship.dockedStation.scriptInfo["oolite-barred-equipment"].indexOf(equipment) != -1)
      {
         return false;
      }
   }

   if (context == "purchase" && ship.scriptInfo.paradoxPassengerCabin == "fixed")
   {
      return false;
   }

   // otherwise allowed
   return true;
}

That says that ships with a "scriptInfo" key of "paradoxPassengerCabin" equal to "fixed" can't buy equipment with this script attached. Then, in your shipdata.plist you add

Code: Select all

script_info = {
  "paradoxPassengerCabin" = "fixed";
};

to the definitions of the ships you want to do this to. You can then include an identical copy of the equipment.plist and script in each OXP, and since they're all identical it doesn't matter which one takes effect.

[Smivs]

I think (hope?) that I've come up with a simple solution to this. I've written a new ship-script which has a counter for new berths, set to zero when a new ship (with four permanent berths) is bought. Subsequently, each time a new berth is bought the counter increases by one, and each time a berth is sold the counter decreases by one. If the counter is greater than zero when the 'sell berth' option on outfitters is used, the berth is removed, and if the counter is at zero the berth is retained as per the original YellOo Cabs script. Seems to work OK.

@ Paradox - check your PMs

[Paradox]

This is great! I read and replied to Smivs PM before I got here, and am encouraging him to post his script in a new thread. Maybe as a "Scripts and Things for Shipbuilders" thread? };] Basically, his script allows shipbuilders to "hard code" a number of passenger berths, and yet allows them to add more later on if they wish. It also allows them to sell ONLY those extra added cabins, and not the original "built in" berths. Very cool!
However... I also see a definite need to be able to restrict the purchase of a passenger berth altogether, and this is what Cims method achieves so far. I asked Smivs about modifications to his script as there would be time issues involved with it as it now stands...But in any case, I think both of these methods offer shipbuilders a fantastic opportunity to make our ships even more individualistic and specialized. A good example being my upcoming Atlas, It is meant to be a major cargo hauler with passenger capabilities. I think Smivs script will be used here to allow them to add berths if they wish. However, my Galaxy Liner (version 2.0 that is...), is meant to be a passenger ship (with a smallish cargo capacity), and I am going to use Cims method to "hard code" those berths into place. Bottom line, thank you all for your help! Both methods will have their uses and anything that gives us more choices is a GOOD thing!

[Smivs]

It's all pretty simple stuff - basically the removal is nullified by immediately re-awarding a berth and refunding the purchase price.

...as there would be time issues involved with it as it now stands...

The problem here is that 'non-removal' takes the same time as removal, around 27 minutes in game-time. And there is no way of avoiding this as far as I can see. The clock automatically advances as the "EQ_PASSENGER_BERTH_REMOVAL" occurs, and this is beyond OXP control, and you can't wind the clock backwards either. I suppose any request for a 'clock.subtractSeconds' js method would be rejected - imagine the chaos that being able to travel back in time could cause!