setVectorDir, setVectorUp and setVelocity 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.