derammo

I think I am getting too close :) By the time my first missile is active, I am so close that I just boresight the other targets. Without TWS, I could not figure out how else to select a DIFFERENT target from my first one reliably. I kept getting the same target again when enemies were grouped up. When we get TWS, will it be able to guide multiple AMRAAM that have not gone pitbull yet?

I am sorry I did not look at the practice mission, as I am away from DCS. So these are just general comments regarding F/A-18C AA radar use "Active Pause" to play with it, in case you aren't already, so your plane stops moving while you fiddle with these settings for the first time like Dun_Aenghus said, click AA on the left side of the cockpit alternatively, it should select AA automatically if you select the AIM-120 as a weapon and set the radar to 40 miles make sure Radar is active (there is a turning knob on the right panel, OPER being the active settings) make sure you know your practice target range, so you can make sure the radar display range includes it - if it does not, use the up and down arrow buttons (right side DDI soft buttons in the top right corner) to change the range make sure you know your practice target altitude, so you can then make sure that the min/max altitude on the little yellow designator bracket includes that altitude - if it does not, then you need to read about the different "bars" modes and radar elevation angle controls, but it is easier to just start in a mission where you are at the same altitude and you are in active pause mode

Well, I think it depends on where people fall on the tinkering vs. buying things spectrum. They're both perfectly valid and II like both :) but I have already ordered replacement USB controllers from Leo Bodnar and reached out to rel4y to see about getting upgraded sensors. That's just too awesome to pass up, being able to upgrade my joytsticks... I need to change their enclosures anyway for mounting, so might as well replace things inside. Also, my rudder pedals are a bit flaky and the USB device fails after PC suspend/resume. Replacing the controller in there will also presumably fix that.

so much great information, thanks! Now I definitely want to upgrade my CH stuff to a higher resolution board, even if it is just the rudder pedals and throttle (which I definitely won't replace)

Awesome idea, thanks Rudel.

I have been using CH sticks forever, currently using a FighterStick. I tried Warthog or other more realistic sticks over the years but I need a really soft (low resistance) stick, because my hands are trash. Carpal tunnel type issues make it so I can't really play with anything with realistic resistance on it. Are there other sticks I could try that might be more precise than the CH sticks and would require 0 dead zone? Maybe something adjustable? Or is CH already very very precise and I should just try a new one (mine is a few years old at this point.) I don't use control center so I don't care that the software is basically dead at this point, I just use vanilla Win10 drivers. Thanks for any ideas! [edit: just looked it up, apparently my throttle is 15 years old and my stick is older than that... maybe just a refresh?]

For now, I simply uninstalled the Nevada terrain so I can update to the latest software. Presumably, the next release will have slightly different files or maybe you can just try to repackage like I suggested?

With all due respect, I don't think that is how malware works. You can still have malware embedded in a non-executable file, for example anything that is compressed or a PDF or something like that. When the target software reads the specially crafted sequence of data, it hits vulnerabilities in the software doing the reading or decompressing. Some of those can be used to get it to execute malware. Data execution prevention stops some of that, but not all. I agree that most likely this is a false positive, but it would be better to follow up on it just in case. The view that only executable code poses a threat is not at all up to date with current realities. If these chunks of torrent files (sorry, not familiar with their implementation) are compressed or encrypted, then you could probably just make a tiny harmless change to the terrain files and see if compression and encryption change the file enough to no longer trigger the anti virus signature. That seems way better than expecting all your customers to turn off their anti virus to install the latest version of the software. Otherwise, reach out to Microsoft and see if they can look at your stuff to see if their pattern can be fixed. PS: I am in no way claiming to be an expert on this topic. So you can feel free to correct if I said something inaccurate above. I'm not here to have a debate about malware tech :)

Yup, that's the part I had not learned yet :). I assume it will just work when I start using COMM1 explicitly instead of just hitting '\'. Thanks.

on that note, do communications after take off work for you? Ground comms are working, but as soon as I take off, nobody wants to talk to me any more :). It is also possible that I am doing it wrong, because I haven't learned Radio operations yet. But it would be helpful to know if it works at all before I try and beat my head against the canopy.

PPS: I put some code into my local Helios to suppress Mouse Down and Mouse Up if there was a Touch Down event on the same control in the last 200ms and that makes the problem go away. So either this screen is just making extra events or something in Windows is trying to be clever and convert a touch with a tiny amount of sideways movement into a gesture to do a mouse drag. Most likely that is what is happening.

PS: This also means I can trivially filter this in the Helios code, but of course it would be nicer not to have to run my own fork of Helios :)

Update: I added some debug code to Helios and confirmed that when I press on my touch screen, it delivers the OnTouchDown event FOLLOWED by a spurious OnMouseDown event. Both of those fire the MouseDown (which becomes 'pushed' event I guess.) Does this ring a bell for any Helios devs? Three mouse clicks: OnMouseDown 25,17 OnMouseUp 25,17 OnMouseDown 21,19 OnMouseUp 21,19 OnMouseDown 19,25 OnMouseUp 19,25 Several touches, with various click speeds: OnTouchDown 14,14 OnTouchUp 17,13 OnTouchDown 15,11 OnMouseDown 15,11 (seems like this is holding mouse down until two taps later, some accessibility thing?) OnTouchUp 22,15 (maybe I slid here?) OnTouchDown 18,8 OnTouchUp 18,8 OnTouchDown 28,16 OnTouchUp 30,13 OnMouseUp 30,-57 (finally released mouse) OnTouchDown 22,20 OnTouchUp 23,21 OnTouchDown 18,11 OnMouseDown 18,11 OnTouchUp 18,11 OnMouseUp 18,11 (this is a pretty normal tap) OnTouchDown 17,11 OnMouseDown 17,11 OnTouchUp 17,11 OnMouseUp 17,11 (another normal one)

Ok, on second look, that seems like fixed configuration. So I cannot find the setting that you describe that maps single taps to double clicks. If you do find it again, please let me know?

I already have it set to send double clicks only if you double tap. See image below. I will look some more if there is another setting somewhere.

Thank you!

Is there a list of things that are not yet implemented maintained somewhere we can see it? Cheers!

Are you saying it is slowing down ('the more I'm playing') so you start at max FPS and then slowly over time it bleeds down?

PS: Regarding option 1), if it isn't already there, I would contribute some code to Helios to make this possible.

Thanks for all your help. I was trying to avoid it, but learning and playing with Helios was the right choice. I decided to create my own F/A-18 profile in Helios, putting just the things that I want on the screen (not running the whole cockpit from Capt Zeen.) It is actually super easy and fun.

I am using a bad/cheap touch screen (Asus VT168H) and it seems to generate more than one click event when I click somewhere. So in the default configuration, when I click an MFD button, it frequently gets triggered twice, turning whatever it is on and then immediately back off. Have you solved similar problems? Buying a better screen is obviously one solution that I would consider "smart assery," so that isn't a suggestion I am interested in. Here are some things I know I could do: 1) configure / change Helios to suppress repeated clicks (like a configurable amount of ms that clicks have to be separated by, like in an accessibility driver) - is there already such a thing? 2) write a device driver to act as a filter driver on the touch screen's driver stack to suppress repeated clicks - is there already such a thing? - this would allow people to use crappier input devices, not just with Helios 3) configure my profile differently - I haven't investigated in detail, but maybe it only creates a single button release event, so maybe I could react to that instead? I am putting this here to fish in case there is a known work around for this situation Thanks for your help, hive mind.

I would like to add clickable buttons around the MFD that is mapped to my second screen (which happens to be a touch screen, but that is immaterial to my question.) I am not looking to map any other instruments or anything weird. I know how to do this with Helios, basically running a very simple config on a very powerful tool. I wonder if there is a simpler way to do this? Is there a native way in DCS yet to define a "button" in a view port? Are you aware of any simple software that allows me to define clickable areas on a screen and assign a key stroke to send? Basically it would just act as a HID that sends keys when you click various parts of the screen, as a driver.

Not to revive an ancient thread, but just in case anyone else googles their way to here: The game runs fine on Intel 3000 with latest drivers. I did a clean install of 1.2.16 and ran it on my laptop. The graphics end up looking funky (z ordering or normals issues) but it works fine for testing or to run as a server. You don't even have to turn off 3D rendering. Fullscreen did not start up for me, so I modified options.lua to set it to fullscreen=false and specify a window size via "width" and "height." Now I can use my laptop for testing or mission editing while we are playing on the "real" computer.

I would also like to know if this file is obsolete or is actually used by the AI code. And does it apply only to aircraft doing the detecting or also ground units?

We made a simple mission to show the issue. Here is the TRK file. You will see that the remote client 'Vader' dives in behind the bomber and flies right past it. The bomber never reacts, speed and course remain the same. It never fires. Then you see the server host 'Sickert' approach the same bomber. At 5.0Km, the bomber detects him and starts maneuvering (his way point is a straight line, so any movement is maneuvering.) He also fires when the plane comes in range. This is the simplest mission in which we could get a repro. Bomber debug.trk