Welcome, Guest Wednesday 16th April 2014, 08:15:07
   Home   Help Search Login Register  

OFPEC Forum

Author Topic: How do scripting commands behave in MP?  (Read 6437 times)
0 Members and 2 Guests are viewing this topic.
Fragorl
Coding Team
Former Staff
****
Offline Offline



« Reply #15 on: 31 Mar 2005, 11:50:15 »

Re: Init fields. I understand now; an init field is local to whichever computer the unit belongs to.

I don't think this is true. I've run assignment statements thru an init field (groupA = group this), and the variable is set on all machines.

oops, i meant to edit that out, once i changed my conclusion about camcreate. Ah well, never mind, let it sit there in all it's incorrect glory for the time being.

Re: camcreate
I'm pretty sure I've had different results with this command than you suggest, but hopefully some MP experts with WAY more experience than me to set us all straight. Smiley

Yeah, hopefully that will happen. I was just stating my findings after a quick 2-computer lan, I tried to be accurate but i could be wrong. On the othe hand, if 'drop' now runs on all machines, maybe camcreate has been changed too.

skipTime
Again, is local to each machine.  What's worse, script execution is partially clock speed dependant.  So if the skipTime script has a pause of (say) 0.1 second between cycles then my machine might take 0.10003 seconds to execute while yours takes 0.100037 seconds to do it.  This does add up over time so that two machines running the same script at supposedly the same time will find themselves out of sync in very short order.

The best solution to this problem is to again have one machine carry out the skipTime function then broadcast the resulting time (via the daytime command) to all other machines via a server loop, while all other machines just read the publicVariable each cycle and skipTime accordingly.

Now that's a smart solution...

« Last Edit: 31 Mar 2005, 11:52:51 by Fragorl » Logged
Chris330
Guest
« Reply #16 on: 31 Mar 2005, 13:03:59 »

Ok I have an interesting question Wink I have a script in my MP mission which calls for a helicopter to extract the squad once two enemy squads are either all dead or all fleeing. I have a trigger which calls the extraction script when the variables attached to the squads become true. So my question is...

Do I have to broadcast the true/false variables to the clients machines in the sensor scripts for the trigger to become active on their machines Huh?

I'd appreciate your help, and I hope I have made myself clear (I normally dont Cheesy) Wink
Logged
nominesine
Intel Depot
Administrator
*****
Offline Offline


I'm NOT back!


WWW
« Reply #17 on: 31 Mar 2005, 14:05:15 »

side
A useful command since it returns wich side each client player is in a DM game. Can be used to send different messages to different sides or to make separate briefings for east and west.

Example of a message shown to everyone who is not east:

?side player != east : hint "You must be playing on the west side, because you are not east"

The game reportedly recognizes 6 sides (and one unit can sometimes fall in to two categorys at the same time). The sides are:

East (tested, I never had any problems with it)
West (tested, I never had any problems with it)
Civilian (never tested myself)
Resistance or GUER (tested, had problems)
Enemy (never tested myself)
Friendly (never tested myself)

My experince is that the game don't always accept the syntax "resistance" and "guer" however. Sometimes resistance works, sometimes guer and sometimes neither will work (when making separate briefings for instance). East and West works perfect, though.

Taken from the on line comref:
Quote
The side of a dead unit (or any inanimate object) will always be civilian. The side of a "rouge" unit (one who killed too many friendlies) will be enemy.
However, the side of the unit's GROUP will always remain the same (east/west/res). So often it may be best to use the syntax:
side (group unit)

The comref also states that "friendly" is the side of a unit that is friendly to all other units. I've never tested it but I assume it is equal to "civilian" or "resistance" (if resistance is set to be friendly to both east and west in the editor).
Logged

OFPEC | Intel Depot
RETARDED Ooops... Retired!
Garcia
*
Offline Offline


Leeds United is the best football team...EVER!


« Reply #18 on: 31 Mar 2005, 14:06:33 »

Createvehicle

The effects of this are similar to camcreate. Two important distinctions - firstly, createvehicle offsets the object it creates to fit in with nearby objects' collision radii. Camcreate does not. Secondly vehicles created by createvehicle will be usable; vehicles created with camcreate will not be.

And 1 vehicle is created for every machine, so if 4 players are playing on a dedicated server, and the script is running for everyone, the amount will be 1+4=5 Tongue
Logged
Mud_Spike
Contributing Member
**
Offline Offline



« Reply #19 on: 31 Mar 2005, 17:11:47 »

The result of this great thread should go in OFPEC's online cmd.ref.


Logged
Chris330
Guest
« Reply #20 on: 31 Mar 2005, 17:13:28 »

Ok I have an interesting question Wink I have a script in my MP mission which calls for a helicopter to extract the squad once two enemy squads are either all dead or all fleeing. I have a trigger which calls the extraction script when the variables attached to the squads become true. So my question is...

Do I have to broadcast the true/false variables to the clients machines in the sensor scripts for the trigger to become active on their machines Huh?

I'd appreciate your help, and I hope I have made myself clear (I normally dont Cheesy) Wink

Can anyone answer my question Huh?  I'd appreciate it as I need to sort it for an MP mission I will be playing with my mate Cool
Logged
Killswitch
*
Offline Offline


Peace, cheese and ArmA


« Reply #21 on: 31 Mar 2005, 17:45:26 »

Lets' do
  • action
  • animate
  • animationPhase
shall we?  Smiley

Command:  action - makes a unit perform an action

Syntax: actor action [ actionstring, target ]

Scope/results: Use it where actor is local. Results/effects seen on all nodes

Example: dude action ["EJECT",somehelo]

Common misuse, giving issues in MP:

* players in MP and his AI loonies not getting ejected from planes. Likely reason: ejection script runs on one machine only. >Bzzzt!<

Best practice
The fix? Make sure that 1) it runs on all machines and 2) enclose the eject action call with
Code:
? local _dude: _dude action ["EJECT",_transport]
or similar locality check.


Command: animate - runs animated parts of a model

Syntax: object animate [ animation, phase ]

Scope/results: one call affects all nodes in MP

Example: myplane animate ["cargodoor", 0.5]

Common misuse, giving issues in MP:

Animated part controlled by the same script running on all machines, each one having a go at calling animate at different times. This leads to the affected vehicle doing some really funky stuff in MP. I recently witnessed a certain radar tower dish do this... while the indended effect was to have it rotate nice and slowly, the multiple animate calls from different players' machines had it jittering and not knowing if it was coming or going... ;D

Best practice
Make sure only one machine (not necessarily the server, mind you) does the animate for a certain animated part at a time. Again, this can be done by a simple locality check, should the object to be animated have a script running on many machines.

Command: animationPhase - return the current phase of an animation. Value returned is a number between 0 and 1.

Syntax:  object animationPhase animation

Scope/results: phase returned might differ between machines. See below for dedicated server gotcha!

Example:  _doorPhase = myplane animationPhase "cargodoor"

Common misuse, giving issues in MP:
OFP feature/bug: sadly, animationPhase ALWAYS returns 0 on dedicated servers

May addons have lots of nifty functionality that uses invisible animations internal to the model as state variables to coordinate these extra features. (cargo loading, towing, rappelling, CAS support feature...the list goes on). In what must be one of the top showstopper bugs/features of OFP, animationState is useless on dedicated servers. In actuality, this breaks a lot of otherwise fantastic functionality in addons out there, rendering them if not useless but at least shaky for MP useage.

Normal OFP clients, arent't affected - the state of an animation is transferred just fine from machine A to all others if/should a script on machine A issue animate on a part. All other machines except the dedicated server can then read the current state of the animation just fine.

Take the example of the jittery radar dish I exemplified above. The rotation of that dish is governed by a script that checks the state of the radar animation in order to keep it spinning. In the current version of the addon with that radar, the rotation script runs on all machines, including the dedicated server, if available. The result is that the rotation monitor script on the deddy basically doesn't do anything since it's waiting in vain for the animation state to change from 0. All player clients, however, have scripts that ever so often detects that the dish has turned one whole revolution and issues another animate call. The end result? A very jittery/shaky radar dish that doesn't really work in MP.


Side note: on camCreate

A camCreated LGB (bomb) on player A:s machine will not be seen on player B's machine. However, the resulting explosion on A's machine will most certainly kill player B should he be unfortunate enough to stand where the bomb lands.  ;D
Logged
General Barron
Former Staff
****
Offline Offline


Semper Fi!


« Reply #22 on: 31 Mar 2005, 21:57:20 »

@Chris330

You do indeed pose an interesting question. However, your question doesn't specifically relate to scripting commands, so I'd ask that you start a new thread with your question, instead of trying to get it answered in here.  Cool

Some clarification about "side"

There is a difference between the "side" data type (data type as in "string", "object", "group", "number", etc) and what gets displayed when you convert a side into a string. For the data type, case does not matter. For example:
    West == WEST == west == WeSt
However, when you convert a side into a string, it is ALWAYS converted into a very case-specific string (an example of converting a side to a string: hint format["%1", side player]). Here are the ones I know off the top of my head:

    Side       String conversion
     west            "WEST"
     east             "EAST"
 resistance       "GUER"
    civilian           "CIV" (not entirely sure)
    enemy         "ENEMY"

I suspect the reason nomineshine has had problems with using the resistance side, for example, is because he did not recognize the difference between when he was using the side as a SIDE data type, or when he was converting it to a STRING data type. For example, this will always return false, even though it may seem like it would work:
    format["%1", side unit] == resistance
Just for the record, this same sort of "string conversion" via the format command can be done with most other data types as well, such as GROUP, NUMBER, BOOL, etc, and it is the only way to pass additional information to certain commands (such as addeventhandler or createunit). But at this point I'm getting way off track...
« Last Edit: 31 Mar 2005, 23:01:37 by General Barron » Logged

HANDSIGNALS COMMAND SYSTEM-- A realistic squad-control modification for OFP
kexp.org-- The best radio station in the world, right here at home! Listen to John Richards!
Fragorl
Coding Team
Former Staff
****
Offline Offline



« Reply #23 on: 31 Mar 2005, 21:59:37 »

And 1 vehicle is created for every machine, so if 4 players are playing on a dedicated server, and the script is running for everyone, the amount will be 1+4=5 Tongue
Likewise with camcreate, I think I found. I reiterate: that was from a test on a 2-person lan, I could be wrong. When I put xyz="t80" camcreate poswherever in an init field, two t80s were created, just like createvehicle would have done in the same position (minus the obvious differences).

OK, as a multiplayer scripting neophyte, I need some clarification as to what 'local' and 'global' mean exactly. This is what I think they mean at the moment:

Global:
When a command is run on a single client, the effects occur on all computers. If the command is run on n clients (plus the server), the effect occurs n times, with each effect visible to all computers.

Local:
When a command is run on a single client, the effects of that command are seen (and felt) only on that client. When the command is run on n clients, the effect occurs once once on all computers.

So,
Global execution + Global command = Repeated execution on all computers
Global execution + Local command = Single execution on all computers
Local execution + Global command = Single execution on all computers
Local execution + Local command = Single execution on one computer

where 'global execution' is for example in an init field, or in a script run from an init field. 'Local execution' is in a script after the conditional '? local <object>'.

Question: does init.sqs run on all clients at the start of a mission, or just the server?
Logged
Killswitch
*
Offline Offline


Peace, cheese and ArmA


« Reply #24 on: 31 Mar 2005, 22:32:49 »

Fragorl, your understanding of "global" and "local" with regards to the effects of scripting commands is indeed a sound one.

I believe the confusion out there has arisen from the usage of those terms both for describing the effects of commands and the so-called scope of variables.

"Global" and "local" effect script commands
...and their effects: see Fragorls post just above. That summarises it quite well.


Variable scope ("reach")
This is where the use of the word "global" above conflicts with the normal understanding of "global variables" in the context of programming languages and OFP scripting. In OFP terms that classical terminology goes like this:

A local variable (the ones who have names beginning with an underscore, e.g _myvar) is one that can only be reached by the script that's using it (or functions called from it, but we'll leave that aside for now).

A global variable is one whose value can be reached (read and written to) by all scripts running on one computer.

What do we then call variables that are handled in such a way as to have their values synchronised on all machines using publicVariable? It has been suggested to simply call such variables, well, "public variables".

However, earlier in this thread, Roni used the terms private/public/shared public for these variables, and perhaps that is a terminology better suited to use, since it avoids confusing variable scope with script command scope. Actually, I think private/global/public would be even better.


Quote
Question: does init.sqs run on all clients at the start of a mission, or just the server?
The init.sqs of a mission will be run on all machines, both server and clients, when the mission starts.
« Last Edit: 31 Mar 2005, 22:45:58 by Killswitch » Logged
General Barron
Former Staff
****
Offline Offline


Semper Fi!


« Reply #25 on: 31 Mar 2005, 22:48:09 »

Quote
When I put xyz="t80" camcreate poswherever in an init field, two t80s were created, just like createvehicle would have done in the same position (minus the obvious differences).
Init fields are run on each individual computer, so in your case, the camcreate command was run on both computers in the LAN.

Quote
Question: does init.sqs run on all clients at the start of a mission, or just the server?

All computers.

Quote
I need some clarification as to what 'local' and 'global' mean exactly.
I wouldn't split hairs too much on this point. The definitions aren't provided by BIS, so they might differ from person to person. Basically, there are two factors to consider in terms of "locality" in MP:
  Local / Remote objects: an object is only "local" to one computer at a time. A player's 'body', squad, and vehicles under the control of them are local to that player's computer. Objects and units not under any player's control will always be local to the server. You can check to see if an object is local using the "local" command. (As a side note, if you convert an object to a string (hint format["%1", object1]), then it will have "remote" at the end if that object is not local). Some commands might behave differently if you pass them a remote object instead of a local object, which is what this thread is meant to find out.
   Local / Public effects: the effects of some commands will only happen on the computer from which that command was run (or example, the weather commands and skiptime commands). The effects of other commands will be seen by ALL computers, regardless of which computer runs the command (for example, the setdammage command). This is the other main thing I hope to find out with this thread.

Other confusing uses of locality

There are many other ways to use the terms "local" and "global", which is why I'm trying to avoid using them altogether. Using the terms in too many different situations just confuses me, which is why I used "public" instead of "global" above. But here are some other, different places where you could use the term:
    Local/Private & Global variables: I would hope everyone knows the difference between the two in SP. In MP they work exactly the same way, but note that each computer has its own variables (even global ones). The "publicvariable" command, as explained above, will force all computers to set the specified global variable to the value that was on the computer executing the command, at the time it was executed (wordy explaination, see Roni's post above for a better one).
    Scripts/commands running locally: A script (or scripting command) is run on a specific computer. The same script can be run on all computers at the same time, but really each individual computer is running it's own script. They all have the same script, but anything random in the script can cause it to run differently on each computer.
   Scripting commands run from the mission editor can be confusing. Triggers can run on one computer, but not on another, from my understanding. Basically, I would assume that, like scripts, each individual computer gets its own "copy" of the mission's triggers/waypoints/etc, and runs them individually on that machine. I may be wrong on this point though, and I sure as heck would like more clarification, since it definately deals with how scripting commands work in MP.

Anyway, my only point is that the terms global/local can get confusing, and it seems best to think in terms of computers. Basically: "what computer is executing this command?", and also "how will this affect other computers on the network?".

A good way to test mp scripting

This is assuming you have 2+ computers hooked together, near enough to each other that you can observe both without having to walk to a different room. Make a mission on desert island, and use Vektorboson's scripting console (in the ed depot) that can be called via an action added to all players. This way you can type in scripting commands on both computers without having to hop in/out of the mission editor, and those commands will only be executed on the computer it was typed in on. You can also monitor the status of variables, and see how it may be different fom computer to computer.

« Last Edit: 31 Mar 2005, 22:53:33 by General Barron » Logged

HANDSIGNALS COMMAND SYSTEM-- A realistic squad-control modification for OFP
kexp.org-- The best radio station in the world, right here at home! Listen to John Richards!
General Barron
Former Staff
****
Offline Offline


Semper Fi!


« Reply #26 on: 31 Mar 2005, 23:00:31 »

    AddAction

The action added will ONLY appear to the computer who executed the command. So if the server adds an action to an object, none of the player's or their AI will be able to see/use the action (unless the server also has a player; i.e. is not dedicated). If a client adds an action to that machine's player, then only THAT player (and AI under his command) will be able to see/use that action. So if you want all players to be able to see and use an action, you have to make sure the addaction command is run on all computers.

When a player uses the action, the attatched script will only be run on that player's computer.
« Last Edit: 31 Mar 2005, 23:01:07 by General Barron » Logged

HANDSIGNALS COMMAND SYSTEM-- A realistic squad-control modification for OFP
kexp.org-- The best radio station in the world, right here at home! Listen to John Richards!
Chris Death
Former Staff
****
Offline Offline


Finally Death's gonna get ya


WWW
« Reply #27 on: 01 Apr 2005, 09:15:46 »

While you're at AddAction, i'd like to keep one question open:

There's the case that when one player is standing close to another
player, which has an added Action, and the first player will be able
to execute the action.

Where the script will be executed?

On both player's machines?

On player A machine?

On player B machine?

Sorry, but at the mo i ain't got chance to test it  Sad

~S~ CD
Logged

Dont argue with idiots....they will bring you down to their level and beat you there with experience.

How to use Waypoint type Scripted
nominesine
Intel Depot
Administrator
*****
Offline Offline


I'm NOT back!


WWW
« Reply #28 on: 01 Apr 2005, 23:50:07 »

Quote
Triggers can run on one computer, but not on another, from my understanding. Basically, I would assume that, like scripts, each individual computer gets its own "copy" of the mission's triggers/waypoints/etc, and runs them individually on that machine. I may be wrong on this point though, and I sure as heck would like more clarification, since it definately deals with how scripting commands work in MP.

I've had this problem with "not present" triggers:

In a MP DeathMatch I made, there was two triggers checking, respectively, if WEST and RESISTANCE was "not present". Both triggers covered the entire map. When either was true, a triggerbased text informed you that mission was acomplished.

It worked perfectly in the editor and in SP mode. In MP it didn't. When a WEST-player was acting as server, the "west not present" trigger fired instantly on RESISTANCE-player's computer. When RESISTANCE-player was server it worked the other way around ("resistance not present" fired on WEST client).

Since the trigger only fired on the client, I'm quite sure that triggers are unique to every computer in the game. If I remember it correctly, I tried to create an alternative by changing the trigger condition "this" to "local server AND this". Thus preventing the client from firing the trigger. But I abandoned this idea and never tested it (and I suspect it would prevent the clients from ever seeing the text).

I still don't know the solution to the problem, but maybe this example can shed some light on the issue at hand to the Mp gurus.
Logged

OFPEC | Intel Depot
RETARDED Ooops... Retired!
Garcia
*
Offline Offline


Leeds United is the best football team...EVER!


« Reply #29 on: 02 Apr 2005, 18:47:59 »

Triggers can run on one computer, but not on another, from my understanding. Basically, I would assume that, like scripts, each individual computer gets its own "copy" of the mission's triggers/waypoints/etc, and runs them individually on that machine. I may be wrong on this point though, and I sure as heck would like more clarification, since it definately deals with how scripting commands work in MP.

Don't think computers got it's own copy of the waypoints, but if it's like that, then I would think the units would stop if there was something wrong with one of the waypoints on a computer.
And that triggers are local, that I can confirme. In the mission I'm making (which I mailed you about Tongue) I've got a trigger with east not present, activated once. When it is activated it changes the first objective to "Done" and shows a hint. And one time we tested it, this trigger was activated for everyone else than me Shocked Everyone else got a hint saying the first objective was done, and the objective changed, but nothing happened for me. Dunno what went wrong. It only happened once, but that proves that triggers are local.
Logged
Pages: 1 [2] 3 4  All   Go Up
  Send this topicPrint  
 
Jump to: