MOOSE - Mission Object Oriented Scripting Framework

Hey FC,

 

I have a question regarding the GROUP class as used on Moose-spawned groups.

 

What am I doing wrong here?

So basically I want to get at my spawned groups by the correct name.

 

Thanks,

 

/Fargo007

Okay, so you use the SpawnScheduled method.

This spawns new groups according the schedule, but you need the "event" when a group is created, and use that group to do actions, correct?

Fortunately, that exists :-)

Have a look here:

http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html##(SPAWN).OnSpawnGroup

This is the code that is useful:

-- Declare SpawnObject and call a function when a new Group is spawned.
local SpawnObject = SPAWN
  :New( "SpawnObject" )
  :InitLimit( 2, 10 )
  :OnSpawnGroup(
    function( SpawnGroup )
       SpawnGroup:E( "I am spawned" ) 
    end      )
  :SpawnScheduled( 300, 0.3 )

So the function that receives the parameter SpawnGroup is called when a new group is spawned.

If you use IntelliSense and LDT, you can add the following in front of the function:

--- @param Wrapper.Group#GROUP SpawnGroup

This will make the SpawnGroup variable known to the LDT IntelliSense type list. You can then inspect SpawnGroup and its methods.

Hope this helps

FC

I just need the name of the group that gets spawned.

I can see them spawning with the GroupName#001, GroupName#002 etc. but for some reason they aren't addressable with those names.

The name is indeed being assigned according to the conventions in the docs, but the names are not usable.

It makes sense that if the group is named a certain way that it's done so such that the name is otherwise useful to access the object.

e.g.

Group target1#001 gets created by the spawn class.

local target1 = GROUP:FindByName("target1#001") -- fails to assign and returns false

I just need the name of the group that gets spawned.

 

I can see them spawning with the GroupName#001, GroupName#002 etc. but for some reason they aren't addressable with those names.

 

The name is indeed being assigned according to the conventions in the docs, but the names are not usable.

 

It makes sense that if the group is named a certain way that it's done so such that the name is otherwise useful to access the object.

 

 

e.g.

 

Group target1#001 gets created by the spawn class.

 

local target1 = GROUP:FindByName("target1#001") -- fails to assign and returns false

Spawned groups are addressable, I use it all the time, but I think you haven't understood.

The spawning of these groups is delayed because U use SpawnScheduled.

So in your code, as i see, you declare your SPAWN object and do a scheduled spawning. So these groups will be spawned later.

You need to catch the time when the group is spawned, and then act upon it. Otherwise these groups simply don't exist!

On top, when you use SpawnScheduled, you'll see a group immediately appearing, but that is only perception!!!

When you process your logic as you have shown me a few threads earlier, it won't work. A scheduled spawn will have a delay in spawning, even a fraction of a second.

Maybe you need to use the SPAWN:Spawn() method!

The :Spawn() method immediately spawns a group and will return the GROUP object instance!

 Spawn_Vehicle_1 = SPAWN:New( "target1" )
:InitLimit( 3, 3 )
:InitRandomizeRoute( 1, 4, 5000 )
-- The 3 vehicle groups spawn successfully and begin their randomized route
-- They are named according to the map as target1#001-#003
MESSAGE:New("DEBUG: MOOSE LOADED",10,"MOOSE Event"):ToAll()
local HeliGroup = GROUP:FindByName( "FAC01")
local GroupInside = GROUP:FindByName( "helo1")

--local target1 = GROUP:FindByName("target1#001") --this doesn't work, but if I used  GROUP:FindByName("target1") it does. 
[color=Red]target1 = Spawn_Vehicle_1:Spawn()[/color]
if (target1) then
 MESSAGE:New("DEBUG:  TARGET1 initialized",10,"MOOSE Event"):ToAll()
end

But I really think you should have a careful look at the :OnSpawnGroup() method!

Dear FlighControl,

a couple of weeks ago I started getting into Moose and learning how things are working. And I have to say it's great! I love it!

However I experienced a bug and I am not sure whether its a bug due to ED or Moose. This is it:

At missions start ships getting spawned at randomly chooses zones. The ships also consist of carriers. In Mission Editor I assigned planes and helicopters to the carrier for the player to choose. If a player joins one of these slots the helicopter just falls into the water. There is simply no ship under it. If for examply player joins a jet on the carrier the jet is floating over the water with an invisible carrier under it.

The planes and helicopters just staying where the template ships are placed in the Mission Editor and not "moving" to where the ships get actually spawned.

Of course this happens not if the ships are just normally placed in Mission Editor.

My question: What can I do to have ships spawning at random zones and also to be able to start from them?

Your help is much appreciated!

Example of code to spawn the ships:

RED_ZoneSea1 = { ZONE:New( "RED_Sea_Zone1" ), ZONE:New( "RED_Sea_Zone2" ), ZONE:New("RED_Sea_Zone3") }

RED_UnitsSea1 = { "RED_Sea_Fleet1" }

RED_SpawnVehicle1_Sea = SPAWN:New( "RED_Spawn Ship 1" )

:InitLimit( 1, 0 )

:InitRandomizeTemplate( RED_UnitsSea1 )

:InitRandomizeRoute( 1, 1, 200 )

:InitRandomizeZones( RED_ZoneSea1 )

:SpawnScheduled(20, .5 )

Explanations to the attachments:

First pic shows that the ships are placed in the upper left corner of the map. Late activated. Just so they dont pollute the rest of the map.

Second pic shows that the red fleet has been spawned somewhere in the right of the pic. Perfectly fine. However you do also see the spawned Su33 in the upper left corner where the template ships are placed in Mission Editor.

Third and fourth pic are after I joined one of the Su33 slots. Jet is howering in the air.

I've added some other important fixes:

This fixes aiplanes remaining on an airfield in case of AI_A2A_GCICAP or AI_A2A_DISPATCHER and the BAI to CAS task conversion when a player is nearby a BAI area while being assigned to the A2G task.

• Added DETECTION_BASE:FilterFriendliesCategory() method, which allows to filter friendlies based on the category of the units found. This method was required to be added to avoid counting airborne units as friendlies in A2G missions. It would result in tasks being converted from BAI to CAS when a player was nearby the target seated in an airplane, which is wrong. Now tasks won't be converted if a player seated in an airplane is near a BAI task area!
  
• AI_A2A_DISPATCHER: Planes remaining on the airfield is now fixed. The issue was with planes out of fuel doing CAP, which would return to a different airbase because they were out of control. At the landing, these weren't despawned.
  

You can download the latest release from: https://github.com/FlightControl-Master/MOOSE/releases

FC

If you think about it, what you are needing is something that has been asked for for many years, "Dynamically assigned Multiplayer slots" and isn't possible in the current engine.

You might ask...."I did not ask for this!"

Check your question, you need a carrier, you want to have it with multiplayer slots, but you don't want it already there, you want it spawned after mission start, even if that is a microsecond later, it's not in the original miz file.

Same issue with FARPS, can't move them or correctly dynamically spawn them (with their correct behaviour - model will spawn) and warehouses - they can have thie rmodel but cannot have their RM, their contents or otherwise.

I don;t know everything about these things, but I know you just can;t get it exactly how you want and it's an engine limit right now.

We asked for dynamic slots, moveable and spawnable farps, editable Warehouses etc for many years. There has been no development here or major changes to the engine. Disappointing, but we are a small breed of the MP community that want to do something amazing and cannot.

Dear FlighControl,

 

a couple of weeks ago I started getting into Moose and learning how things are working. And I have to say it's great! I love it!

 

However I experienced a bug and I am not sure whether its a bug due to ED or Moose. This is it:

 

 

At missions start ships getting spawned at randomly chooses zones. The ships also consist of carriers. In Mission Editor I assigned planes and helicopters to the carrier for the player to choose. If a player joins one of these slots the helicopter just falls into the water. There is simply no ship under it. If for examply player joins a jet on the carrier the jet is floating over the water with an invisible carrier under it.

 

The planes and helicopters just staying where the template ships are placed in the Mission Editor and not "moving" to where the ships get actually spawned.

 

Of course this happens not if the ships are just normally placed in Mission Editor.

 

My question: What can I do to have ships spawning at random zones and also to be able to start from them?

 

Your help is much appreciated!

 

Example of code to spawn the ships:

 

RED_ZoneSea1 = { ZONE:New( "RED_Sea_Zone1" ), ZONE:New( "RED_Sea_Zone2" ), ZONE:New("RED_Sea_Zone3") }

 

RED_UnitsSea1 = { "RED_Sea_Fleet1" }

 

RED_SpawnVehicle1_Sea = SPAWN:New( "RED_Spawn Ship 1" )

:InitLimit( 1, 0 )

:InitRandomizeTemplate( RED_UnitsSea1 )

:InitRandomizeRoute( 1, 1, 200 )

:InitRandomizeZones( RED_ZoneSea1 )

:SpawnScheduled(20, .5 )

 

Explanations to the attachments:

First pic shows that the ships are placed in the upper left corner of the map. Late activated. Just so they dont pollute the rest of the map.

 

Second pic shows that the red fleet has been spawned somewhere in the right of the pic. Perfectly fine. However you do also see the spawned Su33 in the upper left corner where the tamplate ships are placed in Mission Editor.

 

Third and fourth pic are after I joined on of the Su33 slots. Jet is howering in the air.

Thank you for your fast reply. I'm sorry. I wasn't aware that this has been asked by the community for so long. Just thought that this is something obvious to have/to work.

Is there a workaround?

What about spawning an AI plane. With AI deactivated so it doesn't start and then make it as a choosable player slot? Just thinking.

If you think about it, what you are needing is something that has been asked for for many years, "Dynamically assigned Multiplayer slots" and isn't possible in the current engine.

 

You might ask...."I did not ask for this!"

 

Check your question, you need a carrier, you want to have it with multiplayer slots, but you don't want it already there, you want it spawned after mission start, even if that is a microsecond later, it's not in the original miz file.

 

Same issue with FARPS, can't move them or correctly dynamically spawn them (with their correct behaviour - model will spawn) and warehouses - they can have thie rmodel but cannot have their RM, their contents or otherwise.

 

I don;t know everything about these things, but I know you just can;t get it exactly how you want and it's an engine limit right now.

 

We asked for dynamic slots, moveable and spawnable farps, editable Warehouses etc for many years. There has been no development here or major changes to the engine. Disappointing, but we are a small breed of the MP community that want to do something amazing and cannot.

Another idea:

What about lets say 3 carriers in Mission Editor. All late activated and with playable (client set) planes and helicopters on it. The script then just defines which carrier (plane, heli) to activate. This might work, wont it?

Thank you for your fast reply. I'm sorry. I wasn't aware that this has been asked by the community for so long. Just thought that this is something obvious to have/to work.

 

Is there a workaround?

 

What about spawning an AI plane. With AI deactivated so it doesn't start and then make it as a choosable player slot? Just thinking.

Another idea:

 

What about lets say 3 carriers in Mission Editor. All late activated and with playable (client set) planes and helicopters on it. The script then just defines which carrier (plane, heli) to activate. This might work, wont it?

Am trying something out ... hold ...

Am trying something out ... hold ...

Okay, i tried to spawn a group at an airfield and set the skill of the first unit in the group to Client.

The group does spawn, the unit does not appear.

But unfortunately, the slot list does not get updated.

So, you can't select the client from the slot list.

I am sure it is spawned, i am quite sure it is, but you can't select it as there is nothing there...

So forget it. We can't get too creative on this one.

Until ED starts to realize that dynamic slot creation would be a great thing...

So the workaround that is somewhat close that Ciribob, Xcom and the community mangled together is somewhat the inverse of what you ask for, in that the units and slots must be there immediately, but you can deactivate them afterwards.

But the physical object cannot be tampered with as far as I know to date or some interesting things happen like in your screens.

Deactivating slots is a "GameGui.lua" file, or server side only script. Search Ciribob SSB "Simple slot block". It's basically the technique in blue flag - ie all the airports have both client slots available, they just stop you joining the wrong ones.

With Carriers, not sure there is a solution, But feel free to teach me more :)

Spawned groups are addressable, I use it all the time, but I think you haven't understood.

 

The spawning of these groups is delayed because U use SpawnScheduled.

So in your code, as i see, you declare your SPAWN object and do a scheduled spawning. So these groups will be spawned later.

 

You need to catch the time when the group is spawned, and then act upon it. Otherwise these groups simply don't exist!

 

On top, when you use SpawnScheduled, you'll see a group immediately appearing, but that is only perception!!!

 

When you process your logic as you have shown me a few threads earlier, it won't work. A scheduled spawn will have a delay in spawning, even a fraction of a second.

 

Maybe you need to use the SPAWN:Spawn() method!

The :Spawn() method immediately spawns a group and will return the GROUP object instance!

 

 

 Spawn_Vehicle_1 = SPAWN:New( "target1" )
:InitLimit( 3, 3 )
:InitRandomizeRoute( 1, 4, 5000 )
-- The 3 vehicle groups spawn successfully and begin their randomized route
-- They are named according to the map as target1#001-#003
MESSAGE:New("DEBUG: MOOSE LOADED",10,"MOOSE Event"):ToAll()
local HeliGroup = GROUP:FindByName( "FAC01")
local GroupInside = GROUP:FindByName( "helo1")

--local target1 = GROUP:FindByName("target1#001") --this doesn't work, but if I used  GROUP:FindByName("target1") it does. 
[color=Red]target1 = Spawn_Vehicle_1:Spawn()[/color]
if (target1) then
 MESSAGE:New("DEBUG:  TARGET1 initialized",10,"MOOSE Event"):ToAll()
end

But I really think you should have a careful look at the :OnSpawnGroup() method!

Thanks FC, this is exactly the explanation I needed. The delay with scheduled spawn makes perfect sense.

I did find a different way to do it, by using multiple groups and getting the first (and only) unit in each group.

Much appreciated!

Looking forward to publishing my first mission.

Going to try the Escort fixes today.

Hi FlightControl , is it possible to merge A2A and A2G dispatcher? In attached lua file I tried to merger the two dispatcher with different prefix (CAS and CAP) , but only CAP works...

Thank.

mission_A2A.lua

Hi,

So, did a very simple mission with a very simple script with Moose framework. :thumbup:

All went well, except the debriefing page. For some reason seems reporting the spawn units as allied. Probably something iam doing wrong.

MavsTest.miz

I can confirm that the reporting logic in the ESCORT class has now been fixed and works great.

Thanks FC!

/Fargo007

Guys,

Implemented another important fix in the AI_A2A_GCICAP or AI_A2A_DISPATCHER module.

CAP are now also engaging intruders, even when there isn't any EWR coverage. CAP are now part of the EWR network. So the dispatcher will order CAP to engage when the CAP detects intruders and reports them.

Some of you have been awaiting this fix. So please check and tell me if this suits your needs. Note that the CAP is not just engaging any enemy when they detect targets. They are respecting borders and the engagement is coordinated.

• Fixed CAP not engaging problem. CAP become part of the EWR network. They are patrolling and reporting to the EWR their findings. Once they detect targets, the dispatcher will order certain patrols to engage.
  
• Fixed bug with a nil value when searching for friendlies in the vicinity.
  

You can download the latest release from: https://github.com/FlightControl-Master/MOOSE/releases

FC

Will check out the fixes tonight. Thx!!

Sent from my iPhone using Tapatalk

Thanks Sven! Testing now.

You need to look into the DESIGNATE functionality of the moose framework.

DESIGNATE performs a JTAC functionality, but does it in a proprietary system

Hey this certainly looks promising, but does it only work through detection? Since I'm randomly spawning the JTAC sometimes it ends up without LOS or out of range of the target group. When that happens I don't get a detection and thus no targets. One advantage of the in-game FAC taking is that I can put the JTAC anywhere and tell it who to provide targeting info for. Is there a way to force a detection or script in a way that units will "detect" even enemies they can't see?

Hey this certainly looks promising, but does it only work through detection? Since I'm randomly spawning the JTAC sometimes it ends up without LOS or out of range of the target group. When that happens I don't get a detection and thus no targets. One advantage of the in-game FAC taking is that I can put the JTAC anywhere and tell it who to provide targeting info for. Is there a way to force a detection or script in a way that units will "detect" even enemies they can't see?

I dont think you can but with DESIGNATE you can filter the FAC with group prefixes for example "recce". All the groups starting with "recce" will be candidates for FAC task.

If the Weather is good enough I put a helicopter or UAV with a prefix and sometimes I put them invisible If I want them 100% active.

This way you can complement your ground troops with air spoters.

Another thing you can do is spawn ground groups in determined zones where they have LOS to the targets.

Some more fixes for AI_A2A_GCICAP and AI_A2A_DISPATCHER

• Closest CAP is selected to engage closest intruder.
  
• Ensure that CAP is also engaging when there isn't any EWR network initially setup.
  
• Renamed method DETECTION_BASE:SetDetectionInterval() to DETECTION_BASE:SetRefreshTimeInterval(). This allows to modify the detection interval to a specified amount of seconds.
  
• Renamed method DETECTION_MANAGER:SetReportInterval() to DETECTION_MANAGER:SetRefreshTimeInterval(). This allows to modify the detection interval to a specified amount of seconds.
  

Thanks Invisibull helping with testing!

Ensure you download and include the latest moose.lua from the MOOSE release page:

https://github.com/FlightControl-Master/MOOSE/releases

FC

Hey this certainly looks promising, but does it only work through detection?

Yes

Since I'm randomly spawning the JTAC sometimes it ends up without LOS or out of range of the target group. When that happens I don't get a detection and thus no targets.

This is one reason I like MOOSE, it adds some dynamism and a (slim) chance of not being able to complete a attack due to weather or a JTAC loosing sight. Also, I can spawn several AA but the report won't include all of them, so there's a chance of getting "surprised" or having to find them visually. DCS becomes a less perfect world, so more realistic.

One advantage of the in-game FAC taking is that I can put the JTAC anywhere and tell it who to provide targeting info for. Is there a way to force a detection or script in a way that units will "detect" even enemies they can't see?

Units can't detect what they can't see, but you can flood an area with invisible/invulnerable JTAC's. You won't get multiple "detection" of the same target.

Initially I think used 6 ground JTAC's to cover 5 targets in and around Maykop AB due to line of sight issues - later I replaced them with a couple of MQ/RQ-1 Predators.

It's not hard to do as you just choose you own prefix i.e. "FAC" and clone "FAC #001", "FAC #002", etc. as often as you want. You can hide the units on the F10 map so it doesn't spoil it for users.

Quick question does MOOSE have anything that will work for troops mounting and dismounting from APCs and the like?

Quick question does MOOSE have anything that will work for troops mounting and dismounting from APCs and the like?

yes it does

check out the demo missions for examples

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release

https://github.com/FlightControl-Master/MOOSE_MISSIONS/tree/master-release/CGO%20-%20Cargo

^ might have what you seek

Hey this certainly looks promising, but does it only work through detection? Since I'm randomly spawning the JTAC sometimes it ends up without LOS or out of range of the target group. When that happens I don't get a detection and thus no targets. One advantage of the in-game FAC taking is that I can put the JTAC anywhere and tell it who to provide targeting info for. Is there a way to force a detection or script in a way that units will "detect" even enemies they can't see?

Having the same issue, additionally Predators have gone fairly blind when right over an enemy. DETECTION_BASE:AddDetectedItem(ItemPrefix, DetectedItemIndex, Set) looks like it should force the detection but I haven't used it, especially with dynamically spawned items. I'd probably have to use the OnSpawn function to insert them and I still don't know if it will "undetect" them after a while either.