AH-64 Pack

[Guest]

@ dbelnomi

Your question has no relation to the subject all all, not even from a mile away. Please do not derail a thread, stick to the topic and search for a better place to post in.

[redpiano 1]

Hi, have you guys considered making your apache for DCS World? It offers so much more realism and possibilities than Take on helicopters and already has a well established community of flight simmers. Unfortunately they don't have an Apache in development yet, maybe you could fill that void.

[nodunit 397]

DCS already has both alpha and delta models ready to go, they also showcased images of the alpha cockpit long before DCS A-10. They have it they are just..dragging their feet, but delta won't be coming, they already stated that due to classifieds they won't be pursuing that model.

I doubt we will make the switch primarily due to familiararity, while DCS may offer more leeway in the polygons and textures department, and be exclusively oriented to aircraft, we are unfamiliar with it whereas Franze knows quite a lot about this engine, that saves us a ton of time. We also like Arma, a lot, and want to explore it's potential and see just what it is capable of, here, in TKOh and especially in A3.

I guess you could say the project is more about exploration, to see what the engine can do when pushed in certain ways and when you think around the lines...just take the moving map, great example.

Since it's inception in OFP by BAS it had been a static image with a crosshair or other indication of location, as it was in A1, but as the maps grew the option became less viable.

Supposedly RTT was required for a top down image of the map to move and follow your motions, and here we are in A2 without RTT and it has been done, not only that but it's scaleable.

Edited November 14, 2012 by NodUnit

[max power 21]

...while DCS may offer more leeway in the polygons and textures department...

I doubt it does. If it's a directX 9 game it has precisely the same limitations as arma. It's really down to how many textures you wish to use, and how detailed you want each LOD to be.

[redpiano 1]

Well I doubt DCS AH64D/A will come along any time soon. Combat Helo is finally in development again. Your A2 module is coming along..

I just want an Apache sim already.

The reason I ask is, it seems to me from playing TO: Hinds and using various MFD addons for the apache in A2, that it's super limiting. I don't personally want to spend any amount of time learning the complex systems of the apache in the ArmA engine, I do not want to use that scrolling menu to do all the actions on my MFD's and such, it just seems like a horrible engine to develop a complex flight sim; this is apparent to me by the..IMO terrible Hinds addon for Take on is a shining example of this, it's clunky and janky, the physics aren't all there and at all realistic and the engine just doesn't allow modeling of all those complexities in any kind of streamlined or polished way.

I mean no offense of course, quite the contrary I think what you're doing with this addon is insanely cool. It just feels like your efforts are being wasted on this engine. It's fine for infantry simulation, but it is in no way shape or form a quality simulation of vehicles or aircraft.

[nodunit 397]

I doubt it does. If it's a directX 9 game it has precisely the same limitations as arma. It's really down to how many textures you wish to use, and how detailed you want each LOD to be.

Perhaps then the problem is less A2's limit but O2's limit and the presumption that they share the same..I don't know which DX DCS black shark uses, all I know is that looking at those models up close is sheer mind blowing, not a single rough corner, complete smoothness and the texture count is astonishing, you can preview that in the templates on their website.

....

I doubt so as well, not after seeing a fighting falcon and hind cockpit..and nada happening on those, also no offense taken, I understand your concern but I fear you misunderstand our goal. Yes we would love to have an apache as real as possible but at the same time we want to see what this engine is capable of.

I understand that Arma was never meant to be a heli simulated environment, much less a glass cockpit helicopter, but to see what it is capable of makes the effort worth it plenty. Also no offense taken, I understand that you see DCS as superior, and in helicopter versus TKOH you're right. For us addon making is less about an already defined unit but more about exploration, to see what the game we enjoy can do when you push from a different direction. So much of the apache thus far has been based on theory..and all of it has worked.

Granted compared to DCS, just about anything we'd be doing would have already been done, sure..but that isn't the point. In the end the point is that we made an adddon on our engine of choice, and that is this engine, an engine that I personally feel everything is capable of deeper simulation if given the chance, and to see that happen is effort well spent in my eyes.

Also we agree that the action menu is not the best way to get around, which is why Franze made user action commands bind to perform tasks related to MPD and weapon functions, mappable to joystick or mpd's. I am hoping that TKOH will allow us to remove the action menu mostly together and replace it with something more..interactive, but only time will tell.

Edited November 14, 2012 by NodUnit

[max power 21]

Perhaps then the problem is less A2's limit but O2's limit and the presumption that they share the same..I don't know which DX DCS black shark uses, all I know is that looking at those models up close is sheer mind blowing, not a single rough corner, complete smoothness and the texture count is astonishing, you can preview that in the templates on their website.

I'm not sure what limit you're speaking of specifically, but I have not really encountered any texture limit, and there is a 65535 vertex normal limit inherent in directx 9 which translates to roughly 20k polies per object. Even forum members have got by that limit with proxies. But if Black Shark is directx 9 then that helicopter is either under 20k polies (ish) or it is made of multiple objects.

[redpiano 1]

I see so is the video in the first post of this thread no longer representative of how this addon will be controlled?

Anyways, I understand your goal and choice to use A2's engine. I do look forward to playing it myself whenever you plan to release it. Hopefully we'll see it ported into A3 next year?

[franze 196]

When it comes to controls we've co-opted a few that aren't used in helicopters (binocular, salute, change handgun, sight mode) for some functions and used the Custom User actions for a whole bunch of others. Critical/common actions will be useable through keys and only less critical/common ones will be through the action menu. We may have enough spare keys for all actions but that has yet to be determined.

DCS is a good simulation but I feel it is a poor game; it doesn't capture the spirit of the 90s simulations like Longbow, Comanche, Apache, or Hind. I wouldn't mind taking a whack at it as a DCS module, but my knowledge of DCS is virtually nil and to build it up would take several years.

ArmA may not be the best place for it, but I think what we've managed to do so far has allowed us to get some of that 90s spirit into our sails. I won't say that everyone will be happy with it or enjoy it as much as we do but I think we have a fair chance of making our Apache more than just a filler unit for infantry scenarios.

[RSF TheCapulet 59]

Well I doubt DCS AH64D/A will come along any time soon. Combat Helo is finally in development again. Your A2 module is coming along..

I just want an Apache sim already.

The reason I ask is, it seems to me from playing TO: Hinds and using various MFD addons for the apache in A2, that it's super limiting. I don't personally want to spend any amount of time learning the complex systems of the apache in the ArmA engine, I do not want to use that scrolling menu to do all the actions on my MFD's and such, it just seems like a horrible engine to develop a complex flight sim; this is apparent to me by the..IMO terrible Hinds addon for Take on is a shining example of this, it's clunky and janky, the physics aren't all there and at all realistic and the engine just doesn't allow modeling of all those complexities in any kind of streamlined or polished way.

I mean no offense of course, quite the contrary I think what you're doing with this addon is insanely cool. It just feels like your efforts are being wasted on this engine. It's fine for infantry simulation, but it is in no way shape or form a quality simulation of vehicles or aircraft.

This to me, is essentially like complaining to a friend about free cannabis before you even get a chance to smoke it. No matter how politely you can say it, it still makes you look like an ass.

[noubernou 77]

Also we agree that the action menu is not the best way to get around, which is why Franze made user action commands bind to perform tasks related to MPD and weapon functions, mappable to joystick or mpd's. I am hoping that TKOH will allow us to remove the action menu mostly together and replace it with something more..interactive, but only time will tell.

It already could. :( Fully clickable cockpits are entirely possible in A2.

[redpiano 1]

When it comes to controls we've co-opted a few that aren't used in helicopters (binocular, salute, change handgun, sight mode) for some functions and used the Custom User actions for a whole bunch of others. Critical/common actions will be useable through keys and only less critical/common ones will be through the action menu. We may have enough spare keys for all actions but that has yet to be determined.

DCS is a good simulation but I feel it is a poor game; it doesn't capture the spirit of the 90s simulations like Longbow, Comanche, Apache, or Hind. I wouldn't mind taking a whack at it as a DCS module, but my knowledge of DCS is virtually nil and to build it up would take several years.

ArmA may not be the best place for it, but I think what we've managed to do so far has allowed us to get some of that 90s spirit into our sails. I won't say that everyone will be happy with it or enjoy it as much as we do but I think we have a fair chance of making our Apache more than just a filler unit for infantry scenarios.

Well that sounds much better, the scroll menu is just bad UI IMO.

As for DCS, I never got a chance to play the old Janes longbow or any of the other games mentioned so I really have no idea what that really means but I hear it a lot from others. DCS is just sort of the only option these days and as they already have a 3d model as well as all the necessary weaponry(hydra's, 30mm cannon and Mavericks) modeled, the only necessary work would be the avionics and cockpit I would assume.

I look forward to the addon, I've been following it for a while now and it looks excellent, again not meant as a complaint or anything just look at it as a fan's concern I guess :P

---------- Post added at 02:11 ---------- Previous post was at 02:09 ----------

This to me, is essentially like complaining to a friend about free cannabis before you even get a chance to smoke it. No matter how politely you can say it, it still makes you look like an ass.

Not only is your analogy stupid, it doesn't really apply. I'm not complaining about the addon, or anything for that matter.

Thank you for your replies Nod and franze, much appreciation and I wish you luck.

[franze 196]

It already could. :( Fully clickable cockpits are entirely possible in A2.

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.

Well that sounds much better, the scroll menu is just bad UI IMO.

As for DCS, I never got a chance to play the old Janes longbow or any of the other games mentioned so I really have no idea what that really means but I hear it a lot from others. DCS is just sort of the only option these days and as they already have a 3d model as well as all the necessary weaponry(hydra's, 30mm cannon and Mavericks) modeled, the only necessary work would be the avionics and cockpit I would assume.

I look forward to the addon, I've been following it for a while now and it looks excellent, again not meant as a complaint or anything just look at it as a fan's concern I guess :P

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! ;)

[redpiano 1]

Without a doubt you're right, your external is better than theirs as theirs is just an AI unit not meant to be fleshed out.

And my bad on the hellfire, actually don't know if they have those implemented. I know they don't have the Flechette hydra's implemented(will that be on this addon? GOD I hope so!)

Of course the benefit of making a DCS module would be that it's to be sold for 40$, maybe that would give you incentive? I don't know if ED does anything in terms of funding during development or not..hm. But blah, I'm sure it takes much more work than I can imagine but one can dream can't he :)

[franze 196]

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.

Edited November 15, 2012 by Franze

[noubernou 77]

BTW your inbox still works right? I sent you a PM months ago about those interviews.

Yea, crap, I totally forgot (I am not the most diligent at replying to PMs sometimes, infact I have two unread messages in there from like a month ago I think... eek).

I'll dig through Skype sometime today and try and find the info.

Also a heads up, check the next update of ACE, I added in some functionality to hand off guidance of missiles from the launcher to the person using the laser designator in ACE, it might be something you guys want to look at for the hellfires as well (since the location of the designator is updated quicker on the machine where its being generated).

[Sealife 22]

It already could. :( Fully clickable cockpits are entirely possible in A2.

Have they fixed the issue where in flight your reference point is not updated quickly enough , I tired intersect in the geometry and campos/curor target etc . but unless in a static postion , hovering for example , the results of both intersect and campos ,cursor target and all where very unreliable. Planes where impossible but helos ok if you were allowing for 20 30% bad working . Viewgeomtery was a bitch too worked better without that but alas not plausible.

[noubernou 77]

Have they fixed the issue where in flight your reference point is not updated quickly enough , I tired intersect in the geometry and campos/curor target etc . but unless in a static postion , hovering for example , the results of both intersect and campos ,cursor target and all where very unreliable. Planes where impossible but helos ok if you were allowing for 20 30% bad working . Viewgeomtery was a bitch too worked better without that but alas not plausible.

If you do it using a frame handler it is. Everything is where it should be every frame and the code is guaranteed to execute before the next frame is rendered. Spawns in SQF are the devil.

[franze 196]

Yea, crap, I totally forgot (I am not the most diligent at replying to PMs sometimes, infact I have two unread messages in there from like a month ago I think... eek).

I'll dig through Skype sometime today and try and find the info.

Also a heads up, check the next update of ACE, I added in some functionality to hand off guidance of missiles from the launcher to the person using the laser designator in ACE, it might be something you guys want to look at for the hellfires as well (since the location of the designator is updated quicker on the machine where its being generated).

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?

If you do it using a frame handler it is. Everything is where it should be every frame and the code is guaranteed to execute before the next frame is rendered. Spawns in SQF are the devil.

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.

Edited November 16, 2012 by Franze

[scarecrow398 43]

Also a heads up, check the next update of ACE, I added in some functionality to hand off guidance of missiles from the launcher to the person using the laser designator in ACE, it might be something you guys want to look at for the hellfires as well (since the location of the designator is updated quicker on the machine where its being generated).

Cool.

As long as you don't do magnetic declination we're happy >_>

[noubernou 77]

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?

Basically it looks for a laser designator and then gets its owner (we have a variable in ACE we set on designators for the owner). If the owner is not the player then we destroy the missile in flight on the machine that fired it, transfer the state of the guidance system, and reinitialize the guidance function (which runs in a per-frame handler) and recreate the missile on the machine that owns the laser.

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.

As long as your code is tight you can get away with a lot, both ACE and ACRE run numerous things every single frame with minimal overhead, maybe 1-5FPS loss depending on the current in-game situation. The results are far better than the alternatives where scripts can become detached from the action (resulting in missiles flying wildly in guidance code, unexpected delays, mis-timings, variable collisions, etc), which is often the case in almost any normal mission load.

Keeping as much as you can out of the scheduler is just a good rule of thumb in A2, since the scheduler is very poorly optimized and easily overrun by both well made and poorly made scripts.

BIS actually gave us a PFH event, but its not stackable, meaning another addon could override it. The alternative method is to make your own using the way I wrote it for CBA, which is a map control hidden on the screen using the onDraw event, which fires every single frame.

As for clickable cockpits, you'd have to optimize the search algorithm for cursor location if you have a lot of buttons, but it wouldn't be hard (make zones, and subzones for cursor position and then only search buttons/switches, etc that are in those zones).

[franze 196]

Basically it looks for a laser designator and then gets its owner (we have a variable in ACE we set on designators for the owner). If the owner is not the player then we destroy the missile in flight on the machine that fired it, transfer the state of the guidance system, and reinitialize the guidance function (which runs in a per-frame handler) and recreate the missile on the machine that owns the laser.

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.

As long as your code is tight you can get away with a lot, both ACE and ACRE run numerous things every single frame with minimal overhead, maybe 1-5FPS loss depending on the current in-game situation. The results are far better than the alternatives where scripts can become detached from the action (resulting in missiles flying wildly in guidance code, unexpected delays, mis-timings, variable collisions, etc), which is often the case in almost any normal mission load.

Keeping as much as you can out of the scheduler is just a good rule of thumb in A2, since the scheduler is very poorly optimized and easily overrun by both well made and poorly made scripts.

BIS actually gave us a PFH event, but its not stackable, meaning another addon could override it. The alternative method is to make your own using the way I wrote it for CBA, which is a map control hidden on the screen using the onDraw event, which fires every single frame.

As for clickable cockpits, you'd have to optimize the search algorithm for cursor location if you have a lot of buttons, but it wouldn't be hard (make zones, and subzones for cursor position and then only search buttons/switches, etc that are in those zones).

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.

[Sealife 22]

If you do it using a frame handler it is. Everything is where it should be every frame and the code is guaranteed to execute before the next frame is rendered. Spawns in SQF are the devil.

That's something I never tried, look forward to seeing it work someday , I moved on to the TOH Engine now it cuts a lot of the need for additional resource and with rearmed you can get both of both worlds .

However I understand for yourself its not option because your making things for Arma community , I wish good luck with your implementation and again will look out for the videos etc.

[jumpnjack 10]

Hi, have you guys considered making your apache for DCS World? It offers so much more realism and possibilities than Take on helicopters and already has a well established community of flight simmers. Unfortunately they don't have an Apache in development yet, maybe you could fill that void.

Someone is in the wrong neighbourhood lol, joking. But you cant expect to come on BIS forum and try to convert addon makers. These guys pretty much live and breathe Arma I think. I actually enjoy DCS FC2 and since im not a hardcore flightsimer its a good fit for me.

[nodunit 397]

He's not wrong, many of us are akin to drug addicts in relation to Arma, or modding Arma.