IlludiumQ36

Use the TGP to locate and set SPI on your target point - slave MAV to TGP - set MAV display SOI - Boat Switch forward, then Boat Switch center - TMS Up Short to fully collapse tracking gates - Fire

Why bother? Because in Force Correlate mode, TV-Mavs have a greater "effective" range than IR Mavs. You can pop SAMs from 10-14 nm out. IR's achieve lock at 7.5 or less.

A101wayz's method is an excellent alternative to using the RANDOM condition. His setup only requires two triggers to achieve a 25% chance. To utilize RANDOM in your setup, it will take three triggers: Trigger #1 1 ONCE/No Event Conditions: ALL OF GROUP IN ZONE (SINGLE A10, New Trigger Zone) Actions: FLAG ON (50) Trigger #2 ONCE/No Event Conditions: FLAG IS TRUE (50) RANDOM (25) FLAG IS FALSE (51) Actions: GROUP ACTIVATE (MIG-23) Trigger #3 ONCE/No Event Conditions: TIME SINCE FLAG (50 / 1 second) Actions: FLAG ON (51) This will allow for only 1 second to evaluate the RANDOM condition as true.

The RANDOM condition can be used in multiple types of triggers and combined with different functions to get a required output. The simplest application is a type:MISSION START with condition:RANDOM (x). It is only evaluated only at the start, only one time, and does not require any other conditions. Example -- MISSION START / RANDOM (25) / GROUP ACTIVATE ("Enemy CAP") Using RANDOM (x) in ONCE triggers requires a little more investment due to trigger behavior. ONCE-type triggers are executed once only (when all conditions are met), but evaluated every second until true. This makes a RANDOM condition eventually become true regardless of the percentage value. Thus, some other conditions need to be part of the trigger to control the output. Additional triggers may be required depending on the conditions and actions to be achieved. SWITCHED CONDITION triggers using RANDOM are evaluated like ONCE triggers, but can be executed infinitely meaning it will constantly be evaluated. Without some controlling conditions and secondary triggers, it will become true eventually. See my posts in this thread: https://forums.eagle.ru/showthread.php?t=233680

Right-click DCS in Steam, select properties. Go to Betas tab, select "openbeta - Public beta versions" from drop down list. It should update automatically. You can switch back to Stable by selecting the "NONE-opt out..." option.

To expound on the concept, the above example is specific to an exact known point of time in the mission. But what if you wanted to perform a random spawn of some group after a time-variable event, say, destroying a convoy or intercepting and shooting down a bomber? To achieve this, set a flag after the event in question (Group Dead ("Bomber") / Flag On - 100, for example). Then set the two following triggers: Type: ONCE/No event Conditions: TIME SINCE FLAG 100 = x seconds RANDOM (y) FLAG IS FALSE = 101 Actions: GROUP ACTIVATE ("Random Group") Type: ONCE/No Event Conditions: TIME SINCE FLAG 100 = (x+1) seconds Actions: FLAG ON = 101

My multi target workflow: Initial Setup: Right MFD - CDU (this is where you will see your Mark Points as they are created) Left MFD - TGP (Make SOI) Go wheel (orbit) at a safe distance from targets 1.) locate and mark target (TMS Right Short) 2.) verify mark appears on CDU display 3.) repeat 1-2 as required 4.) CDU Steerpoint knob to Mark (or FUNC/8 on the UFC) 5.) Set HUD to SOI (Coolie Hat Forward/Up) 6.) China Hat Aft Long to slave sensors to steerpoint 7.) Cycle through your mark points using DMS up/down to verify targets. Watch the TGP as you do so. Set to Mark A (assuming this is the first point on this attack run). 8.) DMS right/left to select JDAM 9.) run in on Mark A and pickle per your HUD cues. 10.) immediately after pickle on A, DMS up to cycle to next Mark Point - pickle per your HUD cue - repeat until done

Type: ONCE Conditions: RANDOM (25) TIME MORE (20) TIME LESS (21) Actions: GROUP ACTIVATE ("Your group") This works on the premise that ONCE type triggers are evaluated each second. Thus, these conditions can only be true for one second @ 20 seconds into the mission. The TIME LESS function keeps the conditions from eventually becoming true after that point as the ONCE type trigger will continually be evaluated until it becomes true.

Skewing a touch off the topic here - I've read posts articulating a lot of different values for the range from supply vehicle to ground unit, any where up to 220m. Is there a definitive max distance? And also, can the supply vehicle be a static object?

Are you using trackIR and if so, do you have those keys "trapped" in the software settings?

I've seen this behavior in other maps, NTTR, for instance. I believe it is because there are no valid parking spaces for the type of airframe you are trying to place. The size of the plane dictates what ramp spots are available.

A workaround for respawning (without scripting) is to make several copies of the group placed in the same location with each group being set to activate after the previous group is destroyed. Obviously, each group will need to be set for late activation and triggers will need to be set for each groups' spawn (as well as individual triggers for other aspects of the mission that would be specific to each of these groups). Once that original group is dead, any other triggers specific to the group are no longer valid.

I don't really understand what you are asking in #1. #2 - You cannot place statics inside or under a map structure. At Nellis, I just place my static planes between the canopies (sunshades, as you call them). #3 - I don't think that static object elevation is user definable in the ME interface. They seem to adjust for the terrain elevation depending on where they are placed.

You don't have a condition set to instruct the Su-24 to break orbit. I tweaked your mission a little bit: -added a stop condition for the orbit task(flag 2 is true) -added flag 2 ON to the radio command -changed Search and Engage task to Search and Engage Group (SA-11-1) with "Visible" set to On -Removed SEAD enroute task (you had it disabled) -Added Reaction to Threat option, Passive Defense. SEAD Escort(edit).miz

1) Has something to do with the fusing? Not sure. 2) never messed with it 3) The planned escape maneuver after bomb release. I believe this has some subtle effect on release parameters depending on your dive angle, speed, altitude, etc. 4) HOF (height of function) someone with more detailed knowledge may chime in on this one, but I would think the sensors in the bomb canister would function according to barometric pressure, so probably MSL. 5) RPM is the spin rate of the CBU canister - more spin = higher dispersal area, but less concentrated effect.

Place a Ground Unit - set type to Fortifications - choose a unit.

If your structures are Static Objects, then they cannot be assigned. There are some structures that can be placed as Ground Units. Not many choices though.

Another thing to consider: set your bomber's waypoint 3 as a Fly Over Point. If it's a Turning Point, the bomber may be turning towards waypoint 4 in such a manner as to not enter your trigger zone, thus not engaging Flag 71. Waypoint 4 is practically 180° opposed to WP3 and the bomber will start it's turn well before WP3. (See the DCS manual for unit behavior at turning points vs fly-over points) SUNTSAG's added trigger conditions aren't necessarily "fixing" what I believe to be the core issue (the bomber not entering the Sheep Mountain zone) as much as it is giving additional chances for the trigger to fire from the trailing escort craft. Trailing craft tend to take wider arcs when their host unit changes direction.

Some initial thoughts: You say that Flag 71 is activating because your bombers are switching waypoints - well, from what I see on Group Bolo 1 (Unit Bomber 01), you have a Switch Waypoint task from 3-4 on waypoint 3 - that seems redundant - without any other taskings, that unit is going to waypoint 4 no matter what. Are you getting the message that is tied to your trigger?( TIME SINCE FLAG 71, 180 - Message: "MERLIN: Holy cow, Cougar, there's several of them!", 10) You are triggering Flag 71 with (UNIT INSIDE ZONE, Bomber 01, Sheep Mountain). Maybe try GROUP INSIDE ZONE, Bolo 1, Sheep Mountain) since Unit Bomber 01 is a single unit group. Also, and this is purely a shot in the dark, but I noticed all of your Section 1-6 flights are set to Fly Over Point at their air start position - That always seems to default to Turning Point whenever a new flight group is created. Otherwise your unit setup looks good - all have late activation checked.

You are correct - search target is "known" to the engaging aircraft prior to "detection".

Attach mission?

Can someone direct me to the line in the ctld.lua that determines how long the JTAC Status message remains on screen - the F10 message, not the default? I like to enter coordinates and create waypoints to the JTAC locations and it's a pain having to recall F10 two or three times to get everything typed in the UFC/CDU.

Hmm..I've always thought FLAG X=1 is FLAG X TRUE and that FLAG X=0 is FLAG X FALSE. Just seems that I read that somewhere on these forums. I'll try your suggestion. Thanks.

I have 3 randomly spawned groups with each group assigned a Flag Increase action on spawn and a Flag Decrease action on Group Dead. I start with a new flag and a base number of 1(Flag On). It's essentially a counter to determine if all spawned groups are dead and it doesn't matter how many of the groups spawn as the counter will always return to 1 on all groups dead. In play-testing, I cannot seem to get these actions to function.The value of the flag never changes; It remains at the original value of 1. Regardless of whether any of the groups are alive or dead, the final trigger activates. I only want a message to group to activate if any of the three groups are activated then ALL of the activated groups are destroyed. For further testing, I set up some debug triggers to send messages to coalition and increase the flag value after the message, then send another message if the flag value actually increased. I repeated it for the decreasing values. MISSION START -- no condition -- FLAG ON 25 ONCE -- FLAG IS TRUE 25 -- MESSAGE "Flag 25 = 1", FLAG INCREASE 25, 1 ONCE -- TIME SINCE FLAG 25/10, Flag 25 = 2 -- MESSAGE "Flag 25 = 2", FLAG INCREASE 25, 1 ONCE -- TIME SINCE FLAG 25/20, Flag 25 = 3 -- MESSAGE "Flag 25 = 3", FLAG DECREASE 25, 1 ONCE -- TIME SINCE FLAG 25/30, Flag 25 = 2 -- MESSAGE "Flag 25 = 2", FLAG DECREASE 25, 1 ONCE -- TIME SINCE FLAG 25/40, Flag 25 = 1 -- MESSAGE "Flag 25 = 1", FLAG DECREASE 25, 1 ONCE -- TIME SINCE FLAG 25/50, FLAG IS FALSE 25 -- MESSAGE "Flag 25 Off (= 0)" The only trigger that activates is the first one (and apparently, only the message). Logically, it doesn't make sense to me why my little debug set-up doesn't work unless these functions are bugged or there is some other requirement. What am I missing here?

Same here. NTTR is truncated, Caucasus is unaffected. https://i.imgur.com/PXbhmfj.png - This is a fully zoomed out view of NTTR. The entire East side of the map is inaccessible - cannot zoom or pan to get to it. The North and South are cutoff as well with only a limited amount of pan available. I wonder if this has something to do with the upcoming MAC module having restricted portions of these maps in particular and that code possibly being integrated into the current builds in preparation for release. Regardless, this needs to be corrected. I didn't pay $50 for a full map only be able to build missions in a section of said map.