St3v3f

1.2.5 incompatibility? Since the 1.2.5 update, I'm having some problems. slmod.units_hitting doesn't seem to work anymore. slmod.units_ejected does work though Can anyone confirm that?

Thanks

That was one month ago, in the last friday's changelog it doesn't appear anymore

First, make sure the SPI you're sending is correct. It often happens that you want to send the spot your TGP is looking at, but your SPI is waypoint. So waypoint will be sent. Second: A SPI is a point in a 3-dimensional room. For instance if you slew the TGP to a waypoint that is not at ground level, you will look 'through' the waypoint (which is in the air) onto a spot on the ground behind it. On the TAD however, your TGP-diamond will be at the ground coordinates of the waypoint. But if you then go to area-tracking, the TGP will start looking at the spot it points at, and on the TAD, the diamond will appear at this position.

No mention of ATC Update anymore? http://forums.eagle.ru/showthread.php?t=108764

Yes. You don't know Tyger or the 74th :smilewink:

I think there is a DTS option under the NAV page of the CDU. If you go there, press 'orig data' and it'll restore the original data from the mission start. That means markpoints gone, but also all modifications to waypoints or flightplans and all created waypoints will be gone as well.

http://forums.eagle.ru/showthread.php?t=108764

I doubt there is anything ED will do against it. Otherwise all modders would have to live in fear. An active modding community is in ED's best interest.

I'm just glad I could help :) local is a reserved word, yes. It limits the scope of a variable. A local variable is 'visible' only to the block of code it is declared in, and all blocks within that block. If you declare a variable without local, it will be a global variable. You can use it for example in an entirely different script (within the same mission). While that can be a good thing, it also has drawbacks. For example, you could run into conflicts with other functions using a variable with the same name. Haven't tested it, but I would assume that once the target unit is dead, the function will return no in-Zone units, so it should be on false for the rest of the mission

My script does exactly that. It's working like the 'flagFunc' scripts, but turns the flag off again when there are no units in the zone anymore. 'mist.scheduleFunction' schedules a function to run at a later time. The 'unitsInZonesOnOff' function schedules itself to run again in one second after it finished (timer + 1), passing on the 'result' variable as an argument. That is the reason you can call my script once and it continues to run until the mission ends. The 'result' variable is an argument given to my unitsInZonesOnOff function. It is the result from the last time the function ran (Units in zone, yes or no). You could build the function without it, by unconditionally setting the flag true or false every time, but then you couldn't use 'time since flag' conditions in the ME because the flag is set every second. The last line 'unitsInZonesOnOff(false)' is what really kicks off the script itself, it calls the function for the first time (after that it re-calls itself with scheduleFunction) and passes on false as an argument, because no units in the zone is the initial state in the mission. Before this last line, the function has only been defined, it didn't run yet. What the script basically does is: - Get a list of units in the zone - Check if the status changed: - If there are no units in the the zone NOW (#ret == 0) but there have been units in the zone BEFORE (result == true), then deactivate the flag and change result to false (so the script knows there have been no units in the zone next time it runs) - If there are units in the the zone NOW (#ret > 0) but there have been no units in the zone BEFORE (result == false), then activate the flag and change result to true (so the script knows there have been units in the zone next time it runs) - Schedule to run again in one second To use the script for other situations, just modify the variables in the first lines. The script is quickly adaptable to work with 'UnitsInMovingZones' as well: local units = mist.makeUnitTable({'[blue][plane]'}) local flag = 50207 local zones = mist.makeUnitTable({'[g]Red SGrp01'}) local radius = 300 local zone_type = 'sphere' local function unitsInMovingZonesOnOff(result) local ret = mist.getUnitsInMovingZones ( units, zones, radius, zone_type ) if #ret == 0 and result == true then trigger.action.setUserFlag(flag, 0) result = false elseif #ret > 0 and result == false then trigger.action.setUserFlag(flag, 1) result = true end mist.scheduleFunction (unitsInMovingZonesOnOff, {result}, timer.getTime() + 1) end unitsInMovingZonesOnOff(false)

Ahhh I didn't know about that possibility...

But the aircraft weren't late activated... At least I didn't see the box checked.

It's the aircraft that are somehow 'broken'. Try to replace them with new ones, the missions and all the scripts worked just as they should after that for me. The problem with your switched condition trigger is that the script will continuously set the flags to true. So either your message comes up every second for as long as an aircraft is in the zone, or what i saw happening was that the trigger didn't even notice the flag was off again, because the script reactivated it too fast. Altitude of the sphere-zone: It's a sphere, a bubble... It's not only a circle in the horizontal plane but the vertical as well. Max altitude is the triggerzone's radius at it's center, the further you go away, the lower the altitude. Try this mission. What I've changed: Replaced aircraft with new ones Replaced the scripts with mine from above Removed the Flag Off action from the switched conditions WC's Spherical Zone Test v02.miz

Error in the manual. Even the fantastic Grimes and Speed make them as it seems ;) Edit: Oh wow, I've had no idea that it works without the round brackets. I always assumed that you'd need them. I can't look into the mission itself as I don't have access to DCS at this time, so unless you put the scripts in here, I can't comment ;) You possibly expect the functions to work as on/off triggers, but they don't. They can only set the flag to true, they won't set it off again when the conditions are not met anymore. Would be a nice feature though. As to the altitude: There is no 'altitude' variable. Setting it to sphere will make it a bubble with the trigger zone's radius. You could use the mist.flagFunc.units_in_polygon function, it will build a zone with a fixed ceiling. Create a red, deactivated unit and make it's waypoint's the outline of your triggerzone mist.flagFunc.units_in_polygon({ units = {'[blue][plane]' }, zone = mist.getGroupPoints('groupname'), flag = 50107, maxalt = 1000, }) Update: Ok, it didn't let me go. Checked your mission, something is odd here. The aircraft don't appear on the map or visually as if they were deactivated, yet they trigger the scripts. Doesn't look like script problem but a DCS problem. I've set them to deactivated and built a trigger to activate them after 20 seconds. The first one flies to the trigger zone and activates both trigger - as it should be... Set them to activate at mission start via trigger, all fine again. I've added the zone_type = 'sphere' to the second script with flag 50207 and the first plane flew over the ships, triggered the high message but not the low message. That was properly triggered by the second aircraft - all well Your Switched Condition triggers seem to indicate that you're trying just what I said. The functions don't set the flags off again, so the condition does not get set to false... Update2: Okay try this one: local units = mist.makeUnitTable({'[blue][plane]'}) local flag = 50207 local zones = {'1 Sphere Zone'} local zone_type = 'sphere' local function unitsInZonesOnOff(result) local ret = mist.getUnitsInZones(units, zones, zone_type) if #ret == 0 and result == true then trigger.action.setUserFlag(flag, 0) result = false elseif #ret > 0 and result == false then trigger.action.setUserFlag(flag, 1) result = true end mist.scheduleFunction (unitsInZonesOnOff, {result}, timer.getTime() + 1) end unitsInZonesOnOff(false) Just run it once as you do with the other functions. Important: Delete the flag off action from the switched condition

You are missing some brackets. Function parameters are enclosed by round brackets: mist.flagFunc.units_in_zones[color=red]([/color]{ units = {'[blue][plane]'}, zones = {'1 Sphere Zone'}, flag = 50107, zone_type = 'sphere' }[color=red])[/color] Suggestion: Why not use this: mist.flagFunc.units_in_moving_zones({ units = {'[blue][plane]'}, zone_units = {'[red][ship]'}, flag = 50107, radius = 3000, zone_type = 'sphere' }) Saves you a triggerzone ;)

No it's not... Name, DTOT and some stuff yes. But coordinates not.

No

The shkval's locking ability is heavily dependent on the lighting conditions. During dusk, night and dawn, your locking range is heavily reduced. But yes, AI helicopters are godlike. Us poor humans are too limited having just two eyes, ears and arms. AI can see everything, hear everything and do everything at the same time. Plus, I've had one hunt me down from 8km once. With less than 4km visibility due to fog...

'Bump' Any news here?

Because they are 'dumb' bombs (including the GBU-12 in this case). The GBU-38 requires the aircraft to send it the target location before release. That means that there has to be a data connection between the aircraft and the bomb. The other bombs don't need that, so you can just drop them and they do their thing. As far as I know, the GBU-12 works the same way, there is no specific connection between aircraft and bomb, and just like with the CBUs, in the real aircraft, you can't change anything on the bomb on the fly like laser code or HOF. That has to be done by the ground crew.

The ejected pilot does not exist anywhere except as a visual model. Therefore it is not possible to apply triggers or scripts to it

You don't need to press load. Load stores the set frequency into the set preset. Only works on manual though.

Setting the frequency is not everything, you also need to use the correct radio. For the VHF AM radio, you have to bring up the radio menu with RAlt+Numpad+

There does not exist any pilot unit that you can spawn or use to my knowledge. But feel free to hop on to the 74th vfs PUMA server, we are hosting missions with a similar element: http://forums.eagle.ru/showthread.php?t=109054