Scott is correct. I made little script (attached) that allows grass to be cut in a rectangular area between two markers: grass_top and grass_bottom. "Land_ClutterCutter_medium_F" and "Land_ClutterCutter_large_F" work while "Land_ClutterCutter_small_F" does not.

Still not convinced this is doing anything?

Oh, the dream of suppressed eventhandler has been hanging in the horizon for a long time. If only such command was ever realized. Small amounts of Ai could bring players to their knees. Machineguns would take their place among the kings of guns. Dirt would be hugged by so many that the ditches on altis would be filled with players.

Added a repro mission + steps.
This issue seems to also affect some of the buttons on the pause menu dialogue.

Please re-open this issue and remove fixed status. Issue persists in Arma 1.44.130654. The BIS_fnc_codePerformance call completes and the result dialogue displays, but it is impossible to close the dialogue until the external script load completes.

The script load in my test mission is a large looping script execVM'd inside init.sqf. I will try to create a new test mission with a less exotic load script, then retest.

The issue was caused by script load external to BIS_fnc_codePerformance, ie other scripts that happen to be running when BIS_fnc_codePerformance is called. The actual code being tested by BIS_fnc_codePerformance can be trivial (eg: random 1).

I will investigate if it is still an issue again...

This issue persists in dev build 1.43.103502

"Performance Test Result" dialogue opens, but cannot be closed. The only way to exit this state is wait until the external script load completes, or to force close Arma (alt+F4).

Seems to be caused by a high CPU load terrain metadata script which is running in parallel, but is unrelated to the BIS_fnc_codePerformance call. I can only guess the scripts are somehow sharing a local variable or the script engine is overloaded.

I will try to create a repro mision using a dummy script.

I think they should add an idiot proof feature. The first 1-10 times it runs through the code, if it notices it takes a long time it should not proceed or warn the user about proceeding to 1000 cycles. It could approximate how long the code takes in those 1-10 cycles and how long it would take to run the 1000 cycles.

Also, I see in the last 1-2 years you haven't managed to get that repro mission/video...

The function now quits early if the code is too heavy when used both from the speedometer button and as direct call to BIS_fnc_codePerformance. Going to resolve this unless someone has objection.

Afaict this has got fixed by the target and ammo selection improvements over past months.

Thank you you for your help here!

Disregard my last post, it seems I didn't wait long enough. It just takes a lot more time. If a unit is alone, it takes 15 seconds until he preps his AT weapon.

Edit:
Prone stance is not an issue. The AI won't shoot in the repro mission even if you put 'this setUnitPos "MIDDLE"' to its init field.

I can't repro That. My guys engaged EVERY time. You should do a repro mission of that situation too.
I tried AFV's, Marids, differend locations, 1-12 AI's and every time they destroyed it.

And yes, I noticed that the alone AI-AT does engage too. He just waits a bit longer, when the target is APC.
So, being "alone" is not an issue, not using launcher at APC's is not an issue.

But the rooftop placement May be an issue:
In some cases, if the AI goes prone, he loses the line of sight to the vehicle. When alone, he is not ordered to engage target that, when grouped, someone in the group would see.

If you move the AT guy on top of the "Barracks (New)" building near the one in the repro and near the edge, give him 8 meters elevation, facing south, move the AFV south facing away from the AI, so the situation is like in the repro - but now he sees the AFV when prone: wait few seconds and the AFV goes boom.

@AzzurF
Can't repro. I added 1 AT specialist to the same groud and they were unable to engage the vehicle.

Placed a dozen or so AT specialist to one group and put them on the runway. Placed AFV in front of them and not even one wanted to do something else than just lying on the ground, aiming the vehicle with their rifle.

I'd say it's quite a flaw if NATO/AAF don't have even one single AT weapon that can be used in such situations against wheeled vehicles. RPG-42 is the only weapon in the game that the AI can use.

A SINGLE AI-AT soldier doesn't attack Marid/Gorgon/Marshall on his OWN if not being attacked or discovered.

2 or more AI's in the group, and AT WILL attack them even if not discovered.

The issue is only with single unit "groups".

The problem is that AI does not want to engage targets until discovered by enemy.

Only typing "veh reveal this" into units init (veh = target) makes AI start engaging the target - choose proper weapons, etc.

Desired effect is - after some time AI should engage target and return to hidden position.

Armed with PMCL or Titan the AI wouldn't attack the Gorgon or Madrid. OPFOR with Titan wouldn't attack the Marshall, but with RPG would attack the Marshall. OPFOR Titan vs other armorded units did attack.

Maybe an issue with using AT vs the light APCs? Seems it's vs wheeled vehicles.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Hello,

this bug should be fixed in upcoming Steam Dev patch (this or next week), unless you report otherwise, I am stating it as fixed.

Thank you

Can still reproduce in 1.14

As this is fixed now and #14929 is closed you can close this issue.
(Using the close button next to 'monitor')

26-09-2013 Sochor and Scorcher dangerous recoil fixed

oh thanks for the info

wasn't sure if someone already reported this, my bad

couldn't find anything relating to it when i searched

duplicate http://feedback.arma3.com/view.php?id=14929

@Spam that issue exist on almost all planes. I think they are aware of it.

02-02-2016

Added: New script command flyInHeightASL

https://forums.bistudio.com/topic/140837-development-branch-changelog/?p=2974549

All military/commercial aircraft has always 2 altimeter types on board.
There is one more issue with AI - if you give it some large airplane it will make turns like crazy, turns that has too high angels for heavy airplane such as C-130. I'm not sure if there is a ticket, I hope it will be fixed over some time.

REmoved downvote but just one regret: using bad terms. Altitude is above sea level (QNH reference), height above ground (QFE). But Arma doesn't care with real terms... As wind direction, 180° wrong because blowing "to" direction and not "from" like in any weather forecast.

Voted up, this military game really needs a command that allows AI to fly stable. It's very frustrating not be able to jump from an AI plane !

You can drastically damper the terrain following and almost reach the aim with this little script (in init field of an helo):
0 = this spawn {

_h0 = getTerrainHeightASL (position _this);
while {alive _this} do {
  _h = getTerrainHeightASL (position _this);
  _this flyInHeight (400 + _h0 - _h);
  sleep 0.2;
};

};
Change 400 for the height above your start point you want. Helo will smoothly keep the altitude (height + terrain height on map cursor).
Tested in Takistan mountains. C130 is more difficult due to his flight model I guess.
sleep 0.5 is working also for helo.

I tried to add a height prediction with:
_h = getTerrainHeightASL (_this modelToWorldVisual [0,speed _this/0.72,0]);
without significant improvement.
I tried also something onEachFrame with:
["autopilot", "onEachFrame", { _h = getTerrainHeightASL (position vehicle player);
No more improvement. So I "Keep It Simple Stupid", waiting for a BI command.

This will be nice

Since this dovetails with my posted issue about Zeus(debug=1) and the inability to get helos to obey any altitude commands between 10 and 49 over terrain (works fine in VR)... I'll upvote in the hopes that this will all be solved in one change.

http://feedback.arma3.com/view.php?id=24603

Killzone Kid is on the right path here.
Dev team should just move the extended "flyInHeight" command from VBS2 to ARMA.

Syntax: object flyInHeight [altitude,mode];
Parameters:

    object: Object - Aircraft
    altitude: Number - Flying altitude in meters.
    mode: String - "ASL": altitude above sea level, "AGL": above ground level.

Return Value: Nothing

Example: _AiPlane flyInHeight [100,"ASL"];

Using current method gives me a bad headache and sometimes epileptic seizure (try on Stratis).

Up voting

I think the *flyInHeightASL* would be a better name(as i see this is the naming convention). The vehicle should fly in the see level and only change altitude when there is some obstacle in that height.

I tried once continuously change the value with flyInHeight, but it's impossible, because they don't fly forward all the time with constant speed. I made a roller coaster! :D

OK, in real life:
height is above sea level or terrain. Easy to avoid crash in arma, works like a radio altimeter;
Altitude is above sea level (for low profile, steady altitude allows collision with ground!);
Flight level is in hundreds of feet and every one at the same standard barometric reference (1013 mBar)to separate traffic. Not really needed in Arma

let a AI chopper fly over Stratis and set flyinHeight to 300... now enjoy the rollercoaster.

whats the problem to set the heighest ground value into a variable and if flyinHeight > this VARIABLE use constant height over Sea.

No! I downvote because you want to break a useful terrain monitoring (flyInHeight) for a autopilot altitude keeping mode.
You need a flyInAltitude (above sea level). Let flyInHeight for height above terrain (or sea)

Alternative command... who cares, we need anyway to do this. Let it call flyInHeightASL and flyInHeightATL

+1 !! FlyHeight based on terrain is stupid.

the lack of ASL reference for ai controlled aircrafts is making waypoints very chaotic, with constant altitude variation.

Like cyrilator said the AI waypoint following is vey chaotic. It is impossible to make planned flight path, because AI always follow the ground level and constantly lift up and down. It's flying like an idiot.

A command "unit flyInHeightASL height"would help us to force AI fly in smooth horizontal path, sometimes near the ground(over the hill) like players do.

some duplicate of : http://feedback.arma3.com/view.php?id=14194 (please up vote it also ! thanks )

Upvoted even it is a duplicate because it is very annoying. NO AMSL indication and NO possibility to set constant level flight for AI.

you should change this ticket to request alternative flyInHeight [array] implementation like in VBS2 http://resources.bisimulations.com/wiki/flyInHeight

At the moment A3 supports only SCALAR as param

Would aircraft in real life have indicators showing height above sea level and height above the ground?

*Progamer*
Most aircraft have barometric altimeters that can measure altitude from a set reference altitude, mainly sea level.

this is the standard way of telling altitude in an aircraft, always has been.
some aircraft such as Su-25 and KA-50 (that i know of) use both a barometric altimeter and a radar altimeter. the radar altimeter is used to measure altitude above the ground but is rarely used as a reference point for flying height.

I assure you that many if not all fixed wing aircraft use height above sea level as a reference point for flying. Many military aircraft rely heavily upon level flight for proper ordinance delivery. most modern aircraft will not allow the pilot to release a weapon from its pylon without proper flight parameters such as minimum bank angle, minimum altitude etc.

It is 100% realistic to implement a system like this as it has been standard from many, many years and isn't likely to change. Adding this system would defiantly benefit the reality and game play of arma3.

just do some searching, you will see :)

Killzone Kid was saying about AllInArma mod. Search, download, enjoy! Its allprevious arma content in one 13GB pack, including factions, weapons, islands and vehicles

One big con is that you will get kicked from multiplayer server if you play with non-official content.

Because of that I prefer to play with vanilla content and really hope, the developers may find some time, to convert, update and integrate all previously released Armed Assault/ARMA 2 and Operatin Arrowhead content to ARMA 3.

Related to #0027022

+1 to this. Would make joining servers at a lot easier. I've not played in certain communities because I can't find the correct map mod and it's so frustrating.

@tyl3r99

Still it won't be official content.

you do know that BI do not have the time or resources to "port" over all the other content right... let alone test it all works

however the community has already started doing this..

stfu and take my money. What arma 3 really needs now is official content. Mods are really great, and allows the community to take the game and run with it, but the drawback is that to play together, people need the same version of the same mod. If everyone had the same officialy ported, auto-updated version of the A2 maps, there wouldn't be conflicts = easier for people to play on one another's servers.

Distractor, you would be implying BIS actually try to make something good.

BIS should create the original content for free instead of having us pay for it.... you know, just like how they did in OFP, ArmA, ArmA 2, ArmA OA, etc.

Takistan, Zargabad, Chernarus+
Plus all those vehicles....YES I'D PAY.

+1 Maybe what the developers should do is "outsource" porting content to Arma 3 from previous releases, from OFP to Arma 3 OA, then quality-check modder submissions, and/or have a contest to reward players for the best content like the Make Arma Not War contest . The end result should be free DLC for Arma 3 Supporter Editions and very cheap DLC for the rest. Just my suggestion.

Yeah, give them another idea on how to make more money from you. You want ARMA 2 stuff then play ARMA 2, You wont have the stance system (unless you download SMK's animations) or some badly done physics elements but mods make up for everything else.

They said they won't do it.

Free DLC could bring more people on ARMA.

You don't have it for free. A2 assets are not compatible with A3, they need to be converted and adapted, and this takes time and labour.

Actually killzone, yes, they are compatible, buggy, but compatible.

This is why it has to be a DLC and paid one as well.

+1 Sample models released are not the droids we are looking for

I'm pretty sure that would be a LARGE DLC pack... anyways I wouldn't want to play with OFP tanks in ArmA 3, it would look ridiculously outdated.

However I get what the OP means, mods are great, but good luck finding a populated server that is running specific mods.

The problem is that all the content would need to be updated to ArmA 3 standards, otherwise it would be a mess. Tanks need to have armor defined in their models, weapons now have to be adaptable to attachments, etc.

Why would you guys pay for content you already have for free?

SHUT UP AND TAKE MY MONEY!

I would gladly pay for a Sahrani in ArmA3 the sunny awesome Island... Or for other Takistan, to represent the modern battlefields.

Having them into ArmA3 without the need of downloadning tons of gbs, and also problems with versions,bugs,closed communities, and having the ability being:

USMC,US Army, Russian, Spetnaz, Chdk, CDF, RACS, Takistani, BAF, Takiban or my personal favourite the fondamendalist SLA would be just awesome. All those eras all those weapons and modules, the abilities are just LIMITLESS.

Since arma3 is out and dayz is coming soon, noone is going to spend money on ArmA2 let alone, ArmA1.

So I belive this addition is a must-buy.

BIS is always about the community I belive they are planning something like that. If they would gave us the official support of their ex-games the abilities will be... unimaginative