Couple of questions

[fubarno1 0]

1. Anyone been able to make the helli's make a fast insert?

At the moment irrespective of the condition of the unit the helli's seem to really take their time finding just the right spot to put their baby down (even if its slap bang in the middle of a runway with no objects near by), and gets even worse if they start taking incoming fire if they are already unloading they still take off and the AI continue to jump to their death. I'm looking for something that will let the AI pilot ignore enemy fire and drop like a stone on to the invisible H / transport unload waypoint, dump their cargo of AI and take off again, I have tried setting the pilot to careless/never engage/ flyinheight 0 but it just aint right the pilot still dances in the air while giving "the bird" which antagonizes the enemy AI even more to shoot him down, Its like when they designed the game they have never considered that helli's would have to use hot LZ's. (the game needs a new waypoint condition called "hot transport unload" that gets the helli's on the deck asap and back off the deck asap)

2. How to delete a trigger of a unit not present?

I have a unit that needs to complete a task if he gets killed on the way to that task its end game, but if he makes it through the task I need the trigger that covers him to become disabled so should he die rather than mission over the player can switch to another unit and continue with the mission.

I have a trigger that detects if a building gets destroyed so I suspect I need to add something to that trigger which then disables the trigger that detects the player is alive or not?

[-SPA-LynxEye 0]

I'm starting to think that nobody wants to 'spy' the behaviour of the AI with Hints showing certain variables of AI.

Just use only one chopper, with only one AI (pilot) and nobody more in the mission, except you (in the ground).

Make variables to allocate the values that some commands is related to 'object' players and AI, but only checking it with the AI ones.

Then, show these variables in a Hint space.

Loop constantly.

This is one of the methods to 'spy' behaviour of things in ArmA.

Behaviour, fleeing, combatMode, currentCommand, damage, effectiveCommander, expectedDestination, findCover, formation, formationDirection, formationLeader, formationMembers, formationPosition, formationTask, formLeader, getSpeed, glanceAt, etc etc etc

Surely, if you 'playing' with this commands, only to get info about that pilot inside that chopper...you will find some light about AI behaviour in choppers... and then... the behaviour of the vehicles with AI inside...

I see all commands as a seed. I have first to put it inside the ground, then i will start to throw it a little bit of water sometimes.

Then... the whole tree of the knowledgement will grow in front of your eyes (if you have some patience) while you keep throwing it water.

I suppose with this simile, that all of us are gardeners, and there is only one tree of knowledgement in ArmA.

And mostly of times, we are 'patching' issues, not discovering those pretty little pieces of the tree...

Then... why to blame on BIS about its patches, if we are doing just the same...

[fubarno1 0]

Sorry [sPA]LynxEye I realise English is not your first language but

What the fuck are you on about?

I'm asking if anyone knows a faster way to insert troops with helli's and your giving gardening lessons

Back to the subject at hand.

It would seem that the transport unload waypoint is hard coded to force the helli back up to around 25 meters then it goes through finding just the right spot and a nice gentle touchdown.

I have been experimenting with a getout command for the units dropping the transport unload waypoint but even that is still hit and miss, I'd like to know if there is a command for kicking the whole group out at once I have tried the following that seems to work

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">ch1 flyinheight 0; p1 action ["getout", ch1]; p2 action ["getout", ch1]; p3 action ["getout", ch1]; p4 action ["getout", ch1]; p5 action ["getout", ch1]; p6 action ["getout", ch1]; p7 action ["getout", ch1]; p8 action ["getout", ch1]; p9 action ["getout", ch1]; p10 action ["getout", ch1]; p11 action ["getout", ch1]; p12 action ["getout", ch1]

but it sometimes kicks the units out before the helli has touched down.

I ain't no coder (never will be) and most of what I read goes whoosh over my head, but there are some things I do manage to catch a hook into and can maybe understand why it does what it does but not how it does what it does (I'm too old to take it all in) so any help from at a layman's level would be appreciated.

Re: trigger disabling I am using the following code which seems to work (well i didn't get the end mission once I ventilated his head so something must be working right ).

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">lose1 triggerAttachVehicle []

activated from the trigger that detects a object destroyed, maybe one of you scripting guru's can confirm this is an acceptable command, or maybe you know a better solution?

[-SPA-LynxEye 0]

Sry about my way bad last help.

Taking this as a reference:

Quote[/b] ]ch1 flyinheight 0; p1 action ["getout", ch1]; p2 action ["getout", ch1]; p3 action ["getout", ch1]; p4 action ["getout", ch1]; p5 action ["getout", ch1]; p6 action ["getout", ch1]; p7 action ["getout", ch1]; p8 action ["getout", ch1]; p9 action ["getout", ch1]; p10 action ["getout", ch1]; p11 action ["getout", ch1]; p12 action ["getout", ch1]

Try this:

Quote[/b] ]but it sometimes kicks the units out before the helli has touched down.

If this last is your main problem, name that chopper and launch all that statement with something like this:

- first, get the position of the chopper.

- if the Z of the chopper is < 2, 'launch' that piece of script.

- if you looping this, i am supposing that your chopper only will eject your troops from -oo meters to + 2 meters altitude.

2 meters of altitude is a safe altitude to 'start' to eject troops, because, nobody will be wounded from 2 meters... or at least, no more 'damage' added to nobody. Just... maybe... strange issues with players/AI that can't walk (hit leg/legs) when ejecting from 0.5m - 2.5 meters. More or less.

_posChopper = getPos Chopper

_altiChopper = floor (_posChopper select 2). Or change floor by 'round'... can't remember.

? _altiChopper < 2 : goto "RunYourPieceOfScriptIQuoted"

Of course, you can choose '0 meters' as the 'max. altitud' when troops starting to be ejected.  

Another thing, remember that the minimum allowable altitude to fly with flyinheight = 20. See Wiki about the note UNN made.

http://community.bistudio.com/wiki/flyInHeight

So... if you 'forcing it' to 0... it's normal that 'sometimes' your troops trying to suicide.

Well, maybe this is your real problem:

- When you setting "flyinHeight 0" it doesn't mean that the chopper is being put automatically at 0 meters at that moment. I suppose the chopper will start to try to reach 0 meters altitude.

- So, from your first statement, troops will start to jump out... and yes, not always at 0 meters... in fact i guess... difficult to eject them at 0... maybe at 5... 10... 2... 0.8... if i'm not wrong.

Just think about to check the altitude of the chopper, before to eject troops...

I forgot this too:

as never tried to use flyinheight, i don't know which kind of altitude can be set, if normal, or ASL.

If normal, keep on mind always, that normal altitude can be 'interferenced' by buildings, trees... etc as example:

The 'real ground' as 0 (never is exactly 0... always like 0.34126346 or -0.283764832463 etc).

If your chopper is exactly 5 meters over the roof of a gas station, if we suppose that gas station has an altitude from roof to ground of 7 meters (as example), the NORMAL altitude will show 'altitude' of chopper = 5, not 12.

So, as ArmA is not providing the 3rd altitude referred to the real ground or at least to the nearest surface over water, ground... then you have to make a different way to check 'real' ground referred checkings to your air vehicles.

1st. GetPos of your chopper.

2nd. Convert the altitude (Z) to 0.

3rd. Check the same coordinate but with 0 altitude in nearestObjects with radius... hum.... radius... 14... maybe near 20. Radius is 3D, more or less as a radar in films showing in screens. Checking the content of a 3D ball.

Please, if radius is not being checked as 3D, correct me, i think is 3D. It means, i think radius is started to be metered from the real center of a ball, and then radius can be horizontally metered... and vertically too... making it 3D.

Keep on mind too that checking positions of players, vehicles etc... with 'distances', 'nearestobjects' and many commands... you must first to know where is the 'real' coordinate as origin inside a vehicle. Not all vehicles has his reference where 'we can think they are'. I think ArmA is checking first the origin coordinate, and then, starting to check boundaries to detect objects 'touching' others.

Then, if you detecting some 'building' (or trees...etc etc) objects in the radius (horizontally and vertically) from 0-20 meters... probably, you will have a building below the chopper, that can compromise your 'insertion', because the AI will try to make your wish-flyinheight, but probably... or will stop in the roof of a building, and worst cases, trying to touch the top place of a tree etc etc...

I think that chopper never will 'touch' the roof of a building if you are trying it with flyinheight. If flyinheight altitude is referred to normal position Z, nope, if is referred to ASL position Z, yep, is possible to land 'AI' choppers in roofs.

This method is more or less like a vertical (to ground) radar of trees... buildings... etc, what you want to 'detect', no matter what altitude is flying the chopper. Then, if you refreshing that radar... will be one good way to 'detect' early errors... and then is allowing you to 'prevent' it with a few more lines of script.

If flyinheight altitude is ASL, then i can understand perfectly why your troops is ejecting (exactly as you said 'sometimes' not at 0 meters. Because 'our human' 0 meters is not always ArmA meters.

I suppose that if a couple of people (me too) having certain 'weird' issues with positions , is because ArmA is a 'great reallistic' game... and sometimes we forget that their commands is referred to ArmA concepts... not exactly always 'our real world' concepts.

ArmA is a game, not the real life, so test the 'real' concepts of ArmA when you having errors.

It means, if you learn the brain of ArmA, you can move your brain so close to ArmA one... and then... you will reduce a looooooot of 'strange' events.

One thing i forgot too:

Try to use 'eject' instead 'get out'.

Search in wiki for 'eject' as action, not command.

http://community.bistudio.com/wiki/ArmA:_Actions#EJECT

Parachutes will be automatically opened when ejecting from certain altitude referred to nearest 'object'. And when i'm saying 'object' can be the ground itself. I can't remember that 'magic number' of altitude when the parachutes is opening.

Sometimes i noticed that if you starting engine in a plane, and then choosing 'Eject' via 'menu action list', sometimes, you will be effectively jumped out to high altitude and then parachuting down to ground, but sometimes the player (maybe AI too) is at ground level with parachute opened doing some 'dance' lolol. Probably ArmA only is taking into account the speed of the object from you are ejecting to 'start' this kind of animation-behaviour.

Obviously, not only the speed is being 'checked' by ArmA, but i think, they not programmed this with more physical parameters.

I'm not saying that BIS programmers are not 'pro'... just i think they did'nt noticed this issue... or maybe yes.

Another last question:

The main difference from setPos and FlyInHeight with air vehicles is this:

- setPos will set 'instantly' the vehicle in the set coordinates.

- FlyInHeight, is not an 'instant' command, because it has inside a lot of 'priorities' and 'behaviour' to be checked first by ArmA internal code before to put your air vehicle into your desired height (always if possible, never as a fact, or an order).