MOOSE - Mission Object Oriented Scripting Framework

If there's nothing major changed in the last patches, you can spawn any Object with any country affiliation.

The Coalition is determined by country, so it is important to know which country is on what side.

With dynAdd you may even add static objects, not available in the ME ;)

What you should omit is, spawning objects and force a coalition, or spawn them with a neutral country.

Though possible, it may cause issues with internal checks to determine attack behaviour, scores, hit system etc.

I hope we get a fully supported neutral/civilian coalition in the future, though.

By the way, great job FlightControl. Taking my first steps, with MOOSE and in combination with MIST this is fantastic to automate dynamic, repayable missions through some simple spawns.

The Coalition is determined by country, so it is important to know which country is on what side.

Wingthor

Since Moose is objcet programming oriented it shuld have a common snippet library. Does it exists?

Here is my contrib.:)

Converts Blue to Red GROUP (intstance)

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

Regards

Gents,

Small update on the MOOSE framework ...

In the background during the times when I was not sick and feeling good, I've been slowly working on API improvements for the new Tasking module set. Now today, I finally got it working, although it is not yet published.

Find the underlying example task script to coordinate a SEAD mission.

The advantage of this is now, that one can use pre-defined process patterns as sub processes to implement a task.

These are these PROCESS_... type of classes that are given as a parameter.

local Mission = MISSION:New( 'SEAD Targets', "Strategic", "SEAD the enemy", coalition.side.RED )
local Scoring = SCORING:New( "SEAD" )

Mission:AddScoring( Scoring )

local SEADSet = SET_GROUP:New():FilterPrefixes( "Test SEAD"):FilterStart()
local TargetSet = SET_UNIT:New():FilterPrefixes( "US Hawk SR" ):FilterOnce()

local TargetZone = ZONE:New( "Target Zone" )

local TaskSEAD = TASK_BASE:New( Mission, SEADSet, "SEAD Radars", "A2G", "SEAD" ) -- Tasking.Task#TASK_BASE
 --:New( Mission, SEADSet, "SEAD Radars", TargetSet, TargetZone )
 
local FsmSEAD = TaskSEAD:GetFsmTemplate()

FsmSEAD:AddProcess( "Planned",    "Accept",   PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ), { Assigned = "Route", Rejected = "Eject" } )
FsmSEAD:AddProcess( "Assigned",   "Route",    PROCESS_ROUTE_ZONE:New( TargetZone, 3000 ), { Arrived = "Update" } )
FsmSEAD:AddAction ( "Rejected",   "Eject",    "Planned" )
FsmSEAD:AddAction ( "Arrived",    "Update",   "Updated" ) 
FsmSEAD:AddProcess( "Updated",    "Account",  PROCESS_ACCOUNT_DEADS:New( TargetSet, "SEAD" ), { Accounted = "Success" } )
FsmSEAD:AddProcess( "Updated",    "Smoke",    PROCESS_SMOKE_TARGETS_ZONE:New( TargetSet, TargetZone ) )
FsmSEAD:AddAction ( "Accounted",  "Success",  "Success" )
FsmSEAD:AddAction ( "Failed",     "Fail",     "Failed" )

TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 )
TaskSEAD:AddScoreTask( "Failed", "Failed to destroy all target radars", -100 )
TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 )
TaskSEAD:AddScoreProcess( "Account", "Fail", "failed to destroy a radar", -100 )

function FsmSEAD:onenterUpdated( TaskUnit )
 self:E( { self } )
 self:Account()
 self:Smoke()
end

-- Needs to be checked, should not be necessary ...
TaskSEAD:AssignToGroup( SEADSet:Get( "Test SEAD" ) )

Mission:AddTask( TaskSEAD )

The above is a declaration of a workflow. It is in fact a "Hierarchical Finite State Machine (Fsm)" implementation ...

You declare a Task using TASK_BASE. Later, task templates will be added in derived classes. The already existing TASK_SEAD and TASK_A2G in the MOOSE framework need to be reworked to this new method now.

Each TASK_BASE instance has a Finite State Machine (Fsm). It is embedded within the Task, and serves as a template when Units (Players) join the Task and are assigned to it.

When a player joins a unit, that is belonging to the Set of Groups that can be assigned to the Task, the Task will allocate a new Finite State Machine for that Unit. In other words, each Task has multiple running Fsm as there are Units assigned to the task...

The Task itself is also an Fsm, but governs the status of the task, meaning, the results achieved and whether the task is planned, ongoing or failed.

The function

local FsmSEAD = TaskSEAD:GetFsmTemplate()

retrieves the template.

This template Fsm needs then to be filled with state transitions and sub processes.

The function

FsmSEAD:AddAction ( "Rejected",   "Eject",    "Planned" )

adds a state transition based on an event. Read like this: Allow the state of the state machine to be transitioned from *Rejected* to *Planned*, when the event *Eject* happens.

Other example is:

FsmSEAD:AddAction ( "Arrived",    "Update",   "Updated" )

...

Then the question comes, how are these events fired? Well, ...

Each Event declared within the Fsm can be catched, each State within the Fsm can be catched, by declaring separate functions with your own logic.

The example underlying catches the change of the state of the Fsm, when the state changes to *Updated*.

function FsmSEAD:onenterUpdated( TaskUnit )
     self:E( { self } )
     self:Account()
     self:Smoke()
end

When the FsmSEAD reaches the state Updated ( therefore prefix onenter ), the function is executed...

Within this function, you'll see the line

self:Account()

and

self:Smoke()

... These 2 lines fire the events Account and Smoke within the Fsm.

Next ...

The function

FsmSEAD:AddProcess( "Planned",    "Accept",   PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ), { Assigned = "Route", Rejected = "Eject" } )

adds a Sub Fsm to the master Fsm.

The class PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ) is a state machine itself and the reference to the instance is given as a parameter to the AddProcess function.

Read the line as follows: Add a Sub Fsm to the master Fsm, and when the event Accept is fired, execute that Sub Fsm... The return states of the Sub Fsm can be Assigned or Rejected. When the return state is Assigned, the master Fsm state will be set to Assigned, and the event *Route* will be triggered AUTOMATICALLY! Similar, when the end state of the Sub Fsm is Rejected, the event Eject will be fired automatically!

In other words, Sub Fsm classes implement predefined Fsm patterns, do some processing and return a resulting state... Many different types of Sub Fsms can be constructed now, which mission designers can use within their missions.

Scoring ...

Because we have state machines, we can add scoring events to the state machine. When an Fsm reaches a certain state, one can use a couple of functions to set a score, with a text, that is displayed to the coalition for which you are playing for.

The examples are:

TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 )
TaskSEAD:AddScoreTask( "Failed", "Failed to destroy all target radars", -100 )
TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 )
TaskSEAD:AddScoreProcess( "Account", "Fail", "failed to destroy a radar", -100 )

The function

TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 )

adds a score of 250 when ALL of the target radars are destroyed within the test mission. It is given when the *master Fsm* reaches the state Success.

The function

TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 )

adds a score of 25 when ONE target is destroyed within the test mission. It is linked to the state change within the Sub Fsm under the event Account. When the Sub Fsm reaches the state Account, the score is added, and a text is displayed to the coalition for which you are playing.

Why all this explanation?

Because this provides now a VERY DYNAMIC mechanism to implement quickly missions, re-using pre-defined workflows (Finite State Machines), which are tested and used within several missions, and that are working.

You can build you own flows for a task, you can build multiple different tasks, and assign them to a mission. You can implement multiple missions, with multiple tasks assigned to different groups...

That goal is coming really close now.

FC , I'll need several hours to get into what you just wrote, but that's potentially hours saved, if that's what I imagine :)

Just what I was looking for!

Thanks...

Regards and get well soon!

Wingthor

I got most of it, I guess, just missing how to catch or trigger events

Or simply how initial fsm state is declared

I got most of it, I guess, just missing how to catch or trigger events

Or simply how initial fsm state is declared

Let me give a simple example. We will create a state machine to control a unit.

local FsmUnit = UNIT:FindByName("unitname")

local Fsm = STATEMACHINE_CONTROLLABLE:New( {}, FsmUnit )

-- Now we create 2 state transitions.

Fsm:AddAction( "Stopped", "Start", "Moving" )
Fsm:AddAction( "Moving", "Stop", "Stopped" )

-- Set the initial state as Stopped.
Fsm:SetInitialState( "Stopped" j

-- Nothing happened till this point...
-- But now, we fire the event "Start".
-- 2 Start and two Stop functions are automatically added to the Fsm object.
-- Fsm:Start() will fire the Start event immediately.
-- Fsm:__Start( 1 ) will fire the Start event asynchronously after 1 second...
-- Similar with the Stop event...
-- Just remember that event functions starting with __ are asynchronous. They get a parameter indicating the seconds to wait until the event is fired.
-- But now, we fire the event "Start",  asynchronously.

Fsm:__Start( 1 )

-- So now, the Fsm will transition from state "Stopped" to state "Moving".
-- But unfortunately, nothing will happen unless we program the Fsm to control the given CONTROLLABLE, in this case FsmUnit.
-- For each state, we can build a method to catch the state transition when it enters the state, or when it leaves the state in the Fsm.
-- Build a method starting with onenter concatenated with the State name, and this function will be called before the state transitions.
-- Build a method starting with onleave concatenated with the State name, and this function will be called when the state transitioned.

function Fsm:onenterMoving( FsmUnit, Event, From, To )
 FsmUnit:Start()
 self:__Stop( 5 )
end

function Fsm:onenterStopped( FsmUnit, Event, From, To )
 FsmUnit:Start()
 self:__Start( 1 )
end

-- This implementation will start FsmUnit in 1 second, stops FsmUnit after 5 seconds, and repeats this process...

This is a simple example, and Fsm hierarchies have not been touched upon yet...

Note that this functionality in moose is not yet published on the master branch. It is hiding in the branch Spawn-Randomization.

You can try this out...

I am a little bit worried how this new functionality is to be explained to a large audience of varying lua and DCS experience... But that is a worry for later.

FC

+1

Probably got it a little. You modified TAKS object to include a STATEMACHINE_TASK (derived from STATEMACHINE_CONTROLLABLE, so includes all the functions you listed in the second example for FSM control) to control the state of the task.

I've been having a tough time getting a sure definition of "Controllable" in Moose, since I've not seen a definition of a "Controllable" in DCS environment, only "Controller", which refers to AI entity, and Moose doesn't seem to refer to Controllable as AIs only.

All this definitely looks like the generic implementation needed for having various tasks handled in a mission. Really looks like what I needed :)

Probably got it a little. You modified TAKS object to include a STATEMACHINE_TASK (derived from STATEMACHINE_CONTROLLABLE, so includes all the functions you listed in the second example for FSM control) to control the state of the task.

I've been having a tough time getting a sure definition of "Controllable" in Moose, since I've not seen a definition of a "Controllable" in DCS environment, only "Controller", which refers to AI entity, and Moose doesn't seem to refer to Controllable as AIs only.

 

All this definitely looks like the generic implementation needed for having various tasks handled in a mission. Really looks like what I needed :)

CONTROLLABLE is a base wrapper class.

Both UNIT and GROUP derive from CONTROLLABLE.

CONTROLLABLE implements the DCS "task" functions, encapsulating the DCS Controller object.

So, the state machine STATEMACHINE_CONTROLLABLE can govern the behaviour of a group or unit through state transitions.

Happy you like the initiative. There is still some work to do before publishing. But thought of already introducing it and obtain feedback.

Todos are:

- make references to processes weak, to allow garbage collection.

- when a task finished, all contained objects should be cleaned up nicely. No process may run, no hanging events etc.

- test missions workflow.

- complete SEAD and A2G task templates using the new API.

- revise DETECTION and automatic task assignment.

- document changes

- document functions added

- retest test missions

- make release note

- publish

Then make training videos and that is where the fun starts.

Hi FlightControl

I've just started learning Moose by making very simple missions using moose and going forward to more complicated functions. my purpose of making such missions is not making mission but learning how moose works, so I do not care if sometimes the created mission looks insane.

apparently I am doing something totally wrong because some of the very basic and easy to set functions are not working. for example I've been dealing with the PATROLZONE function with no joy, then I ran the Moose Test Mission/PATROLZONE and It also didnt work, the AC lands immediately at nearest airbase exactly the same as my mission. that is why I think that am probably in totally wrong area.

-The last version downloaded from Github.

-Eclipse and Moose framework are installed according to the Tutorial Videos.(very nice and useful videos BTW.Thank You)

-Moose.LUA loads at very first step of the missions.

-And....what else?

Sorry if I interrupted your professional discussions with my basic and boring questions :)

You think that was a basic question LOL.

OK here goes :)

Late to the party I know but this looks too good to miss.

I have literally just downloaded MOOSE and would like to know does it matter where I put the "Moose Mission setup" folder? Does it have to be inside the DCS folder or can I put it anywhere I like?

the documentation isn't very specific on this point.

I am just looking to play with this at the moment I play mostly SP and am looking to create some semi dynamic missions and training missions for myself.

Cheers

SD

You think that was a basic question LOL.

 

OK here goes :)

 

Late to the party I know but this looks too good to miss.

 

I have literally just downloaded MOOSE and would like to know does it matter where I put the "Moose Mission setup" folder? Does it have to be inside the DCS folder or can I put it anywhere I like?

the documentation isn't very specific on this point.

 

I am just looking to play with this at the moment I play mostly SP and am looking to create some semi dynamic missions and training missions for myself.

 

Cheers

SD

What is important is to locate the "Moose.lua" file inside this folder. Once inside mission editor, you'll have to have this file executed through a trigger and point the trigger to this location. The Mission Editor will take the file and embed a copy of it into the mission file, so its original location doesn't matter

I've just started learning Moose by making very simple missions using moose and going forward to more complicated functions. my purpose of making such missions is not making mission but learning how moose works, so I do not care if sometimes the created mission looks insane.

This is fantastic news BSpike, and the way to go. By trying things and playing with the available classes, you'll get a good feeling how these classes work, interface and behave with other classes.

Note also that in the MOOSE framework, some test missions are embedded, which have their own examples.

You can find these test missions here on github: Test Missions

apparently I am doing something totally wrong because some of the very basic and easy to set functions are not working. for example I've been dealing with the PATROLZONE function with no joy, then I ran the Moose Test Mission/PATROLZONE and It also didnt work, the AC lands immediately at nearest airbase exactly the same as my mission. that is why I think that am probably in totally wrong area.

The PATROLZONE function does not work in this version, and neither does the test mission. But the good news is, I have completely reworked the AIBALANCER and the PATROLZONE classes in the upcoming release.

In the new versions, the AIBALANCER and PATROLZONE classes work like finite state machines also.

You can find the test mission here if you are interested, but these are still in the development branch. I suggest you await a bit the delivery of this release, which I am pushing to deliver in December (finally) while testing PATROLZONE.

The development branch with the modified PATROLZONE class is here, but it uses other classes that will be published in the new release upcoming. The reworked test mission in de development branch for the new PATROLZONE is here. It Spawns a new airplane, which when returns to the nearest airbase, spawns a new airplane, which will patrol another zone... Implemented using state machines...

-The last version downloaded from Github.

-Eclipse and Moose framework are installed according to the Tutorial Videos.(very nice and useful videos BTW.Thank You)

-Moose.LUA loads at very first step of the missions.

-And....what else?

Thanks for watching the videos.

Suggest you start playing using the SPAWN class. This is the most obvious class in the MOOSE set to learn. While learning, you'll understand better the APIs, and how MOOSE interfaces within your program.

If you want to try out something more advanced, suggest have a closer look at the ESCORT class. This class allows to let AI planes escort a player unit. (Standard DCS does not allow to do such), and includes many options to "control" the escorting AI. You can setup 4 escorting AI to follow your human plane. Try helicopters and airplanes.

Sorry if I interrupted your professional discussions with my basic and boring questions :)

There are no boring questions concerning the framework :pilotfly:

Thanks for asking. As you may know, I have had health problems, and was out for a couple of months. But would like to finish this framework, and this is the right tempo. Reading posts, and just replying when I have time.

Hope the above helps a bit.

FC

Extract it anywhere.

What is important is to locate the "Moose.lua" file inside this folder. Once inside mission editor, you'll have to have this file executed through a trigger and point the trigger to this location. The Mission Editor will take the file and embed a copy of it into the mission file, so its original location doesn't matter

Maybe also have a look at this video. It is a bit long, but worth it to have a closer look which tools to download and install and how to setup your development environment.

You can explore more videos for further explanations.

Some of the videos are a bit old

(they need to be reworked when the new release will be published).

Check this video:

FC

Extract it anywhere.

What is important is to locate the "Moose.lua" file inside this folder. Once inside mission editor, you'll have to have this file executed through a trigger and point the trigger to this location. The Mission Editor will take the file and embed a copy of it into the mission file, so its original location doesn't matter

I thought as much but wanted to get some conformation. Thanks mate :)

SD

You think that was a basic question LOL.

 

OK here goes :)

No comments :-)

Late to the party I know but this looks too good to miss.

Welcome to the club. It is never late to try something new.

Just know that this framework contains hours and hours of effort, and encapsulates a lot of complexity to write good missions using lua in DCS.

I am about to release something that may be a game changer for mission design in DCS soon. So, you're just on time, not too late at all.

I have literally just downloaded MOOSE and would like to know does it matter where I put the "Moose Mission setup" folder? Does it have to be inside the DCS folder or can I put it anywhere I like?

the documentation isn't very specific on this point.

Have a look at this video on my youtube channel.

I am just looking to play with this at the moment I play mostly SP and am looking to create some semi dynamic missions and training missions for myself.

This is the way to go. Also know that there are test missions with example lua files. You can learn a lot from these test missions.

By the way, great job FlightControl. Taking my first steps, with MOOSE and in combination with MIST this is fantastic to automate dynamic, repayable missions through some simple spawns.

Hi Shagrat,

Thank you for your appreciation. (Feel free to give kudos :D).

If you like, you can have a look at the test missions (described one post above) to learn a bit more about the MOOSE framework beyond spawing groups. There is also a youtube channel.

My intentions were never to replace mist, but to be complementary with it. In this way, people are served with additional capabilities, and can choose what solution is the best of both for varying mission design scenarios.

Have fun

FC

Since Moose is objcet programming oriented it shuld have a common snippet library. Does it exists?

 

Here is my contrib.:)

 

Converts Blue to Red GROUP (intstance)

 

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

Regards

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

By the way, I see you are using env.info lines.

Know that in MOOSE there is a tracing implementation.

You can write like this:

group:E( "This line will always be traced" )
group:T( "This line will only be traced when tracing is on and level 1 is traced" )
group:T2( "This line will only be traced when tracing is on and level 2 is traced" )
group:T3( "This line will only be traced when tracing is on and level 3 is traced" )

group:E( { "Parameter 1", "Parameter 2" } ) -- this traces 2 strings.

local parameter1 = 1
local parameter2 = { key = 2 }
group:E( { parameter1, parameter2 } ) -- this traces 2 variables.

group:F( { parameter1, parameter2 } ) -- this traces 2 parameters at the beginning of a function... The function name is traced too!
group:F2( { parameter1, parameter2 } ) -- this for level 2
group:F3( { parameter1, parameter2 } ) -- this for level 3

Tracing is documented at the BASE class here.

Each moose class IMPLEMENTS the BASE class, so it can be TRACED using these tracing functions!

I follow your suggestion for the code snippet. Where would you suggest to locate this?

Also, your function... After some rework, this could be added to the library in a contribution on github. Good idea?

Feel free to post feedback.

FC

This is fantastic news BSpike, and the way to go. By trying things and playing with the available classes, you'll get a good feeling how these classes work, interface and behave with other classes.

Note also that in the MOOSE framework, some test missions are embedded, which have their own examples.

You can find these test missions here on github: Test Missions

 

 

 

The PATROLZONE function does not work in this version, and neither does the test mission. But the good news is, I have completely reworked the AIBALANCER and the PATROLZONE classes in the upcoming release.

In the new versions, the AIBALANCER and PATROLZONE classes work like finite state machines also.

You can find the test mission here if you are interested, but these are still in the development branch. I suggest you await a bit the delivery of this release, which I am pushing to deliver in December (finally) while testing PATROLZONE.

The development branch with the modified PATROLZONE class is here, but it uses other classes that will be published in the new release upcoming. The reworked test mission in de development branch for the new PATROLZONE is here. It Spawns a new airplane, which when returns to the nearest airbase, spawns a new airplane, which will patrol another zone... Implemented using state machines...

 

 

 

Thanks for watching the videos.

 

Suggest you start playing using the SPAWN class. This is the most obvious class in the MOOSE set to learn. While learning, you'll understand better the APIs, and how MOOSE interfaces within your program.

 

If you want to try out something more advanced, suggest have a closer look at the ESCORT class. This class allows to let AI planes escort a player unit. (Standard DCS does not allow to do such), and includes many options to "control" the escorting AI. You can setup 4 escorting AI to follow your human plane. Try helicopters and airplanes.

 

 

 

 

There are no boring questions concerning the framework :pilotfly:

Thanks for asking. As you may know, I have had health problems, and was out for a couple of months. But would like to finish this framework, and this is the right tempo. Reading posts, and just replying when I have time.

 

Hope the above helps a bit.

 

FC

Thanks for the comprehensive response.

I'm going to take each class and get deep into it. It's been a while I spent an hour or two a day watching the videos and reading the very well made documents that you published.

Spawn class was the first one I took, didn't manage to have limited re-spawn sorted out though. Units ignore the set limit and keep spawning for ever(I must have done something wrong, will take a look at it again tonight)

Hope you have completely recovered and thanks again for your efforts for the community.

BSpike

No comments :-)

 

 

 

 

Welcome to the club. It is never late to try something new.

Just know that this framework contains hours and hours of effort, and encapsulates a lot of complexity to write good missions using lua in DCS.

I am about to release something that may be a game changer for mission design in DCS soon. So, you're just on time, not too late at all.

 

 

 

Have a look at this video on my youtube channel.

 

 

 

 

 

This is the way to go. Also know that there are test missions with example lua files. You can learn a lot from these test missions.

Thanks Sven

I have been following this thread for a while and have watched some of your vids (which are excellent by the way) I get lost in a lot of these threads due to the complexity of what you guys are doing.

but I thought it was about time I dipped my toe in the water so to speak.

I have very limites C++ experience and practically zero LUA skills but it looks like a fun way to try and learn :)

Cheers

SD

Thanks Sven

 

I have been following this thread for a while and have watched some of your vids (which are excellent by the way) I get lost in a lot of these threads due to the complexity of what you guys are doing.

but I thought it was about time I dipped my toe in the water so to speak.

I have very limites C++ experience and practically zero LUA skills but it looks like a fun way to try and learn :)

 

Cheers

SD

Lua is a very nice language, and it has a lot of capabilities not found in many other scripting languages. C++ knowledge is not (yet) required to use MOOSE :).

Just gain experience in lua.

In order not to get lost in lua, I suggest you have a look at the following tutorial pages in order to understand the language constructs of lua.

https://www.tutorialspoint.com/lua/

Learning lua is indeed fun, and using MOOSE is a nice way to do that. I'll be posting next year some new videos and rework some old ones, in order to make the learning curve more smooth. But before I can do that, I need to get that new MOOSE release finished and published .

Sven

Trying to use Spawn-Randomization branch, but the new Moose.lua script loading puzzles me :)

Where to put Scripts/Moose directory?

I suggest you hold back using materials from development branch for the moment. You'll need to wait until the pieces have fallen into pace. If I release now, some people will get slightly angry :-)

Structural changes have happened how the files are organized. When the new stuff is released, all will fall into place.

Sven