MOOSE - Mission Object Oriented Scripting Framework

[hancerPL]

Hello

I have a request, I need a menu for the mission.

For the client he could spawn unit and menu disappears.

I have no idea because I have not made a menu in 'lua' yet.

 

Thanks for the help:pilotfly:

[Hardcard]

@hancerPL

 

https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Core.Menu.html

 

https://forums.eagle.ru/showpost.php?p=3969423&postcount=20

Edited July 14, 2019 by Hardcard

[hancerPL]

Thanks, but I forgot the menu right now.

 

CaptureZone = ZONE:New( "CaptureZone1" )

ZoneCaptureCoalition = ZONE_CAPTURE_COALITION:New( CaptureZone, coalition.side.RED )

function ZoneCaptureCoalition:OnEnterEmpty()

MessageToBlue( "Good Job", 20 )

end

ZoneCaptureCoalition:Start( 10, 30 )

 

Here is the problem because a marker on the map is visible to everyone.

 

How to remove it from the map so that the script will continue to work.:cry:

[Hardcard]

I don't know about that marker, but I think your snippet has bad syntax in it (which might explain why it doesn't work):

 

CaptureZone = ZONE:New( "CaptureZone1" )
ZoneCaptureCoalition = ZONE_CAPTURE_COALITION:New( CaptureZone, coalition.side.RED ) 
function ZoneCaptureCoalition:[color="Red"]OnEnterEmpty[/color]() [color="Blue"]-- The correct syntax seems to be :onenterEmpty()[/color]
MessageToBlue( "Good Job", 20 )
end
ZoneCaptureCoalition:Start( 10, 30 )

[hancerPL]

@Hardcard

Thanks, the script works but it still displays this tag.

 

I have one thing for you.

I made a spawn menu based on yours, it works ok

How to make a spawn of one group, eg "Spawn 1", this menu disappears. Because the spawn is disposable and does not need the menu is displayed.

 

Client1 = GROUP:FindByName( "Enfield")

Nblu_1 = GROUP:FindByName("Nblu #001")

Nblu_2 = GROUP:FindByName("Nblu #002")

 

local function Spawn1()

Nblu_1:Activate()

trigger.action.outText('Spawn 1', 1)

end

local function Spawn2()

Nblu_2:Activate()

trigger.action.outText('Spawn 2', 1)

end

 

MenuSpawn = MENU_GROUP:New(Client1, "Spawn Menu ")

Spawn_1 = MENU_GROUP_COMMAND:New(Client1, "Spawn 1", MenuSpawn, Spawn1)

Spawn_2 = MENU_GROUP_COMMAND:New(Client1, "Spawn 2", MenuSpawn, Spawn2)

 

Thanks for helping me, there are no volunteers like you. I would set you a big beer.

Edited July 17, 2019 by hancerPL

[Hardcard]

https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Core.Menu.html##(MENU_GROUP_COMMAND).Remove

[hancerPL]

Thank you, but a reference to incomprehensible instructions is a vicious circle.

It suffices to write:

local function Spawn1()

Nblu_1:Activate()

Spawn_1:Remove( 1, nil )

trigger.action.outText('Spawn 1', 1)

end

 

That is: Spawn_1: Remove (1, nil)

[Pikey]

https://github.com/FlightControl-Master/MOOSE_MISSIONS/blob/master/MEN%20-%20Menu%20Options/Normandy/MEN-102%20-%20Menu%20Coalition%20Multi%20Player/MEN-102%20-%20Menu%20Coalition%20Multi%20Player.lua

 

Some examples in and around here.

[hancerPL]

That's how I read it, and more. Not everyone knows everything at once.

PlaneGroup = GROUP:FindByName( "Enfield")

Nblu_1 = GROUP:FindByName("Nblu #001")

Nblu_2 = GROUP:FindByName("Nblu #002")

local function Spawn1()

Nblu_1:Activate()

Spawn_1:Remove( 1, nil )

trigger.action.outText('Spawn 1', 1)-- info test

end

local function Spawn2()

Nblu_2:Activate()

Spawn_2:Remove( 1, nil )

trigger.action.outText('Spawn 2', 1)-- info test

end

SCHEDULER:New( nil,

function()

if PlaneGroup:IsAlive() then

Spawn_1 = MENU_GROUP_COMMAND:New( PlaneGroup, "Spawn 1", MenuManage, Spawn1 )

Spawn_2 = MENU_GROUP_COMMAND:New( PlaneGroup, "Spawn 2", MenuManage, Spawn2 )

end

end, {}, 0 )

 

The final working version, maybe it can be simpler, I put in a way if someone had a problem with it.

:thumbup::thumbup::thumbup:

[Hardcard]

Thank you, but a reference to incomprehensible instructions is a vicious circle.

 

Well, those "incomprehensible instructions" taught me how to do it... maybe the problem is that you didn't take the time to carefully examine the content of the several links I provided.

 

I mean, this post alone provided the necessary information + an example of how to add and remove menus:

https://forums.eagle.ru/showpost.php?p=3969423&postcount=20

 

On top of it, I linked the MOOSE documentation for MENU class (which contains all the methods + examples)...twice

 

Sorry, I assumed you already had all the info you required, my bad :doh:

Edited July 18, 2019 by Hardcard

[ReflexArc]

I'm perplexed. I'm trying to add simple SEAD evasion behavior to a SAM site in a test mission.

 

As far as I can tell, the functionality is not working in the Caucasus map.

 

When I do the same thing (same script, same SAM site) in NTTR, I get a string error but the SEAD evasion functionality works perfectly.

 

About to test in PG. Will supply NTTR error message shortly.

 

But hoping maybe this is already a known problem or someone might have a clue what's going on? I'm not familiar enough with the DCS source code to know why different maps would cause totally different MOOSE SEAD behavior.

 

Edit 1:

 

To add to the strangeness, I tested on PG, no string error, just didn't work.

 

Went back to NTTR to try to reproduce SEAD evasion working but getting a weird string error. Now NTTR is just not working like the rest of the maps.

 

Edit 2:

 

Suspecting extra weirdness, I quit out of DCS. Reopened the same NTTR mission without making any changes. Started the mission, got the same two string errors. SEAD evasion functionality working perfectly.

 

Error 1:

[string
"C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5:
attempt to index global 'EVENT' (a nil value)
stack traceback:
   [C]: ?
   [string
"C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5:
in main chunk

 

Error 2: Same as 1 but "SEAD" and different mis number (000022D0):1

 

The code I'm using is literally the example code.

 

-- CCCP SEAD Defenses
SEAD_RU_SAM_Defenses = SEAD
 :New(
   { 'SAM Test'
   }
 )

 

Edit 3: Actually, NTTR isn't working now, just throwing error codes.

 

Very frustrating.

Edited July 18, 2019 by ReflexArc

[Delta99]

Those errors MIGHT mean you are not loading Moose properly.

 

Near the start of the dcs.log file when the mission starts you should see Moose messages indicating it is loaded etc. If you don't see those, Moose isn't being loaded.

 

I'm perplexed. I'm trying to add simple SEAD evasion behavior to a SAM site in a test mission.

 

As far as I can tell, the functionality is not working in the Caucasus map.

 

When I do the same thing (same script, same SAM site) in NTTR, I get a string error but the SEAD evasion functionality works perfectly.

 

About to test in PG. Will supply NTTR error message shortly.

 

But hoping maybe this is already a known problem or someone might have a clue what's going on? I'm not familiar enough with the DCS source code to know why different maps would cause totally different MOOSE SEAD behavior.

 

Edit 1:

 

To add to the strangeness, I tested on PG, no string error, just didn't work.

 

Went back to NTTR to try to reproduce SEAD evasion working but getting a weird string error. Now NTTR is just not working like the rest of the maps.

 

Edit 2:

 

Suspecting extra weirdness, I quit out of DCS. Reopened the same NTTR mission without making any changes. Started the mission, got the same two string errors. SEAD evasion functionality working perfectly.

 

Error 1:

[string
"C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5:
attempt to index global 'EVENT' (a nil value)
stack traceback:
   [C]: ?
   [string
"C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5:
in main chunk

 

Error 2: Same as 1 but "Include" and different mis number (000022D0):1

 

The code I'm using is literally the example code.

 

-- CCCP SEAD Defenses
SEAD_RU_SAM_Defenses = SEAD
 :New(
   { 'SAM Test'
   }
 )

[ReflexArc]

Those errors MIGHT mean you are not loading Moose properly.

 

Near the start of the dcs.log file when the mission starts you should see Moose messages indicating it is loaded etc. If you don't see those, Moose isn't being loaded.

 

Yes that's exactly it, thank you. For anyone else who runs into my issue, the problem was that I tried to use the MOOSE.lua from the source code download and not the MOOSE.lua that contains the entire source.

 

As for whether the SEAD function works, I'm testing but it's looking like possibly no?

 

Is there a way of calling the emissions off action from lua? Might be more reliable than alarm state which doesn't seem to be working.

Edited July 18, 2019 by ReflexArc

[Hardcard]

@ReflexArc

 

MOOSE SEAD evasion doesn't work (it's already reported, btw).

 

Setting SAM radar to alarm state green when SEAD missiles target them should do the trick (this is what I did when I wrote my own SEAD evasion script)

Edited July 19, 2019 by Hardcard

[ReflexArc]

Thanks @Hardcard, I'm looking through your old posts on the topic. I see you might have tried changing the weapon names to the correct values--did that work for you?

 

EDIT: Well, I think I figured out the issue in the SEAD function. I enabled a bunch of tracing and it turns out this was the error:

 

2019-07-19 23:21:06.560 INFO SCRIPTING: stack traceback:

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6062: in function 'round'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:726: in function 'groupToRandomPoint'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:780: in function 'groupToRandomZone'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:752: in function 'groupRandomDistSelf'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:40642: in function 'EventFunction'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6377: in function <[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6376>

[C]: in function 'xpcall'

[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6375: in function 'onEvent'

[string "Scripts/World/EventHandlers.lua"]:13: in function <[string "Scripts/World/EventHandlers.lua"]:11>

 

So I commented out this line

 

--routines.groupRandomDistSelf(_targetMimgroup,300,'Diamond',250,20) -- move randomly

 

And now the SAMs correctly change alarm state.

 

I haven't quite been able to figure out how things are getting improperly passed to the round util function but I'm sure someone with more familiarity with the code base than myself could figure that out pretty quickly...

Edited July 19, 2019 by ReflexArc

[Hardcard]

@ReflexArc

 

Did you modify the SEADWeaponName values, like I suggested in the other posts?

That didn't solve the issue for me, but looks like a necessary modification nonetheless.

 

Also, that last error that you posted, was it also?:

attempt to index global 'EVENT' (a nil value) 

[ReflexArc]

I got the 'EVENT' error in that first post because I was loading in the wrong moose.lua (the small one that builds from source and not the standalone one that you include with missions).

 

Yes, I added the weapon names from your script.

 

It turns out routines.utils.round is not defined anywhere in the MOOSE code. It is called in a number of places, including as part of the function to get SAMs to change places within the SEAD class. I replaced routines.utils.round with math.floor and now the whole SEAD function is working just fine.

 

Later, instead of using math.floor, I added the snippet below to the moose.lua and everything works.

 

routines.utils.round = function(number, decimals)
   local power = 10^decimals
   return math.floor(number * power) / power
end

 

In case anyone wants the weapon names provided by Hardcard:

 

SEADWeaponName == "weapons.missiles.X_58" --Kh-58U anti-radiation missiles fired
   or 
   SEADWeaponName == "weapons.missiles.Kh25MP_PRGS1VP" --Kh-25MP anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.X_25MP" --Kh-25MPU anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.X_28" --Kh-28 anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.X_31P" --Kh-31P anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.AGM_45A" --AGM-45A anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.AGM_45" --AGM-45B anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.AGM_88" --AGM-88C anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.AGM_122" --AGM-122 Sidearm anti-radiation missiles fired
   or
   SEADWeaponName == "weapons.missiles.ALARM" --ALARM anti-radiation missiles fired then -- Check if the missile is a SEAD

Edited July 20, 2019 by ReflexArc

[Hardcard]

@ReflexArc

 

If you haven't already, join the MOOSE Discord channel

 

Share this info with the MOOSE community there.

 

Also, please, report the issue (including your findings) here.

 

Thanks for the nice detective work! :thumbup:

[Delta99]

Yeah, nice work @ReflexArc

 

I saw your issue entered and hopefully someone will incorporate into Moose soon.

[A101Wayz]

I'm afraid I'm stuck again...

Trying to capture when a SPAWN group passes an ME waypoint. Or, optionally, a way to capture the next waypoint in it's mission. I need to execute a state change in an FSM object at a particular waypoint.

 

Any way to do this in scripting?

[fargo007]

I'm afraid I'm stuck again...

Trying to capture when a SPAWN group passes an ME waypoint. Or, optionally, a way to capture the next waypoint in it's mission. I need to execute a state change in an FSM object at a particular waypoint.

 

Any way to do this in scripting?

 

Create a GROUP object off of the SPAWN object with GROUP:FindByName("groupname")

 

Create a ZONE at the concerned waypoint.

 

and in a scheduler (or trigger in the ME) monitor for the presence of that group in the zone, then perform whatever action you want.

 

That's how I'd do it.

[A101Wayz]

Create a GROUP object off of the SPAWN object with GROUP:FindByName("groupname")

 

Create a ZONE at the concerned waypoint.

 

and in a scheduler (or trigger in the ME) monitor for the presence of that group in the zone, then perform whatever action you want.

 

That's how I'd do it.

 

That would do the trick, but it would create a bit of a limitation to what my end goal is...

 

I did, however, get something a little different to work. In the ME, I set up an advanced waypoint action Perform Command|Run Script, and set up the transition command in the script box: My_FSM:__Transition(1). This does require that the FSM object be global rather than local. But it does work.

 

Now, if only I can get:

function CONTROLLABLE:TaskWrappedAction( DCSCommand, Index )

and

function CONTROLLABLE:SetTaskWaypoint( Waypoint, Task )

 

 

to work, I'd have the flexibility that I'm looking for, without the need for using the ME to set it up. TaskWrappedAction() seems to build the task correctly. However, SetTaskWaypoint() doesn't seem to actually APPLY the task, as an examination of the waypoints and tasks shows that the task did not get applied.

 

Unless I'm missing a step in that process...

[fargo007]

I think there's a push function that you need to use, no?

[hancerPL]

Hello

How to remove the main menu after deleting all submenus

MenuTop_2 = MENU_COALITION:New( coalition.side.BLUE, "JTAC" )

JTAC_1 = MENU_COALITION_COMMAND:New( coalition.side.BLUE, "Jtac KN53", MenuTop_2, function()

ctld.JTACAutoLase('JTAC1', 1666, true,"all", 3)

JTAC_1:Remove( 1, nil ) end, nil)

JTAC_2 = MENU_COALITION_COMMAND:New( coalition.side.BLUE, "Jtac MM24", MenuTop_2, function()

ctld.JTACAutoLase('JTAC2', 1667, true,"all", 1)

JTAC_2:Remove( 1, nil ) end, nil)

 

It's about the remaining empty menu "MenuTop_2"

[Hardcard]

Place this in a function when you're done with JTAC:

MenuTop_2:Remove()

 

However, keep in mind that you'll need to create the nested menu structure again from scratch, if you plan on using it later

Edited July 23, 2019 by Hardcard