Interim payload implementation

[sam52796]

From what I can gather, a couple of years ago there was an effort to convert the ship capacity metric from mass to volume. I must say I don't really understand the reasoning behind this, because mass is far more relevant for gravity wells, delta-V, manoeuvrability, and hyperspace jump range than ship volume. Even here on Earth, with air resistance and friction, vehicle carrying capacity is mainly determined by mass, not volume. But maybe if I could see the final implementation in Pioneer I would get it. Anyway, the work was mostly completed on the equipment side, and then it seems everyone just gave up. This has left the game with a number of issues which I think seriously affect its credibility:

• The word "Capacity" is shown in various places in the UI, but generally only refers to equipment volume, which is a sub-set of the ship's overall capacity. However, during normal "flying around and trading" gameplay the player is more interested in cargo space than equipment space. That's why the cargo-run missions still have questions like "How much mass?". Even when fitting equipment it is mostly governed by available equipment slots rather than total equipment capacity. So the "Capacity" figure is featured far more prominently than is warranted by its value to the player.
• Cargo capacity is currently a separate fixed number, measured in ton(ne)s, which does not vary when you fill the ship up with other things. This makes no logical sense. Intuitively, as you load up a ship with equipment, the cargo capacity should reduce, and vice-versa. Even carmakers in the 1950s had figured out that you can convert passenger space into cargo space by folding the seats down. I'm sure that spaceship engineers 1,200 years from now will have made the equivalent discoveries.
• Speaking of passenger space - the passenger cabins take up no space at all. Their volume is set to 0, so they don't consume equipment capacity, and their weight doesn't affect cargo space, because nothing affects cargo space as previously mentioned. When I first saw this I thought that maybe someone forgot to update the cabin equipment volume fields after testing, but then I saw in the Hardpoint-based Equipment System design doc (last updated 2024-09) that this is by design. Huh? I think that installing passenger cabins into the ship ought to affect something.
• Passenger cabins also have a problem whereby "cabin" is used interchangeably to mean "berth" or "compartment that may contain multiple berths". For example in the ship market it will show that ships have "2 passenger cabins" but this tells you almost nothing useful about how many passengers you will be able to transport.
• Passenger cabins have a further problem whereby some ships don't have any slots for them at all. In particular the player is unable to add cabins to the "easy start" ship (Coronatrix). This is confusing and inconsistent, since many smaller ships do have slots.

The goal of this pull request is to patch up the above holes in the current code, while leaving open the possibility for someone to come along and finish off the volume conversion, if they want to, at a future date. Therefore it does not introduce any new ship properties or parameters, merely making their current usage more explicit.

I have made the following changes:

• The "cargo" stat in ship definition files is now used to mean "max payload". The payload is the total amount of mass the ship can carry, excluding fuel. So when a ship is fully laden, the total mass for physics purposes will be hull + fuel + payload. Equipment mass therefore eats into the payload allowance and reduces the amount of cargo you can carry. Since cargo measurements were already still using mass, this doesn't lead to significant changes - just additional checks when fitting equipment.
• Due to the above, I bumped up the "cargo" stat (now meaning total payload mass) in some of the ships, especially the smaller ones. Except for Xylophis which I reduced.
• The "Capacity" column in the ship market now shows "Payload" instead, since it's a better indication of the ship's overall transporting abilities, covering both equipment and cargo, rather than just equipment.
• The UI gauges along the bottom of the station view (comms) screens now have "Payload" as well as "Equipment". I have tried to ban the word "capacity" from everywhere in the UI, to remove any ambiguity about what any given number refers to.
• In most places in the UI that refer to "cabins" I have replaced this with "berths" since that number is generally what the player wants to know.
• If you have no passenger cabins fitted, the UI now shows "None" instead of "100% of 0 cabins used".
• An existing bug was that if the player doesn't have room to add a new piece of equipment, the message shown was "This equipment is not compatible with your ship", even if it is compatible. I added an additional message which says "Not enough space" in those circumstances instead.
• In the equipment screen the mass of a fitted hyperdrive was shown including the fuel, which made the comparison to alternative (or even the same) hyperdrive types come out wrong. Hyperdrive mass is now shown as the bare mass. Fuel reservoir size was already shown separately, so the inclusive number was arguably wrong anyway.
• Cabin slots are now automatically added to ship hulls, according to the max payload, so they don't need to be defined in the ship definition files any more. Since smaller cabins can fit into larger slots, this doesn't mean we end up with hundreds of cabin slots in large transports - it adds as many as it can of the largest ones first, and then a couple of smaller ones to fill out the remaining payload.
• I also made some minor cosmetic tweaks to the way that gauges are drawn, and made the capitalization of some UI strings consistent with other UI strings.

I'd like people to try this code out and let me know what they think.

Note that since I didn't change any underlying ship stats, none of this requires a save bump. However, if the player has a full cargo hold when they save with the current code, and then they load the game with this new code, the ship keeps its cargo and it is possible to end up over the payload limit for the ship. As far as I can tell this doesn't cause any problems - the ship behaves as normal, and after you sell or deliver the excess cargo, you can't go back above the payload limit any more.

Also note that since equipment slots are saved in the save file, if you apply these changes and load a saved game, you won't get the new cabin slots. You have to start a new game, or buy a new ship (that wasn't also saved in the save file), to see what cabin slots it gets assigned.

Finally, yes, this change was my secret agenda all along. I only fixed all those bugs so that you would take me seriously when I submitted this pull request! Hah! Surprise attack!

[impaktor]

I don't think I've actually played any pioneer under the current/new cargo system, so I can not speak of how well it currently works. With that said, here's my 5 cents:

I don't really understand the reasoning behind this, because mass is far more relevant for gravity wells, delta-V, manoeuvrability, and hyperspace jump range than ship volume.

I believe the limiting factor for a space faring ship is the volume of the cargo hold. How much can you fit in there? You could load it up to the ceiling with lead, but then you can only travel to orbital station.

The word "Capacity" is shown in various places in the UI, but generally only refers to equipment volume, which is a sub-set of the ship's overall capacity. However, during normal "flying around and trading" gameplay the player is more interested in cargo space than equipment space. That's why the cargo-run missions still have questions like "How much mass?". Even when fitting equipment it is mostly governed by available equipment slots rather than total equipment capacity. So the "Capacity" figure is featured far more prominently than is warranted by its value to the player.

Yeah, that sounds like it need fixing.

Cargo capacity is currently a separate fixed number, measured in ton(ne)s, which does not vary when you fill the ship up with other things. This makes no logical sense. Intuitively, as you load up a ship with equipment, the cargo capacity should reduce, and vice-versa.

Should not cargo capacity be measured in volume? (and current weight, or some indicator of how much acceleration your ship can squeeze out given current mass, lest be stuck in a gravity well?)

the passenger cabins take up no space at all. Their volume is set to 0,

I believe @bszlrd has in Blender made sure where and how to fit passenger cabins in the ships, so they do take up volume in the blender model.

I think that installing passenger cabins into the ship ought to affect something.

Sounds reasonable.

Passenger cabins also have a problem whereby "cabin" is used interchangeably to mean "berth" or "compartment that may contain multiple berths". For example in the ship market it will show that ships have "2 passenger cabins" but this tells you almost nothing useful about how many passengers you will be able to transport.

Really? 2 cabins = 2 people? I have no objections to renaming it "berth" if that makes things clearer

Passenger cabins have a further problem whereby some ships don't have any slots for them at all

Could be some ship models have a sewage problem, making them smell too bad for anyone but a desperate pilot eager to make money? As mentioned on IRC, slot system is there to make the ships more "different" in roles and purpose.

Oh, only one commit? So it's take it or leave it :P

Many of the changes seem interesting, I'll have to see what @bszlrd and @sturnclaw thinks, or anyone else for that matter.

[sturnclaw]

Going to try to address points here in a semi-coherent fashion, apologies if this reply comes off somewhat scattershot.

mass is far more relevant for gravity wells, delta-V, manoeuvrability, and hyperspace jump range than ship volume

This is correct, mass is much more relevant for planning flights than volume is (in fact, volume is almost irrelevant). However, what is relevant to equipment items themselves is the physical volume of the ship they are being installed in. While it may be tempting to think of Pioneer's ships as a shell that an abstract fluid of "equipment mass" is poured into, with any combination of equipment items being able to be selected as long as the fluid does not overfill the container, this is not a design we intend to follow.

The previous system only had mass as a metric, and as a consequence there were no tools available to designers to specialize ships or create meaningful gameplay around smaller ships; anything a small ship could do, a big ship could do better as it could mount the exact same or better equipment with no downsides.

Anyway, the work was mostly completed on the equipment side, and then it seems everyone just gave up.

I would suggest you avoid casually insulting other contributors in this manner. Pioneer is not a commercial game, and there is no contractual obligation for contributors to work on a specific area of the game to your desired level of completion.

The contributors doing the code implementation are far from the only contributors involved in the design of these mechanics, though other, higher-priority items have taken the attention of the few contributors who actively and regularly contribute code to Pioneer since the initial implementation was written.

Likewise, neither is there any obligation on our part to accept changes that go against Pioneer's stated design in the name of "credibility".

The word "Capacity" is shown in various places in the UI [...] However, during normal "flying around and trading" gameplay the player is more interested in cargo space than equipment space. That's why the cargo-run missions still have questions like "How much mass?".

This is a UI design papercut. The station screen is intended to undergo a redesign, as it's a legacy port of a legacy system from +10 years ago and doesn't match current gameplay design. As a starting point, you're more than welcome to change the gauge along the bottom to display cargo capacity when outside of the equipment outfitter screen.

Similarly, the question "how much mass" is a legacy language string contributed by (IIRC) an ESL contributor that needs to be updated to "how much cargo".

Cargo capacity is currently a separate fixed number [...]

Speaking of passenger space [...]

These points can be (admittedly uncharitably) summed up as "why doesn't the ship behave like a fluid container when I put equipment/cargo/passenger fluid in it". This picture of the interior layout of a Sinonatrix should help to illustrate why cargo, passengers, crew quarters, and equipment cannot be so easily interchanged.

In the semantic model that Pioneer has adopted, ships are treated at the scale of yachts rather than minivans. You cannot simply fold down a seat in a yacht to turn it into a container ship that can safely carry a 40-foot shipping container.

In Pioneer's semantic model, passenger cabins in a spacegoing vessel have certain affordances such as power, life support, and access to the pressurized interior that cargo does not require. Likewise, cargo requires sturdy connections to the superstructure of the hull to sustain acceleration, and has a standardized form factor and external access hatches that ease loading and unloading in low-pressure or gravity environments.

Cargo capacity is currently a separate fixed number, measured in ton(ne)s,

The use of tons to express units of cargo is a hold-over from a legacy system. Some if not all of the UI has been converted to display cargo in cargo units, and the code is ready for commodities to receive per-unit masses rather than a uniform density of 1t/u.

The thing that is lacking in this regard is contributors with time and ability to design and implement the UI elements needed to inform the player that the cargo they have loaded will prevent them from being able to take off under the local gravitational acceleration.

[Passenger cabin] volume is set to 0, so they don't consume equipment capacity, and their weight doesn't affect cargo space, because nothing affects cargo space as previously mentioned.

This is by design. Passenger cabins occupy the fuschia volumes in the above image, which are separate spaces from both the cargo grid (green) and equipment installation compartments (black). As such, they do not consume equipment volume (=0), and do not infringe on the cargo rails when installed. Their mass does affect the performance and handling of the ship when installed.

Because passenger cabins require a contiguous block of space to put passengers in that needs a sensible connection with the pressurized habitat volume of the ship, the option with the least conceptual load is to have defined slots determine how many (and where) passenger cabins can be installed into in a ship.

The missing piece of this puzzle are three additional classes of equipment which are installable in a cabin slot, which would provide crew quarters, additional cargo space, and additional equipment volume respectively. At current, none of these three equipment items have been implemented and passenger slots are in a "first iteration" state.

For example in the ship market it will show that ships have "2 passenger cabins"

The ship market display needs a complete redesign to show the internal affordance (slots) of a ship. It is badly out of date. In general, the one equipment item = one passenger berth association is still (incorrectly) present in the UI because it was existing convention as a holdover from the F:E2-clone days of Pioneer.

Passenger cabins have a further problem whereby some ships don't have any slots for them at all.

This gets into something that's fun to talk about - this is fully by design. Some ships in Pioneer simply do not have the physical volume to install both a cargo container grid and passenger cabins within their hull. Because the current roster of ship hull configurations is intended to be a baseline "general purpose" configuration for each ship hull, the tiebreak is typically in the direction of cargo rather than passengers.

This design dilemma gives rise to a planned system that should (though perhaps not adequately) be documented in the design docs, where a ship hull, e.g. the Coronatrix, can have different hull configurations the player can pay a spaceport foundry to refit the ship into. For example, one of the hull configurations planned to be implemented is a passenger-transport Coronatrix variant which mounts two single-occupancy passenger cabins in place of its cargo bay.

Most of the technical underpinnings of the system are already in place (variants can be implemented as ShipDefs), it just needs the gameplay and user-facing interface to be implemented, gracefully handling cases where the player would lose equipment when changing variants and so on.

---

Hopefully this lengthy reply illustrates the rationale behind Pioneer's design and illustrates the opportunities for contributors to clean up the papercuts and holes with the current implementation.

In sum: a stricter definition of "capacity" is welcome, as are the various fixes to UI papercuts such as ambiguities surrounding how many passengers fit in a given passenger cabin equipment. I'd love to take a high-level look at current and planned equipment items and evaluate which slots are needed to provide meaningful choices to the player, and which items can be installed in any given equipment bay and do not need a slot or limit.

I mentioned on IRC that this PR sees many of the right problems with the game. You've brought up very valid points where players can easily become confused as to what the game is attempting to communicate, and found many of the locations where yet-to-be-implemented features are intended to slot in.

However, reverting to the previous semantic model of equipment installation is not a contribution that advances the state of the game. The current semantic model is the product of many cumulative months of design discussions over the past few years. We are quite certain it is a direction we intend to go, and do not intend to undo the work that has already been done.

Pioneer's current state feels half-finished because it is - there is much work to do and few hands to do it. I'd like to cordially invite you to join in the effort to finish the implementation of this core gameplay mechanic, and to help implement the others that are intended to complement it, if you so desire.

We are happy to answer questions here or on IRC (with some understandable delay involved), and I would greatly appreciate the additional help in finding and resolving all of the inconsistencies and UX issues with the new mechanics. A fresh brain thinking on new equipment items that provide additional gameplay and meaningful choices to the player is always welcome.

[sam52796]

I apologise that once again I find myself in the position of being a newcomer to an open source project and arguing with the main contributors.

I also apologise if I insulted anyone in my message above. I am aware that all the work done on Pioneer is voluntary and nobody is under any obligation to make it the way I want. I will say that regarding equipment specifically, I think the slot system in general is great, and it looks good too. Well done to everyone who worked on that.

Nonetheless, in defence of my initial post above, when I first tried the game a few months ago I was confused by the way ship capacity works, I found it counter-intuitive, and it spoiled my enjoyment of the game. In particular, when I realised I could never do passenger missions in my Coronatrix, I was so annoyed that I stopped playing. Then when I posted about this on the dev forum, the responses I received were along the lines of "We know it's in a transitional state, but we think it's an improvement over the previous system, and nobody plans to work on it in the near future."

This did not make me feel like anyone cared that much about the player experience, and I found it very frustrating. I would therefore argue that "the work was started and then it seems like everybody gave up" is an accurate (if slightly belligerent) assessment of the state of the ship capacity rewrite.

My goals

I am actually happy to help finish the implementation, however there are two main things that I object to in terms of its direction. One is the idea of converting the ship internals to use volume instead of mass, because it seems unnecessary. The second is having separate capacity pools for equipment, cargo, and passengers, because this seems to remove more gameplay features than it adds.

So, I will now embark on a long rambling attempt to change everybody's mind about these things. My third apology is for subjecting everyone to what follows. And please note that I am not targeting anyone in particular with the below. Any mentions of "you" mean the contributor community in general. I actually haven't looked up who designed or implemented the new system, because I don't think it's relevant. The only important question is - where can the game go from here?

Realism

The first thing to establish is - this whole thing is an abstraction. We're discussing imaginary spaceships with pocket fusion reactors, hyperspace ability, and plasma weapons. Any justification for a feature which is based on "it's more realistic" is, to my mind, missing the point. The much more important question is whether a feature allows fun gameplay. Realism only matters to the extent that if something is too counter-intuitive then it may be immersion breaking. However, usually it's possible to justify almost anything as long as you have adequately complicated lore around it. So basically, we can make the ships behave any way we want, as long as someone spends 5 minutes thinking up an explanation for why they behave that way.

For example, I saw some discussion on IRC that "1m³ hydrogen -> 1t hydrogen" is too immersion-breaking, because in real life 1m³ of liquid H only weighs about 70kg. Okay, sure, but you can't just have 1m³ of liquid H sloshing around. It requires a sturdy container to keep it in its liquid state. Also, did you know that water contains more H atoms than liquid hydrogen does? Lithium hydride has an even higher density of H than that. So, to justify the mass of hydrogen fuel, all we need to do is write somewhere that "Standard H-fuel containers store hydrogen atoms in a stabilized ionic matrix which approaches the efficiency of metallic hydrogen, and each container includes a progressive bi-directional lattice extraction/absorption process to ensure a steady supply to/from the output/input nodules" and now the problem is solved. 1t of hydrogen means a 1t container with an undefined but compact amount of H in it. That was certainly easier than re-writing all the hydrogen-handling code.

This same principle can be applied to almost any aspect of the game.

Ship volume

Everyone talks about fitting cargo inside a ship's hull, as if they are imagining the ship to be like an airplane. But the only reason that a ship might need to be like an airplane is if it is going to enter an atmosphere at high speed. In space, where Pioneer ships spend most of their time, aircraft-style restrictions don't apply. And hey, the game already accounts for this because in order to enter an atmosphere you have to fit "Atmospheric Shielding" and possibly "Reinforced Structure".

In real life, even within an atmosphere that includes rain and other environmental hazards, transporting things depends almost exclusively on mass, not volume. If you have a car, you can easily transport things that don't fit inside the car. You can leave the trunk open to carry long planks of wood that stick out the back. You can strap things onto the roof. You can even transport an entire self-contained multi-person passenger cabin (or "caravan") by towing it behind. In all of these cases, the factor governing whether the car can still make it up a hill is the mass of the cargo, not its volume.

Similarly, have you seen those huge cargo container ships? They just stack more and more containers on them like Lego bricks until the mass gets too much. Why don't we just say that Pioneer ships behave like this?

"Come on, we can't strap cargo containers to the outside of the ships."

What does this look like to you?

It looks to me like you could easily swap out those cargo-pod looking things for bigger ones. In fact, you could make the case that those are the bigger ones. It's easy to imagine that the stock ones that come with the ship are smaller so that they are flush with the hull.

"But most of the ships have smooth external hulls with no obvious attachment points. The cargo has to go inside."

This ship looks like it could expand telescopically, to create more internal volume while maintaining the same maximum carry mass:

And this ship looks like it has already been expanded telescopically, and its default configuration would be more compact:

"You think you're very clever don't you, using the ship models against us. But we're treating ships like yachts, and those don't expand."

Who knows what 32nd century yachts will be like? For any Pioneer ship we can just wave our hands and write some flavour text such as "All ships in the *TRIX line feature our standard Expando-Bay^TM technology for seamless accommodation of low-density cargo. The sleek lines of your ship adjust proportionally so that from the outside, you won't even know that the ship has changed shape!" There, problem solved, and now we can stick with mass-based cargo without having to change any code.

Ship configurability

"You cannot simply fold down a seat in a yacht to turn it into a container ship that can safely carry a 40-foot shipping container."

Have you ever seen an airplane when it is first made? The inside is actually empty. It doesn't have any passenger seats in it - those are configured later by the airline, which decides how many first class -vs- economy class seats they want, and how much space to keep for luggage, and so on. If the military were to acquire the plane they would happily use the seating area for cargo instead. I don't know anything about the internals of Air Force One, but I bet the lower deck isn't a large unused luggage space - they will have put anti-missile equipment in there, and one of those devices that let it refuel from another plane while still in the air, and so on. In other words, they are trading off cargo capacity against equipment capacity.

"But in a spaceship, cabins need life support and other connections, you can't just chuck them into an unpressurized cargo hold."

Firstly, what is a passenger cabin? As long as it's undefined, it could be anything. It could be a small cryo-chamber where the passenger lies down and is kept in suspended animation until they arrive. In that case, it only needs about as much volume as an escape pod. And since escape pods can survive in space, the "passenger cabin" could survive in the ship's hold too, strapped down next to some cargo.

Secondly, even if you say no, passenger cabins are more like cruise-liner berths. Well, there is an equipment item called "Cargo Bay Life Support" which implies that passengers could then walk around the cargo bay. As in - this is not an insurmountable problem.

Thirdly, even if you say no, the life support equipment item only provides hookups to cargo containers. Well, then it could provide them to passenger cabins too, and the passenger cabins could be chained together like train carriages to provide a corridor that connects them all to the front of the cargo bay where the pilot quarters are.

Fourthly, even if you say no, absolutely not, sorry but there is no feasible way to put passenger cabins into the cargo hold - well, I'm afraid I have some bad news for you. Because the tiniest ship, the Xylophis, has a passenger cabin slot. And clearly a Xylophis would fit into the cargo hold of a large transport ship. So treat the Xylophis like a two-person passenger cabin (one slot plus one pilot quarters) and stack a row of them inside the cargo hold, and boom. Now your transport ship can carry passengers in the hold.

Frankly, the idea that we must treat the inside of the ship as maximally un-configurable is more immersion-breaking to me than the old "put anything anywhere" system.

Gameplay

"None of that matters because we've discussed it and decided that we want separate equipment and cargo volume-based pools for gameplay reasons, not realism reasons."

Great! This is a legitimate choice. If you could convince me that the result would be more fun, or more immersive, or allow interesting trade-offs, then I would be fully on board. But honestly, nobody has offered any reasons that look good to me. So far I have seen the following:

"We could add a thrust to weight ratio."

You can do that now. It doesn't require converting the entire ship to volume-based cargo. Just bump up the cargo weight allowance of the ships and then implement the TWR to impose an effective limit on ship payload.

"We could have space-only ships whose TWR is too low to land on planets."

You can do that now. It doesn't require any ship capacity changes. Just give a ship a large cargo payload and relatively weak thrusters.

"We could have different types of cargo, like a drone that weighs more than 1t."

You can do that now. It doesn't require tracking cargo by volume. The difficulty is in adding non-commodity type cargo elements, which has nothing to do with what units they are measured in.

"We could have different ship roles."

You can do that now. It doesn't require separate equipment and cargo pools. Just give fighters more combat-orientated equipment slots and a low overall payload mass. In fact, hasn't this already been done?

"Yes, but one of the ship roles is passenger transport, so cabins have to be in a separate pool."

The problem with this is that "passenger transport" isn't a core ship role, it's just something given by a subset of missions. If the player had the choice of starting up a passenger transport company then yes, they should have the option of buying expensive "space-liner" type dedicated ships, versus cheaper transport ships that they strip out and fit with economy passenger cabins instead (though currently the passenger cabin slot system would prevent this). But in practice, the player will mostly be hauling cargo, and will only ever have a handful of passengers when compatible missions arise, so reserving part of the ship for passengers seems like a waste of the ship space. Let the player put cargo in there instead if they want to.

"Actually, we do want to add a type of passenger cabin that will store cargo or equipment instead."

... So let me get this straight. You're dividing up the ship into separate passenger and cargo space to prevent players trading off one against the other, and then you're going to create a special equipment item that lets the player put cargo into unused passenger cabin bays? This ends up with the exact same capacity trade-off mechanic that you were trying to move away from! You could have just left things the way they were! I really don't understand the thinking behind this one.

Trade-offs

I've said that I object to having separate equipment/cargo/passenger pools, and given a lot of realism based reasons for why, but earlier I said that realism-related arguments are weak, and the whole thing is an abstraction, and we should do whatever is most fun. My actual core objection to having separate pools is that I think they lead to less fun gameplay.

Gameplay is fun when the player has to make trade-offs. But specifically, it's fun when the trade-offs let the player feel smart. If the trade-off makes the player feel dumb then it is not fun.

When I used to play Frontier, I would remove the atmospheric shielding and the weapons from the starting ship, and then stick to safe areas for a while. This allowed me to carry more cargo and progress faster. It made me feel smart because I was taking advantage of the trade-off between cargo and equipment, plus it feels kind of cool to imagine stripping out equipment to maximize cargo space. Nice. Then when I had enough money to afford a passenger cabin, I would buy one if I saw a mission that was worth it, and sell it when I wasn't carrying passengers, to free up cargo space. A++ best pilot.

When I tried out Pioneer, I removed the shielding and laser from the Coronatrix, and this allowed me to... uh... well it didn't seem to make any difference to cargo space. Weird. Anyway, it allowed me to... I guess fly a bit faster because I had less equipment mass. Not that it makes any difference because I accelerate time anyway. Still, after a while I had enough experience to take passenger missions, and it turns out I was in the wrong ship. I should have "traded off" the Easy start for the Medium start because that one has passenger cabin slots. This made me feel annoyed. Partly because I hadn't knowingly made that trade-off, but mainly because it isn't really a trade-off. Ships without passenger cabins don't get some other gameplay feature to compensate. They are just locked out of passenger missions for no apparent reason, and then the player feels dumb for choosing that ship.

"Ah, see, we're planning to have hull variants, which would allow the player to... "

Let me stop you there...

Open source philosophy

There should be some kind of principle, similar to medicine's Hippocratic Oath, whereby contributions to an open-source project should not make it worse. It's fine to lay the groundwork for a later improvement, but if your change today introduces user confusion or removes existing features, then "Ah, but this will allow us to make it better in future!" is not an adequate justification. The changes should be rewritten so that they don't impact the user experience today.

I say this not in an accusatory way, everyone here (including me) wants to make the best game possible. But still - I would argue that, for example, removing the passenger cabins from the Coronatrix, thereby preventing new players from taking passenger missions, on the basis that you may at some point put them back as part of a future hull configuration feature, and then leaving it like that for two years - this violates the "do no harm" principle.

Again, to re-iterate, I am not trying to attack anyone. I am not trying to make anyone feel bad or get defensive, and I don't actually know who removed those passenger cabins. I am just saying - let's bear this in mind for future changes.

In particular - if you ever find yourself responding to an unpopular change with "Ah, but this will allow us to..." then alarm bells should start ringing in your head. There was probably a less disruptive way to implement the interim version.

Now what was I saying...

Something about hull variants

Right. As I understand it, the goal is to prevent players being able to fill up the cargo hold with passenger cabins, because this doesn't make sense conceptually. So instead, there will be Coronatrix variant A with cargo space and no cabin slots, and then Coronatrix variant B with no cargo space and two cabin slots instead, and then the player can install a piece of equipment in the cabin slots that lets them put cargo in there. And the final result is different from the old way of letting the player freely swap cabin space with cargo space because... ?

No, sorry, I still don't get it.

Volume problems

I have been assured that there is a coherent and functional design behind the volume conversion, and everything will make sense once it is in place. I want to believe this. But I can think of at least one issue that I haven't seen addressed anywhere. How will the game handle cargo-run pick-up missions? In these, the player's mission is to fly to a new location, pick up some cargo, and bring it back. The player has to determine whether they will be able to fulfil the mission before they accept it, but this isn't as easy as it sounds.

Currently, one of the questions is "How much mass?" This would have to be changed to "How much volume and mass?" because now the player needs to know whether the cargo will fit volumetrically into the hold, and whether the ship will be able to take off afterwards.

Any kind of current TWR meter won't help, since the cargo hasn't been loaded yet. There would need to be a simulated TWR feature which allows the player to see what the TWR would be with a certain additional mass. Then they can compare that to the destination planet's gravity.

This is not a trivial change, and potentially veers into "make the player feel dumb" territory too - if they accept the mission, fly to the location, receive the cargo, and then the ship is too heavy and they can't take off... oops, sorry, game over.

I mentioned this in my dev forum post, and if I'm understanding the response correctly, there is a secret minimum and maximum thrust applied to every ship to regulate manoeuvrability and ensure that the player is never in this situation.

If that is true, what is the point of the volume conversion? All that work to add mass values for every type of commodity and possible mission cargo, and rework the UI to show volume and mass separately, and in the end the player can ignore the mass value because the ship flies the same regardless?

"This would be addressed by the planned TWR change, which..."

No, sorry, see the "Open source philosophy" section above. Also see "implementing a TWR could be done now, it doesn't need these volume-related changes".

Summary

I am generally in favour of fun new gameplay mechanics, but:

• Conversion to volume-based capacity brings a lot of complexity, since mass is actually the thing that matters, so now you need additional UI so that the player can consider both, and it is not required for any of the other cargo-based gameplay features that people want to add.

• Having separate equipment, cargo, and passenger capacity pools leads to the removal of a key trade-off mechanic, while a lot of additional work is done to implement something that seems to end up being basically the same, and it is not required for any of the other equipment gameplay features that people want to add.

• Currently the game is suffering from half-implemented volume and pool conversions which impact gameplay and require significant additional work to complete. In the meantime, my interim payload implementation has already been written, provides a tangible benefit for players trying the game today, with minimal patches over the existing holes, and does not prevent the future addition of any features discussed above. I'm not sure if anyone has actually looked at my commit - it required hardly any changes to show "Payload" as a meaningful metric because everything already has mass values anyway, and it certainly doesn't remove any volume aspects - the equipment volume meter is still there, for example. So it's not "rolling things back" in any sense. In fact, if you are going to add a TWR meter of some kind, then presumably you would need to show the ship's mass anyway, so the payload code that I added is actually a step in that direction.

• Therefore it makes sense to accept this pull request.

Thank you for coming to my TED talk.

[bszlrd]

Thanks for writing it out in this detail.
Here's my thinking:

Realsim / abstraction aspect

• You don't just slap container houses on a container ship and call it a passenger ship.
• You can't really put seats inside the cargo bay of an airplane, even if you could put cargo where the seats would go

Volume and mass

I still think that the conversion to m3 was the right decision.

• TWR is an important metric of spaceflight, and very few games actually do anything with it. Likely only KSP and Orbiter.
• Having cargo mass and volume at the same time does adds complexity, but they are still relevant.
  • We are not aiming for market appeal, so complexity isn't frowned upon.
  • You won't be transporting huge blocks of steel in a minivan even if by volume it would fit
  • If you'd overload your ship by 7 tons of steel, then you can still load 4 and bring consumer goods or something light in the remaining space. Or remove that heavy atmo scoop and your shields, possibly being more vulnerable. Tradeoff.
  • It can also be a question of deltaV and hyperspace travel times. Although currently missions give ample deadlines, so it is less relevant. (better deadline calculation would be nice)
  • TWR does need proper UI and explanation, and the capacity metric does need appropriate displays. I even did mockups for it. Not to mention providing the mass and volume info in the market as well.
    
  • The cargo pickup missions could provide the relevant info. And a TWR calculator shouldn't be too much of a hassle.
    • Sidenote, the comms window of the BBS or even the BBS in general ought to be a floating window in my opinion. That way you could check the map or any other screen while talking to the mission giver. Recently I took some long distance missions, and picked up others along the way, and it was a hassle to switch between the BBS and the sector map, partly because scrolling resets to the top and one needs to find the mission again.
    • We want structural reinforcement upgrades, that would allow for better acceleration. Which does relate to this.
    • We also want overrides to the acceleration limiter, with the tradeoff that higher accelerations could and would wear, and even damage the ship structure. Could also mean less efficient burns.

Ship configurability

• Give me dynamically externally attaching containers, and I'll make ships that use them.
  • For DSMiner-like ships with huge containers, externally visible cargo hold/passenger hab modules would be nice too. Could even be nice for other ships. Like the number of windows on small ships could show how much cabins they have.
• I'm not fond of telescoping ships.
• The Coronatrix lacking cabin slots is an oversight/mistake, not an intent to lock people out of passenger missions. I've already added one to the ship table, so the next pull from that should fix it.

Possible ways forward

I think the way forward is not to revert to ships being one big volume. I could imagine two ways:

• Cabin space could allocated dynamically based on available volume, and the volume of the cabin types. And there could be additional hand-defined slots that won't be used for cargo ever, and limits to how many cabins or cargo it can support. Although this is somewhat going back to the big volume way admittedly, but only for cabins and cargo.
• There could be internal slots of given sizes, and one could choose to install either cabins, cargo grids and some other additional equipment types (maintenance workshop, exploration workstation/lab, etc) into them. There could also be exclusive slots, which could only house cabins or cargo grids, if ship design calls for it. Kinda like how E:D handles it.
• For both cases, the ship market could generate ships for sale that have some cargo and some passenger space. Not to mention additional random equipment installed. Akin to the threat level for spawned ships. So one might get lucky, or might need to clean out unneeded stuff. Which then would be even more interesting when wear and tear is implemented.
• Hull variants would still work with both approach. The Malabar could have volume reserved for cabins, no matter what. But the Vatakara wouldn't, and would provide less space for cabins even after you ripped out everything else.

Couple of tangents

Separating the player from the ship could allow for the player to dock at a station, rent a muscular shuttle, fly down the well to fetch the cargo that needs to be picked up, then transfer it into their ship and fly from the orbital.
There could also be the possibility to rent storage space in a station or port. So they can fetch the cargo in multiple batches.
And both of these could mean that they need to hurry, because the deadline does not care about such detours.

[impaktor]

@sam52796 For the time being, reverting to the old volume-system of Frontier is not on the table, as it is not the direction we wish to take.

It is better to work out the current imperfections that you've identified, but in the direction described by @sturnclaw above, rather than what is implemented in this PR.

I understand this is not what you want, but I hope you can accept it. From here, you have a few options:

• All your changes in this PR are lua-side so you can bundle it as a mod that we can host on the wiki for players to evaluate.

• Work out the current rough edges together with @sturnclaw to make the current system as good as it can be - even if it is not your preferred fix. Once that system is in place, we can properly evaluate game play and see what the next step will be.

• Work on other areas of Pioneer where we are in better agreement of the direction.

I wish to thank you for your many contributions to the project, they've been very valuable, and we sure would love to keep you, even if this might be a blow to your motivation. There is no lack of other areas of the game where we are in agreement on what needs to be done.

[sam52796]

Thank you for the answers. In particular thank you to @bszlrd for fixing the Coronatrix cabin issue.

As I said before, I don't really like realism based arguments when it comes to discussing Pioneer spaceships, because it feels like we're 12th century peasants arguing over whether men will one day be able to travel to the moon, and you're saying "No, it's obviously impossible, because horses can't fly" and I don't have any concrete counter arguments beyond "You don't know what kind of creatures will be discovered in the future", which is not only weak but also not even relevant, and in the end nobody finds out the real answer.

Similarly, maybe it's true that cargo containers don't fit on a yacht, or that seats don't fit into an airplane's luggage section, but so what? If you really need a lore-based explanation for Pioneer ship configurability, then let's just assert that the interior of a ship can disassemble itself and then 3D-print back into any configuration you want. When you buy a passenger cabin you're buying the soft furnishings and a safety inspection by the shipyard to certify that the space is now suitable for human occupation. And converting equipment space to cargo space is as easy as saying "Hey ship, reconfigure this area to store cargo" and it's done.

The only real reason for not taking this path is if you instead want to have something like a mini-game where you have to fit different shaped equipment and cargo blocks into a fixed space, Tetris-style. But as far as I can see this isn't part of the design, and the recently rewritten ship equipment capacity is behaving exactly in the way that you're all saying that you expressly don't want. It's come up several times that "you can't just pour equipment into an abstract equipment volume" and yet that's exactly what the equipment capacity pool is. On a Sinonatrix there is 59 cubic metres of equipment space at the front of the craft, and any equipment can go into any part of that, including:

• Improved Thrusters. Surely these have to be at the corners of the hull where the thrusters are?
• Cargo Scoop. Doesn't this need to be adjacent to the cargo hold? In the ship layout it appears that the pilot's living quarters are in the way.
• Reinforced Structure. Isn't this throughout the entire ship?
• Atmospheric Shielding. I would expect this to be on the outside, by definition.

Nonetheless, in the current model, if the player doesn't have enough free equipment capacity to upgrade the hyperdrive, they can sell any one of the above items to get more space. This rather goes against the concept of "you can't just put anything anywhere, because reasons".

It also seems to go against the semantic model of having equipment slots in the first place. If there is a shield slot, then presumably that's where the shield emitter has to go. You can't put cargo-bay life support there instead because it would be in the wrong place. As I understand it, one of the sillier aspects of the old Frontier system was that the player could fill the entire ship with shield units and become basically invulnerable. But Pioneer's slot system has now solved that, so I'm not sure why there needs to be an overall equipment capacity pool on top.

Okay, that's enough whining from me - what am I actually going to do? Well, it seems that everyone is still in favour of measuring everything by volume instead of weight, and I still think that it's unnecessary, but I am interested in implementing the TWR, so here is my compromise proposal.

Compromise proposal

Convert cargo to use "cargo units" everywhere in the UI instead of either mass or volume. Under the hood it's done based on volume, because you aren't going to agree otherwise, but initially one cargo unit will be one ton so that we can quickly fix all the UI issues without having to add real mass values to everything first.

Remove the "equipment capacity" meter, because it doesn't work conceptually as noted above, and is unnecessary due to the slot system. However, equipment still keeps its volume and takes up space in the ship, so it reduces the amount of other things you can fit in there. I think it's perfectly reasonable if improved thrusters encroach on the corners of the ship so then you can't load as many cargo containers because they don't line up flush with the walls any more. Same goes for reinforced structure. In fact, the reinforced structure NOT reducing available cargo space definitely seems to go against the modular interior design. If the structure around everything, including the cargo hold, has to be reinforced, and you can't put cargo anywhere else, then by definition the volume of cargo that you could carry would have to decrease. There can't be space outside the cargo hold to reinforce the structure, otherwise the cargo hold could have been bigger in the first place, and nobody would design a ship with lots of unused space.

Then add the TWR feature, turn off the thrust minimums so that players can get stranded in gravity wells, and see how this all pans out. If it's well received and plays sensibly, then we can worry about changing the mass values.

For passenger cabins... ugh... I don't know what to do about those. If you're all still determined to treat them as special case objects that can't go anywhere except into predefined slots then I guess we'll just never agree. But my code to automatically add the cabin slots doesn't change any of the underlying code around cabins. The only thing it does is add some slots depending on the size of the ship. It's one additional function call at ship load time which could easily be removed once all the hull variant plus cabin replacement work is completed, so I don't think there's any downside to it. And there's certainly a player upside. I'll be disappointed if you don't take this easy win to fix an issue that the game has now.

Sorry, I guess I had to whine a little bit more. But now that really is enough whining from me. Let me know what you think of the compromise proposal.