Open ghost opened 8 years ago
I don't have the code in front of me right now, but this issue sounds vaguely familiar.
The thing is, we have a slightly schizophrenic approach to the cargo management. On one hand, we have the metric ton approach, which gives us an upper limit as to how much equipment we can embark, including commodities. On the other side, we have the cargo hull, which is strictly designed to hold commodities and nothing else. The "cargo" slot describes the space of this cargo hull, regardless of the mass system. GetEquipFree deals only with the space, not with the mass. In fact, pretty much none of the equipment system knows anything about mass. Another thing that makes matters worse is that we consider that 1t of commodities always takes up the same volume (a cargo slot) no matter its specificities.
So, there is two things to do to makes things a bit more clear: First, address the m=v insanity in the commodities. For that, we'd probably need to convert the masses into kg if it ain't already done (I did it at some point in the #1719 saga, but I dunno if it remained in the final patchset). Just that will probably bring a world of small bugs. Once that's done, we would consider that 1 cargo slot is, say, 1m^3, and then start estimating the correct masses for the different commodities. And of course we'd need to modify the commodity market to make these changes apparent.
Second, we'd scrap the mass limit entirely. It doesn't make much sense, TBH. When you're in space, your mass only impacts your delta-v, but from a structural standpoint there is no reason that your ship should break appart. Of course, near a planet that's another story, but we could simply handwave that and say that the breakpoint is below the point where the engines are not powerful enough to lift you off the ground.
tl;dr: it's not a bug, it's a legacy feature combined with possibly unclear/misleading documentation.
On Fri, Sep 11, 2015 at 5:46 PM, clausimu notifications@github.com wrote:
I think the lua functions that return the space available for loading commodities don't take into account the loaded "extra" equipment that eats into the available space. The following is the output for a Xylophis outfitted with autospheric shielding and an autopilot (using up 1t of mass each), without any commodity cargo loaded. Real, in-game space to buy/load commodities is 8t.
ship:GetEquipSlotCapacity("cargo")
Output expected => 10 (maximal capacity of the "cargo" slot) Output provided => 10
ship:GetEquipCountOccupied("cargo")
Output expected => 2 Output provided => 0
ship:GetEquipFree("cargo")
Output expected => 8 Output provided => 10
I think either the "cargo" slot should be used only to describe the space that is available for commodity type cargo, in which case the ship:GetEquipSlotCapacity("cargo") function should take into account the equipment that has already eaten into this space. Or this equipment should be taken into account when returning occupied and/or free space.
A way to tell how much a given ship can load is important as safeguard. I know that trying to load more than what a ship can load will just return "0" and not load the item in question. But I think it would be cleaner if we could test for available space beforehand.
— Reply to this email directly or view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/3450.
I don't have the code in front of me right now, but this issue sounds vaguely familiar.
Yes, we had an issue with this, #3117, where the fix was to change what the "free cargo bar" showed.
As I understand it, I don't think there's much to do in this issue, other than get cracking on fixing the inconsistencies in our schizophrenic volume vs. mass system. This is not a small task, and should be planned out first. Like what happens if you land on a planet with too much mass to take off? Are there spaceports whith such high gravity that even an empty ship can't take off?
These things are discussed on the dev-forum: Equipment, cargo, mass and volume. I don't see anyone of "us" (dev team) working on this anytime even remotely "soon" at all, so this requires a volunteer to work on.
(note that even if it were one of the core team, they'd still be volunteers ;-)
On Sat, Sep 12, 2015 at 1:03 PM, Karl F notifications@github.com wrote:
I don't have the code in front of me right now, but this issue sounds vaguely familiar.
Yes, we had an issue with this, #3117 https://github.com/pioneerspacesim/pioneer/issues/3117, where the fix was to change what the "free cargo bar" showed.
As I understand it, I don't think there's much to do in this issue, other than get cracking on fixing the inconsistencies in our schizophrenic volume vs. mass system. This is not a small task, and should be planned out first. Like what happens if you land on a planet with too much mass to take off? Are there spaceports whith such high gravity that even an empty ship can't take off?
These things are discussed on the dev-forum: Equipment, cargo, mass and volume http://pioneerspacesim.net/forum/viewtopic.php?f=3&t=245. I don't see anyone of "us" (dev team) working on this anytime even remotely "soon" at all, so this requires a volunteer to work on.
— Reply to this email directly or view it on GitHub https://github.com/pioneerspacesim/pioneer/issues/3450#issuecomment-139749268 .
Okay, let's call this a feature for now then. But for the non-core, still-needing-to-come-up-for-air-after-diving-into-pioneer-code people like me :-) - what is a way to determine the free commodity-cargo space available if I want to check if a certain tonnage of, say, hydrogen fuel can be loaded?
I think the lua functions that return the space available for loading commodities don't take into account the loaded "extra" equipment that eats into the available space. The following is the output for a Xylophis outfitted with autospheric shielding and an autopilot (using up 1t of mass each), without any commodity cargo loaded. Real, in-game space to buy/load commodities is 8t.
Output expected => 10 (maximal capacity of the "cargo" slot) Output provided => 10
Output expected => 2 Output provided => 0
Output expected => 8 Output provided => 10
I think either the "cargo" slot should be used only to describe the space that is available for commodity type cargo, in which case the ship:GetEquipSlotCapacity("cargo") function should take into account the equipment that has already eaten into this space. Or this equipment should be taken into account when returning occupied and/or free space.
A way to tell how much a given ship can load is important as safeguard. I know that trying to load more than what a ship can load will just return "0" and not load the item in question. But I think it would be cleaner if we could test for available space beforehand.