Muzzleflash

To be honest I don't bother with the functions module. I find that it is cumbersome to make the definitions, and I make modules, not functions (that is several functions in one file), and it doesn't support that. For the benefits, benefits compared to what? #1 and #5 was long solved before there was anything called functions module. #2 Anti-hack protection. I suppose some people got something out of this. But for "closed" clans I refer to it as anti-hotfix protection - preventing us from fixing bugs, that the authors (including BIS) either can't, doesn't want to bother to, fix (at least in reasonable time). So for some it may have been a benefit; personally I have gotten zero benefits, only trouble. Also you can use compileFinal without making a functions library. #3 Agree this is a benefit. Particularly if you are making a library. But for private consumption it is way overkill since you already have your source, and know/can easily look up the parameters. #4 Can someone tell me what this actually includes? From the BIKI page the only related is logging and error functions which you can call anyway. #6 Potential? In what sense, and is it still only "potential". 1. But let me end the rant and answer your question. If you are going for performance. Any script/function/name-whatever you are going to run more than once, should be compiled into a variable. The performance benefit is dependent on how often you run the functions/scripts. 2. It really doesn't matter (like at all) since you call it so rarely, but I would still compile it into a variable. 3. No, you don't have to. Your final comment. First of all compile and execVM are not comparable at all. Basically X execVM "myfile.sqf" is equivalent to this: X spawn (compile preProcessFile "myfile.sqf");

Yeah, I am in the same boat. I have a fix to the vehicle respawn module, but no way to inject it. There are two ways to solve it. #1 is overwriting BIS functions is no longer allowed. #2 is get BIS to implement the (a) fix. But I can see many related posts on the feedback tracker about the respawn module, some old, some new, some with the exact same problem, but all with no communication from BIS. So I need a third way.

But you can also use: !isNil "_x" .

Mine doesn't care about when they join. If at any time all players on the server are dead, it will activate. That means that if everybody (survivors) gets connectivity issue at the same time and get disconnected, the trigger will activate - but if that happens you probably want to restart the mission anyway. If someone joins later, they will now also have to die to lose the mission. See the alternative syntax on BIKI.

Not sure what you mean here: Do you mean if someone joins later during the game they shouldn't be counted towards the living survivors? But anyways. You can do it using a game logic. But here is the condition, ready for a trigger: {!isNil {_x} and {alive _x}} count [b1, b2, b3, b4, b5, b6] == 0 The endMission part can then go into the on activation.

See edit made in previous post, near bottom. Could be because how the test is structured: try with all units out of the area. Or it could simply be how it is.

Only for an OR (||). We are using AND (&&). Think about, this is the logic tables: For OR: FALSE OR {FALSE} --> FALSE FALSE OR {TRUE} --> TRUE TRUE OR {FALSE} --> TRUE TRUE OR {TRUE} --> TRUE When one the values is true, the other does not matter anymore, we know the final result. So we can skip evaluating the right side. For AND: FALSE AND {FALSE} --> FALSE FALSE AND {TRUE} --> FALSE TRUE AND {FALSE} --> FALSE TRUE AND {TRUE} --> TRUE Again, when we know the first is false, the other does not matter anymore. So we can skip it. In our case we use AND, and we know that 'alive _x' is likely to be true, and that '_x inArea ...' is likely to be false. So by putting the inArea check first (for an AND/&&), we can skip the other evaluation more often. See: https://community.bistudio.com/wiki/a_%26%26_b and https://community.bistudio.com/wiki/a_or_b Edit: I should add: for OP, players are not likely to be in the extraction zone very often, and will likely be alive most of the time.But for your synthetic test, the assumptions about what likely true or false depend on your setup.

I don't understand, how did you test it? Is triggerName unique for each of the 50? Might be useful to also test whether ANY PLAYER PRESENT gives a list, and whether that can be used instead of manual inArea checks. But regardless, this is gross microoptimisation, for something you need only 1 of, runs only 2 times per second, with at most 6 units (at least in my case). Also what is lazy evaluation? You mean short-circuiting for && and || ? If so, you might try and swap the order in Pierre's since, the alive check will often be true, but the inArea false, so you are short circuiting the "reverse" way. (Also add the > 0 check in both, or remove it in both, otherwise you are not comparing the same behavior)

That doesn't work in SP (my interpretation of coop allows for one player). Of course you can workaround this, but then, with also the additional code, e.g. filtering for isPlayer and so on, the command might not be worth it.

Could have sworn you used to have to do this, or maybe in was in another context. Good to know you don't have to anymore. I still left it in mine since I think it conveys the intent better (but again I'm "damaged" from previous experiences).

That will trigger prematurely if you play with respawn and all are currently dead. Same with your latest. This will never work if even a single player is dead. Here is my updated version. I also ran it this time: thisTrigger call { private _alivePlayers = (allPlayers select {alive _x}) - entities "HeadlessClient_F"; private _inArea = {vehicle _x inArea _this} count _alivePlayers; _inArea > 0 && _inArea == (count _alivePlayers) }

Put this in the condition field of the trigger: thisTrigger call { private _alivePlayers = allPlayers select {alive _x}; private _inArea = _alivePlayers count {vehicle _x inArea _this}; _inArea > 0 && _inArea == (count _alivePlayers) } I would not use any synchronization if you plan to support joining-in-progress (synchronization is broken in that regard).

You are ignoring the "on" part of the name when you add it right? _myCtrl ctrlAddEventHandler ["MouseEnter", {...}] and not "OnMouseEnter"?

You get it from ctrlAddEventHandler.

Just don't think it is a very clean solution - but it is a solution. The only reason spawn works is because that code is guaranteed to run after the expression itself is done. And the only reason that is guaranteed is because the expression (not the spawn'ed part) runs in the so-called unscheduled environment where scripts run without getting interrupted (unless you sleep or run a loop too long) Ideally, a nice way would allow you to run expression when selecting a submenu, and not only for the "final" items. Yep, that is actually how I tested. Thinking back, it was probably a bit silly of me to add it in my answer.

Don't sleep or waitUntil inside unscheduled environments like this (or event handlers for example). You can use spawn: [["expression", "hint ""Car""; [] spawn {sleep 0.1; showCommandingMenu ""#USER:car_subMenu"";};"]] , that works for me (though I do consider it an ugly hack).

The reason your second example does not work is that it wants to shutdown the command menu when it is done running your expression.

Not sure what you want to do, but with this I can either active the main menu, and use it to reach the submenu, or start the submenu directly: car_subMenu = [ ["Submounting", true], ["Kewl-style-vaulting", [2], "", -2, [], "1", "1"] ]; mount_subMenu = [ ["Mount",true], ["Car", [2], "#USER:car_subMenu", -5, [["expression", "hint ""Car"";"]], "1", "1"] ]; showCommandingMenu "#USER:mount_subMenu"; showCommandingMenu "#USER:car_subMenu"; The hint also worked, but in what is shown above it first hints until final choice made. But if I add an expression the submenu choice, then that will run instead.

I believe he wants something like Simulink, but more general purpose and for scripting/programming languages, and not so much physics based. In it you can connect blocks to other blocks using various input/output "pins". And each block itself might be defined likewise as a composition of other blocks taking input/output. Ideally, it should be possible to generate code and/or keep the schematic in sync with code. But otherwise it could still be used for documenting the more complex systems. Personally, for SQF I think it is mostly only plausible to use it for high-level descriptions, rather than enough detailed level for code generation.

If you have code that is working, please post that instead, because what you posted does not work. Also there is no class name "rhs_weapon_ak103" - at least not in my copy of RHS, so try this classname instead: Holder = createvehicle [ "weaponholdersimulated",getpos player,[], 0, "can_Collide"]; Holder addweaponcargo ["rhs_weap_ak103",1];

If you fail to provide a position, any position defaults to [0,0], typically the bottom left of the map. Probably one the triggers had not yet renamed any markers to it. Instead of changing the name of markers, maybe just move one marker named "respawn_west" to the various positions.

No they will not. Better of using BIS_fnc_findSafePos that you linked to. If you need to spawn vehicles, then after finding a position then use https://community.bistudio.com/wiki/findEmptyPosition afterwards to ensure it is safe for vehicles.

That video shows either a poor connection between the client and server, and/or a server that is way too busy. If the server is too busy, unless very poor usage of scripts, scripts are not directly responsible. They may be indirectly, for example by spawning lot's of stuff. From my own anecdotal experience with hundreds of games, I believe that the largest changes in FPS occurs, when a machine, typically the server, goes to suddenly having, or not having, many AI's under its control in active combat.

I don't disagree that it will be useful to find approaches to get better FPS. I just don't believe that the scripting engine is the right place to do it, or that it in fact takes very many FPS directly. I can run a lot of scripts (even poorly written once) and experience almost no drop in FPS. But dropping 30 AI into a mission takes a much larger hit. Especially the AI might use an upgrade instead, still being mostly hardcoded to old-school FSM. But at least we can shoot a guy raising a binoculars, without him completing the raising of the binoculars first, and then the lowering, before finally performing his death animation - it only did take until Arma 3 for that.

Which addition specifically? But making scripts work together is something that needs scripter's input somehow to ensure that scripts work. I can make scripts that work together right now. But - without any changes - will break if Arma becomes able to run multiple scripts run at the same time. Can you clarify what you mean here? I read the first main post, skimmed the entire thread until and has read every response since my first post in this thread. I agree. People are still able to make the game crash with certain sequences even now. To be honest I think the only it could ever work is with a share-nothing approach (which is used in web browsers). In that approach, you gather some data, and it is copied to another thread. That thread has no access to the game world at all anymore. It has all the data sent to it, but cannot run any commands on the world, like getPos or addWeapon. When that thread/script is done computing on the data it was sent, and has computed a result, the result is copied back to the original thread. This way you avoid a community with a majority not having a advanced computer science of software engineering knowledge from screwing up. But again, I still believe all the cases were you really want to take some data, run an independent long-running computation, and then use the results - as in the approach just mentioned - are better served by an extension.