Trouble with tracking bullets, and Multiplayer.

[kevb0]

EDIT: Thanks mod

I've been messing with attaching sounds to bullets and the like, but am coming across some trouble with it in some cases in multiplayer.

For example, I've got a D30 with a firedEH attached to it. When the FiredEH is triggered, it will locate the shell via Nearobjects and use the Say command.

This is what it looks like:

Code: [Select]

_bullet = nearestObject [getpos _this select 0, _this select 4];

while  {alive _bullet} do
{
_bullet say "Sound";
sleep 10;
};
;

That works perfectly fine for players near the firing gun, but for players who are far away, the fired EH won't even activate.

I've tried a number of things, such as:

Code: [Select]

_bullet setvehicleinit "[this] execVM 'makenoise.sqf'; "; processinitcommands;
That doesn't work, as SVI only works on units, not shells.

Code: [Select]

"ShellInFlight" addPublicVariableEventHandler {[_this select 1] execVM "makenoise.sqf"; };
ShellInFlight = _bullet;
publicvariable "ShellInFlight";
for some reason, if run locally on the firer, the firer will see ShellInFlight as 234123: Shell.P3D, but other clients will see <NULL-OBJECT>, if they are a large distance away.

The most successful way of getting sounds to play on a shell in flight, regardless of the client's distance from the firer, is by creating a gamelogic or invisable H, forcing that to play the sound, and continously setposing it to the location of the shell in the air. However, that removes the doppler effect, and sounds kind of akward.

Do any of you guys have suggestions to get all clients on a server to hear the sound of a bullet, even if the bullet is out of visual range?

Thanks in advance.

[Mr.Peanut]

The problem is that the projectile is not a common object on all clients. There is a second way you can deal with this.
1) Use fired eventhandler to delete the original projectile after recording its position, orientation and velocity.
2) PV this information
3) Have a public variable event handler locally create the shell on each client and call the noise script.

Issues:
-projectile will not be exactly in sync for all clients.
-public variable event handlers do not fire on the machine that PV's. Make sure you execute step 3 on this machine.

[kevb0]

That's what I ended up doing, Mr. Peanut. Well, almost, not exactly. I had the firer delete the shell, and create a new one. Once created, I publicvariabled [_shell,_shellvelocity,_shellposistion], and addpublicvariableeventhandler would catch that and setpos/setvelocity the shell. It works decently, however, it is a pain.

Do you know what would happen in a multiplayer enviornment with multiple local shells impacting, near a non-local unit? Would the non local unit be damaged?

[Spooner]

Yes, the shells on every client would cause damage globally! Perhaps use something like a pistol bullet on clients to mimic the shell fired by the server? This way, you don't get the impact effects (sounds, particle effects, direct and splash damage) multiplied by the number of players, but you do get something that will move in the correct ballistic arc (well, I assume it would be the same) and has minimal effect.

[Mr.Peanut]

Ouch! Never considered the multiple damage! To bad there is not a "dud" object for each projectile type that does not do damage.

Keep in mind that if you know the absolute maximum number of shells active at one time, you could create a global variable for each and a PVEH for each. On the machine that is firing the shells, you assign each shell the next available global variable name(looping back to the bottom, if needed), publicvariable it, execute say locally and then release that variable by setting it to objNull. The PVEH will then simply execute say for the object.  If you know you will not have too many simultaneous shells, this would be the way to do it.