Rydygier

On that, if anyone's interested... Tried was models 4o and 03-mini, I believe. Result was... poor. In rough shape it was resembling a neat, simple code, doing heli transport. But there was key problems in the aspect of the syntax (non-existent command used), logic structure (local variables used out of its scope) and design (oversimplification, it was possible to call heli while it was already busy, temporary mouse actions not cleaned up, special situations not handled, code oblivious to Arma's AI limitations and quirks). It was semi-working sketch at best. Probably GPT could do better with languages providing wider training data base.

The priority here was code simplicity, hence there are certain limitations, otherwise we would simply gradually re-create Hermes, that also started from something very simple. For example this script uses different way for reliable keeping the heli at/on the ground for touch down/landing (there's a bug in vanilla heli landings, when heli after the land takes off again and stays hovering). It is done via not available, while Hermes was created, alternative flyInHeight syntax enforcing chosen altitude in real time: _heli flyInHeight [0.5, true] As a result, heli immediately and pretty aggressively adjusts the altitude, even very low, and keeps it, which is cool, but apparently in the process heli doesn't pay attention to trees etc. Hence it is on the player to pick the LZ safely. findEmptyPosition is used, but it may not suffice in certain situations. Player/mission maker being responsible on having smokes/flares on the caller is another thing, that stays so in sake of simplicity. Unlimited calls is not the thing here also, but one could simply set very high limit to get practically same result. Alternatively, one could disable/remove this line: AI_SHT_extractionsUsed = AI_SHT_extractionsUsed + 1; And optionally to adjust info text here to fit better and avoid confusion: _text = if (AI_SHT_extractionsUsed < AI_SHT_extractionLimit) then { (format ["Helicopter has returned to base and is available for another extraction. %1 calls left",(AI_SHT_extractionLimit - AI_SHT_extractionsUsed)]) } else { "Helicopter has returned to base. No calls left" }; hint _text; For example reduce the above to something like: hint "Helicopter has returned to base and is ready for another call";

Gunther asked me to paste here the info about the new mission update on Steam Workshop - he is lately unable even to log in due to persisting technical problems of these forums. Update: Feb 24 @ 3:01am v1.4 ==== - Changed the intro. - Added two new player starting positions. - Adjusted some objects in buildings. - Removed some lamps that were preventing some lights to be seen. - Added another boat patrol. - Adjusted boat patrol markers. - Adjusted waypoint settings of foot patrols. - Added view distance parameter & script. - Updated skill script. - Updated description.ext code for the parameters. - Updated uniforms and gear of most units. - Added few triggers for tripwire flares. - Fixed task id issue for 2 tasks with same id. - Fixed code order of one of the tasks. - Added a new lookout camp with task. - Added 2 new tasks. - Added 2 beach patrols in two seperate locations. - Added three new locations with fog ambiance. - Added Helicopter transport for extraction. - Added exfiltrate task after all tasks were completed. - Added respawn ticket function. - Updated the briefing and replaced diary modules with a script.

Maybe try this way: 1. Find this line (25th in the original file): "_this in _originalTarget", 2. Turn it into: "((_this in _originalTarget) and {(primaryWeapon _originalTarget) isEqualTo 'CaseSensitiveSpecialRifleClass'})", It's action's visibility condition. So the action is visible, where 'CaseSensitiveSpecialRifleClass' is your special rifle class. So the switch action will be visible only, if certain weapon is held. But we need also to handle situation, when the Spectator mode is already switched on, and after that player changes weaponry. Thus: 3. Find this line (35th in original file): if not (isNil "RYD_PRC_Projectile") exitWith {}; 4. And add new line just below, so both would look like this: if not (isNil "RYD_PRC_Projectile") exitWith {}; if not ((_this select 1) isEqualTo "CaseSensitiveSpecialRifleClass") exitWith {}; After that there should be no spectator view if the weapon fired class is not the special one. In fact, points 3 and 4 suffice, if you don't mind Spectator mode switch action visible regardless, if player has that special rifle or not.

Well, that's the way. But if so, this must be done in the place of the code, where output is already determined (after the player confirms his GUI choices with a button). RYD_TakeValues seems the right place - it shows, how it is done for all the other dropdowns (paired with RYD_JR_Dialog). Also you don't need to nil a variable in order to define it with other value. Just define it with other value. I guess, you need to replace editor-placed Alex with spawned unit of desired side defining it as RYD_JR_Alex and selected as a new player unit... Unless would work simply to join Alex a newly created group of proper side, but to me it sounds messy. Anyways, good luck! 🙂

All right, please, test the code included in this version in your own scenario and see, if it helps. AI Medic Auto Heal 1.02 If the above fixes the problem, then @Gunter Severloh - we should update the thread with this version. The change: was: _wounded = _units select {((((getAllHitPointsDamage _x) select 2) findIf {_x > 0.1}) >= 0)}; is: _wounded = _units select { _damageArray = getAllHitPointsDamage _x; if ((count _damageArray) < 3) then { false } else { (((_damageArray select 2) findIf {_x > 0.1}) >= 0) }; }; If it doesn't help - then after all venilla repro would be required.

OK, zero divisor errors bound with "select" (Error position: <select 2) findIf {_x > 0.1}) >= 0)};) in my experience usually indicate, that the code tries to point via select a non-existent element of the array, so in this case - like the array is shorter, than 3 elements, while the code tries to take third element. But the array is produced by this command: https://community.bistudio.com/wiki/getAllHitPointsDamage And per description, it should always have 3 elements. So either it is not about that after all, either there's some abnormal output of this command regarding one of player's group units. Without proper vanilla (no mods/custom addons used/required whatsoever) repro mission, that I could personally test with extra logs, I can't say more nor propose any fix, as there's no clear indication, what could cause this error in the provided logs. So please, give a simple repro, that reproduces this error. EDIT: So this could explain the issue, array can be empty if for any reason units group player return null or no shape entity. I'll propose "blind fix" in that direction to be tested, if it helps, then that was likely it.

Nothing obvious coming to my mind by looking at this line. BTW in original script line 345 is: _val = (damage _x)/(_medicD max 1);, but init.sqf could be altered in this case. I can try to add some UAV and see, what happens, but IMO it rather shouldn't have any impact, as this script works on player's group. Best would be as simple, as possible, vanilla repro mission with clear steps to reproduce that error. EDIT: I added some west and east UAV teams and standalone UAV units to mu demo mission, there was no any errors. So repro is needed.

An advice, if you wish to experiment more with side swapping in the future, you may consider to: 1. at the very beginning of init.sqf define three global variables, for example in the vanilla version: RYD_JR_AlexSide = west; RYD_JR_HostileSideA = resistance; RYD_JR_HostileSideB = east; 2. Find and replace instances of west -> RYD_JR_AlexSide, resistance -> RYD_JR_HostileSideA, east -> RYD_JR_HostileSideB. But do it by hand, not via mass find&replace, as there will be exceptions, that should stay untouched, like compass direction names (west), marker colors bound to sides, such words inside various texts/strings... If done properly, changing Alex side and hostile sides will be then all about changing those three lines. For example: RYD_JR_AlexSide = resistance; RYD_JR_HostileSideA = west; RYD_JR_HostileSideB = east; Still, unit/object classes native to certain side to be changed separatelly. So anyone willing to try should consider, if it's worthy of effort for him.

Primary function of KIA are those marks, but later I added to it also Alex reputation change related to kills. In the Killedmark.sqf the code starting from: if ((_this select 1) in [player,vehicle player]) then { relates to reputation gained or lost due to kills. Side of killed unit matters. In this array: [civilian,west] there should be civilian side and Alex's own side to make "friendly fire" losses check. So if west side is now enemy and Alex is of resistance side, it should be [civilian,resistance]. BTW I recommend to do a mass search across all the files for words west and resistance to see, where else side swap would make a difference. For example, we have RYD_JR_BigCamp function in JR_fnc.sqf. There are spawned recruitable POWs. In vanilla they are of west side of course, so the change is needed also here: _gp = createGroup west; and may be a good idea also to change accordingly POW classes in JRInit.sqf: RYD_JR_CaptivesClasses = ["B_G_medic_F","B_G_engineer_F"]; as those are natively BLUFOR. and revealMine side: if not (RYD_JR_ACIntense > 0) then { resistance revealMine _mine; }; to west. also the checkpoint function: RYD_JR_CPSetup if (_side == resistance) then { _staticW = ["I_HMG_01_high_F","I_GMG_01_high_F"]; }; and _camo = "CamoNet_OPFOR_open_F"; if (_side == resistance) then { _camo = "CamoNet_INDP_open_F" }; should be turned into west and according classes. RYD_JR_Sherwood function (hidden camps): if (isNull _gp) then { _gp = createGroup resistance; }; resistance -> west. and according classes in the RYD_JR_CampStuff array (JRInit.sqf) RYD_JR_Warmonger (ambient combat function): _sides = [resistance,east]; Here should be both sides hostile to Alex. And here: switch (true) do { case (_rnd > 98) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllArmGroupsI;_gpKind = "arm"}; case (east) : {_gps = RYD_JR_AllArmGroupsE;_gpKind = "arm"}; } }; case (_rnd > 90) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllMechGroupsI;_gpKind = "mech"}; case (east) : {_gps = RYD_JR_AllMechGroupsE;_gpKind = "mech"}; } }; case (_rnd > 75) : { switch (_side) do { case (resistance) : {_gps = RYD_JR_AllMotGroupsI;_gpKind = "mot"}; case (east) : {_gps = RYD_JR_AllMotGroupsE;_gpKind = "mot"}; } } }; RYD_JR_AllArmGroupsI etc should hold hostile groups of proper side. Same as RYD_JR_AllLocalGroups = etc. but I guess, those are handled already? Problematic may be RYD_JR_AllFIAGroups = , an array supposed to hold possible to spawn in AC allied with Alex partisan groups of FIA faction. But those must be same side, as Alex. There's more across JRInit.sqf: _sides = [east,resistance]; also: switch (side _x) do { case (east) : {RYD_JR_East pushBack _x}; case (resistance) : {RYD_JR_Resistance pushBack _x}; }; and few other in type of _side = resistance;. At the very beginning of vanilla init.sqf wehave also whole setFriend stuff: west setFriend [resistance, 0]; resistance setFriend [west, 0]; east setFriend [resistance, 1]; resistance setFriend [east, 1]; //west setFriend [sideEnemy, 0]; //east setFriend [sideEnemy, 0]; //resistance setFriend [sideEnemy, 0]; civilian setFriend [west,1]; west setFriend [civilian,1]; //west setFriend [sideFriendly, 1]; //east setFriend [sideFriendly, 1]; //resistance setFriend [sideFriendly, 1]; //civilian setFriend [sideFriendly,1]; Recommended to ensure, all is right here. and lower, same file: if (RYD_JR_ACIntense > 0) then { east setFriend [resistance, 0]; resistance setFriend [east, 0]; }; Ambient combat. If both sides hostile to Alex should fight with each other, both must be properly used here, so for example west instead of resistance, if Alex is resistance. Then AddKMark.sqf: if not ((side _x) in [west]) then into: if not ((side _x) in [resistance]) then also in decoy.sqf: if ((_side in [east,resistance]) and {_delRisk > 0}) then { [east,resistance] - this should hold sides hostile to Alex's side. Mainloop.sqf, code for hacked "mad stomper", two times: if ((side _x) in [east,resistance]) then//hostile sides here { RYD_AS_Targets pushBack _x } Finally, about civilians attacking Alex despite good reputation. Thing is, if Alex has high reputation, sometimes should spawn an armed civilian as an ally. So same side, as Alex. In vanilla that's west. Hence spawned are west side armed civilians. SCA_fnc.sqf: if (RYD_SCA_HostileToSpawn > 0) then { _side = resistance; if (RYD_SCA_FriendlyToSpawn > 0) then { _side = west; So if now Alex is of resistance side, those two should be swapped like this: if (RYD_SCA_HostileToSpawn > 0) then { _side = west;//or east... if (RYD_SCA_FriendlyToSpawn > 0) then { _side = resistance;

Introduction HWS is meant as very easy in use generator of dynamic, interesting battles conducted by HETMAN commanding AI. Unique each play battle experience powered by very complex scripting is created with few mouse clicks. No addons required. Optionally at init player may customize the gameplay by choosing fighting factions, scale of the battle, daytime, weather, forces ratio, persistency of the result (campaign mode, where results of past battles slightly affect every next battle) etc. Additional text field allows advanced users and Hetman veterans to apply also more complex setup code or even regular script, that will be executed at init. Resulting battle may vary greatly each try. War has many faces, nothing is guaranteed. You're only one of many cogs in the war machine controlled by HETMAN, so do not expect any special treatment. Those battles aren't player-centric in any way. One time you may found yourself in the middle of fierce firefight immediatelly, another time you may be kept as reserve long time before you see any action. You may die in the first few minutes or survive to the end without a single shot fired, but with few clicks in the legs. Both extremes are not very probable, but possible and perfectly OK - just do your part or act on your own. Create own war stories. HWS will utilize also units from custom addons when loaded if addons have configured properly groups. Additionally, player may any time via supports menu (0-8) activate passive spectator mode based on Smart Camera script, that will turn the game into kind of war movie to watch, showing autonomously chosen interesting spots of the battlefield - all without any interaction required. That mode may be switched off anytime by pressing a keybord key. In the same menu player may find also other useful in-game switches. Download HWS 1.06 (Armaholic) HWS 1.10 (Dropbox) HWS 1.10 (Steam Workshop) HWS 1.10 open (Dropbox) - open folder Hetman War Stories GithHub public repository WIP It is my own "dev branch". Here I'll try to update the file on an ongoing basis each time, I find and fix any bug, so impatient may use it instead wait for the fix in the next official version. Latest fixes: Changelog To do Recommended addons - TPW MODS (especially for HUD feature); - any preferred low level AI enhancers, that doesn't mess with waypoints (bCombat, ASR AI...); - L_ExShake & L_Twitch; - some custom factions addons for bigger variety of forces to choose from (African Conflict, CAF Aggressors...); - Dynamic weather; - any preferred sound and graphical FX enhancers (JSRS, Laxemann's "Enhanced Soundscape", Blastcore...).; - Liability Insurance 1.1 (units hit by allied vehicles will take no damage, ramming enemies to death still possible - workaround for AI drivers hitting infantry, recommened, until BIS will fix driving AI). Porting HWS to another map Although official ports will arrive not sooner, than when this version reach final state, porting process is easy and not require any scripting knowledge, so anyone is able to prepare port indepedently by following these steps: 1. de-PBO mission file using any tool doing that, eg from here; 2. locate resulting folder, where all mission folders saved in editor are (Win7 usual path: C:\Users\<user name>\Documents\Arma 3\missions); 3. Launch Arma 3 with custom map addon, where you want to port HWS, and whatever this map requires (only, no other addons!), enter editor with Altis and load this mission; 4. Copy (select and ctrl+C) all objects present on the map; 5. Load in editor empty target map and paste on it copied objects in any suitable place (sc1 object's location will determine initial GUI screen camera shot); 6. Set copied unit (dummyPlayer) as player unit; 6b. (Ignore this point, unless you're porting mission to the map from older games of Arma series (OFP, Arma 1/2/OA)) For A2 and older maps, additional step is required: Add in editor another object: an empty, square trigger, that will cover the part of map, you wish to contain a possible battlefield. This trigger must be named: RydBB_MC. Length of the edge should be divisible by 500 (single sector dimension). 7. Save the mission; 8. Go, where you stored de-PBOized HWS, copy everything inside HWS' folder except mission.sqm and paste that as is into newly created mission folder; 9. Return to the editor, reload and preview new mission. If is working - Mission is ready for use/pbo-ize. Notes - Idea behind HWS is to give HETMAN experience for all, also those, who up to now considered HAL as complicated to use; - scripters and Hetman veterans may find the GUI text field very useful for advanced mission/Hetman/spectator mode setup eg by pasting favourite init configs. However keep in mind, not all Hetman settings have a sense; - yes, Hetman in HWS is able to make good use also for custom content without any manual RHQ mambo-jumbo. Is used special piece of code, that constructs RHQ set automatically. It is based on assumption, so unit's config is following some typical patterns established by BIS' vanilla configs. Weirdly configured custom units may be misused; - used settings are stored for the next play. Hit ESC key to restore defaults. Mission is released under APL-SA license. Voice acting: DuddBudda, SiC_Disaster, nettrucker. Enjoy the war stories. Rydygier

Great! Let's wait and see then. 🙂 Clear now, thanks!

Hello @Atlas01Actual. 🙂 Thanks for the kind words! I'm happy, HWS still brings some fun to the people. I'm hardly MP scripting specialist, but at least I could try to put some thought into this... So, I guess for MP there must be initially placed as many playayble units on the map, as many slots is wanted to be available. Hetman itself can run on dedi, it's just server-side script. Not sure about possible issues with HC setup though. Well, that would mean, the initial options GUI must be moved to one of the clients. Also probably initial camera flyover is impractical in MP (being for only one of the players to watch or none whatsoever if left on dedi side; it's just a gimmick anyway). Probably in the very same place in the code, where SP player is put in the shoes on a randomly picked unit: 2133: selectPlayer _player; (init.sqf) should be added the code to handle all the player-controlled slots in similar fashion, provided, it will work OK MP. Now, as lobby MP parameter or another option for the initial options GUI there may be a switch, if all the players should get their units at random, or rather should be found a group, that includes enough members and all the players would land there. So, there should be also added a custom respawn behavior, putting fallen player into another unit, right? ...and also a mechanism, that would keep all the players together, if any of them decide to team switch... And to respawn in the vehicle, they died in? That last one sounds bit weird. Not sure, if I understood this one. Well, aside the last thing, I probably misunderstood, I could at least to think and try. If I manage to achieve anything of the above, I let you know, but no promises, no idea, if or when it may happen. For now, I must to sort some issues with my A3, which was misbehaving recenty. Anyways, Happy 2025, guys! 🙂

As for me - sure, you have my permisson. Good luck. 🙂

OK, I have no big experience with GitHub, I find it confusing a bit, as I'm not a programmer, still attempted to create such a repository. Also attempted to make off limits "sound" Hetman sub-folder, as sound files in Hetman are provided by other community members, probably long time out of reach, so it's neither may work, niether I know exact usage limits, they would want for their input, hence sound files should be left as they are. https://github.com/Rydygier/HetmanWarStories/tree/main Not sure, if anyone would like to work on this, but here it is nevertheless.

In general I keep my Arma projects, HWS included, open source to anybody wanting to make any fair use of it, with "share alike" as the restriction and being thruthful about the original authorship as strong recommendation (APL-SA). Hence we have NR6 HAL Evolved for example.

I didn't review HAL code long enough to lose confidence what's what and where, but keeping that in mind: Rest orders can be issued due to several causes including: 1. Group's vehicle: no fuel, armed but no magazines, damage > 0.5, immobilized; 2. group members: total value of wounds and losses too high (threshold depends on commander's personality - recklesness), note, KIAs are counted by comparing the "initial count" (measured once, somewhere at init) with current units count. So any despawns/caching based on despawns are counted as losses too, which affects both group readiness check and the morale; 3. group's ammo reserve considered too low (complex calculation); 4. If HAL decides, the group is overwhelmed by near enemies (complex calculation), rest order may be issued as well as form of "tactical retreat". So, whatever is going on due to Alive or something else, it most likely triggers one of the above. Mods in type of Alive can mess with stuff sensitive for HAL, sadly. Personally I've no further plans for HWS (empty personal "todo"). To be honest - same applies to Arma scripting in general (no any personal projects planned, probably I'm just burned out/out of appealing ideas, or just (re)tired). But always feel free to write any particular wishes/requests or bug reports. Nothing can be promised, there may be nothing done about them easily, but who knows, maybe I'll be willing and able to do something, if easy/quick enough, depends on my RL situation and overall motivation, both are changing often these years. In any case at least I'll be informed, people would like to have something implemented. Oh, I see, HWS has already 10 years... How this even happened?

This also is a way. So you have some marker in RYD_SPR_RespawnPositions and then in some parallel loop you update it's position to make the player respawn somewhere around last position. Maybe like: [] spawn { _pos = getPosATL RYD_JR_Boat; _i = "respawnMark_" + (str _pos); _i = createMarker [_i,_pos]; _i setMarkerColor "colorBlack"; _i setMarkerShape "ICON"; _i setMarkerType "mil_dot"; _i setMarkerSize [0,0]; RYD_SPR_RespawnPositions = [_i]; while {true} do { sleep 30; _i setMarkerPos (player getPos [(75 + (random 75)),random 360]) }; }; But again, IMO there's serious risk, combining this respawn with Pilgrimage would somehow, at least partially, break Pilgrimage regardless of respawn position method.

There's large risk, it woulnd't work because reasons, but if you want to try, I recommend to [] spawn {}; whole thing at the very end of JRInit.sqf and add such a line: _newUnit = (group _killed) createUnit [(typeOf _killed),_respawnPos,[],0,"NONE"]; RYD_JR_Alex = _newUnit; But then also you need to figure a way to define respawn position/decide, where respawn should occur. At the boat? So initially: RYD_SPR_RespawnPositions = [RYD_JR_boat]; And at the hideout if it is set, so this: case (8) : {_center setVariable ["RYD_JR_Parking",_veh]}; into: case (8) : {_center setVariable ["RYD_JR_Parking",_veh];RYD_SPR_RespawnPositions = [_veh];}; And if you pack the hideout - the boat is set again. But there may be optionally multiple hideouts, so it is more complex - perhaps you should rather add new randomly piced spot to RYD_SPR_RespawnPositions each time new hideout is set, and remove this spot when it is packed, and if after that the array is empty - add the boat to it?

FFE 1.14 (Armaholic) FFE 1.17 (Dropbox) PDF manual INTRODUCTION FFE is a counterpart of A2's "Fire At Will" addon prepared for Arma 3 with only minor changes, mostly unavoidable due to completely new artillery handling. Its variation deals with artillery under Hetman script. Unlike Arma 2, in Arma 3 scripts aren't necessary to actually see AI artillery firing, still some scripting can improve arty AI and can be useful for people, who need such enhancement. That is the goal of FFE. "Fire For Effect" provides fully autonomous AI artillery, that reacts on current situation by smart shelling enemy targets spotted by allied forces. "Smart" means reasonable target choosing, avoiding friendly fire or civilian casaulties and ability of predicting, where moving target will be at impact by analyzing its movement vector. FFE provides also simulation of targeting errors due to factors like human mistakes, weather and more. Addon supports all generic Arma 3 artillery units. Custom artillery pieces, if compatibile with vanilla artillery computer, may be added via init variables. ----- USAGE To use the FFE addon version in your missions launch the game with FFE addon, place on map some artillery pieces, any units of same side acting as FOs, some OPFOR as targets and FFE module. That’s all. To use FFE script version, instead of module, put content of "Script version" folder into mission folder and place following code line eg in the init field of any unit or activation field of trigger etc. or, best way, in the init.sqf: nul = [] execVM "RYD_FFE\FFE.sqf"; See included manual for more details, including optional customization via init config variables. ----- KNOWN ISSUES ETA issue I'll be grateful for any bug reports, best in form of well discussed repro mission. ----- Addon was created "by player for players", source scripts you can freely modify, copy, "cannibalize", to use in your projects. It is released under APL-SA license. I'll be grateful for notification about each such usage. Enjoy fireworks. Rydygier

No idea, cDLC assets can have some extra functionalities scripted in... FFE for sure doesn't make any arty to move anywhere, but if target is revealed by some FO, this may trigger some attack/engage behavior perhaps?

Oh, that's an old code indeed. Simple thing, it seems. RydFFE_FO should include group names, not unit classes, quoting manual: As for the classes: So it works in a bit odd way, as you see...

Title explains, what I try to achieve - thing like this. Shooting straight ahead seems to work (tested with code from BI CAS module used for planes, also works with forceWeaponFire), worse with targeting at ground targets - here I encountered few issues. Heli ignores/will not change direction/pitch/aiming at doWatch/doTarget with or without target reveal (apllied to the heli, heli's gunner and/or driver), target may be allied or hostile unit, whatever. It doesn't even turn minigun turret at the target. Ignores also setFormDir. Said CAS module uses also spawned laser target object. But as soon I spawn it, heli starts to spin around: BTW Similar thing happens after using BIS_fnc_fire (action "UseMagazine" way), but some shots are fired then. Also doSuppressiveFire seems not work with the heli (pity, would be optimal for my need). If applied with position or object, heli will not shoot at it, instead will start doing flybys, like in normal attack pattern until reach some position or indefinitely. I would like to avoid using enforced ways, like setDir, addTorque or setVelocityTransformation, rather to base on AI than fighting with it. Still it may be unavoidable, since to shoot from fixed weaponry at ground level target, heli needs to dive a bit, which without invisible "helping hand" means flying forward (could be countered with setVelocity). Anyway, tested setVelocityTransformation, with partial success. This code: makes the heli turning in right direction, but the turn is too wide (why?). This from the other hand does the trick: but faster, than in 2 seconds and after few more seconds heli starts very rapidly change its vector, like crazy (why?). I have no experience with setVelocityTransformation, so I might misuse it somehow. (_gun/v1 is the heli, _tPos) - target position. I would appreciate any insight.

Well, as the title suggest (stationary hovering position), it's for helicopters. Plane CAS would be quite different story.

Yup, sure, perfectly OK. Implement it, if you find it useful. 🙂