Jump to content
Bohemia Interactive Forums

mons00n

Member
 View Profile  See their activity

  • Content Count

    154

  • Joined

  • Last visited

  • Medals

Posts posted by mons00n

  1. Posted

    You can use the "GetOut" eventHandler to put the unit back into cargo, which is basically the same as your loop, but is perhaps better for performance.

    Although I just tried allowCrewInImmobile on a Zamak with an AAF fireteam in cargo, and they stay in the vehicle even if I shoot out all the tyres, whereas they would normally eject after I damaged 3 of the wheels. What vehicle are you using?

    Hrm, I'm using a Zamack transport (open). Maybe the behavior is different when a driver is present? I've only tested this with an empty vehicle and putting the AI in the passenger seat.

    i'm pretty sure bailing out of the vehicle is part of the danger fsm, so disableai "FSM" might work?

    That's the first thing I tried! Unfortunately the AI still has some sort of brain when the FSM is disabled.

  3. Posted

    When using SRS revive and ZLT fastropes scripts in same mission, neither works. SRS revive stops working, period. There is no opportunity to revive fallen teammates. ZLT Fastropes, when you touch the ground, instant death. Remove one or the other, no issues with the remaining.

    I loaded up a quick test mission with both zlt & SRS - both work fine for me; here's a link. Without anything more specific (error messages, etc) I'm not sure I can help =/

  4. Posted

    ZLT_Fastropes go BOINK! with SRS revive.

    ZLT or SRS alone, no issues. ZLT with SRS, ropes do not work and neither does revive.

    Two great scripts that sadly dont play well together. Anyone know of a workaround?

    Hi lawndartleo, could you be more specific by what "BOINK" means in this instance? I don't see anything in particular with zlt_fastropes that would be causing any issues; all it does is add actions to the player.

  5. Posted

    allowCrewInImmobile should work for all occupants, not just turret seats (driver,gunner,commander,turrets). The key for using that function is to call it while the vehicle is empty. If you call it while the vehicle has occupants, it may not work correctly, at least that was my experience.

    I've tried calling this while it was empty, or occupied, either way makes no difference for me. I slap down a transport vehicle, add "this allowCrewInImmobile true" to the init, tell the AI to hop in, shoot the tire and the AI hops out. If I follow the same procedure with a driver he stays in the vehicle as expected.

    I would also assign him to the seat you want him to sit in, or at least to cargo.

    using the 'assignAsCargo / assignAsCargoIndex' functions.

    oh yea I'm already doing that

    (EDIT: see you've already used it) Can even try the 'addVehicle' function although I doubt that's necessary. I don't believe 'moveInCargo' will assign him a seat, meaning he'll get out at first opportunity or whenever his group leader issues a 'getout' command.

    Yea I think the AI is just pre-programed to get out when the vehicle is damaged. The while loop I posted above seems to be working well enough for me.

  6. Posted

    Is there any way to prevent AI from disembarking from a cargo spot when it gets damaged? I know allowCrewInImmobile works for "crew", but unfortunately does not work for "cargo" =/. I'm trying to setup a sort of escort mission where the unit never leaves a vehicle, but it is proving rather difficult when a few shots to the tire makes him jump out and lay on the ground. I have tried disableAI for FSM & MOVE, neither of which seem to do the trick. Any ideas? Thanks!

    ---------- Post added at 11:55 ---------- Previous post was at 11:38 ----------

    I just figured out a pretty poor way of handling this:

    _unit = _this select 0;
_veh  = _this select 1;

_unit assignAsCargoIndex [_veh,1];

while{true} do{
waitUntil{vehicle _unit != _veh};
_unit moveInCargo [_veh,1];
sleep 1;
};

    which seems to work, but I'd be curious to hear any other approaches.

  9. Posted

    Hi all,

    I'll be trying this out with the ALiVE mod on a dedicated server. I'm re-configuring the server right now so I'll be testing it out later. Does anyone know how well this works with the ALiVE module? Would save me some trouble re-configuring the mission if ALiVE breaks the script. I'm currently using Farooq's but this one looks better. I'll check back here for a response once I get the server reconfigured before I mess with the mission pbo.

    Thanks

    I haven't explicitly tested this with alive, but I don't see any reason why it would conflict!

    Hi Mons00n,

    I was just curious as to how you were implementing the respawnLoop.sqf script you're using? Are you placing it in the init.sqf?

    I'm having a hard time getting units to respawn with their gear.

    You want to run this script on all clients, which is easiest done by creating a file called "initPlayerLocal.sqf" in the root mission directory, then add an execVM statement to execute the respawn loop script:

    [] execVM "respawnLoop.sqf";

  11. Posted

    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

    Hi Powel! Where are you initializing SRS? If in your init.sqf then it should be called for every palyer regardless of if they are JIP or not. You shouldn't have to call SRS_fnc_init multiple times, so deleting the first instance in your example should be fine.

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

    That is something that SRS does not handle, I left that up to the mission creator. This is the script I use in my missions for this purpose.

    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.

    If there is no error then what tells you there is a conflict? I am not familiar with magRepack but it is likely a redefinition in GUI/SRSdialogs.hpp, but without an error message I am not sure.

  13. Posted

    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~

  15. Posted

    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

  16. Posted

    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.

  17. Posted

    Installed on the Comrades in Arms server! Note that the mission is for eight players but the thread title says 5.

    Great to hear! Unfortunately I cannot update the title of the post =/ The mission was originally designed for 5, but I recently expanded it to support 8 as that is the most that can fit in the extraction chopper.

  19. Posted

    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.

  20. Posted

    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.

  21. Posted

    Is there any way to dynamically add AGM modules via script? What I mean is...

    //detect module
AGM_PRESENT = if(isClass (configfile >> "CfgPatches" >> "AGM_Medical")) then{ True } else{ False };

//if module present, add it and set variables
if(AGM_PRESENT) then{
_logic  = createCenter sideLogic;
_agmGrp = createGroup _logic;

AGM_MODULE = _agmGrp createUnit ["AGM_ModuleMedical", [0,0,0], [], 0, "CAN_COLLIDE"];

_vars = [
	["CoefDamage",1],
	["CoefBleeding",1],
	["CoefPain",1],
	["CoefNonMedic",1],
	["MaxUnconsciousnessTime",-1],
	["AllowNonmedics",True],
	["RequireDiagnosis",False],
	["PreventInstaDeath",True],
	["PreventDeathWhileUnconscious",True],
	["SingleBandage",True],
	["AllowChatWhileUnconscious",True],
	["EnableOverdosing",True],
	["RequireMEDEVAC",False],
	["AutomaticWakeup",True],
	["DisableScreams",False]
];

{ 
	AGM_MODULE setVariable [_x select 0, _x select 1]; 
}forEach _vars;
};

AGM_PRESENT

    I call this from init.sqf on each client to determine if I should use either a revive script, or AGM if it is present. The idea is to basically make my missions work with or without AGM. This appears to work fine in single player (no surprise there), but in MP this appears to execute after the AGM core module initializes. Is there any way to maybe re-init the AGM core module to consider the newly placed medical module? Thanks for the great work!

  22. Posted

    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

  23. Posted

    My group used this in coop tonight and it worked very well.

    That's great to hear! Appreciate the feedback.

    One thing I would love to see though would be an alternative to the action menu. For example, a dedicated key that presents you with a simple menu of the options when pressed near a downed player. Maybe this goes beyond your idea for a "simple" revive script, but it would be a great alternative to the scroll menu (can't believe we are still battling against that thing in 2015). At one point I ended up placing a satchel under a downed squadmate with a misclick.

    Alternatively a hotkey for revive and a hotkey for drag.

    Anyway, thanks for this script.

    I agree that the action menu system is pretty horrific. I know they have a better solution on their road map, so let's hope they can come up with something clever. In regards to the dedicated keys I worry about conflicting with other mods and the such, but I'll take a look into it.

    how to disable the fatigue applied after revive ? :mad:

    Hi Maquez, I just implemented a variable to disable this in the latest version. Just set

    SRS_reviveFatigue = False;

    in the fn_init.sqf script.

    G'day Monsoon.

    I currently use Farooq's revive in my coop hardcore missions however that is no longer supported and I'm looking around for revive scripts.

    As your work is still currently WIP do you have any plans to implement the following?

    1: FAKs to stablise patient and halt/slow bleedout clock

    2: Definable parameter to allow medic only revive

    3: Consumption of FAK upon use

    4: Loading of wounded into vehicles

    I like the applied high fatigue level after revive and think that adds an extra challenge to the wounded player.

    1) this is on my radar, but a low priority at the moment

    2) Just updated the code to account for this, set

    SRS_medicsOnly = True;

    and only people with a Medikit should be able to revive.

    3) I just implemented this in the latest commit. Should take a FAK away from the injured player first, if one is not present then it will remove one from the healer.

    4) I do not have plans of implementing this, sorry =/

  24. Posted

    Mons00n, thank you for your detailed guide. It has helped me put things together conceptually :)

    I have a question:

    You have mentioned that certain scripts that modify the AI basic (editor or main script) intelligence level should also be run on the server as well as the Headless client.

    If I got this statement correctly then if the AI are spawn exclusively on HC, do I still need to run that script on the Dedicated server also?

    If there are no AI on the server then I presume not. But I probably still would just in case the HC crashes and all of the AI gets transferred back to the server. Either way if there are no AI on the server then it shouldn't be wasting too much processing power.

  25. Posted

    Regarding the HC, I always wondered one thing. Given the AI HC is good but the HC is not immune to a disconnection or crash.

    This happens if the AI is managed by a HC and it disconnects?

    The AI does not work? There is an automatic transfer to the server?

    If you have an answer, I'm interested.

    The AI should be transferred back to the server as I mention in the guide when discussing ownership. Less chance of disconnect is another reason why having the HC on the same network or in the same datacenter is ideal.

×