ShuRugal

Channel separation is a huge thing which AWACS needs. Not just for CAP vs CAS missions, but even for separating comms for multiple flights of the same type prosecuting different objectives. A real-world E3 has seats for up to TWENTY mission crew (IE: controllers) Each of those controllers can be working multiple frequencies (I don't know how the USAF divides but, but civil ATCs are often expected to manage 2-3 separate freqs). The DCS AWACS model works fine for single-player missions, where it's really just simulating the controller assigned to the PLAYER's flight. This even works OK for simple multiplayer missions, where everyone is in the same flight. But once you have 3+ flights working multiple objectives, the built-in AWACS becomes useless FAST. Most folks i know only put them in the mission for the datalink picture, and either use scripts to generate AWACS calls which are relevant to each individual flight, or use LotATC and have an actual player do it.

Excellent news! i will test it today after i get off work and let you know! Thanks for following up!

alright, here it is actually with my VR overlay visible.

alright, found the offset sliders, but it looks like they don't work as expected. When i move the sliders, it moves the VR hand relative to the world, instead of relative to the orientation of the hand. Meaning that if i align the DCS hand with my touch controller while it's pointing, say, forward, it ends up wildly off while pointing up. i'm recording a video now to show what i mean.

wait, when did controller position sliders get added? where do i find that?

boop

DCS log attached. I am using the Valve Index hand controllers In the following screen captures, i use the tip of my VR glove to indicate the position of my real fingertip. The offset here is not as bad, only about 4" as opposed to the 8" i was experiencing when i first posted, but it's still enough to make it awkward or impossible to interact with switches close against my "body" in the cockpit. dcs.log

bump

bump.

bump. S300 mast radars still definitely cannot be lased on their upper portions.

I probably wasn't clear in how i worded it, but yes, my thought was that the new spawning behaviors would co-exist with the 'pre-set' spawn behavior we currently get. as far as detecting collisions being unreliable, literally anything would be better than what we currently have, where there is a very real risk of spawning on top of someone who has parked in that slot for re-arming, or who is taxiing out from parking and doesn't know where all the spawns are to dodge them. I've been on both sides of both types of collision plenty of times.

bump

bump

bump

bump

bump

Consider me to be "another player expressing the same need". I have flown behind the 430 IRL and would love to be able to use it in DCS, but having it float in front of my face is a dealbreaker. Ideally, i would like to be able to position it the same we we can reposition the framerate counter display. Super ideally, I would like to be able to slap it anywhere in the cockpit in 3 dimensions, but even just being able to slap it anywhere on the "menu plane" would be an improvement which takes this from "unusable" to "amazing"

nullsee the screenshot. To set this screenshot up, i set my touch controllers on the top corners of my keyboard tray, with the corners passing through the palm grips of the controllers. the tray is 20 inches (50cm) wide. Note that the DCS fingers are intersecting one another by about 2 inches (5cm), meaning that the fingertip in VR is approximately 12 inches (30 cm) forward of where my physical palms are, which puts it about 9 inches (23cm) forward of where my real fingertip is. In addition, you can see that the DCS VR hand is more than one full hand-width above the grip on the controller. In VR, when i rotate my wrist 180 degrees, my VR hand traces an arc with a radius of about 5 inches (13 cm). This makes reaching some of the buttons in the cockpit extremely awkward. I understand that the Eagle devs might have higher priorities to deal with, but it has been like this since I bought my Index, more than three years ago (nearly four) now. If the DCS Dev team does not have the spare time to configure hand position data for the various touch controllers on the market, could you at least give us a set of sliders under VR options to modify the 6-axis position of the VR hands? Or if that's too much work, expose the values for this in a text file we can edit ourselves to a comfortable position? Having to work through the Kama Sutra to start up various aircraft is starting to get old.

Then you have the option to not purchase it. see how easy that is?

@Flappie Video has just finished processing, see my post above for the track. Please let me know if there's anything I need to do differently to give good test data.

well, go ahead and make your offer to Nick Grey, I'm sure he'd appreciate any funds you wish to donate to fund research and development into your module of choice.

This is a dumb take, even for these forums. In the first place, These aircraft have very complex systems which can take a very long time to master. Real world pilots of these aircraft put in hundreds of hours per year to achieve and maintain the proficiency in them required to excel in combat operations. Various militaries around the world invest hundreds of hours of instructor-driven training to get pilots to a point where going out and practicing will be more helpful than harmful. In the second place, why the <profanity> do you care how other people play the game? Giving and receiving instruction can both be extremely rewarding experiences. Even ignoring the first point entirely, that makes a hypothetical CFI/IP module attractive to many people.

Sorry that took longer than anticipated. I fucked up my test on Friday and had unusable results (to include forgetting to save the track....) anyway, attached is my track file. I cold-started the helicopter, in case there is some issue with my start technique which may be contributing to this. I've test every radar model in the game except for the giant offshore platform model and the one under the giant radome. Many models have laser reflection bounding boxed which do not match the position of the dish. Some have laser boxes which do not at all match the visible model, period (S-300 high-altitude search radar was particularly egrigous, with less than half the model giving a laser return) Test parameters: line of all models ~900 meters from the he helicopter (though George was creeping closer the whole test....) Units hostile units left on default behavior Helicopter cold-started LRFD set to First Return reporting Laser hellfires selected to give a clear indication of loss of return when aiming at targets which extended above horizon. Also observed during this test.... radar hellfires have gone entirely stupid? I have to jhave been doing something wrong, but i don't know what. if someone could educate me, that would be nice. Framerate really started to tank at the end when i finished the test and started shooting things. track file attached, video is uploading to youtube, i will add a post for it when it finishes processing. radarlaser.trk

DCS T-55 gunners have always been just a wee bit better than they should be. I remember being sniped by one from ten km in the black shark once. I was in a hover to engage him with vikhr (this was years ago, i've learned my lesson...) and saw his muzzle flash. I remember thinking "what the <profanity> is he shooting at? no way he can hit me this far away", right before i exploded.

Working on doing SEAD with the apache recently, I have discovered that moving components of ground vehicles all appear to be transparent to the laser ranger/designator. This is most obvious with radar units, with massive moving dishes which are frequently the only part of the system visible above terrain/trees/buildings. So far, I have identified the following components of the following systems to be 100% transparent to the laser ranger/designator: SA-10 SR 64H6E search radar - dish SA-10 SR 5N66M mast-mounted search radar - the mast above the inspection platform, as well as the dish. SA-10 TR 30N6 track radar - radar dish and mast above the cross-brace struts. SA-5 TR 5N62B track radar - the entire thing. the only part of this unit which returns radar range is the small stationary component directly bolted to the ground. With all of these units, you can slew the laser up and down while continuous ranging and see the range jump suddenly by several hundred meters as you cross onto/off-off the transparent parts. when designating a transparent part, missiles impact the ground behind the unit. when designating a correctly reflecting part, the missile impacts the unit as expected. I will put together a track and video showing this later today. This bug makes doing SEAD with the Apache massively inconvenient, as it requires targeting either the lower half of the unit, or the ground beneath it, which is frequently masked when trying to remain below the engagement envelope of these units.