Set a variable when chopper height is <3 m

[rekrul 7]

How would I do that? In my script, I want to use this to know if he has "landed" (hovered) yet. Meaning if I order myChopper land "GET OUT"; and then change the variable, it would be changed before the landing has happend. I want to wait until people are starting to get out (or in) before changing the variable but how?

(getHeight seems to be VBS2 only.)

[jw custom 56]

I think you could use this:

_height = (getPos _heli) select 2;

if (_height > 0.2) exitWith { hint "Heli not on ground" };

[rekrul 7]

Great thanks! I think I'll try it with waitUntil though, so the script is halted until it has landed.

Edit: Hmmm, I have to run a loop so I check the height continuously though. I'll figure it out.

[jw custom 56]

Something like this:

while {true} do

{

_height = (getPos heli) select 2;

if (_height > 0.2) exitWith { hint "Heli not on ground" };

sleep 1;

};

[shuko 59]

What's wrong with?

waituntil {(getpos heli select 2) < 3};

[rekrul 7]

It's not complex enough. :D

I was on: while height < 3 do getpos heli thing but yours is obviously so much better.

---------- Post added at 11:36 PM ---------- Previous post was at 10:28 PM ----------

Hmm, this is weird...

This is (part of) my script:

hug_pilot sideChat "Get ready, I'm putting her down!";
hug land hug_action; 
waitUntil {(getpos hug select 2) < 10};
If _tmp_Hug_Cargo then 
{	Hug_Cargo=True;
hug_pilot sideChat "Hug_Cargo - TRUE"
} 
else 
{	Hug_Cargo=False;
hug_pilot sideChat "Hug_Cargo - FALSE"
};

But hug_pilot never says anything. I made a radio-trigger with a waitUntil command, but then Arma2.RPT reported "Suspending not allowed in this context" so I made this radio-trigger instead:

_tmp=If ((getPos hug select 2) < 10) then {hug_pilot sideChat "Under 10!"} else {hug_pilot sideChat "Over 10!"};

And this one reports over and under accurately. So what's happening with my script?

Some variable explanations:

hug_action: String. Either "GET OUT" or "GET IN"

hug: Object. My UH-1Y

hug_pilot: the pilot of the chopper

Hug_Cargo: Boolean. For telling me if there are personell on board or not

_tmp_Hug_Cargo: Same as above, except I don't want to change Hug_Cargo until after chopper has landed. I tried using Hug_Cargo = _tmp_Hug_cargo; but that doesn't work for whatever reason (probably me, been testing too many workarounds at the same time).

I'm thinking maybe I should just check how many are on board instead (how do I do that?). My boolean seemed like a quick and simple solution but I keep digging myself a bigger hole it seems.

[jw custom 56]

But hug_pilot never says anything. I made a radio-trigger with a waitUntil command, but then Arma2.RPT reported "Suspending not allowed in this context" so I made this radio-trigger instead:

hug_pilot sideChat "Hug_Cargo - TRUE";

hug_pilot sideChat "Hug_Cargo - FALSE";

Dunno if this is your problem!

[shuko 59]

"Suspending not allowed in this context"

That means you are trying to sleep/wait in the main game thread, which is not allowed as it would halt the whole game. You have to create a new thread for it (using spawn or execvm).

[rekrul 7]

hug_pilot sideChat "Hug_Cargo - TRUE";

hug_pilot sideChat "Hug_Cargo - FALSE";

Dunno if this is your problem!

Nope, the } is right after so that closes it the same way. I've actually encountered problems by having ; infront of }.

"Suspending not allowed in this context"

That means you are trying to sleep/wait in the main game thread, which is not allowed as it would halt the whole game. You have to create a new thread for it (using spawn or execvm).

Yeah well, this was just a radio-trigger to test my statement. The same statement is in the .sqf I posted above, where it doesn't work. :)

[shuko 59]

hug_pilot sideChat "Get ready, I'm putting her down!";
hug land hug_action; 
waitUntil {(getpos hug select 2) < 10};
waitUntil {(count crew hug) < 2}; // change if there are gunners onboard
hug_pilot sideChat "Good luck, I'm leaving!"

[rekrul 7]

Thanks shk, I think checking for crew is better.

And I figured out what the problem was. The wait command worked fine (i put a hint after it, which displayed), the problem was the if-statement later I thought local variables meant local within the function which established it (as in my script) but it was actually only within my first if-statement (which I didn't include here) so the "If _tmp_Hug_Cargo then" check stranded since _tmp_Hug_Cargo didn't exist anymore.

Well, you live and learn. Thanks for everyone's help though!

Edit: btw, is there a way to eject the passengers from the chopper? I'm thinking if it's a hot LZ and someone gets injured, AI won't get off on their own.

Edited November 27, 2009 by Rekrul

[shuko 59]

// nul = (units myGrp) execvm "eject.sqf";
// nul = [p1,p2,p3,p4,p5] execvm "eject.sqf";
{
 if (vehicle _x != _x) then {
   unassignvehicle _x;
   [_x] ordergetin false;
   _x action ["eject", vehicle _x];
   sleep 1;
 };
} foreach _this;

[rekrul 7]

Thanks again. :)

I've been struggling with my script a bit. I have triggers and scripts where I can mark the LZ, the chopper lands ("GET OUT") and everything works fine on "cold" LZs. When it's a hot LZ, it's a different ballgame though. What happens is that it starts ejecting people, but after 1 or 2 (while taking fire) it lifts up and keeps ejecting crew, injuring those who are below parachute height, but I can't understand why.

First I have a trigger with this condition:

((getpos hug select 2) < 3) AND ((count crew hug)>1) AND (hug distance getMarkerPos "huginn_base">100);

Hug is the chopper. huginn_base is a marker in base and I have the last check there to make sure it isn't in base, e.g. on mission. In the On Act. field I have this:

nul = (crew hug) execVM "hug_offload.sqf"

hug_offload.sqf:

titleText ['Unloading passengers','plain'];
while {((count crew hug)>1) AND ((getpos hug select 2) < 3)} do
{	hug_pilot sideChat 'Yeeeehaaaaa!';
{	if (group _x!=huginn) then 
		{	unassignVehicle _x;
			[_x] orderGetIn false;
			_x action ['eject', vehicle _x];
			sleep 1;
			_x sideChat 'Out'
		};
} forEach _this;
};
waitUntil {(count crew hug) < 2};
If (alive hug) then
{	deleteMarker 'LZ_hug';
LZ_marker_hug=0;
deleteWaypoint [huginn,1];
_var=huginn addWaypoint [(getMarkerPos 'huginn_base'), 0, 1];
hug_pilot sideChat 'This is Huginn, RTB!'
}
else
{	hint 'Huginn has crashed!'
};

Huginn is the pilot group. hug_pilot is the only member in Huginn.

As I said, it works fine on a calm LZ, but when the pilot lifts up and flies away due to incoming fire, it keeps ejecting passengers. Is it queued or something? I would think that the while-loop made sure it wouldn't eject when it was over 3m and that it constantly checked?

[shuko 59]

Welcome to the world of Arma AI. ;)

Your script will start ejecting people when its below 3m and will continue until all the units from the group are out. The height checking while-loop only needs to pass once and everyone will be ejected.

[nomdeplume 0]

You might want to try setting the helicopter's landing WP behaviour to "CARELESS", which will result in them completely ignoring the enemy - I think this is about the only way to get an AI chopper to behave reasonably in a hot LZ.

You also might want to look at assignedCargo which might be slightly better for your needs than "crew".

To prevent ejections once the chopper becomes airborne again, you'd want to move the altitude check from the top-level while loop to the check of each individual soldier. Your current script checks the helo is low enough, then loops through every crew member and ejects them at 1-second intervals. If there's a lot of crew members, this will take a while. It doesn't return to the condition of the while-loop until it's finished processing the forEach.

[rekrul 7]

Welcome to the world of Arma AI. ;)

Your script will start ejecting people when its below 3m and will continue until all the units from the group are out. The height checking while-loop only needs to pass once and everyone will be ejected.

Ah that makes sense actually. I guess I was hoping for a sort of interrupt-signal when the while-condition wasn't true anymore, but that's way too optimistic. :)

You might want to try setting the helicopter's landing WP behaviour to "CARELESS", which will result in them completely ignoring the enemy - I think this is about the only way to get an AI chopper to behave reasonably in a hot LZ.

Well, I kind of like the challenge you get with a hot LZ and part of the mission success is that the choppers survive. My second problem is that I've set the LZ as waypoint and when the pilot panics, it has no instructions where to go so I got to figure something out for that.

You also might want to look at assignedCargo which might be slightly better for your needs than "crew".

But some of the guys there are in gunner and observer positions (UH-1Y) so I'm not sure if they'll eject but I'll try - thanks! (Then I can skip the huginn-check.)

To prevent ejections once the chopper becomes airborne again, you'd want to move the altitude check from the top-level while loop to the check of each individual soldier. Your current script checks the helo is low enough, then loops through every crew member and ejects them at 1-second intervals. If there's a lot of crew members, this will take a while. It doesn't return to the condition of the while-loop until it's finished processing the forEach.

Yeah, when that's the behavior I can see it wasn't the best of choices. :) I guess the same thing goes for the "condition-field" in the trigger? The second check is after the script is finished?

[nomdeplume 0]

Ah that makes sense actually. I guess I was hoping for a sort of interrupt-signal when the while-condition wasn't true anymore, but that's way too optimistic. :)

If while-loop is basically just a repeating if-statement, i.e. the condition is checked, and if it's true, then the code block is run. After the block is run, the execution flow jumps back up to the condition, where it's checked again. So on until the condition evaluates as false.

If you want to short-circuit a loop, you can use exitWith.

Well, I kind of like the challenge you get with a hot LZ and part of the mission success is that the choppers survive. My second problem is that I've set the LZ as waypoint and when the pilot panics, it has no instructions where to go so I got to figure something out for that.

Not really sure what reasonable behaviour you could put in place; generally pilots avoid hot LZs like the plague, but if there's no choice then the only thing for it is to get in and get out as quickly as you can, and hope and pray for the best. All comes down to luck, really. I think we stopped using hot LZs after Vietnam though...

You could perhaps have two LZs, the one you pretend you're using (the hot one) and one you actually use (less dangerous) - then have the pilot approach the hot LZ, and after being fired at abort and go to the other one.

If you really want to land at the hot one, I think CARELESS is your best bet in that it'll get the pilot to land without getting nervous and flying off after dropping off half the tropos, which is pretty useless behaviour for both the pilot and the poor understrength team now on the ground. You could also look at using setCaptive to prevent the enemy from firing at the helo, or use addEventHandler to add a "HandleDamage" event handler which prevents the helo from receiving damage (at least to critical locations, such as the tail rotor) during the insertion, so it feels exciting and dangerous but doesn't result in frustrating random deaths and mission failures outside of the player's control. You might need to handleDamage for the pilot and other critical people in the helo though, in case they catch a stray bullet.

But some of the guys there are in gunner and observer positions (UH-1Y) so I'm not sure if they'll eject but I'll try - thanks! (Then I can skip the huginn-check.)

In that case it probably won't do what you want... at least for this insertion. But maybe for others it'll come in handy. :)

I guess the same thing goes for the "condition-field" in the trigger? The second check is after the script is finished?

Not sure what you mean by the "second check"... triggers have three fields for scripts, the condition, "on activation", and "on deactivation". Normally you don't use the deactivation. The "condition" part runs continually (twice a second or something?) and once it becomes true once, the "on activation" scripting is run. Unless the trigger is set to "repeatedly" (instead of "once" - one of the button options near the top of its properties display), that's all the trigger will ever do.

If it's set to repeatedly... I'm not entirely sure, as I've never used that for anything other than radio things for test purposes. I think the condition would continue to be evaluated continuously, and once it becomes false the "on deactivation" script would be run - at which point it would revert to its starting behaviour, i.e. checking the trigger condition until it becomes true.

[tj72 0]

I made a couple scripts for helis in Arma so just some comments and advice based on what I learned during the process.

Its not uncommon that you start a simple setup with a script that works well initially but over time using it you find it needs something more. You have to add alot of code to avoid particular things that happen that break things just like the falling thing here. The AI has a knack for screwing up your best made plans so I always had to make extra checks to make sure the AI wasn't getting stuck or screwed up somehow.

I think you should set behaviour to careless because you have the script to controll the AI behaviour and dont need the meddling from the AI fsm. That way the pilot shouldnt take off like that. Its better when the AI doesn't try to do too much (Careless vs Aware) so you dont have to spend more time checking and fixing some weird behaviour that breaks your script all over again.

You have to expect and handle a time when pilot/chopper is dead or cant fly somehow and exit out of everything if that happens. You dont want any scripts hanging forever if the "mission" of the script is dead.

If you want to make it abort the landing you have to add more sections where you check damage or add hit EH and go down that way. I guess if the chopper started taking hits before or during landing at LZ you could use that event to trigger an abort procedure. I would want it to weight that decision though so it doesnt run away from a guy with a pistol. So you can see how expanded things may get as I was saying at the beginning.

Hope that helps...

Edited December 1, 2009 by TJ72

[rekrul 7]

Thanks for your input guys. Part of my "problem" is that I want the pilot to be AI or a MP player so I try to take into consideration everything that can go wrong (heh). Right now, I'm thinking that if the heli was below 3m but not anymore, and still has cargo - it was a hot lz (if empty, it RTBs). The idea when a hot LZ is encountered to RTB and tell the rifle squad leader to pick another LZ. That's all fine, but when the trigger aborts the scripts, and then is re-triggered it seems to pick up where it left and at the same time launch another instance of the script which is really challenging.

In the end, I want the player assigning LZ to make a tactical correct decision or suffer consequences (e.g. splitting up his team).

As TJ said, these things require a re-structure of the script so I think I eventually have to cheat and make a flow-chart. :( On the other hand, I am making this mission to learn scripting (or editing in general I guess), so I doubt I'll ever release or even finish this one. :)

[nomdeplume 0]

Are you making sure the script exits when things go bad?

If all else fails, and assuming you're using execVM, it returns a handle to the script which you can use to kill the script from another part of the game. You can use setVariable and getVariable to store the handle as a variable on the heli and then retrieve it again elsewhere in order to kill the already running script. Probably better to make sure your script can detect when it's no longer needed and bail out, though.

Your best bet if you want to make it AI or player-controlled is to come up with a "one true plan" and set up the AI to do that, but keep in mind your player might do something else. Also remember you can use isPlayer driver heli to check if the pilot is a player or not, so you can set special things for the AI but leave a human pilot to fend for themselves.

I've never tried seriously to get an AI to land under fire, but in one scenario I had, I wanted a low-level dropoff using a small mountain as protection from a set of AA launchers. I set up waypoints for the AI that worked 4 out of 5 times, but every now and then it'd go a little bit high (usually on egress) and get shot down. I worked around this by using setCaptive on the heli if it was AI-controlled, so the enemy would ignore it if it did go a little bit high, then once it was back to a safe position I'd turn that off. If a player is flying, then that cheat wasn't enabled so the player just had to keep low on their own.

This way if you're playing with an AI heli, you get a good gameplay experience; but if a human is flying, then they also get the exciting insertion you were aiming for. And ultimately that's what it comes down to, so cheat if you have to in order to ensure the right game experience.

Also -- if you intend to have your missions work in multiplayer, I'd try to test every single thing, ideally with both a dedicated server and a player-hosted server. I've not made/tested a MP mission, but if you read the info in the wiki and elsewhere you'll see there's lots of things that work slightly differently in MP so it's probably best to get a handle on them early on, rather than trying to fix up a complex mission after you've spent ages making it.

[rekrul 7]

Ah the isPlayer would surly save me a lot of headache!

Yeah, currently I'm not focused on the MP-tweaking (which I fear and expect to be massive), that's "phase 2". ;) Currently I'm using both SOM and ACM which I predict will be trouble in MP.