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

Cargo handling #294

Open
se5a opened this issue Jul 14, 2020 · 3 comments
Open

Cargo handling #294

se5a opened this issue Jul 14, 2020 · 3 comments

Comments

@se5a
Copy link
Contributor

se5a commented Jul 14, 2020

This is a thread for ideas on how to improve the cargo system, cargo ui, mod data etc.

I'm currently in the process of reworking the cargo system, and in this pass I'm mostly focused on just getting the new system implemented and "working", but here are some notes on possible issues that may need resolving or improving.

Old system problems:

  • Old system was restricted in that it was mass based only, this limited options with different newtonion engine fuel types, since a lot of the pros and cons are based around how dense the fuel is.
  • Old system was far too complex codewise which made it hard to figure out what was going on, which created a lot of bloat code and methods to try simplify the complexity.

New system:

  • Storage is volume based.
  • Storage components have a volume for how much of a resource it can contain.
  • Storage components have a dry (empty) mass.
  • ICargoable has a Density field added.
  • The code (so far) is a lot simpler and cleaner, despite the added volume and density. converting between mass, volume and density is fairly simple (D = M / V)

Potential issues/future goals with the new system:

  • I expect that most the time the player will be interested in the amount of Mass that can be moved, rather than the volume since this affects DeltaV, especially in the case of fuel.
  • Some ICargoable will have a minimum Mass and Volume unit, ie one unit of fighter shouldn't be able to be broken up.
    Currently this is set in the Mass field in ICargoables.
  • Resources also have this 'Mass' field, and is typically set to 1 (in the json files).
  • UI wise, to keep things simple we should restrict resources to this single 1kg unit size for transferring cargo, however that may case some issues where:
  • Possible float errors in volume mass density conversion leads to non unit entity transfers.
  • If internal transfer code respects the unit size, we could have problems with large units never getting transferred due to the item not being big enough to transfer in a single tick, vs transferring half a unit and cancelling the transfer resulting in half an e.g. fighter transferred.
  • In the case of fuel, we may end up with a non unit amount of fuel stored since fuel can be burned as a double.
  • For small entities, filling that last half a kg of tank might actually matter.
  • To help alleviate the above we can have load and unload all orders ignore the unit restriction, but it'd have to differentiate between a resource that can be split vs and entity which can't.
@se5a
Copy link
Contributor Author

se5a commented Jul 16, 2020

So I've tweaked it a bit:

  • ICargoable now has MassPerUnit and VolumePerUnit instead of just Mass and Density
  • ICargoable no longer has Density - it ended up being easier to have mass and volume instead.
  • Storage stores by unit now instead of volume, however it's still limited by MaxVolume
  • Storage has a bunch of useful functions/methods to store by volume, mass, or (probibly most commonly) Unit amount
  • Storing by mass or volume will still only store by whole units, i.e. if you try to store 4kg of an item that has a MassPerUnit of .75 then it will only store 5 units (and the method will return 3.75kg as successfully stored)
  • We will see if the previous points/issues I made on the above behaviour are actually a problem and go from there.
  • Storage also has methods to get the max mass, or units that can be stored for a given ICargoable.

I've pushed the changes above, but I still need to fix up the json files. (so there's going to be some crashes in the current push).
I still need to tidy up and remove some dead code.
I still need to fix some tests. (currently the test project won't even compile).
I still need to resolve some potential issues with storing specific entities.
With storing entities, ideally we want to to store e.g. the design rather than the specific entity, unless the entity itself is damaged or in some way special from the design. if it is damaged or in some way special from the design we need to be able to handle that as well.

@se5a
Copy link
Contributor Author

se5a commented Aug 7, 2020

I think this is all done,
I just need to check for more dead code or other tidyups before I close this.
and check I fully handled entity storage, inc. damaged/unique entities.

@se5a
Copy link
Contributor Author

se5a commented Nov 28, 2024

##So I spent the last week reworking this again.
When the order is given, it'll shift the requested items into escro. so it can't be used by industry or grabbed by other ships.
The mass and volume should still remain unchanged until the items have actually been moved to the other entity (mass seems right as I write this, but looks like volume is changing.. I need to check this)
Now instead of averaging the range and rate between the two entities, they both get to move items.

It's mostly done, but there are a few things I still need to fix:

  • Clean-up of EscroItems list in CargoStorageDB once transfer is complete.
  • Check handling of > 2 entities transferring at the same time.
  • Check movement of large items such as ship components, and facilities.
  • For some reason, telling the survey fleet to refuel doesn't fill it up.
  • Handle orders given when eg tell a ship to grab a cargo hold of minerals from a colony that is mining but not produced as much as the ship can carry.
  • Some work around the ui to show escro etc a bit better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant