Scott-S6

As I understand it missiles exist outside of the aircraft module (which makes sense since you don't need to have the module to be shot by the missile...) and require ED to integrate them into the core engine. HB could do the work and hand it to them as a finished package but there is still a degree of work and cooperation required from ED to test and integrate. Testing will be unusually complex if any of the unusual behaviours are simulated. Many of the current, much simpler, missiles are simulated rather crudely, suggesting that this is not an area ED sees as a priority. Also, flying a typhoon doesn't mean that he has much insight into the detail of the missile's decision making process and behaviours, especially since he will not have had the opportunity to observe it's behaviour in combat at all, let alone the many times that would be required to infer that. Even if he did have that insight (dubious) if public documentation is not available then it can't be used in the module. So the question remains, do we have sources detailing the decision making processes and behaviours of the meteor?

That ability to selectively coast while retaining the option of burning to maintain speed while manoeuvring make the meteor drastically different. Is the data out there on the missile decision making process in order simulate it properly? Will ED do the work (since it would fall to ED rather than heatblur) or it will it just be an amraam with different stats? (which would be disappointing)

ED can't meet that standard with their own projects so I've no idea why you think they should impose that standard on 3rd party developers.

I'd say that it's possible that it's likely that he pulled that statement out of his butt.

What's the point of this kind of speculation? "Really close" could mean lots of things. You say it's "possible" that it's "likely" before Christmas. That statement is so vague as to be meaningless.

They'd also need data to build that flight model and an expert with plenty of time flying an F15E with no CFT to validate it. That is tricky, to say the least.

Perhaps if you put your mic at the other side of the room you can enhance the realism?

There is a very small but vocal part of the community that flies PvP without concern for scenario/operational accuracy. (Which seems a little perverse to me since that gives you a "competitive" game with no attempt whatever at balance). They see an F15E without CFT as providing a competitive advantage to them and they don't care about capabilities since all they do is dogfight.

If you update infrequently, which seems plausible for someone that described themself as scared of the VPV software) then it's rather more likely that the accumulated updated will contain one of those that renames the devices.

I suspected as much. Terrain masking absolutely will be functional then.

Before you do a firmware upgrade on it check back in - it'll change the name of the device which means all your binds are gone... You can make it easier to sort though.

I disagree - it isn't simple at all, it's much more complex than typical course corrections, especially since it may well involve the missile breaking line of sight with the launching aircraft. How will corrections be transmitted? Will the missile be handed off to the aircraft that's illuminating the target to receive corrections? Those corrections are now much more sophisticated and require the guiding aircraft to have accurate positional data of both the target aircraft and the missile. Is the guiding aircraft going to paint the missile? The aircraft thats illuminating the masked target may not even be in a position do so.

Yep, just give us appropriate commands to bind to and everyone can utilise them however they like.

A definitive update of what? It's being worked on. They don't have a release date. That's it. The F15E guys have been waiting over a decade for a release date and they still don't have one...

Clearly this is because of the lack of representation. Although men have no problem playing a female character since there isn't actually any reason to make a game character a self-insert of yourself in order to enjoy a game, especially a game with essentially zero characterisation, women apparently require a female character in order to play according to Elphaba.

The sides setting doesn't actually do anything. It's just so that if you have two sticks (for space games) you can tell which is which.

Easier to just get rid of pilot models and voices entirely.

I'm not American so none of the WSO voices are "inclusive" for me. Should that be a problem?

This post didn't age well.

When you set duplicate desktop for the main monitor pair they'll both switch to the lower resolution. It's an extra step to ready your pit but it will solve the problem. Keep that one in mind if you don't find a lua fix.

I would suggest setting the left monitor to X= 0 and updating center and right accordingly. I do not believe you can have negative values, 0,0 is the origin. You may also need to add this so that the UI isn't horrible. GU_MAIN_VIEWPORT = Viewports.Cente

The EHSI in the F16 is already configured for export, just create a viewport called EHSI. For any other displays you want to export, like the DED, you need to edit the LUA file of the relevant display and create a viewport. The DED's LUA is at: DCS World\Mods\aircraft\F-16C\Cockpit\Scripts\Displays\DED\indicator\DED_init.lua Add these two lines somewhere in the file (I usually put it at the end) with XXXX replaced by whatever you want to call the viewport: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("XXXX") Then create a viewport called whatever you replaced XXXX with.

Viacom just does comms. You're asking for a Voice Attack profile, that might help your searching.

Have you deleted all of the axis binds?

Or just set windows to duplicate one desktop on the two displays since you won't be using the two for different things at the same time.