Fishbreath

My friend and I took up some Su-25Ts last night, and we were doing great until the hostile fighter jumped us. I guess next time we ought to run more vigorously toward friendly AA.

I pledged for one too. I look forward to seeing it released.

I've only overheated the laser in two circumstances: 1) Accidentally binding the range/designate target button to my push-to-talk key. 2) Firing a full weapons load (cannon, rockets, and 12 Vikhrs), then rearming and returning to combat before the 30-minute full cooldown had elapsed. Normal use (ranging for unguided weapons and guidance for 12 Vikhrs) has never burned out the laser for me.

Has there been any news on this? As a temporary fix, I'm going to have stationary units move a little when they spawn, but being able to remove them would be great.

You don't have any right to say this: After you said this: Sorry.

On that note, I've found that my DCS helo experience helps me fly on instruments in Arma, and my Arma helo experience makes me better at seat-of-the-pants flying in DCS.

I think the problem is that the data you have is hard to work with. The probabilities you have would work just about right for a closing target checking once a second, but they don't translate very well to e.g. a crossing target. The graph is probability of detecting a closing target before a given range; you would want something more like probability per unit time vs. range graph. You could maybe cheat it a bit. 400 knots is about 250 yards per second, so the gap between each vertical line on the graph is about four seconds. So, for instance, from 5,000 to 6,000 yards, the midpoint of the curve in there looks to be about 0.08; we'll call that pDetect. There's a corresponding probability that the plane won't be detected: 1 - pDetect = pUndetect = 0.92*. If you have a bunch of independent events, the probability that they'll all come out in a given way is their product. Our pUndetect happens in a four-second window from 5,000 to 6,000 yards, so it's logically the product of the probabilities that the airplane won't be spotted in each of those four seconds: pUndetect = (1 - pDetectPerSecond)^4 or, filling in a little and working it out... 0.92 = (1 - pDetectPerSecond)^4 4throot(0.92) = 1 - pDetectPerSecond about 0.98 = 1 - pDetectPerSecond pDetectPerSecond ~= 0.02 So, at 5,000 to 6,000 yards, there's about a 50% chance that an aircraft will be detected after 25 seconds, and it's almost certain that it'll be detected after 50 seconds. That passes the smell test for me. For this specific case (using the probability to detect a 400kt closing target during a certain 1,000 yard window as the probability that such a target will be detected in four seconds if flying head-on in that range window), you can just use this formula to convert to probability per second: pDetectPerSecond = 1 - 4throot(pDetectOver1000Yards) * It's possible to run the math that comes after this the other way around, I think, but it makes more intuitive sense to think about it as the probability of the event failing to happen in this case, and since I'm not a mathematician I can't tell you why**. ** Okay, so I asked a mathematician, and we came up with an answer that has to do with distributions and independence of probability. This is a fun case where the way you ask the question has a significant outcome on how easy it is to find the answer, so that's cool. Pretend that you're rolling a six-sided die, and if you see a six, you detect a target and stop rolling. Now, on any given roll, you have a one-in-six chance to roll a six, but since we don't keep rolling after we detect a target, the probability that we'll roll a six on, say, the third roll depends on the results of the previous two rolls: if we roll a six the first time, there won't be a third roll at all. That's the phrasing that asks about pDetect, with the wrinkle that we have to sum the probabilities for the first, second, and third times. Asking if we haven't rolled a six after the third roll contains the implicit assumption that we get three rolls in, because that's the case we're asking about. The answer to that question just happens to contain the answer to the other phrasing, too. It's actually a little more complicated, because summing the probabilities per second doesn't quite work out (if you assume that for second n, pDetectInThatSecond = pUndetectPerSecond^n * pDetectPerSecond), but I'm given to understand that's because working it out second-by-second is a piecewise approximation of a curve (the one described by a probability density curve).

Not really. Speed, altitude, boresight vector, and velocity vector would be enough, wouldn't it? The flight model can start with that, just like it does in an air start.

The R-27ER is very vulnerable to chaff right now—there's a thread around somewhere that says it'll only track a non-maneuvering, chaffing target about a quarter of the time. I think that's obvious bunk, and I hope it'll be fixed soon. The AIM-120 and F-15 is working as intended. You don't get a launch warning when an AIM-120 is launched at you, because it's an active missile instead of semi-active, and the launch platform therefore doesn't need to use a missile guidance radar mode.

Well, I was going to do a bunch of work tonight on my training range mission's air to air setup, but I guess that would be wasted effort now. :P

2. Static target objects are treated as buildings by the game (and the AI), so you need to use actual objects if you want the AI to respond correctly to commands, I think.

Nope, it was quite a shock to me when I tried to restore my profiles the first time, too.

I'm going to be away for the weekend, but I might try it on Sunday night.

The KMGU setting starts releasing the next KMGU or multiple ejector rack as soon as the previous one has finished. The fixed delays start the next one after the delay. I seem to recall that's how I always thought it worked (source: the training videos on Youtube).

Okay, thanks. That's the last piece I needed for the fighter range component of my most recent project—it's a little dull if the targets all come from exactly the same place every time.

Dedicated early warning radars only do air target datalinking in DCS. SAM types with separate search radar units have those in the game—make a group with a command post, search and tracking radars (which have the suffixes 'SR' and 'TR'), and launchers, and they'll all work together correctly.

The external model and 6DoF cockpit were finished a while back, but the flight model hadn't been updated. They've been pretty coy on predicting dates, so we don't know when it'll be. For myself, I'm thinking a month or two, but that's not based on anything concrete.

Is there any way to combine the cloneGroup(group, boolean task) and cloneInZone(group, randomZoneTable...) mechanisms for aircraft? I tried cloneGroup first and passing the spawned group name to teleportInZone, but the AI pilots uniformly ejected after they were teleported.

The Su-25 and A-10A are already available. The F-15C and the Su-27 are only waiting on advanced flight models for separate releases, and those are both in progress. (Belsimtek is doing the F-15, and ED is doing the Su-27.)

After several years of putting it off, the fact that the guys at Apex DCS are running this mission got me to finish the rewrite I've been planning for a long time, so here's an update. Basic Instructions To spawn targets, use the F10 radio menu. Some ranges have parameters you can change, under the Range Options... menu item. To view the current options or repeat target callouts (for ranges which support them), use the Utilities... menu item. Flyables Not actually sure offhand; I started with the version off of the Apex server for carriers and tankers, so whatever they have there. Planned Features Possibly a remove-destroyed-units feature, if available Possibly other cleanup features; i.e. clearing target areas completely Open-source the whole thing Target Areas Airfield Target Area Located SW of Kobuleti at the abandoned airfield. Hard targets: 6 Leopard 1A3, 6 M113, 6 Marder II Soft targets: 40 infantry, 12 trucks AAA: 2 M163s IR SHORADS: 1 Strela-1 Radar SHORADS: 1 Osa [*]SEAD Range SAM battery spawns create a launcher, search and tracking radars (where applicable), and a command post (where applicable). SHORADS spawns an Osa, a Strela-1, a Strela-10M, and a Shilka. [*]BVR Range Provides highly configurable spawns of enemy aircraft, with options suitable for every A2A-capable flyable. Currently available: Mustang, Dora, Saber, F-4E, F-5E, F-16C, Tu-95, Tu-22, C-130. [*]Locations: West Far: ~150km west of Kobuleti West Close: ~75km west of Kobuleti South: around Batumi [*]Altitudes: about 25,000 feet for High, about 5,000 feet for Low. [*]Armament: for aircraft without access to certain kinds of weapons, categories for those weapons mean 'fully armed'. (e.g. P-51D IR Missiles is just gun-armed.) [*]EWR is available to provide vectors. [*]North Target-Spotting Range Spawns targets randomly in one of thirteen spots north of Kobuleti. Targets are platoon, company, or battalion-sized formations of armored units, with optional air defenses. Spawned units will be marked with a smoke marker, and a mission message will indicate location relative to landmarks and towns. [*]COIN Range Spawns units either stationary in a town, or moving on or off roads through it. Low-intensity targets (topping out at IFVs, truck-mounted ZU-23s) moving through civilian traffic. Known Issues None That's not to say that it's bug-free, merely that I'm not presently aware of any issues Changelog v6.0.0 (05/27/19): full-on rewrite of everything for ease of use and porting to other maps, with an eye toward open-sourcing the script; COIN range implemented v5.0.1 (08/14/16): bugfix for recent versions of DCS, do most ranges with scripts instead of triggers v4.1.1 (10/3/14): bugfix (BVR range spawned all targets at near spawn point) v4.1 (10/3/14): New BVR range first release. v4.0 (TEST VERSION): New BVR range first pass, using scripts and some fancier options. May break things or cause script errors. v3.3 (09/17/14): MiG-21 slots! (n.b. the attached file without a version number is v3.3) v3.2 (09/13/14): fixed KC-135 bug, added slots for more flyables, added in-progress COIN range, split airfield target range targets into soft and hard spawns, moved fast movers to Senaki Airbase to free up room at Kobuleti, moved transport helos to FARPs SW of Kobuleti for the same reason v3.1 (09/09/14): fixed menu bug, changed Ka-50 skin to something less parade-ground v3 (09/08/14): switched player coalition to blue for future JTAC v2.1 (2/6/14): added tankers, removed 4x Phantom BVR range spawn v2 (2/3/14): added random target range, BVR range, many more aircraft slots v1: initial version with Su-25T and Su-25 slots and Kobuleti abandoned airfield range Edit: for now, use Home Fries' version toward the end of the thread, which has better support for Tomcats and Viggens. I'll roll those into the next release. Super Multiplayer Range Blue v6.0 Unbranded.miz

No, it absolutely does not. If the flight dynamics, the system modeling, and the weapons delivery are accurate, my wingmen could be speaking Martian for all I care. Putting someone down because he wants simulated radio communications to be in a language he speaks is moronic. It ought to be an option that can be set in the game. Saying 'no' to that is indefensible.

I'm up to mission two, and I'm kind of curious if anyone has some advice here. The target is a column of artillery protected by four man-portable Stingers, and they can apparently reload those pretty darned fast—if I get anywhere near the target below 3000 meters, they fire off several missiles at me and my wingman both (more than four). I had some success killing some of the launcher infantry with S-8 rockets fired at long range, but that's not ideal for killing the targets. It mostly seems to me like the speed of re-engagement and the number of rounds carried for the infantry is a little high, but ignoring that, is the best way to keep out of trouble just to stay high up and far out? Even a floor of 2500 meters was too low for delivering bombs.

The only one you really need to know and love is 'SAM launch' and the numbers for o'clock. :P

You're still a lucky bum. :P

As I understand it, the reason the unchain-rudder-trim mod is popular is because people remove the centering springs from their rudder pedals. There are three behaviors here: 1. With rudder centering springs and rudder trimmed: Press/release trimmer. New center points set. You have to move your feet back to the rudder center position, but the rudder isn't centered anymore, so your feet no longer correspond to the rudder position. On the upside, the pedals have a centering force, which strikes me as probably correct when the helicopter is at a decent speed, and possibly not correct when the helicopter is slow. 2. With rudder centering springs removed and rudder untrimmed: Press/release trimmer. New center points set, but not for rudder. You just leave your feet where they were. This is more nearly how an actual helicopter works (or at least one with trimmable yaw?). 3. With rudder centering springs and rudder untrimmed: Wrong, IMO; you have rudder pedals which don't behave like helicopter rudder pedals, and you aren't using the game's recenter-controls modes to help mitigate the disconnect, either.