Robin_Hood

Both Barometric and radar altitude as displayed in the HUD are in feet. AFAIK there is no way to display altitude in meters apart from the PCN. And distances are in nautical miles, and speeds in knots. Although certain air-to-ground modes will give you a distance in kilometers.

CptSmiley is the maker of the Mirage 2000C flight model, and has not stopped working on it. We had several updates recently. Only avionics updates are on hold because of the Harrier.

Yes, this switch is not a limiter on-off switch, but switches between two different limiter modes (not only G I think, roll rate also ?). However, I did experience wing breaking off with a clean aircraft (barring 2xR-550) using the elastic limit override while doing performance testing. At certain speeds, pulling the maximum amount of G "allowed" by overriding the limiter will break the wings. I had the issue appear at 10 000 ft, 21 000 lbs, 2xR-550, around 450-500 knots, pulling 9.5 - 9.7 Gs

I used to do 350 Kts, Idle, 60°, no airbrakes, and now I have to add power halfway through the turn. I would be surprised if adding airbrakes improves things, but I'll try. What airspeed do you expect at the end of the turn ? EDIT: Heres what happens when I try this (Track and Tacview attached) ; 60°, idle, airbrake out, 180° level turn, airbrake in at 200-220 kts. I run out of energy before the end of the turn. Do you guys make a level or descending turn ? M2KC Overhead break.zip

Hi all, I am wondering whate are everybody's parameters for the overhead break. With the new flight model, it seems that the aircraft loses a lot of energy at idle throttle and I have to add power in the middle of the break to keep some airspeed. I hava seen various parameters over the year, but currently none work for me (and airbrakes are especially no-no). I wonder if people have thoughts on the subject.

FPM and VVI, yep. As you can see, the sudden increase in turn rate is very localized, and may be missed at first. After my first test flight I had only one point that was affected by it, although it was not that higher than the others ; still I thought it was weird, so I ran a second (and then a third) series of tests around this speed range to see what happens exactly. Normally I try to take a reading every 25 knots.

No problem. Here's my test procedure for sustained turn rate measurements Test flight - be at the correct altitude (I am using ME altitude instead of altimeter altitude) - start on the high speed end - start a high-g turn, pushing the throttle to maximum - adjust roll and stick force to maintain calibrated airspeed - keep the airspeed and altitude stable for about 5 seconds - reduce speed and take another measurement Data computing - open Tacview Pro - open graph view, in relative time for the X-axis - export TAS, CAS in a file, export Mach, G in another file (since only 2 values can be exported at the same time) - look at the graph (in M-G, or CAS-G), spot the sustained turns - zoom and choose a sweet spot where airspeed and G look stable enough - go ahead and copy TAS, CAS, Mach and G for this time (Tacview measurements are made every .25 seconds) - to check for variability it is possible to take several measurements at different points in the same sustained turn** - finally, calculate turn rate and turn radius from aerodynamic formulas (using TAS and G) *: sometimes it can be hard to be perfectly level, so I accept a slight descent or climb, as long as everything is smooth **: I have had pretty close results doing that, so unless I am unconvinced by a specific turn, I now take only one measurement Note: it would be possible to extract turn rate and turn radius from the Tacview directly, but I'd rather calculate them from TAS and G, as I am afraid Tacview might introduce deviations (I think Tacview uses actual heading change, which, if you are not wings level, may overestimate your turn rate - just picture a loop, with in instantaneous 180° heading change). Now I may be wrong about that, but it shouldn't matter anyway if flights are performed up to standards, and the tests I did make when I started this had the Tacview turn rate measurements virtually identical to the calculated ones. It is a rather tedious process, although it isn't that long with a little practice. Count maybe 2-3 hours for one altitude and configuration. High speeds are easier than slow speeds, speeds around the best STR can be tricky because of the very big effect any change in roll will have.

Affirm, thanks for noticing the typo

I started doing some new turn performance tests with the new flight model and first let me say that on the whole, performance charts look better now, more what I would expect than before (pretty much constant G until corner speed). However, while testing sustained turns, I came across something that seems really weird : at 10 000 ft (configuration mentionned below) there is a very sharp peak in sustailable load factor at M0.92 or 520 KCAS, up to 9 Gs. I wonder if this is intended, but it looks like it might be an artifact from the flight model to me. On my end at least, it is very reproducable (note: I do my tests with unlimited fuel and GLOC off, to guarantee accurate results - supposing these do not modify the flight model behaviour in any way) Tests were made in DCS World 1.5.8.12823

Actually, both definitions exist. I believe the Navy uses (or used) that one.* But yes, the other one (head-on=180°) is the more widely used and logical. What I didn't realised is that, acording to jojo (didn't check), the Mirage actually uses both définitions, one on the HUD and the other on the VTB. Now that can be confusing. I imagine it has something to do with different thought process for intercept and close combat. *: Can't find a solid reference now, unfortunately. I'd did notice that some official Brevity codes gives aspect definitions (HOT, FLANK, etc...) with both methods (ex: HOT is "CONTACT aspect stabilized at 160-180 degrees angle from tail or 0 – 20 degrees angle from nose." There must be a reason why they feel they have to give the angles from the nose. EDIT: Found a reference, in CNATRA P825 - Air To Air Intercept Procédures (2010), Appendix C - Multiservice Brevity Codes

Got it. The way I did it was more of a workaround anyway. What would be really great would be that the cockpit= function doesn't default in the CA folder. This would not bypass CA entirely, as the module would still be required in order to take control of the unit, so I think it would be something nice to allow.

To quote the second message in this very thread:

Hi Since the new stable update (1.5.8.xxx), mods will apparently only work when placed in the Saved Games folder. This was not unexpected, but it highlights the problem I mentionned here. My custom cockpits for CA do not work anymore, because they had to be in the game's directory. I have still not found a workaround. I would really like a word from ED on this, even if it is to say that they do not want custom CA cockpits to be possible.

Happens to me as well, the VR indicator is very unreliable at short distance (I can only confirm for MP, as I rarely fly SP)

Correct wording, IMO, would be: #2: Target true heading (target bearing is 095 here, per #9) #6: Target aspect angle (relative to nose, so 0° would be head-on)

Yes, absolutely correct. Thing is, earlier in the thread, people wanted to use a tool to calculate the distances from the coordinates of the two points, which obviously won't work in DCS. By the way, I'm not sure why you necessarily talk about ground troops. PI can be used for Strike planning for example, where squadron planners will do that, not "ground troops".

Thing is, you cannot calculate ΔL/ΔG from two sets of coordinates (it would require knowledge of the exact grid-to-true north variation everywhere on the map. However, you can absolutely measure it, whether from the F10 map or a paper map, but you have to make sure to use the "DCS true north", or grid north. I imagine that for short enough distances, you can measure the local G-T variation (with approx. 0.1° or 0.2° precision if you're careful), then use that in a computation. PS: unfortunately, "DCS true North" doesn't run along MGRS grids either.

That posts only forgets to say that all true headings in DCS (as indicated by instruments) are actually relative to grid north (and magnetic headings are Grid+MagVar). So it's not only a matter of the Mission Editor or the F10 map. This is one of those things I would really like to see fixed in DCS. I hoped it would be in 2.0 but no luck. I understand this is not an easy fix, though. In fact, in DCS we can call grid north "True North" for nearly all purposes, except the ones that are related to coordinates (as in our case here), since now our new true north doesn't run along the meridians.

Yes, Piston, BUT in DCS, Grid North is called True North, and Magnetic North is based off of it. All instruments that show "true headings" actually show grid headings, and magnetic headings are grid + MagVar. So, yeah, for BAD you can use bearings as measured on the map.

All this won't work, because in DCS, "True North" doesn't run along meridians. This means that if your IP is at, say, N44°01.00' E044°00.00' and your target is due north, at N44°08.00' E044°00.00', any real-life tool will give you 0 m ΔG. But in DCS, you will have a non-zero ΔG. The only way I know to do it is use the map, and measure it there (which is tricky because you have to estimate the target position).

Hi, I have a question/request. I am trying to create a custom "cockpit" for a Combined Arms vehicle. Unfortunately, the GT.WS[ws].cockpit= call in the unit.lua expects a file path inside the Combined Arms folder. I have been unable to redirect it to a mod in the Saved Games folder. Just to be clear: GT.WS[ws].cockpit={current_mod_path.."Cockpit/custom_cockpit"} and the likes won't work, because it will search in DCS World\Mods\tech\Combined Arms\C:\User etc... From what I can tell, it is impossible to point to the right directory from there. Also, yes, I have been able to make it work with a mod in the game directory, using a clumsy "../../../../"..current_mod_path.."/Cockpit/", but I think it is preferrable to have mods in Saved Games (also encouraged by ED). It would be great if Eagle Dynamics could make it so that the .cockpit call doesn't look directly in combined arms. Or if there may be another solution, either readily available or provided by ED, it would be great.

Great list! I have a couple remarks. 1. The F-4E being modeled by Belsimtek would seem to be a late 70's version, possibly 1977 or so, according to this topic (I can't vouch for the exact date though). 2. The initial version of the Gazelle may have been introduced in 1973, but the SA 342M1 (with Viviane) was introduced in or circa 1998 AFAIK. For the other versions, I have found 1996 for the Mistral-equipped one (after initial tests called Gazelle Celtic in 1990-1991). Not sure for the SA 342L. More in-depth research might be warranted.

The accuracy in CCRP is to be improved, but if your bombs 1 or 2 kilometers long you may have a different problem. With the current accuracy you can expect to hit a few hundred meters off. Some have suggested designating the target with the upper tip of the diamond, I have yet to try this. If you could provide a track, this might help see if what you are experiencing is the "normal" inaccuracy, or something else.

It isn't, actually. It means (from the 2005 Brevity Codes): "[A/S] Friendly air-to-surface missile launch". You are right about Splash, though.

I remember that around that time I also tried using the Mirage III charts with the M2KC, using jettison for release. It wasn't that bad, so this may be another lead. For Snakeyes, the depression is easily measured by depressing the gunsight while in CCIP (at least it used to work) in active pause.