franze

Are you placing it in a init line or init.sqf?

Yes, you can use this: fza_ah64_armingunits = ["NoArming"]; To disable the arming dialog.

That would explain a lot then because most pictures on the net only have the standard 4 sensors. I've never seen an Apache with more than 4.

Everything I've found only shows four sensors, two in the nose, and a staggered two at the base of the tail.

CMWS only consists of four detectors; you can see this by looking at the OH-58Ds, UH-60s, and CH-47s equipped with the same system. Some other countries use different systems, notably the WAH-64, Dutch AH-64Ds with AMASE, and IAF AH-64s with some other combinations.

Most of the proposed AH-64B upgrades were placed on AH-64As; the AH-64D had them designed in place from the outset. The AH-64C was intended to retain -701 engines and not have the FCR, but with provisions to add upgraded engines and the FCR. The sensors on the wingtips are part of CMWS, they are the respective rear hemisphere sensors. The AH-64E has an updated/modified system that is intended to link into systems beyond CMWS. Pretty sure FLIR displays as black and white through the ORT/TEDAC as the DTV is also black and white, but I am not certain on this.

Sharing data whether it's target coordinates, camera feeds, or waypoints, was not refined and fully implemented. PFZ sharing only just barely works and it was the only data sharing mechanic implemented at release.

Since the AH-64B and C were proposed variants that were never built (and the AH-64C became the AH-64D NR), we probably will not entertain these variants.

SelectionPosition is what I've had to use for a while now due to other issues, but I still rely on modelToWorld for the screen position. That still leaves the problems we were having with the pylon elevation and gun turret.

I'll try and answer a few questions: ACE Mod: Sorry, too busy with other things to even get into ACE compatibility. AH-64A will have ATAS option. ETA on AH-64A can't be given due to the major differences in modeling and functionality. Laser targets: Yes, but only works with SAL missile types. ArmA3: Beyond the released controls file, ArmA3 versions are not happening. ArmA3 broke too many basic features of our aircraft.

The problem is that bis_fnc_spawnvehicle looks for the HelicopterX simulation. We use Helicopter simulation because HelicopterX messes up the click action capability. You'll have to create/use a different functionality to spawn with crew on board and in flight.

Try using this switch in your mission: fza_ah64_cem = false It will turn off complex startups which may be the issue you're having.

A2 version is still on the table for at least one more version but more focus will be toward TKOH over A2.

There were two major issues that came across for the ArmA3 version: - simulation=helicopterx introduced a velocity error when translating model position coordinates to world coordinates. This completely ruined the clickable cockpit mechanic. A velocity correction routine was tried but still did not completely fix the issue. - In multiplayer, the gun and pylons would not properly animate for the gunner. There was a 5 second delay between where the gunner aimed and the weapons following suit. The animate command was modified in such a way that it no longer transferred animation data effectively between the pilot and gunner. v1.31 for ArmA2, the gunner had control of the gun and pylon elevation exclusively and was tested with such; no issues came up. What I couldn't seem to figure out was in ArmA3, for everyone not part of the helicopter crew, the animations looked normal; but for the gunner there was always a 5 second delay. These two issues attack some major 'selling points' for not just the Apache, but future aircraft as well. I am unwilling to give these features up simply for some extra graphical effects, especially when the game itself runs very poorly for me. TKOH on the other hand offers RotorLib and we've already been able to do some amazing stuff with it. Things like loadout weight, fuel weight, crew weight, etc. can be accounted for, we don't have to hack a startup sequence, and we have far more flexibility in helicopter specific equipment and health. ArmA3 offers none of this; it's claim to fame is some additional graphics effects. If our project were simpler then we'd likely be fine with it. However, our plan was never to rehash the same old with a new model, and going into ArmA3 is one step forward, two steps back. Once the TKOH project is done then perhaps ArmA3 will have matured enough to make it worthwhile.

The positional error induced by the animations doesn't affect these as the control positions are relative to the model - that is, even if your head moves shifts in X, Y, and Z, their position remains the same. For example, even with 6DOF in TKOH the controls stay in the same place. This is some error induced by the new simulation classes in ArmA3 - if you use the old helicopter, car, plane, etc. simulation types then the error is not present. Create a mission with a MH-9 named heli and a 100cm sphere helper object named cone1, then put this in a radio command: myconepos = { helippos = heli modeltoworld (heli selectionposition "rotor_center"); cone1 setpos helippos; }; ["myconeid", "onEachFrame", "myconepos"] call BIS_fnc_addStackedEventHandler; Observe that the sphere remains centered on the rotor mast until the velocity changes. Then the sphere will start moving in the direction of the velocity instead of maintaining a static position at the rotor mast. Note however that if one uses attachTo, the object attached to the helicopter will maintain it's position; this leads me to believe that there is distortion between model space and world space due to velocity that the modeltoworld command does not account for - when using the x class simulations. ETA: It is possible to correct for some of the velocity distortion, however much precision is still lost using this. _helivel = velocity heli; _helivelcorx = (_helivel select 0) * 0.03334; _helivelcory = (_helivel select 1) * 0.03334; _helivelcorz = (_helivel select 2) * 0.03334; _helippos = heli modeltoworld (heli selectionposition "rotor_center"); _helippos = [(_helippos select 0) - (_helivelcorx),(_helippos select 1) - (_helivelcory),(_helippos select 2) - (_helivelcorz)]; cone1 setpos _helippos;

I thought I'd update this as I've come across a big error with this mechanic: If your simulation entry is one of the new ArmA3 types - such as helicopterx or planex - there is a positional error induced with the application of velocity to a vehicle. I am not entirely sure the reason for this, but model coordinates are apparently being offset somehow when the velocity of a vehicle changes. I do not know by how much, but it is present and is difficult to correct for. If your simulation type for a vehicle is one of the old types such as helicopter or plane, the error goes away. I assume this is some kind of interference with the PhysX engine since the X at the end of the simulation type most likely indicates PhysX applied to a vehicle. I will try to come up with a velocity correction routine for the future, but just be aware if you're having issues during motion that it has something to do with the simulation types used.

To simplify the scripting, it uses the center of the aircraft to determine LOS. Further enhancements to that would probably be considered only for the TKOH version which will see modifications to the sensors and database scripting.

I'd double check and make sure you're using the controls file for A3 and not the one for A2. Also, what other mods are you using? Gun Burst: CHANGELOG v1.31 - ... - Gun burst no longer forced time restriction. Gun now has overheat tracking and overuse can result in gun jamming. ... An LOS is required for an LOBL launch. LOAL does not require an LOS but it will be inaccurate without it. The 114L is pure fire and forget while the 114K requires steady designation for the duration of the missile's flight.

Need more information - are you starting in flight or on the ground? If on the ground then you have to turn on the battery before the electrical systems can be turned on. If in the air then something is missing or being interfered with.

1 - Two arrays control whether incoming missiles are classed as IR or RF, the defaults are: fza_ah64_mis_ir = ["M_R73_AA","M_Strela_AA","M_Igla_AA","M_Stinger_AA","M_Sidewinder_AA","fza_fim92"]; fza_ah64_mis_rf = ["M_9M311_AA"]; If a missile isn't in either array then it is assumed they are RF. Add the class name for the missile to either array to set which jammers/countermeasures affect it. 2 - You would have to modify the config to get flares and add support for the BIS default missile warning/spoof system. Editing the model(s) is not allowed at this time.

There seems to be an issue in the ArmA3 controls file with two players in the same aircraft related to the cannon tracking. ArmA3 may have changed how animations are handled since the mechanic was tested in ArmA2 and worked fine.

The CPG cannot use HMD or AUTO tracking modes unless heads down. This was to correct a problem where the gunner's view is linked to the gun's aiming direction and these modes interfered with the viewpoint, causing jumping around, etc. When looking through the optics they function normally for the gunner; AUTO mode only works with a target acquired outside of the optics. The A3 version doesn't have this limitation though it brings back the mentioned view bug - this was done as the CPG can take flight controls which removes the viewpoint problem when active.

The laser only works when using heads down for the gunner; when you exit heads down view the laser will stick to the last position it was looking at when you left heads down.

In multiplayer (this goes for ArmA2 as well): - If the gunner is not present nor local to the pilot (that is if he is an AI unit not under the command of the player or a different client), the pilot cannot change weaponry. - If the gunner is present and local to the pilot (an AI unit under his command) he can change the aircraft weaponry. - If the gunner is a different client then the pilot cannot change the weaponry nor take control of the gun. - The MPDs will have to be initialized by both the pilot and the gunner in multiplayer. This can be done by using the crosshair action on the MPD DMS menu button (the small M button on the lower left hand corner of all MPDs). ---------- Post added at 19:07 ---------- Previous post was at 19:06 ---------- Due to an unknown cause, sometimes the pilot and the gunner cannot get a heads down view. This can usually be fixed by getting in and out of the helicopter. This is only in ArmA3; ArmA2 is unaffected.

We aren't really porting it so as much as giving people a functioning ArmA3 version; I've had a lot of people asking me about moving it over but the fact is we're just not ready for it. The goals we had in mind work better within the framework of TKOH, not ArmA3.