MOOSE - Mission Object Oriented Scripting Framework

I hacked my way into it already ;) (ugly static kind of reference to Moose libraries, but it works, and I promise to not open any ticket on it before official ;) )

Up to what point can the Detection function be changed to reflect a more realistic detection profile for IR SAMs? Like in the detection script from MBot:

https://forums.eagle.ru/showthread.php?t=117424&highlight=detection

BTW good to see you back in the saddle FC!

Up to what point can the Detection function be changed to reflect a more realistic detection profile for IR SAMs? Like in the detection script from MBot:

 

https://forums.eagle.ru/showthread.php?t=117424&highlight=detection

 

BTW good to see you back in the saddle FC!

Hi Looney,

There is a DETECTION class that is the worker class for detection.

Can you elaborate a bit further what class you have in mind?

The detection class will detect what the unit is capable off.

That being said, additional filters and randomization logic can be applied.

Was also thinking on maybe put certain zones where detected units cannot be detected at all... Like forests. Should be possible with the use of polygons zones.

And yes ... Back in the saddle, but this time a pony.

Not a speed race horse like before ...

However, making some good progress nowadays.

What I am preparing is complicated, and requires a lot of testing and additional development (like onforeseen events I did not think of, only during tests).

So, my current priority is the implementation of the orchestration of:

Head Quarters (per coalition) <-> Coordinating Multiple Missions <-> Having Multiple Tasks with multiple achievements <-> Multiple Groups <-> Multiple Units (players) that can execute the Task belonging to the same group or different groups ...

Implementation is done using Finite State Machines.

Currently working on the reporting side, coordinated from the HQ to:

- Provide a status report of all active and inactive missions.

- Provide a detailed status report of one mission (showing overview of Tasks).

- Provide a detailed status report of one task (showing overview of achievements, and who got which achievement and when...).

...

The core is finished, but working now on the pheripherals.

Sven

Hi FC,

I'm looking more into the behaviour of the visual detection parameters of the IR SAM units like the Strela, Stinger and Igla.

The script in my previous post defines certain parameters as well as some probabiliy guestimation as to when an aircraft will be detected.

I have no idea if that script will work in 1.5.5 but I'll certainly try. I'm just curious to know if MOOSE has anything similar.

As far as I've seen it, Moose uses DCS detection mecanism through use of getDetectedTargets (http://wiki.hoggit.us/view/DCS_func_getDetectedTargets).

Integrating MBot script would require quite some changes.

Hi FC,

 

I'm looking more into the behaviour of the visual detection parameters of the IR SAM units like the Strela, Stinger and Igla.

 

The script in my previous post defines certain parameters as well as some probabiliy guestimation as to when an aircraft will be detected.

 

I have no idea if that script will work in 1.5.5 but I'll certainly try. I'm just curious to know if MOOSE has anything similar.

You mean, the ir sams detecting other objects of the enemy and reporting it? like whisper suggested?

Moose utilises indeed the dcs detection mechanism. But additional filters could be added to make the detection more "realistic". As i said, like defining some zones where units are less likely to be detected, add a detection "fog" % parameter etc.

It is not the idea that we just copy over functions from existing scripts, because that would not be fair and there it's no immediate benefit. I believe in a good requirement discussion first.

If you want we can put this dev item on our "todo" list on the MOOSE github. Maybe somebody can extend the current detection capability class with more parameters. Should be quite easy to implement.

In order to do that, who is interested needs to craft a summary of the goal or requirements. This can be done on this forum, sharing the discussion.

And once the requirements are clear, this can be taken as a co-development under my help and supervision.

Good idea? So, ... who is interested to spend some time in this item.

Fc

I have a really stupid question. Should 'Late Activation' units be moving?

I have a situation where I am trying to spawn in some 'target' units via radio calls. So here is the expected MOOSE pseudo-code

1. Put a pair of 'spawnable' units in the ME. One is a single element group (1 ship) of target aircraft and the other is a pair element (2-ship) of target aircraft;

2. Put in a set of paths that these spawnables get assigned to randomly;

3. Set all of these groups/units to 'Late Activation' so that they, I think, do not spawn it.

4. Set up a radio menu to allow the pilot/client to request a spawn;

5. Set up a spawn function to spawn one of the spawnables (point 1 above), get a random path (point 2 above) and spawn the spawnable in on that unit (SpawnFromUnit) and assign that route (Route( GROUP:FindByName( UnitName ):GetTaskRoute() );

The issue is that at mission start, if I call the radio commands then the appropriate actions happen (the requested group spawns in on the randomly assigned unit/route). That is all fine. The problem is that if I wait, take off and fly to the target area and then request the spawn, the unit/route position is a hundred miles off to the west??

So, to try and figure out what might be happening I added a debug menu command to send a message to everyone with the North and East positions of all of the paths (point 2 above). And, before spawning anything, I call that menu command twice to view the output. I expect that the positions of the 'Late Activation' units would be 'static' until they are activated via the above SpawnFromUnit and Route calls BUT I am seeing changes in the position! That tells me that the 'Late Activation' units are actually activating but are hidden?

Am I crazy?

I want to ask here before to make sure my MOOSE calls are correct. I want to avoid the obvious first response :-)

So here are the spawnables:

SpawnSingle_Template = SPAWN:New("RED Target 01"):Limit( 10, 10 )
SpawnPair_Template   = SPAWN:New("RED Target 02"):Limit( 10, 10 )

and here is the array of unit/route/path units:

RedRoutes = { "RED Target Route #001", "RED Target Route #002", "RED Target Route #003" }

and here is how they would be spawned:

local idx = math.random( #RedRoutes )
local UnitName = RedRoutes[ idx ]
local SpawnUnit = UNIT:FindByName( UnitName )

SpawnSingle_Template:SpawnFromUnit( SpawnUnit ):Route( GROUP:FindByName( UnitName ):GetTaskRoute() )

and here is what I am doing to get and report on the positions of the 'Late Activation' units:

for unit_idx,unit_val in pairs (RedRoutes) do
  local tmpunit = UNIT:FindByName( _unitname )
  local tmppos = tmpunit:GetVec2()
  <cut putting that into a message for all>
end

Everything from the MOOSE code should be fine but it seems that my assumptions about 'Late Activation' has changed with a recent patch ... oh ... DCS World 2.0.4

I have a really stupid question. Should 'Late Activation' units be moving?

 

I have a situation where I am trying to spawn in some 'target' units via radio calls. So here is the expected MOOSE pseudo-code

 

1. Put a pair of 'spawnable' units in the ME. One is a single element group (1 ship) of target aircraft and the other is a pair element (2-ship) of target aircraft;

2. Put in a set of paths that these spawnables get assigned to randomly;

3. Set all of these groups/units to 'Late Activation' so that they, I think, do not spawn it.

4. Set up a radio menu to allow the pilot/client to request a spawn;

5. Set up a spawn function to spawn one of the spawnables (point 1 above), get a random path (point 2 above) and spawn the spawnable in on that unit (SpawnFromUnit) and assign that route (Route( GROUP:FindByName( UnitName ):GetTaskRoute() );

 

The issue is that at mission start, if I call the radio commands then the appropriate actions happen (the requested group spawns in on the randomly assigned unit/route). That is all fine. The problem is that if I wait, take off and fly to the target area and then request the spawn, the unit/route position is a hundred miles off to the west??

 

So, to try and figure out what might be happening I added a debug menu command to send a message to everyone with the North and East positions of all of the paths (point 2 above). And, before spawning anything, I call that menu command twice to view the output. I expect that the positions of the 'Late Activation' units would be 'static' until they are activated via the above SpawnFromUnit and Route calls BUT I am seeing changes in the position! That tells me that the 'Late Activation' units are actually activating but are hidden?

 

Am I crazy?

Hello dwpenny,

First of all, let me give you some confidence that you are highly likely not crazy. It is glitchy software that can make you crazy, and probably I am the root cause of this fenomenon ...

Let's have a look ...

I want to ask here before to make sure my MOOSE calls are correct. I want to avoid the obvious first response :-)

 

So here are the spawnables:

 

SpawnSingle_Template = SPAWN:New("RED Target 01"):Limit( 10, 10 )
SpawnPair_Template   = SPAWN:New("RED Target 02"):Limit( 10, 10 )

and here is the array of unit/route/path units:

 

This code looks okay.

RedRoutes = { "RED Target Route #001", "RED Target Route #002", "RED Target Route #003" }

and here is how they would be spawned:

 

local idx = math.random( #RedRoutes )
local UnitName = RedRoutes[ idx ]
local SpawnUnit = UNIT:FindByName( UnitName )

Here I have a question...

There these names in RedRoutes defined as Groups or as Units?

You use UNIT using the UnitName defined by the Random Process.

The problem is, that UNITs don't have routes. GROUPs have routes.

Not sure if this is the root cause of your problem.

SpawnSingle_Template:SpawnFromUnit( SpawnUnit ):Route( GROUP:FindByName( UnitName ):GetTaskRoute() )

Ohh, now i see it. So you spawn a new group from the position of a Unit, and then route it using the ... No, wait a second ...

UnitName should be a GROUP Name. You're mixing the two. Have a further look into this. This may solve you a lot of problems.

and here is what I am doing to get and report on the positions of the 'Late Activation' units:

 

for unit_idx,unit_val in pairs (RedRoutes) do
  local tmpunit = UNIT:FindByName( _unitname )
  local tmppos = tmpunit:GetVec2()
  <cut putting that into a message for all>
end

Everything from the MOOSE code should be fine but it seems that my assumptions about 'Late Activation' has changed with a recent patch ... oh ... DCS World 2.0.4

Pls check first the code I indicated, if that is okay, but it did not solve the problem, we can continue our search.

Hope this helps.

UnitName should be a GROUP Name. You're mixing the two. Have a further look into this. This may solve you a lot of problems.

I should have clarified that earlier. I match group and unit names for these. Since the groups that I use for paths are single unit groups, I match the group name and unit name to make it clear (to me) which group I am referencing without having to worry about it having a different unit name. That is possibly not the clearest thing I could have done but it seems to work :-)

So in this case, I am re-using UnitName as both the Unit to spawn in as and the GROUP Name to get the path for.

I did post an edited version of this question (my earlier post) to the DCS World OpenAlpha forums and Grimes did a quick test and did find that the late activation units are moving. His code for spawning the unit, however, did reset the path. I take this to mean that the Late Activation unit is moving (and it shouldn't) but when he assigns the position and path to the cloned unit it seems to reset to the path start. I am waiting for a follow up on that post to to see if there is a difference in how MOOSE handles the clone and path/route assignment and how his code handled it. I could be that the way MOOSE clones and assigns the route was sensitive to the position of the Late Activation unit in a way that his code is not (a choice of how to assume where the 'start' position is).

I will let you know what comes of it.

Here is the brief thread: https://forums.eagle.ru/showthread.php?t=177975

I should have clarified that earlier. I match group and unit names for these. Since the groups that I use for paths are single unit groups, I match the group name and unit name to make it clear (to me) which group I am referencing without having to worry about it having a different unit name. That is possibly not the clearest thing I could have done but it seems to work :-)

 

So in this case, I am re-using UnitName as both the Unit to spawn in as and the GROUP Name to get the path for.

 

I did post an edited version of this question (my earlier post) to the DCS World OpenAlpha forums and Grimes did a quick test and did find that the late activation units are moving. His code for spawning the unit, however, did reset the path. I take this to mean that the Late Activation unit is moving (and it shouldn't) but when he assigns the position and path to the cloned unit it seems to reset to the path start. I am waiting for a follow up on that post to to see if there is a difference in how MOOSE handles the clone and path/route assignment and how his code handled it. I could be that the way MOOSE clones and assigns the route was sensitive to the position of the Late Activation unit in a way that his code is not (a choice of how to assume where the 'start' position is).

 

I will let you know what comes of it.

 

Here is the brief thread: https://forums.eagle.ru/showthread.php?t=177975

This bug happened before... When new units were spawned, they started moving... That bug got solved earlier, but if this is again happening, ED may want to have a close look at this again.

Sven

This code you write, could become a function that is added to the MOOSE framework, what about that???

Sorry about late reply, beein busy

That sound like a good idea. I have modified i a bit now it looks like this:

---@Param instance of GROUP:
function convertBlueToRed(group) --Switch side of a group in the databse template
if group~=nil then
   local oldTemplate =  group:GetTemplate()
   local cCoaltion = group:GetCoalition()
   if cCoaltion == coalition.side.BLUE then
   group:SetTemplateCoalition(oldTemplate, coalition.side.RED)
   group:SetTemplateCountry(oldTemplate, country.id.RUSSIA)
 else
   group:SetTemplateCoalition(oldTemplate, coalition.side.BLUE)
   group:SetTemplateCountry(oldTemplate, country.id.USA)
 end
 env.info ("Group is succesfully converted")
 return group
end

:)

Wingthor

Sorry about late reply, beein busy

 

That sound like a good idea. I have modified i a bit now it looks like this:

 

---@Param instance of GROUP:
function convertBlueToRed(group) --Switch side of a group in the databse template
if group~=nil then
   local oldTemplate =  group:GetTemplate()
   local cCoaltion = group:GetCoalition()
   if cCoaltion == coalition.side.BLUE then
   group:SetTemplateCoalition(oldTemplate, coalition.side.RED)
   group:SetTemplateCountry(oldTemplate, country.id.RUSSIA)
 else
   group:SetTemplateCoalition(oldTemplate, coalition.side.BLUE)
   group:SetTemplateCountry(oldTemplate, country.id.USA)
 end
 env.info ("Group is succesfully converted")
 return group
end

:)

 

Wingthor

cool. the are a couple of things that need to be changed in the code. I'll explain tomorrow about documentation, naming conventions...

Hello all,

A small note regarding the current status of the MOOSE framework. :detective:

MOOSE has always been in "pre-release state". But slowly it is getting to a point where it is ready to be released as a comprehensive package for mission builders to work with.

Therefore, I've been preparing a pre-release branch on GIT-HUB.

https://github.com/FlightControl-Master/MOOSE/tree/MOOSE-RELEASE-2

Those who would like to have a peek look into the new release, can use this branch for pre release mission building, taking into account that there will be bugs and things may change further.

Planning to get this release out by the end of December, beginning of January.

This release of MOOSE will add some interesting additional new features:

- Mission Orchestration: :pilotfly:Per coalition, one can setup multiple logical Missions, which contain multiple Tasks to be achieved by a Group of players. Once Players join the Group, the latest pendingTask needs or is accepted automatically, and the Task goals are followed. Upon achievement of the Task, a Scoring is granted. These Missions are governed by CommandCenters, which are any Identifiable objects within your mission. The CommandCenters take care of communication between the Groups of players, and coordinate Task status, Mission status etc.

- Cargo Handling: :juggle:Cargo is being handled through Finite State Machine orchestration. There are different Cargo types: Units, Groups, Packages, ...

- AI Balancing: :drunk:Balancing the AI is a defined quality in any good mission design. The AI Balancing capability within MOOSE allows you to balance AI based on Player joining events. AI Balancing is actually a Finite State Machine mechanism, that will trigger or destroy/manage AI being dynamically spawned within your mission based on player activity. The AI will receive Tasking to complete, and many different processes can be developed within the MOOSE framework to balance the AI and add its behaviour.

- As mentioned above, the major achievement of this release is the implementation of several Finite State Machine :pain: classes, which orchestrate long-lasting processes within your mission, without much CPU overhead and provides a clear, understandable method to transition between states within the process based on events that are being fired both internally in the process and externall from the process. Also, the Finite State Machines support sub processes, that support the re-use of pre-defined state machines as a long lasting process with possible end-states as a result.

Note that MOOSE is a framework, meaning :sleep:, it provides a mechanism to develop functionality. The current release will contain some functionality required or wanted by the community, but it is the idea that others will use MOOSE to extend the functionality in the future.

Now, I am further preparing this release to get it deployed for others to use and get excited about :music_whistling:

cheers,

FC

The MOOSE framework in its present state prior to the new branch already is heavily used in the 132nd training mission. Functions such as tankers restarting when they are out of fuel, smokey Sam missile scripts and dynamic re spawns and routings of units are some of the major functions we use. I am totally excited about the continued development of MOOSE and wish you all the best with the release! Good times ahead! :)

Good job! The AI-Balancer seems updated, is that so? And I cant see the release brance in git desktop, is it disabled from sync?

Try to press F5 in the GIT Desktop. This key press is undocumented, but refreshes the branch structure in your GIT Desktop. Then Sync.

The AI Balancer is updated, but there are still some issues with it. Fixing those this week. Have a look at the Patrolling test mission, which you can find in the test missions section.

FC

Try to press F5 in the GIT Desktop. This key press is undocumented, but refreshes the branch structure in your GIT Desktop. Then Sync.

The AI Balancer is updated, but there are still some issues with it. Fixing those this week. Have a look at the Patrolling test mission, which you can find in the test missions section.

 

FC

That worked perfect :)

Will check out Patrolling test mission for sure! Thanks FC :thumbup:

Thanks FlightControl!

I have been using MOOSE in my missions a fair bit. I have a semi-dynamic helicopter mission based on nodes I scatter around the map - meaning ground forces attack and defend the nodes. I am hoping to make some use of the Mission Orchestration and Cargo Handling features of MOOSE .. when I get back into that mission. If I can, anything I come up with I am going to try and contribute to the code base but that is a looong way off at the moment!

Thanks for doing this work! It has made my mission building life so much easier.

Is there a third party program that will allow you to review setting of flags, flag numbers and values and such? Like a debugger for LUA script files?

For instance, I'd like to see which flags are set and what their values are, does anyone know of such a program?

I've got logExpert but that does't tell me which flags are set and such..

Is there a third party program that will allow you to review setting of flags, flag numbers and values and such? Like a debugger for LUA script files?

 

For instance, I'd like to see which flags are set and what their values are, does anyone know of such a program?

 

I've got logExpert but that does't tell me which flags are set and such..

You mean an app riding on side of a running mission with the trigger and flag status? Like if single triggers have been active etc?

EDIT: The best alternative is a tail solution as you already have in combination with a separate log for mission and debug codes on triggers.

EDIT2: I think it is even possible to dump flag status to a separate logfile on every frame.

Eagerly awaited release on my side, the ability to have a flexible mission tasking & scheduler is a god sent. Imho, the possibilities of this for open-ended permanent missions are huge.

The DCS Witchcraft utility does work and provides a Lua interface that can be used to query the game live. That lives here: https://jboecker.github.io/dcs-witchcraft/

I have that working but each patch/update means I have to reconnect it. :-)

That an there is a utility called snake-tail which will follow log files as they are generated (like the tail utility for unix)

Debug/Trace

Hi FlightControl,

Could you explain a bit further about debugging in Moose, try to turn on tracing by this :

attempt to call method

BASE:TraceOn( true )

Get this error: attempt to call method 'TraceOn' (a nil value).

And Im not sure about where to put the parameters cause nothing happens, might be due to above problem.

local menuSpawnEscort = MENU_GROUP_COMMAND:New(cClient,"Spawn Escort Helis",menuFeatureParent,spawnEscort,player):E("Debug Exort Menu Line")

:book: Debugging DCS makes me crazy, so hope your trace function can bring som light into my dark dark tunnel :).

Second thing, as you can see Im using menu to spawn escort, due to the menu multiplayer bug I tried to just use to spawn the escort in startup, but it apears like the same bug problem apears in ESCORT class when in MP. Can you confirm this?

Hi FlightControl,

 

Could you explain a bit further about debugging in Moose, try to turn on tracing by this :

 

attempt to call method

BASE:TraceOn( true )

Get this error: attempt to call method 'TraceOn' (a nil value).

 

And Im not sure about where to put the parameters cause nothing happens, might be due to above problem.

 

local menuSpawnEscort = MENU_GROUP_COMMAND:New(cClient,"Spawn Escort Helis",menuFeatureParent,spawnEscort,player):E("Debug Exort Menu Line")

:book: Debugging DCS makes me crazy, so hope your trace function can bring som light into my dark dark tunnel :).

 

Second thing, as you can see Im using menu to spawn escort, due to the menu multiplayer bug I tried to just use to spawn the escort in startup, but it apears like the same bug problem apears in ESCORT class when in MP. Can you confirm this?

The API is

BASE:TraceOnOff( true )

You can "level the output", by using the API:

BASE:TraceLevel( value )

Value is a number from 1 to 3.

You can trace one class:

BASE:TraceClass( "CLASSNAME" )

for example

BASE:TraceClass( "GROUP" ) 

All GROUP objects will be traced ...

You can use objects derived from the BASE class to trace also:

local GroupObject = GROUP:FindByName( "object" )
GroupObject:T( "Text" )

The functions E, T, T1, T2, F, F1, F2 take a table as a parameter...

Thus you can write:

GroupObject:T( { "Text" } )

This will provide the output as:

[1]="me"

Or, you can do as follows

GroupObject:T( { Text = "Text" } )

Provides the output:

[Text]="Text"

You can provide a structure to the trace functions...

GroupObject:T( GroupObject )

This will trace the complete GroupObject field values ...

The key to success is trying it out ...

The tracing will put light into darkness ...

There are MANY examples in the MOOSE code base.

Refer to this post for more explanation:

https://forums.eagle.ru/showpost.php?p=2961579&postcount=245

FC

Right, thanks again for quick and comprehensive answer. Check the docs, I pasted straigh from the docu. for BASE class, BASE:TraceOnOff(TraceOnOff) under "usage" it states:

-- Switch the tracing On
BASE:TraceOn( true )
-- Switch the tracing Off 
BASE:TraceOn( false )

Should have figured out anyway, hope it works now! :)

Regards

Wingthor