No announcement yet.

HOW TO code for limited respawns by individual

  • Filter
  • Time
  • Show
Clear All
new posts

  • [GUIDE] HOW TO code for limited respawns by individual

    Whether you plan on using this approach in TG missions or not, it's here for edification for the new coder, or if the winds change.

    While shared tickets sound good in theory, my experience has been that players with videogame habits need two or three sessions with their own separate respawn counter to break those habits and starting thinking like it's a milsim. Rather than subjecting everyone to such players' bad habits (which they may actually never change, if they even want to), a limited respawns approach like this both teaches non-ramboing and protects everyone else. WIN-WIN!

    As with other scripted solutions, you can also enable or disable it via mission parameter, so it's modular and can be used or not based on whether you're playing a mission on an open server or a closed session among friends, or whatever.

    You can also enable or disable a separate *persistence check* (i.e. protecting against re-logging) with a separate mission parameter.

    You can also make the *number* of limited respawns a parameter. (I've been using 0, 2, and [5] as my options, so this also supports single-death mode for extreme sessions / expert players.)

    The mission is otherwise configured to use BIS revive and BIS respawn in the editor's Attributes > Multiplayer section.

    In your client init script run this kind of code (here my mission's 2nd parameter is # of respawns and the entire limited respawns architecture is a given, but you can also wrap the whole thing with another paramsarray check if you like):

    //Stick's limited respawns implementation
    myRespawns = 0; //client-side global var, used elsewhere
    nul = [(paramsArray select 1)] spawn {
      _maxrespawns = (_this select 0);
      hint format["Remaining Respawns: %1", (_maxrespawns - myRespawns)];
      while {true} do {
        waituntil {not (alive player)};
        _deathlist = missionnamespace getvariable "sticklimitedrespawnsdeathlist";
        if (myRespawns >= _maxrespawns) then {
          _deathlist pushback (name player);
          missionnamespace setvariable ["sticklimitedrespawnsdeathlist", _deathlist, true];
          if (isserver) then {
            titleText ["You died too many times...", "BLACK OUT", 2];
            _cam = "seagull" camCreate (player modelToWorld [0,0,100]);
            _cam cameraEffect ["FIXED", "LEFT TOP"];
            _cam camCommand "MANUAL ON";
            sleep 2;
            while {true} do {player setposasl [-3000,3000,3000]; sleep 0.5;}; //player switchCamera "internal";
          } else {
            endMission "END4"; //totally local!  don't make it a remoteexec!
        } else {
          waitUntil {alive player};
          myRespawns = myRespawns + 1;
        hint format["Remaining Respawns: %1", (_maxrespawns - myRespawns)];

    For a persistence check, I initialize this variable in the SERVER init:

    missionnamespace setvariable ["sticklimitedrespawnsdeathlist",[],true];
    and then I do the following back in the CLIENT (and JIP) init (here my mission's 6th parameter is a 0/1 flag controlling limited respawns persistence checking):

    //Stick's limited respawns implementation of re-join trapping
    if ((paramsArray select 5)==1) then {
      nul = [] spawn {
        if ( (name player) in (missionnamespace getvariable ["sticklimitedrespawnsdeathlist",[]]) ) then {
          try {
            disableuserinput true;
            waituntil {not (isnull (finddisplay 46))};      
            titleText ["Nice try.  You already died too many times...", "BLACK OUT", 1];
            sleep 3;
          } catch {
            disableuserinput false;
          endMission "END4"; //totally local!  don't make it a remoteexec!
    Naturally, if someone is so motivated to rejoin a session after running out of personal respawns that they switch to a different player profile in order to change their name and bypass this check, they will get away with it. But they'll quickly tire of that after learning to just play Arma like a milsim instead of a videogame.

    NOTE: This is coded to work not just for regular clients but also hosted clients - it won't automatically end the mission if the hosting player dies too many times (which sometimes just happens because war is hell, or Arma killed you because your helicopter touched a rock), it instead puts that hosting player into a seagull.

    NOTE: This code ends the mission via the END4 ending, which I've defined in my description.ext cfgDebriefing class thusly:
        class End4
            title = "Excessive Death";
            subtitle = "Failure";
            description = "You died too many times!";
            pictureBackground = "";
            picture = "MinefieldAP";
            pictureColor[] = {0.9,0.3,0.3,1};
    You can, of course, handle the seagull mode or the mission ending any way you like.

    The mission parameters definitions in the description.ext used in the above examples look like this:

            class Revive
            // paramsArray[1]
                    title = "Number of Revives:";
                    values[] = {0,2,5};
                    texts[] = {"0  - Extreme", "2 - Hard", "5 - Normal"};
                    default = 5;

            class EnforcePersistentLimitedRespawns
            // paramsArray[5]
                    title = "Enforce limited respawns through reconnect";
                    values[] = {0,1};
                    texts[] = {"Do not enforce it", "Enforce it"};
                    default = 1;
    Last edited by Stick; 04-14-2017, 08:29 AM.



TeamSpeak 3 Server


Twitter Feed