Author Topic: Most Up-to-date Ammo System Script?  (Read 5801 times)

It's not about the animation here guys, about the script.

Perhaps the "batter" script is actually better image states? Image states are, I believe, handled client-side, so the problem could be that the script is changing things like image ammo at the last moment on the bad one, while the other sets those values as early as possible, giving the clients time to recieve the information that the state has changed...

Perhaps the "batter" script is actually better image states? Image states are, I believe, handled client-side, so the problem could be that the script is changing things like image ammo at the last moment on the bad one, while the other sets those values as early as possible, giving the clients time to recieve the information that the state has changed...
That all happens in a matter of miliseconds silly.
I don't believe you really get the point by the way.
You only talk about time related things and image states.

A comment I have seen in quite a few copy-pasted scripts mentions that the image state data is sent to the client.

There is a function to set the image state, set if it has ammo, and set if it is loaded (probably if a clip is inserted).

Therefore, if the script changes the image state or sets the ammo/loaded immediately before a state that plays sound, the clients won't be notified of the change until (latency) ms later, thus allowing it to start playing the wrong state/sounds for a moment. A script that branches based on ammo and loaded, but sets the states as early as possible can comunicate the change to the clients before they start playing the wrong state.


Oh i get it.
But that would make it change very quickly right?
If it plays the state sound but is in an other state, it played, but very fast.

I think, i now get what you said.

I am terribly sorry.
Never thought about it that way.