Cargo Refactor
Posted: Thu Oct 04, 2018 12:06 am
I'm basically dumping this here to have something to reference as I implement it, but I welcome comments, concerns, and constructive criticism.
The goal of this refactor is to reduce the amount of data saved to JSON, increase the flexibility of cargo and commodities, allow for transporting equipment without needing to equip it, and move to a better system of tracking cargo capacity than mass.
To that end, I will be moving commodity definitions to JSON, complemented by my recent JSON pr. This will allow mods to override, modify, and extend the list of commodities that are in the game. This will likely require several passes, as numerous systems are hard-coded to the current commodity list.
I will also be splitting cargo into its own logical item type, separate from equipment. The cargo representation will be able to carry several different types of items inside, from equipment, to commodities, to perhaps even other ships. This would help pave the way to "drone ships" for mining, combat, or any other type of task in which multiple subordinate, AI-driven vessels are useful.
This split will allow saving cargo items as a tuple of item + count, drastically reducing save file space for ships with large cargo holds. When cargo items contain unique items (like ships or certain types of equipment), this will add a small amount of overhead, but it will more than likely be entirely offset by the gain of not having to store 500 unique instances of 1t of hydrogen.
The third and most important feature of this change is the move from mass to volume as the determinant factor of cargo space. 1m3 is the standard unit for cargo, being considered '1u'. Cargo holds are measured in intervals of 1u, and a single 'item' of cargo has a size measured in intervals of '1u'. Note the phrasing here - cargo is not always 1 item = 1u, but may have a minimum volume of 2u, 4u, or even 5u per item, depending upon the item. For example, mining machinery or slaves would almost definitely take up more than 1u of cargo space.
This change will absolutely not be attempting to follow any physical constraints as to the packing of cargo - the volume is just a scalar, and will be treated as such. Thus, two 5u cargo items will fit in a 10u cargo space, even if the actual dimensions of the ship are not necessarily permissible of that. Additionally, we will not be attempting to simulate space losses due to storage mechanisms or real-world storage constraints - a 1u container always has 1m3 of carried volume, regardless of whether the carried item is a cryogenic fuel like LH2 or metal ore.
Cargo space will be it's own defined scalar, separate from equipment space. Ships will be able to install equipment modules to extend the amount of usable cargo space at the expense of equipment space, but modules that do the reverse will likely be rare, if not non-existent.
Cargo will still retain a mass value and effect on the ship, though it will be calculated more correctly - e.g. 1u of hydrogen will only weight 70kg instead of 1t, and metals may weigh 5t or more per unit of volume. This will require some reworking down the road as to ship fuel capacity - the current mass values are wildly incorrect with regard to the ships' volume and the actual physical properties of liquid hydrogen. Ideally, ship fuel and equipment capacity will be moved to volume as well, neatly solving that problem.
The goal of this refactor is to reduce the amount of data saved to JSON, increase the flexibility of cargo and commodities, allow for transporting equipment without needing to equip it, and move to a better system of tracking cargo capacity than mass.
To that end, I will be moving commodity definitions to JSON, complemented by my recent JSON pr. This will allow mods to override, modify, and extend the list of commodities that are in the game. This will likely require several passes, as numerous systems are hard-coded to the current commodity list.
I will also be splitting cargo into its own logical item type, separate from equipment. The cargo representation will be able to carry several different types of items inside, from equipment, to commodities, to perhaps even other ships. This would help pave the way to "drone ships" for mining, combat, or any other type of task in which multiple subordinate, AI-driven vessels are useful.
This split will allow saving cargo items as a tuple of item + count, drastically reducing save file space for ships with large cargo holds. When cargo items contain unique items (like ships or certain types of equipment), this will add a small amount of overhead, but it will more than likely be entirely offset by the gain of not having to store 500 unique instances of 1t of hydrogen.
The third and most important feature of this change is the move from mass to volume as the determinant factor of cargo space. 1m3 is the standard unit for cargo, being considered '1u'. Cargo holds are measured in intervals of 1u, and a single 'item' of cargo has a size measured in intervals of '1u'. Note the phrasing here - cargo is not always 1 item = 1u, but may have a minimum volume of 2u, 4u, or even 5u per item, depending upon the item. For example, mining machinery or slaves would almost definitely take up more than 1u of cargo space.
This change will absolutely not be attempting to follow any physical constraints as to the packing of cargo - the volume is just a scalar, and will be treated as such. Thus, two 5u cargo items will fit in a 10u cargo space, even if the actual dimensions of the ship are not necessarily permissible of that. Additionally, we will not be attempting to simulate space losses due to storage mechanisms or real-world storage constraints - a 1u container always has 1m3 of carried volume, regardless of whether the carried item is a cryogenic fuel like LH2 or metal ore.
Cargo space will be it's own defined scalar, separate from equipment space. Ships will be able to install equipment modules to extend the amount of usable cargo space at the expense of equipment space, but modules that do the reverse will likely be rare, if not non-existent.
Cargo will still retain a mass value and effect on the ship, though it will be calculated more correctly - e.g. 1u of hydrogen will only weight 70kg instead of 1t, and metals may weigh 5t or more per unit of volume. This will require some reworking down the road as to ship fuel capacity - the current mass values are wildly incorrect with regard to the ships' volume and the actual physical properties of liquid hydrogen. Ideally, ship fuel and equipment capacity will be moved to volume as well, neatly solving that problem.