Jump to content
mons00n

SRS: a MP-only Simple Revive Script for A3

Recommended Posts

I'm having massive issues trying to get your script to work.

Following the readme text in the file I have achieved the following:

### Installation

To include this script in your mission, add the following lines to your ``description.ext``:

#include "SRS\GUI\SRSdialogs.hpp"

class RscTitles {

#include "SRS\GUI\SRSprogressBar.hpp"

};

class CfgFunctions {

#include "SRS\CfgFunctions.hpp"

};

And this entry in your ``init.sqf`` so that it will execute on all clients:

[] spawn SRS_fnc_init;

--

However, where do I put the rest of the files? I've placed then alongside the init.sqf / mission.sqm in the mission folder, but nothing seems to trigger or work in game when ran in a MP game.

Did you simply place the SRS folder in your mission directory? The layout should be:

mission root
- SRS
-- all SRS contents
- mission.sqm
- init.sqf
- description.ext

Share this post


Link to post
Share on other sites

The extracted file is called something like rthompson-srs--something. You have to rename it to just SRS otherwise it won't work.

Thanks for this script Monsoon... like it very much.

Share this post


Link to post
Share on other sites

Hi there,

Script is pretty cool, just have 2 major issues with it. Other than these, it pulls off more than any other revive script I've used, and the customisation is fantastic.

1. TFAR is definitely not muted when a unit is unconscious. I am able to have conversations both ways with people in the unconscious state with TFAR mod enabled.

2. JIP is not working at all. If all players load in at mission start, there is no problem with the script loading. If players load in after the mission starts, SRS only half loads on that client, so they are unable to revive, or be revived. So the script seems to load at least some function because the players go into the unconscious state and are awaiting to be revived. However, no players, even with medikits and FAKs equipped, have the function to revive the downed player. So it's like only half of the script loads? Regardless, it is definitely JIP that is causing this issue, from our extensive testing.

EDIT: I did some further testing on this with the Debug enabled. It looks like the JIPs are the ones who CANNOT BE REVIVED. They can revive other people, but nobody can revive a JIP that the script doesn't load properly on. Looking at the SRS Debug, it can be seen that those who the script fails to load properly on, load in as an 'AI' name. E.g. if I were to load into a mission JIP, the script would run on the unit 'Price' (instead of Phant). About 5 seconds later, I'll be assigned my actual name Phant (instead of the placeholder name 'Price') and thus the script will have not loaded on me at all. Upon using reset SRS I can revive other players, but nobody can revive me. If I rejoin and the script detects me as Phant straight away (instead of the placeholder 'Price') then there is no problems with the script. It is only when the server is slow in detecting a player, the script will run anyway.

I think the script just needs JIP wait code chucked in so it waits when a player joins that they fully load and initialise, but I am not sure which file to put it in.

Resetting SRS does not fix the issue, but rejoining the server does.

Let me know if you need more info on the above cases.

Edited by Phant

Share this post


Link to post
Share on other sites
I wonder if there is an ability to disable suicide?

Yeah, quite easily but manually, you can remove the button from the 'unconscious' interface entirely, through SRS > GUI > fn_button.sqf. You want to remove the quoted part below ONLY, from fn_button.sqf.

case "RESPAWN":{

[] call SRS_fnc_suicide;

};

Else you could just simply open up SRS > Functions > fn_suicide.sqf. I am not sure you can delete the file as it is called from other scripts but you can just delete the contents of the file and save it, then the suicide option won't do anything.

Edited by Phant

Share this post


Link to post
Share on other sites
Yeah, quite easily but manually, you can remove the button from the 'unconscious' interface entirely, through SRS > GUI > fn_button.sqf. You want to remove the quoted part below ONLY, from fn_button.sqf.

Else you could just simply open up SRS > Functions > fn_suicide.sqf. I am not sure you can delete the file as it is called from other scripts but you can just delete the contents of the file and save it, then the suicide option won't do anything.

Cool I'll give it a try!

Share this post


Link to post
Share on other sites

1. TFAR is definitely not muted when a unit is unconscious. I am able to have conversations both ways with people in the unconscious state with TFAR mod enabled.

Really? That is quite odd! You should still be able to *talk* to one another locally, but you shouldn't be able to transmit via the radio. You had SRS_muteRadios set to true correct? If you take a look at fn_toggleRadio.sqf you see all I do is set each player variable "tf_unable_to_use_radio" accordingly. In my tests it *seems* to work ok, but would be interested to know what is going on here.

2. JIP is not working at all. If all players load in at mission start, there is no problem with the script loading. If players load in after the mission starts, SRS only half loads on that client, so they are unable to revive, or be revived. So the script seems to load at least some function because the players go into the unconscious state and are awaiting to be revived. However, no players, even with medikits and FAKs equipped, have the function to revive the downed player. So it's like only half of the script loads? Regardless, it is definitely JIP that is causing this issue, from our extensive testing.

EDIT: I did some further testing on this with the Debug enabled. It looks like the JIPs are the ones who CANNOT BE REVIVED. They can revive other people, but nobody can revive a JIP that the script doesn't load properly on. Looking at the SRS Debug, it can be seen that those who the script fails to load properly on, load in as an 'AI' name. E.g. if I were to load into a mission JIP, the script would run on the unit 'Price' (instead of Phant). About 5 seconds later, I'll be assigned my actual name Phant (instead of the placeholder name 'Price') and thus the script will have not loaded on me at all. Upon using reset SRS I can revive other players, but nobody can revive me. If I rejoin and the script detects me as Phant straight away (instead of the placeholder 'Price') then there is no problems with the script. It is only when the server is slow in detecting a player, the script will run anyway.

I think the script just needs JIP wait code chucked in so it waits when a player joins that they fully load and initialise, but I am not sure which file to put it in.

Resetting SRS does not fix the issue, but rejoining the server does.

Let me know if you need more info on the above cases.

Thank you very much for your detailed feedback! Testing JIP is quite challenging with only a single Arma account. I think what is happening is that the unitVariable is being assigned before the player actually exists in the game (when a unit is initialized it is first owned by the server before being transferred to the client). Since each individual client is responsible for new unitVariables, this isn't a trivial fix. I have a simple idea I'd like to test so if you'd be willing to give it a go shoot me a pm!

I wonder if there is an ability to disable suicide?

You could disable suicide, BUT there is a big caveat that comes along with it: if the person never gets revived, they are STUCK on that screen until the timer runs out, and if the timer never runs out they will have to manually kill the Arma3 process since you cannot access the game-menu through the escape key. But as was said above, if you remove the contents (or better yet comment them out) from fn_suicide.sqf the button will be useless.

Share this post


Link to post
Share on other sites
Really? That is quite odd! You should still be able to *talk* to one another locally, but you shouldn't be able to transmit via the radio. You had SRS_muteRadios set to true correct? If you take a look at fn_toggleRadio.sqf you see all I do is set each player variable "tf_unable_to_use_radio" accordingly. In my tests it *seems* to work ok, but would be interested to know what is going on here.

Ahh okay I see what it is for then. Yes it does mute radio, but it doesn't mute direct communication. This is fine if this is what it is intended to do. It is working correctly for me then!

Thank you very much for your detailed feedback! Testing JIP is quite challenging with only a single Arma account. I think what is happening is that the unitVariable is being assigned before the player actually exists in the game (when a unit is initialized it is first owned by the server before being transferred to the client). Since each individual client is responsible for new unitVariables, this isn't a trivial fix. I have a simple idea I'd like to test so if you'd be willing to give it a go shoot me a pm!

Yeah sounds good. I would be happy to test out any amendments to your script. I will shoot a PM to you.

And thanks again for creating SRS, it's currently a valuable asset to my group's Operations.

Share this post


Link to post
Share on other sites
Ahh okay I see what it is for then. Yes it does mute radio, but it doesn't mute direct communication. This is fine if this is what it is intended to do. It is working correctly for me then!

excellent!

Yeah sounds good. I would be happy to test out any amendments to your script. I will shoot a PM to you.

Literally in the midst of responding to your PM I thought of what was causing the problem. I believe the unitVariable was being assigned on all clients *before* the JIP player was fully initialized, which means that when I tried "getPlayerUID" it returned an empty string, so the publicVariableEventHandler attached to each unit (on each client) was not setup properly for those who JIP --> causing the menu options to not properly be updated when those units were downed. To fix this I added a check that ensures that getPlayerUID returns a non-empty string before initializing the unitVariable. Hopefully this resolves silly JIP issues! But please download the latest version from bitbucket and let me know if it works =)

It looks good, one question, is there a way to limit the amount of revives per player?

Not currently Schmucke, do you mean limit the number of times a unit can be revived?

Changelog

Feb 26, 2015:

- added a check to make sure that the unit is fully initialized before setting up the unitVariable, hopefully resolving some JIP issues.

Share this post


Link to post
Share on other sites

So yeah we tested the shit out of the new version of your script with JIPs, all working absolutely perfectly. Had no problems at all in a live Op either.

Thanks very much for that.

Share this post


Link to post
Share on other sites
So yeah we tested the shit out of the new version of your script with JIPs, all working absolutely perfectly. Had no problems at all in a live Op either.

Thanks very much for that.

That's fantastic news! thanks again for the continued testing =) Let me know if you run into any other issues or have any requested features.

Share this post


Link to post
Share on other sites

hi have a problem, I lose leader status in squad when respawning.

don't know if this related to your revive script, but would be very happy to get rid of it and all I tried fails.

Edited by maquez

Share this post


Link to post
Share on other sites

hello, I am getting some strange error and don't know why.

\SRS\GUI\SRSdialogs.hpp,line 22:.RscText:Member already defined

Is this a conflict with another dialog.hpp? or is this something else and how can I fix?

Thanks

Share this post


Link to post
Share on other sites
hi have a problem, I lose leader status in squad when respawning.

don't know if this related to your revive script, but would be very happy to get rid of it and all I tried fails.

I think this is a general issue with how Arma handles respawn, as my script does not mess with group leadership. I know it is not ideal, but I would recommend a simple group interaction plugin of some sort which will allow you to regain leadership after respawn.

hello, I am getting some strange error and don't know why.

\SRS\GUI\SRSdialogs.hpp,line 22:.RscText:Member already defined

Is this a conflict with another dialog.hpp? or is this something else and how can I fix?

Thanks

What does your description.ext look like? If you have more than one RscText defined then you need to merge them into the same class.

Share this post


Link to post
Share on other sites
What does your description.ext look like? If you have more than one RscText defined then you need to merge them into the same class.

I will go back and look, I swear I had everything in the same RscText class.

Share this post


Link to post
Share on other sites
I will go back and look, I swear I had everything in the same RscText class.

error

\SRS\GUI\SRSdialogs.hpp,line 22:.RscText:Member already defined

description.ext

//------------------------- Includes / Functions

#include "scripts\VAS\menu.hpp" 						// VAS
#include "scripts\taw_vd\dialog.hpp" 					// TAW View Distance
#include "scripts\vehicle\crew\common.hpp"  			// vehicle crew hud
#include "scripts\spectator\spectating.hpp"     		// Kegetys Spectator Script
#include "VVS\menu.h"									// Virtual vehicle spawn
#include "ATM_airdrop\dialog.hpp"						// Halo jump
#include "SRS\GUI\SRSdialogs.hpp"						// SRS revive

class CfgFunctions
{
	#include "functions\cfgfunctions.hpp"			// Integrated I&A functions
	#include "scripts\VAS\cfgfunctions.hpp"			// VAS
	#include "VVS\Functions.h"						// VVS
	#include "scripts\taw_vd\CfgFunctions.hpp"		// View distance
	#include "SRS\CfgFunctions.hpp"					// SRS revive
    class FETT {									// Curator synch http://forums.bistudio.com/showthread.php?176691-Making-placed-units-be-editable-for-every-Zeus
        class curator {
            class eventHandlers {postInit = 1;};
            class objPlaced {};
            class grpPlaced {};
        };
    };
};

class RscTitles
{
	#include "scripts\vehicle\crew\namesleft.hpp"		// Occupants HUD for vehicles
	#include "=BTC=_Logistic\=BTC=_Lift\=BTC=_Hud.h"	// BTC
	#include "SRS\GUI\SRSprogressBar.hpp"				// SRS revive
};

What am I missing?

Share this post


Link to post
Share on other sites
error

\SRS\GUI\SRSdialogs.hpp,line 22:.RscText:Member already defined

description.ext

//------------------------- Includes / Functions

#include "scripts\VAS\menu.hpp" 						// VAS
#include "scripts\taw_vd\dialog.hpp" 					// TAW View Distance
#include "scripts\vehicle\crew\common.hpp"  			// vehicle crew hud
#include "scripts\spectator\spectating.hpp"     		// Kegetys Spectator Script
#include "VVS\menu.h"									// Virtual vehicle spawn
#include "ATM_airdrop\dialog.hpp"						// Halo jump
#include "SRS\GUI\SRSdialogs.hpp"						// SRS revive

class CfgFunctions
{
	#include "functions\cfgfunctions.hpp"			// Integrated I&A functions
	#include "scripts\VAS\cfgfunctions.hpp"			// VAS
	#include "VVS\Functions.h"						// VVS
	#include "scripts\taw_vd\CfgFunctions.hpp"		// View distance
	#include "SRS\CfgFunctions.hpp"					// SRS revive
    class FETT {									// Curator synch http://forums.bistudio.com/showthread.php?176691-Making-placed-units-be-editable-for-every-Zeus
        class curator {
            class eventHandlers {postInit = 1;};
            class objPlaced {};
            class grpPlaced {};
        };
    };
};

class RscTitles
{
	#include "scripts\vehicle\crew\namesleft.hpp"		// Occupants HUD for vehicles
	#include "=BTC=_Logistic\=BTC=_Lift\=BTC=_Hud.h"	// BTC
	#include "SRS\GUI\SRSprogressBar.hpp"				// SRS revive
};

What am I missing?

It looks like a conflict with one of your other hpp files - something is getting defined twice. In SRSDialogs I redifine a bunch of defaults since they don't exist by default - feel free to comment these out and see if that helps. Right now it seems to be complaining about #define CT_XSLIDER 43

Share this post


Link to post
Share on other sites
It looks like a conflict with one of your other hpp files - something is getting defined twice. In SRSDialogs I redifine a bunch of defaults since they don't exist by default - feel free to comment these out and see if that helps. Right now it seems to be complaining about #define CT_XSLIDER 43

That's what I was seeing too. If I comment those out will it interfere with SRS?

Share this post


Link to post
Share on other sites
That's what I was seeing too. If I comment those out will it interfere with SRS?

I'm not sure to be honest as I haven't messed with those other scripts. I assume that if they're both defined the same then it should be fine - but your best bet is to go and see if it works!

Share this post


Link to post
Share on other sites
Looking good! I already like a lot of the features it has but what I think most of the other script versions are missing and what would make this script unique if added, is a two stage heal-process (BTW: I know some addons have it but not scripted versions).

A wounded player (patient):

1) first needs to be stablized to reduce the bleeding (and thus slowing down the timer). This gives the medic time to work on multiple patients. Any player with a FAK (or a FAK taken from the patient) is able to stabilize the patient.

2) can then be healed. Time of process can be varied by the severity of the wounds (lightly wounded, moderate or heavy) added with a random value. A easy parameter would set if all players, only players with a medikit or only medics with a medikit are able to fully heal a patient (like BTC has, so missionmakers can decide who is able to heal)

Such a feature will require a lot more teamwork and will put the medic in a more dominant/depending role.

If there's a possibility you could/would add this, we will probably add this medic-system to all of our missions.

If you want we can do some additional testing for you in a multiplayer environment and report back.

I like this idea, but it adds an additional layer of complication that I really didn't want to get into. As of right now the parameter "SRS_medicAdvantage" dictates how much quicker a unit with a Medikit will revive; by default this is set to 0.5, so 50% quicker healing. You can very easily crank this up to say 0.75 (75%) and tinker with "SRS_reviveTime" which dictates how long it takes to revive for non-medic units. But when I get more time I'll revisit the idea and think about how to properly implement it.

Although not exactly the same, I will use your proposal of crancking up SRS_revivetime and SRS_medicAdvantage for the time being. Looking forward to the "stabilize"-option for the future then :) Fingers crossed!

Just been trying SRS and I really, really like it! Good job mons00n!

With all the variables that can be configured already (thanks for that!!), it lacks one more in my view:

- an option to turn on/off the use of the camera (3rd person/1st person) once you're incapacitated. Hardcore gamers that don't use 3rd person view, normally want to stick to 1st person, even when they are waiting to be revived.

Additionally you could also add an option for people to set if they want the camera 1st or 3rd person by default, just an idea though ;)

Will try this some more with my friends to see if we can find any bugs but it's working fine so far.

Edited by deleyt

Share this post


Link to post
Share on other sites

Is there any way to edit the scripts to disable the FAK requirement?

Edit: Spent a little while messing with it and figured it out.

\SRS\Functions\fn_revive.sqf

and modify it to this

_isMedic = if(_healerItems find "Medikit" >=0) then{True} else{True};

_healerHasFAK = if(_healerItems find "FirstAidKit" >= 0) then{True} else{True};

_injuredHasFAK= if(_injuredItems find "FirstAidKit" >= 0) then{True} else{True};

_availableFAK = if(_injuredHasFAK || _healerHasFAK) then{True} else{True};

Edited by plsgo

Share this post


Link to post
Share on other sites
Just been trying SRS and I really, really like it! Good job mons00n!

With all the variables that can be configured already (thanks for that!!), it lacks one more in my view:

- an option to turn on/off the use of the camera (3rd person/1st person) once you're incapacitated. Hardcore gamers that don't use 3rd person view, normally want to stick to 1st person, even when they are waiting to be revived.

Additionally you could also add an option for people to set if they want the camera 1st or 3rd person by default, just an idea though ;)

Will try this some more with my friends to see if we can find any bugs but it's working fine so far.

Thanks for the kind words! Check the latest update for the 3rd/1st person cam fix =)

Is there any way to edit the scripts to disable the FAK requirement? I'm using AGM and it's conflicting.

Glad to hear you figured it out. I just added a flag to the latest version to allow you disable this requirement (I wasn't aware anyone was using this with AGM!).

UPDATE March 25, 2015:

  • SRS_requireFAK --> this checks for and removes a FAK, if disabled this check is bypassed and no FAKs are removed.
  • SRS_toggleCam --> this enables the 3rd person 1st person camera toggle

just download the latest version of the repo and you should be good to go~

Share this post


Link to post
Share on other sites
snip

Thanks a bunch for this, I was having issues with AGM Medical module but I was also able to fix those. Regardless some mods mess with FAK mechanics so this is a very useful function!

Share this post


Link to post
Share on other sites

hi, i have some issue and i am a newbie

1. SRS script for JIP player is not enabled so i wrote in init.sqf :

[]spawn SRS_fnc_init;

if (!isServer && isNull player) then
{
   waitUntil {!isNull player};

   []spawn SRS_fnc_init;
};

with this SRS is enabled for JIP player but i have some lags

2.how respawn with same gear when you dies and hit suicide button ?

3. i have a conflict between SRS and outlw_magRepack script version and no error message shows,

i always use magRepack in my missions no conflict with BTC Revive or FAR Revive so i think SRS is the problems.

otherwise SRS is good.

PS: sorry for my bad english

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×