franze

UPDATED! v1.31 has been released! Changes: - Modified gun tracking in HMD and AUTO modes to remove bank error. - Modified IHADSS scripting to work faster on per frame handler. - Modified weapon damage so that if using a linked weapon and one pylon is damaged, only ordnance is lost on that pylon. - New laser designation system for CPG. - New experimental mouse input for click actions: when the Head Tracking On action is used, the mouse will move the 'X' click action point. - Gun burst no longer forced time restriction. Gun now has overheat tracking and overuse can result in gun jamming. - Gunner heads down symbology in place. - Added DTV monochrome effect. - Modified gun control: gun control exclusively the realm of the CPG in multiplayer. - Fixed issue with MPD buttons not working with CEM off. AH-64D ArmA2 v1.31 And as a bonus, here is a ArmA3 compatible controls file (note: requires fza_ah64_us.pbo from v1.31 for ArmA2 to function): AH-64D ArmA3 compatible controls file v1.31 Note that this is not fully tested and may not work 100%! I had wanted to delay until v1.4 was ready so we could get new skins and textures in place but Nodunit won't have that ready for a while. These scripting updates are not fully tested so there may be some issues in multiplayer or certain situations that I haven't found yet.

For calling from an addon, you need a \ to the script path. The examples given are within a mission framework. So instead of: A7E_clickaction = compile preprocessFileLineNumbers "CHANGEVOUGHT\script\InteractionButton_click.sqf"; You should have: A7E_clickaction = compile preprocessFileLineNumbers "\CHANGEVOUGHT\script\InteractionButton_click.sqf";

Yup, all done in that section - a constant loop would be like this: if(inputaction "User20" > 0.5 && _controlpos distance [0.5,0.5] < 0.4) then { _boat animate ["ramp",(_boat animationphase _ramp + 0.01)]; button_clicked = 1; };

Yes, that's what this section does: if(inputaction "User20" > 0.5 && button_clicked == 0 && _controlpos distance [0.5,0.5] < 0.4) then { //do whatever we want the click action to do here// button_clicked = 1; }; It's all in how you want the key or key(s) to function.

Best way would be to record the fuel amount, then setfuel to 0 when folded, then set back to the right amount when unfolded. _mv22 = _this; _fuelqty = fuel _mv22; _mv22 setfuel 0; waituntil{_mv22 animationphase "pack_engine_1" == 0}; _mv22 setfuel _fuelqty;

I used it in a vehicle init like this: fza_ah64_armingunits = [(typeof truck1),(typeof apc1)]; And it worked for me. If that doesn't work you can try adding it to a delayed script in order to overwrite the default arming vehicles.

There's no limitation on what type of vehicle it can be used with; the first example works with all man class units. For the latter two examples you can just replace the first "Helicopter" with "AllVehicles" and it will work with all vehicle types.

There's actually a built in functionality to change arming vehicle classes on a per-mission basis: fza_ah64_armingunits = ["vehicleclassname1","vehicleclassname2"]; Simply add the class names to the array - as many as you want -and place it in a init line anywhere. Then you can use the arming interface with that vehicle class, nothing fancy required. This was added to allow mission creators to set specific classes for rearming capability or to disable the capability entirely. To get flare launchers by default would require editing the config to add flare launchers (as BI neglected to give us a AddWeaponTurret command) to the pilot's weapons and then it wouldn't really look right either as this version doesn't have the memory points in the model to spawn flares at the right point. A purely script based solution is possible but I'm unsure of what the proper drop commands are for that in ArmA3. In ArmA2 one can use the following: drop["\Ca\Data\kouleSvetlo","","Billboard",0.05,10,[1.5,1,0.7],[2+random 8,0,+10],0,2.8,1,0.1,[3],[[1,1,0.3,1]],[0,1],0.1,0,"smoke.sqf","",_heli] //smoke.sqf drop["\Ca\Data\Cl_basic","","Billboard",1,5,_this,[0,0,0],0,1,1,0,[1,5],[[.8,.8,.8,0.6],[0.8,0.8,0.8,.1]],[0,1],2.8,1,"","",""]; Which will not have any countermeasure effect, it will only be for FX purposes. For acquiring targets in FCR/A and FCR/G modes, you use the vanilla tab-lock functionality to cycle through the targets. While this will also make your pilot give out the 'target xyz at whatever' vocal command, the 'true' target is the one indicated on the IHADSS or TSD/FCR displays. We did not want to require a separate key to acquire visual targets vs FCR targets, although that can be changed if enough people feel it is desirable to have two separate targeting keys. Yes all, RF missiles are AGM-114L at this time. Unless they decide to expand upon radar guided types, RF will indicate that model. Those are some quality videos, I'm glad you're enjoying it despite the bugs!

Flares are not on the version in this package; however, they will be added to modernized variants. As this version only barely works in A3 and we've repeatedly stated that we're not ready to move to A3 yet, I can't say what it would take to fix any problems it has in A3.

To use less resources, the standby instruments use animation sources hard coded by BI rather than scripting.

Can't speak for the TKOH issues but the ArmA3 issue isn't unique to ArmA3; the air speed on the left side of the IHADSS registers air speed, not ground speed. The waypoint information box in Cruise or Transition modes registers ground speed as measured by doppler navigation.

Actually, in Desert Storm, a HARM missile did lock onto the tail radar of a B-52 (http://en.wikipedia.org/wiki/B-52#cite_ref-203), so it's within the realm of possibility. Keep in mind though that missiles like HARM and ALARM lock onto radar emissions which I don't think jamming noise counts as, which is why you usually hear about Home On Jam capabilities. I'm pretty sure a lot of this stuff is classified but my general theory is that RF jammers generate noise on certain known frequencies in order to prevent radars from properly tracking on their various detection and guidance bands. I do believe a side effect of this is that it makes it relatively easy to find out where the noise is coming from. All straight up theory of course; there's probably way more to it than that and probably even less that's out there on the unclassed realm.

I can't speak for RF missiles or even real life applications, but in the game turning on the RF jammer will give false signatures on the air radar and TSD, which can affect target acquisition in FCR modes.

The startup sequence is inaccurate because it was rushed. You CAN rebind the MFD cycle keys, they're linked to the Custom User 1 and 2 keys.

Are you following the startup procedure? Battery on, APU on, ENG 1 + 2 to start, throttles to full? Yes, there is an integrated mechanism though it has to be set per mission: fza_ah64_maplist = ["\fza_ah64_US\tex\mpd\notfound_2.paa"]; //sets the list of available map files for the mission fza_ah64_mapsizearea = 5120; //sets the map size in meters fza_ah64_currentmap = "\fza_ah64_US\tex\mpd\notfound_2.paa"; //sets the default map You will have to make your own map images and either reference these in a pbo or in the mission file itself. There may be some other addons out there but vehicle AI is difficult to directly control.

Negative, it is unavailable at this time.

Yes, that's what Gun tracking/User 3 is for. Figured this one out - there's a bug that requires the battery to be on (or the rotors turning) before the hot link buttons will work, to include the DMS menu. I'll fix that bug for CEM off states in the next update.

Because the scripting system needs an overhaul to work with ArmA3.

Most are for the pilot but some only apply to the gunner. It also depends whether it's multiplayer or not. If you get out of the helicopter with the engines running, you will have to engage the rotor brake and redo the startup procedure again. This version isn't equipped with flares, only chaff; this is controlled exclusively by the pilot with the game default countermeasures key ®.

This is the way I have my controls bound: FCR On/Off/Salue: \ FCRAA/FCRAG/HMD/TADS sensor selection/OpticsMode: numpad / Gun Burst, Rocket Salvo, HELLFIRE trajectory/Binocular: B PNVS: Numpad arrow keys and joystick hat Cycle right MPD page/User 1: Right Shift + < Cycle left MPD page/User 2: Right Shift + > Gun tracking/User 3: Left Shift + G WAS/Weapon Action Switch/User 4: Mapped to joystick TSD/FCR target filtering/User 6: Left Shift + R TSD Range Setting/User 7: Left Shift + E TSD Mode/User 8: Left Shift + T PFZ Selection/User 9: Right Ctrl + P IR Jammer toggle/User 11: Mapped to joystick RF Jammer toggle/User 12: Mapped to joystick IHADSS Mode/User 15: Mapped to joystick Crosshair Action/User 20: ; and a mouse button

Remote designation is a tad complicated on the back end but it will work with the ULB by placing this in the ULB init line: laserscript = [this] execvm "\fza_ah64_controls\scripting\add_remt.sqf" The laser MUST be on when the missile is fired and this is the problem a FAC unit has, the AI in control of him will swap or turn off the laser as soon as it gets control. The system was really intended to work in cooperative mode with multiple players. You can override some of this by creating a fake laser target and adding it to the designator list like this: _helilaser = "lasertargetW" createvehicle [0,0,0]; fza_ah64_desiglist = fza_ah64_desiglist + [_helilaser]; You will have to remove the laser via scripting when no longer needed.

We had a lot of other things in mind for what we'd do after the Apache but elaborating on them would be foolhardy; the amount of time it took from concept to release for the Apache pretty much says any announcements now wouldn't be accurate, especially when the Apache itself is far from done.

That's why you don't exceed ~150 knots. ;)

You have to acquire the laser with tab lock and often you have to lead the target with the laser if it's moving to get a good hit.

It's a debugging camera, only applies for missiles. You can enable it by placing this in an init line: fza_ah64_miscam = 1