Troubles with adding cargo space/Ways to solve them.

[ocz]

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.

Question: 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.

Storytime: 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.

Summary: (Problem) 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.

[Cody]

Too much boffinry for a dumb pilot such as myself, so I can't really comment.
Don't expect much - even when the forum is busy, polls get little response.

[Smivs]

There was a bug allowing negative cargo space a long time ago (and indeed I exploited it) but this was fixed in Oolite v1.76.
Re the poll, I went for the missing option which is that the code does not need changing as it is not broken.
Personally I have issues with the proposition that these ships have infinite space available within them. They don't. They are probably already crammed with stuff and magic-ing more space out of nowhere is daft. This is why I like the idea that some equipment requires space (and wouldn't mind at all if this was extended to some core equipment). I don't really even like the core Cargo Bay Extension for this reason.
No, leave things as they are, and if you need more holdspace, buy a bigger ship.

[ocz]

Thank you already for reading through that whole stuff. I wait a while with a reply to see where this threat is going.

Too much boffinry for a dumb pilot such as myself, so I can't really comment.
Don't expect much - even when the forum is busy, polls get little response.

I'll keep that in mind.

[gizmo]

No, leave things as they are, and if you need more holdspace, buy a bigger ship.

This!

[phkb]

While I'm not against the idea, I think the implementation of it should be done by creating new ship definitions in a shipdata.plist file, then using ship storage helper to switch the players ship to it, like I'm doing with ship respray OXP. All you'd have to do is use "like_ship" to link up your definition to the original, then redefine the "max_cargo" value to whatever you like. The down side is that you'd have to create a definition for each ship you want to adjust the cargo for.

That being said really you should just be buying a new ship with extra cargo space anyway. Using a modern equivalent, if I bought a small car but then needed more internal luggage space (excluding the options of installing roof racks plus pod, or attaching a trailer, both of which are external) I'd have to buy a larger new car.

[Fritz]

To be honest, I found the idea of increasing cargo space (from 20 to 35 t) strange even 30 years ago on the C 64. A ship has well defined external dimensions, and increasing cargo space would mean extending the hull or at least the fitting of stronger engines (if not space but weight is the limiting factor).

But there are so many OXPs that can change the game in ways I had never expected to be possible, so allowing to manipulate cargo space without building a new ship probably can be justified if it can be done simply and doesn't cause new problems with the core game or existing OXPs.

But I can accept this only because the core game can do this kind of magic with the cargo bay extension. To be even more honest, I would prefer to dump the cargo bay extension completely! But it's original Elite, so I can live with it.

PS: I'm missing the option "I dislike the idea of cargo space manipulation, but I would not oppose it if somebody implemented it."

[ffutures]

I have no problem with the idea of hull extensions of relatively small fixed size that simply add cargo capacity - I think of them as reconfiguring internal components to free up some wasted space. Apart from anything else, the Cobra III hull extension is a BIG step forward fairly early in the game, it would make the early stages much slower if it was dropped.

I don't like the idea of just cramming stuff in indefinitely. I think of most of the standard components as being designed in from the outset, e.g.
- all ships have provision for two energy units
- most of the avionics improvements are adding another card / processor / program to the ship's computer
- lasers are standard sized modules, installing them is more complicated for military lasers which is why it takes longer
- There's an escape pod bay in every hull, it's illegal to use the space for anything else
and so forth.

But right from the start passenger bays have taken up cargo space, it seems plausible that other large equipment items also need some space. Being able to negate that would really detract from realism.

[ocz]

I have written a workaround jscript for this problem, that can be used by OXPs. I'll create a link here, when I'm done writing a thread in Expansion Pack. But the problem still stands, that this workaround must be implemented by every OXP, that wants to expand the cargo space or ELSE! A solution source code wise would be much better.

Well, of course such a feature could be abused to create gigantic cargo holds in the tiniest ships, but you can also already build deathlaser, money generator and hyperhyperspeed drive OXPs. Unbalanced OXPs are unbalanced OXPs.

Also initially I was trying to create an "upgrade" (My ACSA OXP) available for all ships. I didn't want to create another OXP ship. Of course I also could have tried to modify the known standard ships into getting bigger holds, but then what about OXP ships? In most cases I try to write OXPs that are compatible with other OXPs and maybe even useful in there "changed rules" universe. (ACSA came to live because I wanted the Adder to have a 5t cargohold (before I noticed spara already gave it a cargo bay expansion to 5t). But what about the mamba, the kraite and of course the asp? A little bit more would be very desirable! And it wouldn't break the game. Just let it be expensive!)

@fritz: In all honesty, I did find it strange, too. (Even back when playing X) But as you said, it is part of the game play. And it makes things interesting. "Another step to victory. (Whenever you have the feeling to have archived it.)"

But there are so many OXPs that can change the game in ways I had never expected to be possible, so allowing to manipulate cargo space without building a new ship probably can be justified if it can be done simply and doesn't cause new problems with the core game or existing OXPs.

That's why I'm in favour of implementing it into the source. Than there is no harm done and same rules for everyone.

I think of them as reconfiguring internal components to free up some wasted space.

That's the spirit! As long as the OXP developers can come up with a justifiable explanation, everything works out.

Also @ffutures: There is a OXP that does what you want. Adjusting a standard ship with better engines, more energy banks, but they do weight a lot and make the ship slower... I couldn't find it now (I don't remember it name), but it's quit big and does its stuff quite well from the looks of it. This threat is somewhere in "Expention Packs" I believe. If I find it I'll post the link.

Edit:

phkb's Ship Configuration: viewtopic.php?f=4&t=17842
Great oxp, but that's just me, imho. Adds the feeling of creating and tinkering with a Character/Avatar in RPGs to your ship.

That one.

[Amah]

phkb's Ship Configuration: https://bb.oolite.space/viewtopic.php?f=4&t=17842
Great oxp, but that's just me, imho. Adds the feeling of creating and tinkering with a Character/Avatar in RPGs to your ship.

[ffutures]

I have written a workaround jscript for this problem, that can be used by OXPs. I'll create a link here, when I'm done writing a thread in Expansion Pack. But the problem still stands, that this workaround must be implemented by every OXP, that wants to expand the cargo space or ELSE! A solution source code wise would be much better.

Well, of course such a feature could be abused to create gigantic cargo holds in the tiniest ships, but you can also already build deathlaser, money generator and hyperhyperspeed drive OXPs. Unbalanced OXPs are unbalanced OXPs.

Also initially I was trying to create an "upgrade" (My ACSA OXP) available for all ships. I didn't want to create another OXP ship. Of course I also could have tried to modify the known standard ships into getting bigger holds, but then what about OXP ships? In most cases I try to write OXPs that are compatible with other OXPs and maybe even useful in there "changed rules" universe. (ACSA came to live because I wanted the Adder to have a 5t cargohold (before I noticed spara already gave it a cargo bay expansion to 5t). But what about the mamba, the kraite and of course the asp? A little bit more would be very desirable! And it wouldn't break the game. Just let it be expensive!)

@fritz: In all honesty, I did find it strange, too. (Even back when playing X) But as you said, it is part of the game play. And it makes things interesting. "Another step to victory. (Whenever you have the feeling to have archived it.)"

But there are so many OXPs that can change the game in ways I had never expected to be possible, so allowing to manipulate cargo space without building a new ship probably can be justified if it can be done simply and doesn't cause new problems with the core game or existing OXPs.

That's why I'm in favour of implementing it into the source. Than there is no harm done and same rules for everyone.

I think of them as reconfiguring internal components to free up some wasted space.

That's the spirit! As long as the OXP developers can come up with a justifiable explanation, everything works out.

Also @ffutures: There is a OXP that does what you want. Adjusting a standard ship with better engines, more energy banks, but they do weight a lot and make the ship slower... I couldn't find it now (I don't remember it name), but it's quit big and does its stuff quite well from the looks of it. This threat is somewhere in "Expention Packs" I believe. If I find it I'll post the link.

Edit:

phkb's Ship Configuration: viewtopic.php?f=4&t=17842
Great oxp, but that's just me, imho. Adds the feeling of creating and tinkering with a Character/Avatar in RPGs to your ship.

That one.

I'd be happier losing some cargo space to get more performance - making ships slower and stodgier is not my idea of fun!

[ocz]

I thought that OXP was all about pimping your ship. Like adding stronger thrusters for example, but I didn't test it so far.

Edit:
Ranting: (Just skip it.) I promised a workaround script earlier, but every time I finish it something new pops up. This time I found out, that weighted equipment, that has no place left, when the gameengine restores a savegame, doesn't get added and therefore is deleted much like commodities, that have no space.

This means I had to create a missionVariable for them, too. And a parser of cause. (Both mostly done.) This script gets larger and larger. I still haven't finished it. But guess what. Passenger Berths are omitted, if there is no place for them, too. I have to look into it, but I fear I have to save those passenger contracts as a missionVariable, too. Next thing I know cargo contracts get auto cancelled, if the needed commodities are auto deleted, too.

I'm rewriting the whole restore game state function of the source code in jscript here, aren't I?
Sadly the workaround script still isn't done yet, but I'm working on it.

[phkb]

I thought that OXP was all about pimping your ship

Sort of. The goal of Ship Configuration is to add some meaning and purpose to the way you configure your ship. Rather than just fill your ship with equipment and cargo, with no flow-on effects of all that stuff, Ship Config alters the performance of your ship based on the amount of equipment and cargo you are carrying. You can certainly "pimp your ride" and install the fastest engines and thrusters, but you do so by taking up cargo space.

making ships slower and stodgier is not my idea of fun!

Again, the goal of Ship Config isn't to make ships slower and harder to turn. It's about making decisions about the role you want your ship to perform. If your goal is to trade, then you want cargo space, so you might want to remove some equipment to maximise your cargo. If you want to be a bounty hunter, then engines and shields might be the priority, so don't worry about the lost cargo space taken up by the larger engines.

That's the intent, anyway. Whether or not I've achieved any of that is a different question entirely! YMMV obviously, and as I state in the preamble on the Ship Config thread, it might not be to everyone's taste. I haven't put it on the download manager because it's still quite early in the development cycle. The next version will correct some of the slowness and stodginess of NPC ships as I'm applying some role-based logic to the installed equipment.

Next thing I know cargo contracts get auto cancelled

I think you're pretty safe with cargo contracts. They are designed around the possibility you might not have enough cargo at the other end, so they won't get cancelled half way if you suddenly lose cargo.

[ralph_hh]

I kind of feel the idea is very funny. You invest a lot of time to enable the code to enable certain OXP to have the ships cargo bay expanded. Well, If you as a pilot are in urgent need to do that, simply edit your shipdata-override.plist. It's a single player game, so if you like to cheat, here you go. It's neither more nor less "cheating" if you do this by a oxp that introduces some gadget that does the same thing for some 1000Cr. I got very much bored doing milk runs to make a fortune to upgrade my Cobby, so to shorten this, I gave it 100t cargo capacity for a limited time. Helped.

[ocz]

I kind of feel the idea is very funny. You invest a lot of time to enable the code to enable certain OXP to have the ships cargo bay expanded. Well, If you as a pilot are in urgent need to do that, simply edit your shipdata-override.plist. It's a single player game, so if you like to cheat, here you go. It's neither more nor less "cheating" if you do this by a oxp that introduces some gadget that does the same thing for some 1000Cr. I got very much bored doing milk runs to make a fortune to upgrade my Cobby, so to shorten this, I gave it 100t cargo capacity for a limited time. Helped.

There is nothing wrong with investing time into a hobby. And if it would only be about a ride with more cargo space I would have just installed an OXP ship, but that's boring.

Storytime: At first I thought about ways to expand the game experience for me, so I installed some OXPs. There I stumbled about "[wiki]Start Choices[/wiki]" and "[wiki]Illicit Unlock OXP[/wiki]" and saw the potential both of them have. IMO the Cobra Mk.III is totally uber. It's speed, energy banks, energy regeneration, cargo capacity, weapon mounts, agility and quite slick bodyline in combination are more than a little bit outstanding in comparison to other standard crafts. For me personally, there is little to no reason to give it up. And it is given to you right from the start. But starting out with an Adder instead? Ingenious! You have to earn your Cobra MKIII! How many more hours of fun could you milk out of that! But the game was designed for the Cobra MKIII and it's 35t cargo hold and not for playing with an Adder. So while it's adding a whole new and long game phase to the game, that phase isn't really that fleshed out. That's where my motivation began.

I began to think about ideas, how to increase the fun level and motivation for such a beginning phase and came to the conclusion, that a few simple OXPs might already be enough.

First you have to start in a pretty small craft and you gotta have the motivation to look for a new craft before the Cobra MKIII. There is the Cobra MKI. Good. And before that ship? Well, Illicit Unlock unlocks quite a range of cheaper vessels. But they lack cargo space. An additional cargo space OXP was needed. It was written quite fast. (Later I found out, that I made a mistake while testing it or didn't test it thoroughly enough. Quite a blow and I took it down.) Many of those crafts also don't have a witchdrive, but just equipping them with one? Nah. Maybe as a purchasable item. It would have to be big too, but they have nearly no room. A small one with downsides is needed. And the [wiki]Single-Use Witchdrive[/wiki] (ad) was born. Now interstellar travel with those ships is possible AND unattractive. Just like I wanted it to be. I'm also on the lookout for/trying to write my own station OXPs to create some low profitable in system trade routes. ([wiki]Distant Suns[/wiki] and [wiki]Torus to Sun[/wiki] might even add more depth. Distant Stars [Test release 0.0.3] looks good.) Maybe I even write an extra activity. [wiki]Mining Contracts OXP[/wiki] might be wonderful for that phase, too.

But one regret is still left. There is no way of a general cargo hold expansion. (I'm not talking about the cargo bay expansion as this means mending with the shipdata.plist, what is too inflexible for my taste (works only for known ships) and can only be done once. But in the end, if there is no alternative, this will have to do.) That expansion possibility is very important, as 1t, 2t or even 3t more space mean a lot, if the cargo space it limited to, how much?, 7t? I'm just not willing to give up on that, as this feature is worth it IMO! One way or another I'll somehow add an option to increase it. An implementation into the source code would be the best solution. (I'll try to look into that one day again, too.) A workaround is the next best, if it isn't too messy. And I do have to confess, that the nearly 500 lines of jscript I wrote so far, do mess around a lot! But hey! It isn't as if there is an alternative! I think I'll go for the modified shipdata.plist OXP to shoot down my beloved "Illicit Unlock", too.

So yeah. It's a lot of time, a whole lot of frustration, more fun that a barrel of monkey (but not as much as a barrel full with Pinkie Pies) and I DO write some code again, what is awesome!

So much for my personal motivation. BTW. I also realized how much pain it is to implement this and how much it would be for others. And it still would conflict with my work, if somebody else would do it by him/herself. So for them (and for my sake) I'll finish this workaround.