Cerebus06

@Larrow and @RyanTurner - thanks a lot. RespawnOnStart was the answer I was looking for. Really appreciate the help!

Yes, I did, but just to make sure I started one from scratch. Multiplayer Attributes: Respawn on Custom Position Select Respawn Position Show Respawn Counter (set at 5 seconds) Two Respawn icons (named "respawn_one" and "respawn_two," respectively) synchronized with two Triggers (set to BLUEFOR Present). When I run this as Multiplayer, when I start the game and hit the Continue button on the briefing page, I get thrown immediately to a respawn page where the countdown occurs, and then a "Respawn Disabled" message on the respawn button.

I've searched the forums, and I admit that if this has been dealt with before I didn't find a post that addressed this specifically, so I apologize if it's been covered prior to this. What I'm trying to do is create basically a respawn in a Co-op multiplayer mission that is purely based upon a Trigger firing when BLUEFOR is present. I'd like to have several of these across the mission area so when the player(s) reach specific points a new respawn point activates. I've been messing around with a VR test mission using various methods, including the one that @Larrow illustrated in this post, but I'm not having any luck at all. I can't get the Trigger deal to work the way I want - it does fire and enable the respawn point, but if I set the Multiplayer Respawn Attribute to "Select Respawn Position" then the player starts the scenario on the respawn screen, and since no respawner has been activated they can't start the scenario (the button reads "Respawns Disabled"). If I disable "Select Respawn Position" then the player immediately respawns after the countdown on my dead body - which isn't what I want, I want them to be able to select a respawn point. If I put two respawns in the test mission, each with a BLUEFOR Present Trigger and "Select Respawn Position" disabled, I can activate both without a problem - but when I die I respawn back on my own body instead. I assume that's due to the "Select Respawn Position" option not being enabled... but again, if I do enable it, I can't even start the mission. And for the sake of being thorough, in the above example, if I also add a respawn icon not activated by anything and set to BLUEFOR, I still don't start the mission normally - it'll still start the mission on the respawn screen, but of course now I'll have a respawner to select. I'm sure I'm missing something really simple - what am I not doing, or doing wrong?

Okay, awesome - thanks a lot! One more question - is there a way for knowsAbout to occur at a distance without the need to Reveal / Lock the target? Or is that just a necessary quirk of ARMA 3?

I don't even know if this is possible, but I'm working on a mission where - I'm hoping - I can create a trigger when the player actually views an object. In this case, it would be enemy personnel, vehicles, helicopters, etc. The idea is that the player uses binoculars, a spotting scope, or a sniper scope to view the object, and once seen it fires the trigger. Is this something that's possible within the scope of ARMA 3 scripting, or is there a better method to accomplish something like this?

Thanks to you both for the info there. I wasn't aware of the HMD command, and "unLinkItem" makes things a lot easier. Thanks!

Oooh man. *facepalm* I never even thought of that. I became so convinced it was a scripting problem or something similar I never considered the possibility that I was making a call to the wrong NVG classname. So, naturally, when I changed my SQF to _soldier unassignItem "NVGoggles_tna_F"; _soldier removeItem "NVGoggles_tna_F"; it worked perfectly. Thanks for that suggestion ProfTournesol. Definitely a lesson learned there.

I've been fighting this for the last couple of hours - I've combed through the forums here and at ArmaHolic with no success. I'm trying to remove the Night Vision Goggles from all members of the Players group (a 5 man team of SF soldiers). This is such a simple thing that I'm stumped why it's become so problematic. Initially, I added the following - which is the standard method - to each soldier's INIT field: this unassignItem "NVGoggles"; this removeItem "NVGoggles"; and this didn't work. Rather surprised, I tried another take on it: this unassignItem "NVGoggles"; removeItem "NVGoggles"; and this didn't work either. So I decided (since I have several changes I want to make to the loadout of each soldier) to create an SQF file and try that. I created a LOADOUT.SQF file, and entered the following into it: // Set Variables _soldier = _this select 0; // Remove Headgear and NVGs removeHeadgear _soldier; _soldier unassignItem "NVGoggles"; _soldier removeItem "NVGoggles"; // Add Booniehat and Magazines _soldier addHeadgear "H_Booniehat_tna_F"; (vestContainer _soldier) addMagazineCargoGlobal ["30Rnd_65x39_caseless_mag",2]; putting this into the INIT field of each soldier. This STILL didn't work. The Booniehats and the added rifle magazines are added, but the NVG's are still there. At this point, I don't know what's going on. I gave some thought to the possibility that my addons could be causing the problem, so I reloaded the game with no addons, and am still getting the same results. It's things like this that make me wish that it was possible to simply edit the loadout of individual soldiers within the Editor itself. Am I doing something wrong? Have I encountered some kind of weird bug?

Hi Beerkan - You, sir, are my new hero. Thank you! It works great!

Hi Beerkan - Thanks for the reply. I don't have any wind speed or direction set in my current scenario (in fact, the scenario I'm using this in is a simple test scenario to get all the functions working like I want before I use it in the scenario in question). I'm not sure where the velocity is coming in - the player's direction of movement is (initially) the same direction that the helo / C-130 is traveling. It changes when the player turns left or right - the velocity will then change to 9:00 (to the left) of whatever direction the player is facing (so, for example, if the player turns to face North while in free fall, the direction of travel will change as the player turns so the momentum / velocity will be carrying them to the West). I tried removing the _x setDir (_dir + 90); as you suggested - that didn't work. Instead of facing 90 degrees to the right of the plane, the player exits the plane 90 degrees to the left (I assume it's facing due North as my plane is flying nearly due East). However, oddly, I found that if I changed that line of the script so that the player exits the plane facing the same direction as the aircraft's heading, like so - _x setDir (_dir + 0); this creates a situation that much more closely resembles real life HALO parachute drops. The player will continue moving forward for a few moments (carrying the momentum of the plane), but then that momentum will bleed off and about 8 to 10 seconds later they will be falling straight down - turning to different facings doesn't cause the player to move forward in any direction at all... which was exactly what I was hoping for. I tested this with other directions as well... 180 degrees for example... and it works the same for the most part with them - but for some reason if _dir is set to 90 the momentum just never dissipates and the player falls with a ton of forward momentum. As a side note, the player can voluntarily move forward (create forward momentum) in the dive by pressing whatever key they have assigned to "move forward," but that's normal so not a big deal (for my purposes anyway). So... if you leave the _dir variable to zero it cancels out the strange velocity issue I was experiencing earlier and creates a more realistic HALO insertion drop situation. That being said, this only seems to affect the player. Regardless of what _dir is set to, any AI members of the player's Group will be carried off into the distance by the same problem (I test dropped at 4800 meters... by the time we hit the ground - chutes popped at 110 meters - my spotter was halfway across Stratis).

Hi Beerkan, et. al. - This is an awesome script, and it's exactly what I was looking for. I've tried several different ideas and scripts that simulate similar air drops and this one fits what I need perfectly. I do, however, have one question. In my case I'm simulating a night HALO drop. As I stated, everything works great - except for the fact that the player continues moving to the left. What happens is that the player exits the plane facing South, and continues moving toward the East (the aircraft's heading is nearly due East). The player does continue to fall toward the ground, but they never stop moving toward the East as well. What makes it even more problematic is that if the player turns while in free fall, their direction of travel will ALSO move, keeping their left side toward the direction of movement. Is there a way to counteract this? What I'm hoping to accomplish is a way to force the player object (and, by proxy, any AI objects as part of the player's Group) to simply fall straight down. The main reason for this is in how the continued forward momentum complicates the area designated as the drop zone (along with some other Triggers that are dependent upon that). I do have to say that the forward momentum, by itself, isn't as much of an issue - it's the fact that the momentum changes direction with the facing of the player that's the real problem, because I could simply move the actual HALO drop waypoint back far enough to counteract the momentum if the direction of movement never changed. I realize that this script seems to focus more on a low altitude parachute drop than a HALO drop... but if someone has an idea how to counter the forward momentum it would be absolutely perfect for my needs.