nomdeplume

Caveat: It's been over a year since I tested it so things might have changed, but at least back then the JDAMs did far less damage than LGBs and free-fall bombs. The reason is because their flight modeling is different and they lose a lot of speed during fall. The impact speed has a significant effect on the amount of damage done. During my tests I found the Mk-84/GBU-10 would consistently do around 2,500 points of damage to hardened structures (I was using a command centre and ammo depot to test). The GBU-31 would do about 850. The bunkers have 10,000 life to start with it, so to reliably destroy them took 5 hits from Mk-84/GBU-10, but around 12 GBU-31s.

Not entirely sure what you're asking. The M-2000C selects CCIP or CCRP delivery based on the store, it is not something the pilot can select. Selecting low-drag bombs will enable CCRP symbology. Selecting high-drag bombs (clusters and Mk-82SE) will enable CCIP symbology. Direct-attack weapons (rockets, guns) are also delivered using a CCIP-like pipper. Your most common choice for air-to-ground attacks will be using TAS + RS (with RS just providing a fallback in case TAS is for some reason unable to provide the needed information for a solution). I don't think TAS is functioning entirely correctly yet, so you might have more luck with just RS in some situations at present. For the fuse options, it probably doesn't really matter. If you use the delayed fuse the game just seems to have the bomb land and then explode a second or two later. It's unclear if it actually does more/different damage as a result. It might be of some use in very low-level deliveries to allow you to get further away before it explodes.

Any possibility it's being accidentally activated? It'll get ripped right off if it's deployed at speed, so maybe if things get hectic and you accidentally press the button or if there's additional bindings or a faulty controller which occasionally sends 'ghost' presses it could be deploying without you realising it?

Yes and no. Working out the indicated airspeed is not straightforward, it's not really dependent on the altitude but on air density. So while altitude is part of it, it also depends on temperature/air pressure. At least that's my understanding. If you're keen enough, you could try this: http://aviation.stackexchange.com/questions/25801/how-do-you-convert-true-airspeed-to-indicated-airspeed This page also has a converter (at the bottom) which can calculate IAS from true air speed, with some limitations. So you could perhaps use that if it's close enough for your purposes. The relevant function is calculateTAS() in AviationCalculator.js.

Probably related: slightly hard landings on building rooftops will very often set the building on fire without seeming to do anything to the Gazelle. Might be easier to reproduce than the ship damage.

If you have the Eclair pod loaded for extra countermeasures, it replaces the drag chute. If I recall correctly, the Eclair pod gives you 32 flares total, without it you would have 16. Also if you land, you'll need to re-arm to get a new chute.

Well, one possible partial explanation is that the Rules of Engagement the US has pretty much always been operating under since the advent of BVR missiles usually required pilots to visually identify a contact before they could engage it. So if your experience is that you can almost never actually use your weapons at beyond visual range, continuing to maintain and develop super long range missiles probably doesn't seem like an attractive use of resources. Especially when you can instead work on increasing the range of your cheaper, smaller missiles to give you BVR capabilities in the rare situations where you can actually utilise it. Also, semi-active missiles may be preferred in situations where friendlies may be near your enemy (e.g. when you outnumber the enemy), as it's easier to prevent friendly fire incidents if you can just break the lock and have the missile go stupid.

I think it's probably from your custom payloads, so it'd be in your Saved Games folder, under MissionEditor\UnitPayloads. You could try deleting the M-2000C.lua and you should then just have the default payloads from the main game.

Just trying it myself now actually, and can't get it to work either. The radio setting is just "ADF", "BOTH" is a separate position (transmit/receive on tuned station, listen on guard). I can hear my sound sample but the needle stays fixed to the right. Only TACAN seems to be able to move the pointer. Is there something else that needs to be done to enable DF on the HSI? The manual has very few details. Edit: working fine now, not sure what I was doing wrong. Maybe I hadn't switched the nav switch from TACAN to ADF.

I think their issue is that they don't have enough buttons on their controllers to be able to assign it to three different push buttons. So an option that cycled through the override modes and PCA selection would allow them to use a single button, even if it's not quite as convenient/ergonomic.

The following extra information about your flight might be helpful: 1. Did you correct your aircraft starting position? 2. How did you measure your drift at the end? 3. Did you also happen to measure your drift before take-off to verify your initial coordinates were accurate?

Just to try to add some clarity here. The group/unit names are not lua variables. In the scripting environment, groups and units are objects, which in lua really means it's just a table with specific keys/values. I think most of the 'objects' are just tables with a single "id" key which has the unit/group/whatever number which uniquely identifies that object, and all the calls into the game engine use that to identify it and return the data you want. The innards don't matter though - from your point of view, a unit is an "object". There is a global function that allows you to get a unit object from the name given to it in the mission editor, Unit.getByName(), which you would use like: local unit = Unit.getByName("My First Unit") local unitpos = unit:getPoint() env.info(string.format("Unit is at: %.2f, %.2f", unitpos.x, unitpos.z)) That should log a line with the X and Z (north/east) coordinates of the unit named "My First Unit" into the dcs.log. So, to explain line by line: unit = Unit.getByName("My First Unit")This calls Unit.getByName() which is one of the scripting environment built-in functions to get the unit with the given name. If that unit does not exist, it will return nil. You should normally check for that in real code, otherwise you'll get errors when you try to access it. This will create a local variable named unit which contains the unit 'object' mentioned above. --- local unitpos = unit:getPoint()This creates another variable called unitpos which - assuming the previous call actually worked and returned a valid unit object - will contain the position of the unit - Unit.getPoint() returns a "vec3" object, i.e. a table with x, y and z keys, each of which contain the corresponding distance/position value (in metres from the map origin point). The varname colon(:) functionname syntax is lua's notation for calling a 'method' on an object, and in this case it's basically equivalent to: local unitpos = Unit.getPoint(unit)but, to me, a little easier to understand. Essentially the : is telling Lua to call the function and pass the variable itself as the first parameter. Again, the details don't really matter - so long as you understand the syntax. --- env.info(string.format("Unit is at: %.2f, %.2f", unitpos.x, unitpos.z))Despite appearances, this is a fairly simple way to output stuff. It calls two functions: env.info() which accepts a string to log; and string.format(), to which you pass a string with special formatting characters and then the variables you want to interpolate into it. Basically it just provides an easier syntax than doing it yourself with string concatenation, which would otherwise look like: env.info("Unit is at :" .. unitpos.x .. ", " .. unitpos.z)although that output would be slightly different since it'd print every meaningful digit after the decimal point.

First, your "do local" is a bit strange, and is more normally written the way lua will interpret it: do local table = { ... } end i.e. you are creating a local variable called 'table' which only exist within the scope of the do/end block. So: you've created a local variable called "table" which has "vec3" as one of its keys (the value of which is another table). You can't print "vec3" because it does not exist (therefore it's nil). print(table.vec3) is probably what you want. If it works, it will just print "table: 0x12341234". You can also use table["vec3"] to access that element of it. The dot notation is more convenient for directly accessing them in your code; the array access is useful when the name of the field is contained within a variable. i.e. ages = {alice = 26, bob = 22} print(ages.alice) -- prints 26 person = "alice" print(ages[person]) -- also prints 26 --- Hopefully that's clear, so next thing: you probably shouldn't use the name 'table' for your tables, because it's actually a lua built-in. If you overwrite it you'll lose access to some functionality you might potentially want to use one day. So, best kick the habit early. --- In your first example, where you put function mist.groupToPoint (InfantryGroup001 , vec3) endyou are declaring a function named mist.groupToPoint, not calling the existing function! Also, if "InfantryGroup001" is the name of your group, then you should be quoting it. Without the quotes you would be passing it a variable named InfantryGroup001, which is probably not defined (nil). The easiest way to use the function if you're just starting would be to send the group to a trigger zone you've added in the mission editor: mist.groupToPoint("InfantryGroup001", "Zone name") This is because mist.groupToPoint() passes the provided point through a function which will, if it's a table, use the point.x, point.y and point.z elements, or the x, y, and z elements; and if it's a string, it'll try to find a trigger zone with the same name and use the centre of that as the location. Which basically means it can be called with a point directly (DCS scripting environment 'Vec3' table), a trigger zone 'object', or the name of a trigger zone (as a string).

If you only have keyboard/buttons (no analog axis), then you're going to have trouble with the brakes. F-5 doesn't have anti-skid, and the current implementation for buttons means it's all on or all off.

True. But I guess if it's activating the clutter filter when the radar thinks it's in "look-down" mode, then it can occur that the filter is active even when it's not needed. So perhaps low-PRF is really only useful in that very specific regime: where you are trying to maintain contact with something that is not actually in front of terrain, but the high-PRF notch gate would be active anyway. But this can be a pretty big area. For example if you're on the deck, on the Caucasus map there's peaks around 15,000 feet at least - so even if your radar is most definitely pointing "up" it'll still be in "look-down" mode because of the possibility of terrain behind it. You'll only truly be out of "look-down" mode if you're above the highest terrain and your entire search cone is pointing up. This is of course assuming the simpler "option b" above is in effect, i.e. the "look-down" is activated based on a predetermined altitude.

Short version: Low-PRF is potentially useful when you're in a "look-up" situation trying to find contacts with a low closure rate, e.g. slow-flying helicopters or planes flying perpendicular to you. Why: High-PRF uses the Doppler shift from the radar returns to work out the contact's closure rate. This provides "look-down" capability by allowing the radar to eliminate returns from the ground by simply ignoring anything that is "stationary" i.e. approaching the aircraft at the aircraft's own ground speed (+/- a bit to also filter out vehicles travelling on roads, so maybe around 130 kph). This also means that it will ignore any aircraft with a closure rate similar to your ground speed. In practice, that means an opponent can easily cause your radar to lose lock by turning perpendicular to your radar beam (i.e. putting you "on the beam", at their 3 or 9 o'clock) while flying lower than you (so your radar is in look-down mode). This practice is referred to as "notching" as it is deliberately causing the enemy radar to disregard you because you're in the "doppler notch", i.e. the range of closure rate that will cause your return to be ignored. Low-PRF mode is not subject to the Doppler speed filtering (I think the rate of radar returns is not high enough to work out the closure rate), so it can detect slow-flying targets in the above situation. However, because it's not filtering out returns, it will be completely swamped if it's actually looking at terrain. If a contact is much closer to you than it is to the ground, its radar return may be strong enough for the radar to distinguish it from the background. But for something like a helicopter that's below you and near the ground, low-PRF won't find it. It also won't find a fighter closing at high-speed if it's below you; the radar will just see a wall of returns it can do nothing useful with. This also applies to co-altitude contacts if there's e.g. a mountain behind them. In DCS, helicopters are also often hidden from your radar due to this effect, since they nearly always fly lower than you, and fly relatively slowly. I'm not sure this is realistic since the rotors should be very visible, fast-moving objects on radar, but it is useful for game balance purposes. Basically: a hovering helicopter will be invisible to your radar in high PRF look-down mode. It's also unlikely to be visible to you in low-PRF mode unless you're somehow at a lower altitude than the helicopter, and it has no terrain behind it (from your perspective). The notion of "look-down mode" itself is potentially a bit nuanced, and I don't know how it's implemented in DCS or the M-2000C module. I think there's basically two methods for determining if the radar needs to consider itself in "look-down" mode: a) by dynamically measuring the volume of returns and using that to enable/disable the filter as required or b) enabling it whenever any part of the radar cone is below a predefined altitude. Option b is the simplest and requires configuring the aircraft's avionics with the highest altitude of any terrain in the area it's expected to be operating in. This means your radar can be in "look-down" mode even if there is no terrain behind the target from the perspective of your aircraft, and even if the target is at a higher altitude than you. So: low-PRF is only useful when you're searching for slow- targets like helicopters, or other fighters trying to hide in your doppler notch, so long as they don't have terrain behind them. However its drawbacks are that it has a reduced detection range, and you can't hard-lock (PIC/DTT) or guide S-530 missiles (since the RDI radar needs high PRF for both). If you try to launch an S-530 in PID/TWS mode with low/med-PRF, the radar will try to transition to high-PRF and go to PIC, but may fail - and even if it succeeds, the lock may drop anyway. Medium- (or Interleaved-) PRF tries to strike a balance between the two modes, by switching between the two for each scan (interleaving). In theory this means you get the benefits of both modes while mitigating the drawbacks of both. But since it's not using its full output power for either mode, you don't get the same range as in pure High-PRF. Guidance and PIC aren't available with Medium-PRF either.

Are these possibly old missions? The way the payloads were defined was changed a while back, and old loadouts resulted in invisible pylons. I think the easiest way to test that would be re-arming while on the ground, using the current missile definitions.

Ka-50 has a laser warning receiver, not radar. So a rangefinding laser probably should trigger it, although only when it's active of course.

I believe the original sound was the stock Su-25T engine sound. Not sure if just deleting the sounds definitions for the engine might cause it to be used or if it's more involved than that, though.

Your open seems a strange. Why using "r+" mode, and why open the file for every single entry? Anyway, I believe r+ mode opens the file at the beginning of the stream, and since you never read from it or otherwise advance the file pointer, you just overwrite from the start of the file every time you write your new line. The easiest fix would be to just change the flag to "wa" mode (write append) so it opens the file and puts the file pointer at the end; but really I would be opening it before you enter the loop, and close it after you finish, so save all that unnecessary work within the loop itself. i.e. if _height <= 2 then local _tabletarget = table_unique(targetObjects) -- overwrite file each time, change to "wa" to append to it exportFile = io.open("ground units report", "w") for k, v in pairs (_tabletarget) do ... local text2 = ... if exportFile ~= nil then exportFile:write(text2,'\n') end end if exportfile ~= nil then exportFile:close() else trigger.action.outText("Unable to open output file!", 20) end else trigger.action.outText("You need to land to reveal the pictures",20) end Alternatively if you expect the output to be fairly small (no longer than a few tens or hundreds of kilobytes) you could just append it all to a single string, then write that string out at the end. if _height <= 2 then local _tabletarget = table_unique(targetObjects) local outputstr = '' for k, v in pairs (_tabletarget) do ... local text2 = ... outputstr = outputstr .. text2 .. "\n" end -- overwrite file each time, change to "wa" to append to it exportFile = io.open("ground units report", "w") if exportFile ~= nil then exportFile:write(outputstr); exportFile:close() else trigger.action.outText("Unable to open output file!", 20) end else trigger.action.outText("You need to land to reveal the pictures",20) end P.S. It might be easier for people to open the file if its name ends in .txt.

It was from the DCS changelog for the initial release of the module at the end of July.

Yes, that's the button, Magic Slave/AG Designate/INS Position Update. It is a separate button than the one used to lock air targets (STT/TWS Toggle (Target Lock)). They are both in the HOTAS category. As its name suggests, it has multiple functions depending on the avionics mode. I don't think it has a default binding.

Interesting. You can have a look in your game install directory to make sure they're there. They live under mods\aircraft\F-5E\Missions\Training. You should be able to load them by specifically browsing to that location, as a workaround. Do other modules show up in the training section?

Could you possibly be a little more specific..?

Datalink is for the A-10C datalink. Not relevant to other aircraft. Were your two clients in the same group, or in separate groups? Just thinking that the ability to have multiple players in the same group is fairly recent and maybe the JTAC script might not work properly with it.