MOOSE - Mission Object Oriented Scripting Framework

[shagrat]

Unless you guys are wanting to immediately update and sync from the Dev branch and contribute to coding at your desktop using Github desktop, then setting up LDT has very little gains for all the effort. Just download moose, get notepad and write something. Too many people hung up on this and it's killing new uptake. This was designed this way as a dev environment so more people could contribute to the codebase, but there's only a handful of people that actually do that.

Yes and no. The intellisense feature is a tremendous help when writing scripts, though setting up Eclipse and LDT is some effort.

With the step-by-step setup guide and video it isn't that difficult anymore.

It is just very important to follow every step and concentrate on the details.

 

https://flightcontrol-master.github.io/MOOSE_DOCS/Usage_Guide.html

[funkyfranky]

Yes and no. The intellisense feature is a tremendous help when writing scripts, though setting up Eclipse and LDT is some effort.

I strongly agree on this. LDT has many advantages with makes it worth installing it:

• The intellisense and auto completion (tab) avoid a lot of typos which make your script crash.
  
• The intellisense suggests all the right functions available for each MOOSE object. Something you would otherwise need to lookup in the documentation (which not many people do). So you don't miss out functions you might need or are not aware that they even exist.
  
• If you put your cursor over a MOOSE object variable, you get the documentation at a glance.
  
• If you put your cursor over a MOOSE object/function and hit F3 it automatically jumps to the MOOSE function in the code. You can easily check what is happening in the function which is better than any documentation at times.
  
• Probably more that I forgot :)
  

It might be a hassle to install it the first time, but once you got it running, it saves a lot of time.

[Habu_69]

As someone new to coding I agree LDT is a big help, but NOT essential, as Pikey points out. I also get the module warnings when saving files, but I found that ignoring them creates no issues I have noticed.

[kunterbunt]

Thanks to everybody who is trying to help. Unfortunately nothing helped. Intellisense is not working in LDT for the MOOSE framework. Probably related to the errors I get when compiling (cleaning) the project.

Five errors about 'Build Modules' with the following java error: An internal error occurred during: "Build Modules".

java.lang.ArrayIndexOutOfBoundsException

[Pikey]

There's no way I would say it's not useful (once you have it going), but what I'm afraid of is folks get bogged down in the install and config and get put off using Moose altogether. I wouldn't say that if I hadn't seen it people struggle times over. I use it, i use it over Notepad++, but it's not a silver bullet to help you coding, the intellisense seldom pops up for me before I typed the line, and most of the time I copy and paste from previous code and then edit it so it's never going to have that chance. There's also a pretty common error that even if you follow the instructions it still errors until you erm, I forget how it was fixed for me, but adding a path into the build repository that should have appeared by itself. That one killed a lot of passion.

 

 

Then, two screens and bookmarks for all the docs and soaking up the functions was what got me over the hump. Still use it, but jeez it's the source of much angst!

Edited July 1, 2018 by Pikey
yoda speak

[S D]

From my point of view i only use NP++ and then example missions and info i can find online to put code together.

I didnt like the look of installing and setting up the LDT stuff and like Pikey said it might possibly of put me off had i gone down that route and had issues.

[RedeyeStorm]

I have the latest java wich is 171 I believe. Using the stable version of LDT. I have no knowledge of lua so thee intellisense is a must for me. Bassicly all I want is single plane to spawn and follow me around. When rtb despawn and when client starts or restarts engine spawns in again. An attempt to work around the fact that vanilla wingmen can not be spawned in. Plan to use it for the Through the inferno missions.

 

RedeyeStorm.

[doodenkoff]

[...] but what I'm afraid of is folks get bogged down in the install and config and get put off using Moose altogether. [...]

 

 

This. The "process" as shown for MOOSE, will put off many casual mission creators. If you just want to see some example scripts, see what they do, and edit them to fit your needs, Notepad++ set to the lua language is more than adequate.

[Swany]

Hi all,

I am trying to setup Eclipse but damm it is testing my skills allready. I think I finally got it where the map 'Moose Development' is noted as a source. When I press ok I got five errors about 'Build Modules' with the following java error: An internal error occurred during: "Build Modules".

java.lang.ArrayIndexOutOfBoundsException

 

SOS...SOS...Iceberg

 

I've always found it to be a Problem with the folder name. I ways remove anything trailing _ ie MOOSE 2.3.1_blah lah blah. If I rename it to MOOSE 2.3.1 it sets up with no build errors

[Hardcard]

Where do I put my ogg sound files for MOOSE to play?

 

Hi,

 

I've checked the github documentation regarding usersound functionality.

While that's probably enough to write a functional script, I still have no idea of how to tell MOOSE where my custom ogg sound files are.

 

For instance:

 local BlueVictory = USERSOUND:New( "BlueVictory.ogg" )
 local PlayerGroup = GROUP:FindByName( "PlayerGroup" )
 BlueVictory:ToGroup( PlayerGroup )

 

This is nice and all, but how does MOOSE know where to find that "BlueVictory.ogg" file?

 

Do I need to set up my custom ogg files in the mission editor first?

Do I need to place them somewhere specific?

 

I'm at a loss here, any help would be appreciated :cry:

[Delta99]

Yes, set them up in the ME first. They can be in a trigger that will never fire. This adds them into the mission.

 

Hi,

 

I've checked the github documentation regarding usersound functionality.

While that's probably enough to write a functional script, I still have no idea of how to tell MOOSE where my custom ogg sound files are.

 

For instance:

 local BlueVictory = USERSOUND:New( "BlueVictory.ogg" )
 local PlayerGroup = GROUP:FindByName( "PlayerGroup" )
 BlueVictory:ToGroup( PlayerGroup )

 

This is nice and all, but how does MOOSE know where to find that "BlueVictory.ogg" file?

 

Do I need to set up my custom ogg files in the mission editor first?

Do I need to place them somewhere specific?

 

I'm at a loss here, any help would be appreciated :cry:

[Hardcard]

Need pointers for custom menu creation and command insertion with MOOSE

 

Thanks Delta, that did the trick!

 

Problem now is to assign my ogg sound files to custom menu commands without issues...

Not only that, though, since building customized menus with MOOSE seems to be already daunting, even with the script examples and test missions available online, I just fail to grasp the underlying structure/order/logic, which leads to my scripts not working.

 

For instance, here I tried to play 2 different ogg files along with their respective text messages for two different groups (when I spawn them for the first time):

 

 

local Su33briefing = USERSOUND:New( "Su33 carrier operations briefing.ogg" )
local Su33Briefingmessage = MESSAGE:New( "briefing message", 40, "Intro1" )
local KuziGroup = GROUP:FindByName( "Su33 Kuzi" )
local Su33AirRefuelingRED = USERSOUND:New( "Air refueling briefing RED.ogg" ) 
local Su33AirRefuelingBriefingRed = MESSAGE:New( "briefing message", 40, "Intro2" )
local SochiGroup = GROUP:FindByName( "Su33 Sochi" ) 

 if KuziGroup:IsAlive() or SochiGroup:IsAlive() then
Su33briefing:ToGroup(KuziGroup)
Su33Briefingmessage:ToGroup(KuziGroup,Settings)
Su33AirRefuelingRED:ToGroup(SochiGroup)
Su33AirRefuelingBriefingRed:ToGroup(SochiGroup,Settings)
 end 

 

 

This script results in only Su33briefing and Su33Briefingmessage being played on spawn (to KuziGroup).

SochiGroup never receives its spawn messages (even when I spawn it first on mission start).

 

 

I noticed that the opposite happens (ie KuziGroup stops getting its messages) when I write the script in the opposite order, like this:

 

 

 

local Su33briefing = USERSOUND:New( "Su33 carrier operations briefing.ogg" )
local Su33Briefingmessage = MESSAGE:New( "briefing message", 40, "Intro1" )
local KuziGroup = GROUP:FindByName( "Su33 Kuzi" )
local Su33AirRefuelingRED = USERSOUND:New( "Air refueling briefing RED.ogg" ) 
local Su33AirRefuelingBriefingRed = MESSAGE:New( "briefing message", 40, "Intro2" )
local SochiGroup = GROUP:FindByName( "Su33 Sochi" ) 

 if SochiGroup:IsAlive() or KuziGroup:IsAlive() then
Su33AirRefuelingRED:ToGroup(SochiGroup)
Su33AirRefuelingBriefingRed:ToGroup(SochiGroup,Settings)
Su33briefing:ToGroup(KuziGroup)
Su33Briefingmessage:ToGroup(KuziGroup,Settings)
end 

 

 

So that means I must be writing it wrong.

I've tried several different versions of this script, the most I've been able to achieve is make these spawn sounds and messages play correctly ONLY when I assign the script file to a continuous trigger (obviously, the problem then is that the messages won't stop playing :cry:).

 

The only other option that has worked for me is to just write 2 separate script files, one for KuziGroup and another for SochiGroup (running on separate triggers).

 

As for building customized F10 menus with MOOSE, I found this example on github:

 

-- This demo creates a menu structure for the two groups of planes.

-- Each group will receive a different menu structure.

-- To test, join the planes, then look at the other radio menus (Option F10).

-- Then switch planes and check if the menu is still there.

-- And play with the Add and Remove menu options.

 

-- Note that in multi player, this will only work after the DCS groups bug is solved.

 

local function ShowStatus( PlaneGroup, StatusText, Coalition )

 

MESSAGE:New( Coalition, 15 ):ToRed()

PlaneGroup:Message( StatusText, 15 )

end

 

local MenuStatus = {}

 

local function RemoveStatusMenu( MenuGroup )

local MenuGroupName = MenuGroup:GetName()

MenuStatus[MenuGroupName]:Remove()

end

 

--- @param Wrapper.Group#GROUP MenuGroup

local function AddStatusMenu( MenuGroup )

local MenuGroupName = MenuGroup:GetName()

-- This would create a menu for the red coalition under the MenuCoalitionRed menu object.

MenuStatus[MenuGroupName] = MENU_GROUP:New( MenuGroup, "Status for Planes" )

MENU_GROUP_COMMAND:New( MenuGroup, "Show Status", MenuStatus[MenuGroupName], ShowStatus, MenuGroup, "Status of planes is ok!", "Message to Red Coalition" )

end

 

SCHEDULER:New( nil,

function()

local PlaneGroup = GROUP:FindByName( "Plane 1" )

if PlaneGroup and PlaneGroup:IsAlive() then

local MenuManage = MENU_GROUP:New( PlaneGroup, "Manage Menus" )

MENU_GROUP_COMMAND:New( PlaneGroup, "Add Status Menu Plane 1", MenuManage, AddStatusMenu, PlaneGroup )

MENU_GROUP_COMMAND:New( PlaneGroup, "Remove Status Menu Plane 1", MenuManage, RemoveStatusMenu, PlaneGroup )

end

end, {}, 10, 10 )

 

SCHEDULER:New( nil,

function()

local PlaneGroup = GROUP:FindByName( "Plane 2" )

if PlaneGroup and PlaneGroup:IsAlive() then

local MenuManage = MENU_GROUP:New( PlaneGroup, "Manage Menus" )

MENU_GROUP_COMMAND:New( PlaneGroup, "Add Status Menu Plane 2", MenuManage, AddStatusMenu, PlaneGroup )

MENU_GROUP_COMMAND:New( PlaneGroup, "Remove Status Menu Plane 2", MenuManage, RemoveStatusMenu, PlaneGroup )

end

end, {}, 10, 10 )

 

 

After spending several hours trying to understand it and failing to make it work in my script, this was my conclusion ---> :helpsmilie:

 

I really want to avoid ending up here all the time, asking people to teach me how to do specific things in MOOSE.

I'd love to have the MOOSE menu/command building procedure explained somewhere, so I could just go there and learn on my own :book:.

 

I'm sure many more players would start using MOOSE if this kind of things were explained somewhere, step by step...

I mean, like "First you need to declare this, this and that. Then you have to specify this or that, then you must set a logic in place, etc."

 

Eclipse, the github documentation, the mission example files, flightcontrol YT videos, etc. help quite a bit, but noobs like myself need direction to do pretty much everything.

We live in a state of permanent doubt when scripting and when our scripts don't work (almost always the case) we just go like this --->:crash: :surrender:

[Delta99]

@Hardcard, I don't know what "settings" would be passed to ToGroup() or whether you are setting up some variable based on some example. I would remove it. Don't think it is required. Might be a documentation error OR since it isn't documented I have no clue what it should / would be.

 

I bet if you remove that it will work.

[Habu_69]

@ Hardcard. I also wrestled with adding menu items for hours before I got this code to work. It adds a simple F10 menu item when a scheduled condition = true and removes it when executed. The key is all the stuff you want to trigger by the menu item is contained in the function "reqhelp." The text at the F10 command is "Bandits hot. Request Help." I also have the (optional) timer function for Enfield's response with a 15 sec delay. Hope this helps.

 

 

 

--Initialize MOOSE objects from ME

F18_Grp = GROUP:FindByName( " Player" )

Target_Zone = ZONE:New( "Target" ) 
HelpMsg = " Enfield 3, Colt 1. Request Assistance"
EnfieldResponse = "Colt 1, Enfield 1. Roger, on our way."

 function EnfieldMsg ()     -- Enfield response timer function
   MESSAGE:New( EnfieldResponse, 15, nil ):ToAll()
 end

--  These function commands are executed on F10 item invoke. 
 function ReqHelp()
    MESSAGE:New( HelpMsg, 15, nil ):ToAll()
    trigger.action.setUserFlag( '10', 1 )
    timer.scheduleFunction( EnfieldMsg, {}, timer.getTime() + 15 )  -- Delays Enfield response 15 sec.
    BanditsHot:Remove( 10, nil )   -- Removes the F10 menu item
  end     

MenuScheduler = SCHEDULER:New( nil,   -- F10 menu item scheduler
 function()

   if F18_Grp:IsPartlyInZone( Target_Zone ) then
       BanditsHot = MENU_COALITION_COMMAND:New( coalition.side.BLUE, "Bandits hot. Request Help", nil, ReqHelp )
       MenuScheduler:Stop()
    end

 end, {}, 10, 15 )

[Hardcard]

@Hardcard, I don't know what "settings" would be passed to ToGroup() or whether you are setting up some variable based on some example. I would remove it. Don't think it is required. Might be a documentation error OR since it isn't documented I have no clue what it should / would be.

 

I bet if you remove that it will work.

 

Hi Delta!

 

Sadly, the "settings" parameter doesn't seem to be the problem.

Intellisense adds it automatically when I select the "MESSAGE:ToGroup" function... I think it adds an F10 settings menu that is already included in MOOSE by default (not sure though). Anyway, if I remove it, the problem persists.

 

Just to make sure, you are referring to this, right?:

 Su33AirRefuelingBriefingRed:ToGroup(SochiGroup,[b]Settings)[/b]
Su33Briefingmessage:ToGroup(KuziGroup,[b]Settings[/b])

 

For some reason, the script I wrote only works for the first group being referenced, it ignores instructions for the second group.

I'm probably writing it wrong or just using an invalid logic or whatever.

 

 

 

@Habu__69

 

Wow, thanks a million for that!

 

There are several things in that script that I don't understand, though:

 

1- Function "ReqHelp()" (which includes BanditsHot:Remove) being written on top of the MenuScheduler function (which declares BanditsHot when the player is partly in zone, as I understand it).

 

Shouldn't it be written the other way around? I mean, first declare all the stuff, then execute the functions that use the declared stuff?

 

2- What does "{}" mean ??? I understand it's used to create arrays, right?

Intellisense is telling me that's supposed to be a...function argument?

It's included in timer.scheduleFunction and then repeated at the end...:huh:

 

3- The whole timer.scheduleFunction / menuScheduler thing eludes me.

Why do you need those and what do they do exactly?

 

4- How would I go about turning this script into local instead of global?

 

5- Are zone triggers needed or can this be done without them?

 

6- Where does that "EnfieldMsg" function come from?

 

Please, don't get me wrong! I'm not questioning your scripting style or anything like that, just trying to understand how this all works :shocking:

 

 

Also, could you please attach a simple mission example with that script and all the required triggers in place? I think that would help me figure things out.

(I don't own the F18 module, btw, just FC3, Mi8, Huey, CA and a couple other modules I haven't even installed)

 

Thanks again!

Edited July 5, 2018 by Hardcard

[Habu_69]

@ Hardcard: I am a total coding and MOOSE novice, so I tend to do things by rote and leave a thing alone if it works, until I really understand it.

 

1. The functions, like ReqHelp and EnfieldMsg must be declared BEFORE they are used in a method or the method will be clueless. I included BanditsRemove to delete the F10 command after use to eliminate clutter as, in this case, I would only invoke that F10 command once.

 

2. {} contain function arguments, if any. I really do not understand much about function arguments, so I usually have none.

 

3. The timer function is optional and confusing, but very useful once you understand it. I use it mostly to add a delay to an event. The event (text message EnfieldResponse ToAll) is declared in the function EnfieldMsg and that function is processed 15 sec after the F10 command is activated.

 

4. Make it local by preceding the Variables and functions with "local"

 

5. Trigger zone condition is optional and unnecessary if you don't mind having the F10 command available at mission start.

 

6. EnfieldMsg () declares function in the script for the Message EnfieldResponse and is required only for the timer.scheduleFunction.

 

I am currently involved with F-18 so have no other handy mission examples using the menu method to attach. Maybe later. Do not get discouraged. Having almost no coding experience, MOOSE took me MANY hours to become conversant with, but I found it well worth the effort. Your kind of questions are better addressed on the MOOSE discord channel. You will find more indiviualized help there.

[Hardcard]

@Habu_69

 

Thanks for taking the time to answer in such detail!

 

I've been wrestling with different menu/command script examples these last days and I think all the frustration/cluelessness I've been through is starting to pay off.

I've just written a script that provides custom nested command menus for each plane group, which in turn trigger custom messages and sound files.

 

Tomorrow I'll figure out a way to remove the commands after execution (I hope).

It'll probably take a general overhaul of the script, but I'm feeling confident after today's breakthrough. :v:

 

Once my script is polished and perfected to my satisfaction, I'll probably post it here as an example for desperate people (like myself).

 

Thanks for your help.

 

PS: I joined the MOOSE Discord channel like you suggested, I already got valuable help from Pikes. It seems like a great place to get quick help with specific things and also to learn from what others have done :thumbup:

[funkyfranky]

MOOSE 2.4 pre-release

 

MOOSE Pre-Release 2.4 alpha - Patch 1

 

Hi guys,

 

FlightControl is very busy at the moment with real life stuff. But there have been many improvements of the MOOSE code in the last couple of months. So all the people who contributed, felt that it would be time to share the new developments with you :)

 

For now, this is still a pre-release of 2.4, i.e. there a probably issues which need to be fixed. So if you feel brave and encounter something unusual, feel free to report here, on Discord or on github :smartass:

Of course, you can make our lives much easier, if your report contains all information necessary to reproduce the issue. It's always best to include the whole mission (.miz) file because it contains the most information (moose version, mission script, defined groups, etc). But also relevant excerpts of the dcs.log file are welcome :detective:

 

Download:

Moose.lua files can be downloaded from the github page.

 

Okay, let me try to summarize the new stuff:

 

Firstly, there is a new documentation homepage, which includes the latest changes. Check it out and RTFM ;) It's not perfect but very helpful in many cases.

 

Several new classes have been added. As you can see, most but not all of them are focused on cargo. One thing to point out is, that this MOOSE version supports the new DCS feature of neutral coalitions (c.f. changelog below).

 

CARGO Core Classes

 

CARGO GROUP

Declares a CARGO object that handles a GROUP of infantry or vehicles for cargo handling using the MOOSE cargo handling classes for boarding and unboarding into and from carriers.

 

CARGO CRATE

Declares a CARGO object that handles a STATIC object or cargo object for cargo handling using the MOOSE cargo handling classes for loading and unloading into and from carriers.

 

CARGO SLINGLOAD

Declares a CARGO object that handles a STATIC cargo object for cargo handling using the MOOSE cargo handling classes for sling loading by helicopters.

 

Cargo Handling Classes

 

AI_CARGO_APC

Provides methods for the transportation of cargo by a group of ground vehicles, like APCs, trucks etc.

 

AI_CARGO_HELICOPTER

Provides methods for the transportation of cargo by a group of helicopters.

 

AI_CARGO_AIRPLANE

Provides methods for the transportation of cargo by a group of planes.

 

Cargo Task Dispatching for AI Units

AI_CARGO_DISPATCHER_APC

Orchestrates the AI to transport cargo to deploy locations, by APC groups.

 

AI_CARGO_DISPATCHER_HELICOPTER

Orchestrates the AI to transport cargo to deploy locations, by helicopters.

 

Cargo Tasking for Human Players

TASK_CARGO_TRANSPORT

Orchestrates the tasking of cargo transportation by human players to defined deployment zones.

 

TASK_CARGO_CSAR

Orchestrates the tasking of transportation of downed pilots behind enemy lines.

 

 

Artillery

Can be used to easily assign and manage targets for artillery units.

 

 

Suppression

When ground units get hit by (suppressive) enemy fire, they will not be able to shoot back for a certain amount of time.

 

 

Hope you enjoy :)

FF on behalf of all MOOSE contributors!

 

 

Changelog:

Note that this only contains changes w.r.t. the inital 2.4 alpha pre-release.

 

DATABASE

* Added support for new NEUTRAL coalition DCS feature. Neutral groups (and players) are registered in the MOOSE data base (e.g., neutral groups can be found by GROUP:FindByName()).

 

AIRBASE

* Added Persian Gulf map airport enumerators including Shiraz and Kerman airports.

* Added a lot of convenient wrapper function for new DCS API getparking() function. This enables finding the coordinates of parking spots, explicitly specifying terminal types, check on runway, mark parking spots and many more.

* Added sophisticated find free parking spot routine, which is takes dimension of aircraft etc into account. Also, aircraft are not spawned at places with statics or too close to scenery objects (optional).

* Added parameter of how many parking spots are required in find free parking spots routine.

* FindFreeParking function: Added check that units of a group don't overlap with previous members of the same group.

 

AI_CARGO_DISPATCHER

* APCs and helos will now obey speeds set by SetPickupSpeed() and SetDeploySpeed().

 

DESIGNATE

* Fixed bug when e.g. smoke is fired that made script crash.

 

RAT (v2.3.2)

* Improved how free parking spots are found with the new DCS API function.

* Respawn delay is now used as despawn delay as well. Groups will not get removed immediately after engine shutdown.

* Commute "starshape" option added to preserve home base.

* Added user functions for parking spots, terminal types etc.

* Added return of self for user functions.

* Added check for all units of a group that did not move within a certain time.

* Added new check on runway function and removed old version.

* Changed some default parameter values.

* Removed old RAT parking spot DB routines and old check on runway functions.

* RATMANAGER: Added interval between spawns.

 

ARTY (v1.0.4)

* Added tactical nuclear shells, illumination bombs and smoke shells.

* Added dynamic target/relocation assignment via marks on the F10 map.

* Added small data base with min/max firing ranges of most common artillery group.

* Added possibility to set rearming place and group via marks.

* Fixed bug that coordinates from marks are always at an altitude of five meters ASL.

* Changed behavior that if no arty group is addressed explicitly, nothing is happening. Before all groups were addressed.

* Added cluster and alias assignment via marks.

* Added option to automatically relocate after each engagement.

* Added option to automatically relocate to within firing range.

* Added/fixed relocate option.

* Corrected MISSILE category.

* Added option to not engage an already assigned target.

* Many other changes and bug fixes under the hood.

* Rearming group will not always use 20 km/h = 11 mph.

 

RANGE (v1.2.0)

* Optimized performance. Bombs are now only tracked if the player is within a certain distance of the range.

 

CONTROLLABLE

* Improved TaskGroundOnRoad() function. Optionally, the controllable will take the direct route if the path on road is 10x longer than path on road or path on road is less than 5% of total path.

* Added GetFuelMin and GetFuelAve functions to ensure polymorphic behavior.

* Added speed unit to @param description. Sometimes it was unclear if speed needs to be given in m/s or km/h.

* Fixed some default speed and conversions.

* Fixed bug that ships cannot have another alarm state than green.

 

COORDINATE

* Improved GetPathOnRoad to give the length of the path.

* Added new function to scan for units, statics and scenery around the coordinate.

* Added functions to return the coordinates of the closest (free) parking spot.

* Added power option for illumination bombs.

* Added surface type function.

* Added readonly and text as optional parameters for mark points.

* Added possibility to get coordinate from latitude and longitude given in decimal degrees.

* Added Big smoke and fire effect API functions.

* Cleaned up some speed unit stuff.

* Reintroduced PathOnRoad function to contain the full path. Useful as interface to DCS API function.

* Fixed some default speed and conversions.

 

SPAWN

* Fixed bug in SPAWN:InitHeading(headingmin, headingmax) function.

* Fixed grouping bug in SpawnAtAirbase.

* Fixed spawn on runway bug.

* Added user functions for livery and skill.

* Reworked SpawnAtAirbase() function to use new feature that position of (free) parking spots can be determined.

* Terminal type can now be specified for SpawnAtAirbase().

* If no parking spot is available, units are spawned in air (or not spawned at all).

* Aircraft are despawned when accidentally spawned on runway (should not happen any more anyway).

 

CARGO_GROUP

* Improved UnBoarding so that units of a ground don't get spawned on top of each other if no explicit coordinate is specified.

 

ZONE_UNIT

* Offset option added.

 

TASK_A2G

* Fixed GetAlt() vs. GetY() bug.

 

SET_GROUP

* Fixed bug in SET_GROUP:FindNearestGroupFromPointVec2( PointVec2 ) function. This caused DESIGNATE class to crash (caused critical bug in DESIGNATE class).

 

AI_CARGO_APC

* Included improved route on/off road routine to use improved CONTROLLABLE:TaskGroundOnRoad() function.

* Speed is not fixed any more. Default is set to 50% of the max speed a given unit can move at.

 

AI_CARGO_HELICOPTER

* Speed is not fixed any more at 150 km/h but can be given as input parameter. Default (if no speed is provided) is 50% of max possible speed, the unit type can fly at.

 

AI_A2A, AI_A2A_Patrol and AI_A2A_Dispatcher

* Changed average fuel for controllable to new min fuel function which should provide better RTB behavior for a group > 1 unit.

 

AI_FORMATION

* Fixed comma vs. dot bug.

 

UTILS

* Added clock vs second functions.

* Added function to display mission time.

* Added split function (used in many other classes).

 

DCS

* Updated country.id enumerator to include latest countries available in DCS.

 

MESSAGE

* Added possibility to clear previous messages.

 

ROUTINES

* Fixed MessageToBlue() function sending to red coalition.

 

RADIO

* NewUnitTransmission wrong method call fixed.

[Habu_69]

You guys are doing amazing work!

[fargo007]

You guys are doing amazing work!

 

Preach.

 

 

This is some amazing stuff. I'm trying out suppression right now.

[Dutch Baron]

Awesome work, guys!

Your efforts are not going unnoticed, keep it up!

[unipus]

Getting back into mission design after a long hiatus. Never used MOOSE, but seeing functions I've expected forever in DCS like suppression and effective loading/unloading of infantry certainly makes me take another look!

 

Question on suppression specifically: would there be any way to modify the distribution of time suppressed based on unit skill level? This would model very well to reality and give some good capability to finesse. Of course I say this without knowing the full scope of what is effected by skill level by default!

 

Also, what counts as "hit" for purposes of initiating suppression? Any weapon? Would being on the very edge of the radius of a bomb do it? Or is there some threshold of damage applied that does it?

Edited July 30, 2018 by unipus

[Hardcard]

The whole cargo/artillery management and message clearing functionalities sound sick!

 

I haven't tried this 2.4 pre-release yet, only because I don't know if it's going to be compatible with MOOSE 2.3.1 based scripts/missions.

 

Is there a specific procedure in order to update MOOSE or it's simply a matter of replacing Moose.lua both in Eclipse and ME?

 

Btw, I watched a FlightControl MOOSE video on YT where Sven mentioned that there's some kind of update functionality built within MOOSE. Is that still a thing or should I ignore it?

 

Thanks!

Edited July 31, 2018 by Hardcard

[Delta99]

The whole cargo/artillery management and message clearing functionalities sound sick!

 

I haven't tried this 2.4 pre-release yet, only because I don't know if it's going to be compatible with MOOSE 2.3.1 based scripts/missions.

 

Is there a specific procedure in order to update MOOSE or it's simply a matter of replacing Moose.lua both in Eclipse and ME?

 

Btw, I watched a FlightControl MOOSE video on YT where Sven mentioned that there's some kind of update functionality built within MOOSE. Is that still a thing or should I ignore it?

 

Thanks!

 

The arty and cargo handling is amazing. I will post a playlist of video's that I've released on a mission I've been working on using both and other Moose functions of course.

 

2.4 pre-release should mostly be backwards compatible with Moose 2.3.1. The best thing to do is trying replacing it and just test your mission. Check the dcs.log and your mission carefully. Just make sure to keep 2.3.1 around so you can revert back if something is not working. If something is NOT working report it on the GitHub issues list and someone will look into it.

[Delta99]

Here is a playlist of some videos where I am play testing a mission I am working on primarily using the new MOOSE Arty and Cargo handling functionality. The idea is that AI helicopters will ferry troops to various LZ's around a town and the infantry will attack the town.

 

You can fly CAS in a Huey or A10C as well as provide artillery support (mortars, smoke, illumination rounds).

 

Playlist: