KC Grimes

That's unfortunate. Is anyone else able to confirm? I am in school and will not have the time to address this for at least a few months, assuming it is worth the time come the summer. If someone would care to take a stab at a fix, that would be great and of course credited later on.

Thanks for playing. Take a look at G_Revive\G_Revive_Init_Vars.sqf, line 233 if ((side _x) in G_Revive_AI_Incapacitated) then { [_x] spawn G_fnc_EH; }; You could nest another if (or just add another condition), perhaps checking to see if the particular AI _x is playable. Alternatively, at line 238, you could do something differently than allUnits and allDead, though doing so many also effect players. Either way, testing will be required, particularly with AI systems. On that note, if it hasn't been noticed already, I have started back up in school and am unfortunately putting this project on the back-burner again. I encourage the community to continue to participate in this thread with feedback, suggestions, and bug reports, and help each other keep the project going. I'll try to pop in every now and then, though I can't offer much more until further notice.

Seeing this for the first time, looks great in the demo video!

Awesome, glad that is working. The subsequent issue you are having with the dialog is due to a workaround (read: dirty) fix for the dialog sometimes seemingly closing on its own without input. The fix detects the unexpected closure and simply re-opens the dialog. So long as the unit is Incapacitated, as yours is despite doing teamSwitch, this will occur every few seconds. Take a look at G_Unconscious.sqf, Line 157 to 170. I would suggest removing lines 157-170, inclusively, and replacing it with the following code (which used to be inside those lines): private _reviveDialog = createDialog "G_Revive_Dialog"; if (!G_Allow_GiveUp) then { ((findDisplay 474637) displayCtrl 1600) ctrlShow false; }; That will fix your issue, which is certainly more of an issue than the periodic unexpected closure of an otherwise cosmetic dialog. Have fun!

Remote exec should work, just use the "object" approach for the targets. Specifically, your target argument is "crew _vehicle", where _vehicle is the subject vehicle object. That will execute the desired code locally on all vehicle occupants (dead and alive).

A bug in the system that incapacitates a unit for revive purposes instead of killing them has been brought to my attention. This bug resulted in certain non-fatal damage resulting in incapacitation. Specifically, critical damage to the hands, arms, and legs would result in incapacitation, when in the stock game that is not the case. This slipped through for so many years because I tend to test with head shots, not leg and arm shots! I imagine most players tend to roll this way in-game too. The issue has been fixed and pushed to github, though its inclusion in a release is still pending.

Team Switch is admittedly something I have never personally used as I tend to play my SP missions in the MP environment. That said, I have recognized Team Switch as a desired feature, though I do not have an ETA or guarantee that it will be implemented. I have not looked into it enough to provide a tested suggested approach to implementing it into this script. If you whip something up, even if it involves using a Custom Execution, please do share (and credit will of course be provided)! If teamSwitch just needs to be executed, I think the cleanest route would actually be enabling the Give Up button, then changing the action of the dialog button (G_Dialogs.hpp, Line 19) from having "player setDamage 1" to "teamSwitch". I have no idea if that will work, what will happen, or how switching back to the unit will work. Best of luck!

Take a look at the Code Optimization page on the biki, which will help with some ideas on how to slim down. You use a forEach to define playerSarray as playableUnits. If you were checking for a specific condition this would make some sense, but it seems you are not, so instead just directly define playerSarray as playableUnits. Use the selectRandom command instead of the function BIS_fnc_selectRandom. On that note, you are selecting from "playerarray" but you previously defined "playerSarray". Was "playerarray" defined earlier in code that you did not include? Same thing happens later, you use "playerspos" and not the defined "randomplayerpos". Slimmer means fewer definitions of variables/number of lines. Only referencing "randomplayerpos" once? Then don't make it a variable, just execute the command directly where you are using the variable. I do not understand your comment in the code snippet. For anything further we may need to see more of the code.

Just to clarify, the issue you are having is that you do not know how to get the AI to spawn on their squad leader? If that is the case, sorry I did not get around to this feature in time! This is mostly due to the fact that it is an easy workaround, though there are some catches, which I will get to. Anyway, you actually want to execute your custom script with G_Custom_Exec_3, which will handle the unit on respawn. Something like this should do the trick: script.sqf //Script to move AI to squad leader on respawn //_respawnedUnit is local params ["_respawnedUnit"]; //Only move AI to squad leader if (!isPlayer _respawnedUnit) then { //Handling AI, so move them to squad leader _respawnedUnit setPos (leader group _respawnedUnit); //Assume squad leader's stance [_respawnedUnit, animationState (leader group _respawnedUnit)] remoteExecCall ["switchMove", 0, true]; }; I added a little stance change, mostly so that a standing AI does not spawn onto a prone squad leader! Now, there are a few considerations. No need to address them here, just things to think about. What if the squad leader is dead? What if the AI is the squad leader? What if the squad leader is in a vehicle with space available? Full vehicle? Good luck!

In Line 6 you are missing the _x argument for setDamage. {setDamage 1;} forEach _bollards; {_x setDamage 1;} forEach _bollards; The same error occurs in Line 14. Also be advised that you are defining __bollards (2 underscores) but referencing _bollards (1 underscore).

What is not working exactly? Make sure -showoScriptErrors is enabled, as I would bet that your issue would pop up there. And how are you executing the addAction? My understanding is that you have an ammo crate with an addAction scripted onto it, and the above code block is what is executed. The code is intended to add that list of items to the nearest vehicle within 15m. Regarding the error, read through the biki entry for nearestObjects. Pay close attention to the return value, and understand that you are executing commands that require an object as an argument, and you are giving them an array. Because nearestObjects returns an array, you need to select the first (closest) element in that array and set your local variable equal to that. If that makes sense, take a look at the difference between nearestObjects and nearEntities and then read up further on nearEntities. Although not a particularly big deal here, it is a good habit to get into when the circumstances fit.

Your idea is fine. Just a few points on your approach. Read through the biki page for addAction, and that should address your question (and very clear formatting issue) regarding your use of the command. I am assuming that large code block is teamleader.sqf. If so, why are you execVM'ing it again? That is what the addAction is accomplishing, or so I thought. Either way, you don't need the "null" when using execVM in a script file. Try to be consistent about use of single or double quotes. Which one to use is a whole different question and, arguably, personal preference, but you should still pick just one.

Post-release, I noticed one minor bug but @Rockapes noticed a bigger bug that caused G_fnc_initNewAI to not function. These issues have been corrected. A minor optimization was also included. Please see OP for a re-release of V0.92 to include these hotfixes. Sorry for the inconvenience. Thanks for playing, and thanks for the feedback!

The Eden Editor settings are pretty user friendly and straightforward. I tried to kind of mix and match between it and description.ext, but that became very messy. Especially to make things easier for anyone else viewing the files, I try to stick to Eden as opposed to manual settings in init.sqf and description.ext. It seems like for now it is definitely user preference.

@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!