franze

Prior to this we did have a mechanic for starting up the engines with several clicks but that was linked to the action menu, so I removed it when I built the new script. An in-depth start up is still on the table, depending on what info we can put together on the start up and how to integrate it. If we put in a complex start up it will likely remain an optional feature, for A2 anyways. If we have the time to move on to TKOH then it will likely be a permanent or required function. Given that we still don't have CLASSIFIED Manual #57373-ZFTWOMGWTF-28-a, "Piss tube operations and usage for Attack Helicopter, AH-64D" and therefore are not eligible for DCS, I'd say we're still working in ArmA2-land. ;) Thanks Nouber, pretty much everything you see in that video was possible with your help. We were able to implement things that we considered a bust before but now they're a lot more intuitive. The unfortunate side effect is now I have to document a lot more than just key bindings. :dead:

If we go to the trouble of doing new crew models then I see no reason why we couldn't do some additional tailoring to encompass more than just Apache crew. Also, new video up demonstrating cockpit interaction (big thanks to NouberNou on helping to get this working!):

We want to do new crew models complete with helmets, but that's secondary to completion of the helicopter.

Have a few voice acting roles I need to get filled: - One American male - One older American male (30s, 40s) - Three Two eastern European male - One eastern European female All lines are in English, but your English doesn't need to be perfect. If you're interested, send me a PM.

Those of you with joystick problems have already checked the Controllers>Customize options that ArmA2 provides?

Mouse n' keyboard will still work but there will be a learning period since the agility - and instability - is increased compared to BIS helicopters. Sorry that we don't have much to show right now, been working on documentation, missions, and scripting. Scripting refinements and fixes have been going through as we try to iron out bugs and implement planned features. Things are getting done and we have only a few major hurdles left before we can go for an initial release.

The UAVs have a gunner turret; to get a driver turret you basically have to work around using custom animations. That is what we've done to enable the pilot to aim the M230 in addition to using PNVS.

You could borrow our method for doing PNVS by using the driverview memory point and binding it to a user animated turret point - it'd only work for one pod but it would enable you to get a controllable view through the pod with the optics/heads down view. With a bit more scripting you can make a laser designator for it, etc.

That's VBS2, not ArmA2. That's possible in TKOH but not ArmA2.

Actually we're still in alpha as there's features we still need to implement. When those features are implemented we will be moving into beta which I hope to not take nearly as long as alpha has.

Textures are set by a script after everything has initialized, it is entirely dependent on mission settings for what a texture is set to. This may be changed to link with the arming system but that might be a little complicated early on. The campaign goes on, usually a mission every couple of weeks. We don't plan to release this then expect everyone else to make missions for it.

So not much to report on this time around, been spending most of my time building missions for the main campaign while Nod plays around with the texturing. Nonetheless, the first glimmers of the skin system have been put in place: This will allow us to implement our damage system in the future while serving as a baseline for customizable skins. Skins can be referenced exclusively to one client and what they might have on their hard drive, the mission file, or a pbo file. Skin files do not have to be shared by all clients. Skin files can be any size so as long as they follow the ^2 rule. That's all I've got for now, enjoy!

In the AH-64A unclass manual there is a switch for LOAL mode which has settings "OFF", "HI", "LO", and "DIR". Manual says that selecting "OFF" disables LOAL mode and forces the missile into LOBL mode. This is good info too, although due to the nature of the scripting the SAL missiles already behave like this as long as they're in the terminal phase.

That's some good info anyways and I think we can implement it; however I see some controls in the AH-64A manual that indicate LOAL mode can be turned off and the missile forced into LOBL mode. Is there any more solid information on that?

gator, that helps a lot and I'll change LOBL guidance accordingly to match.

FYI, a few pages back we discussed that if it appeared ArmA3 was right around the corner and we would be unable to get it completely done for A2, we would release in alpha/beta state.

It doesn't present that much of a problem as originally it was designed so that dropping the tank would add X amount of fuel to whatever fuel is left, but that could be changed so that the total fuel is reduced when the tank is dropped. Altering the FM is a non-isue IMO. Lastly, you don't need any FX for a fuel tank since JP-8 isn't nitroglycerin like Hollywood would have us believe.

That mode of operation for LOBL was through information gathered from a variety of sources, so I've no doubt the real story may be totally different. Most sources seem to give the impression that LOBL mode requires laser energy prior to launch - this may be referring to an older model of missile rather than the most recent variants. If the latest models made in the past decade don't need laser energy at launch in LOBL mode then that is certainly changeable, though it'd be nice to know if it was the same for older versions.

At the time that old picture was taken, the Kiowa we made for FP wasn't even finished yet - note all the grey on it. I would have direct linked to that picture to show a better comparison but that one is 55KB over the limit and I was too lazy to resize it. Remember, that's from summer of 2005! That was the only scratch built OH-58D made for FP at the time and we built it even though the OH-58D was already in the game courtesy of BIS. It was never ported past FP so the ones you've seen in A1 and A2 are ports of the BIS model, not our old one. I think Pufu has intended his OH-58D purely for ACE.

Another update, not much major to talk about, long work week so not much done. Thanks to NouberNou's help we've managed to get a per frame eventhandler in place which will be used for timing critical scripts, which is fortunate as we already had a few that needed to be placed in a fast running environment. This will also make certain damage effects run a lot smoother. We improved HELLFIRE functioning by introducing an obscurement element, so that if you do not have an LOS to your target you cannot use LOBL missile launch modes. LOAL modes on the other hand can be launched without having an LOS to the target, though you must get an LOS while the missile is midway through it's flight (for SAL missiles). RF missiles LOAL mode only works against static targets since this forces the missile to rely on it's own radar instead of getting data from the FCR and thus cannot receive accurate target data en route. SAL missiles still require a constant lock on the target to ensure a hit. The FCR scripting incorporates this LOS scripting so now it is much more accurate than in the past where we had to rely on a different mechanism to block certain targets. LOS elements are indicated on the HMD so you know when you have a good lock or not; this applies to all weapons available to the aircraft. I'll finish up with a few pics: And see how far we've come in 7 1/2 years! OH MY GOD MY EYES Bonus screens: Loading Pad 1 Loading Pad 2

Does the remote unit get a kill counted this way? Even if not that's a cool way to solve issues like that, though admittedly we haven't seen anything like that yet. That's interesting to know considering what the scheduling engine was originally built for. Most of what we have so far is not timing critical save for a few things so using a per frame handler would be restricted to those critical things.

The Addon Request Thread is the place to ask.

Haven't even gone that far yet although the hooks are there. How does this work with a custom guidance script local to the firing turret? What are we looking at in terms of CPU cost here? We're looking at some very heavy usage and moving around the scheduling engine might make for some bad situations (remembering the days of ArmA with no scheduling engine). I've tried to abide by a 3ms limit to keep things from getting too clogged up although sometimes you just run out of the buffer. Curiously enough, my missile guidance wasn't happy until I went to a 5ms delay. Also, any outside addon dependency is something we've been planning to avoid. I consider CBA and ACE great, but if they're requirements to getting any of this done then that isn't the route we want to go initially.

So far we have HELLFIRE A, C, K, L, M, and N types made, with possibly a couple more down the line (F and P likely). Hydra warheads are currently M151, M229, M261, and M255, with an option later for M257 and M156. We're also not in this for the money; this is a call-back to the one we originally made in FP, only this time we actually know what we're doing.

I know, I know, but we've been sitting on that while trying to sort out a whole bunch of cockpit issues. BTW your inbox still works right? I sent you a PM months ago about those interviews. I would argue that our external model(s) are better than DCS's Apache models. Don't get me wrong, the DCS folks did well - they just didn't do well enough. The HELLFIRE missiles, Hydra rockets, M230 cannon, and Stinger missiles would all take plenty of additional work to implement properly. Just because they're already in place does not mean they're done right - that's kind of like saying the AH-64 weapons already in the game are all we need. That simply is not true. In addition the cockpit is probably the most time consuming part of this whole project and thus far we've only barely gotten close to completing the D Block II pilot's cockpit; we haven't even started on the CPG cockpit yet. This ignores our requirement for the A cockpits and D Block III cockpits (yes, there are differences!) which will be necessary for our project. Lastly, we'd also have to implement a flight model in an unfamiliar engine. So far we've worked for a bit more than 2 years on this project just for A2 and I'm sure a module for DCS would take just as long, if not longer, to do. Keep in mind we both have day jobs, too! ;)