Instant rotation speed woes

So I wanted to give an update this weekend in relation to what I want to have working in the Alpha with new Movement code and what to expect, but it seems like it’s going to be a lot more work than I initially thought. Originally, I thought it would be pretty simple to setup a new “Set Course” for larger vessels in turret mode to choose a direction and just let the ship automatically rotate toward that target direction. Sure that’s pretty easy with direct rotational old movement code, but it looks terrible with digital inputs (No smooth acceleration into or out of the turns). You see this already with Turret mode when rotating your ship, the rotation turns extremely fast. That’s because the vessel instantly reaches it’s turning speed in a single frame.

So to move forward with an accelerated torque on the new physics based movement, I’m looking into ramping up/down the rotation rate with a sort of back end “momentum” meter so it receives both digital and analog inputs that would drive how much demand toward a rotational direction would be. This way if the Player decides to instantly demand turning into a different direction, not only does the torque need to be overcome physically, but more back end control is given to smooth out the demand on the ship so the rotation isn’t jerked so hard in the different direction.

Originally I thought I could rely on just using Torque and the mass of the vessels to deal with true momentum of the vessels (especially larger vessels) but with yaw/pitch vs roll, I wanted to have more individualized control over how fast they would rotate in different directions. Not to mention with the Floating crosshair setup, rotation on the ships handles via analog and usually when playing, you want a faster turn rate depending when flying in that mode anyway.

Headaches with Child Actors

So with previous updates, I’ve been showing off setups with Turrets and Weapons attaching to ships. Those setups have been via the Child Actor systems which worked well up this certain point of saving loadouts and dynamically loading them (Especially for Multiplayer). This headache in both attachment and removal has been a huge pain in the ass since there’s sometimes hiccups in determining if the attached Child Actor either exists or has been deleted from the parent. Either case spits out an error in the output logs and usually ends up with an orphaned actor at 0,0,0 in the level never to be deleted. Furthermore to this, additional headaches occur when I have to deal with sorting out what actors I am Box Selecting when in PDI since Child Actors do count as regular actors and just bloat the entity list. Also per Unreal dev forums, Child Actors are usually not the things to use when dealing with attachments on Pawns. That’s usually left up to Components.

Component Blueprints don’t allow for Blueprint added SubComponents

So with the idea of movement Turrets and Weapons over to Components instead of Child Actors, I was excited at the prospect of that since it would definitely clean up a lot of the bloat I had initially on those actors when defining their muzzle flash and the rest. However I found that when creating new Components via Blueprints that you can’t actually pre-define attached additional sub-components on them and would either require strict code setup on them or be called in on Begin Play (At game start – which is a terrible idea). This is extremely frustrating since the Blueprint actor system made it so easy to attach sub-components for easy reference and use and additional prototyping to make sure setups work. I’m honestly quite baffled why Epic didn’t allow for attachment of subcomponents in the first place.

Summary

I dunno, these last few weeks have been a huge headache when it comes to development and I wish I had more for you guys in this update. I hope to have better new for you guys in the next update.

-Kami