Loadout Design

We have been discussing an idea for a Drone powered loadout. Here are some refinements to that idea. First, the idea of docking pods to the ship has difficulty. It is not as smooth graphically. And when you subtarget the ship, you get all these cargo pods plus all the docking points.

A better idea is to use subsim avatars. These are subsims with a graphical component (for example the players current weapons). It turns out that essentially all subsims support a graphical component.

The drone will move the weapon pod near the loadout point, then the weapon pod will "vanish" at the same moment the subsim is attached to the player ship.

A ship that supports loadout would need hardpoint entries like this:

Weapon Pods (cargo pods that represent player weapons) need the subsim property added. This tells the loadout drone that the cargo pod is really a weapon pod. And it tells the drone which subsim to mount.
How the mounting is done: The drone uses a standard cargo dock to pick up the weapon pod. Pog will then place a docking port at the hardpoint location. Pog will also place a docking port on the drone, just on the far side of the weapon pod. Placing this docking port requires the weapon pod have correct values for width, length, height.

The drone will dock with the two ports together, making it look like it has just mounted the weapon. The weapon pod will be hidden. Then the subsim will be added to the ship. Then the weapon pod will be removed. The drone will undock. Pog will remove the docking points.

This will give us the illusion of proper equipment handling. But there will not be any extra docking ports, or cargo pods, or other stuff floating around.

Note, that aside from the drone, this is not really any different than the GUI loadout idea. I do like the thought of a drone mounting weapons, but there are some drawbacks:

The player gets no feedback and heat and power usage until they get into the ship. Or watch it fly. So it would be really easy to overload a ship. A GUI would let you see the choices you are making. As well as study the details of each weapon.

I think I could live with the possibility of overloading a ship, giving the option to be able to actually watch weapons being loaded and unloaded.

I did more research on how to code the loadout and wanted to document what was done. The information stored in the ships INI file has changed somewhat. Hardpoints are now a numbered list.

[Hardpoints]
hardpoint_name[0]="left_wing_mount"
template[0]="ini:/subsims/systems/player/heavy_pbc"
template_number[0]=15
hardpoint_type[0]=16
position[0]=(15,30,75)
orientation[0]=(0,90,0)

hardpoint_name[1]="right_wing_mount"
template[1]="ini:/subsims/systems/player/heavy_pbc"
template_number[1]=16
hardpoint_type[1]=16
position[1]=(15,30,-75)
orientation[1]=(0,90,0)

The behavior is different than earlier discussions.

Every hardpoint entry has a default subsim (listed as template). This subsim is created and attached to the ship at the specified location. This is done when the ship is created (by new pog code).

The template number is the unique key used to sort between subsims (super important not to use the same number).

Subsims that were created using the template entry can be changed by the loadout code. Nothing prevents every subsystem from being placed on a ship via the hardpoints. If someone wanted to build a ship out of subsystem avatars, this code could be used to do it.

A new function called tsShip.ReplaceSubsim has been written. This function takes a new subsim template name and the subsim you want replaced, and swaps the two. The old subsim is destroyed.

This makes the loadout program very simple. All it must do is give the player a list of systems that can be swapped, and give the player a choice about what new subsim to put in the location. If the loadout wants to "remove" a system and leave nothing, then it swaps in a mountpoint subsim.

Save and restore have already been added to the player wingman code. The hit points of the subsims are remembered and so is the subsim template. When the ship is restored, if the subsims have changed, the restore code will swap in the saved subsim. Again, this makes the loadout program very simple, because it does not need to do any save or restore.

JT, if you are still interested in working on this project, here is what I propose: I will code up a very simple loadout package. It will be conversation based. No drones, or animation, or GUI, just a "magic" swapping of parts. That will not take me long to code, and will be a good example program. The tiny loadout will allow building ships and equipment while the crew is waiting for the full loadout.

You can then dialog with the team and pick if you want to do a GUI or drones, or whatever.

How did I end up doing all this coding when I didn't want to do a loadout? Because it seems far more important to people that I first expected. We like feedback!

Had a think about this. While the drone load out sounds nice. I wonder if the novelty of watching it happen will wear off rather fast. I think a GUI that will provide detailed load out info and more importantly a quick and responsive process to the player might be a better way to go.

Well, why do we need a quick and responsive process? How often do we need to be changing out weapons? I was enjoying the idea of breaking free of the space sim convention of crazy levels of configurability of starships, something that just doesn't strike me a believeable. Having a system were the ship could change loadout, via an involved and real system was perhaps a way to reach between the two extremes (loadout/no loadout) and make something that could keep a little of both.

Besides, having it get done in game hearkens nicely to other prominent features of the game.

Also, it seems that the changing out of weapons isn't something that would really be 'GUI' driven. Like changing out an engine in a car, you have to actually get in there do it.

I think Joco's point is that a slow involved process may be soon feel more annoying than fun. It might be the best long term (meaning when someone else codes it) solution would be have a GUI that lets the player choose the loadout and gives lots of data and feedback so it is easy to see the choices being made are smart. After selecting is done the actual parts are swapped by drone. This two step process is how cargo loading is done now.

If weapons are able to over heat a ship, or power is limited, or anything is limited, then the player will want a GUI and not have to swap and test.