Troubles with adding cargo space/Ways to solve them.

[phkb]

ocz, I was thinking about your issues with adding cargo space and I'd like to offer a suggestion on ways to implement the idea. I think it's fair to say that attempting to update max_cargo at "startUp" or "startUpComplete" is too late. Too many things have been set up, you can't tell the order in which things will be changed, and the likelihood of OXP conflicts are huge.

I think your best bet is to work with shipdata-overrides.plist. Be aware I haven't tested what follows, but it at least works in my head!

Make a change like this:

Code: Select all

// shipdata-overrides.plist
{
	"oolite_template_adder-player" = {
		max_cargo = 10;
	}
}

That will change the Adder's default max_cargo from 2 to 10.
Next, create a series of "filler" equipment items, that take up cargo space but are not visible on the F5 screen.

Code: Select all

// equipment.plist
{
	(
		0,
		1,
		"FillerSpace1",
		"EQ_FILLERSPACE_1",
		"Virtual filler space 1t",
		{
			"available_to_all" = yes;
			"available_to_NPCs" = no;
			"available_to_player" = yes;
			"condition_script" = "cargospace_conditions.js";
			"damage_probability" = 0.0;
			"requires_cargo_space" = 1;
			"visible" = no; // listed on the F5F5 screen.          
		}
	),
	// you'll need more of these items, from 1 to 10t, or more depending on how much additional space you will potentially want to add to ships
}

The "cargospace_conditions.js" would look like this:

Code: Select all

"use strict";
this.name        = "CargoSpace_Conditions";

this.allowAwardEquipment = function(equipment, ship, context) {
	if (context == "scripted") return true;
	return false;
}

With those things set up, it should be just a matter of adding the appropriate filler items to the player ship to take away the extra space. Because the shipdata-overrides.plist change happens before any cargo or passenger berths take place, you shouldn't have to worry about monitoring cargo or passengers and making sure they are added back if they get lost.

To purchase additional cargo space, it should be a simple matter to swap out the old filler item and putting a smaller one back. Instant extra space.

Anyway, as I said I haven't tested this, but it seemed like a viable way to add space without disrupting lots of other components of the system.

[ocz]

ocz, I was thinking about your issues with adding cargo space and I'd like to offer a suggestion on ways to implement the idea. I think it's fair to say that attempting to update max_cargo at "startUp" or "startUpComplete" is too late. Too many things have been set up, you can't tell the order in which things will be changed, and the likelihood of OXP conflicts are huge.

I'm very aware of that sad fact. When I knew I had to restore the commudities in the startUp-phase, I was still taking the risk of adding commodities to late for other OXPs (maybe missions that checked them) in the hope, that most OXPs would do this kind of checks in the startUpCompleted-phase. When I realized that equipment items would have to be restored too and I slept one night over it, I was really close to abandoning the jscript approach I took.

But the script was nearly done, so I wanted to finish it and publish it. If OXP developers just follow some simple rules of logic (initialize and set your OXP a late as possible if possible, which is in most cases a good idea. A luxury dev.s using this script don't have. ) and maybe if there are a few tricks to make it so, that it the script runs as soon as possible, it might still prove to be useful. (Is there a way to run it as early as possible? I read something about in [wiki]Handling OXP Dependencies with JavaScript[/wiki] about alphabetic order, that's not reliable. And can OXPs using this script be identified and called by it? var names = somethingSomething.worldScriptThatStartWithInItsName("OXPACSW");) All this might be wishful thinking. Maybe someone could use it for an closed OXPmod project of his/hers.

Well, it is now really done, as I really believe I have implemented the handling of everything. From commodities to passengers. But it's to late today to create a thread. There surly still are bugs and thing I forgot and it's ugly and parts surly could be be done better, but I outfitted a sidewinder with 23t space and a lot of equipment today and didn't lose anything. Looks good.

Your approach looks good, but one has to make sure, that only altered ships are outfitted with those filler items or else,... well, not so pretty. It should be usable for all standard ships. A good approach.

[phkb]

one has to make sure, that only altered ships are outfitted with those filler items or else,... well, not so pretty.

Using this approach, the downside if a ship is missed when allocating the filler item is that it gets some extra cargo space for free. The downside of the other approach is that potentially cargo, passengers or equipment is lost. If it's a matter of looking at potential flow-on consequences then I know which I'd prefer!

If OXP developers just follow some simple rules of logic...

This is a bit of an assumption. OXP developers come from a variety of backgrounds, not all of them software development. Plus, there are a lot of unsupported OXP's that are still widely used. And even if developers set things up as late as possible, it still might not be late enough, as you've noted.

There will certainly be value in the code, and bits will undoubted be useful to others. And I'm sure you've learned heaps about the intricacies of Oolite Javascript in the process!