Home   Help Search Login Register  

Author Topic: server / local woes  (Read 1828 times)

0 Members and 1 Guest are viewing this topic.

Offline trooper.ryan

  • Members
  • *
server / local woes
« on: 29 Feb 2008, 07:34:33 »
I'm really not getting it when it comes to server versus local execution with multiplayer.

I have a trigger that I only want to be triggered once, so I use cond: this AND local server.  When it gets triggered and executes a script, things like sidechat and titletext dont get displayed to players, probably because the trig is being executed on the server. 

titleText is noted as local in the biWiki, so I'm assuming that sideChat is also.

Any suggestions how I can cause these effects on local players from a server executed script?

Thanks
trooper

Offline Mandoble

  • Former Staff
  • ****
    • Grunt ONE and MandoMissile suite
Re: server / local woes
« Reply #1 on: 29 Feb 2008, 10:09:47 »
A quite basic way to do this, add the following to the init.sqf file of your mission:
Code: [Select]
my_title = "";

[]spawn
{
   while {true} do
   {
      waitUntil {my_title != ""};
      my_title  = "";
      titleText[my_title, "PLAIN"];
   };
};

Anywhere else, when you need from some place to broadcast a text to be displayed, just do the following:
Code: [Select]
my_title = "HELLO WORLD";
publicVariable "my_title";

Offline Spooner

  • Members
  • *
  • Mostly useless
    • Community Base Addons
Re: server / local woes
« Reply #2 on: 29 Feb 2008, 12:29:28 »
Mandoble, your code order is slightly out (I know you know what you were trying to do) and will always show an empty title. Just need to set the titleText before resetting the value of my_title:
Code: [Select]
   while {true} do
   {
      waitUntil {my_title != ""};
      titleText[my_title, "PLAIN"];
      my_title  = "";
   };

Also, trooper.ryan, the use of "local server" is deprecated. You should just use the isServer command and then you don't need to mess about with creating a server logic.
« Last Edit: 29 Feb 2008, 12:31:01 by Spooner »
[Arma 2] CBA: Community Base Addons
[Arma 1] SPON Core (including links to my other scripts)

Offline Mandoble

  • Former Staff
  • ****
    • Grunt ONE and MandoMissile suite
Re: server / local woes
« Reply #3 on: 29 Feb 2008, 12:39:03 »
haha true, I wrote to quick  ;)

Offline trooper.ryan

  • Members
  • *
Re: server / local woes
« Reply #4 on: 29 Feb 2008, 14:42:03 »
Thank you both very much for the prompt reply!   

I'd spent the most part of 8 hours racking my brain on this, I should've posted sooner!   :weeping:

Offline Nixer6

  • Members
  • *
Re: server / local woes
« Reply #5 on: 29 Feb 2008, 16:31:32 »
It's a pretty complex concept to come to grips with Trooper, at least for an old fart like me. 

SickBoy has page on the Biki http://community.bistudio.com/wiki/6thSense.eu:EG that has some good info. ATM, I pretty much try to do all my communicating with messages and such in waypoints and triggers. They exist on the server and AND clients. But, it seems there are always exceptions such as radio triggers, which only fire on the client machine of the guy who activated the radio.
Why do I have to be a Rocket Scientist to make a good mission?

Offline Tajin

  • Members
  • *
Re: server / local woes
« Reply #6 on: 29 Feb 2008, 16:38:53 »
;) hehe, thats what we're here for right ?

anyway... you can also put the code above into a trigger.
Basically does the same job.

Condition: my_title != ""
Activation: titleText[my_title, "PLAIN"];my_title  = "";


Another alternative would be using setvehicleinit. (those initlines are always executed on all clients)

Or having sort of a core-script running in background pretty much like the code mandoble posted above, just a little more complex. That allows you to execute code local/global/or wherever you want without much hassle.


- edit -

good link Nixer6
post it more often ^^ I'm sure it'll help alot of people.
Locality is tricky but quite important.
Not only for those communication things but also for optimization.

We all know those (sorry) ugly chopper-transportscripts or paradrop-scripts that look very choppy on clients. Well, making good use of locality allows to avoid that for example.
« Last Edit: 29 Feb 2008, 16:45:11 by Tajin »

Offline Nixer6

  • Members
  • *
Re: server / local woes
« Reply #7 on: 29 Feb 2008, 16:50:05 »
Very true. One of the newer mission makers I work with grabbed a pardrop .sqs from here and used it in his mission. Of course it was made for SP.  :whistle:

It looked like a whole airborne division was dropping out of one blackhawk!  :D  Parachutes were created by all 20 clients at once.

I too am a complete noob when it comes to MP scripting. Thanks to all the great folks here I am learning.  :good:
Why do I have to be a Rocket Scientist to make a good mission?

Offline bheggsum

  • Members
  • *
Re: server / local woes
« Reply #8 on: 06 Mar 2008, 11:33:33 »
On the thought of making a general mechanism for executing commands locally, you could use:

Code: [Select]
//init.sqf
globalCommand = "";
publicvariable "globalCommand";

[] spawn {
     while (true) do {
           waituntil { globalCommand != "" };
           call compile globalCommand;
           globalCommand = "";
     };
};

If you feel structured, maybe a separate function for executing the command:

Code: [Select]
// globalCommand.sqf

globalCommand = _this select 0; // command to be executed on all computers in MP scenario

publicVariable "globalCommand"; // publishing to all clients, listening to this variable from init.sqf script

Then it is easy to make any local command execute on other computers in multiplayer scenarios. Examples are setDate which is a local command, and needs to be executed on all computers if they shall have the same time (it is rediculous to have a night time look on the server, and bright daylight on clients....). In order to set time equal you can then:

Code: [Select]
["setDate[2008, 4, 1, 23, 00]"] exec "globalCommand.sqf";
« Last Edit: 06 Mar 2008, 11:36:02 by bheggsum »