Jump to content

Recommended Posts

Posted
Typically you don't need to as that is what it is doing by going to its "Home" location that you designated. Unfortunately they won't shut down engines so will just sit there forever until they run out of fuel (maybe).

 

I suppose you can stop the dispatcher but not sure that is really necessary.

 

As I said the only way to do that RouteRTB is by spawning a new aircraft in place of the current one. So this is an ugly work-around but the only way to do it as far as I am aware.

 

 

Ahhhh, I understand what you're saying now - RouteRTB is specifically doing the delete/respawn. I hadn't read the RouteRTB docs, just the example mission and never guessed it'd have that kind of behavior. What does and does not work with DCS' scripts/AI always leaves me guessing, even more than Arma's! :)

 

 

 

Regarding stopping the dispatcher; I'm mostly doing this to learn more about how it works so I could retask AI groups if I wanted.

 

 

Thanks for the help, I'll poke around more at the dispatcher FSM now that I know some of what _not_ to do :)

Posted (edited)

For some reason DCS is not running the MOOSE script.

 

 

 

When I run the Moose demo missions provided they work ...the script runs

 

 

But when I make up my own missions they wouldn't work for some reason.

 

 

 

After testing I found that for some reason DCS is not loading the MOOSE script even though the trigger is set properly.

 

 

Not sure why not.

Edited by rooster328
Posted
That looks correct. Did it work?

 

Actually...yes.

 

Sorry for the delayed reply.:music_whistling:

[sIGPIC][/sIGPIC]

Primary Computer

ASUS Z390-P, i7-9700K CPU @ 5.0Ghz, 32GB Patriot Viper Steel DDR4 @ 3200Mhz, ZOTAC GeForce 1070 Ti AMP Extreme, Samsung 970 EVO M.2 NVMe drives (1Tb & 500 Gb), Windows 10 Professional, Thrustmaster Warthog HOTAS, Thrustmaster Warthog Stick, Thrustmaster Cougar Throttle, Cougar MFDs x3, Saitek Combat Rudder Pedals and TrackIR 5.

 

-={TAC}=-DCS Server

Gigabyte GA-Z68XP-UD3, i7-3770K CPU @ 3.90GHz, 32GB G.SKILL Ripjaws DDR3 @ 1600Mhz, ZOTAC GeForce® GTX 970.

Posted

Hey guys, complete MOOSE Newb question, but would it be possible to make an aircraft orbit between two moving zones?

Intel i9-9900KF @5.2GHz

MSI Z390 Gaming Pro Carbon

32GB G.Skill Trident Z DDR3200 RAM

MSI RTX 2080 Ti Gaming X Trio

40" Panasonic TH-40DX600U @ 4K

Pimax Vision 8K Plus / Oculus Rift CV1 / HTC Vive

Gametrix JetSeat with SimShaker

Windows 10 64 Bit Home Edition

 

[sIGPIC][/sIGPIC]

Posted

I'm confused when you would use a zone using a Trigger zone vs a Late activation Helicopter. Below is the Trigger zone name that you would then put into the mission using ME Trigger Zones.

 

PatrolZone = ZONE:New( "Patrol Zone" )

 

AICapZone = AI_CAP_ZONE:New( PatrolZone, 500, 1000, 500, 600 )

 

 

or you could use the late activation Helo method to create a zone.

 

 

redborder = ZONE_POLYGON:New( "redborder", GROUP:FindByName( "redborder" ) )

A2ADispatcher:SetSquadronCap( "redcap", redborder, 200, 2000, 750, 800, 800, 1400 )

A2ADispatcher:SetSquadronCapInterval( "redcap", 4, 10, 20, 1 )

It seems like both serve the same function. Why have two different methods to setup a Zone?

Posted

You can’t compare Arma scripting to DCS. You can do almost anything in Arma. It’s at least 10,000 times better than DCS maybe more. Arma is in a totally different league than DCS in this area. No comparison whatsoever.

 

Ahhhh, I understand what you're saying now - RouteRTB is specifically doing the delete/respawn. I hadn't read the RouteRTB docs, just the example mission and never guessed it'd have that kind of behavior. What does and does not work with DCS' scripts/AI always leaves me guessing, even more than Arma's! :)

 

 

 

Regarding stopping the dispatcher; I'm mostly doing this to learn more about how it works so I could retask AI groups if I wanted.

 

 

Thanks for the help, I'll poke around more at the dispatcher FSM now that I know some of what _not_ to do :)

Posted
Hey guys, complete MOOSE Newb question, but would it be possible to make an aircraft orbit between two moving zones?

 

I don't know the answer..,but this question is intriguing...I'm curious how you want to use this...

[sIGPIC][/sIGPIC]

Primary Computer

ASUS Z390-P, i7-9700K CPU @ 5.0Ghz, 32GB Patriot Viper Steel DDR4 @ 3200Mhz, ZOTAC GeForce 1070 Ti AMP Extreme, Samsung 970 EVO M.2 NVMe drives (1Tb & 500 Gb), Windows 10 Professional, Thrustmaster Warthog HOTAS, Thrustmaster Warthog Stick, Thrustmaster Cougar Throttle, Cougar MFDs x3, Saitek Combat Rudder Pedals and TrackIR 5.

 

-={TAC}=-DCS Server

Gigabyte GA-Z68XP-UD3, i7-3770K CPU @ 3.90GHz, 32GB G.SKILL Ripjaws DDR3 @ 1600Mhz, ZOTAC GeForce® GTX 970.

Posted
Hey guys, complete MOOSE Newb question, but would it be possible to make an aircraft orbit between two moving zones?

 

This shouldn't be too difficult. You can probably easily find the centre of the zone or a random point in the zone and use that to build a waypoint. Then just wait for the aircraft to hit that waypoint OR enter that zone and do the same for the other zone. Rinse and repeat continuously.

Posted
Hey guys, complete MOOSE Newb question, but would it be possible to make an aircraft orbit between two moving zones?

 

 

 

 

Yup. That is possible. Of course. And how would these zones be moving, like airborne planes like tankers or rather moving vehicles and let a helo fly between them?

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Posted

Hi, I have a question on the behavior of MOOSE patrols as I'm playing around with a few use-cases and trying to understand the framework behavior.

 

Question 1:

 

Situation: I create a few dynamic zones I want an AI group to patrol.

 

Once I assign a zone (zr) to a patrol, and a group (rescueHeloGroup) to that patrol, via

 

   
patrol = AI_PATROL_ZONE:New( zr, 50, 100, 3, 10 )
patrol:ManageFuel( 0.2, 60 )
patrol:SetControllable( rescueHeloGroup )
patrol:__Start(1)

 

will the patrol follow the zone around if the zone position dynamically changes via:

 

   
-- update zone position dynamically (this repositions the zone somewhere else during the mission)
zr:SetVec2(new_zone_center_vec2)

 

 

Will the patrol automatically follow the zone change, or do I need to recreate the patrol?

 

Question 2:

 

How do I terminate a patrol? Meaning, remove the object from the patrol and cleanup?

 

-- does this work?
patrol:SetControllable(nil)

 

 

Question 3:

 

Looking at the sample mission code, I'm not sure I understand the __Start(), __Accomplish() and how to change states in the AI routines in general. Looking up examples isn't helping, I'm looking for what they do, I see them used, but I dont see the parameters explained. Must be looking in the wrong area :)

 

Thanks!

Posted
I don't know the answer..,but this question is intriguing...I'm curious how you want to use this...

Yup. That is possible. Of course. And how would these zones be moving, like airborne planes like tankers or rather moving vehicles and let a helo fly between them?

 

Basically, I was thinking of using this as a basis for keeping a tanker overhead a moving carrier, although funkyfranky is also working on this now :)

Intel i9-9900KF @5.2GHz

MSI Z390 Gaming Pro Carbon

32GB G.Skill Trident Z DDR3200 RAM

MSI RTX 2080 Ti Gaming X Trio

40" Panasonic TH-40DX600U @ 4K

Pimax Vision 8K Plus / Oculus Rift CV1 / HTC Vive

Gametrix JetSeat with SimShaker

Windows 10 64 Bit Home Edition

 

[sIGPIC][/sIGPIC]

Posted

Also: Is there a MOOSE equivalent to the Integrated Air Defense System or Smarter SAMs scripts? - I also would like all the SAMs to cooperate and give us a hard time!

 

Thankful for any help!

/Mats

 

 

I second this.

 

I saw that MOOSE has a SEAD class: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Functional.Sead.html

 

But so far I have not got it working - even in the demo missiom, AI sits there like usual and waits for ARM to hit.

Posted

Is there a line for having the squadron returning to a specific airbase?

Right now they fly the mission and return to the closest airbase which in some cases is a Neutral.

Thanks.

Posted

Hi, yesterday during a mission, Red Cap didn't spawn. I use all the time the same proven scripts. First CAP spawned correctly but once wiped out no more Red Cap spawn. At the same time Blue CAP and RAT script worked. I attached the . miz file hoping that someone could help me in solving the bug.

Thx.

=MDS=_Op_Unrest_pt1_v0.1.Caucasus.miz

CASE Antec C5 Constellation series |CPU Ryzen 7 7800X3D | COOLER Corsair iCue Link H150i RGB Elite | MB Asus Tuf Gaming X670E-Plus | RAM 64GB Corsair Vengeance DDR5 6000mhz | GPU MSI RTX 3070 Ti Gaming X Trio | SSD OS Samsung M.2 nVme 990 Pro 1TB / SSD DCS870 Evo 2TB | PSU Antec HCG 850W Gold | SO Win 11 pro 64bit 23h2 | MONITORS LG 27GP850P/27GL850 | PERIFERICHE GAMING TrackIR 5 | Thrustmaster Hotas Warthog | MFG Crosswind + combat pedals + hydraulic damper | TM MFD Cougar | Logitech G923

 

"Mai discutere con un idiota, ti trascina al suo livello e ti batte con l'esperienza" cit. Oscar Wilde

Posted

Hello, I am a complete noob with lua scripting. I want to create an LSO mission for Case 1 practice and I'm trying to create a moving zone at the carrier to trigger "sound to all" for an LSO radio call, "Don't Settle", if the player's aircraft exceeds -800 FPS decent rate. I have tried several times to try the Vertical Velocity trigger in DCS ME but I can't get it to work with a negative number. Is there a way to do this using MOOSE?




Liquid Cooled i9 11900K | GeForce RTX 2080 | 32 gig RAM | SSD Samsung 850 EVO | HP Reverb G2

TM F/A-18 Stick | Virpil WarBRD | WinWIng F/A-18 HOTAS

Posted (edited)
I have tried several times to try the Vertical Velocity trigger in DCS ME but I can't get it to work with a negative number. Is there a way to do this using MOOSE?

 

Seems like we're in sync or something.

I spent the whole day trying to create a MOOSE script that successfully returns unit climb/descent rate.

It's still work in progress, but it seems to work decently (the returned values are quite close to indicator readings, which is a good sign).

 

Here's the script:

 

SCHEDULER:New( nil,

function()

 

local Client = UNIT:FindByName("Client")

local ClientVelocityMPS = Client:GetVelocityMPS()

local ClientVelocityMach = ClientVelocityMPS / 330 --Approximate conversion from m/s to Mach. The returned values seem accurate enough--

local ClientMOOSEDescentAngle = Client:GetClimbAnge() --I think that this might be actually returning the climb/descent angle in radians instead of degrees, contrary to what the documentation and intellisense say--

local ClientMOOSEDescentAngleDegree = UTILS.ToDegree(ClientMOOSEDescentAngle) --After adding this line, the script seems to work as intended!--

 

--This is one of the descent rate approximations I've tried. The returned values seem to be accurate enough--

local ClientDescentRateMOOSEFtM = ClientMOOSEDescentAngleDegree * ClientVelocityMach * 1165 --Returns climb/descent rate in feet per minute--

local ClientDescentRateMOOSEMpS = ClientDescentRateMOOSEFtM / 196.85 --Returns climb/descent rate in meters per second--

 

MESSAGE:New("Velocity (m/s):"..ClientVelocityMPS.."\nVelocity (Mach):"..ClientVelocityMach..

"\nMOOSE Descent Angle (Radians?):"..ClientMOOSEDescentAngle.."\nMOOSE Descent Angle (Degrees?):"..ClientMOOSEDescentAngleDegree..

"\nDescent Rate (Ft/min):"..ClientDescentRateMOOSEFtM.."\nDescent Rate (m/s):"..ClientDescentRateMOOSEMpS,5,nil,true):ToAll()

 

end, {}, 1, 5

)

 

 

Now, this script will only give you the following values:

- Unit's velocity (expressed in m/s and Mach number)

- Unit's climb/descent angle (expressed in radians and degrees... if I'm not mistaken)

- Unit's climb/descent rate (expressed in feet per minute and meters per second)

 

It won't set up any checkers, flags or triggers (which you'll probably need in order to accomplish what you described).

Lucky for you, that's the easy part :thumbup:

 

PS. If anyone knows a better way of getting unit climb/descent rates, I'm all ears!

 

EDIT: Found a better way!

 

 

SCHEDULER:New( nil,

function()

local TestClient = UNIT:FindByName("Client")

 

local ClientVelocityVec3 = TestClient:GetVelocityVec3()

local ClientVerticalVelocityMxS = ClientVelocityVec3.y -- Y happens to be the unit's vertical velocity expressed in m/s) --

local ClientVerticalVelocityFtxM = ClientVerticalVelocityMxS * 196.85 -- Conversion from m/s to Ft/min --

 

MESSAGE:New("Vertical speed (m/s): "..ClientVerticalVelocityMxS.."\nVertical speed (Ft/min): "..ClientVerticalVelocityFtxM, 5):ToAll()

end,

{}, 0, 5 )

 

Edited by Hardcard
Posted
Seems like we're in sync or something.

I spent the whole day trying to create a MOOSE script that successfully returns unit climb/descent rate.

It's still work in progress, but it seems to work decently (the returned values are quite close to indicator readings, which is a good sign).

 

Here's the script:

 

SCHEDULER:New( nil,

function()

 

local Client = UNIT:FindByName("Client")

local ClientVelocityMPS = Client:GetVelocityMPS()

local ClientVelocityMach = ClientVelocityMPS / 330 --Approximate conversion from m/s to Mach. The returned values seem accurate enough--

local ClientMOOSEDescentAngle = Client:GetClimbAnge() --I think that this might be actually returning the climb/descent angle in radians instead of degrees, contrary to what the documentation and intellisense say--

local ClientMOOSEDescentAngleDegree = UTILS.ToDegree(ClientMOOSEDescentAngle) --After adding this line, the script seems to work as intended!--

 

--This is one of the descent rate approximations I've tried. The returned values seem to be accurate enough--

local ClientDescentRateMOOSEFtM = ClientMOOSEDescentAngleDegree * ClientVelocityMach * 1165 --Returns climb/descent rate in feet per minute--

local ClientDescentRateMOOSEMpS = ClientDescentRateMOOSEFtM / 196.85 --Returns climb/descent rate in meters per second--

 

MESSAGE:New("Velocity (m/s):"..ClientVelocityMPS.."\nVelocity (Mach):"..ClientVelocityMach..

"\nMOOSE Descent Angle (Radians?):"..ClientMOOSEDescentAngle.."\nMOOSE Descent Angle (Degrees?):"..ClientMOOSEDescentAngleDegree..

"\nDescent Rate (Ft/min):"..ClientDescentRateMOOSEFtM.."\nDescent Rate (m/s):"..ClientDescentRateMOOSEMpS,5,nil,true):ToAll()

 

end, {}, 1, 5

)

 

 

Now, this script will only give you the following values:

- Unit's velocity (expressed in m/s and Mach number)

- Unit's climb/descent angle (expressed in radians and degrees... if I'm not mistaken)

- Unit's climb/descent rate (expressed in feet per minute and meters per second)

 

It won't set up any checkers, flags or triggers (which you'll probably need in order to accomplish what you described).

Lucky for you, that's the easy part :thumbup:

 

PS. If anyone knows a better way of getting unit climb/descent rates, I'm all ears!

 

Thanks! I’ll give a try.




Liquid Cooled i9 11900K | GeForce RTX 2080 | 32 gig RAM | SSD Samsung 850 EVO | HP Reverb G2

TM F/A-18 Stick | Virpil WarBRD | WinWIng F/A-18 HOTAS

Posted (edited)

So, using the script I provided before as a means to get your plane's descent rate, you could simply add a few extra lines inside that same scheduler (at the bottom, before the end) in order to receive those messages you mentioned

when the client is within that zone.

 

I think these extra lines should do the trick:

 

local Carrier = UNIT:FindByName("UNIT name of the carrier in ME")

local CarrierZone = ZONE_UNIT:New("Name of the carrier zone in ME", Carrier, radius of the zone in ME)

local ClientCheck = Client:IsInZone(CarrierZone)

 

if ClientDescentRateMOOSEFtM < -800 and ClientCheck == true --I'm using a "<" (less than) operator in this check, since we're dealing with a negative value. It should work, haven't tested it, though!--

then

MESSAGE:New("Don't Settle!", 10, nil, true):ToAll()

USERSOUND:New("Name of your sound file.ogg"):ToAll()

end

 

 

Of course, in order for all this to work, the units and zone names in the script must match the ones you defined in ME.

Edited by Hardcard
  • Recently Browsing   0 members

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