Jump to content

MOOSE - Mission Object Oriented Scripting Framework


Recommended Posts

Great to hear @Tiramisu. Moose has a steep learning curve so it will take time. That is also why there are a lot of demo missions. But learning the basics will certainly help in the long.

 

If you haven't already, join us on Discord. You'll find a lot more people there helping each other. Should be a link in the OP.

 

Thanks for this link! I have found a very helpful example there called GRP-100 - TaskAttackUnit.lua. Based on that example I changed my code and it seems like it also works, so I do not have to use the basic API from DCS any more:

 

 

local Mig21Group = GROUP:FindByName( "Iranian Mig 21s#001" )
local PlayerGroup = GROUP:FindByName( "Player Group" )

local AttackUnits = PlayerGroup:GetUnits()

local Tasks = {}

for i = 1, #AttackUnits do

 local AttackUnit = PlayerGroup:GetUnit( i )
 Tasks[#Tasks+1] = Mig21Group:TaskAttackUnit( AttackUnit )
end

Tasks[#Tasks+1] = Mig21Group:TaskFunction( "_Resume", { "''" } )

--- @param Wrapper.Group#GROUP HeliGroup
function _Resume( HeliGroup )
 env.info( '_Resume' )

 Mig21Group:MessageToAll( "Resuming",10,"Info")
end

Mig21Group:PushTask( Mig21Group:TaskCombo(Tasks), 30 )

 

 

 

I have found that site already, but for some reason I am not able to understand this kind of documentation. So I am learning from actual examples instead.

Link to comment
Share on other sites

For some reason I cant get units to attack with TaskAttack for some reason. I was originally trying to get a CAS aircraft to bomb a static object but after further testing I cant even get them to attack other units. I don't remember ever having this issue. Any ideas?

 

trigger.action.outTextForCoalition(coalition.side.BLUE, string.format("Test 1", 11), 20)
Grp = GROUP:FindByName( "T11" )
Unit = UNIT:FindByName( "U1" )
trigger.action.outTextForCoalition(coalition.side.BLUE, string.format("Test 2", 11), 20)
Grp:TaskAttackUnit(Unit)
trigger.action.outTextForCoalition(coalition.side.BLUE, string.format("Test 3", 11), 20)

Link to comment
Share on other sites

@A Hamburgler

 

There are several problems involved as far as I can tell.

 

First off, this will only define the task, it won't execute it:

Grp:TaskAttackUnit(Unit)

 

In order to execute it, you'll need to store that task in a variable and then set/push it:

GrpTask = Grp:TaskAttackUnit(Unit)
Grp:PushTask(GrpTask)

[color="Blue"]--OR[/color]

GrpTask = Grp:TaskAttackUnit(Unit)
Grp:SetTask(GrpTask) 

 

Unfortunately, that only seems to solve half of the problem.

 

The other half is that :TaskAttackUnit() and :TaskAttackGroup() don't seem to work.

 

EDIT: After more testing, I've concluded that :TaskAttackUnit() and :TaskAttackGroup() work, but only if the attacking group has one of the following roles assigned in ME:

CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip

 

From what I've seen, CAS seems like the best option, since it can be used for both air and ground targets.

 

In any case, I wouldn't use :TaskAttackUnit() or :TaskAttackGroup() if I were you, there are better / more practical ways of handling AI behaviour (ROE, Alarm states, zone detection, etc).

 

Btw, if someone can provide an explanation of why :TaskAttackUnit() and :TaskAttackGroup() only seem to work when specific roles are provided in ME, I'll be grateful!


Edited by Hardcard
Link to comment
Share on other sites

@A Hamburgler

 

There are several problems involved as far as I can tell.

 

First off, this will only define the task, it won't execute it:

Grp:TaskAttackUnit(Unit)

In order to execute it, you'll need to store that task in a variable and then set/push it:

GrpTask = Grp:TaskAttackUnit(Unit)
Grp:PushTask(GrpTask)

[color=Blue]--OR[/color]

GrpTask = Grp:TaskAttackUnit(Unit)
Grp:SetTask(GrpTask) 

Unfortunately, that only seems to solve half of the problem.

 

The other half is that :TaskAttackUnit() and :TaskAttackGroup() don't seem to work.

 

EDIT: After more testing, I've concluded that :TaskAttackUnit() and :TaskAttackGroup() work, but only if the attacking group has one of the following roles assigned in ME:

CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip

 

From what I've seen, CAS seems like the best option, since it can be used for both air and ground targets.

 

In any case, I wouldn't use :TaskAttackUnit() or :TaskAttackGroup() if I were you, there are better / more practical ways of handling AI behaviour (ROE, Alarm states, zone detection, etc).

 

Btw, if someone can provide an explanation of why :TaskAttackUnit() and :TaskAttackGroup() only seem to work when specific roles are provided in ME, I'll be grateful!

 

 

Indeed. I can explain. try to model a task to attack a unit, using the pure mission editor, using a role Transport ...

It is modelled like this in DCS. No other way.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Indeed. I can explain. try to model a task to attack a unit, using the pure mission editor, using a role Transport ...

It is modelled like this in DCS. No other way.

 

Hi Sven!

 

Yes, I already tried that during my tests and noticed that it didn't work, same happened with "Reconnaissance" and "Nothing" roles.

At first I had assumed that scripted tasks worked independently from ME roles, but looks like this isn't the case.

 

After several hours of tweaking and testing, I noticed that setting AI roles to CAP, CAS, etc. allowed them to attack (problem then was that I didn't know whether it was my script handling the AI behaviour).

 

Then, I checked the Hoggit Wiki documentation and found this:

Available Under: CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip

 

So I concluded that :TaskAttackUnit() and :TaskAttackGroup() were linked to ME roles.

 

Finally, I restricted :TaskAttackGroup() in my test mission to a moving zone, in order to see whether the AI was actually following scripted behaviour... turns out that it was!

 

Thanks for confirming it! :thumbup:

 

PS. Would it be possible to note this in the MOOSE documentation / intellisense? I think that would help prevent confusion.


Edited by Hardcard
Link to comment
Share on other sites

@Silvern

 

It's linked at the bottom of the post you quoted earlier.

 

 

Thank you! This will be invaluable with the HARM!

Default SAM AI is non-existent.

 

 

 

On a separate note, did anyone ever try to make an A2G dispatching script?

Something that would work similarly to A2A dispatcher, but instead of air targets the patrolling planes would attack the ground targets?

Link to comment
Share on other sites

Hi Sven!

 

Yes, I already tried that during my tests and noticed that it didn't work, same happened with "Reconnaissance" and "Nothing" roles.

At first I had assumed that scripted tasks worked independently from ME roles, but looks like this isn't the case.

 

After several hours of tweaking and testing, I noticed that setting AI roles to CAP, CAS, etc. allowed them to attack (problem then was that I didn't know whether it was my script handling the AI behaviour).

 

Then, I checked the Hoggit Wiki documentation and found this:

Available Under: CAS, CAP, Fighter Sweep, Intercept, SEAD, AntiShip

 

So I concluded that :TaskAttackUnit() and :TaskAttackGroup() were linked to ME roles.

 

Finally, I restricted :TaskAttackGroup() in my test mission to a moving zone, in order to see whether the AI was actually following scripted behaviour... turns out that it was!

 

Thanks for confirming it! :thumbup:

 

PS. Would it be possible to note this in the MOOSE documentation / intellisense? I think that would help prevent confusion.

 

This is NOT the case according to Grimes as far as I remember discussing with him or reading in Discord or the forums. I can't find the reference. When you select CAS or CAP for example in the editor this sets up Enroute Tasks in the advanced waypoints for you. That is why it APPEARS to be working for you. I'll bet if you remove those in your mission you will see it is the same behaviour.

 

So your test likely isn't proving anything unless you removed those enroute tasks in the editor.

 

The Tasks likely are not working in Moose due to other issues like the unit not being seen and the task being thrown away or for other reasons the AI throwing the task away. I think tasks are supposed to happen immediately but the AI has decision processes it will go through and for whatever reason, if it thinks perhaps that task can't be accomplished OR there are better things to do, it probably throws it away.

 

The editor ROLE option is strictly there to just limit followup selections.

 

I would suggest to use EnrouteTasks because they stick around are work way better.

Link to comment
Share on other sites

This is NOT the case according to Grimes as far as I remember discussing with him or reading in Discord or the forums. I can't find the reference. When you select CAS or CAP for example in the editor this sets up Enroute Tasks in the advanced waypoints for you. That is why it APPEARS to be working for you. I'll bet if you remove those in your mission you will see it is the same behaviour.

 

So your test likely isn't proving anything unless you removed those enroute tasks in the editor.

 

Hi Delta99!

 

As I already mentioned in our previous Discord conversation about this, the scripts worked all the same with or without the advanced waypoint actions you are referring to.

 

Script 1:

local Attacker = GROUP:FindByName("Name of the attacker group in ME")
local Target = GROUP:FindByName("Name of the target group in ME")

local AttackTask = Attacker:TaskAttackGroup(Target)
Attacker:PushTask(AttackTask)

 

 

Script 2 (zone restricted behaviour test):

local Attacker = GROUP:FindByName("Name of the attacker group)
local ZoneUnit = Attacker:GetUnit(1)
local FlightZone = ZONE_UNIT:New("Flight_Zone", ZoneUnit, 10000)

SCHEDULER:New( nil, 
function()

local Target = SET_GROUP:New()
:FilterCoalitions("red")
:FilterCategoryAirplane()
:FilterCategoryGround()
:FilterStart()
 
if Target:AnyInZone(FlightZone)
then
  Target:ForEachGroupAnyInZone(FlightZone,
  function(Target)
 
   local AttackTask = Attacker:TaskAttackGroup(Target)
   Attacker:PushTask(AttackTask)
   MESSAGE:New("Target in zone!\nAttacking!",10):ToAll()
  end
  )
 
 else 
   local HoldPosition = Attacker:TaskHoldPosition(30)
   Attacker:SetTask(HoldPosition)
   MESSAGE:New("No targets in zone!\nHolding Position!",10):ToAll()
 end
end, {}, 1, 30
)

 

I tested these (and several other versions of them) with and without ME roles + with and without the role advanced waypoint actions.

They only work when CAP, CAS, etc. roles are selected, regardless of advanced waypoint actions being present.

 

Now, I won't argue with you, Grimes or Sven about what's actually going on.

I just tested :TaskAttackUnit() and :TaskAttackGroup() and noticed that they only work when certain ME roles are selected (again, no visible ME advanced waypoint actions involved).

 

Not trying to be a smartass here, just trying to understand how it works :thumbup:

EDIT: Just thought it would be helpful to attach a test mission as well (it runs on script 2).

As you can see, the F15C group doesn't have any advanced waypoint actions, in fact, there are no waypoints (really!), yet the programmed behaviour works.

And yes, I've also tested it with waypoints (Waypoint 0 and waypoint 1 ), same results.

However, if you try using "Nothing" or "Reconnaissance" roles instead, it won't work anymore. Why? :dunno:

Engage any bandits in moving zone.miz

Task attack any in zone.lua


Edited by Hardcard
Link to comment
Share on other sites

Yeah, I asked Grimes again and we discussed it further. I'm sure he said the opposite before but no matter. It looks like you have decent test cases and you are correct.

 

In the DCS API there is this: https://wiki.hoggitworld.com/view/DCS_func_addGroup

 

If you look at the groupData you'll see an entry for "task". I believe this is the role it is getting from the editor. I haven't tested or looked further but most likely.

 

We can probably easily have Moose handle this in something like an init on spawn. InitRole("CAP") or something like that. Then it would set this in the structure and we would be good most likely.

 

But we should note this somewhere in the DOCS in BOLD. If you want planes to do a certain role via scripting it should be set accordingly in the ME template group.

 

Thanks for being persistent with this.

 

Hi Delta99!

 

As I already mentioned in our previous Discord conversation about this, the scripts worked all the same with or without the advanced waypoint actions you are referring to.

 

Script 1:

local Attacker = GROUP:FindByName("Name of the attacker group in ME")
local Target = GROUP:FindByName("Name of the target group in ME")

local AttackTask = Attacker:TaskAttackGroup(Target)
Attacker:PushTask(AttackTask)

 

 

Script 2 (zone restricted behaviour test):

local Attacker = GROUP:FindByName("Name of the attacker group)
local ZoneUnit = Attacker:GetUnit(1)
local FlightZone = ZONE_UNIT:New("Flight_Zone", ZoneUnit, 10000)

SCHEDULER:New( nil, 
function()

local Target = SET_GROUP:New()
:FilterCoalitions("red")
:FilterCategoryAirplane()
:FilterCategoryGround()
:FilterStart()
 
if Target:AnyInZone(FlightZone)
then
  Target:ForEachGroupAnyInZone(FlightZone,
  function(Target)
 
   local AttackTask = Attacker:TaskAttackGroup(Target)
   Attacker:PushTask(AttackTask)
   MESSAGE:New("Target in zone!\nAttacking!",10):ToAll()
  end
  )
 
 else 
   local HoldPosition = Attacker:TaskHoldPosition(30)
   Attacker:SetTask(HoldPosition)
   MESSAGE:New("No targets in zone!\nHolding Position!",10):ToAll()
 end
end, {}, 1, 30
)

 

I tested these (and several other versions of them) with and without ME roles + with and without the role advanced waypoint actions.

They only work when CAP, CAS, etc. roles are selected, regardless of advanced waypoint actions being present.

 

Now, I won't argue with you, Grimes or Sven about what's actually going on.

I just tested :TaskAttackUnit() and :TaskAttackGroup() and noticed that they only work when certain ME roles are selected (again, no visible ME advanced waypoint actions involved).

 

Not trying to be a smartass here, just trying to understand how it works :thumbup:

EDIT: Just thought it would be helpful to attach a test mission as well (it runs on script 2).

As you can see, the F15C group doesn't have any advanced waypoint actions, in fact, there are no waypoints (really!), yet the programmed behaviour works.

And yes, I've also tested it with waypoints (Waypoint 0 and waypoint 1 ), same results.

However, if you try using "Nothing" or "Reconnaissance" roles instead, it won't work anymore. Why? :dunno:

Link to comment
Share on other sites

Thanks for being persistent with this.

 

"Stubbornness and OCDs aren't flaws as long as they lead to useful places"

-Hardcard's motto- :megalol: (hey, I might even use this as signature)

 

PS. Btw, I just realized it's "advanced (waypoint actions)", not "advanced waypoint actions" :doh:


Edited by Hardcard
Link to comment
Share on other sites

Hey, I need some more help. I want to let spawn 8 AAA within a Zone, witch works fine. In the second part I want the AAAs explode one by one with a 5 sec delay inbetween. The explosions works but all at the same time without any delay. Is there a methode to code a time delay or loop?

 

 

 

 

 

_AAA = SPAWN:New("AAA")

:InitLimit ( 8,8 )

:InitRandomizeTemplate( AAATemplate )

:InitRandomizeZones( RandomZoneTable )

:SpawnScheduled( 0.5, 0.5 )

 

-----------------------------

 

AAAs = SET_UNIT:New():FilterPrefixes("AAA"):FilterActive():FilterStart()

 

function nofunc ()

MESSAGE:New( "Explosion!", 5, nil ):ToAll()

end

 

AAAs:ForEachUnit(

function( AAAs )

zuf = math.random(1,4)

if zuf >= 2 then

AAAPosit = AAAs:GetCoordinate()

AAAPosit.y = AAAPosit:GetLandHeight()

timer.scheduleFunction( nofunc, {}, timer.getTime() + 5 ) -- Delays 5 sec

AAAPosit:BigSmokeAndFireSmall(0.5)

AAAPosit:Explosion(50)

end

end )

Link to comment
Share on other sites

_AAA = SPAWN:New("AAA")

:InitLimit ( 8,8 )

:InitRandomizeTemplate( AAATemplate )

:InitRandomizeZones( RandomZoneTable )

:SpawnScheduled( 0.5, 0.5 )

 

-----------------------------

 

AAAs = SET_UNIT:New():FilterPrefixes("AAA"):FilterActive():FilterStart()

delay = 0

function nofunc ()

MESSAGE:New( "Explosion!", 5, nil ):ToAll()

end

 

AAAs:ForEachUnit(

function( AAAs )

zuf = math.random(1,4)

 

if zuf >= 2 then

blow_stuff_up( AAAs )

end

 

end )

 

 

 

function blow_stuff_up( AAAs )

 

SCHEDULER:New( nil, function()

AAAPosit = AAAs:GetCoordinate()

AAAPosit.y = AAAPosit:GetLandHeight()

AAAPosit:BigSmokeAndFireSmall(0.5)

AAAPosit:Explosion(50)

 

end, {}, delay, 0

)

delay = delay + 5

 

end


Edited by HC_Official

Click here for tutorials for using Virpil Hardware and Software

 

Click here for Virpil Flight equipment dimensions and pictures.

.

Link to comment
Share on other sites

is it possible to send a message only to the group that enter the zone?

in my case:

i have 4 helos, if one the enter a zone from a ship, the one (who entered) should get a message, the ship transmits a radio transmission (to all) and the ship should shot a flare.

 

in my knowlege i must do it for every helo the same function.

 

so is there a way to wrote one function?

 

like:

helo(x)=helo entered the zone ( can be /helo1 or /helo2 ...)

 

if helo(X) in zone

do Message: (hi):to Helo(X)

radiotransmission

shoot flare

Link to comment
Share on other sites

Hi there!

 

There are several ways of doing this.

 

One of them would be to include the helo client groups that you choose in a SET_GROUP, then iterate that set so only the client groups that are within the zone will get the message.

 

For instance, this script example should do the trick (includes usersound + ship flare):

 

 

local HeloSET = SET_GROUP:New()

:FilterPrefixes("Chosen prefix in ME")

:FilterStart()

 

local MessageZone = ZONE:New("Name of the zone in ME")

 

local Ship = UNIT:FindByName("UNIT name of the ship in ME")

 

local ShipCoordinate = Ship:GetCoordinate()

 

HeloSET:ForEachGroupCompletelyInZone(MessageZone,

function(HeloSET)

 

MESSAGE:New("hi!",10):ToGroup(HeloSET) -- this message will only be sent to the client groups in the set that are located within "MessageZone"

 

USERSOUND:New("hi.ogg"):ToGroup(HeloSET) -- if you want the usersound to be sent to all, then use :ToAll() instead of :ToGroup(HeloSET)

 

ShipCoordinate:FlareWhite()

end

)

 

 

If you need this to run continuously, put it inside a scheduler.


Edited by Hardcard
Link to comment
Share on other sites

Hi thank you this was the point im missing:

 

HeloSET:ForEachGroupCompletelyInZone(MessageZone,
function(HeloSET)

 

if i want A radiot transmisson instead of usersound. i have to use this?:

 


CVW17 = UNIT:FindByName("USS Lake Erie")

CVW17Radio = USS Lake Erie:GetRadio()
CVW17Radio:SetFileName("USSOliverPerryHeloLand.ogg") 
CVW17Radio:SetFrequency(127.5)         
CVW17Radio:SetModulation(radio.modulation.AM)
CVW17Radio:SetLoop(false)

 

and in the if

 

 CVW17Radio:Broadcast()

 

i am right?

 

thanks for the help

Link to comment
Share on other sites

I've never scripted a radio transmission before, but, according to the MOOSE examples, this should do the trick:

 

 

local HeloSET = SET_GROUP:New()

:FilterPrefixes("Chosen prefix in ME")

:FilterStart()

 

local MessageZone = ZONE:New("Name of the zone in ME")

 

local Ship = UNIT:FindByName("UNIT name of the ship in ME")

 

local ShipCoordinate = Ship:GetCoordinate()

 

local ShipRadio = Ship:GetRadio()

 

HeloSET:ForEachGroupCompletelyInZone(MessageZone,

function(HeloSET)

 

MESSAGE:New("hi!",10):ToGroup(HeloSET)

 

ShipRadio:SetFileName("sound file.ogg")

:SetFrequency(127.5)

:SetModulation(radio.modulation.AM)

:SetLoop(false)

:Broadcast()

 

ShipCoordinate:FlareWhite()

end

)

 

 

Btw, you made a small mistake (which would generate a scripting error):

 

 

CVW17 = UNIT:FindByName("USS Lake Erie")

 

CVW17Radio = USS Lake Erie:GetRadio() -- USS Lake Erie:GetRadio() is invalid.

 

--Notice that USS Lake Erie doesn't exist as a variable, since you haven't declared it anywhere. The variable that you declared is called CVW17.

--(Also, never split variable names like that, you must avoid blank spaces. A correct format for a variable name would be USS_Lake_Erie)

 

--Here's the correct form

 

CVW17 = UNIT:FindByName("USS Lake Erie")

 

CVW17Radio = CVW17:GetRadio() --We use the variable CVW17 instead

:SetFileName("USSOliverPerryHeloLand.ogg")

:SetFrequency(127.5)

:SetModulation(radio.modulation.AM)

:SetLoop(false)

 

--On another note, there's no need to write CVW17Radio in every single line of the variable declaration. (As long as you're working with the MOOSE object directly)

 

--If you write that variable in single line format instead, this concept will be easier to understand (I think):

 

CVW17Radio = CVW17:GetRadio():SetFileName("USSOliverPerryHeloLand.ogg"):SetFrequency(127.5):SetModulation(radio.modulation.AM):SetLoop(false)

 

-- Notice that the variable CVW17Radio is simply getting the radio object for the ship 'CVW17:GetRadio()' , and then setting it up using functionalities that belong to the RADIO class

 

 

 

There's no "if" logic in the script example I gave you, but I think I understand what you mean.

 

Sure, you can store the radio transmission in a variable and then broadcast it whenever you please.

 

Example:

 

 

 

local Ship = UNIT:FindByName("UNIT name of the ship in ME") --This variable contains the ship unit object

 

local ShipRadio = Ship:GetRadio() --This variable contains the radio object for the ship unit object above

 

--Declare the radio transmission variable. In this case, we'll call it RadioTransmission

local RadioTransmission = ShipRadio:SetFileName("sound file.ogg")

:SetFrequency(127.5)

:SetModulation(radio.modulation.AM)

:SetLoop(false)

 

--Then broadcast the radio transmission variable at your discretion by adding this line in any function below it:

RadioTransmission:Broadcast()

 

 

Hope this helps :thumbup:


Edited by Hardcard
Link to comment
Share on other sites

ForEachGroupCompletelyInZone, if I'm following right, wont work. He wants it if 1 helo from the group enters. They would have to all be in the zone for this to trigger. Might want to look for ForEachGroupPartlyInZone? Can double tap the docs :)

 

https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Core.Set.html##(SET_GROUP).ForEachGroupPartlyInZone

 

Only issue I see from that is then, as each one enters the zone, it'll trigger

B. "Swany" Swanberg

Gigabyte Designare, Intel i9 9900KF (3.6, OC'd to 5.0)

32GB Patriot Viper Steel (black, non-RGB)

OS installed on a Samsung Evo 970 1TB SSD

DCS installed on a Samsun Evo 860 1TB SSD

EVGA 2080Ti 11GB

EVGA Supernova 720p 750w PS

3 Dell S2716DG monitors in Surround mode (7680x1440)

Oculus Rift S VR

Thrustmaster Warthog Throttle and Stick

Thrusmaster Rudder Pedals

assorted button boxes/Arduino boards

All drivers always kept up to date (30 days old, max)

Link to comment
Share on other sites

@Swany

 

Sure, :ForEachGroupPartlyInZone() can be used instead.

 

I didn't use it precisely because of what you mentioned: "as each one (client) enters the zone, it'll trigger (the message will be sent to all the clients in the group, regardless of them being inside the zone)"

I assumed BlackLibrary wouldn't want clients outside the zone to get the message, :ForEachGroupCompletelyInZone() ensures this doesn't happen, since it'll only run when all clients in the group are inside the zone.

 

The fundamental problem here is that the DCS scripting engine doesn't offer "message to unit" functionality, so workarounds must be used.

 

Another possible solution would be to put each client in a separate group, that way both :ForEachGroupPartlyInZone() and :ForEachGroupCompletelyInZone() would work exactly as requested.


Edited by Hardcard
Link to comment
Share on other sites

Hello,

 

I dont know much about scripting, but I do love to use RAT to add ambiance to my SP missions, however I've noticed that when I use RAT, a message about the briefing appears ... between loading Moose and loading the RAT lua, like this:

 

msTSdxg.jpg

 

Does anyone know how to avoid that message?

Thanks a lot for any help that you may give me with this :)

 

 

Eduardo

 

For work: iMac mid-2010 of 27" - Core i7 870 - 6 GB DDR3 1333 MHz - ATI HD5670 - SSD 256 GB - HDD 2 TB - macOS High Sierra

For Gaming: 34" Monitor - Ryzen 3600X - 32 GB DDR4 2400 - nVidia GTX1070ti - SSD 1.25 TB - HDD 10 TB - Win10 Pro - TM HOTAS Cougar - Oculus Rift CV1

Mobile: iPad Pro 12.9" of 256 GB

Link to comment
Share on other sites

Does anyone know how to avoid that message?

Which MOOSE version do you use, Rudel?

 

I ask because I also was not fond of that message either since it broke the immersion for me. So it was removed upon my request some time ago - at least if there is no other (moose) briefing text for the mission or even completely, can't recall.

A warrior's mission is to foster the success of others.

i9-12900K | MSI RTX 3080Ti Suprim X | 128 GB Ram 3200 MHz DDR-4 | MSI MPG Edge Z690 | Samung EVO 980 Pro SSD | Virpil Stick, Throttle and Collective | MFG Crosswind | HP Reverb G2

RAT - On the Range - Rescue Helo - Recovery Tanker - Warehouse - Airboss

Link to comment
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

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