• Content count

  • Joined

  • Last visited

  • Medals

Community Reputation

40 Excellent


About Muzzleflash

  • Rank
    First Sergeant


  • Interests
    Little of everything
  1. 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.
  2. Take a look at this
  3. 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.
  4. 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");
  5. 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.
  6. But you can also use: !isNil "_x" .
  7. 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.
  8. 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.
  9. 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.
  10. 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: and 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.
  11. 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)
  12. 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.
  13. 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).
  14. 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) }
  15. 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).