PiedDroit

Hopefully they will revamp some of the bindings in their 2.0 update (many controls can't be bound to controller at all, or lack a "X or else Y" binding option). For what it's worth, mouse cockpit mode is not only double click on the mouse center button, on keyboard it is LAlt+LShift+C by default, and can also be bound to a controller button.

Haha thanks, this one wooshed over my head. Good to know there's some updates planned, still one of if not my favorite module en the roster.

I'm picking up the MiG-21 after a long time not flying it and I was curious about this announced new version, but could not find any info, is SMT actually confirmed? I did a quick read on the variants, and what I could find is that the SMT was extremely unpopular due do the worsened handling caused by the additional fuel tank on the "spine", most were rebuilt with a smaller tank and redesignated MiG-21ST, visually identical to the bis. So, I hope we'd be getting the SMT, but the ST, which is the same as the SMT (as far as I understand) system-wise, but flies better and less ugly.

Did anyone notice these screenshots from the Home > Downloads > Screenshots > In Development section? Not sure if I should get hyped right away note the file names, e.g. In_Dev_03.12.2021.6.jpg

Yep exactly. I'm DCS non-Steam user. What I did to make it run: - Configured the Windows Mixed Reality environment as instructed when plugging the headset. - From Steam, installed "Windows Mixed Reality for Steam" (had to search manually for it in the store) - When I play, I first start "Windows Mixed Reality for Steam" (which also starts the WMR envirnment), I wait for the headset to hook up and then I start DCS, works like a charm.

Hi folks, I finally got the chance to get the Odyssey, I'm posting here to give detailed feedback about wearign it with glasses, as it was very difficult for me to get info on that. They fit much better than in the Oculus Rift, putting it on and removing it is a breeze too thanks to the "crown" design. The Odyssey's space is 140 mm at the widest point without compressing the foam. The width of my glasses' frame is 135 mm, height 35 mm. I think they are wider than average and yet they fit well. The lenses didn't touch each other either (they were with the Oculus Rift), but I guess this might depend on each person's morphology. Funny detail, in the manual they explicitely tell to not wear the HMD while wearing glasses, as doing so "may cause facial injuries". Covering all the bases I guess :D Hope this is useful. Cheers,

On the higher FOV picture, there will be more objects to display, so at equal resolution, I assume the performance should be worse with the higher FOV.

Also, make sure the LEDs on the camera are OFF by selecting "Track clip" on the TIR software (if you see four red dots on the camera itself, it means it's emitting IR light, you don't want that when using the track clip). It's still possible to have parasitic reflections though, from the sun, as the other said, the best way to diagnose the problem is to have the camera view selected and look for any masking / parasites (red).

Despite all the other ways of perceiving depth, I think binocular vision is the major contributor, not focal length. Chaning world scale with camera separation works, it has been done in other sims.

It has to be provided by the graphics engine, I assume that doing such transformation after rendering is quite costly in terms of processing power. Or maybe it's not that costly, but it still has to be applied after rendering. Which means new software development. The day graphics API (DirectX) and 3D game engines will be able to render pictures directly with barrel transform applied then it will be possible to add this even for monitors quite easily. Good thing is that VR is pushing us right in that direction :thumbup:

Interesting topic indeed. I've been researching this a while ago, I found this good read on the subject: Reducing stretch in high-FOV games using barrel distortion Right now the 3D engine we have does not (I think) offer such camera type / transform but maybe in the future... WebGL sample from the same article Pictures from the article:

I was assuming 3) FOV is tied only to the headset and not to the user. If in the real world my vision is already distorted by glasses I thought it would not matter too much in the headset as I'm used to this distortion (I'm already seeing the world smaller than it actually is because of the glasses), but maybe it has more impact. I think 2) and 5) are the same thing, the ratio between them is the actual parameter. I'm more curious about 4), isn't that an optical thing? How would that affect the rendered picture?

But the link he posted shows an "IPD" setting in DCS, that would be the camera spacing! - or world scale, or viewport separation, or rendering IPD, whatever. The IPD term is used for too many things :D It's not available yet, it's for 2.5.

Hi, that's exactly this. There is a confusion of terms I think, I see this kind of questioning coming back every now and then because there are actually two settings related to the distance between eyes, not just one. The IPD is more the optics side, having proper IPD on the headset means your eyes are well aligned with the lenses and the screen, which is better for comfort, but this will not drastically affect the sense of scale because the images on the screens will be not be modified by this. World scale, on the other hand, is on the rendering side, it is the distance between the two rendering viewports. If the distance between the two viewports is too large, the world will appear very tiny (think of looking at a toy plane), and vice-versa. The size of the world itself has nothing to do with it, it's the relation ship between the world "size" and the distance between the two rendering viewports that matters. This setting should be unique to each person, currently I understand it is fixed in DCS, that's why some people complain about the world scale and some other not.

Sitting in a trainer aircraft does not magically train you, the instructor does. The problem in that case is unused and/or insufficient training missions, not the lack of training aircraft - DCS is virtual, so, many platforms can be trainers, from basic training to advanced training, there is no cost issue, safety issue nor dual-seater limitation. With the curent status of DCS (counting the Hornet), between more aircraft and more content, I favor the latter personally.

From the video, I'd add: Worse for glasses than HTC Vive or Oculus Rift

I saw that happen (veering off due to incorrect course setting, then correcting back to compensate for the deviation it generated), I think it was on a A320 but not sure :) Not real airplane, a simulator, but using a real autopilot software (I think it was before capture, but it's been a while, I don't remember the test conditions).

It looks like there are two different discussion going on here, hence the diverging opnions. - Is the course value needed for an accurate LOC capture? Yes - but maybe not on all A/C types, on my side I can only guarantee it is need for airliners. - Is the HSI course value used for that? Probably not, that's a different instrument - On airliners again, the only places you can tune that course is through the radio management panel (in manual mode) or through the FMS (in managed mode). So, I'm not saying Piston85 is wrong about saying HSI course selector should not affect ILS' autopilot, I'm just saying that you can't justify this by saying no ILS autopilot ever uses a course value, this is something that depends on the A/C.

I can name pretty much all airliners ILS systems. The course setting might be hidden from the user's view, because it is stored in the navigation system. On an airliner, the FMS has this information and feeds it to the flight guidance system, I believe this is the same thing with military aircraft, hence the use of "airport" navigation points. The FMS also feed the ILS frequency. When in manual mode (standby nav), the user bypasses the FMS's settings and sets the ILS frequency from the radio management panel using the selection knob. Once the user validates the frequency (goes from standby to active), he can then set the course value. You might be very experienced as a user, but there are a lot of things going on under the hood that you might not be aware of.

Hi folks, I don't know about the military systems but I can give some insights on the civilian A/C ILS systems, from the avionics point of view. The ILS is actually two beams, one for LOC and one for G/S, the G/S frequency is deduced from the ILS frequency (as in drPhibes's post). The ILS receiver can only compute a deviation value (angular deviation), one for each beam. This means it can tell you if if the ILS antenna is on the beam or not. If you get a zero deviation, then you are on the beam, if you get non zero deviation, you are not on the beam. It's quite simple The problem is that the deviation you get doesn't tell you anything about the orientation of the aircraft with relationship to the beam. This is where the course setting is useful, it gives the flight guidance computer that missing information. The autopilot will try to follow the course that has been input by the user, and also tries to keep the aircraft with zero deviation. If the course is totally wrong (against current heading), the autopilot might even refuse to engage the approach mode. If the course is off, the aircraft, while riding the beam perfectly, will try to follow the course, then leave the beam, then correct again because of the deviation, etc. When closer to the runway the deviations are given more importance than the course, because the aircraft is already well aligned and the course setting is usually not very accuracte (1 degree accuracy at best), but at the beginning of the LOC beam capture, the course setting has a significant impact on the autopilot and FD behaviour. So, unless you are using two ILS receivers (this is not the case on airliners, they only use one at a time), the autopilot and FD need the course information.

I tried to re-read the manual more carefully and I found this: "In the HUD, the presence of the star representing the commanded slope, indicates the pilot that the autopilot is connected". Could that indicate that the flight director is the star? The other picture I have attached is for the visual approach, the text in the box says that autopilot is connected, and we can see the star in the HUD, and that the FPM should be put on the star. In comparison, the 2 pictures in the other post I made don't say that the autopilot is connected. The manual I have (m2000c.pdf found on the net) is a scanned document with no OCR, so it makes looking for stuff a bit difficult. The paragraph on the ADI ("spherical indicator") only state that it displays the ILS cues (Marker - LOC - Glide). My best guess woud be: * -> flight director box -> deviation indicator

No problem, I'm a patient person and can deal with that, I apologize for my reaction. The manual has no details about the ILS, the only thing are these pictures. The fact that there is an autopilot that can follow a glislope would be a good argument to say that the box is fligth director, because after all, why not display the flight guidance commands when you have them? It's much better than a raw deviation. The data from the manual is just too scarce to conclude anything. I have been advocating for an ILS deviation indicator because of the way the drawing is done and the terms presented in the manual, but it is very thin. I'd love to have more data from a SME. I don't have anything more to add here, next move is RAZBAM's choice, I only wanted to expose that because I had the feeling that this HUD footage from an Airbus had been taken too lightly. I deal with avionics systems every day and even with a same type of aircraft you can have a lot of tiny differences to be looked at with a magnifying glass.

Good, very good, I prefer tackling problems rather than people :) If RAZBAM have a SME that confirmed it, it's OK, but otherwise we have to rely on the manual. I have attached the two pages on ILS I have from the real manual. This is where I think the confusion is coming: You seem to be sure that if the indicator is relative to the FPM, then it is a flight director and if the box was a deviation indicator, it should be put in the center of the HUD, but I disagree here. A deviation indicator is not necessarily to be put in the center of the HUD. It might be true for an Airbus, but we're talking about a different beast here. The deviation indicator could very well be tied to the FPM. There is no other indicator on the Mirage's HUD (the Airbus has the vertical deviation on the right of the HUD). At the same time, for example, a flight director is not necessarily tied to the FPM. On an Airbus' primary flight display (not HUD), the fligh director is a green cross that you need to put in the center of the display, it's not tied to the FPM. The real manual says: "Put the aicraft model in the guiding window". That kind of sentence could apply to both a flight director (commands from flight guidance computer) or a deviation indicator (raw deviations from ILS receiver). If you maintain the FPM in the box, then you're on path, it works for both. There is also a little triangle on the picture that says "Excessive LOC deviation (flashing)". That kind of terminology is associated to a deviation indicator, not a flight director. So, if the box is a deviation indicator and tied to the FPM, there is no need to put it in the center of the HUD. If the box is on the right of the FPM, then it means that you are to the left of the path, vice versa, same in vertical. That works for both a flight director and a deviation indicator. The proof that is needed is a SME that confirms either possibility. What I'm saying is that the instruction to put the FPM in the box is not enough to decide this is flight director. Especially when this box can have a little triangle that says "Excessive LOC deviation".

Yet I fully understand the topic, take some time to think about it. There is no conclusive data that goes one way or another (sorry but an A319 HUD footage doesn't prove anything), I'd love to see something more solid than that.

The video you posted above is a good example of what I'm talinkg about, in the attached picture I just highlighted some elements, in red some that are attached to the HUD frame, in blue some that are mapped to the actual flight vector. But I'm just stating the obvious anyway. This is where there is a confusion I think. "If the box is in relation to FPM then it must act as a director" - why must? Flight director and deviation indicator are two different things, the flight director show deviation between flight path computed by the flight guidance versus actual flight path, where deviation is a raw value that shows the angular difference between the localizer beam (and g/s) versus your current position. So having the box, let's say on the right of the FPM could very well mean two things: in case of a flight director implementation, it would be a command from the flight guidance to go right in order to catch the computed flight path. In case of a deviation indicator, it would simply tell you that the localizer beam is on the right. If the FPM is on top of the box, it just means deviation is 0. lets says you are on a 90° course in relation with the runway, and your position is right on the runway axis (runway in your 3/9 O'clock). In that case the deviation indicator will show zero (FPM on top of the box), but a flight guidance system would put the flight director to the left or right of its anchor because obviously you'd need to do a turn to catch the loc beam. If the real manual says it's a deviation from the LOC beam, then it is, it is not a flight director and you can't use another aircraft's footage to prove your point... If RAZBAM acknowledged the above as bug, then I think it's a mistake (unless they have data that we don't have). The only thing is that the manual is not 100% clear, I think this has been discussed in another thread, I'll to dig a bit to find it.