Basic MP Editing Q's

[General Barron 0]

Ok, I've never done any MP editing, but I really need to learn. I've read snYpir's intro to MP editing, so I understand the basic concept of scripts running separately on each client, variables being local only to that client unless you use the global command, and how to make scripts only run on the server. But I still have a couple Q's that the tut didn't seem to answer. My main question is:

If you use a command that affects the 'game world' (i.e. setdammage, move, setbehavior, etc), does it matter what computer that command is run from? So, what would happen if I had a unit named 'bob', and on ONE client's computer, I scripted "bob setdammage 1"? What if I did the same thing on the server, or what if I did it at the same time on all computers?

Actually, this one Q has been keeping me from getting into MP editing. I know a few commands are only local to one computer, like camcreate and drop, but other than that, I don't know about the rest of them. TIA.

[gandalf the white 0]

and another MP Q:

does Game Logic a called SERVER allway's help on MP games?

oh, and say a setdammage script works for all PC's , since everyone has thesame mission everyone detects that Bob is in the death zone...

[T J 0]

Any command which is not LOCAL in application, will broadcast its effects to all clients.

Setdamage for instance is GLOBAL in effect as far as I remember, or at least if BOB is dammaged then that fact will be broadcast.

I cant recall accurately whether the unit being dammaged has to be local to the client executing the code, but I dont think so.

Sometimes you create anomalies within the game, with one unit being in two different states on varying clients, especially when concerned with groups, this can cause a CTD.

Some simple rules to remember.

The PLAYER variable is ALWAYS local to the client.

AI are always LOCAL to the CLIENT that their LEADER is controlled by. (ie, if you are TEAM LEADER, the AI in your GROUP will be LOCAL to YOUR CLIENT.)

Time should be allowed for the slowest updating client in the game to catch up with current variables.

A VEHICLE is always LOCAL to its DRIVER.

(Therefore, vehicles can change locality during a game, and they dont switch back automatically)

Hope those help you on your way a bit.

As for Gandalf, a game logic called SERVER only helps if you want it to.

That is, there is nothing 'magical' about calling it "SERVER", any other name would suffice. SERVER is just easy to remember and use.

Basically, when a mission starts, any units placed on the map by the mission maker will be LOCAL to the machine which is HOSTING the mission. Other player units and vehicles etc get farmed out as appropriate, but all other units stay local to the HOST machine, ie, the SERVER.

Since your GAMELOGIC unit was placed by the mission editor on the map, you can run SERVER side only scripts by a simple check as to whether the unit called "SERVER" is LOCAL to the machine where the script is running.

EG:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? (LOCAL SERVER) : HINT "SERVER IS LOCAL"

If you have no need of checking if scripts are server side or otherwise, then simply placing a unit called SERVER is pointless.

Hope that is clear.

The best way to check this all out is to set up a simple dedicated server at home and try running various tests.

TJ

[General Barron 0]

Ah, thanks very much for the help so far! I never thought of units being 'local', since they are placed in the map editor. So am I safe to assume that all objects (units, variables, arrays, waypoints, markers, etc.) are 'local' to one computer or another?

How do I know if a certain command is local or global? I'm guessing trial and error, but hopefully there is a better way..?

What would happen if I used a 'game altering' command like setdammage, and the command ISN"T global? Would weird desynch/chaos ensue? Or do those commands need to be executed on the server? Or perhaps on all clients?

Ok, one more related question. I've heard that, for example, radio triggers (0-0-1, etc) are global, which I assume means that if ANYONE uses them, then the corresponding code is executed on ALL clients. Then there are user actions, which are local, which I assume means the script executed will only be run on that one client's machine. So in these "local" scripts, what happens when I use global commands? Actually, come to think of it, this question should be directly answered by the above question, so sorry for repeating myself.

Thanks for the help; I know I should set up a server and test things out, but I wanted to get some pointers first, so I don't have to figure everything out via trial and error. Once I get started with the basics, I'll be able to try things out on my own, and have a clue what I'm doing .

[T J 0]

The best thing to do is set up a system whereby all events are handled as desired on the host.

You can do this by having a series of variables which you can make global using PUBLICVARIABLE.

Therefore, even if a script is run on a remote client, you can broadcast that fact, and work it so that the event is globally broadcast.

I think I know pretty much which commands etc are global in scope or local, and there's probably a listing somewhere. If I get time later i'll go through and comment each one.

One point of note though, when making a mission, you have to allow for it to be playable on a dedicated server, where there will be NO PLAYER variable locally, and where any non player group AI will be local only to the server. This can make for a tricky scenario in certain cases.

TJ

[benu 1]

Afaik there is no complete list of local/global commands/entities, but i could be wrong. So if you have something like this or it isn't too much hassle to write one then please post it. I know a lot of people asked for something like this. I think newer version of the official comref contained some info on this, but i think even those were not complete.

[General Barron 0]

Quote[/b] ]The best thing to do is set up a system whereby all events are handled as desired on the host.

Ok, do all scripting on the host that affects the game world. Got it. So would this be the best way to do it?

Make a variable called ExecCode, or whatever. Make it an empty string.

On the server, you have a continuous loop that waits until that variable changes (from a global broadcast).

Execute that codestring on the server via call.

Set the variable back to an empty string and repeat.

That seems like the most useful way to do it, instead of having a ton of global variables each linked to a certain event or string. Is this the best way?

[T J 0]

You may wish to check out the Chain of Commands system that they devised. Although I never saw or used it, I believe it allows just such a system, although my personal feelings are that their stuff is a little cpu/network heavy at times.

I will go and try and recall which commands are global in effect now and post it up for others to comment on and amend as appropriate.

TJ

[T J 0]

this is as far as I got before getting bored senseless, and remembering that I cant remember half of them.

I'll maybe do a little more, but I rather hope others will continue it.

Quote[/b] ]

THIS LIST IS PREPARED WITH A VIEW TO IT BEING CORRECTED AS APPROPRIATE.

(In cases where I cannot remember exactly I have taken a best guess and indicated such with a ?)

In some cases the command can only be performed upon a local unit, but the effect is seen globally. EG - With ADDWEAPON

COMMAND : EFFECT:

****************************************************

ACTION - LOCAL

ADDACTION - LOCAL ?

ADDEVENTHANDLER - GLOBAL ? (Handled events may/may not be global)

ADDMAGAZINE - LOCAL

ADDMAGAZINECARGO - LOCAL

ADDMAGAZINEPOOL - (Used in SP campaigns)

ADDRATING - GLOBAL ( In effect at least) ?

ADDSCORE - GLOBAL (In theory at least, though MP scores seem to vary widely)

ADDWEAPON - LOCAL (but event broadcast)

ADDWEAPONPOOL - (used in sp campaigns)

ALIVE - GLOBAL (able to query remote objects)

ALLOWFLEEING - LOCAL - (Must be used upon local units) ?

ALLOWGETIN - GLOBAL ??

AMMO - LOCAL (not sure if you can query remote units) ?

ANIMATE - LOCAL (Animations things are generally broadcast, depending on various factors)

ANIMATIONPHASE - GLOBAL (possible to check phase of remote objects)

ASSIGNASCARGO - LOCAL

ASSIGNASCOMMANDER - LOCAL

ASSIGNASDRIVER - LOCAL

ASSIGNASGUNNER - LOCAL

BEHAVIOUR - LOCAL (able to check only local units accurately ) ??

BENCHMARK - LOCAL

TJ

[DrBobcat 0]

YAY! Lets get odd with it yo.

Addaction I have found to be probably one of the most annoying commands in all of OFP as it is so messy.

I've done quite a few of those "crime city" type of maps and the number one issue I've had is when are added actions local and when are they global.

Everyone knows that any actions that are added from scripts (not in CCPs)[which is odd] can be activated by hitting it next to that unit. That means, you can be a soldier, and then go up to another soldier that has an action added to him and then you can use it. This is double sided.

When removing the action from the person, it HAS to be global or only the person with the action will have it off his menu, but everyone else will still be able to use it off him...confusing - I know.

Things I've done before in scripts for these kinds of missions have been selecters. You know what I mean....

_arg1 = _this select 0 ; This is the unit/object the action was added to

_arg2 = _this select 1 ; This is the person hitting the action

So thus you could easily say.....

? (_arg2 != _arg1) : hint "You are not allowed to use this action from someone else!"; Exit

This would just prevent people from using actions off one another and only activating it themselves. I did this also to make HALO scripts that would only allow people to activate it from the inside of the chopper/plane or to make it so the pilots or gunner couldnt jump out (HALO I mean, they could eject )

Anyway.....yeh....adding actions can be one of the most annoying things in OFP. I find the easiest way is to add all the actions to an object that you know is always gonna be there.....instead of using triggers or whatever to add them.

Out