[Nuke]

i dont consider it a problem that shotgun weapons count each sub-shot, i usually just have the analog ammo gauge on so i can see how fast ammo is being depleted. its far more useful than the numeric indicator.

[Solatar]

That all depends on how much ammo you are carrying.  If you can carry a few hundred shots and on up, visual representation is great.  If you've got a special weapon that carries 20 'shells', then a visual representation will be a bit harder to read (do I have 4 or 5 left?).

I don't know what the nature of the weapon the original poster had in mind, however.

[Dragon]

Somewhere between, but in fact, it'd just be more realistic for all shotguns to count shells instead of pellets.

[Nuke]

also you must note that weapons in one bank, say you have 4, and you fire one salvo, it will use 4 rounds. just be sure thats not whats causing the issue. if thats whhats causeing the extra ammo usage, thats kinda ok. but if its counting individual pellets, then i think its a sanity issue to just count that as 1 shot.

[Wanderer]

Via vectors its simple to force recoil from any direction to an object as a change in velocity vector. Imbalanced recoil would be trickier but doable (MOI) as it would (like it realistically does) generate torque and rotation..

As for casings.. I take the 'shot' option only expends as many 'shells' as described in the 'shots' value?

[Dragon]

Yes, it'd have to always round up to still count half of the shot as 1, but other than that, it'd just be ammo count divided by $Shots: value.

[Nuke]

Via vectors its simple to force recoil from any direction to an object as a change in velocity vector. Imbalanced recoil would be trickier but doable (MOI) as it would (like it realistically does) generate torque and rotation.

its math i had to figure out for my atmospheric flight model. i was going to do summation of forces from multiple sections of the airframe, of course i never got around to implementing the other stuff it would require, so i never did it. i did however do a test with a drag vector to see if the aircraft would turn itself into the wind, it worked for the most part, but i hadnt got to control surfaces yet and it was completely uncontrolable.

F =  force vector, P = point where force is applied in relation to the ship's center of mass, T = net torque, V = (change in) angular velocity, n =  number of forces, M = inverse! moi matrix
T = ((F1 X P1) + (F2 X P2) + (F3 X P3) + .... (Fn X Pn))

not sure if this is the right order but you do something like
V = T * M

then you just add V to the angular velocity of the ship, the physics code should apply caps for you to prevent the game from screwing up.

[Dragon]

It seems that the mathematics behind this aren't too complicated.
How difficult would be to make it work?