Home   Help Search Login Register  

Author Topic: Some tips for addon scripter & mission designer  (Read 9110 times)

0 Members and 1 Guest are viewing this topic.

Offline rom

  • Members
  • *
  • . . .
Re:Some tips for addon scripter & mission designer
« Reply #15 on: 18 Apr 2003, 13:36:57 »
Init EHs are local-only?

From the tests I did it seems like the script called by the init EH of a vehicle is run on the server no matter if the unit is in the group of a player (or player is pilot/driver) or not. (1.91 dedicated Win server, 1.90 clients)

For the cargo system I'm doing I have a similar situation with dialogs like you Dinger.
I'm using a string lookup table on the server and the clients for strings needed in dialogs to display the registered addons.
To setup the lookup table on the server and the clients I'm using a combination of init and fuel EH to register the addons. The init EH script is run on the server and sets the fuel to 0 and back again. This triggers the fuel EH on all the clients and starts the client side scripts.
This way I only need the #include line in the desfription.ext for the dialog but no init.sqs to start the server and client scripts.

The only problem is that if a vehicle is local on a client (in player group) the setfuel command called on the server doesn't work, so I have to createVehicle a special dummy vehicle that uses this init and fuel EH combination to get scripts running on the server and the clients for registering the addon.

Offline uiox

  • Contributing Member
  • **
Re:Some tips for addon scripter & mission designer
« Reply #16 on: 18 Apr 2003, 15:13:07 »
What is EH?  ???

Offline rom

  • Members
  • *
  • . . .
Re:Some tips for addon scripter & mission designer
« Reply #17 on: 18 Apr 2003, 15:25:50 »
EH = eventhandler

In this case the fuel and init eventhandler line in the config.cpp of an addon:

Code: [Select]
class eventhandlers
{
init  = "[_this select 0, 24] exec ""\cargo\scripts\unitinit.sqs""";
Fuel  = "[_this select 0, 24] exec ""\cargo\scripts\FuelEvent.sqs""";
};

Offline uiox

  • Contributing Member
  • **
Re:Some tips for addon scripter & mission designer
« Reply #18 on: 18 Apr 2003, 16:46:21 »
Thx

The init eventhandler is both, local and server, for an addon you have an init for the server object and an init for the remote object.


No it's not right the init of addon is only server side I'm completly sure now.
« Last Edit: 17 May 2003, 15:11:33 by uiox »

Offline rom

  • Members
  • *
  • . . .
Re:Some tips for addon scripter & mission designer
« Reply #19 on: 18 Apr 2003, 17:31:59 »
Are you sure about the init eventhandler also running on the clients?

In my example above: When I put a hint command in both the unitinit.sqs and the FuelEvent.sqs, then the hint of the unitinit.sqs is never shown on a client (no matter if the unit is local or not) but the FuelEvent hint is shown on every client.

Offline uiox

  • Contributing Member
  • **
Re:Some tips for addon scripter & mission designer
« Reply #20 on: 18 Apr 2003, 18:38:28 »
It's for addon, the event init of a addon is start on the server and on each client.

And for script I have to test, for learn how apply what I have learned with addon scripting.
Note : I don't have a trigger server and I start a server loop and I can call it.

So I say to myself maybe it's possible in mission MP scripting.

****Edit

Only server side
« Last Edit: 17 May 2003, 15:12:35 by uiox »

Offline Dinger

  • Contributing Member
  • **
  • where's the ultra-theoretical mega-scripting forum
Re:Some tips for addon scripter & mission designer
« Reply #21 on: 18 Apr 2003, 19:53:19 »
Init EHs fire only on the machine local to the unit.  This can be a server or a client.
CoC_Mines relies on the "local-only" init.  That case with manned vehicles is interesting.

The fuel is a good trick rom, but you don't have to do it for each unit.  All you need is one dummy object to start a master control script.  CreateUnit and setfuel is good and automatic; I might "borrow" that idea.
What we're doing is a little more ostentatious: we're making a big fat obelisk (that emits a slight humming sound) that the mission designer has to put on the map for things to work.  It's init EH will indicate the server and launch server-side stuff.  It will also "fire" something (maybe a starter pistol sound, maybe just a green mist), and that will trigger the fired EH on all clients, loading the client-side stuff.
Client-side init script registers each asset, and indexes "TypeOf" against a list of known addons.  If it's not in the list, it loads the interface library (and any client-side scripts the asset requires)

Anyway, I hope to have a beta to show you soon (jostapo's been busy with work lately).
Dinger/Cfit

Rubble_Maker

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #22 on: 21 Apr 2003, 19:36:07 »
Alright, small reference so far.

Right now I'm missing information on wether the following commands are local or global:

VehicleRadio
cutRsc
animate


REFERENCE
========


GLOBAL
=======
scripts:

init.sqs
OnPlayerKilled.sys


commands:

setdir
setVelocity
setpos
RemoveWeapon
RemoveMagazine
SetFuel
DeleteVehicle

event handlers:

Fired, IncomingMissile, Damaged, Getin, Getout, Engine


LOCAL
======

commands:

drop
showCompass/Map/Radio&GPS...
say
inflame

event handlers:

Killed
Hit
init   (only where unit is local)



@Dinger: The addactions are local when added by script, but the actions defined in the addon's config.cpp are global I think (I mean the scripts triggered by them are run on all machines, no?)


Offline uiox

  • Contributing Member
  • **
Re:Some tips for addon scripter & mission designer
« Reply #23 on: 22 Apr 2003, 09:24:42 »
Useractions are local everywhere (addon and script added). In addon useractions one advantage you can modify radius detection, but in the script called you don't have the array pass by script action.

Some précisions

Event start on all clients are not really global. A script called by an event only start on all clients, exemple an animation (always local), If you do some commands broadcast by server you will have problem of repetition of the command (one by server one local),so you need trapped the server for avoid this.

A command is not really global when it needs the server side.
We can make a new classification

Global command : start everywhere, do everywhere (server + client)
Server side command : start on server broadcast on all clients
Local: start local

Tactician

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #24 on: 22 Apr 2003, 09:47:41 »
Some things:

- onPlayerKilled.sqs is triggered locally (only by the player).  It exists globally as part of the mission for all to see but is only called into action when the player dies.

- I would use the term "public" rather than "global".  Public events are events transmitted to all other clients, whereas the global scope can still be local to one client.  For instance, any variable can vary between clients until publicVariable is called to sync them.

- Actions added by script are not public.  If you use 'player' in a condition for a trigger adding an action (i.e. player distance object < 10) then only a player meeting those conditions will see the action.  I assume config.cpp actions are viewable by all players.

- No such thing as a server-side command; commands are either public or local, and a public event can be called from any client.  "Server-side" is only a method of implementing public commands, consolidating them to one reliable client (or dedicated server).  Yes, even createVehicle avoids duplication when only run by one player.  The server is just a logical traditional place to call it from, and there are reasons to call it from other clients.  The duplication property of createVehicle is a property of OFP vehicles, not OFP scripting.

- A neat way to use init eventHandlers.  If the eventHandler calls a script with _this as a parameter, the unit is the first parameter.  If you check ?(player != _this select 0): exit, any commands run afterwards will be local to the player if he is that type of unit, and AI troops will be excluded in the host's case.
« Last Edit: 22 Apr 2003, 09:49:07 by Tactician »

Rubble_Maker

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #25 on: 23 Apr 2003, 00:07:48 »
Well ok, so useractions are local no matter if installed by config.cpp or a script, but how to replicate local commands on all clients?

One idea that might help is to have a special script (I call it "replicator script") running for each useraction, which must be executed by the init.sqs so it runs on all machines. This script only waits until another script signals a useraction, and then it runs the local commands on all machines.

I thoght this through carefully and the problem is that scripting will turn into a mess this way. The replicator script would have to check on which machine it is running, and leave out the unit which called the useraction, or else the script commands will be dublicated.

I ended up thinking that the best way to take care of all this stuff is the way they did it in Quake: generic server-client buffers. That way *all* local commands will be run through a buffer that distributes the command that should be run to all clients. On each client, there is a script that waits for a new command in the buffer, and then dispatches that command. This buffer will be used even in SP to guarantee some continuity and to avoid the mess I that the "replicator" method would introduce. Running all local commands through such a buffer could actually make it possible to write scripts that work exactly the same in SP and MP, so no need for extra code anymore :)

What I'd like to know is if the overhead introduced by using such a buffer would be noticable. The buffer would have to be constructed with metavariables only,since arrays don't work with the "publicVariable" command.


Tactician

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #26 on: 23 Apr 2003, 13:27:08 »
I think the usage of an action is public if all clients see the action.  So, if you add an action to an object through its init field where all clients will see it, the script run by that action will be run by all clients.  To make a local action do something public, it's just a few publicVars:

init.sqs snippet:
Code: [Select]
publicObj = objNull
publicUnit = objNull
[] exec "checkaction.sqs"

Trigger activated repeatedly
Condition: alive player AND player distance (nearestObject [player,"SoldierE"]) < 10
Activation: reportAction = player addAction ["Report contact","reportaction.sqs"]
Deactivation: player removeAction reportAction

reportaction.sqs:
Code: [Select]
_obj = _this select 0
_unit = _this select 1
_index = _this select 2

;; broadcast the player and the enemy soldier he reported
publicUnit = _unit; publicVariable "publicUnit"
publicObj = _obj; publicVariable "publicObj"

;; remove action from player
_unit removeAction _index

checkaction.sqs:
Code: [Select]
#start
;; wait til object is broadcast by a player
@!isNull publicObj
;; store variable values
_obj = publicObj
_unit = publicUnit
;; reset the variables to null
publicObj = objNull
publicUnit = objNull
;; sideChat seen by _unit's side
_unit sideChat format["I found an enemy soldier!  His name is %1",name _obj]
goto "start"

Offline Dinger

  • Contributing Member
  • **
  • where's the ultra-theoretical mega-scripting forum
Re:Some tips for addon scripter & mission designer
« Reply #27 on: 23 Apr 2003, 15:46:09 »
RubbleMaker: bn880 is working on just such a suite of MP scripts, or at least he was before the CoC forums crashed; they were pretty far along too.
Dinger/Cfit

Rubble_Maker

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #28 on: 23 Apr 2003, 23:40:37 »
Dinger: any chance I could get in contact with bn880? never saw him around here.

Well I just did a lil test with user-actions (defined in config.cpp), and it seems like NONE of these actions is available to anybody but the server. I was client and they were available, but nothing happened when I activated them.

So the question is: how can I make these actions become available to everybody? Do I have to add them on every client?

« Last Edit: 23 Apr 2003, 23:41:45 by Rubble_Maker »

Rubble_Maker

  • Guest
Re:Some tips for addon scripter & mission designer
« Reply #29 on: 24 Apr 2003, 00:03:58 »
One more q: when I have like 3 vehicles on a map, and all players start outside these vehicles, will the vehicles then be local to the server only? Coz that could be the reason why I couldn't use the actions: because I was client and the vehicles were all local to the server. However, then the script associated with these actions still should have executed on the server (although it was called from a client), which however it *did not*. The funny thing is that the useraction didn't do anything, neither on the server nor on the client.

any ideas?