Bearfoot

Hint 1: extend your legs at the knee, not turn your hips; your hips don't actually have to come into play (if you don't want to) Hint 2: that's how it works in every air frame in existence or has been in existence throughout the entirety of recorded history on this planet

+1000000000000000000 I use all three system regularly on a day-to-day basis. I have been, in the past, a sys admin for an HPC, and currently not only use an HPC daily but also run Windows (for DCS), and do all my programming/development on both Mac's and Linux's, do photo editing on a Mac, etc. etc. etc. They all have their strengths and weaknesses. My personal machine of choice is a Linux (*if* I can be ensured of driver/hardware compatibility), but honestly could make do with any of them (though, for working would infinitely prefer a Mac over Windows if I could not get a Linux). So, whenever someone says to me something like "Macs are not a real computer" I hear "<noise><noise><noise>I do not know what I talking but try and pretend that I do to impress people who do not know any better<noise><noise><noise>". Back to the topic at hand: yes, you can run DCS on a MacBook, but only through dual-booting via Bootcamp. It works fine within the limits of your hardware CPU/GPU/RAM.

So, I had a chance to give both missions a run. And they both work! Good job, folks, and thank you! I think the approach with two moving zones that need to be entered to trigger the weapons free flag is a little more robust to variation in starting distance and closure. With the static zone, if you are not careful in the setup, it is possible that one guy enters or even passes through it while the other guy is still approaching it. The radio command is a nice backup in cases like this. So ideally, a hybrid approach may be the best solution?

Thanks! Will give this also a try after work. I assume that, if it is based on time, the initial distance/speed is critical?

Thanks! Will give it a try. A radio call seems to be the most reliable way to get this.

I though of this, but the problem is that the AI will enter the radius before the merge as the radius is centered around one of the a/c. If the radius is large enough to allow decent lateral separation, then the AI will almost certainly be able to launch a heater to your face before the merge.

As simple as needed and no more simpler! So yes, air start at co-altitude should be fine. Head-on should be OK to, but it would nice if this can be varied,

To practice WVR engagements "dueling" style, I would like to have the player + AI opponents fly at each and other and only start engaging after the merge. Is there any way to suppress the AI from firing its heaters before the merge?

Thanks!

I am no expert, but I think that the carrier and air bases have different risk profiles. The carrier is a lot easier to mission-kill (would not take too much damage to force it out of the picture) and/or kill (takes a lot less damage than an air base), a lot more difficult to defend (smaller air group and anti-missile / point defenses limited to hulls in the battle group and what can be fit on them), and has a lot worse optics if it were to be lost (a US carrier going down vs a foreign air base damaged). Which is why uncertainty of location is a big part of the carrier group defense doctrine.

So, when I map the TDC to the TMWH mouse, if I pull upwards on the mouse switch, by default the cursor moves DOWN on the screen (replicating pulling "aft" on a stick rather "up" on a hat switch). This is easy enough to invert in the axis tuning page. But wondering if in RL the behavior is like the default or inverted.

Is there a reference to which number corresponds to which button? E,g,, Button #1 is the upper left corner and numbering proceeds clockwise?

That's what I was thinking. Lesson learned, with sacrifice, in the Coral Sea almost a century ago, and the Navy does not forget easily! Question is then, if you want to simulate a full symmetrical peer-on-peer conflict on the PG map we have now (with maybe contesting air battle being the primary aim) is there any place for carriers at all?

I have the beta firmware. It ... reduces the problem. Unfortunately, does not fix it completely and entirely. Still get it at least once or twice each day (as opposed to several times an hour until a restart, so it is an improvement). Really frustrating. E. g., making a ground run and suddenly you switch to AA mode, resulting in needing to go to stores and reselect; or closing in with AIM-7 and suddenly switch to AIM-9, throwing off your game. FWIW, It seems to be triggered by an roll or pitch movement. I am guessing it's got to do with voltages[TM] :). I don't know, TBH. I'm going to wait for the final release of the firmware to see if that solves things, otherwise, if it doesn't, I will make one last attempt at tech support. The problem is that things are so random that you cannot always trigger it while having the config or the button tester up, so it is difficult getting the bug report requirements .... [EDIT: in fairness, I suspect my case is an outlier. And the last time, AeroGator worked with me to get it fixed via software. I am hopeful still that this round of problems will be ironed out eventually, either through the next firmware update (hopefully improving on the beta; which is why I describing the problem here), or through a support ticket etc.]

Which server is this?

Me too. And I don't think it is WIP thing, because the same thing happens in many other modules --- calibrating curves for one screen (or zoom in e.g., the A-10C) make it jump around like a gnat on meth in other screens. I think the real problem is the absolute catastrophically-bad quality of the TMWH mouse. Honestly, using warm oatmeal might give you better precision. I guess ED could help by allowing us different curves on the different screen, but that's probably not going to happen. Work arounds: (1) use different inputs (e.g., throttle mouse for radar, and a POV hat or shifted mouse or something for auto bombing mode); this is what I use, as, luckily with the VKB MCG pro grip there is a hat switch (and then some) to spare (2) use discrete buttons for input (as opposed to axis). If you want to continue to use the THWH mouse switch but as a 4-way hat, I'm sure there is a way, but I don't know how. If someone could advise, that would be great.

Thanks. Good to know, and nice link to learning the AA system too (applicable to DCS Hornet as well).

Could you show me this? How to set it up and what it looks like in game?

Thanks, but I think you misunderstand me. I am not asking about magnetic vs true headings. Just the bearing to radar contact I am looking at on the scope. I can roughly figure it out, but was wondering if there radar display gave an exact number anywhere.

Is there a way to get the exact (as in 3-digit) bearing to a radar target? I see exact altitude and heading when it is locked up, but it seems I have to ballpark the bearing based on my own heading the contact offset from center. Is there a better way?

Confirmed: still present.

This is not true, at least as implemented in the current game (don't know about RL).

You can use multiple springs (2). It really is doubtful this is the issue, though. But worth experimenting with (and try a weaker spring as well). Also, of course. recalibrate each time. PIA, I know ... For changing springs --- use the zip tie trick. Use a zip tie loop slipped over the spring end to pull the spring into place, then either cut or slip out the zip tie. Makes it really easy.

Other things to try: (1) make sure screw fastening the top are not screwed in all the way; in ver I, if you do this on one particular screw, in contacts and engages wit the friction mechanism. You can get alternate (shorter) screws that avoid this and this is what ships with later units (2) there is no reason (I think) for this behavior for any spring/cam combo, but just to pin down the problem maybe try a different set of springs? stronger?

Could this be an over-dialled in friction setting?