Editor-placed triggers: locality question

[blackmamb 2]

Hi everyone.

So, until now I've never been too big on using editor-placed triggers, as creating them by script would usually answer my needs better.

Now, I'm working on a little project that does need editor placed triggers. But I really need them on one machine only (namely, either the server or the HC. Let's be clear, I'm not asking how to have the trigger fire on one machine only. I just would like to remove them completely from machines where they are useless, for performance purposes).

Another clarification: I'm working on a tool to easily spawn stuff from editor-placed triggers. Not using editor-placed triggers is not an option here, even though I understand that in most cases it would be the sensible thing to do. I know that.

I've always assumed that editor placed triggers existed locally only. Which meant that I could delete a given trigger on a client, but it would still exist on all others.

Now, I've been testing this quickly this morning, and from what I can see, it's not the case.

My test: there's a trigger, placed in the editor, called mytrig.

We're on a dedi, I'm connected as well as an HC.

The HC has a variable (f_spawn_local) set to true, while the server and myself are set to false.

I executed this globally:

if !f_spawn_local then {
deleteVehicle mytrig;
};
HCtrig = mytrig; publicVariable "HCtrig";

Now, I'm monitoring two variables: HCtrig, and mytrig.

Both became <NULL>.

So, am I right in deducing that triggers placed in the editor cannot be deleted from one machine without being deleted from every other?

Thanks.

Edited September 20, 2013 by BlackMamb
code typo / reformulated question

[David77 10]

I'm sure you are correct. You'd have to us IsServer in the condition of the trigger to get it to run only on the server. The trigger is created locally on each machine. When they trigger it seems global because the condition is usually the same for all clients. When you script a trigger, it is only created on the machine executing the command according to the wiki.

In any case, probably didn't help much :p

Edited September 20, 2013 by David77

[blackmamb 2]

Sorry, my question was somewhat unclear, so I'm not sure what you're saying here.

Using isServer wouldn't solve things. The trigger would still constantly check on each machine if they are the server, which is not what I'm asking here.

Then you say the trigger exists locally, when my test seems to show that they're actually existing as a global object. Is my test flawed?

[David77 10]

As far as i can remember they are create & executed locally. But most times giving global effects because the condition is true for all machines most of the time when using triggers.

Edited September 20, 2013 by David77

[Tajin 348]

Yes and No.

The problem with your experiment is that the "deleteVehicle" command is global, so it removes the trigger on all clients.

Heres an idea (never tried that before, so no idea if it works).

Try changing the name of the trigger using "setVehicleVarName" and delete it using the new name. Maybe that makes the delete local.

[ I'm pretty sure that won't work though ^^ ]

The only other solution I see would be to create the trigger via script, that works locally.

Using "isServer" would be a much easier solution (and I'm sure its still good for performance).

That, or you don't use triggers in the first place and only rely on scripts (which you have full control over).

Edited September 20, 2013 by Tajin

[David77 10]

^ What he said. Even local commands in activation will seem global most of the time. In most cases where one would use a trigger.

[blackmamb 2]

Thanks, Taijin. Makes sense. In a weird, twisted, Bohemia-like way.

The setVehicleVarName idea was quite cunning! Unfortunately, I can't seem to get it to work.

I guess I'll quickly update the OT to explain that I need editor-placed triggers (the whole point of the thing is to spawn units easily from editor-placed triggers. Not using editor-placed triggers would be surprising).

Maybe I'll even ask BI to get us a deleteTriggerLocal command. That'd be most useful. In some very rare occasions.

[Tajin 348]

Actually, we need a general "deleteVehicleLocal".

Oh and why exactly do your triggers have to be editor-placed?

You could for example place markes instead of triggers and have a script running in background that checks for available markers and handles the spawning.

If done right, that can be very dynamic.

Yet another option would be to place your triggers normally but at missionstart you run a script, that creates local copies of your triggers and deletes the original ones. The commands for that should all be there.

You could use a specific entry in the "text" field of the triggers to specify which ones should be deleted.

---------- Post added at 02:36 PM ---------- Previous post was at 02:17 PM ----------

Give this one a try (untested):

if (!isServer) exitWith {};

_triggerlist = allMissionObjects "EmptyDetector";

{
if (triggerText _x == "Server") then {
	_trg = createTrigger["EmptyDetector", getPos _x];

	_trg setTriggerActivation (triggerActivation _x);
	_trg setTriggerArea (triggerArea _x);
	_trg setTriggerStatements (triggerStatements _x);
	_trg setTriggerText (triggerText _x);
	_trg setTriggerTimeout (triggerTimeout _x);
	_trg setTriggerType (triggerType _x);
	_trg triggerAttachVehicle (triggerAttachedVehicle _x);
	_trg synchronizeWaypoint (synchronizedWaypoints _x);

	deleteVehicle _x;		
};
} forEach _triggerlist;

Put it in an sqf-file and call it from your init.sqf.

Like so:

nul = [] execVM "sqf-file.sqf"

That should delete & create local copies of every trigger that has "Server" in its text-field. :cool:

Let me know if it works. :j:

[blackmamb 2]

Actually, we need a general "deleteVehicleLocal".

Amen to that. Although it might lead to some confusing stuff when it comes to actual objects.

Yet another option would be to place your triggers normally but at missionstart you run a script, that creates local copies of your triggers and deletes the original ones. The commands for that should all be there.

You could use a specific entry in the "text" field of the triggers to specify which ones should be deleted.

That's what I'm currently doing, except I define the to-be-deleted triggers by syncing them to a gamelogic. It's working fine, but feels a bit overkill, if you know what I mean.

I've been tempted to explore the marker way, but triggers do have interesting uses when it comes to spawning, that markers couldn't have without quite a bit of additional code, and I'm trying to keep this thing as light as possible.

I'm not willing to elaborate to much on this project as it may not ever be released under any form (some Community scripts do all that already, and much more), but the goal here is to add to the F3 framework a simple spawning script to help in-house mission makers cater with the possible future addition of an Headless Client for our sessions.

[Tajin 348]

Good idea about the gamelogic. (I should use them more often)

Basically triggers are nothing else than conditions that run in a loop, so thats not really lighter than using a script.

[blackmamb 2]

Performance wise, I guess not really. On the other hand, in terms of amount of scripting (and also in filesize), they are.

Keep in mind that I'm trying to make something as simple to use as possible, even for not very experienced mission-makers, somewhat along the lines of what F3 does. Overwhelming them with incomprehensible code is not always the wise thing, and letting them do most of the stuff from the editor, without going into too much scripting is the goal here.

[Tajin 348]

I know. I was actually thinking along the way of having them only place place markers and let the script do the rest. It doesn't get much easier than that. ;)

I had a missiontemplate for a frontline-gamemode once that worked this way. (Frontline mode is when you have to hold several capturepoints at once in order to capture the whole frontline and move on to the next line.)

You basically only had to place some units, respawnmarkers and as many markers for the capture points as you like (with specific naming). The script did the rest.

[blackmamb 2]

Well, that has nothing to do with anything, but you mentioning Frontline just gave me a nice idea of a mission. Thanks for that as well.

I'll think some more about an implementation based on markers, but for now, seeing that you can't write code directly into a marker (and you can't use setVariable on those either), it would mean listing the markers somewhere, the for each one defining what you need to spawn in, with what behaviour, and so on. Seems like more of a hassle to me. But I may be missing something.

Thanks for taking the time to answer anyway.