Shooting/Hitting animations dead-zone?

[Deleted3645212User]

Hi everyone.

 

I found a problem that exists in both fallout new Vegas and fallout 3 and i think is related to animations.

 

I'll try to explain as best as possible but my English are terrible so please bear with me. :laugh:

 

The problem is that every time i fire any weapon, or even when i use unarmed/melee, there is a chance that the weapon won't fire or the melee hit animation won't start. Like there is some kind of dead zone when clicking near the end of the animated weapon recoil effect.

 

Example

 

1- I click the mouse to fire with a pistol.

2- The weapon fires normally and the recoil animation starts.

3- If i click again near the end of the weapon recoil animation the gun won't shoot at all.

4- If i click rapidly the weapon shoots normally using its rate of fire speed.

 

As i said, the same happens with unarmed and melee just the same. I click the mouse to throw a punch, the animation plays normally but if i click again while the punching animation playing its last frames(hit ends and hand goes into normal idle position) the click won't register at all.

 

The problem exists in all of my computers(Laptop windows 7, Desktop windows 10) even with unmodded setup. :mellow: Using a keyboard key to fire instead of using the mouse won't solve the problem.

 

[dubiousintent]

An "animation" is an internally scripted event. By this I mean that the sequence of images that make up the animation are programmed to take a specific amount of time, and once started the sequence has to run to completion before the CPU can act on another command. (Sound files work in a similar fashion.)

 

Your description indicates you are attempting to "attack" again before the animation is completed. The act of triggering an "attack" (either by mouse or keyboard) sends a signal to the CPU called an "interrupt" that tells it the device (mouse or keyboard in this instance) wants to perform some command (e.g. pass along the mouse button action or keystroke). "Interrupts" have a priority based upon the device type. When an animation is running, the CPU Input/Output (I/O) manager basically says to the mouse or keyboard: "not now" because of a higher priority task. The CPU has the option of "queuing" the request to act on later, or responding to the device "busy". (This option is usually determined by the program/game.) In the latter case the initiating device may respond to the request return with the equivalent (i.e. "busy") or by ignoring the response completely. That response depends upon the device. In the case of a mouse or keyboard, they are not generally "two way" devices and ignore any response; resulting in the command being ignored by both the sending and receiving side of the sequence: i.e. "nothing happens".

 

I hope you are realizing from this simplified explanation that there are a series of devices and processes that are involved in a choreographed series of events between you signalling an "attack" and the game responding. Just because you want to speed things up by initiating an attack before the recoil sequence is complete does not mean the computer or game can respond in that fashion.

 

Summary: Things are working as designed. You need to adjust your response to wait for the animation to finish. Some call that "timing" or "attack rhythm".

 

-Dubious-

[Deleted3645212User]

Summary: Things are working as designed. You need to adjust your response to wait for the animation to finish. Some call that "timing" or "attack rhythm".

 

-Dubious-

Thanks for the detailed answer Dubious but i think my problem comes during the last frames of the recoil animation and the starting frames of the idle animation. As i said above, if i start clicking the mouse rapidly(without giving a chance for the idle hand animation to start), the weapon shoots at its normal rate of fire without miss-clicks.

[dubiousintent]

If there is a question there, you answered it yourself: "clicking the mouse rapidly(without giving a chance for the idle hand animation to start)". In those circumstances, you managed to get your mouse "interrupt" asserted (recognized and it's priority accepted) before the animation was started, preempting it during the chain of events; and starting a new "attack" chain of events. Doesn't change my initial response: still a matter of timing.

 

Aborting an animation is in effect altering the game physics. You could (theoretically; I've never tried this) eliminate certain animations by replacing their ".kf" files with "null" versions (the same filename with no content). However, this would also eliminate the delay in the sequence of events that animation is providing, such as the effect of recoil on the aim of a firearm as well as the "cyclic rate of fire" it takes to move another round into position to fire or to reposition a melee weapon after a swing.

 

-Dubious-