Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lua function GetEquipFree("cargo") is not behaving as expected #3450

Closed
ghost opened this issue Sep 11, 2015 · 5 comments
Closed

Lua function GetEquipFree("cargo") is not behaving as expected #3450

ghost opened this issue Sep 11, 2015 · 5 comments
Assignees

Comments

@ghost
Copy link

ghost commented Sep 11, 2015

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.

@laarmen
Copy link
Contributor

laarmen commented Sep 12, 2015

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
#3450.

@impaktor
Copy link
Member

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.

@laarmen
Copy link
Contributor

laarmen commented Sep 12, 2015

(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
#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
#3450 (comment)
.

@ghost
Copy link
Author

ghost commented Sep 13, 2015

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?

@sturnclaw
Copy link
Member

GetEquipFree() is no more, as is "combined" cargo/equipment capacity. Yay!

@github-project-automation github-project-automation bot moved this from Stage 1 to Done in Equipment Rewrite Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants