Move control would feel very artificial: No collision check, no terrain check, etc...
I still think the best way would be to tell it to move sideway with turret straight (or rather, counter-turned). Make the unit have a very high turning rate, so turning is instant. Make pressing left strafe or right strafe tell the unit to move left or right, with turret turned +/-90┬░. Of course, if the unit is under direct control, move order might be ignored, and that'd be an issue. I'm also not sure you can turn the camera 90┬░ if it's in direct control mode. I am supposing your mod still use the hard coded "C" direct control mode. I would instead switch to a system like in my
HOMF, where the engine think not a unit is controlled, not a unit is selected, but a gadget translate keypresses into move order (technically, SetUnitMoveGoal). Have you tried
HOMF yet? There strafing is not a problem: you move in any of the eight direction with the four arrow key, while aiming freely 360┬░ with the mouse. Yes, my
HOMF is using a top down view instead of a first person view. But that is just a matter of rewriting the SetCameraState line. You will also want to change a bit the keys->SetUnitMoveGoal conversion so that's it's relative to the direction camera is pointing instead of map's absolute N-S-E-W. As an extra, maybe change what it does with mouse pointer from "point to world coordinate pointed by mouse" to some "turn accordingly to mouse screen coordinate", but that might not even be necessary, or simply use middle-click mode.
- Unlike move control, in my
HOMF system the unit is still subject to the game's physic.
- Unlike hard coded direct control, in my
HOMF system you have full freedom to lua whatever behavior you want.
I heard Regret implemented some sort of virtual unit. See his topic
SpecRun - Your own imaginary unit. Use it to convert user controls to FPS movements. Then bind it to a physical unit, with code from my shoot_n_run.lua gadget. And you'll have far better FPS control than the hard coded "C" direct control. Yes, you do need to know Lua to glue my code to Regret's code, then polish at the corner. But, those two Lua codes show good FPS control is possible in Spring without engine changes. Multiplayer would still suffer from the unresponsivness from Spring networking model, but quit Spring and go use a true FPS engine if you need position prediction and smooth handling of lag.
In short: Pretty much implemented in other projects, but you need to learn Lua to bring it together.