Jump to content

Ourorborus

Members
  • Posts

    189
  • Joined

  • Last visited

About Ourorborus

  • Birthday 03/01/1978

Personal Information

  • Flight Simulators
    DCS
    X-Plane
    MSFS
  • Location
    Brisbane-Australia
  • Interests
    Flight Sim, Photography, Music, Motorcycles, Diving
  • Occupation
    ATC

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. One of the best additions to the core game in recent years was the introduction of savable graphics presets. This can be very handy when switching aircraft. Especially so when changing to aircraft of different mission profiles. For example I have a preset for F18/14 and run a different preset for the helos. Primarily this is because in fixed wing I need a greater draw distance and can bump a few settings up due to spending most the time at altitude, whereas helos are always close to the ground and hence draw distance can be reduced to allow the headroom needed to make terrain look a bit better. I am not sure if it would even be achievable given the mission load sequence but the icing on the cake would be to have the appropriate graphics preset auto load when selecting an applicable aircraft. If this is not possible I would like to request the preset buttons be replicated on the main DCS page to save going into the settings page each time we swap aircraft.
  2. I love what the OP has said and agree 100% that I would prefer to have functioning systems that are not 100% real than not have the systems at all. On the other hand, as Big Newy has said, ED uses SME's. Simulation of certain systems could potentially place both ED and those SMEs in hot water, and it is not just a black and white matter. To give two examples: 1. ED uses educated guess work to make something that functions well. And their educated guess falls very close to the mark. ED now looks like they may have used classified sources, and the SME looks like they have provided that source either directly or directly with such feedback as. "This button should be over here" 2. ED uses educated guesswork to make something that functions well. The result is close but with an obvious discrepancy. Now it looks like they used classified sources and deliberately changed some factor to avoid prosecution. In both instances the onus may fall upon on ED and the SME, potentially in separate cases, to prove no wrong doing. This can be difficult to prove as the proof relies on an absence of evidence, so the implication is you are hiding something. It is a fine line to tread and on the whole ED does it well. Perhaps the importation of systems from other platforms may be a way ahead. E.g. Importing the CAS page from the A10 would be clearly not a use of classified F18 documents and give the players a functional system.
  3. Cheers, but I was referring to closed beta. Like most users I already use open beta. Besides, open beta is too late to help make a good ATC system, the framework is already set at that point and you are only looking for bugs. Just letting ED know there are some of us with expertise happy to help create something good.
  4. As a real life ATC, Sim ATC has long been something that drives me mad. That said, I am happy to see if that nut can be finally cracked and would be happy to help out. How does one get onto beta testing for this?
  5. +1000. I have the same issue in the F18 and the Apache. The problem is that HMD senses up/down tilt with its inbuilt accelerometers. DCS then takes that value as gospel, and places the HMD in the center of the view. Unfortunately due to different face shapes, the HMD may be tilted up or down slightly on your face, placing your personal center of view slightly above or below the absolute center of view. Thus the JHMCS/IHDDS displays slightly high/low. i.e if the HMD sits on your face tilted up 2 degrees from the "perfect" horizontal. the JHMCS/IHDDS will appear 2 degrees high in your vision. Re-centering while looking down/up doesn't fix the problem as accellerometers sense you are looking up/down. I personally wedge a small cloth between the top of my HMD's face cushion and my face as I have long given up on ED even acknowledging this problem let alone fixing it.
  6. Like the idea of an "AP engagement Dead zone" as a different setting to axis dead zone.
  7. So its not just me!!! I am also a VAICOM user so it could well be something between VAICOM and Huey. No issues in other modules, (F18, F14, Spit) For me It doesn't matter if I use VAICOM "OPTIONS" or a key bind the menu only shows once in about 20 attempts.
  8. Some irregular drift in datalink is to be expected, As Big Newy stated, a datalink contact can be up to 12 seconds old. How long depends on many things and will vary constantly. Your own display shouldn't extrapolate a PPLI as this will potentially add further error to the position. Remember the PPLI is simply a position sourced from another aircraft, and has already been subject to track filters/extrapolation etc. Think of datalink as a type of LAN. The protocols/language differ but the concept is the same. Instead of Cat5/6 cable or wifi it is linked over crypto radio. So, 1. Aircraft A (AWACS/wingman etc) detects a track, the track is subject to interpolation to account for RADAR update rate. (e.g. time for AWACS RADAR to complete a 360degree sweep, wingman may have a wide 6 bar sweep etc....) 2.The information is encrypted. Anyone who has ever used crypto radio voice will know there is noticeable delay in transmission. So the data may be 1-2 seconds old before it even leaves the donor. 3. The data is broadcast over the network. This is a biggie. Unlike your home LAN, the network is subject to atmospherics, antennae shielding, changes in range... the list goes on. Try maintaining a wifi network between 10 cars on the highway and you will get the idea..... Now make those cars maneuver abruptly in 3d and fill the electromagnetic spectrum with multipe RADAR, UHF, VHF, ECM etc etc... 4. The data is received, decrypted and displayed in aircraft B (you). 5. Like all networks this data is constantly being refreshed, updated and transmitted to/from all participants... with so many variables is impressive that the delay is only up to 12 seconds.
  9. I can adjust the left right alignment with a "VR recenter" keybind. In fact the recentre keybind works for 5 degrees of movement, forward back, left right, , up/down, rotate left right, but not tilt up down. That is fixed slightly high for me. For ED to replicate, it is NOT noticeable unless using an in game HMD display such as the F18 JHMCS. It is the JHMCS that displays high/low, not the whole VR picture.
  10. Simplest way is to ignore the QFE on DCS ATIS, and just adjust your altimeter to read the airfield altitude on startup. That will give you QNH. Unless the mission has a very dynamic pressure system, that QNH will hold true for most 2 hour (or less) sorties. Particularly if you are operating in VMC below the LSALT. In real world application, you would set Airfield QNH, for arrival/departure, area qnh outside the terminal area, Force QNH within the AO, and if complying with ATC, 1013/29.92 above the transition altitiude. (Fighters tend to ignore this unless transiting/cruising outside the AO). These figures will update throughout the day as weather progresses (but not THAT frequently) However, unless the MIZ designer has provided all this info for you (either in briefing or by a script), setting QNH as indicated above before takeoff should suffice for 99% of missions in VMC, and probably 90% of missions in IMC.
  11. Just let me clarify, you want ILS added to the hornet because you have no idea how to shoot a TACAN approach. Yet you somehow know of a super ILS that gives a "3 wire everytime"........ Please elaborate, I am interested how you can get a 3 wire off an ILS. (PS.You do know that airfields don't have a "3 wire" and carriers don't have ILS don't you?)
  12. You are talking about ILS CAT IIIC. It has existed for a significant time in the civil world and permits autolanding. Implementation in a fighter may or may not ever happen given the cost/weight/maintenance issues required. When the rest of the conversation refer to TACAN etc, they are talking about the TACAN Approaches not just the aid. Any navaid can have an approach built around it, and these days you can have approaches built entirely around GNSS/RNP without any ground based aid. (Even the GNSS approach can be flown in the F18 although given the lack of a data cartridge is too cumbersome to program in to be useful.) The aim of any instrument approach is to safely descend an aircraft to a point where they can get visual and land. All a precision approach (like an ILS) gives over a non-precision approach (TACAN/VOR etc) is a glideslope and usually lower minima. While I would love to see the option for ILS as I am Australian and tend to replicate Aussie models which had the ILS, the ability to recover off TACAN, DME, and even NDB approaches is there, you just need to put the time in to learn how to fly them.
  13. I know the HMD alignment system is simulated however it doesn't allow alignment of a VR HMD. When conducting alignment, the cross hair has to be put on the other cross hair. Unfortunately, this does not correct for VR headset alignment. To explain. The center of the HMD display is placed over what the sim thinks is the center of our VR HMD. However, if for example the VR HMD physically points slightly upwards on our face, the sim thinks we are looking slightly up, even though we looking straight ahead. i.e. the real center of the VR HMD is below where the sim thinks it is. Consequently to align the cross hairs during the alignment procedure the pilot has to physically tilt their head down. Once "aligned" the HMD display remains high within the VR HMD for the duration of the flight. (for me it is about 4degrees) The reverse would happen if the VR HMD pointed slightly down on your head. To replicate this issue, place two pads between your VR HMD cheek pads and your face to physically tilt it upward, and see where the HMD display sits in your field of view. Request a setting (even in a lua) to permanently/semi-permanently account for personal variations of VR HMD fitment.
  14. I have been holding out on this until the conflict between real controls and leap selection is resolved. Thinking laterally, I wonder if there is a way to permanently inhibit any mapped controls with the leap motion. That way anything you have mapped to real buttons (HOTAS MFD etc) can be permanently inhibited and leap ignores them....
×
×
  • Create New...