Two equipment-related requests

[Thargoid]

Based on discussions in my APRIL OXP thread - firstly can I request a new equipment.plist key which indicates how much (cargo) space a piece of equipment requires? But as distinct from the existing similar key (requires_cargo_space), the purchase of that equipment actually removes that amount of available cargo space (like the passenger berth does). Either that or change requires_cargo_space to actually remove that amount of cargo space?

Secondly, for practicality could an equipment-override.plist file be implemented, in the same way as the current shipdata and shipyard ones, for the same basic idea (to enable "on the fly" tweaking of existing equipment.plist files without having to overwrite them).[

[Eric Walch]

Its not the first time this question comes up. another_commander also made start on this but gave up. The whole calculation of free space is a mess of patches. Changing it at one place is likely to break it at another place. A change would probably need a full rewrite of the whole concept of space. At first glance it looks doable but difficult. At least that was what I thought when I looked at it two years ago.

[Thargoid]

I know, but we've had a few things achieved lately which were tried and failing in the past, so thought it worth a shot.

One idea I was pondering last night was perhaps an extension to Wildeblood's thinking. What if we had an additional cargo type (for example "equipment") which is accessible by scripting, but could not be bought/sold on the market screen (although could perhaps be displayed there). It would count against your held cargo amount, and equipment which required space would only be purchasable if the hold space was available.

Then if the equipment is bought a suitable amount of "equipment" cargo is also bought by the script, and if it's removed then that amount of cargo could be "sold" to reserve and release the required space.

Would a concept like that work? Of course it would need OXP scripters to be quite strict in how they "buy and sell" such space, but that could perhaps be done via suitable trunk API's?

[Eric Walch]

One idea I was pondering last night was perhaps an extension to Wildeblood's thinking. What if we had an additional cargo type (for example "equipment") which is accessible by scripting,

I have the feeling that this would lead to even more patching on patching. When doing it, it should go through the existing requires_cargo_space property we already have. I think when strictly keeping the cargo space used by equipment in a separate variable throughout the code, everything will eventually fall on its place when changing things and save files will stay compatible between versions. It still will be a lot af work and lead to intermediate versions with bugs. (At least I don't think it will be 100% correct at the first time )

[Thargoid]

What, code that doesn't work 100% perfectly first time?

The required_cargo_space could perhaps be used to "buy" the equipment space I mentioned, plus it would be fairly backward compatible as I presume there's already code in place to catch having more cargo than space for it?

The space used by equipment would already be a separate variable (the hidden equipment cargo) - I wouldn't envisage it being accessible via the manifest.

But anyway, you're certainly right that it'll be a challenge to do - maybe a trick was missed a few versions back when the manifest was introduced. That would have been the ideal time for such a clean-up.

[Kaks]

I've had a quick look at the way adding passenger berths works, and it's not pretty. Berths are handled as a very special case, and there's no provision in the existing code for a more generic way of handling required_cargo_space. And, well, there are other factors, apart from figuring out a way of coding in the extra flexibility: indeed, it looks to me that the whole subject is pretty much a minefield!

I'll expand on that thought!
So far, required_cargo_space was just used to see if the extension was offered or not, but adding/removing berths was hard coded to 5 tons anyway.

As an experiment, I've made passenger berths actually respect the required_cargo_space set in equipment.plist. It's in trunk now, so you can do some experiments too using the nightly build.

Changing required_cargo_space in equipment.plist to - say - 7 instead of 5 does modify the total available cargo space as expected.
However, and that's the problem, it does that retroactively too. There's simply no space for 5 tons berths in a 7 ton berths universe.

I created a few example savegames with a standard cobra3, to see what would happen.

Before: cobby with cargo bay expansion, 2 passenger berths, and 25 tons of cargo. After:2 passenger berths, and 25 tons used out of 21 available. However, we'll have to remove the extra 4 tons of cargo somehow. This would cause 'a few' problems to contracts: making the savegame consistent with the new ooniverse parameters will potentially make some already taken contracts impossible to fulfil.

And a cargo bay expanded cobby with 7 full passenger berths will load as having 5 passenger berths. Mercifully, instead of killing 2 passengers at random, it will spare the lives of all surplus passengers. Of course, this state of affairs cannot be allowed to continue, so in future any supernumerary passenger will be kindly escorted to the nearest airlock when loading a savegame. Intriguingly, after noticing that we can't have more than 5 berths to fill the 35 tons, the available cargo calculation gets 'slightly' broken, and we magically get 35 tons of available cargo space once again, to do whatever we like with it!
'Unfortunately' it's not quite recursive, so no matter what I do I can't seem to get more than 10 7 tons berths... Again, that can't be allowed to continue!

Fun fact: upping the number of berths from 7 to 8 inside the savegame shows the same extra cargo space bug in 1.76! A fix for trunk & maintenance is coming asap!

In any case we now know that the answer to:

The required_cargo_space could perhaps be used to "buy" the equipment space I mentioned, plus it would be fairly backward compatible as I presume there's already code in place to catch having more cargo than space for it?

Is "nope, there isn't." There's a number of checks in place to try and avoid getting more cargo than available cargo space. As a consequence - and thanks to us humans being so wonderfully complacent at times - no-one seems to have anticipated the need to add such a check when loading games. Not too much of a biggie in and of itself, that check is in the TODO list for 1.77/1.78 now.


However, at the moment, I get the feeling that my experiment with 'flexible berth space' is indeed going to stay just that, an experiment.
We're just talking about 1 piece of equipment with this capability, and it already looks like presenting us with a very non-trivial problem:

Enabling all equipment to potentially disrupt savegames retroactively doesn't 'quite' seem right. It's all too likely that a player might not notice their cargo 'slimming down' after adding oxp 'X', and to overwrite their savegame with reduced cargo as a consequence. Adding notices & readmes might not really be an effective solution, as per the amount of RT(F)Ms abundantly peppering forums everywhere.
At the same time, allowing older savegames to load a ship with cargo space altering equipment that doesn't actually alter cargo space doesn't seem right either. I believe we're at an impasse, as it where.


As A_C already pointed out, this is pretty much a Frontier-like feature. Without Frontier to 'show us the way' I doubt we'd even think in terms of cargo-taking equipment. After all, adding a CD player to a van requires finding space on the dashboard, not shrinking the cargo compartment....

Anyway, if we can figure out a solution to this impasse, I'm more than happy to investigate the possibilites!

[Commander McLane]

After all, adding a CD player to a van requires finding space on the dashboard, not shrinking the cargo compartment....

Adding a CD changer, on the other hand...

[CommonSenseOTB]

I have an idea

Wasn't there a conversation by someone a long long time ago about this and one thought put forward was the idea of equipment_space? Perhaps we could leave cargo space alone and make a new variable that is hard wired to the max cargo capacity of a ship, say 20% to 30%, perhaps with a hard ceiling of 50 units because of power requirements and rounded up to the nearest unit. Oxp authors could still make computers and software and other knick knacks take no equipment space but set a value for the big stuff.

[Thargoid]

Two points (mainly @ Kaks):

1) No-one is talking about making cargo berths take more space, they can happily stay at 5t and so there's no retroactive breakage. And as required_cargo_space isn't (to my knowledge) used by anything else (because it basically doesn't work) then there should be no other backward compatibility issue anyway.

2) The only point at which a clash needs to become a concern is the first time a save game is loaded with the new (hypothetical) code active. At that point I'd be more inclined to dump the equipment affected as incompatible with the ship in its current state rather than the cargo. Yes it will cost credits and be perhaps inconvenient, but as you say it may be a "lesser evil" than dumping cargo. But it will be a one-off hit for the version-up, and then life can continue as normal. And it'll have to happen at some point when the code mess does get tackled I would guess.

[Kaks]

The passenger berths thing is a quick example of what could easily happen in the future if someone adds a different oxp with different ideas of what equipment requires cargo space, and what doesn't.

Having different OXPs with different equipment-overrides.plist containing conflicting required_cargo_space setting would make the 'only once' concept well, not that clear cut, to say the least.

Getting in a situation where trying out an oxp can affect your Oolite 'career' by either jettisoning cargo or equipment based on any preset concept of what's better for the player, and depending on exactly which oxps & oxp versions are loaded seems a step too far to me.


However, I believe the idea CSOTB mentioned might actually be more easily integrated in the game... an equipment_space shipdata.plist key (proportional to the max cargo setting unless unless explicitly set) plus an equipment_space_used key inside equipment.plist (proportional to the equipment price unless explicitly set) and once the equipment_space_used is greater than the ship's equipment_space no more equipment is buyable should allow for the kind of tweakage you're talking about. The good bit about this idea is that it won't actually affect cargo space one way or another.

To make any such concept (either your original idea or CSOTB's) work properly from a player's perspective, I'm afraid we'd have to support selling equipment in the core game though, which is yet a bit more work, in addition the the lot of work Eric mentioned.

BTW, as of rev4871 passenger berths are again taking up 5 tons regardless of what required_cargo_space says, as always.

[Wildeblood]

When I experimented with this idea last year, I utilized ("re-purposed " for younger readers) the extended cargo bay, and mission profile determined "equipment packs". (I was much influenced by the US Navy's littoral combat ship, and obviously Gerry Anderson, too) So on the F3 screen I'd click "reconnaissance mission pack" or some such, and the cloak, masc'm & whatnot would be added to the ship and the extended cargo bay simultaneously removed. As long as the mission pack had the extended cargo bay as required equipment and requires empty space set to the same size as the cargo bay it worked. I lost interest in that idea because I couldn't think of many mission profiles; I had stealthy recon or mining, and not being able to switch the mining vs. military lasers by script was frustrating. (You know I don't handle frustration well, Kaks.)

[Eric Walch]

Enabling all equipment to potentially disrupt savegames retroactively doesn't 'quite' seem right. It's all too likely that a player might not notice their cargo 'slimming down' after adding oxp 'X', and to overwrite their savegame with reduced cargo as a consequence. Adding notices & readmes might not really be an effective solution, as per the amount of RT(F)Ms abundantly peppering forums everywhere.
At the same time, allowing older savegames to load a ship with cargo space altering equipment that doesn't actually alter cargo space doesn't seem right either. I believe we're at an impasse, as it where.

I now used another approach. That the EQ_PASSENGER_BERT and EQ_EXTRA_CARGO equipment change the max_cargo value in the save game is a burden we can't change without loosing compatibility with the old saved games. I now tried an other approach were I keep count of the weight of all the other equipment (except those two). It is not saved but calculated on adding or removing the equipment. My first tests seem to show it works as it should. The value defined in requires_cargo_space is now consequently reduced from the available cargo in the hold.

Doing this, I found a new bug:
My testship was a boa II and when trying to add a EQ_EXTRA_CARGO by script worked. And this type of ship is not allowed to have that equipment. It seems that the addEquipment always skipped that test. I went back to 1.73 and there is was already wrong.
The good thing is that I fixed it now in my test version. This fix will probably also go to 1.76 maintenance.

[CommonSenseOTB]

<fingers crossed>

[PhantorGorth]

Just some thoughts on handling the change to OXP that can impact the max_cargo value or don't have room for.

1)
a) How about a test before the save game is loaded to see if current OXPs would cause a problem because you have cargo/berths/equipment capacity issue. If it does then a compatibility warning appears at the save game loading stage and you then have the option either to not load that save game or remove equipment/cargo/etc that will cause problems (not quite sure how this would be decided).

b) If the size of something can be changed via JS then it should fail if it causes a problem (with an appropriate false returned from the function). A "test if possible" function could then be created for OXP to test this before doing it. Maybe the function should have parameters that allow for eject/sell random cargo to make space or remove passenger berths to make room.

c) Equipment that requires space you haven't got, or could never have, would not appear on the equipment screen.

2) Another idea is to allow at save game load is temporary over capacity. If it is say on load you have 4 tons over what you should be allowed the max_cargo value is upped by 4 until you reduce your use of cargo space. if I sell one ton of cargo then the max_cargo value is now 3 over instead of 4. Also passenger berths with passengers are included the temporary over capacity but if they are empty they are removed instead.

These ideas should cover the issue. Not that I think it would be very easy to implement.

[Eric Walch]

Just some thoughts on handling the change to OXP that can impact the max_cargo value or don't have room for.

1)
a) How about a test before the save game is loaded to see if current OXPs would cause a problem because you have cargo/berths/equipment capacity issue. If it does then a compatibility warning appears at the save game loading stage and you then have the option either to not load that save game or remove equipment/cargo/etc that will cause problems (not quite sure how this would be decided).

If an oxp equipment has claimed space and it was a 1.76 save game, the trunk version now will just ignore that equipment when there is no longer space for it. (no warning to the user, other than a log line probably).
Kaks already added check to trunk that when there is more cargo in the hold than could fit the bay, the excess of commodities is removed until it fits. Starting at the top with food. Although I think this will only kick in when the player edited his saved game to illegal quantities.

b) If the size of something can be changed via JS then it should fail if it causes a problem (with an appropriate false returned from the function). A "test if possible" function could then be created for OXP to test this before doing it. Maybe the function should have parameters that allow for eject/sell random cargo to make space or remove passenger berths to make room.

c) Equipment that requires space you haven't got, or could never have, would not appear on the equipment screen.

b and c already happen since long ago. the requires_cargo_space was always used to decide if equipment could be added. The strange thing was just that, when added, it did not use the space. Except for the passenger_berth that had some hardcoded exceptions.

EDIT: implemented the changes in trunk with r4905