MOOSE - Mission Object Oriented Scripting Framework

Oh! I didn't know sorry. I deactivated the trace and now its working fine!!

 

Thanks.

You may want to have a closer look at this...

For your enjoyment... A next level of detail in the task dispatching mechanism...

Great efford!

 

Sadly, I have to find the time to dive into MOOSE, yet, but it is looking really sophisticated. So this leaves me with a more general question: how customizable are all the communication messages - i.e. from the command center or the task dispatchers? Two points I have in mind here in particular: 1. does the comms utilize the aircraft's radios or is it all done by MESSAGE TO xxx? I'd love to see missions with "realistic" comms reqirements - like, if you have dialled in the wrong frequency, you won't hear the task dispatcher and thus you will be of no help to the war ... ;-)

 

The other point is, aside from the debugging output, the tasking messages look somewhat "technical". Efficient, but maybe not too realistic in terms of how the real communication would go. Can the wording of those messages be customized in some way?

The comms is currently just messages, which is already a challenge in its own to get it all orchestrated. However, one of our community members is working on new radio classes that will be embedded in the framework very soon. Once this is done, we can start working on incorporating the radio into the message system, which will then result in additional configuration options for players to tune in at certain frequences for certain mission / tasks etc.

On the form of the messages, yes, they look a bit complicated, but just bare in mind that the system is designed for multiple players flying together multiple tasks in different groups and together in one group. The messages are targetted to only those groups who should receive it. When you join our moose community on slack.com, we can further discuss your requirement and how to optimize it to user feedback.

kind regards,

Sven

However, one of our community members is working on new radio classes that will be embedded in the framework very soon.

RADIO is coming soon, I swear :)

[EDIT]

To be more specific, the RADIO class implementation is at its core a wrapper for DCS' "TransmitMessage" command and the singleton function trigger.action.radioTransmission(). The first goal is to make a radio transmission as easy as

BatumiRadio = STATIC:FindByName("Batumi Tower"):GetRadio()
BatumiRadio:NewGenericTransmission("YourSoundFile.ogg", 115, radio.modulation.AM, 100)
BatumiRadio:Broadcast()

When this is done (and I'm on the final steps, the code is written and tested, I'm now working on documentation), I'll be working on implementing a BEACON class to wrap DCS' Command "ActivateBeacon". That should keep me occupied for a while.

I am aware that there is a demand to make tasks and command centers use some sort of radio communication (@Flagrum : You're not alone !), and it's on my todo list if nobody gets around to do that before I do. But I really want to finish BEACON first, it looks very promising and seems like it would allow the mission designer to do some very cool stuff !

[/EDIT]

I've made a mission with TASK_A2G_DISPATCHER with area reports. It all works fine but after about 20 minutes of playing the reports stop appearing, the tasks remain in the mission menu (F10) but the reports don't appear anymore.

I have groups randomly respawning, is it possible that the ammount of groups detected are so many (i think it detected 8 areas) that is preventing the reports to keep showing?

I've made a mission with TASK_A2G_DISPATCHER with area reports. It all works fine but after about 20 minutes of playing the reports stop appearing, the tasks remain in the mission menu (F10) but the reports don't appear anymore.

 

I have groups randomly respawning, is it possible that the ammount of groups detected are so many (i think it detected 8 areas) that is preventing the reports to keep showing?

cool! They're must be a glitch. One of many probably. But i am not going to resolve this discussion here on the forums for such a complex subject and development. Please send me your email as a private message on this forum so i can get you on slack and we can share much better information and communicate better.

The RadioComs Branch has officially been merged, which adds a radio communication feature.

Concretely, you can attach a RADIO to any POSITIONABLE and use the methods in RADIO to broadcast your radio transmission.

For example, in vanilla DCS, a Unit switching freqency to 115AM and then transmitting "Noise.ogg" looked like that :

Unit.getByName("myUnit"):getController():setCommand({ 
           id = "SetFrequency", 
           params = {
               frequency = 115000000, 
               modulation = radio.modulation.AM,
               } 
           })

Unit.getByName("myUnit"):getController():setCommand({ 
           id = "TransmitMessage", 
           params = {
               file = "Noise.ogg",
               duration = 0,
               subtitle = "",
               loop = false,
               } 
           })

In MOOSE, it now looks like this :

local UnitRadio = UNIT.FindByName("myUnit"):GetRadio()
UnitRadio:SetFileName("Noise.ogg"):SetFrequency(115):SetModulation(radio.modulation.AM)
UnitRadio:Broadcast()

Please read the full documentation of the RADIO class here http://flightcontrol-master.github.io/MOOSE/Documentation/Radio.html

I'm really unfamiliar with MOOSE, I've just started reading into it, and watching the (very helpful) videos.

If I had an AI CAP setup and happily patrolling a zone, how difficult would it be to redirect that flight for a different mission? IE: a GCI. Or can the AI's 'detection' be extended by the ground radar?

Is this easy, simple, and built into MOOSE? A little head scratching? Or face plant and give up if I don't really understand the depth what I'm doing.

I've written a couple of LUA scripts, one-offs for a few missions, maybe totaling a few thousand lines.

I'm really unfamiliar with MOOSE, I've just started reading into it, and watching the (very helpful) videos.

 

If I had an AI CAP setup and happily patrolling a zone, how difficult would it be to redirect that flight for a different mission? IE: a GCI. Or can the AI's 'detection' be extended by the ground radar?

 

Is this easy, simple, and built into MOOSE? A little head scratching? Or face plant and give up if I don't really understand the depth what I'm doing.

 

I've written a couple of LUA scripts, one-offs for a few missions, maybe totaling a few thousand lines.

drop me a pm

Hey Sven,

Seems like currently the missile training script is removing all weapons from the simulator, not only the A/A ones, but also A/G.

Just getting my head around MOOSE, this might be a simple one. I'm looking to respawn selected groups based on the number of units left in the group. The intent is to have a 'perpetual' mission.

Ultimately, I'd like a number of groups which spawn in random locations around the map, then travel on randomised routes. These two functions I can get to work. What I'd like to be able to do is respawn one of these groups when say 90% of it's units have been destroyed. Or alternatively, have the group respawn after all the units have been destroyed, after a delay.

Just getting my head around MOOSE, this might be a simple one. I'm looking to respawn selected groups based on the number of units left in the group. The intent is to have a 'perpetual' mission.

 

Ultimately, I'd like a number of groups which spawn in random locations around the map, then travel on randomised routes. These two functions I can get to work. What I'd like to be able to do is respawn one of these groups when say 90% of it's units have been destroyed. Or alternatively, have the group respawn after all the units have been destroyed, after a delay.

You can do:

SPAWN:NewWithAlias(SpawnTemplatePrefix,SpawnAliasPrefix):InitLimit(SpawnMaxUnitsAlive,SpawnMaxGroups):InitRandomizeRoute(SpawnStartPoint,SpawnEndPoint,SpawnRadius,SpawnHeight):SpawnScheduled(SpawnTime,SpawnTimeVariation)

SpawnTemplatePrefix is the group used in the ME set with waypoints

SpawnMaxUnitsAlive is the maximum units that can be alive at the same time (it will not spawn any more groups if the quantity is above this number)

SpawnMaxGroups is tha maximum quantity of froup spawns (you can set it to 100 or more for a semi infinite spawn)

SpawnStartPoint is the first waypoint to begin the randomization

SpawnEndPoint is the last waypoint COUNTING BACKWARDS (0 will be the last waypoint)

SpawnRadius the radius in meters to randomize each waypoint

SpawnHeight is otional is the randomized addition of altitude in meters

SpawnTime is the time it will take to spawn a new group

FlightControl, AMAZING WORK!

I've read lots of documentations and tested lots of missions from MOOSE and seems fantastic, plus, i subscribed your yt channel.

I din't managed yet how to clearly work with moose, but it's a matter of time, there's too many options and scripts that a i get a little confused. (I'm not LUA fammiliar yet)...

So, i would like to have some light if possible.

I'm trying to keep planes (groups) in the air patrolling all the time.

So, when it crashes or landing it should respawn (in a couple of minutes), to keep skyes populated 24/7.

I used some parts of codes and did the Following:

-Grp Blu

AgrAz4 = SPAWN:New("AgrAz4"):InitLimit( 2, 0 )

AgrAz4:HandleEvent( EVENTS.Crash )

AgrAz4:SpawnScheduled(60,0)

AgrAz4:InitRepeatOnLanding()

function AgrAz4:OnEventCrash( EventData )

AgrAz4:SpawnScheduled(10,0)

end

 

-- Grp Red

AgrVm1 = SPAWN:New("AgrVm1"):InitLimit( 2, 0 )

AgrVm1:HandleEvent( EVENTS.Crash )

AgrVm1:SpawnScheduled(60,0)

AgrVm1:InitRepeatOnLanding()

function AgrVm1:OnEventCrash( EventData )

AgrVm1:SpawnScheduled(10,0)

end

The code above worked, but they first spawn at same time, i would like to be able to spanw they in a randon period let's say inside 5 minutes, to make the encounters more aleatory, but i didn't managed to change this behavior.

SpawnScheduled(60,0) second 0 is for the randomisation. .5 means from 30-90 seconds (50% +/-)

If you want to delay the inital spawn - it's already in github as a feature request - you coudl use the scheduler around it, there's some example scripts of scheduler spawning things in slowly in several of the missions.

FlightControl, AMAZING WORK!

I've read lots of documentations and tested lots of missions from MOOSE and seems fantastic, plus, i subscribed your yt channel.

I din't managed yet how to clearly work with moose, but it's a matter of time, there's too many options and scripts that a i get a little confused. (I'm not LUA fammiliar yet)...

 

So, i would like to have some light if possible.

 

I'm trying to keep planes (groups) in the air patrolling all the time.

So, when it crashes or landing it should respawn (in a couple of minutes), to keep skyes populated 24/7.

 

I used some parts of codes and did the Following:

 

 

 

 

The code above worked, but they first spawn at same time, i would like to be able to spanw they in a randon period let's say inside 5 minutes, to make the encounters more aleatory, but i didn't managed to change this behavior.

Hi. They're is an open issue on this item on our GitHub site. It will be incorporated in release 2.1, but you'll be able to use it when beta testing.

You know about our moose community on slack?

Hey Sven,

Seems like currently the missile training script is removing all weapons from the simulator, not only the A/A ones, but also A/G.

We'll check it with the 132nd team. Thanks. Been a while since i saw you on slack :-)

Hi everyone !

It's been worked on for the past few weeks, but we are now ready to announce it : Moose-2.0 is out !

Here is a small explanation of the changes. You are highly encouraged to RTFM here : http://flightcontrol-master.github.io/MOOSE/, as well as :

• For the mission designer : http://flightcontrol-master.github.io/MOOSE/Usage_Guide.html
  
• For the tester : http://flightcontrol-master.github.io/MOOSE/Beta_Test_Guide.html
  
• For the contributor (or the curious ;) ) : http://flightcontrol-master.github.io/MOOSE/Contribution_Guide.html
  

Release process :

• We are now releasing a stable version of Moose as regularly as possible.
  
• You can grab the latest Release from here : https://github.com/FlightControl-Master/MOOSE/releases, no need to use GitHub Desktop anymore
  

Setup and update :

• If you are already a Moose user and want to use the latest Release, you can ditch your local Moose repository as well as GitHub desktop, and simply download the latest release (link above). In your missions, load the Moose.lua that comes in the download.
  
• If you are already a Moose user (i.e. already installed GitHub, LDT, and have a local Moose repository) and still want to access the latest bleeding edge features of Moose, then you need to setup a Tester environment. First, install 7-Zip (requirement) if you don't already have it, then use the automated process; Sync the repo, then browse to MOOSE/Moose Development Environment Setup/ and start MooseDevelopmentEnvironmentSetup.exe as an administrator. Input the location of the folders it asks for, and let it do its magic. Now, in your missions, you should load the Moose.lua that is in DCS World/Scripts/Moose/. More information about the setup of a tester environment and the MDES tool here.
  
• If you are new to Moose, then the doc is your best friend.
  

Repository :

• The repository has been cleaned up, and the test missions are now available here for the latest stable Moose Release : https://github.com/FlightControl-Master/MOOSE_MISSIONS/releases
  
• If you are using GitHub (Testers), then access the latest updates to test missions by cloning the MOOSE_MISSIONS repository, and switching to the release branch
  

Features :

• If you have been syncing your Moose local repository regularly, then there shouldn't be anything new.
  
• The huge news is that Moose-2.0 is as stable bug-free as possible ! We spent the last weeks cleaning up the code and fixing up the bugs in preparation of this release !
  

Why did you have to change everything ? It was just fine before !

The simple answer is that the way Moose was released had some not-so-subtle drawbacks for everyone involved.

The truth is that MOOSE development is fast paced in will stay this way, which introduced some problems :

• Instabilities for the mission designer
  
• The need for the mission designer to use GitHub Desktop.
  
• The contributors needed to generate a static version of moose before any pull request to the master, which is a source of errors and confusions
  
• The test misisons don't version control well, and it was a pain to maintain them with Moose static loading.
  
• The testers workflow was really complex and undocumented, meaning that testing a regularly updated Moose was a pain.
  

We felt like the end user and the contributors shouldn't have to deal with either of those problems. That's why we changed the release plan.

Although we tried to make this change as smooth as possible, any change this huge is bound to raise issues or at least question. We will try to be as available as possible to swiftly answer your questions, on this topic or on slack.

In the name of every MOOSE Contributor and Tester, we wish you happy mission designing with MOOSE-2.0 !

EDIT : This is only relevant for TESTERS : The .lauch files (the automated tools to manage .miz files, in LDT->Run->External tools) won't work for now. We are working on a fix that will come ASAP. Sorry for the inconvenience and thank you for your patience. Note that the rest (dynamic loading) is working !

Installation Documentation

We've updated (today) in great detail the installation documentation to use the Moose Framework. For those interested, consult the Moose Framework main page for more details.

Moose Main Page:

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

Moose Usage Guide:

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

Moose Beta Test Guide:

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

Moose Contributor Guide:

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

Moose Community Guide:

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

For normal users, suggest you have a thorough read through the tsage guide. If you have questions, please let us know you concerns so we can help you. Thank you.

FC

Setup Videos

Redoing the setup and configuration videos on YouTube.

Check this playlist:

It contains how the release process works, how to configure the lua editor, where and how to download and install the moose demonstration missions in ldt, and how to build your first mission using the moose framework. Especially video #4 will be of great helo for many!

All is explained in much detail while showing what to do.

Good luck and ENJOY!

Sven

Sven, this is really brilliant!

I am just getting into MOOSE and is has been a steep learning curve in the first couple of days. However, your videos help a lot. So meanwhile things fall into place. And what I see is just awesome! So much more fun to create missions than with the ME.

Keep up the good work! It is much appreciated :thumbup:

MOOSE Release 2.1.0

Finally it is here, release 2.1.0 of MOOSE!

It took some time to prepare this release, as it was a lot of work to get the building blocks of the framework developed and tested. You'll find in this release a lot of new features as well as a couple of important bug fixes.

Release 2.1.0 is now published into the master-release-2.1 branch of the MOOSE repository on github: Release 2.1.0.

You can download the file moose.lua to use MOOSE and include it in your missions.

Those who are using the master branch can continue to beta test, as new bleeding edge features will be added soon in preparation for release 2.2.0! There are many topics on the agenda to be added.

This release would not have been possible without the help and contribution of many members of this community. THANK YOU!

In summary:

This release brings you an improved tasking mechanism.

Tasking is the system in MOOSE that allows to:

* Execute co-op missions and tasks

* Detect targets dynamically

* Define new tasks dynamically

* Execute the tasks

* Complete the mission goals

* Extensive menu system and briefings/reports for player interaction

* Improved Scoring of mission goal achievements, and task achievements.

On top, release brings you new functionality by the introduction of new classes to:

* Designate targets (lase, smoke or illuminate targets) by AI, assisting your attack. Allows to drop laser guides bombs.

* A new tasking system to transport cargo of various types

* Dynamically spawn static objects

* Improved coordinate system

* Build large formations, like bombers flying to a target area

1. TASKING SYSTEM!

A lot of work has been done in improving the tasking framework within MOOSE.

**The tasking system comes with TASK DISPATCHING mechanisms, that DYNAMICALLY

allocate new tasks based on the tactical or strategical situation in the mission!!!

These tasks can then be engaged upon by the players!!!**

The TASK_A2G_DISPATCHER class implements the dynamic dispatching of tasks upon groups of detected units determined a Set of FAC (groups). The FAC will detect units, will group them, and will dispatch Tasks to groups of players. Depending on the type of target detected, different tasks will be dispatched. Find a summary below describing for which situation a task type is created:

* CAS Task: Is created when there are enemy ground units within range of the FAC, while there are friendly units in the FAC perimeter.

* BAI Task: Is created when there are enemy ground units within range of the FAC, while there are NO other friendly units within the FAC perimeter.

* SEAD Task: Is created when there are enemy ground units wihtin range of the FAC, with air search radars.

More TASK_... dispatcher classes are to come in the future, like A2A, G2G, etc...

Improvements on the TASKING are in summary:

* A COMMANDCENTER has a dedicated menu.

* A MISSION has a dedicated menu system.

* A MISSION has a briefing report.

* A MISSION has dedicated status reports.

* A MISSION has for each TASK TYPE a menu.

* A MISSION has for each TASK TYPE a dedicated menu system for each TASK defined.

* A MISSION has an "assigned" task menu that contains menu actions relevant to the assigned task.

* A TASK (of various types) has a dedicated menu system.

* A TASK has a briefing report.

* A TASK has dedicated status reports.

* Player reports can be retrieved that explain which player is at which task.

* ...

TASKING is vast, and at the moment there is too much to explain.

The best way to explore the TASKING is to TRY it...

I suggest you have a look at the

Many people have contributed in the testing of the mechanism, especially:

@baluballa, @doom, @whiplash

2. New MOOSE classes have been added.

MOOSE 2.1.0 comes with new classes that extends the functionality of the MOOSE framework and allow you to do new things in your missions:

2.1. Target designation by laser, smoke or illumination.

DESIGNATE is orchestrating the designation of potential targets executed by a Recce group,

and communicates these to a dedicated attacking group of players,

so that following a dynamically generated menu system,

each detected set of potential targets can be lased or smoked...

Targets can be:

* Lased for a period of time.

* Smoked. Artillery or airplanes with Illuminatino ordonance need to be present. (WIP, but early demo ready.)

* Illuminated through an illumination bomb. Artillery or airplanes with Illuminatino ordonance need to be present. (WIP, but early demo ready.

This class was made with the help of EasyEB and many others.

DESIGNATE demonstration missions:

* DES - Designation

2.2. Transport cargo of different types to various locations as a human task within a mission.

The Moose framework provides various CARGO classes that allow DCS physical or logical objects to be transported or sling loaded by Carriers.

The CARGO_ classes, as part of the moose core, are able to Board, Load, UnBoard and UnLoad cargo between Carrier units.

This collection of classes in this module define tasks for human players to handle these cargo objects.

Cargo can be transported, picked-up, deployed and sling-loaded from and to other places.

TASK_CARGO_TRANSPORT defines a task for a human player to transport a set of cargo between various zones.

It is the first class that forms part of the TASK_CARGO classes suite.

The TASK_CARGO classes provide you with a flexible tasking sytem,

that allows you to transport cargo of various types between various locations

and various dedicated deployment zones.

A human player can join the battle field in a client airborne slot or a ground vehicle within the CA module (ALT-J).

The player needs to accept the task from the task overview list within the mission, using the radio menus.

Once the TASK_CARGO_TRANSPORT is assigned to the player and accepted by the player, the player will obtain

an extra Cargo Handling Radio Menu that contains the CARGO objects that need to be transported.

Cargo can be transported towards different Deployment Zones, but can also be deployed anywhere within the battle field.

The Cargo Handling Radio Menu system allows to execute various actions to handle the cargo.

In the menu, you'll find for each CARGO, that is part of the scope of the task, various actions that can be completed.

Depending on the location of your Carrier unit, the menu options will vary.

The CARGO_GROUP class defines a

cargo that is represented by a GROUP object within the simulator, and can be transported by a carrier.

The CARGO_UNIT class defines a

cargo that is represented by a UNIT object within the simulator, and can be transported by a carrier.

Mission designers can use the SET_CARGO

class to build sets of cargos.

Note 1: Various other CARGO classes are defined and are WIP.

Now that the foundation for Cargo handling is getting form, future releases will bring other types of CARGO handling

classes to the MOOSE framework quickly. Sling-loading, package, beacon and other types of CARGO will be released soon.

Note 2: AI_CARGO has been renamed to CARGO and now forms part of the Core or MOOSE.

If you were using AI_CARGO in your missions, please rename AI_CARGO with CARGO...

TASK_TRANSPORT_CARGO is demonstrated at the

TASK_TRANSPORT_CARGO demonstration missions:

* TSK-110 - Ground - Transport Cargo Group

* TSK-210 - Helicopter - Transport Cargo Group

* TSK-211 - Helicopter - Transport Multiple Cargo Groups

* TSK-212 - Helicopter - Cargo handle PickedUp and Deployed events

* TSK-213 - Helicopter - Cargo Group Destroyed

2.3. Dynamically spawn STATIC objects into your mission.

The SPAWNSTATIC class allows to spawn dynamically new Statics.

By creating a copy of an existing static object template as defined in the Mission Editor (ME), SPAWNSTATIC can retireve the properties of the defined static object template (like type, category etc), and "copy" these properties to create a new static object and place it at the desired coordinate.

New spawned Statics get the same name as the name of the template Static, or gets the given name when a new name is provided at the Spawn method.

SPAWNSTATIC demonstration missions:

* SPS-100 - Simple Spawning

2.4. Better coordinate management in MGRS or LLor LLDecimal.

The COORDINATE class

defines a 2D coordinate in the simulator. A COORDINATE can be expressed in LL or in MGRS.

2.5. Improved scoring system

Scoring is implemented throught the SCORING class.

The scoring system has been improved a lot! Now, the scoring is correctly counting scores on normal units, statics and scenary objects.

Specific scores can be registered for specific targets. The scoring works together with the tasking system, so players can achieve

additional scores when they achieve goals!

SCORING demonstration missions:

* SCO-100 - Scoring of Statics

* SCO-101 - Scoring Client to Client

* SCO-500 - Scoring Multi Player Demo Mission 1

2.6. Beacons and Radio

The Radio contains 2 classes : RADIO and BEACON

What are radio communications in DCS ?

* Radio transmissions consist of sound files that are broadcasted on a specific frequency (e.g. 115MHz) and modulation (e.g. AM),

* They can be subtitled for a specific duration, the power in Watts of the transmiter's antenna can be set, and the transmission can be looped.

These classes are the work of @Grey-Echo.

RADIO and BEACON demonstration missions:

* RAD-000 - Transmission from Static

* RAD-001 - Transmission from UNIT or GROUP

* RAD-002 - Transmission Tips and Tricks

* RAD-010 - Beacons

2.7. Build large formations of AI.

AI_FORMATION makes AI @{GROUP}s fly in formation of various compositions.

The AI_FORMATION class models formations in a different manner than the internal DCS formation logic!!!

The purpose of the class is to:

* Make formation building a process that can be managed while in flight, rather than a task.

* Human players can guide formations, consisting of larget planes.

* Build large formations (like a large bomber field).

* Form formations that DCS does not support off the shelve.

AI_FORMATION Demo Missions: FOR - AI Group Formation

AI_FORMATION demonstration missions:

* FOR-100 - Bomber Left Line Formation

* FOR-101 - Bomber Right Line Formation

* FOR-102 - Bomber Left Wing Formation

* FOR-103 - Bomber Right Wing Formation

* FOR-104 - Bomber Center Wing Formation

* FOR-105 - Bomber Trail Formation

* FOR-106 - Bomber Box Formation

Note: The AI_FORMATION is currently a first version showing the potential, a "building block". From this class, further classes will be derived and the class will be fine-tuned.

3. A lot of components have been reworked and bugs have been fixed.

3.1. Better event handling and event dispatching.

The underlying mechanisms to handle DCS events has been improved. Bugs have been fixed.

The MISSION_END event is now also supported.

3.2. Cargo handling has been made much better now.

As a result, some of the WIP cargo classes that were defined earlier are still WIP.

But as mentioned earlier, new CARGO classes can be published faster now.

The framework is now more consistent internally.

3.3. New methods have been added. Please check the release notes here.

We hope that you will enjoy this new release.

Any feedback please post here in this forum.

Thank you very much!

Just published MOOSE Release 2.1.4, a couple of bug fixes have been done.

If somebody is experiencing strange things while testing Normandy, designing and running test mission using moose, would you be so kind to post here your issues or findings? Positive news is also feedback.

Hello, FC,

I am setting up MOOSE in order to run and edit scripts within the game. A quick question about setting up new project names - my preference is to use spaces and not underscores, like "Mission Template v20N", instead of "Mission_Template_v20N". Will there be a problem with that convention? It does not seem to be an issue...

I am looking forward to making this work - it will save me tons of time with my scripting.

WC

Hello, FC,

I am setting up MOOSE in order to run and edit scripts within the game. A quick question about setting up new project names - my preference is to use spaces and not underscores, like "Mission Template v20N", instead of "Mission_Template_v20N". Will there be a problem with that convention? It does not seem to be an issue...

 

I am looking forward to making this work - it will save me tons of time with my scripting.

 

WC

Hi Sir!

First of all thank you for your interest in the framework!

Regarding your question, I don't think this will be a problem, no.

If it is, please tell us.

Also, you are kindly invited to join our community at slack.com.

It is free, open and also professional in the sense that we are jointly communicating and providing feedback on how to improve the framework...

We also have a joint GITHUB site where we log issues and do joint fixes in pull requests.

If you wanna join, please do, but you'll have to send me (private message) an email address to where i can send you an invitation to join the slack platform. Slack only allows you to join through an invitation by email.

I encourage you do. It will save you a lot of time and you'll be able to meet the other kind members.

Sven