Mutiplayer map guru needed

[Sexacutioner 0]

Ok, I'm working on some stuff for a multiplayer map that is starting to make me crosseyed.

Now, I've just made a small map with a few things to test out like:

an open/close door feature

a radio that can be turned on/off

an ai guy that you can have join your side, or leave

various other things

All works fine untill you jump in multyplay.  Then I realize that everyone is running their own instance of the scripts.

So if I put this in the initulization field of something...

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">this addaction ["open door","opendoor.sqs"]<span id='postcolor'>

and the script opendoor.sqs runs a little thing to move a wall and set a global variable to tell the door is open then whoever ran the script (opened the door) is fine and the door is considered open on their machine, but on everyone elses machine the door looks open but is considered closed.

Here's a simpler one:  If someone turns on a radio, on their machine it is on and on everone's else it is off until THEY turn it on.

So basically everyone gets their own version of the game, and it gets really screwed up.

Here is the mission I was messing around with if you wanna see what I mean:

My Multiplayer Test

Might need an addon or too, sorry but didn't have time to look through my TON of addon's to see.

Anyway, I think I have heard somewhere about server/client side scripting or something that would help my problem.  I have been searching this forum with no results.  If there is someone that knows a good way to link these scripts together, please help me.  I can do nothing without this knowledge.

Laters.

[bn880 5]

Well I will see if I have any time to look at it tomorrow.

Hmmm, I know how to sync the radio, the Ai joining should be fine in MP, the door's are beyond me until I look at what you did.

I can even sync the campfires, but doors?

Oh it moves a wall... yea I can sync that too.

Anyway I will try and look tomorrow, I will fix your radio problem and from that I will let you figure out what I did and you can fix the rest. Do you have any background in Semaphores or thread sync? It helps to get started.

[Sexacutioner 0]

Thanks your help will be appreciated. I am a fairly decent java programmer, but haven't had the need for using threading yet.

[bn880 5]

Well this was simpler than I expected since you have set results that you expect and can wait for on all machines, ex: radio on or off

Here is the mission file I updated

http://members.rogers.com/ct-hru/Doom Canyon 2.0.zip

note the following:

1. I did not have your addons on my machines so I substituted basic objects for them

2. Next time you need someone to look at your mission, eliminate the need for addons or give them links to all required addons. It's a hassle but it's fair.

3. I have synchronized the radio, it uses true and false (boolean) instead of 1 and 0... using that you should be able to figure out how to synchronize the rest of your troubles. As long as you know which values you are waiting for ie: 0 1 2 3 , you can use that simple method (only build on it as needed)

4. I have put the first run stuff in a file called init.sqs, a file with this name is executed when you start your mission by default.

5. I have provided an example.sqs file which shows you how to run stuff on; all machines, server only, all clients, west clients, east clients)

6. For the ?(local Server) conditions to work I created a game logic in the middle of your yard called 'server'.

7. I have to go eat breakfast.

PS: look also in radioMonitor.sqs

[suchey 0]

this is something which happens alot when using the addaction command...bn880 has probably fixed your problem, but Ill go through a method in case others may be reading this.

When using the addaction, the script will tend to run sporadically on client machines...heres one method of running a server side only script from an addaction:

create a trigger with condition of 'anyone here' and a small radius of 2 or 3 on your map which switches a variable from 0 to 1 'or' false to true. Place the trigger away from the playing area of your map in an area which a player will not be going.

In the script which runs from the addaction...include a setpos command which moves the above trigger to the position of the player (you can accomplish this by using the getpos command). SO...when the player triggers the script from their action menu, they move the trigger aver themselves effectively changing a variable from 0 to 1 on a global level.

Now, make a 2nd trigger with radius of zero and condition of '?variable==1. Trigger fires a 2nd script when activated. This 2nd script will be a server side only script by using this line '?!(local server)' and the server gamelogic described by bn880 above.

Running the script on the server side and using the 'publicvariable' (use of the public variable will be attached to different variables depending on what you are trying to do, but in a nutshell, it transmits a variable to all clients connected) This will ensure that the same info gets to all clients. There are instances where you would want to use a 3rd script which runs from the client side (withou the ?!(local server) item) in order to move objects etc.Since this 3rd script would be triggers by a variable from the server side, all clients would run it.

Heres some final info that doesnt have much to do with the above, but may prove to be useful in your situation...we know that a variable can be passed via an 'exec' command and referenced by _this within the script itself...however, you cant pass a variable to the script from within an addaction. BUT...'_this' does exist in the addaction as an array of the following format:

[unitName which had action attached, Unit Name which triggered action, Action Number]

so...to reference the unit which triggered the script from his action menu you could do this:

_dude=_this select 1

in this snippet the _dude would be whoever triggered the action from their menu. In your case, this may help in adding an animation or something only to the player which is currently performing the action.

Hope this stuff makes sense...and hope it helps!

[Sexacutioner 0]

bn880 YOU RULE!

Sorry bout' the addons, I already uploaded the level to my server before I thought about that.  I'll take a look at this tonight, and soon me and my friends will be having the best multiplayer fun ever!

[bn880 5]

Well hopefully you can get it all resolved after my and Suchey's input. (Remember I fixed the radio and gave you an example, I didn't do everything for you)

Just remember to take your time if you are stuck, don't give up thinking of a solution too fast.

EDIT:

Suchey, that is very useful info you posted although I figured that out just a few days ago. I notice that there are dozens of things which are basically easy to use in the OFP system but, they are not at all documented by BIS. The variables passed by an action command are a prime example. The other one is the server logic. Things like that can drive people insane.

[Sexacutioner 0]

Thanks dude, by the way your link wasn't IE formatted (%20 for spaces), but I managed. I got the download now, so you can remove it from your server when you want to.

[bn880 5]

Oh yea, sorry about that, didn't notice IconBoard has probs with that.

Mind if I leave the link up? Just in case someone is looking for MP answers.

If you mind I will remove it ASAP.

[Sexacutioner 0]

Nah, don't care, long as you have the server space.

[KaRRiLLioN 0]

Well another method is to use scripts that run on everyone's computers from the start that wait for a Global Variable to be made public as well. For example:

@RadioON

this script can be started from init.sqs and then it waits until that variable is true. When a player does his addaction, then it simply does this:

RadioOn=true

PublicVariable "RadioOn"

Then the script that is running on everyones machines sees the var is true and then starts to run whatever is in the script. This is probably easier than using a move trigger method since you don't have to place a lot of triggers in the map. When the player wants the radio off, then they click the action and it sends a RadioOff Global Var and makes it public.

[bn880 5]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (KaRRiLLioN @ Aug. 04 2002,13:50)</td></tr><tr><td id="QUOTE">Then the script that is running on everyones machines sees the var is true and then starts to run whatever is in the script. This is probably easier than using a move trigger method since you don't have to place a lot of triggers in the map. When the player wants the radio off, then they click the action and it sends a RadioOff Global Var and makes it public.<span id='postcolor'>

Nobody is using a move trigger... using PublicVariable and waiting on it is what's called synchronization, and that's what I gave him an example of.

[suchey 0]

I think Karillion was talking about the method which I mentioned...it seems either method works about the same as a triggered script will also run on all clients just as one initiated from the init. Either method should work...so there are a couple of options for achieveing a similar result for anyone trying to do this in their missions. GOOD THREAD !

[bn880 5]

Yes good thread , but unfortunately this is the same method, that's why I replied, I don't want to people to get confused.

The only way I know to begin a synchronization process in OFP during a mission, is to use PublicVariable, or to use an Object (which is always public).

The only thing missing from simply waiting on a PublicVariable is that you are not sure the event has already taken place on all machines, when you may need to use it again, to fix that you need more advanced logic than true and false. That's what I did for a multiplayer artillery which fires several rounds one right after another, and they must occur in a linear fashion on all machines.

If you know what PublicVariable does, you can probably figure out how to sync anything in OFP.

[KaRRiLLioN 0]

I didn't download the mission to see what your solution was, I was simply replying to Suchey.

I try to leave triggers out as much as possible and resort to only scripts primarily because this makes it much easier to plug-n-play templates so players can create missions more easily by simply copying over scripts. Unfortunately in some case you just about have to use triggers.

The great thing about using GlobalVars (GV) in that sense is that you can then pass a GV to a script and then in the script use it as a Local Var (LV) -- this is the one with the _ in front of them (for those who don't know) and then you can pass off artie shells, or whatever you want in order. Also, if you have a player use an AddAction command which initiates a GV to true and then declares it Public to all players, then you can have each player change that GV back to false without declaring it public so that each player will see (hopefully) the same thing that the others did, even with lag.

Now there are some instances where GV's that are declared Public do not for some reason get recognized by some clients. Unfortunately lag is the main factor here.

I suppose what I'm getting to is that is you have a LOT of flexibility using PV's, GV's and LV's without resorting to triggers.

While scripting RTS and RTS2 I learned quite a bit about AddAction and how you have to get around certain limitations, but it seems there are always 20 other methods for doing the same thing once you think about it. The main thing is figuring out the most optimized way to do it.

Umm, anyway, didn't mean to get off on a tangent. =)