Refactored Cargo Capacity Calculations and Reporting. #5339
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Campaign cargo capacity was not correctly reporting cargo units stored in non-bays. For example, many industrial 'Meks have parts labeled 'cargo'. Mechanically, these are not cargo containers so do not get picked up as available cargo. I believe the intent is that at TW level these units are always presumed to be carrying cargo of some description. Rather than this being available cargo space.
I went ahead and modified how we fetch total cargo capacity from a unit, so now these amorphous 'cargo' parts are considered cargo capacity. This uses string comparison which is not my favorite method, but after a while searching through our codebase it doesn't seem we have a better option as these 'cargo' parts are not treated as special equipment so we don't have another way to confirm whether the part we're looking at is 'cargo'.
I also adjusted cargo capacity so that units that are not fully crewed do not contribute cargo capacity. No more filling the hangar with empty cargo trucks.
Finally, I adjusted the cargo report displayed on the command center so that it's rounded to 1 decimal place, rather than nearest whole number. This will prevent users mistakenly bug reporting 0.5t capacity displaying as 1t.
Closes #5324