How exactly does centerspeed work?

[psijaka]

Thanks for the feedback, OMFGSHAMBLER!!!!11

I may start a new thread when I am more confident of the methods used and when I have worked my way through all the combinations of guns and attachments.

I don't think that I will go beyond the 4th bullet though, as this is enough to see the trends emerging, and my spreadsheet is bloated enough as it is (the firing of 150,000 bullets simulated per gun/attachment combination).

[EDIT] - I find the results quite fascinating, especially the difference between the guns with low but biased recoil and those with larger but more random recoil, and the difference between the low and high ROF guns.

I knew from experience that the Famas and Galil pulled off target quite quickly on full auto, whereas the likes of the AK47/Aug were a bit wild but tended not to pull off target as much. And that the higher ROF guns were more difficult to control than lower ROF guns.

And look at the Skorpion !!![/EDIT]

Not familiar with how to sticky a thread; excuse my ignorance. As I said, I am new to the forum. How do you do this and what is the effect?

[n1gh7]

Don't worry about the sticky part, but make a new thread.

[mannon]

Sorry, my assumption that the M14 always cancelled out downward kick were based on someone else's math that suggested as much. I didn't really bother checking the math as that wasn't really my point.

My point was merely that just because a downward kick is completely compensated for by centerspeed that doesn't mean that it didn't happen. This assumption that kicks that recenter before the next shot is fired do not exist belies a misunderstanding of viewkick and centerspeed and I was just trying to point that out.

All viewkicks happen within the viewkick ranges of each weapon, but some are completely recentered before the next shot on one or both axis and become functionally irrelevant. (Unless you adjusted your aim to compensate for the recoil and thus actually caused yourself to be off target...)

In fact nearly every weapon would get some recenterings, as Den has been pointing out by calculating the odds of recentering. That is, unless the kick is favored so highly in one direction that it cannot fall within a range that centerspeed can return to zero in time. (Mebbe the Deagle from W@W, I recall it's viewkick being a box to the top and right, far away from center.)

Anyway, good thread!

[mannon]

I'm not sure exactly how you're modeling the 3rd, and 4th shots there. The math would get considerably more complicated than it is for the 2nd shot since even if the 2nd shot was off target (had leftover viewkick) the third shot could be kicked back into the area that can be recovered from. I'd like to know your methodology there.

[mannon]

Having done some math I make the M14's odds of landing a second shot below the first one to be at 10.93% with 44.8% centering out vertically and 44.27% going high. Of course those shots going high account for up to 53.12 units of viewkick not compensated for via centerspeed, while the downward kicks max out at a mere 13.12 units of viewkick uncompensated.

In other words the M14 does indeed have some actual downward kicked shots, but they are few and don't go very far.

Subsequent shots would have better odds of falling below the last one since once the gun climbs due to multiple upward kicks centerspeed is always trying to push it down. It is easy to understand why the gun climbs so much even when it is capable of kicking down however, considering it is capable of kicking nearly 3 times as far vertically in 1 shot as it can recover in it's firetime and it is twice as likely to kick up than down (before centering).

There are many other weapons, however which really are incapable of landing shot #2 below the first one. (Which is not the same as saying shot #3 couldn't land below #2, and so forth, due to the subsequent shots already being off center.) The FAL for example won't drop a 2nd shot below the first at all unless you use the ACOG and even then only 0.89% and only up to a whopping 0.8 viewkick uncompensated. Galil is similar but with ACOG does 3% and up to 2.4 uncompensated. Enfield won't go down on 2nd shot period.

BTW when it comes to that skorpion I gotta agree with psijaka, that's fascinating!

[mannon]

PS. How vertical is the vertical kick on an M14? Odds of completely recentering horizontally... 67.2% and the maximum horizontal kick uncompensated for is merely 13.12. Compared to numbers above the answer is VERY! Adding a grip cuts some of the vertical and a lot of the horizontal.

[psijaka]

I did some tests on the M14 this morning (GMT)

I shot off about 60 rounds and recorded whether there was upwards or downwards kick.

Virtually all of the shots had upwards kick, and I did not see a single downwards kick.

This troubles me, as with up/down kick figures of 80,40, I would have expected some shots to kick downwards.

Not sure what to make of this.

[mannon]

With odds at only 10.93% only about 6 of your shots on average should have gone down, and by a rather tiny amount considering there's only a maximum of 13.12 units of viewkick uncompensated. So I'm not particularly surprised you didn't really notice any.

In the video I linked earlier I noticed many downkicks, though the majority were well compensated for by the centerspeed before the next shot fired. I couldn't view it at good enough resolution or a slower speed so I couldn't really note if any of the shots landed below previous shots, though it was easy to see from the decals that many landed at the same height.

Sadly I don't have the game so I can't test it, myself.

[mannon]

I didn't want to hijack the other thread so I'm just posting this here. Seems like people want to see some M14 FAL comparisons so here you go some numbers to look at. Sorry there's no pretty graphics and it does come across as a wall of numbers, but they all tell a different story so bear with it.

[white]Data[/white]	[white]Value[/white]			[white]Odds[/white]	[white]per[/white]	[white]Region[/white]	[white][/white]		[white]Max[/white]	[white]Uncompensated[/white]	[white]Vkick[/white]
Weap, Attch:	M14, None			Left	Center	Right	Total		Left	Up	Right
Viewkick:	-40 L, 40 R, -40 U, 80 D		Up	7.26%	29.75%	7.26%	44.27%			53.12
CenSpd, Ftime:	1400, 0.096s		Center	7.35%	30.11%	7.35%	44.8%		-13.12	◄▲▼►	13.12
Full Recovery Time:	0.143s X, 0.286s Y, 0.286s Both		Down	1.79%	7.35%	1.79%	10.93%			-13.12
Recovery during Ftime:	26.88 VKUs		Total	16.4%	67.2%	16.4%				Down

[white]Data[/white]	[white]Value[/white]			[white]Odds[/white]	[white]per[/white]	[white]Region[/white]	[white][/white]		[white]Max[/white]	[white]Uncompensated[/white]	[white]Vkick[/white]
Weap, Attch:	FAL, None			Left	Center	Right	Total		Left	Up	Right
Viewkick:	-70 L, 50 R, -20 U, 70 D		Up	17.22%	21.46%	9.23%	47.91%			43.12
CenSpd, Ftime:	1400, 0.096s		Center	18.72%	23.34%	10.04%	52.09%		-43.12	◄▲▼►	23.12
Full Recovery Time:	0.25s X, 0.25s Y, 0.25s Both		Down	0%	0%	0%	0%			0
Recovery during Ftime:	26.88 VKUs		Total	35.93%	44.8%	19.27%				Down

This is all based on some mathematical theorycrafting based on what Den has revealed about centerspeed. This data applies to where a second shot would land at full ROF. Rather than doing brute force simulations I worked out the chances similarly to Den's formulas. Basically I treat each axis as an independent dimension, calculate how much VKick centerspeed can recover and subtract that from the VKick values.

It's all still preliminary and no it can't hope to tell you anything about about 3rd or later shots other than what inferences you can draw from the second. (Probability is no longer flat after the 2nd shot and thus gets way more complicated, though I have some ideas on how to do that in a fairly elegant mathematical model.

Also note that VKU stands for ViewKick Units. I did not attempt to convert them into degrees as I do not yet have a good formula for doing so due to the nature of how centerspeed works. I seriously doubt you can simply multiply those units by a single conversion ratio and it be accurate, but it still gives some idea so I used them.

I do have data on the attachments that alter these figures as well, but each combination has to be treated as a different weapon and I didn't want to toss 6 M14 tables and 3 FAL tables all up at once. (There are so many to account for every possible combination, since the Grip can be used in conjunction with the ACOG or IR Scope on the M14, though luckily the scopes themselves are mutually exclusive or we'd have even more.)

I'm also still refining this. It's all very much still just theorycrafting... as I said before. And I need a good hard look at it before I can say it's really 100% accurate.

In particular I've gotten a few figures different from Den's, though I think those discrepancies were explained. The numbers I have compared to psijaka's tables are quite similar, though. Since we are using two completely different methods yet getting similar results I am encouraged that we are both on the right track.

[psijaka]

Very interesting, mannon.

I can get as far as mathematically calculating the position of the gun when the second shot is fired, but after that it is brute force for me. And it makes for a very ugly and bloatescent spreadsheet (must write some code...).

The 3rd shot is much more difficult to predict as you need to know where the gun was when the second shot was fired. And so on.

Must think some more on this.

[psijaka]

@ mannon

Just plugged the numbers for the M14 and FN FAL into the theory part of my spreadsheet and I get the following percentage of second shots fired on target, IF the guns were fired at their maximum rate (a big if in reality).

M14 -------- 30.11%
FN FAL --- 23.34%

This is derived mathematically.
Reassuring that our numbers match to 4 significant figures.

Just for fun I popped the numbers into my brute force simulator, firing 50,000 shots, and I got:

M14 -------- 30.35%
FN FAL --- 23.08%

Not exactly the same, but close enough to give me confidence that the 3rd and 4th shot figures I derive from the simulator are reasonably accurate.

[mannon]

That's excellent news! Yeah when the gun starts from a nice fixed position and even after the viewkick it's just a big rectangle with perfectly evenly distributed probability across it... well it makes the math a LOT easier than 3rd and 4th shots. I've not even attempted those yet. heh Though, I have been thinking about it...

BTW for anyone else looking at the numbers up there I forgot to really explain the regions. Basically any of the four corner regions means that those second shots will land in a box somewhere in that 90 degree slice from the initial target, (unless the probability listed is 0% of course in which case it doesn't happen, ever.) There are also high, low, left, and right center regions. Shots falling in those will be on an exactly horizontal or vertical line from the target. (I always wondered why burst patterns randomly will often leave decals in horizontal and/or vertical lines... should have figured it out even with the specifics.) Then of course there's the dead center region and that one means the second shot lands exactly dead on target due to centerspeed cancelling out the viewkick for a region at the center.

This is literally the result of simply multiplying the X and Y probabilities per region since one axis doesn't care what the other is doing.

Anyway, I'm very glad to see things coming along and that makes me feel pretty good about my theorycraft too. heh Though, I'm still iffy on how to convert things into degrees. I should backup and go over Den's posts again.

[mannon]

Okay going back to the original topic. If I am reading this correctly then viewkick is applied as a velocity such as X degrees per second per VKU. If that is the case then the VKU it-self would simply represent a number of degrees per Y time, maybe a tenth of a second or something?

Centerspeed is then applied as an acceleration. Or more descriptively it is applied as a deceleration immediately after the shot is fired and then it transitions from deceleration to acceleration at the peak of the kick and begins pushing the view back to center.

We now know that centerspeed divided by 5 equals the viewkick that can be compensated for in seconds which means we can convert. In other words if these are applied exactly as stated then we know a few things. Let's take the M16's 1200 centerspeed as example just to have a number.

1200 CS can compensate for 240 VKU in one second. Now remember that to completely compensate for a kick centerspeed doesn't have to just stop the movement, but has to then turn it around and bring it back to zero. Luckily if acceleration is constant then the time needed to decelerate to zero velocity will also equal the time it takes to accelerate and move back to center. Therefore we know that 1200 CS also equals 480 VKUs per second because it takes twice the amount of acceleration to actually return to center as it would to simply stop the velocity in the same amount of time.

So, my question is, do we have a clue what timescale VKU's are on so we can go from arbitrary units to actual degrees? hmm... Even if not we could still map it out to distance units of arbitrary length and compare weapon to weapon. I just thought I would probe for more info.

One thing this definitely implies, though... is that merely noting how many VKU's go uncompensated won't result in a true map of the position of the next shot. For example, going back to our M16 it kicks up to 50 vertically up at it's highest vkick. Centerspeed would need ~0.208 seconds to recenter in the worst case scenario, but only has 0.064 seconds to do it. During that time it can only counter up to 15.36 VKU's. However what that means is that it can completely recenter that number, thus it is actually applying 30.72 VKU's during the 0.064 seconds it has between shots fired which isn't enough to even stop the upward motion let alone turn it around and head back towards center. There would still be 19.28 VKU's of upward force leftover when the second shot fired.

This brings up another thorny question.

What, exactly, happens when the third shot gets fired? Does the current velocity get simply overwritten with the new viewkick, or is viewkick added to the current velocity? If it gets added to the shot then it makes quite a bit of difference whether the view is still headed up or if it is moving back towards center already. If not then only the position it is at when the 3rd shot gets fired will matter. At the moment I'm leaning towards added to, just because it makes sense. If it is added then that means that centerspeed is always a constant force towards center and each shot is a force applied to the gun that instantly accelerates it in some given direction. If you don't erase the velocity each time then it all compounds somewhat realistically.

It's an important question to answer, though. Far more important than what the VKU's actually represent, even. Though I'd wager Den already has a pretty good idea.

It should be testable too by altering vkick numbers to remove uncertainty. For example change a full auto weapon's vkick stats to 0, 0, +100, +100 or in other words so that every single vkick = 100 up. Give it a 1 second firetime to make it more observable and make the math easy. Then you know a centerspeed of 500 should recenter the weapon on each shot while a centerspeed of 250 should mark the apex of it's kick with the second shot and then kick up at exactly the same amount for the third shot, and so forth, until it hits the max. Note: the results should be the same for 500 and 250 regardless of whether the current velocity is erased or kept, because in each of these cases the view has become stationary and has no velocity to keep. The question is what happens if the centerspeed is other than these numbers? Centerspeeds between 0 and 250 should result in the second shot happening while there is still upward velocity. Centerspeeds between 250 and 500 should result in it happening with downwards velocity as it is heading back to center. (Not inclusive... a centerspeed of 0 should result in the weapon flying up to max and never coming back down... if it doesn't cause a glitch which seems likely.)

Another way to test would be to keep centerspeed constant at say 500 but alter the firetime. As before 1 second marks the recenter time, thus 0.5 seconds should mark the apex. Anything between 0 and 0.5 is going up when the next shot fires and anything between 0.5 and 1 is going down when the next shot fires.

Sadly I only have any CoD games on xbox and a non modded box so I'm not able to test anything, myself. T_T

PS. Also note that there is a clustering around the apex of a kick, this is because the velocity is lowest there. Thus across all possible firetimes there would be more shots near the apex of the kick than near the center, and on a nonlinear scale. This in particular is why noting leftover VKU's in a linear scale won't give us truly accurate results. But if we know what happens to leftover velocity when the next shot is fired we can work out all the details.

PPS. That's all assuming the velocity/acceleration model of ViewKick and CenterSpeed is correct, though given the description of CenterSpeed being always at work I believe that it is.

[mannon]

Here's another way to think about it. CenterSpeed is gravity, center is the ground, and ViewKick is how fast you throw a stone (the view) strait up. (The stone's mass is irrelevant, you throw it at a given speed, not a given force so don't go too far with the analogy.)

[psijaka]

You have given me a lot to think about here, certainly enough to make me seriously doubt my method for calculating percentages of 3rd & 4th shots on target. But the results just look so convincing, especially if I simulate and plot a 10 round burst.

I dont know what to think about the possibility that the velocity towards the centre is added to the viewkick of the next shot (assuming that the gun had not recentered). This would tend to neutralise the tendency of a gun to pull off target when you fire long bursts, especially guns such as the Famas which have strongly biased recoil. But we all know what happens if you hold the trigger down on the Famas; it pulls away strongly upwards and to the right.

And what is the effect of the following Gunkick variables?

adsViewKickPitchMin = -30
adsViewKickPitchMax = 60
adsViewKickYawMin = 60
adsViewKickYawMax = -60
adsViewKickCenterSpeed = 1500

adsGunKickReducedKickBullets = 0
adsGunKickReducedKickPercent = 75
adsGunKickPitchMin = 5
adsGunKickPitchMax = 15
adsGunKickYawMin = -5
adsGunKickYawMax = 10
adsGunKickAccel = 800
adsGunKickSpeedMax = 2000
adsGunKickSpeedDecay = 32
adsGunKickStaticDecay = 40

I have been treating the Viewkick figures as the boundaries within which the gun kicks, and the centerspeed as the speed at which the gun recenters from the viewkick positions (divided by 5). The naming of these parameters suggests this.

I am not convinced that I am wrong in assuming this, as I believe that a simple method will have been used (why waste valuable in game processing time on overcomplicating recoil?), and it just seems to work. We all know that the Famas pulls up and to the right, and that is what I get when I simulate a 10 round burst.

[mannon]

Yes the names really do seem to suggest a fairly simple method and why I tended to think that the kick determined how far out it would kick to and centerspeed how fast it would get there and then come back. It may still be the case. I really don't know.

It just seems to me that the statement that centerspeed is always active and the way it appears that the view slows down at the apex of a kick and draws back rather than it being a simple flat speed suggests the method I mentioned. But then, that was all speculation, and sadly I have no way of testing it. But I suspect there are many here on these boards with more knowledge and/or means of testing so I thought I would bring it up.

Either way it is calculated I think we still need to know if the velocity is conserved or discarded when the next shot is fired. BTW this would not always result in helping recenter. You mentioned the FAMAS having extremely biased recoil. With a max viewkick of 60, centerspeed of 1600, and firetime o 0.064 that means the following should be true.

For ViewKick	Result	Approximate Odds
0<n<20.48	Recenter	34.13%
20.48<n<40.96	Post Apex, Inward Velocity	34.13%
40.96<n<60	Pre Apex, Outward Velocity	31.73%

Note: Technically it's a tad more complex than above because a kick of exactly 40.96 would be right at the apex with zero velocity when the next shot occurred.

By these odds the FAMAS is only about 2.40% more likely to have leftover inward velocity than outward velocity and keep in mind that the times it does still have inward velocity it is by definition not yet recentered and thus still has outward position working against it. All that outward position would dwarf the relatively small number of times it has a fortunate velocity more often than an unfortunate one.

On top of that consider that a lot of that inward velocity gets wasted when it hits zero and sticks there. On the other hand the outward velocity MUST be countered by centerspeed alone.

For the M14's vertical kick it works out to:
33.60% Recenter
33.60% Inward
32.80% Outward

Then throw an ACOG on it and you get:
24.00% Recenter
24.00% Inward
52.00% Outward!

On M14+ACOG more than half the second shots are being fired before the view has even started heading back to center!

We really need to know what happens to that velocity. For us it would be simplest if it merely goes away and isn't kept when the next shot is fired, but for building the game engine keeping it is literally as simple as 2+2, because it is merely the difference between overwriting the variables with the ViewKick function's output vs adding it to them.

Even if the velocity/acceleration model isn't accurate we do need to consider that the view takes a trajectory out and back in, and thus uncompensated viewkick won't work out directly to how off target the second shot is. Consider the semi auto sniper rifles from MW2. You could fire two shots from the M21 EBR before the recoil took you too considerably far off target. Firing earlier like that means even more VKU's not yet compensated by centerspeed, but the aim is also not, yet, that far off target. It will, of course, kick more off target. Perhaps the Barret is an even better example. You can't really be accurate on a second shot with it, but the recoil will throw you WAY off target if you wait for it. You can actually get a second shot closer to on target by shooting quicker.

In fact every distance (except the apex it-self) that the view will track off target during the entire kick will be crossed twice, (though with velocity in opposite directions).


As for the gunkick Den has shown that it is essentially irrelevant. The gunkick figures kick the gun in a various direction similar to the way the view is being kicked off target, but the recentering of gunkick is so fast that it is essentially zeroed out by firetime in pretty much every weapon. Den went so far as to give an AK47 zero idle or recoil, but left gunkick alone and it was a laserbeam across the map with negligible deviation off target.

[mannon]

It could still be that ViewKick represents literally a range of degrees and Centerspeed is determining a time it takes to return to center. If it is the game is still decelerating and accelerating back to center, it's just doing it in such a way that the apex would stop at the predetermined ViewKick angle. That would be nice for us, but you would have to calculate how much velocity to use to let centerspeed/5 still recenter in 1 second, and that wouldn't be a linear amount of velocity. That's why I'm thinking that ViewKick is actually a velocity, because it would be simpler to program... But then, who knows.

Some things, at least, work out quite predictably based merely on the recentering time, which we do know.

[asasa]

Feb 15, 2011 12:23:25 GMT -5 psijaka said:

I did some tests on the M14 this morning (GMT)

I shot off about 60 rounds and recorded whether there was upwards or downwards kick.

Virtually all of the shots had upwards kick, and I did not see a single downwards kick.

This troubles me, as with up/down kick figures of 80,40, I would have expected some shots to kick downwards.

Not sure what to make of this.

Yes, thats what I was trying to say. Even with Acog, where the recovery speed is dropped greatly, it NEVER kicks down to ANY degree.

[n1gh7]

For further clarification, gunkick is how much the gun moves on the screen. Viewkick is like how much your whole body moves, and gunkick is how much the gun moves in your hands.

[mannon]

Good. I thought that gunkick was relative to the view rather than target, but didn't want to say it without any sort of real knowledge. (Though I assumed with viewkicks as large as we have and gunkicks as small as the numbers suggest as well as the fact that the gun could kick in the opposite direction it would put the gun WAY off camera if it wasn't view relative.)

A pretty forced analogy is you are kinda like an R2D2 that can strafe with a tank turret for a head. (That sounds suspiciously like a Dalek, though they don't shoot out the eystalk, but still. heh) heh heh Actually that's not even accurate, I just found the visual image amusing. R2 could tilt his body forwards and back, something we in CoD can never do. Basically there's three levels. Ignoring the body of it and how you move around you basically aim like a tank turret, or a telescope. You pan or yaw left and right on an axis and tilt or pitch up and down on another, secondary axis. The pitch axis never affects the angle of the yaw axis, hence if you could aim strait up or strait down and spin in place you'd just be looking at the center of everything spinning. The pitch axis on the other hand very much is affected by they yaw axis.

But then there's like a turret on a turret on a turret... kind of... View Kick throws you off from the direction you aimed at without actually altering that aim, so if you let it recenter it-self you'll be aiming at the same spot you were in the first place. But it's really more of an offset, because while the pitch axis does indeed get rotated by the yaw axis the yaw axis always remains perfectly vertical, (or horizontal... however you want to look at it... when you turn sideways the turn always keeps level to the ground never moving the view higher or lower). Gunkick is parobably a similar offset rotating around the same point, but used just to throw the gun off a little to make it more visually interesting.

I don't think roll is ever used except for some special effects and is probably tied to pitch the same way pitch is to yaw so that roll always spins things around the center of the screen. (In other words if you could look strait down at 90 degrees then turning in either the yaw or roll axis would appear the same, though when you pitched back up you would notice the difference because if you rolled rather than yawed then the horizon would not be level.

Anyway... meh

This does, BTW, have the every so slight effect of bringing shots pitched high or low closer on the horizontal scale. Of course, unless you are aiming very high or low close to the zenith it won't make much difference, and is probably why they don't let you actually aim all the way strait up or down. Of course I could be wrong and the viewkick axis COULD be rotated by pitch as well so that it's always centered. It would still have a slight narrowing effect when pitched up and down, but you wouldn't notice unless it pitched a LOT. A 90 degree pitch would squash down the horizontal offset to zero regardless of the horizontal kick, for example, but you'd already be so far off target it wouldn't matter and no weapon kicks that far due to the max kick stats. Still... I find it somewhat interesting since it does make vertical and horizontal recoil ever so slightly, but fundamentally different.

But now I'm just chittering because I still can't answer the questions I really want to know about recoil. heh

Although... I have been thinking about this velocity/acceleration vs distance/speed modeling thing and I'm not really sure that there IS much of a difference in the two after all. It just seems like knowing that centerspeed is directly linked to vkick and time and knowing that the kick it-self follows a somewhat natural looking deceleration movement rather than a flat velocity out and back in... the two could be approximately equivalent to each other... But here I'm merely speculating, I haven't attempted to do any math stuffes on it... though I'm itching to.

Unfortunately this also really complicates the chit out of the ideas I had for modeling subsequent shots mathmatically as well, whereas before it seemed nice and neat... just complicated.

But, we'll figure it out.

[psijaka]

This is all getting very complicated, and I can't help feeling that it must have been simplified in some way, just to cut down on the processing required. After all, who will notice if the recoil is not perfectly modelled? Where the bullets go, hit detection etc is where the accuracy is needed.

So I thought "how would I handle recoil if I was the programmer, and wanted to keep things as simple as possible?".


I will work in one dimension, considering recoil that kicks vertically upwards only, for simplicity.

Our starting point is that we have a set of figures defining the range of viewkick, lets say proportional to degrees. This makes sense if the parameters are named pitch and yaw. We also have centerspeed; I will assume that this is related to speed as speed is in the name.

So when we fire a shot, we get kick applied to the gun, and recentering to pull the gun back to zero. As the gun does not immediately go to it's maximum deflection as defined by the kick figure, I will assume that the kick figure is where the gun wants to go, it's intended "destination", for want of a better phrase..

But this destination changes as recentering is applied, so that after a period of time:

Destination = Kick - recentering/5 * time

This gives us a straight line decreasing linearly to zero (recentered) - the blue line on the graph. The gun does not behave like this though. To simply simulate a more realistic movement, we can say that the gun moves part of the way to its destination within a given time period.

Let us choose 4 ms as a time period (I note that all firetimes are multiples of 4ms). And then let us say that the gun moves 0.25 of the way from where it it to it's "destination" within this time period. The red line is what we get.

We could choose different time periods and "travel factors" to get a similar effect.



EDIT
Viewkick = 80 (vertical axis)
Recenter = 1500


Fantasy, I know, but what if.....

[mannon]

To me that actually sounds... more complicated. ;p

If ViewKick represents a number in degrees, but we don't immediately jump to that position then surely it represents the position we should be at after a given amount of time. But, if that's true then it is the very definition of velocity because distance/time=velocity.

As for centerspeed I don't know... Maybe it is like you say and it represents the maximum velocity that the view will take on the path back to center, but if that's true then what governs the acceleration that eases us into it from the initial kick? Well considering viewkick*5 worth of centerspeed always recenters in one second it would have to be based on centerspeed as well, somehow.

Also consider that they already have the functions to handle acceleration and deceleration, ect. The game has simulated physics built in already due to the very nature of it. So why build a physics fudge function instead of just using velocity and acceleration with code that is already in the game, or at least very similar code to it?

But, again... I could be very wrong about all that. I just can't think of a way to model it that seems simpler and more direct. That doesn't mean it doesn't exist, however...

Oops... got distracted... Just gonna post whatever the hell I was saying. Been too busy doing math...

[psijaka]

Think about it another way. If you point your finger at someone and pretend to shoot them (with a Python, say), you would jerk your hand sharply upwards to simulate recoil, and then allow your hand to drop more slowly back to where it was. This could be achieved by using my "fantasy" approach outlined above. Not that I am saying that this is exactly how it is done; no doubt there are other ways of achieving this.

If we were to say that viewkick were a velocity and that recenter speed was an acceleration applied to this, then the analogy of throwing a stone vertically upwards is a good one. If we were to plot it's height against time we would get a sine wave, which is not what we want at all if we want to simulate realistic recoil.

Food for thought?

[psijaka]

Feb 18, 2011 10:28:23 GMT -5 mannon said:

To me that actually sounds... more complicated. ;p

If ViewKick represents a number in degrees, but we don't immediately jump to that position then surely it represents the position we should be at after a given amount of time. But, if that's true then it is the very definition of velocity because distance/time=velocity.

As for centerspeed I don't know... Maybe it is like you say and it represents the maximum velocity that the view will take on the path back to center, but if that's true then what governs the acceleration that eases us into it from the initial kick? Well considering viewkick*5 worth of centerspeed always recenters in one second it would have to be based on centerspeed as well, somehow.

Also consider that they already have the functions to handle acceleration and deceleration, ect. The game has simulated physics built in already due to the very nature of it. So why build a physics fudge function instead of just using velocity and acceleration with code that is already in the game, or at least very similar code to it?

But, again... I could be very wrong about all that. I just can't think of a way to model it that seems simpler and more direct. That doesn't mean it doesn't exist, however...

Oops... got distracted... Just gonna post whatever the hell I was saying. Been too busy doing math...

It is actually very simple. Here is the basis of the maths in the spreadsheet:

Gun "Destination" = Kick - Centerspeed/5 * time since shot

Current gun position = Previous gun position + (Destination - Previous gun position) * travel factor

I used time intervals of 4ms and a travel factor of 0.25; chosen after a bit of fiddling around to give a nice response up to the time the gun reaches it's "destination", as described in the first equation.

Once the gun position actually reaches it's destination, then it's position is entirely controlled by the effects of recenter time upon the initial kick, allowing us to determine the recenter time according to the methods previously discussed.

Even though there will be functions built into the program to handle acceleration etc, these will still take up more processing time than more simple mathematics, even if writing code to avoid using these functions means more work for the programmer!

EDIT - please don't take my fantasy method too seriously; I was just trying to demonstrate that there are other ways of achieving semi realistic recoil. I am very uneasy about treating ViewKick as a vector and Centerspeed as acceleration.

[mannon]

I think you overestimate just how difficult the math would be for a velocity/acceleration model. I was able to graph it after just looking up a couple of formulas on Wikipedia, and keep in mind that they don't even have to graph it, they only need to know where to put the view from one frame to the next, which basically means they need to track the velocity anyway, regardless of model.

As for modeling recoil accurately then sure, you'd want to come back down slower. but then again you'd also have to slow down before stopping in the middle, and you would probably overcompensate and actually wiggle back and forth a bit before settling, kinda like if the gun were on a spring. We know flat out neither of these effects take place. CoD is a good shooter, but a lousy simulation.

Anyway my point is basically this, why treat the upward arc differently than the downward arc if you don't have to? It's not like many players would notice, and from anecdotal experience I don't believe I recall seeing weapons settle slower than they kick. It appears to me that the inward velocity matches the outward velocity, though it does taper off at the apex.

That's not to say my model is correct it's all just theorycraft, but we are getting there. I just really friggin wish I could mod the game to run tests. heh

Here's a graph I did based on a velocity/acceleration model. I used the M14's vertical kick (max 80), firetime of 0.096s, and centerspeed of 1400. The vertical units are the equivalent of whatever ViewKick units are worth per second. In other words if they are literally degrees per second, (not likely) then they are degrees. If VKU's = degrees per oh say 0.4 seconds then I believe each would be 2.5 degrees, ect...



Still... I'm not even saying that this IS the model. But I think it as likely as any other present candidates. Now we just need a little more testing to work out the kinks and iron it down.

Note that in this graph if CenterSpeed were zero 80 maximum kick represents a velocity that would put the displacement at 80 in exactly 1 second. The fact that it never even reaches 6 is due to the fact that CenterSpeeds are set at levels easily high enough to counter nearly every weapon's maximum ViewKick in well under a second.

Also note you can see clearly how kicks greater than 53.76 would have outward velocity while kicks less than 53.76 would have inward velocity.

The formula I used to determine the position or more accurately, displacement, only needs three variables: Initial Velocity, Acceleration, and Time which are ViewKick, CenterSpeed/-2.5, and Time.

BTW dividing CenterSpeed by -2.5 isn't mysterous. The negative number is just to point the acceleration down, back towards the center, just the same way you would use -9.8m/s² for gravity. As for why 2.5, that's simple. It takes ViewKick times 5 to return to center in 1 second. But remember that the acceleration is applied both on the way up and the way down. In other words to recenter a ViewKick in 1 second you are applying a total of twice the velocity of the kick during that time since only applying the total amount of acceleration would merely stop at the apex rather than recentering.

The formula is:
Displacement = MAX( ViewKick * Time + 0.5 * ( CenterSpeed / -2.5 ) * Time², 0 )

"Max( X, 0 )" of course just flattens us out at zero rather than plowing right through it and going negative. I'm not sure how to note that except with the spreadsheet function so you get that. heh

[mannon]

Okay I couldn't resist... Somebody a ways back had mentioned getting wonky looking recoil returns after some shots and it stuck in my head that you really would get some pretty weird stuff since one axis can recenter before the other one.

Since I already had one dimension graphed I added a couple more rows and substituted the other dimension for time.

This time I only graphed the maximum up and right kick from the M14... a pretty rare happenstance, but still.

The net result is predictably wonky indeed.



I suppose it would have been nice to mark where on this plot the firetime happens, but I didn't do that, nor is it in scale to the other graph. Sorry. I did try to match the horizontal and vertical scales so that they would be square, but I only eyeballed it.

In such a kick the view is almost still going up when the horizontal kick recenters, which results in a hairpin turn taking the view strait down towards center.

Of course had it still been going up things would have gotten weirder still as the horizontal kick would stabilize at 0 but the vertical would have kept going strait up from the leaf shape before coming strait back down.

As is this is actually hitting right at the apex since the max horizontal kick is exactly half the max vertical on the M14. ;p

Of course this is the extreme case

[psijaka]

Food for thought here. I have been thinking along the lines of the stone analogy. As you say:

x=ut+0.5at²

x = displacement
u=initial velocity (viewkick)
t=time
a=acceleration (centerspeed)

(I should remember this stuff; I went to the same school as Newton - true!)

But I am still very uneasy about this method. Will post back once I have done some (more) sums!

[psijaka]

It could work.

For the Famas:
Centerspeed=1600
Fire time=0.064
Max recentering between rounds = centerspeed / 5 * firetime = 20.48 (as discussed elsewhere on this thread)

Applying 20.48 as an initial velocity:

Displacement = 20.48 * 0.064 - 0.5 * 1700 / 2.5 * 0.064² = 0

Recentered!

Still not proof that this is how it is done, but it could be. EDIT - time to plug the formula into the simulator, I think.

What we need to do is to do a video capture of a good vertical kick, and analyse it frame by frame, measuring the displacement, and plotting the results to look at the shape of the displacement/time graph. If it is a sine wave.....

Any volunteers?

[mannon]

What would be really super keen is to mod a weapon to have a single kick variable rather than a range. Something like 0, 0, +80, +80 so we know exactly what the vkick is on every shot. Then fire it off and record it, note how it accelerates and decelerates as you say, and while we're at it note the exact apex in degrees. (Should be able to determine degrees off target visually as long as we know the FOV, though I don't know the math to convert pixels to degrees... I know it isn't linear, though. Then again I doubt it would be hard to lookup.)

Of course... it might not be a sine wave... heh But if it is this could work and if we can figure out the apex of a known kick/centerspeed then we can work it backwards to figure out exactly what VKU's represent in terms of velocity.

We also still really need to know what happens to velocity when the next round is fired, but that's pretty much an either or situation and should be easily testable, especially if we work out the rest.

[arcanine2009]

<i>No, what Den is saying is much, much simpler. To make a more general statement:

(5 * viewKick) / Centerspeed = Time to return to center

To put it a better way to analyze how it would apply to recoil of a certain gun:

(FireRate * Centerspeed) / 5 = Maximum viewKick allowed to be able to fully recover from shot fired

You could probably reference this value against all possible viewKick values of any given gun and create a hitmap of some sorts.</i>

Interesting.. I did the calculations for time to return to center..

For WaW smgs, type 100, thompson, and mp40 are pretty much the same.


for sniper rifles in black ops

.65 for dragunov
.39 for WA2000
.475 for PSG-1.