[Hanzolo]

Very interesting find. This is like finding the holy grail imho. So many tournaments and games... Unbelievable. Valves alfred is right when saying that the gamers just got used to the false mechanics but I wonder how it feels when it calculates correct. Now I'd like to digg deeper into the time related cooldown. Which source file is it? Can you please give me a hint where to look? Also do you know which weapons besides ak and g3sg1 are also effected from this issue?

[Hanzolo]

Yea, I know, it could be shorter, but in that case it would require a lot more "if's" in the code, and that's a bad thing, since shooting function is called quite often in the game, and therefor the server will use more resources, and therefor chance of laggy server will increase. Weapons are using different math formulas for their bullet accuracy calculations.

Good to see you are caring about performance of your code. Imho less code might be faster to load, but I am no coding expert to judge the performance of this or that code.

--- Bullet spread discussion beginning here ---

Except, that you have forgotten, that when weapon is idle, the "m_iShotsFired" is slowly resetting back to 0 (which happens within weapons PostFrame function). Oh, and also even when it's 0, the accuracy calculation which goes, still wont be as dead-on-center compared to what it is after reload or weapon switch. But that you have already mentioned. Good, you have figured out that spread is assigned before the accuracy variable is changed, and that that is what is causing "use the last fire bullet glitch".

So the first bullet after a false cooldown ("m_iShotsFired" = 0, "m_flAccuracy" not changed yet) will have the last "m_flAccuracy" from the previous burst. This can cause an well recognizable issue when the first bullet after a heavy spray - which casues the "m_flAccuracy" values reaching high numbers (20-25 shots with AK f.e.) - will hit very far away from the crosshair. The second shot will be calculated correct and will hit almost pin-point accurate as can be seen in the value table below.

Also you see that there is no possible case scenario when "m_flAccuracy" is changed, with "m_iShotsFired" being 0, so one bullet calculation is just missing from the code, since (let's take the ak47 example) with the reload or switch accuracy variable is 0.2, but in any other case scenario best it can be is "0.35 + ( ( 1 * 1 * 1 ) / 200 ) = 0.355". So from 0.2 it just jumps to 0.355, then to 0.39. Which is a problem in 2 ways. Cause the normal 0.35 is just missed, and if that's not enough, the transition isn't smooth at all.

I don't aggree on this one. Who tells you that 0,2 is not the supposed "m_flAccuracy" for the first shot? You are saying it should be 0,350 because you assume the same formula should be applied when m_iShotsFired = 0, therefore calculating the accuracy for the first shot. It can also be that the first shot should have a fixed m_flAccuracy of 0,2 - we both don't know what the truth is (yet)!

For AK the "m_flAccuracy" values are:
After reload or weapon change: 0,2 (used in the 1st shot after reload or weapon change) - you are saying it should be 0,350 which is a view I can't follow at the moment (see comment above)
m_iShotsFired = 1: 0,355 (used in the 2nd shot after reload/weapon change and in the 1st shot after false cooldown - as opposed to the 0,2 you get when reloading/switching)
m_iShotsFired = 2: 0,390 (used in the 3rd shot after reload/weapon change and in the 2nd shot after false cooldown)
m_iShotsFired = 3: 0,485 (used in the 4th shot after reload/weapon change and in the 3rd shot after false cooldown)
m_iShotsFired = 4: 0,670 (used in the 5th shot after reload/weapon change and in the 4th shot after false cooldown)
[etc.]

I recorded a video for myself:
https://www.youtube.com/watch?v=0e9aSdCUdVY
At 0:28 you can see the bug occuring when I shoot my 10th bullet (leaving me with 9 bullets in the mag). The bullet does not hit where the crosshair is although I am not moving.
Ok, now I am fully understanding your post #30 here.

What about the recoil issues? What is wrong with the punchangle and why is the engine acutally jumping to the 4th shot as you mentioned in #30?

[ezio_auditore]

Least Known Bug....
Thanks...
Awesome Plugin..
Cheers - ezio

[MPNumB]

Originally Posted by Hanzolo Very interesting find. This is like finding the holy grail imho. So many tournaments and games... Unbelievable. Valves alfred is right when saying that the gamers just got used to the false mechanics but I wonder how it feels when it calculates correct. Now I'd like to digg deeper into the time related cooldown. Which source file is it? Can you please give me a hint where to look? Also do you know which weapons besides ak and g3sg1 are also effected from this issue?

To be perfectly honest, the file of where "m_iShotsFired" is cooling down, I was not able to find. However I did many debugs, and did find out that it was cooling down (makes sense). However due to low fps, there can be a bigger delay from one frame to an other where the variable lowers itself. After a lot of research I found it to be within PostFrame of the weapon. Without knowing exactly what was going on, I looked at code from Source engine, and it did answer some questions. So I ran some more tests, and came to the conclusion that if player isn't holding attack button, and "m_flDecreaseShotsFired" is lower than "get_gametime()", the "m_iShotsFired" will decrease by 1. The low fps thing happens cause there's usually a time difference between when "m_flDecreaseShotsFired" can decrease, and the time when it will decrease (frames aren't in perfect sync with it). And the less fps there are, the bigger the time difference becomes. And eventually it adds up. If I remember right, max "m_iShotsFired" is 16, but at 20 fps, my fix fixes it 8 times. So 20fps and 8 times, is = 0.05*8=0.4sec difference. Just in case, what my fix does, is gets the time difference between when "m_flDecreaseShotsFired" can decrease and frame time when it actually happens. And it removes that time from next 'wait time'. If wait time is less than 0, than it decreases "m_iShotsFired" by 1 + the amount of original delays what could happen during that left over time. And at the end if some time less than original delay is left, then it's set to be the next delay (if not original delay is set). And then the cycles repeats itself in next frame when "m_iShotsFired" is decreased. The wrong accuracy calculation - all weapons which have the math in it. G3SG1, Scout, and AWP are hardcoded. To change their values you need to change player zoom/on ground/velocity conditions, or use orpheu. The low fps glitch - all automatic weapons.

Originally Posted by Hanzolo Good to see you are caring about performance of your code. Imho less code might be faster to load, but I am no coding expert to judge the performance of this or that code. --- Bullet spread discussion beginning here --- Except, that you have forgotten, that when weapon is idle, the "m_iShotsFired" is slowly resetting back to 0 (which happens within weapons PostFrame function). Oh, and also even when it's 0, the accuracy calculation which goes, still wont be as dead-on-center compared to what it is after reload or weapon switch. But that you have already mentioned. Good, you have figured out that spread is assigned before the accuracy variable is changed, and that that is what is causing "use the last fire bullet glitch". So the first bullet after a false cooldown ("m_iShotsFired" = 0, "m_flAccuracy" not changed yet) will have the last "m_flAccuracy" from the previous burst. This can cause an well recognizable issue when the first bullet after a heavy spray - which casues the "m_flAccuracy" values reaching high numbers (20-25 shots with AK f.e.) - will hit very far away from the crosshair. The second shot will be calculated correct and will hit almost pin-point accurate as can be seen in the value table below. Also you see that there is no possible case scenario when "m_flAccuracy" is changed, with "m_iShotsFired" being 0, so one bullet calculation is just missing from the code, since (let's take the ak47 example) with the reload or switch accuracy variable is 0.2, but in any other case scenario best it can be is "0.35 + ( ( 1 * 1 * 1 ) / 200 ) = 0.355". So from 0.2 it just jumps to 0.355, then to 0.39. Which is a problem in 2 ways. Cause the normal 0.35 is just missed, and if that's not enough, the transition isn't smooth at all. I don't aggree on this one. Who tells you that 0,2 is not the supposed "m_flAccuracy" for the first shot? You are saying it should be 0,350 because you assume the same formula should be applied when m_iShotsFired = 0, therefore calculating the accuracy for the first shot. It can also be that the first shot should have a fixed m_flAccuracy of 0,2 - we both don't know what the truth is (yet)! For AK the "m_flAccuracy" values are: After reload or weapon change: 0,2 (used in the 1st shot after reload or weapon change) - you are saying it should be 0,350 which is a view I can't follow at the moment (see comment above) m_iShotsFired = 1: 0,355 (used in the 2nd shot after reload/weapon change and in the 1st shot after false cooldown - as opposed to the 0,2 you get when reloading/switching) m_iShotsFired = 2: 0,390 (used in the 3rd shot after reload/weapon change and in the 2nd shot after false cooldown) m_iShotsFired = 3: 0,485 (used in the 4th shot after reload/weapon change and in the 3rd shot after false cooldown) m_iShotsFired = 4: 0,670 (used in the 5th shot after reload/weapon change and in the 4th shot after false cooldown) [etc.] I recorded a video for myself: https://www.youtube.com/watch?v=0e9aSdCUdVY At 0:28 you can see the bug occuring when I shoot my 10th bullet (leaving me with 9 bullets in the mag). The bullet does not hit where the crosshair is although I am not moving. Ok, now I am fully understanding your post #30 here. What about the recoil issues? What is wrong with the punchangle and why is the engine acutally jumping to the 4th shot as you mentioned in #30?

Will be answering as I read through. Yes, and no. The first bullet after a long burst is inaccurate - that's right. The second bullet after that is inaccurate as well, since it's more accurate than it should be (it uses accuracy of what acc should be in first bullet) (pretending you shot 2 bullets in a row). But since there's a glitch as well "m_iShotsFired" is always one higher than it should be, the calculation is accurate. Except that transition isn't smooth at all and needs fixing, and one value is still missed.

No, you misunderstood. I'm exactly saying that 0.2 should be the accuracy of the first shot (and if your not moving and ducked, it should be 0.0, which I've made in the plugin - dead on center). And that by idea 0.35 should be the accuracy of the second shot (though it isn't) - it's 0.355. So I fixed that to be 0.35, by lowering "m_iShotsFired" by 1. But you can still see that 0.2, 0.35, 0.355 isn't a smooth transition, so I added an other smooth transition function for that.

What values I'm saying were intended are:
0.2
0.35
0.355
0.390
0.485
...
Here's how values actually are without the plugin:
(whatever previous value was)
0.355
0.390
0.485
...
Here's how 1.0 version of the plugin worked:
0.2 (or 0.1 if standing and not moving and on ground, or 0.0 if ducked not moving and on ground)
0.355
0.390
0.485
...
Here's how 2.0 version works if you disable smooth transition:
0.2 (or 0.1 if standing and not moving and on ground, or 0.0 if ducked not moving and on ground)
0.35
0.355
0.390
0.485
...
Here's how 2.0 version works (by default) with enabled smooth transition:
0.2 (or 0.1 if standing and not moving and on ground, or 0.0 if ducked not moving and on ground)
0.2+0.05+0.000 = 0.25
0.2+0.10+0.005 = 0.305
0.2+0.15+0.040 = 0.39
0.2+0.15+0.135 = 0.485
0.2+0.15+0.320 = 0.67
0.2+0.15+0.625 = 1.02
0.2+0.15+1.080 = 1.43 // higher than 1.25, so 1.25
0.2+0.15+1.715 = 2.065 // higher than 1.25, so 1.25
...

Post #30 isn't my. It's

Originally Posted by b0n40 My FAV PLUGIN for all times ! gameplay is much better!

Maybe you meant my post #28 ?

Originally Posted by MPNumB Well, I wouldn't say that this plugin will work for the bad, cause... Cause I'm actually fixing, so bullets would go in the crosshair (where people expect them to go), and not in some random spot. Cause I would like to note: this isn't weapon recoil - it touches nothing in recoil. It fixes accuracy compared to the crosshair what has nothing to do with the recoil.. Accuracy itself is something what is randomized in the engine, and it cannot be learned. In other words, this type of accuracy is exactly the same random as firing bullet with awp while in air and without zoom, except case scenario with awp has a higher value length through what it can choose a random number.

If this one, well... There are 2 things in... Bullet spread (which is most of what is being talked about here - how far away from where bullet should hit, it hits). And recoil. Recoil is just how much your angle changes, and it has nothing to do with spread. Spread always starts calculation from the middle (which is angle+punchangle, which is your recoil). However there also is a recoil glitch where it's actually angle+punchangle+punchangle, and that's why bullets fly way above your crosshair when you are spraying. That is a visual issue mostly. It is too late to make a fix for that, cause that will mess up the game quite a lot. Yet non the less, I've made a fix for that one as well: Recoil Fix.

[Fr33m@n]

Does this plugin can cause problem with theses kind of plugins ?

no recoil using punchangle set to 0 in Primary attack in post.

fire rate managing, like shooting 2 time faster with a CS weapon.
When i have time, i will try to recreate CS way using CS souce code as a base

PHP Code:

// CS
float CBasePlayerWeapon::GetNextAttackDelay( float delay )
{
    if( m_flLastFireTime == 0.0 || m_flNextPrimaryAttack == -1.0 )
    {
        m_flLastFireTime = gpGlobals->time;
        m_flPrevPrimaryAttack = delay;
    }

    float elapsedFireTime = gpGlobals->time - m_flLastFireTime;
    float timeOffset = 0;

    if( elapsedFireTime > 0 )
    {
        timeOffset = elapsedFireTime - m_flPrevPrimaryAttack;
    }

    float nextDelay = delay - timeOffset;

    m_flLastFireTime = gpGlobals->time;
    m_flPrevPrimaryAttack = nextDelay;

    return nextDelay;
} 


Do you think that your plugin could interfer with this kind of stuff ?

[MPNumB]

Nope. This plugin just modifies spread. It has nothing to do with time between shots, or even punchangle. As long as you don't execute for pistols an extra Ham_Attack at Ham_Attack pre with a plugin that goes after my in plugins.ini list, or at Ham_Attack post with a plugin that goes before my in plugins.ini, you shouldn't have no problems.

[KaranMohadkar]

is this means when a player connects or disconnect server starts to lag ? [ can affect bullet spray etc........ ? ]
even why server lags ?

[MPNumB]

This plugin has no possible way of lagging a server due to reconnects and things like that (in fact it has no possible way of doing anything more than it's designed to do). You should google what is wrong with your config, and/or server settings.

Even if some other plugin is somehow conflicting (which is highly unlikely, since there are almost no plugins which even use similar pdata offset, and even if would, there almost had to be an intentional design to lag), it wouldn't be possible for it to crash the client.

[souvikdas95]

@MPNumB, I was playing aim_usp map and the accuracy of the weapon was really bad. i was getting a stable latency of 60 ms. Many other players also complained about the bad accuracy of glock. When I removed this plugin, the accuracy became stable and proper. Please check. I am using build 6132 mod cstrike.

[MPNumB]

Okey... Let's see... Were they using burst mode? By default (and this plugin doesn't fix this next glitch) glock when in burst fire is more accurate when running than while standing still. Maybe I should write a special fix for that in this plugin as well, just to avoid this kind of 'feel's.

If it was more than just glock... What I can say to that, did you watch the demos from the first post? That's what this plugin does, plus other features what I've written in the description. So, only possible reply what I can give to address this issue is, if people '''feel''' that 0 is a bigger number than 1, then there's nothing technical what I can really do about it, now is there.