Muzzleflash

Just to be clear, I rewrite the condition field when the script runs, so that line is only ever only executed once (by that trigger). I did it did way because I suspected OP has most if not all content in the mission itself, so this was less intrusive. But normally I would have compiled the function from elsewhere. I can't remember if Arma allows me to omit it, so I just added it. It essentially does nothing. I change the condition/on act/on deact when the script runs. False is there because I am not sure what would happen on the very first check otherwise. So false tells it that the condition (that the trigger changed side) has not happened yet. So about the +1. It's a bit of a trick. You have 3 sides [resistance, west, east] with index from 0 to 2, e.g. _sides select 1 is equal to west. But you also have four colors; green if resistance, blue if west, red if east, and finally grey if noone. I use find to find the index of the side that currently controls the area, so, 0 if resistance, 2 if east. But if find fails to find the side, it returns -1. So I add one to shift unknown to grey, 0 in the color array, and resistance to 1 its position in the color array. I could have done it this way instead: private _colors = ["ColorGrey", "ColorGuer", "ColorWest", "ColorEast"]; private _sides = [sideUnknown, resistance, west, east]; private _newColor = _colors select (_sides find _newSide);

Did you play alone, with some AI's? Because, then of course nothing happened. You trigger uses "ANY PLAYER", there is only you. So the values are (west countSide thisList) = 0 and (resistance countSide thisList) = 1. So the trigger never activates. And because the trigger never activates, it never deactivates either. And you killing any of them would change nothing, since the trigger is Jeder Spieler and no AI is a player

1. The reason it (de)activate constantly when you remove those lines, is becase you it also needs the ..._re_akitivierer variable to be true. But immediately when the trigger activate, you set it to false, thus the trigger deactivates. 2. I think you want an 'and' between your two countSide checks. I looked a bit at this, and have the side changing working but not the counter. Personally, I believe putting all that code in a trigger becomes too complicated. Especially since a trigger can only detect whether something is true or not, but you have 3 sides. Instead you could do something like this: Condition: 0 = [thisTrigger, "area_marker"] call compile preProcessFile "TriggerArea.sqf"; false Clear the On Act, and On Deact fields. They will set them by script. Then you make a file called TriggerArea.sqf in your mission folder root, where you put the following. params ["_trigger", "_marker"]; // We create some helper functions, but only once if (isNil "TriggerFunctions_Init") then { TriggerFunctions_Init = true; // This code will return true if the trigger changed side TriggerSideChanged = { params ["_trigger"]; private _list = list _trigger; // Assume last side still owns it private _lastSide = _trigger getVariable ["MostSide", sideUnknown]; private _mostSide = _lastSide; private _mostCount = 0; { private _sideCount = _x countSide _list; // We have a tie. if (_sideCount == _mostCount) then { _mostSide = sideUnknown; }; // Or a new winner? if (_sideCount > _mostCount) then { _mostCount = _sideCount; _mostSide = _x; }; } forEach [west, east, resistance]; _trigger setVariable ["MostSide", _mostSide]; // Return whether side changed _mostSide != _lastSide }; TriggerSideHasChanged = { params ["_trigger"]; private _newSide = _trigger getVariable ["MostSide", sideUnknown]; // Find new color for marker private _colors = ["ColorGrey", "ColorGuer", "ColorBlue", "ColorRed"]; private _sides = [resistance, west, east]; private _newColor = _colors select ((_sides find _newSide)+1); private _marker = _trigger getVariable ["Marker", ""]; _marker setMarkerColor _newColor; }; }; _trigger setVariable ["Marker", _marker]; _trigger setTriggerStatements [ "[thisTrigger] call TriggerSideChanged", "[thisTrigger] call TriggerSideHasChanged;", "" ];

Also notices '_this' in the list - you probably already fixed that. I never said anything about compile in this thread, that was dedmen. My main point was just that you had to be very careful obfuscating, particular anything non-local, like commands, or global variables and functions, strings, and especially any use of string formatting to access variables. And that a universal tool for obfuscating would have to be very conservative, to not cause problems. But if you know the code, you can of course be more aggressive in obfuscating. compileFinal is one alternative. You don't really need the compile though (unless you want it to be final): 3FX3vwXs = {(_this select 0) setVariable [(_this select 1), (_this select 2), (_this select 3);};

Very interesting tool. May I ask what you made the the GUI in, WPF? The look feels quite unique :) But to follow my example, it gives rise to the question: I notice you translate "_x" to "_grN3oo" in the image. How does that work in say: {alive _x} count allPlayers

The obfuscator cannot convert, say obfuscate the variable "MyPrettyVar" in: MyPrettyVar = 123 into "HzaT34A = ((1148-41)/9); unless it can make sure all references to MyPrettyVar are changed to HzaT34A . And that is hard to do since, someone might have written: _myNum = missionNameSpace getVariable [format ["%1%2%3", "My", "Pretty", "Var"]]; Or maybe I am misunderstanding, and obfuscation means something different for .sqf than elsewhere?

I would guess the opfuscators will have to be terrible conservative. Staying away from strings and global variables (including functions), lest you access it indirectly though a constructed string by same name. E.g.: CanNotBeObfuscated = 14; // Because missionNameSpace getVariable (format ["%1NotBeObfuscated", "Can"])

Well you can use the on-connect handler on the server. If someone connects, wait a few seconds, then check for leader change? https://community.bistudio.com/wiki/Arma_3:_Event_Handlers/addMissionEventHandler#PlayerConnected

I guess you mean in the scheduled environment :) I just let the scheduler handle the scheduling of threads, but it is fine if you want to sleep to let other scheduled scripts run. But maybe it would be prudent to add a warning that it should be run in a scheduled environment only. If you try to sleep in a unscheduled environment you will get an error and the script will be terminated.

Why do you sleep in the implementation? If I am running this in a scheduled environment I do not need it, and if I am running it in a unscheduled environment I most certainly do not want it.

You might use https://community.bistudio.com/wiki/checkVisibility or lineIntersect* commands, to check whether there are obstructions between an object and the current sun position, and thus whether that object should be in shadow, at least with respect to the sun. But other than that, no as PuFu says. But in Arma shadows are very subjective, and limited less than a couple hundred meters, often less by player graphic settings, so two players standing side by side, might not see the same shadows. Shadows are something I think Heroes & Generals do very well. Of course they pay the price by their terrain shadows not being dynamic and thus not shifting over time; but they work at any distance.

Do you delete the marker before the script runs again? If you don't then the createMarker call will fail, and any attempt to get the position of _citymarker/current_taskmarker/current_task will yield [0,0,0] .

How many times do that script run? Only once or multiple times? If it runs multiple times, does it ever fail on the very first run?

When you create a marker it is recommend to always set is shape, using setMarkerShape, and if "ICON" then also setMarkerType. Using only createMarker and no other commands to configure it, means it stays invisible. But as far as I can tell, your task destination would always be [0,0,0]. When you create the task, you specify [0,0,0] as the destination. Then you set it to "current_task", but where is that defined? Also, something to beware of, there can only be one marker with the same name at any given time. So remember to delete the old marker when you change tasks.

Assuming you somehow have a reference to the door in TheDoor, you can do this. Or if the door is an object you put it, put this in its init. TheDoor addAction ["Beam me scotty", {(_this select 1) setPosATL (_this select 3);}, getPosATL trainstation];

My guess is that the BIS_fnc_findSafePos fails in it search. In that case it would ordinary return valid position. Same if you call getMarkerPos something non-existent. So my guess is the only reason you get that size error is because your have specified your own defaultPos in a wrong format and it is attempting to use a single number as a position (rather than an array of 3 numbers). You have specified the defaultPos as: getMarkerPos current_tasks , but BIKI would suggests that you have to have an array of two default positions, so it should be [getMarkerPos current_task, getMarkerPos current_tasks].

The only thing to be careful of with splitString is that it will split on character in the delimiter. So if you split on "<>" you are fine with what @das attorney suggests, since you text will likely not contain those symbols. But if it did, you would be in trouble.

How about this (untested): CountNonOverlappingOccurrences = { params ["_array","_pattern"]; private _patternSize = count _pattern; if (_patternSize == 0) exitWith {0}; private _result = 0; // Let _i denote the start of potential match in _array for "_i" from 0 to (count _array - patternSize) do { scopeName "main"; // Let _j denote the number of characters matched so far. private _j = 0; while ((_array select (_i + _j)) isEqualTo (_pattern select j)) do { _j = _j + 1; if (_j == _patternSize) then { //Got a match. Move next search to after current match _i = _i + _j; _result = _result + 1; breakTo "main"; }; }; }; _result }; private _lineBreaks = [toArray _string, toArray "<br/>"] call CountNonOverlappingOccurrences;

Yeah, analogues have their limitations. At first glance, it does seem bizarre, but it actually makes sense, since the setHitIndex/setHitPointDamage are recent commands, not having setDamage affect them too will break backwards compatibility meaning all scripts made before those commands would still damage vehicles, but it would no longer look right. It wouldn't work with damage being "transferred" the other way either, because you could damage the lights without any structural damage being done. Even then, I didn't consider the order like you did, so good catch :)

That is not going to change. In fact, one of the things they removed in Arma 3, can't remember exactly when (it was a few years ago), but it was no later than with the release of the 3den editor, was the ability to see object IDs in the editor. They removed them, at least visually in the editor, because people used it, exactly in the manner you do now, and they couldn't (or wouldn') guarantee those IDs never changed. So you will have to use other techniques, like the capturing a reference to the object based on te location of the object (at mission start if it might move).

Hitpoints only cover special parts of the vehicle, sort of like setObjectTexture. The non-hitpoint parts of the vehicle can still be damaged. For example, you might have removed damage to lights, wheels, glass, but that doesn't mean that there isn't still damage in between. The human analogue, would be that I shot you, and some medic only fixed your organs (aka. the hitpoints), there might still damaged tissue between the organs. So you still have to manage the main damage/setDamage commands. You might take a look at how ACE solves this, they refer to the non-hitpoint damage as structural damage: https://github.com/acemod/ACE3/blob/master/addons/repair/functions/fnc_setHitPointDamage.sqf#L36-L67 (line 59 seems most relevant for you)

Still works fine. Just tried it: synchronizedObjects logic ==> [] Run logic synchronizeObjectsAdd [dude]; Then synchronizedObjects logic ==> [dude]

Also something to keep in mind about synchronization using synchronization lines: in multiplayer, only the server get synchronized to stuff. Furthermore, it only get sync'ed to stuff present at the beginning. For example: modules synchronized to objects that is not present in the beginning, for example players who join-in-progress, will not be sync'ed, even after they join, and including on the server. But if the object were properly synchronized, they keep being it after respawn - at least for players. If you need to sync on stuff not available in the beginning of the mission, you will need to reevaluate and somehow discover and manually add the synchronization like Larrow mentions.

Take a look at this https://foxhound.international/arma-3-eden-scripting.html

I think you need to add it to self-action since you are inside the vehicle I believe you can't interact with it. If so, you might need to change the condition. Nvm, I though you were inside also.