Jump to content

MOOSE - Mission Object Oriented Scripting Framework


Recommended Posts

Hey Eric,

 

Also have a look at the first post in the threat. It contains a short tutorial.

You can download the test missions to have good examples of usage. Check the lua files in the "test missions/lua" folder at github:

 

https://github.com/FlightControl-Master/MOOSE/tree/master/Test%20Missions/lua

 

The documentation files on github are a bit out of date. i'll try to regenerate them today. (Documentation is embedded in the source code using loadoc).

 

I also need to write a manual and a training that explains how to install and use the eclipse lua development environment based on java, and how the function and class luadoc documentation system works in eclipse. I will try to do that the coming weeks. Step by step we'll get there...

 

kind regards,

FC

 

Documentation is published here:

 

https://github.com/FlightControl-Master/MOOSE/tree/master/Documentation

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Contacted FlightControl to help me use MOOSE, he was most helpful and got me on the right path quickly. It is evident that he put a lot of work in this project and is passionate about it.

 

Mission scripting just became doable for me.

Thanks mate!

Midnite Signature.jpg

552334314_MidniteSignature.jpg.7c1678ea5639bd6d044b092eb97c300e.jpg

Link to comment
Share on other sites

Hi all, making a bit of progress on the ESCORT class for multi-player. Added now also a function that multiple groups can escort a CLIENT (group).

Multiple scenarios are possible now:

 

- Use a ship escort to fire a Tomahawk to a ground target detected by a plane escort.

- Use an artillery escort batallion to destroy a ground target detected by a helicopter escort.

- Make a plane escort illuminate an area upon command, so that the client can destroy the ground forces.

- Make a helicopter escort a player through a danger zone. The player follows the escort, and the escort gets commands from the player.

...

 

great fun actually.

 

You can find the ESCORT class here: https://github.com/FlightControl-Master/MOOSE/blob/master/Moose/Escort.lua

 

kind regards,

FC


Edited by FlightControl

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

FC,

 

I've been busy all week and was wondering if you got escorting with planes working?

 

 

Sent from my iPhone using Tapatalk

 

 

 

Yep, it works with planes, but also with helicopters, ships, ground vehicles...

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Optimizations done on MOOSE the last week:

 

- Optimized the following logic of planes and helicopters.

- Fixed bugs with menus already present in the cache of the client.

- Fixed a bug in the SPAWN ReSpawn function.

- Optimized the JoinUp logic.

 

- Registering each excort at the client internally.

- Each escort known at the client can exchange targets.

- Each escort can acquire attack assistance from other escorts known at the client.

- Made the MENU class more slick. Now menus are removed recursively for CLIENTS.

- Added a few more types and fine tuned the documentation.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Hello all,

 

For those who want to use or try-out the MOOSe framework, and are looking for support, I've opened a chat channel at the slack.com service.

 

Slack is a great free tool for bringing people together sharing information interactively or just having a chit-chat. Slack has apps available for most mobile OS that support the slack service, so you can be permanently on-line. There is also a dedicated windows application of slack.

 

If you want, you can register on the below channel and interact with me or with others on questions, bugs, ideas etc regarding the MOOSE framework.

 

Click on the link below:

https://flightcontrol.slack.com/signup

 

kind regards,

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

FlightControl

Im interested in this system and went into your Designed missions area to find you have a crap load of missions in there. If I needed to grab 1, which would you recommend to get a good taste of this system. Thanks for the advice.

I was in Art of the Kill D#@ it!!!!

Link to comment
Share on other sites

begin with the following mission:

 

https://github.com/FlightControl-Master/MOOSE/tree/master/Test%20Missions/Moose_Test_SPAWN

 

This mission explains how to spawn new units in all its variable scenarios, which is what most users will want to start with.

 

And I suggest you make a slack.com sign-up on the MOOSE channel.

 

Happy to help out.

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Sorry, forgot to tell that for the test missions dynamic loading is done. You need to install moose in the scripts/moose folder. Find details in the first post of this threat.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

I've just published the alpha release of MOOSE on github here:

 

https://github.com/FlightControl-Master/MOOSE/releases/tag/v0.1.0-alpha

 

Note that the API of the different classes may still change.

So, when i need to change an API, i'll describe what has changed and make a major version upgrade. Counting on your flexibility in this.

 

Note that when designing the classes, the API is well designed, but sometimes during experience, new classes or APIs need to be added.

 

The following version labelling will be used:

 

 

Given a version number MAJOR.MINOR.PATCH, increment the:

 

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

 

 

You can find more info here:

http://semver.org/

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Currently looking at the event dispatcher. Optimizing the logic to improve performance. (eliminating unnecessary loops and improving the call hierarchy). The result will be a smooth event dispatcher with event APIs... A job to be done during next week...

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 2 weeks later...

Hi all,

 

I've detached the scoring logic from the DATABASE class, and created a new SCORING class.

 

This scoring class can:

- Log the player history in a mission.

- Score the hits done by players.

- Score the kills done by players.

- Detect fracitide. Players get killed from the mission if they are killing too many friendlies.

- Log the scoring into a CSV file.

 

The CSV file can then be used to publish the scoring results an a web page or a BI site ...

- Scoring can be shown through the F10 menus...

- Scoring is added in the mission scheduler, so task achievements are accounted for also.

 

TODO(sometime):

- Create a scoring table, based on threat level of the killed units. I have some ideas around that, but need to work it out a bit more ...

- Allow mission designers to apply their own scoring tables.

- Show scoring results to the specific client joined (now all players get a scoring result to see when requested).

 

I know that ED is working on a scoring logic in the server. But we haven't got any clue what can be expected. And probably the scores done by players won't be logged anywhere and cannot be retrieved anywhere. So, with this system there is an attempt to make scores persistent if mission designers want to...

 

Note: there was already a SCORING logic into MOOSE, but it is has been separated from the DATABASE class.

 

Next step now is to extend the DATABASE class so that mutiple DATABASES can be instantiated with its own "filters"..., in other words, to create sets of units and groups dynamically without having to create loops.

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

The next addition to moose i am going to work on is an Early Warning Radar system, so that mission designers can create "groups" of radar detection units. The idea is to have an "EWR" object that can then be used in combination with a new "INTERCEPT" or "SAM" defense objects to create automatic air defenses when a specific EWR group detects new threats...

 

In other words, instead of creating a complete script, i am going to try to develop individual classes that can be used to instantiate multiple objects within the framework that mission designers can then utilize to their own will and fantasy to create AI behaviour...

 

Of course, these object will already use the available classes within the framework. However, i'll need to extend the DATABASE class a bit so that multiple DATABASE objects can be created that monitor dynamically the alive and dead units with specified filters set of each object.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Hi Sven,

Thank you for this awesome framework!

I think this is the way to go with mission scripting etc.

 

I have a question about what is currently possible and what not.

I'm trying to create a function that blocks people from despawning midair to prevent kill denying. So what i currently think I need is a method that prevents people from despawning what I enable via an event handler.

 

Alternatively, some kind of punishment mechanism that blocks people that did despawn midair to spawn again for n minutes.

 

 

Again thanks a lot for this.

Link to comment
Share on other sites

Hey, thanks for your message. Preventing a despawn midair is something I've not yet thought about.

 

 

 

I think what would be doable to make is a system where people may only despawn in air without enemy air threats being 'near', meaning not within a certain range. If they then do despawn (you can't prevent them from doing that), they would be kicked out of the game... Every time they try to reenter, the player would be kicked out again. Something like this maybe?

 

 

 

The scoring follows a similar method when there are players shooting too many friendlies...

 

 

 

Sv.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Thanks for the answer,

you're idea is similar to what i was thinking about if the block of despawning doesn't work. I think a kick is a bit to harsh. To prevent em from spawning for n minutes if they do it would be something appropriate.

I gonna check what i can do with the scoring class, and reply next week.

 

 

 

Don't misunderstand. I still would need to implement something, but if you can do that, I am open for suggestions :-)

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Hi all,

 

You will all be busy this weekend flying the new Gazelle, which will indeed be a good investment :-)

 

Just want to let you know that a few important changes have been published on the MOOSE framework.

 

1. Started off a proper documentation set published online. You can retrieve the documentation of MOOSE here:

http://flightcontrol-master.github.io/MOOSE/

 

These pages are hosted by GITHUB!

 

2. The DATABASE class has been extended to support customized filters and iterators (One to check, as this is really a great addition to the moose framework): http://flightcontrol-master.github.io/MOOSE/Documentation/Database.htm

 

With the new DATABASE class, you are able to instantiate new DATABASE objects and use the filter criteria to buid sets of units contained within the object. There are iterator functions available to iterate the sets within the DATABASE.

 

An example of DATABASE utilization you can find in this test mission:

https://github.com/FlightControl-Master/MOOSE/tree/master/Test%20Missions/Moose_Test_DATABASE

 

Especially the following code may be of your intrest (highlighted in RED):

 

Include.File( 'Database' )
Include.File( 'Spawn' )

[color=Red]DBBluePlanes = DATABASE:New()
 :FilterCoalitions( "blue" )
 :FilterCategories( "plane" )
 :FilterStart()

DBRedVehicles = DATABASE:New()
 :FilterCoalitions( "red" )
 :FilterCategories( "ground" )
 :FilterStart()

DBShips = DATABASE:New()
 :FilterCategories( "ship" )
 :FilterStart()
 
DBBelgium = DATABASE:New()
 :FilterCategories( "helicopter" )
 :FilterCountries( "BELGIUM" )
 :FilterStart()
 
DBNorthKorea = DATABASE:New()
 :FilterCountries( "NORTH_KOREA" )
 :FilterStart()
 
DBKA50Vinson = DATABASE:New()
 :FilterTypes( { "Ka-50", "VINSON" } )
 :FilterStart()

DBBluePlanes:TraceDatabase()
DBRedVehicles:TraceDatabase()
DBShips:TraceDatabase()
DBBelgium:TraceDatabase()
DBNorthKorea:TraceDatabase()
DBKA50Vinson:TraceDatabase()

[/color]
SpawnUS_Plane = SPAWN:New( 'Database Spawn Test USA Plane')
GroupUS_Plane = SpawnUS_Plane:Spawn()

SpawnUS_Vehicle = SPAWN:New( 'Database Spawn Test USA Vehicle')
GroupUS_Vehicle = SpawnUS_Vehicle:Spawn()

SpawnUS_Ship = SPAWN:New( 'Database Spawn Test USA Ship')
GroupUS_Ship = SpawnUS_Ship:Spawn()

SpawnRU_Vehicle = SPAWN:New( 'Database Spawn Test RUSSIA Vehicle')
GroupRU_Vehicle = SpawnRU_Vehicle:Spawn()

SpawnRU_Ship = SPAWN:New( 'Database Spawn Test RUSSIA Ship')
GroupRU_Ship = SpawnRU_Ship:Spawn()

SpawnUS_AttackVehicle = SPAWN:New( 'Database Spawn Test USA Attack Vehicle' )
SpawnRU_AttackVehicle = SPAWN:New( 'Database Spawn Test RUSSIA Attack Vehicle' )

for i = 1, 10 do
 GroupRU_AttackVehicle = SpawnRU_AttackVehicle:SpawnInZone( ZONE:New("Spawn Zone RU"), true)
 GroupUS_AttackVehicle = SpawnUS_AttackVehicle:SpawnInZone( ZONE:New("Spawn Zone US"), true)
end


--DBBlue:TraceDatabase()
routines.scheduleFunction( DBBluePlanes.TraceDatabase, { DBBluePlanes }, 1 )
routines.scheduleFunction( DBRedVehicles.TraceDatabase, { DBRedVehicles }, 1 )
routines.scheduleFunction( DBShips.TraceDatabase, { DBShips }, 1 )
routines.scheduleFunction( DBBelgium.TraceDatabase, { DBBelgium }, 1 )
routines.scheduleFunction( DBNorthKorea.TraceDatabase, { DBNorthKorea }, 1 )
routines.scheduleFunction( DBKA50Vinson.TraceDatabase, { DBKA50Vinson }, 1 )

[color=Red]DBRedVehicles
 :ForEachAliveUnit( function( DCSUnit ) 
   DBRedVehicles:T( DCSUnit:getName() )
 end )
[/color]

3. Documentation has also been updated for:

 

SPAWN:

http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html

 

ESCORT:

http://flightcontrol-master.github.io/MOOSE/Documentation/Escort.html

 

BASE:

http://flightcontrol-master.github.io/MOOSE/Documentation/Base.html


Edited by FlightControl

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Just released v0.2.0-alpha of MOOSE: https://github.com/FlightControl-Master/MOOSE/releases

 

The following extensions were done:

 

  1. The underlying EVENTS handling mechanism has been changed. A new _EVENTDISPATCHER object is created for use in the MOOSE classes.
  2. The DATABASE class has been extended with filters and iterators. More filters and iterators will be added in the near future.
  3. A new SCORING class as been created to track the scoring and log the scoring of hosted missions.
  4. The function ZONE:GetRandomPointVec2() now calculates true random points within the circle of the zone. Previously it would calculate points within a calculate square with the base and the height equal to the radius of the zone.

IMPORTANT: Some function APIs have changed, so this release is not backward compabible. If you are using these functions within your mission, you'll need to revise the SYNTAX of the following functions:

 

  1. SPAWN:SpawnInZone(Zone, ZoneRandomize, SpawnIndex) The ZoneRandomize parameter has been added as an optional parameter! Setting the value to "true" for this parameter will spawn the units at randomized locations within the zone.

ACTION REQUIRED: for this release!

The MOOSE dynamic loader has been modified. Now a new Moose.lua include file has been added within the MOOSE framework. This moose file is included within the Dynamic loader.lua file (https://github.com/FlightControl-Master/MOOSE/blob/master/Loaders/Moose_Load_Dynamic.lua). Ensure that you refresh the dynamic loader within ALL your active missions, or MOOSE will not dynamically load correctly! I had to do this action because with the changes, conflicts were generated within the original Include.File mechanism, and I wanted a proper solution. Now these conflicts are cleaned and a proper base has been set...Re-Including the dynamic loader is a small action for the current small user community...

 

kind regards,

FC


Edited by FlightControl

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...