Grimes Simple Revive Script

[KC Grimes 79]

@Rockapes 35 was right about my magic number too. Still looking into this. A bunch of things I can optimize and a few logic errors to correct that may or may not be related. Stay tuned. 

 

@Jnr4817 Any respawn settings should do, just keep Revive disabled (thanks for the reminder to better document this). The Eden Editor settings are just a UI for the description.ext statements editors have used for years. Feel free to use either.

 

I have considered moving at least some parameters to the lobby settings for on-the-fly changing, but need to think of a better way of doing that then just moving all of the settings there. What I may do is leave the settings as they are now, then in addition add the in-game params which could potentially override the G_Revive_init.sqf settings. Stay tuned!

 

Regarding your error, it looks like MobileRespawnEAST is defined in G_Revive_init.sqf as an MRV for EAST, but does not actually exist in your mission. You'll need to either match that variable name to the variable name of your EAST MRV, or just remove the name in the settings (which is just there by default for the example mission). That said, this points out a variable validation that I am missing. Thanks for sharing. 

[KC Grimes 79]

@Rockapes I did a massive overhaul of the Unit Tags system back-end which I thought would play a role in the issue you are describing. That said, I am unable to reproduce the issue of units unexpectedly bypassing revive and going straight to respawn. For both the V0.9 release and the latest commit, I threw a grenade into a group of 200 revive-enabled units, incapacitating at least 50 of them, while toggling the Unit Tags on and off. The Unit Tags lagged like crazy (which I fixed in the latest commits), however at both points I did not have a single unit bypass revive and go to respawn. It was cool to watch the AI pick up the mass casualties though. Yay numbers.

 

Could you please PM me your mission folder, or tell me how to reproduce the issue (including with settings)?

[Rockapes 103]

@KC Grimes Yeh mate I can do that soon as I get home. I wonder if some of the issues are caused by the fact that I am calling the spawn fnc after I have created the units during game ( using Zeus ).

I use fox admin mod to give me zeus access on any mission so I can give myself a proper team. 

Obviously because they spawned using Zeus they dont respawn.

[KC Grimes 79]

6 hours ago, Rockapes said:

@KC Grimes Yeh mate I can do that soon as I get home. I wonder if some of the issues are caused by the fact that I am calling the spawn fnc after I have created the units during game ( using Zeus ).

I use fox admin mod to give me zeus access on any mission so I can give myself a proper team. 

Obviously because they spawned using Zeus they dont respawn.

 

Ah, and for what it is worth, I have not played with Zeus at all. Who knows what else is having trouble with Zeus :P

[Rockapes 103]

4 hours ago, KC Grimes said:

 

Ah, and for what it is worth, I have not played with Zeus at all. Who knows what else is having trouble with Zeus :P

I tried quickly this morning your latest master branch with one of the missions I play regularly with AI loaded from mission start and they wouldnt even heal me when I was down. Very weird. I will upload when Im home. At hospital at moment.

[stick_hogue 10]

Meister Grimes,

 

My guys have a drag script that's very similar to this one, and possibly was based on an earlier version of it.  Thanks for that.

But they have stopped using it because of a variety of issues that happen in special-but-unfortunately-not-rare-enough circumstances, like if someone disconnects while being dragged, or just getting broken animation states, or breaking TFAR, etc.  I'm convinced that the issues have to do with using the attachto command for the drag, because attachto undoubtedly does things to player objects that BIS doesn't protect against in the rest of the game engine (why should they? that'd be a lot of code just to protect against exactly this odd situation).

 

So I've begun experimenting with replacing attachto (and its closeout detach) with something like this:

 

    [_target] spawn {
      params ["_target"];
      [_target,player] remoteexec ["disableCollisionWith",0];
      while {FAR_isDragging} do {
        try {
          if (!isNull _target && alive _target && !isNull player && alive player && ((lifestate player) in ["HEALTHY", "INJURED"])) then {
            [[_target,player],{
              (_this select 0) setposatl ((_this select 1) modeltoworld [0, 1.5, 0.092]);
              (_this select 0) setdir (getdir (_this select 1));
            }] remoteexec ["call",0];
            uisleep 0.1;
          } else {
            FAR_isDragging = false;
          };
        } catch {
          FAR_isDragging = false;
        };
      };
    };

 

I'd be curious to know if you've had complaints about problems that you think might be related to attachto in the drag functionality, and whether or not you've ever tried an approach like this.  It's really a simple idea:  setpos/setdir instead of attachto.  Why not?  attachto must cause problems with player objects - we've all seen it.

Thoughts?  Anyone?   Anyone?  Bueller?

[KC Grimes 79]

3 hours ago, Rockapes said:

I tried quickly this morning your latest master branch with one of the missions I play regularly with AI loaded from mission start and they wouldnt even heal me when I was down. Very weird. I will upload when Im home. At hospital at moment.

 

Hope all is well or else speedy recovery. 

 

That is peculiar. I've tested it both for V0.9 and the same commit you probably tested and am not having this issue, for both editor-spawned AI and post-init spawned AI (after use of G_fnc_initNewAI). I look forward to seeing the mission so we can try and figure out what is going on!

 

2 hours ago, stick_hogue said:

Meister Grimes,

 

My guys have a drag script that's very similar to this one, and possibly was based on an earlier version of it.  Thanks for that.

But they have stopped using it because of a variety of issues that happen in special-but-unfortunately-not-rare-enough circumstances, like if someone disconnects while being dragged, or just getting broken animation states, or breaking TFAR, etc.  I'm convinced that the issues have to do with using the attachto command for the drag, because attachto undoubtedly does things to player objects that BIS doesn't protect against in the rest of the game engine (why should they? that'd be a lot of code just to protect against exactly this odd situation).

 

So I've begun experimenting with replacing attachto (and its closeout detach) with something like this:

 

    [_target] spawn {
      params ["_target"];
      [_target,player] remoteexec ["disableCollisionWith",0];
      while {FAR_isDragging} do {
        try {
          if (!isNull _target && alive _target && !isNull player && alive player && ((lifestate player) in ["HEALTHY", "INJURED"])) then {
            [[_target,player],{
              (_this select 0) setposatl ((_this select 1) modeltoworld [0, 1.5, 0.092]);
              (_this select 0) setdir (getdir (_this select 1));
            }] remoteexec ["call",0];
            uisleep 0.1;
          } else {
            FAR_isDragging = false;
          };
        } catch {
          FAR_isDragging = false;
        };
      };
    };

 

I'd be curious to know if you've had complaints about problems that you think might be related to attachto in the drag functionality, and whether or not you've ever tried an approach like this.  It's really a simple idea:  setpos/setdir instead of attachto.  Why not?  attachto must cause problems with player objects - we've all seen it.

Thoughts?  Anyone?   Anyone?  Bueller?

 

Below are the only issues I currently have relating to Drag.

Combat pace (2xC) preventing movement

Hitting X while Dragging may force user into Carry animation

 

Your idea is absolutely feasible and would get the job done. My only concern would be network traffic. I like to think attachTo works well enough in the engine that it isn't essentially running setPos/setDir every frame. Assuming it does not do that, my concern is that running setPos/setDir (essentially) every frame may cause a negative performance impact in high numbers. 

[Rockapes 103]

Hey @KC Grimes, new baby boy in hospital so havent had a chance to do much but will asap. Thanks for the support 

[KC Grimes 79]

5 minutes ago, Rockapes said:

Hey @KC Grimes, new baby boy in hospital so havent had a chance to do much but will asap. Thanks for the support 

 

Congratulations! Enjoy the moment, the script will still be here :P 

[Rockapes 103]

4 hours ago, KC Grimes said:

 

Congratulations! Enjoy the moment, the script will still be here :P 

 

Thanks for the kind words mate, I have PM you with the link to download one of the missions that I noticed the problems on, maybe there is a background setting or conflict. Thanks again

[KC Grimes 79]

While testing with @Rockapes I was able to identify and fix a significant bug that was causing these inconsistencies in AI behavior after reviving. With that bug fix and the workarounds removed, the AI are now behaving better and more smoothly than ever (one may even say "as intended"). Additionally, if applicable, AI rescuers will now return to the vehicle they disembarked in order to perform their revive or guard duty. Finally, enemy AI can now be "Secured", a concept introduced in BIS Revive 1.82. My version of it accomplishes the same thing with the same look and feel so that we can continue to stay as stock as possible. All of these commits are currently available by downloading the master branch. 

 

Working on drawing 3D icons next. Expect V0.91 in the next day or so, which is a fairly significant update due to the AI behavior and Unit Tags rework. 

[KC Grimes 79]

@Rockapes @Jnr4817

 

V0.91 is now available, see the OP for download links! 

 

This update contains significant optimizations and some features, specifically with AI rescuer behavior and a complete rework of the Unit Tags system. The AI will now operate more "as expected", including increased utilization of vehicles as appropriate. Additionally, players can now "Secure" an incapacitated enemy, taking them out of the fight. Other new features and optimizations are also included. As always, a more complete changelog can be found by checking out the V0.91 milestone on github and a comprehensive changelog can be seen in the list of commits. 

 

Thanks for playing!

[Guest]

The Armaholic mirror has been updated with the new version:



Grimes’ Simple Revive Script v0.91

[Jnr4817 215]

//Custom Executions
//Note - By default they will execute on AI as well. Read comment to side.
G_Custom_Exec_1 = ""; //File executed when unit is set Incapacitated (NOT "killed"). _incapacitatedUnit = _this select 0, and is local.
G_Custom_Exec_2 = ""; //File executed when unit is killed (not revivable; unit is officially killed). _killedUnit = _this select 0, and is local.
G_Custom_Exec_3 = ""; //File executed when unit respawns after being killed. _respawnedUnit = _this select 0, and is local.
G_Custom_Exec_4 = ""; //File executed when MRV respawns after being destroyed. Newly spawned MRV = _this select 0, and is local. 
G_Custom_Exec_5 = ""; //File executed when unit is revived. _revivedUnit = _this select 0, and is local. _rescuer = _this select 1. 

Could any .sqf or function or file be used to execute in these? For example a custom AI skill set or loadout, etc. Or is this internal to the revive script for further functionality?

 

Thanks

[KC Grimes 79]

13 hours ago, Jnr4817 said:

//Custom Executions
//Note - By default they will execute on AI as well. Read comment to side.
G_Custom_Exec_1 = ""; //File executed when unit is set Incapacitated (NOT "killed"). _incapacitatedUnit = _this select 0, and is local.
G_Custom_Exec_2 = ""; //File executed when unit is killed (not revivable; unit is officially killed). _killedUnit = _this select 0, and is local.
G_Custom_Exec_3 = ""; //File executed when unit respawns after being killed. _respawnedUnit = _this select 0, and is local.
G_Custom_Exec_4 = ""; //File executed when MRV respawns after being destroyed. Newly spawned MRV = _this select 0, and is local. 
G_Custom_Exec_5 = ""; //File executed when unit is revived. _revivedUnit = _this select 0, and is local. _rescuer = _this select 1. 

Could any .sqf or function or file be used to execute in these? For example a custom AI skill set or loadout, etc. Or is this internal to the revive script for further functionality?

 

Thanks

 

These Custom Executions are intended for external use by the mission maker. The string will be the path to the SQF file (which is preprocessed into a function and executed as a function going forward). For instance, if I want "myLoadout.sqf" to execute after each respawn, just enter that string in for G_Custom_Exec_3 and it will work as intended. 

[Jnr4817 215]

Perfect, can there be more than one string per execution? For example, myloadout.sqf and aiskillz.sqf. 

[KC Grimes 79]

9 hours ago, Jnr4817 said:

Perfect, can there be more than one string per execution? For example, myloadout.sqf and aiskillz.sqf. 

 

At this time, no. You could either merge the files, execute one from the other, or search for the appropriate function's use in the code and just modify it directly. 

[PigeonSparrow 3]

Hi Grimes,

Is it possible to setup a trigger that revives any unit that enters? I'm trying to have a medical tent that heals and revives units that are dragged inside.

I tried using this code in a trigger that is set for BLUFOR Present, but I believe it only works for individual units:

{_x spawn G_fnc_exitIncapacitatedState} Foreach thislist;

What am I doing wrong here?


 

[PigeonSparrow 3]

Disregard, I figured it out. I used this and it worked.
 
0 = [] spawn { 
       { 
            if(_x distance (getMarkerPos "FOBa_Med") < 8) then {_x spawn G_fnc_exitIncapacitatedState}; 
        } forEach allunits; 
        
        sleep 1; 
};
 
hint "Patients Fully Recovered";

[KC Grimes 79]

On 5/26/2018 at 9:19 AM, PigeonSparrow said:

Hi Grimes,

Is it possible to setup a trigger that revives any unit that enters? I'm trying to have a medical tent that heals and revives units that are dragged inside.

I tried using this code in a trigger that is set for BLUFOR Present, but I believe it only works for individual units:

{_x spawn G_fnc_exitIncapacitatedState} Foreach thislist;

What am I doing wrong here?


 

 

Cool idea! Not sure why that statement was not working for you, but glad you got it figured out using script instead of a trigger anyway. 

 

To make your script a bit more consistent, I would also include a check to make sure that the unit is actually incapacitated before spawning a script to "revive" them. Without looking I'm not sure if your current setup may cause any issues, but maybe it would in the future. Consider the below, which includes a check for G_Incapacitated being true. 

 

[] spawn { 
	{ 
		if ((_x distance (getMarkerPos "FOBa_Med") < 8) && (_x getVariable "G_Incapacitated")) then {
			_x spawn G_fnc_exitIncapacitatedState;
		}; 
	} forEach allunits;
	sleep 1; 
};

 

[PigeonSparrow 3]

Thanks for the tip Grimes. I'll try adding that check to my mission. I'm having a lot of fun messing around with this script of yours.

I did run into a possible bug, but not sure if its because its conflicting with ASR ai or not. When I white list "B_Medic_F", the medic gets caught running around in a loop. It looks like the squad leader is ordering him back into formation when he attempts to revive another unit. I'll try testing it out when I get home from work to see if it is indeed ASR Ai conflicting with it.

[KC Grimes 79]

1 hour ago, PigeonSparrow said:

Thanks for the tip Grimes. I'll try adding that check to my mission. I'm having a lot of fun messing around with this script of yours.

I did run into a possible bug, but not sure if its because its conflicting with ASR ai or not. When I white list "B_Medic_F", the medic gets caught running around in a loop. It looks like the squad leader is ordering him back into formation when he attempts to revive another unit. I'll try testing it out when I get home from work to see if it is indeed ASR Ai conflicting with it.

 

If the behavior you are talking about is existing, it should not be due to the white list being used. If you use an empty white list instead (where every unit can revive), then all of the units should exhibit the mentioned behavior. If this is the case, this is something I have not reproduced with the script alone, and would suggest it is a conflict with ASR AI. Also try it without ASR AI of course.

 

Let me know what happens. If there is a conflict, I'll write it up and see if there is anything I can do on my end.

 

Thanks!

[PigeonSparrow 3]

Turns out it wasn't any mods that were conflicting when I whitelisted a medic unit. I tried putting in a different medic unit classname and it worked. I could of sworn I didn't misspell it but I guess I did. Probably just my newbie old hands. Thanks for the help!

[KC Grimes 79]

@Rockapes @runforrest @jeremyjhutton@gmail.com

 

V0.92 of Grimes Simple Revive has been released and is available in he OP! This update contains a few bug fixes primarily relating to loading/saving/otherwise rejoining a mission. Additionally, a scripted mission-end has been added as an option for when all friendly units are incapacitated and unable to respawn. Also, the integrated briefing is now dynamic, outputting based on settings chosen by the mission maker. Various other changes are included. As always, a more complete changelog can be found by checking out the V0.92 milestone on github and a comprehensive changelog can be seen in the list of commits. 

 

Thanks for playing!

[Guest]

The Armaholic mirror has been updated with the new version:



Grimes’ Simple Revive Script v0.92