nomdeplume

At some point they added the Detection functions, which you can use to get insight into what units a particular group "knows about". Attached is the script I use (no dependencies) which might give you a starting point, and in simple cases may be all you need. It gives the ability to set a flag when a particular group (usually an EWR or SAM) "knows about" enemies. By default it only cares about detecting player-controlled units, but you can pass it "detectAI=true" to make it also detect AIs. There's a few other options, like only setting the flag after a certain period of time, or ignoring units outside of a particular range or zone. Documentation (such as it is) is in a comment block at the start of the script. Another function which I haven't seen working (though I've only tested it very briefly with a player-controlled Mirage; might work with AI units or other modules?) is this one: boolean, Object function Unit.getRadar(Unit self)which would be used as: radarIsOn, trackedUnit = someunit:getRadar()with the first return value (boolean) indicating whether the unit actually has a radar or not, and the second (an object) the thing the radar is interested in (presumably tracking/locked; nil if it's not tracking). detection.lua

Still don't understand why you would want to activate the next blue group while the first one is still alive, though. I think your best bet would be to make a large zone covering the entire 'combat area' (i.e. not including the airbases you spawn on), and use a "PART OF COALITION (red) IN ZONE" 'switched condition' trigger to increment a flag. That way, when a red player enters the zone, flag gets increased (to 1 initially). Then you can have a normal 'once' trigger with condition "flag value equals 1" to activate the first AI group. Another 'once' trigger condition "flag value equals 2" to activate the second AI group, etc. To spawn the next group, all red players will need to exit the zone (so that the condition of the "switch condition" trigger is no longer true), and then one of them re-enter (making it true again). If everyone gets shot down, that counts as "exiting the zone". If someone survives, they just can fly back to the base area to meet up with the respawning players, thus exiting the zone. Or you could use a smaller zone that people will probably no longer be in once the combat starts. This would probably be the easiest way to set it up without using a dynamic group creation script, which would allow you to spawn infinite groups. It would be fairly easy to add several waves this way, potentially with different numbers of enemies and different weapon loadouts to make it progressively more difficult.

Does your mission use dynamic weather? I've seen crashes in the weather DLL that I resolved just by changing the pressure zones. Presumably there's some combinations that it can't cope with. On the other hand, this update was pulled, so you might just want to wait until they release the fixed update and see if it still has problems.

This will be difficult, as non-activated groups are not counted as "Dead". Also I think when a client respawns the group will stop being dead. So the only way this would work is for every slot to be spawned in, and for all the clients to be killed. But, I don't quite understand why you want to activate the second blue group when all red (i.e. clients) are dead. It would seem to make more sense to me that you activate the second blue group when the first blue group are dead; possibly also requiring a red player to be in the activation zone?

Yep, known issue.

On the INS panel is a selector dial which allows you to select the parameter displayed. Amazingly enough, putting this in the "ALT" position will show the altitude of your current waypoint (6,562 feet in my screenshot).

Known issue. Workaround is to use the HOTAS 'Magic II SELECT' button (not the PCA 'Magic II SELECT' button) which still allows the smoke pods to be selected.

Middle position. Most forward position is test mode. Not sure what it does in test mode, but generally doesn't produce sound. Btw, other switches like the HUD switch and countermeasure switches are the same, off, on, test. If you just push them all the way forward your systems won't be operating how you think they should!

Are you using 1.5.3 stable or open beta? The module hasn't been updated in 2.0 for some time. If you are, then I think it'll be usual thing of removing any mods you have installed, running a DCS repair, and testing it again without mods.

Well, that's interesting. I don't know what to make of it, but most of the time is being spent in state "BtwnRenders" which I assume is "everything except rendering". So that implies it's very unhappy about something on your system. Two of them are showing nearly 2.5 seconds, and the 3rd is still spending a quarter of a second. Just to be certain, you get this behaviour in all M-2000C missions? Do you know how to use the mission editor enough to make an empty mission with nothing but you're aircraft and see if that makes any difference? If it's still bad, maybe try switching it to an AI M-2000C so you're spectating - does it only happen if you're in the cockpit? On that subject, if you hit F2 or F10 or something to switch out of the cockpit view and go external or to the map, does the framerate recover? If it does that'd point to something to do with the cockpit rendering, if not then maybe flight modeling or other systems. Finally, are you able to have Resource Monitor open and check if you've got any disk activity? The extreme time involved suggests it could be waiting for I/O or similar. You can get to the Resource Monitor by opening the Task Manager, going to the Performance tab, and clicking Resource Monitor... at the bottom. Then click on the Disk tab to bring up info about the disk subsystem. Or if there's other programs you prefer to use, use them instead - basically just looking for any kind of explanation as to what the heck the game is spending all that time doing. Oh yeah and of course - what's the DCS.exe process CPU usage when it's crawling along like that?

Friendlies are indicated by a diamond symbol on the contact in the radar display. Enemies do not respond to IFF interrogations and do not have any symbol. In the game world, everything is either friendly or enemy, so lack of a symbol effectively indicates an enemy. Real life is a bit more nuanced. To enable IFF, you need to move the IFF selector dial to SECT or CONT mode. This is on the right hand side horizontal panel. The IFF section has a four-digit code number (set to 0000 by default) - the selector dial thing is to its right. (The code set does not matter.) Then there's a button on the HOTAS you can use to interrogate for IFF, and it'll show diamond symbols on friendly contacts for 30 seconds.

You could try hitting Ctrl+ScrollLock twice to get some extra information about where the system is spending its time each frame, and take a screenshot (PrintScreen - saved in Saved Games/DCS.../Screenshots) to share that info. Something in there might provide a clue. What resolution do you play at? Also, you said "sucking so much memory" - what was this based on? How much memory does Task Manager say DCS is using when you're in the M2000C cockpit? What about other aircraft? Probably best to restart the game between tests, I've noticed the memory usage tends to creep up when I'm repeated restarting a mission I'm building and it regularly goes over 8 GB on the Black Sea map.

That's a bit like asking what really happens when a pilot engages in BVR combat. :) You can make generalisations, but the specific actions they take will depend on the particular circumstances. In general though, if things turn out to be not as expected, it's probably a good idea to get out of there while you still can and reassess your plans. So in this scenario, was the pilot aware that the enemy possessed things with 'more powerful' radars? Was the pilot expecting to remain undetected at this point? If so, a sudden (but short-lived) spike might well inform the pilot that they aren't undetected, and therefore if their plan was to abort if they were detected early, then they'd abort. On the other hand, maybe they weren't expecting to get all the way to a shooting position without being detected, but just wanted to reduce the amount of time the enemy had to react. In that case, they might well continue. If the pilot is being supported by AWACS or similar, then they're probably providing better radar coverage than the pilot's own radar would provide, so they likely have pretty good situational awareness. Search radars will generally perform a 360 degree scan, though I guess in some very specific circumstances they could be limited to a specific arc. Practically speaking though, you need to think in 3D: they scan a sphere (at least, the top half of a sphere). But it's common for parts of their search sphere to be masked by obstructions; terrain, trees, buildings, possibly weather. Depends on the altitude - a hill that's near the radar site could mask out a big slice of the airspace. But the air above it would still be in full view. Also, ground radar are just as susceptible to clutter problems as aerial platforms, so may have difficulty detecting/tracking contacts that are in line of sight, but have a mountain or similar behind them. So generally speaking, higher altitudes will have better/more radar coverage than lower altitudes, and coverage will tend towards "circles centred on radar sites". Lower altitudes can get quite complex, though it's theoretically simple: anywhere that a radar within range has line of sight to will be covered. This is why most modern SAM systems are designed to be highly mobile. A fixed SAM site can be combined with a detailed topographic map to determine blind spots. If you don't know exactly where the site is, you can only estimate probabilities that certain areas aren't covered.

It's not selectable via the PCA buttons, but the "Magic II SELECT" in the HOTAS category (not the Weapons Management category) will still select smokewinders. And they'll still give the seeker tone when selected. ;)

I think it's definitely worthwhile for ED to try to find ways to monetize improvements to the base game. There's a lot of things that could and should be improved or added, but only make sense if they're available as part of the base install. e.g. new AI units, more liveries, etc. Personally I really want more "low threat" ground units, things like technicals with a variety of light weapons. Fighting the same Zu-23-on-a-Ural over and over gets dull for COIN type missions. Maybe the new particle system could do justice to 'flak' as well. More civilian aircraft would be nice to have, too, to be able to populate the skies. But none of those things would really make sense as standalone DLC, since then mission makers couldn't rely on people having them. There's a lot of value in things like that being part of the base game. On the other hand, if you can do things that directly make money (new maps, aircraft, campaigns, etc.) then it's hard to justify doing things that don't have such a direct payoff. On the other hand, another thing to consider is word-of-mouth, e.g. lots of people find out about DCS via videos on YouTube on the like, so it's in ED's interests for the game to look as good as possible for everybody. One strategy which would be particularly interesting with a texture upgrade DLC would be to make it available at whatever price point they feel is right, but with a clear notification that it will also be a free update for everyone at some specific date in the future, e.g. 2 or 3 months away. That lets people who want to support the creator - or who are just impatient :D - vote with their wallet, while still letting everyone benefit from the update in the long run. They could even reduce the price on a weekly basis or similar, to reflect the amount of time until it becomes free. That way people can decide what price point they think is reasonable; some people might be willing to pay $5 to get updated textures a month early, but not $10 to get it two months early, for example. This model could possibly even work for AI units, as people who decide to buy it to get access early could design missions using them, and then everyone can play those missions later. There are already community-made addon units, but they're rarely used by mission designers that want to distribute their missions because most people don't want to mess around with mods just to play a user mission.

Makes sense. To detect a target at say 45 nm, the radar must emit enough energy for the radio waves to not just reach the target, but also be reflected back to the emitter. So it needs to be enough energy to travel at least 90 nm and still be recognisable, plus not all of the energy would be reflected to the emitter (some scattered, some absorbed). I think it's also likely that you need a stronger signal for a radar system to be able to determine the precise distance a contact is away, in order to build a track and distinguish it from reflections from clouds etc. A RWR on the other hand only has to say "I'm getting a weak signal from this direction" and can be much more vague about the "distance", especially at long ranges. All it really needs to communicate to the pilot is "I'm picking up an emission from this type of radar, but it's too weak to currently be a threat".

Would not be impossible for them to add, though. They already have parachuting pilots, and they have some infantry units as well. All it needs is the will to make some parachute units that become infantry when (and where) they land. The really hard part would be the mission editor UI to make them do something useful once landed. One of the most interesting things mentioned in the latest DCS Newsletter was the implementation of different runway types for the Normandy map, and placeable airfields. So it's not so far-fetched to think we might one day have placeable grass airfields that are perfectly landable. Also, you can already land on roads without problems, so there's a fine workaround already. :thumbup:

The Q&A part was done in the chat during the stream, so not in the video itself. Answers have just been posted here: http://forums.eagle.ru/showthread.php?t=164579

They - and all the other 3rd party devs - have consistently said that the module will be released on Steam once it's "released", i.e. out of beta, finished, complete. There's no date given for when that will occur because it's not yet known.

What's your framerate when this is happening? You can hit ctrl+scrollLock to get a counter within the game.

I just encountered something that might be related. Head-on contact (B-52) at about 45 nm. My altitude ~18,500, theirs ~15,600. Was able to tag it for PID mode, but after a few seconds the contact was dropped. Altitude readout at the radar cursors says 0 - (-33). When I reset the antenna elevation the contact re-appears. Attached screenshots might show it clearer than I'm describing. First: before tagging contact for PID/TWS. Second: contact is tagged. Third: right after losing contact. (Elevation is 6 to (-27) - did not take screenshots first time it happened.) Edit: some more playing with it, and it looks like it's related to the player's pitch axis. Pointing the nose down results in the altitude cursor showing higher numbers, pulling the nose up causes lower numbers. With pitch at -11 degrees (as shown in the statusbar in F2 view) the cursors are showing 49 - 33 for the altitude. This does not occur without a contact tagged. It looks to me like the antenna elevation just remains where it was when the target is lost, which I think is the expected behaviour. The strange occurences with PID/TWS mode might be unrelated. The min/max altitude readout does change with a target locked in PIC/STT, but only as expected.

Game options, Units (dropdown in right hand colum) -> Metric. Affects mission editor, in-game F10 map, and the status bar in external views.

Mods\aircraft\M-2000C\Input\M-2000C\joystick\default.lua (or keyboard\default.lua if you want to assign a keyboard command for it) in the game installation directory.

I think I might have found the issue with the starter not working. Repro: Cold start. Battery, fuel pumps, starter switch on. Move throttle forward so it no longer moves back to the 'stop'/'off' position, and will go back to 'idle'. Use the "Engines STOP" command (Default: RShift+End) - throttle will move to the stop/off position. Press engine start button. No effect. I tried binding "Engine IDLE -> OFF Button" (no default) and when I used that instead, it worked fine. On more careful investigation, it looks like "Engines STOP" presses and holds down the Engine Shutdown Button next to the throttle. While it's held down, the engine won't start. (That sounds logical. :)) So if you use "Engines STOP" (RShift+End) you can just left-click the little red Engine Shutdown Button just to the right of the throttle to pop it back out. Once it's out, the engines will start normally. I'm not sure what "Engines STOP" is supposed to do that's different to the "Engines IDLE -> OFF Button". Although the "Engines START" doesn't appear to do anything, so perhaps these are the 'auto startup' and 'auto shutdown' binds? (Normally those are in the 'cheat' category though, and use the WinLogoKey+Home/End.)

Not sure, but I have read that they don't let the nose drop on its own (not just on the Mirage), as it can come down too hard. Better to gradually lower the nose yourself while you still have control to do it gently. Intuitively it might make sense for the FBW to raise the nose to try to maintain AoA as the speed slows. But perhaps there should be a weight-on-(main)-wheels modifier to that behaviour to prevent it commanding a tail strike?