franze

Ok, this will be a somewhat lengthy post. When we first started this, we had planned: - A minimum of 5 variations of AH-64A and AH-64D. - Campaigns for AH-64D, AH-64D Block III/AH-64E, and AH-64A. - A kind of career hub a la Longbow 2 that would track score, awards, etc. - A minimum of two terrains, 40x40km in size. - Various hostile/friendly units, such as SA-9, SA-6, Patriot, etc. to fill gaps in ArmA2's lineup. - Expansions into other variants of the Apache like Israeli, Dutch, United Kingdom, etc. and associated 'mini-campaigns' for them. - Much more vast single and multiplayer missions - I didn't really accomplish what I'd hoped to with the ones included. - In depth, as close as the A2 engine could get, simulation of Apache systems - essentially, aiming for more than 'tab lock' that virtually all A2 vehicles use. Immersion was the key word. As we found out, these were (and are) lofty goals for a 2-3 man development team. What we ended up with: - The terrains were a BIG one. Making new terrains is a massive undertaking, even if one uses 'degraded' flight simulator details. I got as far as making a basic terrain and a few tree models before I decided it would take too much work to get to the point we needed. - Making just one variant of the AH-64D proved to be a huge challenge, much less 5. Even then, we technically have a Block I, not a Block II, given certain features. - Doing a set of campaign missions is not an easy task. While I had hoped for 30 mission campaigns, reality sets in that going with an 'impersonal' Longbow 2 style campaign leaves a huge swath of scripting work with mission generation in a semi-dynamic campaign. This is why the included 10 mission campaign became chained together as it was. I would call it a Comanche Gold style campaign. The training missions/campaign was a lot of work as well, especially for Froggyluv who voiced a huge number of lines as the instructor. I think he did a great job at being the clear, understandable voice for these missions. - Making additional low-detail units is a lot of work, too. I tried recycling some very old Mi-28s that I built in the FP era but in the end I never really used them. Given this, I never recycled the units I made to be used with the Su-17 in ArmA, primarily because they were unfinished and didn't really apply to helicopter operations. - Around the start of development, I ended up going back to college part time with a full time job. This put a huge damper on the work I could get done, especially scripting. Try as I might, scripting wizardry seems to come best at midnight through 0300 rather than 9-to-5. This is difficult to accomplish when your job dictates a 2100 bed time and a 0500 wakeup and college work often takes weekends. - Some features were probably way too ambitious and poorly planned. Engine startup is one of them as ArmA2 doesn't have much beyond 'press Q to start'. I'm still not pleased with the mechanic we have to use to bring it all together in ArmA2 for complex startups. I'm also not pleased with the limitations we had to work with to get our digital displays in place; NouberNou has indicated that an external DLL system might allow us more flexibility there, but I haven't looked into that much. As it stands, we used model.cfg and hiddenselections to get where we needed to go and that limited us to the 256 bone limit. Performance of the addon suffers as a result of our high bone count which hovers around 200 bones. I had planned to combat this by trying some virtual displays and a lite or limited model that would cut the bone count down to essentials, but never got to it. Some immersion would also be broken this way. - The automatic gun and rocket system leaves a lot to be desired. Yes, it works to some degree, but my ballistic arithmetic leaves a lot to be desired. The scripting doesn't properly take into account all variables that apply to a gun or rocket solution and has some very problematic issues, especially at long range. - Missile guidance still isn't functioning the way I'd like it to. It works to an acceptable level but in BVR conditions it's more troublesome than I'd like. - Thermals! Holy cow, this is a sore spot. Yes, they work to some degree... But not like the real thing! Only really good for picking out targets rather than pilotage. Unfortunately we can't do much about this, which led to compromises such as NVG operations. - Multiplayer integration isn't as good as I'd like. Target sharing in the current public version is bugged (fixed in development build) and remote SAL designation is difficult to use. Beyond that I had wanted to do other things like being able to view a remote Apache's TADS viewpoint that I never got around to. - ASE/missile defense did not pan out as I'd hoped. Part of this is the SA-19 in the game is a bit odd, having an incredible velocity and hit potential and it's the only radar guided SAM in the game by default. A better prototype was in the Su-17 - SA-6 integration I did in ArmA, but that would have required a number of custom SAM systems to properly do and I was unwilling to make or modify the existing SA-19 to fit that. In basic terms, the default missile guidance used by BIS is a simplified, pure pursuit mechanic (I like to call it 'lag pursuit) that makes for inaccurate missiles, so BIS made up for that by making the SA-19 missiles faster. In the end, while we accomplished a lot, we didn't go as far as I wanted to. I'd like to think that we did prove you can make a very good and in depth vehicle in ArmA2 if you're willing to put a little bit of effort into it, but it is by no means the ideal way to go if you're looking for a higher level of fidelity such as DCS. On the other hand, what gets traded for fidelity is made up for by immersion; the flexibility of ArmA2's editor and scripting allows for scenarios to be put together that aren't possible in a simulation like DCS. One thing that always bugs me about a lot of addons out there is the creators put a lot of work into the addon but virtually nothing beyond that. It's handed out in a 'here, do what you want' fashion and there's a lack of context. This isn't exactly bad, but I believe that an addon should include a few scenarios to provide context and show what it can do. Given that scenarios operate on the same basis as a lot of addon scripting, it doesn't take much to make a basic mission. The single mission "Ground Attack" I included is like this, as it's based on the old "Ground Attack" missions from FP. A simple 'go here, blow up targets, come back' can make a world of difference for an addon. Perhaps that may be asking too much for the typical addon maker but I believe it is worth it in the long run.

Yeah, that's the way it's supposed to work in the real world. ArmA only sees one engine though and I never got around to how I might script single engine operation. TKOH already has that built in of course. But basically: Press the illuminated FIRE button to get the RDY indicator, then press the primary or reserve discharge buttons. They've tried to do that with ArmA3 to some extent but it's not as robust as we'd all hope for. The AI's piloting ability leaves a lot to be desired, that is a fact. I've tried a lot of scripting commands to try and get the pilots to do certain things but they seem to be ineffective on the whole. At least in TKOH and ArmA3 the gunner can take control of the helicopter if he's the group commander. One of the key things we were trying to do was prove that ArmA could be used to make a halfway decent vehicle game/'simulation' beyond ground/infantry, just that doing so took some work and creativity to attain the goal. I think tomorrow I will do a writeup of what the original goals were and how far we had intended to go a few years back when we started all this. Something for me to do at work. :o

I didn't plan out the training missions in the best way; unfortunately, when you're the scripter you tend to forget that some people may need more guidance than what you think is enough. Usually both fire bottles are sufficient to put out fires, it's only very rarely that they fail to do so! The training campaign is also optional and doesn't have to be played in sequence either. Essentially, the pilot and gunner are restricted to one 'optic' viewpoint; that is, they can't toggle between TADS or PNVS respectively. The game does have a camera function but the problem then becomes when you use a scripted camera, you lose all control. This is unfortunate as it prevents us from doing fun things like fly by cameras, missile cameras, target cameras, etc. The PiP capability of TKOH and ArmA3 help somewhat but they are still imperfect solutions. That being said, being able to use both seats at one time wasn't something we experimented a lot with. We only extensively tested with two crew integration; a huge part of this was making sure that everything would function properly in a multiplayer environment, which is finiky in the ArmA/FP series. What ended up being released was not nearly the amount we had planned to release.

If the primary bottle doesn't put out the fire, you can use the reserve bottle, or as a last ditch effort you can land and turn off the engines.

PNVS can be linked to TrackIR or similar head tracking device, thus enabling you to move your head and get a thermal viewpoint independent of where the aircraft is facing. Barring that, it is linked to the numpad view keys for elevation and azimuth and can be used to aim the rockets and guns. You will find it more useful in the combat missions where it is useful to pick out infantry in cover.

We didn't bind the IHADSS toggle to a hot key due to the limited number of keys available for use. I tried to restrict usage of keys to combat critical functions and leave the remainder for future functions (given our plans at the time).

Helicopter handling is controlled through balance of the geometry LOD in the model files, not scripting. There are no config or scripting controls for aircraft handling. To change handling you would have to rebalance the geometry LOD.

Yes, it is in the same class of issues that NouberNou reported here: http://feedback.arma3.com/view.php?id=16115 I don't expect much from the Helicopter DLC. ArmA3 was originally going to have the TKOH FM for helicopters available and it didn't ship with it, so I am skeptical that the DLC will contain what we hope it to.

Can't do anything about it. Related to physX bugs. Upon further consideration, I am pulling support for the ArmA3 controls file. I am tired of trying to support a half-baked implementation for ArmA3 and then seeing a ton of issues that I can't do anything about. I can't remove download links from the various mirrors out there but I will no longer be updating the A3 controls file.

There's not much I can add that hasn't already been touched on in this long thread. I believe a number of people are incredibly naïve about what some mod/addon makers goals are and their motivations, especially when there's really not a whole lot of people out there in this community capable of making content equal to or superior to base content. Most of this has already been addressed so I won't bother placing my 2 cents in on that. What I see being hurt the most by any kind of paid content is one of innovation. As the saying goes, any idiot can make things more complex but it takes a stroke of genius to move in the opposite direction. In our context, this means that we can come up with some incredibly complex stuff that breaks the mold of what we think is possible or impossible with the game, but there will be caveats to doing that. Namely you will have a lot of restrictions and limitations with innovative features. 'Wait, how can that be a bad thing? That is great!' you might say. Well, not exactly. Consider that the base ArmA3 game came out with a lot of bugs and problems; this is typical of software releases. Most buyers expect that the product they paid for will eventually be patched or made to work well enough to suit their standards. Everyone wants to get their moneys worth out of a product and software is no different. Now, consider your typical addon/mod: Even the most basic often has some galling issues or bugs in a released state. We typically accept those because we get the product for free. If it doesn't satisfy us then no big deal, didn't cost a dime. Once you start throwing money into the equation, it starts to look and feel like a ripoff when you have a 'game breaking' issue that the creator is unable to fix either for technical reasons or time reasons. 'No big deal! They can just get a refund then!', you might say. For a typical product and creator, yeah probably not a big deal; if you make a Mi-28 that looks like ass and isn't worth a damn in the game, then it might give you motivation to go back and try again with the experience you've gained. The trouble starts when the content starts to get so far out there that it can't really be fixed in a way to satisfy your typical consumer. Let's say you've got an innovative artillery support addon that works really well in the single player game, but has significant issues in the multiplayer game. Not that it doesn't work; just that it has certain issues that you as an addon maker do not have the capability to fix due to either engine limitations or some other issue outside of your control. It won't matter how much you try and explain these issues to people - it's broken and you will fix it, from their perspective. Doesn't matter how innovative the content is or how well it works despite the limitations; those small limitations will matter to people and they will matter a great deal since they will have already paid for a product and expect to get their moneys worth out of it. End result is that you will have content creators who will fear thinking outside of the box because it will be too risky and too much trouble to try innovative new features. That means the content we'll be seeing will end up being very conservative and amount to not much more than base content with a different skin, for all intents and purposes. Take a quick look around and you'll see this same scenario is already happening - with free content.

The next time ArmA3 compatibility questions come up, I am simply going to link to the original post I made on the subject here.

I'm sorry, I can't replicate this problem. Are you using any other mods or addons? Keyboard or joystick?

It would have to be because otherwise there would be loads of errors and you would be not able to drop the Apache into the editor and go - the A3 controls file changed the default crew and inheritance of classes.

As I've stated before, there can be no fix until the underlying issues with ArmA3 are fixed by BIS. ArmA3 is not our focus at this point in time because of the many issues involved with getting all features to function as desired. The ArmA3 controls file is available purely to allow you to use the addon in the game in some capacity; the focus still remains in ArmA2 and TKOH. Now, as I am tired of posting the same explanations over and over again, the next time ArmA3 compatibility questions come up, I am simply going to link to the original post I made on the subject here.

The remote target script only works with a laser designator weapon from ArmA2, specifically "Laserdesignator_mounted". I don't believe such a weapon class still exists in A3. You can try and get around this with a custom script though: _unit = _this; while{alive _unit} do { _laserpoint = lasertarget _unit; if(!(isnull _laserpoint) && !(_laserpoint in fza_ah64_desiglist)) then { fza_ah64_desiglist = fza_ah64_desiglist + [_laserpoint]; publicvariable "fza_ah64_desiglist"; }; if(isnull _laserpoint) then { fza_ah64_desiglist = fza_ah64_desiglist - [_laserpoint]; publicvariable "fza_ah64_desiglist"; }; sleep 1; }; fza_ah64_desiglist = fza_ah64_desiglist - [_laserpoint]; publicvariable "fza_ah64_desiglist";

There have been a variety of holdups and issues with the project. I'll try to describe a few of them here. Some are specific to ArmA3; some are generic limitations spread across the RV engined based games (to include TKOH, ArmA2, ArmA3). One of the first and major ones is the bone limit. Currently, the max supported bone limit is 256 bones. This seems like a lot and for the most part it is; the problem is that when you want to get real in depth like we did, you end up running up the bone count pretty quick. This presents some other problems as well which I'll delve into later, but main thing is that everything from the MPD pages to the rotor blades use bones. This is why some pages are only on the left or right MPDs; the bones they use is too extensive and to duplicate them on both MPDs would not allow bones for other parts of the aircraft. Displays and instruments are another. Currently, there only exists the BIS 'MFD'/'HUD' config section for displaying information in 3D space. The limits are of course you can only have just the one and the information you can display on it is limited, along with tying it into scripting. This makes it a no-go if you want to have realistic displays like we have. If we had a capability to take a canvas and render it on a 2D face (similar to PiP) using a mechanic similar to the way our IHADSS works, we would be a lot more flexible and could cut way down on the bone count. I had at one point in time wanted to do a MFD overlay on the screen similar to the way IHADSS works now but never got around to it. Side note: the original FCR/TSD display worked like this in a prototype form while waiting for the cockpit model to be completed. _X simulation types, introduced in ArmA3, brought on a separate issue. When finding or locating points on the model with modeltoworld and worldtomodel, if a vehicle has one of the new PhysX based simulation types (indicated with a X on the end - such as HelicopterX, CarX, etc.), then there is a disconnect with the model space and the world space. What this means is as the vehicle or object gets variances in it's velocity, the accuracy of modeltoworld and worldtomodel goes to shit. You end up with your model points being 10m behind you when flying backwards, 20m above you when climbing, etc. which means that everything from weapon positioning to click actions are completely FUBAR. This creates further problems because the old physics model doesn't exist anymore (though I'd be hard pressed to find differences between the old physics and the PhysX implementation in ArmA3) which gives you the odd issues with flight physics, center of gravity, and so on. The animate command and custom animations in ArmA3 were changed or modified somehow that results in very bad synchronization of animated parts. What this does is makes it impossible for the gun and pylons to be tied to a custom user animation, which ruins the ability to use the automatic tracking capability and HMD capability for the gun and rockets in multiplayer with two different clients in the same aircraft. When it is just the pilot with an AI gunner there are no issues; it all works the way it's supposed to. When you have two clients in the same aircraft, the gunner can't aim the weapons properly; there is a 5-10 second delay from when he moves the weapons to when they actually aim at the target. This issue does not exist in ArmA2 or TKOH. The end result is that you get two steps forward but two steps back with ArmA3. Yes, we could ditch the click actions and the pylons and the turrets. But those were both very major things that took months (and in the case of the gun turret, years) to implement. It leaves a very sour taste in my mouth to simply ditch those features to get - in effect - a Comanche with a different skin and model.

ASPI is built by a different contractor, when they come off the assembly lines at Boeing they have the old exhaust stacks. AH-64As are all completely gone now as well, the TXNG turned them in a couple years back. The AH-64Es that Taiwan has are equipped with provisions for ATAS. The AH-64Ds that the JSDF have are equipped with the same hardpoints.

In ArmA3 it has 6DOF. The ArmA2 version was designed for vanilla ArmA2:CO which doesn't have 6DOF.

As Nodunit said, one of the issues is HelicopterX causes a desync with the model space and world space; I don't exactly know why, but others have had similar issues with the new PhysX simulations in ArmA3. The second issue is there is a synchronization issue with animations in multiplayer which causes problems with the turret and pylon elevation. This problem makes it impossible for the gunner to effectively use the weapons in either a manual or automatic capacity.

I believe the 'NoHud' issue is related to TKOH not having the HUD definition, but I'm not entirely sure. The TKOH version has been in progress for a while now and I believe I fixed it for that dedicated version. In ArmA3, you need to make sure you use the appropriate ArmA3 controls file (the ArmA2 one doesn't work properly).

Hmm, try adding it to the end of your init.sqf with a slight delay prior to running it.

Can you post a screenshot of how you're using the command?

Yes, has to go in an init line or init.sqf of your mission.