Dev Update – Ship Rotation and Sockets

Greetings Wardens

In this Dev Update I wanted to show off some progress made with pulling over all the systems from the old Spaceship Pawn onto the new one and a few improvements that are a result of the efforts. The main things I wanted to highlight are the flight characteristics and control with rotation of the ship and since moving over to Physical Angular Velocity has allowed the system to just manage rotational moment on its own rather than some terrible hacks to try and get the ship to rotate in Turret Mode. Also along with rotation of the ship, the math behind the circular clamp for your floating crosshair got re-examined and instead of using a short hand for defining a circle from X,Y coords, I’ve decided to base the rotation around Arc Tangent 2 (2 = two input coordinates) or Atan2 for short. This along with progress toward getting the turrets/weapons into components via “Sockets” can all be found in this update.

Turret Mode Rotation Momentum

Since the demo, it always bugged me that the rotational movement on your ship while in Turret View (Q/E roll, A/D yaw, R/F pitch) was very stiff and lacked any momentum after initializing your turn. Before using Angular Velocity, there was only setting/adding rotation values to the ship and didn’t give any sort of momentum denoting any sort of weight (mass) that would need to be countered after executing the turn in Turret Mode. Since the change over to Angular Velocity and letting physics take over (and the pre-programmed stopping power on your vessel for rotation), this setup on allowing your ship apply force for turning power now also needs to counter act that momentum to provide that stopping behaviour. This is much more noticeable now as you can see in this GIF here.

(Side note: the “After” shows the vessel with a placeholder HUD for a basic testing floating crosshair since the HUD hasn’t been ported over yet to the New Spaceship Pawn)

In the above GIF, you can see the old Spaceship Pawn has a stiff rotation start/stop (with some very minor camera lag) since the rotation rate immediately goes from 0 to Max in 1 frame, but the After shows a more smoother motion from start/stop since it requires that additive force from momentum of inertia to final rest. This was extremely apparent with larger vessels and it felt fake on larger vessels on rotation without this. This definitely bring a lot more “realistic weight” to the feel on ships especially with the need for stopping power in outter space.

This all encompassing torque rotation on the ship applies to any method of turning the ship, no matter what Orientation Mode you might be using (Floating/Fixed Crosshair, Turret Mode, etc.). The main hope here is now to allow AI or even auto-pilot (even in turret mode) to be able to look/feel like a smooth realistic turn on the vessels while you might focus on shooting with turrets.

One additional thought I had with this that we could implement later on is a Turret Mode that has an additional toggle to “keep turret orientation”. Meaning if the ship rotates, then we could counter rotate the turret view in order for your floating crosshair to remain in the same “world direction” so it doesn’t screw up your shot or keep a lock on your target. This shouldn’t be difficult to add and likely will only take a few additional lines of code to setup.

Floating Crosshair Poles sticky bug

Another annoying bug that was present in the Demo was this issue of the Floating Crosshair getting this weird stuck behaviour when you move the crosshair to the Top/Bottom of the circular clamp that was implemented. The initial math here was a simple √X²-Y² based primarily on the Yaw X axis against the Pitch Y axis. This magnitude calculation defines a circle, but has problems at the “poles” of the rotation. You get the inverse problem if you base this from the Pitch first vs Yaw where the “sticky poles” are on the far Left/Right sides on the extremities of the circular clamp. To sort of hide this a bit for the demo just to get it out to you guys, I opted for the the issue to be on the Top/Bottom of the circular clamp as the floating crosshair tended to clip past the top/bottom of your screen (assuming wide screen resolution) and it was far less noticeable.

To resolve this, I went back and re-examined it and decided to instead of relying on 2 different inputs to pass values, I would resort to Tick and pass through the values from both Pitch/Yaw (+ any additives from the player when moving the floating crosshair around) into Atan2, and then resplit the result into X(COSd) and Y(SINd) and Abs the result (and multiply -1 for min clamp) to redefine -X/+X and -Y/+Y min/max Clamps for each axis. This does wonders to get past the poles issue as you can see in the Before/After GIF below.

I’m not fully satisfied with this fix as there’s lingering cross overs at 45/45 degrees in all 4 corners (cross hair seems to slow down here when moving around), where it seems like there might be some overlapping constraints between both axis, but I’ll iron this out later on.

Sockets

Leaning on the name used for additional helpers for bones on skeletal meshes, I have since developed a new prototype system that will house the specific specified component “types” on different “Socket” locations that can be defined on a ship (or any actor really). The idea with this is to create the rule set of specific “Sockets” on a ship that will allow for different components at different physical locations/rotations on the vessel (Turrets, Counter Measures, Cargo Containers, etc.). Each Socket will have a specific type(s) it can place at this location, along with the “size” of said component. This arbitrary limit is mainly for the specific size restrictions (and size limits for gameplay) so you don’t attach a “Naval” size turret on a small Icarus Fighter.

Seen above is an Icarus (with the new Spaceship Pawn as the parent) get setup with a new “Socket Component” that can be setup on the skeletal mesh bone pre-placement for each bone location/rotation socket. Then which specific type (Turret in this case for the weapon), the Size of the Turret (Small) and what specific Class of Turret (Gimbal Small). This default setup is automatically generated with an Autocannon attached. However, this system can be edited to override the Class Default settings (like what weapon is default on this turret).

From here, we can override the “Default Turret Weapons”, which specific turret socket they get placed (left/right if applicable), and which weapon group by default they will be placed in.

Since all this is done on construct, this makes it far easier of setup from the Blueprint side to both register new weapons/components to the ship and have accessible from the inputs. Furthermore, this makes the setup of the default ships almost a breeze with specific pre-set limits on Types/Sizes on components that are specifically designed to be fitted at certain locations on different ships. Since the front end customization will also rely on these limitation selections, menus will be easy to create and expose these selection capabilities to the Player.

Currently in this setup, these Weapons are still “Actors” and I want to remove them as such and finish transitioning them over to real sub-components to reduce overhead.

Conclusion

Tons of progress on the New Spaceship Pawn with refactoring well on the way with numerous improvements still to come. Among the next changes to be made will include as said above – Weapons as components – and then also the move of the HUD over to the New Spaceship Pawn.

Thanks again for tuning into this update and we will see you in the next one!

God Speed, Warden

-Kami