Hardcard

Here's a way of getting the unit's altitude from ground (required fields marked in red, don't remove the quotation marks): As for radar detection, let me think about it.

As it's written, the script will work with any standard unit, as long as it exists on the map and has the ME unit name that you've indicated in the script.

Some tasks can be pushed on individual unit controllers. I've recently done this using AttackGroup task... don't know about routing tasks, though.

Yes, but what kind of Elnya Tanker are you using? The standard unit or the static? In other words, did you pick it using the ship icon or the statics/structures icon?

The following script will generate an explosion on the designated unit (required field marked in red, don't remove the quotation marks): I'm assuming you aren't using a static Elnya tanker, btw. Let me know if you are.

AFAIK, this can't be done, not even with scripts. DCS objects always spawn with full health. You could, however, set off an explosion on spawn, that would damage it.

Ok, so you're only interested in triggering a flag when a client flies over a certain altitude and gets detected... right? What would be the altitude threshold? Also, can you provide more details on detection conditions? Do you want the flag to be triggered when the client gets detected by ANY radar or only when it gets detected by certain specific radar units?

I haven't tested it, but I'm guessing this would work: unitRadar,target = Unit.getByName("[color="Red"]ME PILOT name of the unit using the radar[/color]"):getRadar() target:getName() [color="Blue"]-- Should return a string containing the name of the unit being painted[/color] [color="Blue"]-- It can be used in messages:[/color] trigger.action.outText("Name of the unit being painted = "..target:getName(),10) [color="blue"]-- In logic checks (probably what you're after):[/color] if target:getName() == "[color="Red"]ME PILOT name of the unit you're interested in[/color]" then do stuff end [color="blue"]-- etc.[/color]

Interesting, I'll try it, thanks. Although I'm not sure it's going to work well on all aircraft. In my case, I use trim reset in the following situations: - When I need my full climb ability in mountainous areas I usually trim cyclic and rudder when cruising, so altitude, heading and speed remain kind of constant. The problem with this, however, is that it drastically reduces climbing ability. I guess that this has something to do with the rotor mast being tilted forward when the cyclic is trimmed for cruise... In any case, when flying in mountainous regions, I usually find that my "trimmed climb rate" simply doesn't cut it (regardless of how much collective I apply). So the quickest and easiest way of getting my full climb ability back is by simply resetting the trimmer, which instantly increases my climb rate (at the cost of speed, ofc). In other words, resetting the trimmer instantly restores climb influence to the collective. - When I need to drop quickly I've found that the quickest and easiest way for the chopper to drop (when it's trimmed for cruise) is by resetting the trimmer and (almost) killing the collective. It drops like a brick, which is exactly what I need when an emergency landing is required (they are usually required in MP). Also, as I mentioned earlier, having the trim reset restores lift influence to the collective, so it delivers all the lift it's supposed to... no funny trim business :D This also helps me avoid vortex ring state and gives me much better control of the descent.

Right...since having the A-10A use a slightly different kind of maverick (which only needs to be programmed to lock on a specific JTAC lasing frequency) is as outlandish as having it behave like a Harrier... In any case, this is the mod section, if you don't approve of people messing with things, I don't even know what you're doing here, tbh.

So far I've managed to equip laser mavs on the A-10A. I went to Gamedir\Scripts\Database\planes, and edited A-10A.lua I added the following code in lines 154 and 314 (ie the tables for the maverick-compatible pylons): { CLSID = "{F16A4DE0-116C-4A71-97F0-2CF85B0313EC}" }, [color="blue"]-- LAU-117 AGM-65E[/color] The problem, of course, is that DCS freaks out and crashes when I select the AGM-65Es while in AG mode. My goal is to simply have them available for buddy lasing (Drone/JTAC units will take care of it), so I don't need an interface, just a way for the mavs to follow the lasing spots. Any ideas? Maybe I could use the interface of another A-10A weapon? (In case an interface is required)

Of course I don't realize it, easy for you to make the connection, since you created the nickname and are a member of Havoc Company. I stopped trying to make sense of people's nicknames on the internet long ago, HC might stand for "Hot Carrot", for all I know... :D Anyway, looks like you have this one covered ;)

MOOSE ultimately uses DCS scripting engine functions. Check the MOOSE scripts used by missions like the one from the video, chances are you'll be able to write the same kind of thing using standard DCS code.

@HC_Official You might want to try MOOSE, then:

IIRC, setting them to alarm state green does pretty much the same thing, but nvm.

It should be enough to set SAM groups to green alarm state when anti-radiation missiles are detected in zone

I assumed the hornets were equipped with their own laser pointer (ok, they need the AN/AAS-38 "Nitehawk" pod for that). But, hey, you can always add a predator drone to the mission and have it lase the boats on command.

@Colmillo @Habu_69 You're welcome, guys. Hey, Colmillo... can you send me your rig as thanks? (kind of jealous over here ;) ) Btw, I'm no master (by any stretch), just a newbie who learns stuff and shares it it with others :thumbup:

Turns out the OSAs are properly implemented after all, nice :thumbup: Yup, task weapon compatibility is the stuff of madness :D

@jozeff I agree that TARGET isn't needed at all. For the Huey (and any other DCS modules), I think that a headtracking system is a must (I don't care which kind). If you combine that with a mouse, there's no need to bind 99% of the controls. However, binding certain essential things comes in pretty handy, here's my list (off the top of my head): - Trimmer & trimmer reset - Starter (it's bound to the Home key by default, I think) - Weapon selector switch - Pilot & copilot aiming sights (sight deployment + reticle activation) - Flare dispense - AI gunner ROE cycle (if you want to get the door gunners firing automatically without having to leave the pilot's seat) - In my case, since I use Simple Radio Standalone, I also have the radio switcher bound to a thrust handle key, so I can quickly switch radios in order to speak to people on different frequencies.

Sure, but if the units aren't reachable anymore, there's no straightforward way to check whether they are on board... that's the problem, isn't it? I know that MOOSE and CTLD have ways of "emulating" the presence of troops / cargo in the chopper (even though the objects aren't actually there). Like I said, if the DEAD event trigger is the problem, GTFreeFlyer can make modifications, so it doesn't trigger stuff that's not meant to be triggered in the embarking process.

@jmarso My personal hunch is that the DCS API doesn't recognize the mod OSAs, because they aren't fully implemented. Creating the 3D models and animations is one thing... making the unit fully functional within the DCS scripting engine is another. I can tell you that speedboats (and probably the rest of DCS naval units) can be set as targets for AI aircraft. Check this other thread to see how: https://forums.eagle.ru/showthread.php?t=243960

AFAIK, that shouldn't work. As funkyfranky said, liveries must be specified before :Spawn() is called. That script spawns b727 BEFORE the liveries are specified Are you 100% sure it's working? It shouldn't :huh: Perhaps funkyfranky will be able to explain what's going on. In any case, I think this would be a valid way of doing it:

I'm surprised that it works at all with 2 sets of parenthesis :D @funkyfranky I was so focused on the table - variable thing that I didn't stop to check the method order :doh: Yup, :Spawn() should always be at the end

If you pay attention to how JanK's script is written, you'll realize that the parenthesis are already there. I think the reason it didn't work is because he wrote a320:Livery() instead of A320:Livery(), in other words, he got his variables mixed up in the copy/paste process (happens to me all the time)