I worked on a (in the beginning simple) OXP that grands the option to buy additional cargo space. I found, that I bit off more than I could chew. (But I'm still not done chewing.
) This Post is quite long and I will repeat myself occasionally, but please endure it for a while.
Why is a negative value for available cargo space viewed as such an evil thing? The source code tries everything to prevent it from happening and in a clean, vanilla version it's impossible in oolite to use up more cargo space with commodities and weighted equipment than available. But there are still those evil OXP developers, that dare to dream there twisted dreams of impossible features.
One of those guys (me) tried to create an OXP that grands additional cargo space (No, not hypercargo.) In doing so however he didn't realize, that the cargo space value would be recalculated each time a gamestate is restored (savegame loaded) instead of using the value "max_cargo" from the savegame itself, resulting in losing the additional space.
Unwilling to back down this Ignorant embarked on a foolish quest to create a workaround to breath life into his creation. But it was for naught. Once his creation was of beautiful simplicity, much like his mind, but now it was a code line filled, inflexible mess. And it didn't work right either.
Though he managed to restore cargo space and retrieve standard commodities, that were swallowed by cleansing algorithms, (but not new commodities provided by other OXPs, mind you,) there was this problem with weighted equipment items. Should even 1 ton of them depend on the cargo space provided by his OXP, doom would find its way into the lands and his Cobra MKIII would be stuck with to horrors of the flipped integer curse (a negative free cargo space value represented as a huge positive value, that couldn't be changed any more unless some weighted cargo is being removed). There another_highlyDecorated fairy came to the fools aid. Worried by the bug he uncovered the fairy committed a bugfix and the lands were save again.
But the fool didn't stop there. Ohh no, he didn't! He pondered and pondered over the problem and came to the a conclusion. "I should just use space, that doesn't exist!"
Deal with it reality.
When a savegame is restored the cargo space gets normalized and commodities, that are too much, are deleted. Only afterwards cargo space can be reset and a separately saved commodity manifest can be applied by the OXP again, to the state before saving. But this only works for known commodities at this point.
Also if too many weighted items are installed on the ship, that ship would end up with an negative value for free cargo space. This caused a bug, that another_commander patched, by preventing the weight, that would be too much, from being calculated into the ships cargo space. But if that item is being sold off, it frees up this weight, and therefore adds too much free cargo space to the ship. This might create problems, if not handled properly by the OXP that blew it in first place.
A workaround for this is to always save the ships cargo capacity in a mission variable and its cargo manifest, too. After loading that state an OXP might then reset everything to those values, but this also creates the possible corruption of the cargo space value at some point in the future. This value won't be checked and be taken as a given, even if this value somehow got changed and isn't right any more. Those corruptions already happened in tests of my OXP. And while theoretical working out, every OXP, that expands the cargo space, would have to use this method. That's quite a lot of redundant information being stored and applied over and over again.
One possible solution:
Now imagine negative cargo space values would be possible (without causing a bug). There is a chance, that we might end up with a negative value after loading a state, if the ship was overloaded, because of the additional OXP cargo space. BUT
directly afterwards (maybe in the startUp-phase) the OXP could add
the right amount of space (the "bought" one associated with the installed OXP-item) instead of just overwriting the calculated value with the possible corrupted value from the savegame. We would end up with the "right" (calculated+OXPadded) value. The space would have been recalculated correctly, making a possible savegame corruption, at least in this hindsight, impossible. AND many OXP could use this simpler method without causing troubles or conflicting with each other.
Also, if still in a negative range (which shouldn't have happened at this point) the game might still delete commodities at this point (right after the startUp-phase, before the startUpCompleted-phase). If there still is a negative value (because a OXP has been removed for example), a warning could be given out, the ship might be called somehow overloaded and be less manoeuvrable or something (which would suck at this point, if it can't be undone, but weighted items should always be removable. JustMO.)
There are catches though.
- The whole code has been written with a "no negative values allowed" rule in mind and a "burn it (0 it) till it dies, if it's negative!" approach. Changing that approach that late in the game might be a bold move
. This is where many problems MAY arise, as the rest of the code just doesn't expect a negative value. But it's also possible, that it's just a small change, that works pretty well without causing any trouble after done well.
- While negative values do good for equipment, commodity handling (at least the deleting part) would have to be moved, too. This might also cause troubles as scenario handling is also in between somewhere there and moving parts might also mess things up. (I myself haven't been able to see though the whole commanderDataDictionary
method, but I will try my very best to do so.)
Final words (of this posting):
Allowing cargo space to be added is only one feature and one might ask if it's worth the trouble. But the cargo space value is also one of the most important factors in oolite and the freedom to manipulate it in a civil manner without too many out of the world workarounds&hacks is pretty important, too.