toutenglisse

Here is an example with a little function I wrote. (to use it, load MIST and my script with mission start trigger, and when you need use MoveTo('group 1 name','group 2 name') so group 1 moves to leader of group 2 until group 2 or group 1 is dead). In the example, the blue group of 4 soldiers use the function to attack Red1 group, then Red2 group. Red1 group has 2 soldiers hidden behind houses. You can watch it in F10 map view and accelerated time. (their feet is their only carriage...) Edit : removed example, an updated one is posted in a following post.

Yes this is what is needed for ground groups to engage others : "line of sight" and "in range". So you have to script this. If there is for example 1 enemy group, make your group move to unit(1) of enemy group (and eventually hold position when "line of sight" on it and distance < fire distance), and when destroyed and your group is still alive repeat move to unit(1) of enemy group until it is totallty destroyed.

Thanks, that solves everything in the simpliest way. With copy/paste it is possible to place "invisible farp" with correct heading on every heliport, and then just place a helo with "ramp start". (...even if the heliport has a tree on it and should be considered dangerous for player and not practicable for AI ^^)

yes, engine is running and unit is heating up and appears "hot" on flir (if unit has the new flir complient textures).

@104th_Money just as a side note, with script it is possible to spawn an invisible Farp wherever you want (in picture attached : on a heliport where mission editor doesn't allow to). That makes all syria's heliports available. (with one limitation : mission editor also won't allow you to place a ground started helo in some cases, so the heliports will be available for everything except spawn on it)

It is the hottest summer ever! I'm interested in almost all new projects, and eager to try the new AI bfm.

I just noticed a thread with changed title, that shows old title on main "home" forum page.

Did you notice that @Mover made several videos flying DCS with @Wags ?

You can try this tip :

@104th_Money In case it helps, many are in fact usable. The only limiting factor is : can you place an "invisible farp" close enough. There are 3 scenarios : 1) you can place an "invisible farp" right on heliport. In this case you turn farp's heading to match heliport's heading and you use "start from ramp". 2) you can place an "invisible farp" at less than 100 meters from heliport. In this case you use "start from ground" and turn your helicopter unit's heading to match heliport's heading. 3) you can't place an "invisible farp" at less than 100 meters from heliport. In this case you can't use the heliport. To quickly see what heliport you can use, use the base mission from @Grimes, create an "invisible farp" anywhere, click and hold farp's icon with left mouse button and move it accross the map, also using mouse wheel in and out to zoom, to see if it can match or close enough the marked heliports. .miz example and picture attached to show cases 1) and 2), don't forget to add ground units to get comms, ground crew, power/rearm/refuel. BASE MISSION used is from @Grimes (heliports are marked in mission editor), you can find it here : Ruler with both length units can be found here : test-Syria-heliports.miz

In case it helps, it is possible to use a very simple script (DCS event) to detect engine shutdown, and then in your trigger you set conditions : unit dead OR flag true (flag is turned true in engine shutdown event detection). EDIT : you could add to flag true a unit's altitude>X condition to avoid normal shutdown at base. Attached is an example .miz and .trk where an Anton kills engine of a Mustang, and when propeller starts to stop after some seconds the trigger fires. (the script only detect the Mustang unit, but it is easy to make it work with any unit, and activate a flag that is the unit's name so you easily can set your triggers for all units with associated flag - I'll add it here if needed) test-dead-or-EngineOut.miz test-dead-or-EngineOut.trk

@exil yes, as long as your radio items are created at the group level (no addSubMenu or addCommand for all or coalition), you just have to add to associated function's arguments the groupname, groupID, whatever. But nothing exists at the unit level. Ex : missionCommands.addCommandForGroup(GroupId, 'Guns only, defensive', _1v2Path, _DogFight, GroupName, GroupId, GroupCoal, GroupType, GroupBaseC, GroupBaseP, TKName, AWName, WMFreqVal, 2, 2, 2) Inside the function called by the command, you can add lines to, for example, add to a table a new entry with time, function name, and all datas you need relative to the group that triggered execution of it. Or trigger a message with these datas...

@XCNuse F10 radiomenus work OK here (BTW they are created by DCS scripting functions, not MIST).

@Hotdognz you need this option :

Yes, due to very simplified FM of these kinds of AI, and some situations where for example they have to correct their position/trajectory with an initial orientation that is way off their new trajectory vector, they do crazy moves. Example track attached : 1 pair of B17, crossing trajectory of another B17 pair, has to rejoin it in a "big formation". N°2 from follower pair does crazy moves to rejoin its position in formation. WWII-bomber-FM-bug.trk

"forged in truth". Solution can't be simpler / more straight forward. (example attached for @Grodin) test-change-tanker-orbitRT-speed-alt.miz

Salut @Flappie. It is the icon in mission editor, on the bottom bar, with a battle tank on it, to show the unit's 3d models instead of only unit's icons. Effectively, since one or two updates, when you rotate a template group the units don't rotate individually to keep the original group's aspect. It was the case before. The only case where the units were not rotating with the group was, for what I saw, in the case of a group of static objects, created by mission file editing. I see this "visual bug" (the units in fact rotate correctly / are correctly placed when mission is launched) as a "mark" that Devs are working on this.

Hi, doing that with mission editor is OK (I've just tried with a small moving zone linked to a small static cargo linked to the carrier, so the moving zone stays on elevator 4. Bringing another cargo and unhook it on elevator 4 triggers a successfull "cargo dropped in zone", by detecting "cargo unhooked" + "cargo inside moving zone"). The big issue I see is that the cargo you unhook on moving ship's deck stays static in space, so it just slides off the deck...

You can try :

nice !

Hi, you can find in ...DCS World OpenBeta\Mods\aircraft\FA-18C\Cockpit\Scripts\devices.lua the device number for AMPCD at line 50 : devices["AMPCD"] = counter()--37 -- Advanced Multipurpose Color Display - ??? and in ...DCS World OpenBeta\Mods\aircraft\FA-18C\Cockpit\Scripts\command_defs.lua the numbers for AMPCD pushbuttons at line 501 : -- MDI/AMPCD Pushbuttons count = start_command + 10 -- Pushbuttons are numbered clockwise from the lowest button at the left side for PB_num = 1, 20 do local PB_command = counter() MDI_commands["MDI_PB_"..PB_num] = PB_command AMPCD_commands["AMPCD_PB_"..PB_num] = PB_command end That you can read like this : start_command is 3000 (written at the top of script) so count is 3010 First pushbutton (lowest from left side) is : AMPCD_commands["AMPCD_PB_1"] = 3011 (PB_command = counter() = count + 1 (that is also written at the top of script) = 3011) Other 19 pushbuttons clockwise from the 1st one are 3012, 3013, etc...

@Florence201 yes it works this way, and it is intended (it is not a bug, I've already asked for this topic). As the "Orbit" task seems to be by design a "waypoint action" (even if created in "triggered actions" tab), it always sets its orbit center to the "currently passed waypoint", when Orbit task is activated with "AI Push Task". If you use "AI Set Task" instead, the orbit will be centered on actual position of the aircraft, because "AI Set task" does erase the route and associated tasks, so the only "currently passed waypoint" is the actual position of the aircraft (it is like if it just spawned here with no other wpt/task). Consequence is that when Orbit ends, the aircraft just RTB. With airplanes, there is a workaround : using aerobatics to do circles (as much as you want, cumulating aerobatics if necessary), as aerobatics happens at the point the airplane is when it is triggered (and simply using a stop flag to resume flight plan). But Helos don't have aerobatics option. Edit : attached an example with very simple script solution (AI group orbits where it stands, and resume route, using player's F10 radio menu to execute functions) Test-orbit-resume-script.miz

@Gryzor and @NineLine I tried with track number 2. Turned it into .miz and tested. For a reason I'd say the "attack group" task has a bug / corrumption. test-1.miz is the exact mission from track : (as player I activate Balt and reduce throttle to stabilize M0.81) Mig29 turns from merge and then immediately break from fight (all the times, but sometimes, rarely, it is because he lost detection upon player - checked that with a istargetdetected() trigger) test-2.miz is the same but I just re created the "attack group" task with the exact same default option : Mig29 allways kill the player (no break) Also Mig29 can shoot guns face to face (see track). test-1.miz test-2.miz Mig29-vs-sitting-duck-face-to-face-gun.trk

Shocking quality for all cockpit pictures. Your work looks like a hudge task. I feel sad to think that, while several projects did turn from absolutely promising mods to FF 3rd party modules, the Ka-52 might by problematic - due to laws - to become a 3rd party module at a point.

Hi, it doesn't seem normal to me that you can rearm at a FARP with only "invisible FARP" and "APC M1025" comm vehicle. (in theory you would also need "M818" or "FARP ammo storage") Track attached : refuel denied, but rearm OK. Farp-rearm-without-ammoStorage.trk