setVectorDir, setVectorUp and setVelocity in MP

[Mandoble]

Anyone did any test with any of these in MP? Do they work?

[Mr.Peanut]

I'll probably put my foot in my mouth here... 
My guess is that they will act properly on when executed on the local client. They will still work for non-local units, but any changes will disappear with the next synchronisation. So for all server controlled units, you need only execute these commands on the server. However, if you want to guarantee all players see the same effect, and your script is neither computationally expensive nor involves random numbers, there is nothing wrong with running it on all clients and the server.

Okay, long pause as I open my mouth wide and prepare to stick my foot in...

[Mandoble]

mmm running the script in all clients would not guarantee same effect as all these commands are quite dependant on the "speed" of the machine, I mean, you may make a unit turn 360 degrees smoothly in 10 secs in machine A and 15 secs in machine B, at some point clent A and client B will see the object pointing at different directions.

long pause as I open my mouth wide and prepare to stick my foot in too 

[Mr.Peanut]

This is true. I guess which is better will depend on the amount of network lag. Big lag would make the local solution better. I did also say for scripts that were not too computationally intensive local solution would be okay. For fast looping scripts with lots of short pauses.. not okay.

My helicopter collision avoidance script I wrote for OFP(only used setVelocity) worked fine in MP run server only because it only affected enemy ai helicopters. (aside: my recent test for ArmA revealed that ai pilots are significantly better at avoiding collisions with each other, but still collide too much.)

[Mandoble]

Definitively I'm lacking way too much MP scripting  knowledge that, or MP scripting is plainly absurd 

[WhisperOFP]

I would say, if possible, try to launch commands impacting a unit on the PC where this unit is local, be it the server or a client PC.

[ViperMaul]

Mandoble,

I've been working with your scripts in a MP environment.
Thanks to you I have all the pieces to begin more extensive MP testing with our tournament.

The testing I've down so far is with 3 vs 3 on a dedicated server. In terms of how the missile flys straight or properly tracks the helo looks fine. But then again 3v3 doesn't really give you much chance for lag.

The problem that has motivated me to quickly learn proper Client Server coding habits is the following:

For my debug code I use a combination of hints and sidechats to log a list of MissileIDs to keep track of the missiles fired.
The problem is every client sees a different missileID on the screen.  Now i set the local variable by using _unitecm getVariable myVariable. Isn't object variables Public? Meaning all clients would get the same value from this getVariable command?

The other concerns is the way I described my post here. But I got no answer. I've decided to ask Sickboy in other forums. He seems to have done extensive work in the MP coding area.  Looking at his code he seems to religiously use the Private command as well as the If (! local server) then {} commands as well as timely publicvarible commands. I just need to learn when and where its appropriate.

Any way I've added code to force it to run on the server to see what happens. And I only display values from object getVariable commands now.  And this week I will be doing more 2 v 2s and 3 v 3 testing and give you feedback.

Our intent is to use your code every Sunday in our 30 v 30 tournament where we are experiencing some desync and lag on occasion. So we are motivated to find the same answers as you are.

I would like to help you with your MP testing as well Mandoble.

[Mandoble]

Lets use this as a basic case of study:

(tractorinitpos is a gamelogic placed somewhere)

Code: [Select]

// tractor_turning.sqf
_tractor = "tractor" createVehicleLocal getPos tractorinitpos;
_ang = 0;
_speed = 20;
while {_ang < 360} do
{
  _vdir = [sin(_ang), cos(_ang), 0];
  _vel = [(_vdir select 0)*_speed, (_vdir select 1)*_speed, (_vdir select 2)*_speed];
  _tractor setVectorDir _vdir;
  _tractor setVelocity _vel;
  _ang = _ang + 1; ¦nbsp;
  Sleep (0.01);
};
deleteVehicle _tractor;

Would it be MP safe ensuring all the clients and servers see the same?

ViperMaul, I understand you are just testing the ArmA stock missiles interference, right?

[ViperMaul]

"ViperMaul, I understand you are just testing the ArmA stock missiles interference, right?"

Yes. As stated above we are about to step up our MP tests this week in preparation of a big 20 v 20 test this Sunday.

EDIT: I also found this as an interesting read. To try to identify ( client or server ) a script will run on.
http://community.bistudio.com/wiki/Locality_in_Multiplayer

[WhisperOFP]

For my debug code I use a combination of hints and sidechats to log a list of MissileIDs to keep track of the missiles fired.
The problem is every client sees a different missileID on the screen.  Now i set the local variable by using _unitecm getVariable myVariable. Isn't object variables Public? Meaning all clients would get the same value from this getVariable command?

No.
Variables stored into object space (using setVariable) are not public, nor published, and not even sent accross the network when you publicVariable the object itself.

[ViperMaul]

Whisper,

This is what I feared.
So what is the solution?

Code: [Select]

publicvariable myobject;

• Will this solve my issue listed above? So that all the variables are the same
• Will cause unnecessary lag? If yes I need to be careful about not broadcasting so much within a while do loop

Whisper, thanks so much for responding. I really didn't know how to verify this. Your answer takes me to the next step. Even though I am stuck again. That is ok. It's a learning process that I am excited about.

[JasonO]

I've always known it since OFP to publish a variable from a machine to all other machines and the server to the same variable. This needs to be local for it to work properly, else you have different versions of the variable flying about client to client with different value's and it will probably have different value's on each machine.

[WhisperOFP]

Like I said, if on server, you do a
object1 setVariable ["object1_data", 3]
publicVariable "object1"

on a client, object1 getVariable "object1_data" should be objNull, because when you publicVariable an object, the variables attached to it are NOT passed.
You could, though, try to publicVariable the data themselves. But if it is to keep track of Mandoble missiles positions, velocity, etc... in real time in a loop, I would advise against that as it could very fast overload the network.

Now, why do you need this? To be sure that Mandoble scripts give the correct trajectories in MP to the projectiles?
In which case the problem is rather simple. I've not dug deep into Mandoble's scripts, just used them a few time (superb work, btw), but I guess he's using combinations of setPos, setVelocity, etc....
If you read the "Locality in MP" Biki article, you see that every object is local to one, and only one, PC on the game (PC can be the server )
Being "local to PC P" means that decision on "what will object X do in the next frame?" is taken by P, and not any other PC in the MP game. Object can be a AI, in which case the PC where this AI is local will decide on the AI behavior (turn, run, aim here, fire, ....) then broadcast this information to all the clients and server so that all are aware of it and can render it synchronised.
Object can also be a bullet, for which trajectory must be calculated, by the PC where bullet is local, then positionnal and vector information is passed so that other PCs can render the bullet.
If a PC tries to "force the decision" for an object not local, it will not work. I guess for certain commands it can work somehow, but at the next frame, synchronization will be done again, and it will be re-synchronized with the situation on the PC where object is truely local.
As far as I've seen, each time I tried to setPos an object not local, or moveInCargo an AI not local, it never worked.

You can see the "re-sync" effect in action rather easily : make a mission with 1 player named "unit1", and 1 AI named "unit2", not grouped to player. Put 2 radio triggers, repetitive, the 1st doing "selectPlayer unit1"; the second doing "selectPlayer unit2". Save as MP mission
launch a dedicated server, then a client and connect to local dedi server. launch game. "Unit1" (player unit) is local to player's PC, of course. "Unit2" is local to the server, because it's not in player's group.
Then use radio 2 to switch to unit "unit2". By doing this, "unit2" is still "local to server", there is no transfert of locality. Try to move your character. It will move, then will quickly be switched back to its original position (re-synchronised with server's version of this unit). It's a very strange, but quite funny effect :p
I've not tested yet (but I'll do right after this post ), but my guess would be this :
when you make a AI unit join the player's group, this AI becomes local to player's PC (because it's in player's group), there is, this time, transfer of locality between server and PC. So, if, before doing the selectPlayer "unit2" in radio 2, I make unit2 join the player's group, then I launch the selectPlayer, I should not see any re-synchro effect occuring.

Anyway, I wouldn't bother too much about Mandoble's script. I would perhaps just check as much as I can that they are launched on PC where the guided missile/bomb/etc...  is local.


As for Sickboy's use of "private", I think it's unrelated to MP locality issues, it's more about being sure of variable's scope in his scripts, which is another tricky subject, that has appeared with ArmA SQF. I've had much more problems in ArmA scripts because of variable scope issues than because of MP locality issues, lately.

[WhisperOFP]

I just did the selectPlayer test, and it worked as I expected
See attached demo mission.

[Mandoble]

Well, about the missiles the current public version has a very complex script that executes other scripts for smoke, launch, detonation, sound, endurance checks and also stores in a variable of the target the missile's object, so that the target may "know" a missile is incomming to drop flares or chaff. Well, all these is secondary, primary and mandatory commands are setVectorDir, setVectorUp and setVelocity, no setpos are used there (BTW, BIKI states setpos fails in MP).

[h-]

WhisperOFP, do not double post.
If you have something to add, edit your post instead of replying to yourself, unless at least 2 (preferrably 3) days has passed since your reply..

And, there is no need to quote the entire post you're replying to.

[Mandoble]

Good news, after initial testing seems setVectorDir, setVectorUp and setVelocity work well in MP affecting anything created with createVehicle 

[ViperMaul]

Keep in mind those tests were done on a client side server.
When I left you we had not yet used a true dedicated server.
I am told that you can get different results on a dedicated server in certain areas.
To be sure we should try it on a dedicated server if you haven't already.

[Mandoble]

I'll try to setup a more advanced test for a dedicated server, including also a modified version of the ECM system which will not depend on vehicle's variables. Anyway, in the test without dedi server it was clear setVectorDir, setVectorUp and setVelocity effects applied by client A to a vehicle created by client A were correcly seen by client B and viceversa, and it is a quite good starting point 

[WhisperOFP]

if you have a good enough system (mainly, a dual core proc and 2G RAM is enough), you can launch a dedicated server and a client on the same machine. See my post above. And it's truely a dedicated server, even if the client is on the same machine Address space and all are separated

[Mandoble]

Thanks for the tip Wishper. While I'll try that ASAP, an environment with more than one client (preferably 3 or more) and a dedicated server is also needed.

[ViperMaul]

I have some time today if you want to do some more tests.
Also today I am doing a MP test with your full version as well.

[Mandoble]

Got another weird questions, as far as I remember, in OFP gamelogics were always local to the server, but what would happen with a client creating one with createVehicleLocal?

[ViperMaul]

Got a report for ya Mandoble.

Your full version perform its functions as expected. This means that we had a 3 v 2 little mock battle. And all 3 clients that was in the area saw the flares drop from the Cobra we fired at it.

In that mando_missileecm.sqf, I tried the If (local server) the { run code }; And it never ran. The flares stopped working. In fact, I don't think the server even saw that script. I think only the clients saw that script.

However, later the server crashed and I don't know why. One thing I want to do next is put code in there to make sure that the code only runs once per helo. 

I also used ammo crates too which has been known to crash the server as well. So next time i will not use ammo crates. I thought I could get away with it. Perhaps not.

[Mr.Peanut]

(tractorinitpos is a gamelogic placed somewhere)

Code: [Select]

// tractor_turning.sqf
_tractor = "tractor" createVehicleLocal getPos tractorinitpos;
...
deleteVehicle _tractor;
Would it be MP safe ensuring all the clients and servers see the same?

Dunno about game logics and createVehicleLocal, but the sleep command would cause some timings differences, as we discussed earlier in this thread. Best bet is to use createVehicle and run this script only on the server. That is 100%.

As for mando_missile. Your effects display on all clients because ArmA uses createVehicle for particles and not the drop command.¦nbsp; Most everything missile related will work fine if run server side only. Your problem will be translating the missile interface control to MP, because it needs to run on all clients and communicate the information back to the server using publicVariable. You need to write a server side monitor script, and a client side broadcast script, which is not trivial.¦nbsp; Data transmission from client to server also must include when a player activates anti-missile. For example, the player activates chaff. You publicVariable the player to ther server as a new global variable chaffer = player. The server monitor detects that chaffer is not null, activates the chaff script at that player's location,¦nbsp; resets chaffer to null, and then waits for chaffer to become non null again.

The problem is when two or more players chaff at nearly the same time. Whichever player's chaff request reaches the¦nbsp; server first will be fine. The other players will be out of luck. For this reason each player needs to be assigned a different chaffer_j variable, and there must be separate monitor scripts for each chaffer_j. The easiest way to do this is with dynamic variables.

Now I am not up to speed on MP scripting in ArmA, so there might be a better way. Obviously ECP had an extensive server/client-monitor/broadcast system. Chain of Command's CoCNS2 for OFP was designed specifically for problems such as these.

Finally, using createVehicle for particle effects might cause network lag if a huge number of particles are being used. What a huge number is, I don't know, but each particle source should probably be treated as a vehicle wrt to network traffic. In reality, I suspect they should¦nbsp; should only be a fraction of a vehicle's network traffic.

[Mandoble]

Well, it becoma safe if you run it in one machine, only one, doesnt matter if client or server as where you run it will be the owner of the tractor. But using createVehicle, not createVehicle local.

Anyway, the last pending question was related to gamelogics created with createVehicleLocal by a client, I believe these would be local to that client and never distributed along the network, right?

[Mr.Peanut]

Oops, you posted after I editted my above post! I don't know about local creation of game logics, and only BIS or a test will tell the truth. I once asked the same question about camCreateing game logics OFP and never got an answer.

[ViperMaul]

Everyone,

I bet you are all suprised that everyone saw the drop flares in my test? I very much doubt the RUS AA shooters who shot at the Cobra were running the  Helo missileecm script on their clients. That flare script had to be only running local on the Cobra pilots client side. At least I think. I forgot to look at the debug text. Any way regardless, the drop flares were visible by all 3 seperate clients on the opposite side of the Flare Vehicle.

Does this say that the ArmA version of the drop command effects are GLOBAL?
If not what does this say about the ArmA version of the  drop command compared to the OFP version?

OFP REF: http://community.bistudio.com/wiki/drop

[Mandoble]

Well, first of all, the missiles should be local to who created them, so, local to a single client or local to the server if the server fired them. setVectorDir, setVectorUp and setVelocity effects applied by the client to its missile seem to be correctly broadcasted all around. The effects of the "particle source" vehicle are not seen by anyone except who created that vehicle (being the server or the client). And finally, the graphic interface for the missiles works nicely in MP as it is local for every client and the missiles fired from it are local to the corresponding clients too.

Basically, the server seems to be nothing but another client with its own units. For example, client A with player A being the leader of a group of 11 units more, every one of these units are local to that client, and every movement of these units are correcly broadcasted to all clients and the server too. It seems the same rule applies for vehicles or units created by that client.

Now flares and chaff are quite different thing, mostly because a flare pack may be affecting more than one missile aproaching the same target, and the target must be noticed at least about one missile incomming.

The gamelogics are needed there for missile inertial guidance and terrain avidance only, but if these are not local to the client, then its position should be synced with the server and that may create some desync effects. I'll try to setup a new testbed with all logics being local and a new flare/chaff system in the following hours 

[ViperMaul]

Unfortunately my services are tasked fully this weekend.
I will be available again Monday.