dotChuckles

Struggling to get the hotfix, what's the current version number I'm showing 1.5.8.12162 I run the updater but nothing updates.

Many thanks! Loving your work.

Legend! That's my Photoshop time booked up :-)

Hi, any news on this? Couldn't find a link anywhere.

Multiplayer in about 6 hours..... "dakkadakkadakkdakkadakkadakka... you can teach MONKEYS to fly better then that!"

I'll give that a go. Thanks :-)

Same here, can't use DCS because of this, as since switching to the Rift I have no interest in anything other then multiplayer and VR :-(

So as other people have said, this system and aircraft really dates to before GPS was a common thing and the INS system had no external reference and was subject to drift. The offset was selected in mission planning to be a geographical feature. You're now flying your attack, and can pinpoint from your plane of reference either using ground radar in some aircraft or visually in the M2000C the geographical feature. This updates or "cancelling your offset" so that your INS and position are exactly aligned. Now you have a fixed bearing and distance to your target that is very accurate. The use of the offset IP means that this procedure is done before you are committed to attacking the target. Imagine trying to update your INS, correct for INS drift, fly an attack profile and then release weapons all while having incoming fire... all at the same time. The offset lets you do that on the run-in, which also allows you to use standoff tactics like loft bombing too. All of this would be done in mission planning, IP offset bombing was never meat to be used as a CAS attack method. Really only for planned targets.

Does this not still work to make the menu clickable? https://forums.eagle.ru/showpost.php?p=1147011&postcount=29

That sounds like a dynamic roll over... TL;dw Immediate collective reduction before hitting the critical angle.

I don't think this isn't actually the case. INS/RADAR offset bombing was one of the primary methods in the Tornado GR.1 for low level loft profile delivery. While the mirage uses a visual system for updating the IP offset as opposed to a ground scanning radar and a cursor, the principle is essentially the same. The Navigator in the tornado updated the offset by cursor hooking a known feature to update the offset, in the M2000C you do it visually with a HUD cursor. This method was accurate enough to put a grouping of bombs on a building, taxiway junction or aircraft on the ground when performed correctly. We are talking precise to within meters as opposed to inches, but that was pretty accurate for the 70's and got the job done when it was four 1000lb bombs. Remember, precision bombing is a relative term depending on what decade you're talking about ;-) but even by today's standards it was pretty good. If you want to read a good account of the method, even though the raid went pear shaped, John Peters/Nichols book "Tornado Down" describes it and it's capability very well. A worthwhile read on it's own too. The loft attack at 20:00 is all driven by INS and offsets, some nice shots of the symbology there too. A lovely film and worth watching for the nostalgia :-)

Yep, we've been getting this too. Couldn't fly the F5 because of not being able to contact ground crew.

So I am wanting to get into content creation for DCS, I have to produce some 3d models fro my work occasionally and I was hoping to bring that skill to making bit and bobs for DCS. The issue I am running into, being relatively late to the party, is that Autodesk no longer grant permanent licenses for 3ds. You can go 3 versions back which includes 2014, which I understand is the most up to date version that the modding tools support. The issue is that when 2018 comes out I would no longer have access to 2014. I don't want to take out an expensive subscription to only have access to the software for six months or so. Are there any plans to update the edm tools? Or support an open source platform like blender? Or am I stuffed and essentially too late to make content for DCS? Any help or suggestions would be greatly appreciated. Thanks!

Legend! I will try this tonight. Honestly, this is the number one solution for radios as far as I'm concerned.

First off, this is an absolute joy to use. Massively impressed, had it running on my server last night with zero problems. By far the best radio implementation I've used. My one question though... we were using the intercom in the L-39C for some training, I've bound the intercom PTT from the cockpit to my HOTAS, but every time you click it, it pops open the interphone radio menu. I get the feeling that this is a DCS issue, but is there any way that you could give us the option to use the SimpleRadio PTT so that didn't happen as well as the current way of doing it? Also as a suggestion, have you thought about bleeding a bit of the engine noise and some 400Hz AC into the audio? Maybe thudding of the rotors in helos. it's something that you hear a lot in transmission and intercom recordings. Could make it a user option of course. Very much loving this, anything that kicks Teamspeak out of the signal path is a godsend. We will certainly be adopting this as our main communications tool.

HAlso... The representation we have when not in VR and as default, is that of the whole HUD. Surely this is a faithful representation of what the pilot sees as it was designed to be shown. Since the broad consensus is that the eyepoint is in the wrong position, even by Wags himself in his VR video, then it stands to reason that you should see the whole HUD at the correct position. Or why would ED choose to represent it as such at default and not the truncated HUD that you are proposing? This would then lead us to believe that a compromise was made. As I say... Something is not right here.

Doesn't settle anything. Provide the designed eyepoint diagram from the Fairchild Republic plans and the appropriate MILSPEC for the HUD showing what should be visible at designed eyepoint and then we can call it settled. While I appreciate your effort, it doesn't prove anything, there are far too many assumptions in your diagram. It also uses the in game model as a reference, again, we are not sure how accurate that is. You need to reference the real airframe if you want to prove accuracy. The only person that can definitively say is a RL pilot. And given discussions on Reddit and interviews it doesn't match up with what we are seeing. Something is not right. I am prepared to be proved wrong, but I would rather that it was though actual real world experience and documented evidence. As I say I appreciate your effort, but we cannot call this settled yet.

I think the camera is a little bit below the height of the canopy bow and angles down. Photographer was probably resting his arms on top of the ejection seat to steady himself to take the long exposure required to get the shot. Certainly judging by the pitch ladder the viewpoint is higher. Also gun camera footage doesn't assist in this case. All it proves is that the HUD is proportionally accurate within itself. Which is not up for debate. ED made a faithful reproduction. The problem is the origin point for viewing the collimation of the HUD seems to be in the wrong place. As I have said elsewhere it seems that a sensible compromise was made in development to allow the HUD plus key instruments to be viewed on one screen. And to do that the HUD origin was moved. This was before the Rift was a thing so was never a problem. The only way this is going to get settled is if someone can produce the ergonomic and sight line diagrams for the cockpit. But certainly comments from pilots and the above photo, which shows much more of the HUD then is visible when you set the eyepoint to the correct position in VR lends weight to the fact that it's wrong.

It's a nice picture certainly. But the camera is not positioned at the designed eyepoint. It is higher and a touch further back. While a very nice image and not one that I have seen before it doesn't really prove anything. Also recently in a Reddit AMA a serving A-10 pilot said that the whole HUD was visable.

It's useful information, thanks. But we still need ED to address that the HUD projection is in the wrong place as a compromise for 2d displays.

This has nothing to do with what is being discussed. The issue is that the designed eyepoint for the HUD collimation is set too far forward. Clearly a sensible compromise was made during development to place the eye point there to allow a representation on a 2d screen of the instrument panel that would mean people didn't have to pan about all the time while still retaining detail in the instruments. This however is broken when you go into VR as depth cues and simply looking around tells you that your eye point is too close to the panel. The fix for this, even stated by wags in one of his VR videos, is to manually adjust the eyepoint. However, as the designed collimation viewing point is incorrectly set in the cockpit model, by moving back you only see a small portion of the HUD. This is what we are talking about when we say the HUD is not readable. No amount of super sampling is going to fix that :)

You're not wrong ;-) DCS Forums are what fills my time while I wait for AfterEffects to finish rendering. :megalol:

What you are asking for would have the unintended consequence of making your cockpit appear massive as opposed to stretched, relative scale would be all wrong. It's all optics at the end of the day, if you change it at one end you effect it at another. No way around that I'm afraid.

Agreed! Has anyone from ED or Wags commented on this subject at all?

This seriously needs to be looked at now that VR is more of a thing. Very disappointed in the implementation in the Oculus with the A-10