ARGHHH!!! I'm getting really tired of these XXXXXXX continuous MP problems.

[laggy]

Hi everyone,

All the continuing rage will end with a question. Please stay with me here guys.

Even though MP designing is my passion, I'm really loosing my patience when I do ArmA MP mission editing. With OFP you at least knew that if you followed the simple MP rules it would work fine.
With ArmA you spend more time figuring out the MP rules than actually making fun and inventive missions.

I have read Mandobles and Spooners MP tutorial, it's great and very informative. Through their info i have learned how to use MP scripts better and how to execute them only on the local machine.

However, as soon as you design a MP mission old OFP style, meaning you depend a lot on (editor placed) waypoints and triggers your planned commands and/or effects ALWAYS FAIL.
My experience is that ArmA is very MP unpredictable concerning (editor placed) waypoints and triggers, their function and locality is very inconcistent and unreliable. What works on a Hosted server doesn't work on a Dedicated server and vice versa. Am I completely wrong here? I can take a bad critique.

I read somewhere on the forum that the best way to script in MP is to completely leave out editor placed triggers and waypoints and just use external scripts. That way if you just figure out the locality where to run the script, your plan will allways be functional and editing predictable. Just use publicVariable's to run a script that exits if you are not local.

Question: If I want to be a steady and reliable MP mission designer, should I just rely on local scripts and basically abandon editor placed triggers and waypoints?

Sincerely pissed off... Why can't BIS change the MP solution to: ? ! local : DoesNotMatter command OR InThisParticularCaseDoNotPublicVariable command?

Laggy

[ModestNovice]

you can use that command.

Code: [Select]

?! local player : exit

or

Code: [Select]

?! local server : exit


[Spooner]

Use of local server has been obsolete for a good while now (In ArmA, if not in OFP). Just use isServer, which is functionally identical and doesn't require you to place a game-logic.

I can understand your frustration with ArmA MP. I don't think that it is unpredictable though; it is just that the rules are complicated, undocumented and just plain non-intuitive at times ;P There isn't really a need to avoid editor-placed triggers and the like, but you do need to understand how they work in MP which is often not as you'd expect.

The first thing you really need to do is work out what sort of machine you are running on and act accordingly. isServer only gets you one part of the puzzle and isNull player is only reliable at the very start of the mission, so it is best to create some globals to remember the information for later (remember to use your tags):

Code: [Select]

// This MUST be run at time == 0, i.e. at the very top of init.sqf, or it might give faulty results.
isDedicatedServer = isServer and (isNull player); // A server without a player.
isClient = not (isNull player); // Not the same as not server, since the host is client and server at once.
isHost = isServer and (not (isNull player)); // A server with a player (Or SP game, which should act the same way).
isDedicatedClient = not isServer;

For example, if you avoid running "client-side" code, like particles, on the server, then they won't show up on the host machine or if you want to test it in SP. If you avoid running "server-side" code on machines with a local player, then it won't be run on the host machine or in SP either!

[ModestNovice]

right, forgot bout that Spooner.

Thx for the advice too.