FlightControl

Does somebody have experience with table creation using BB codes in vbulletin? I see the [table] tags do something, but not [tr], , [td] ...

Yup. Once I had a mission that played "background music". The .miz file was 20 mb lol... It took some courage to download that mission in mp :-) Ensure you follow the advice of Grimes :-)

On a regular basis I get hints that people are having difficulties setting up the LDT environment correctly. This is understandable, as LDT is a bit intimidating in the beginning. If such is the case, just contact us for help. We can sort it out easily within the team. Fc

If you're prepared to learn or try something else... local HitZone = ZONE:New( "Bridge" ) HitZone:HandleEvent( EVENTS.Dead ) function HitZpne:OnEventDead( EventData ) . if EventData.IniObjectCategory == 3 then . if EventData.IniUnit:InZone( self ) then . MESSAGE( "Bridge dead", 15 ):ToAll() . end . end end Just written out of my sleeve. 9 lines of code. If you're interested give a yell... Fc

The forums tells me now that "I am just really nice"... lol

Download this small test mission using some MOOSE functions ... To run this mission, work only in MAP mode (F10). You can speed up time using CTRL-W (or Z) You see a red airplane flying over a zone with hundreds of potential targets. The detection is dynamic, and will use the detection capabilities of the red plane and will dynamically group (ungroup) detected targets in areas of 2km wide... The areas are indicated by the moose framework adding tyres around the areas formed. You'll see these with a red diamond symbol. Try different planes, with different detection capabilities (like pods) at different altitudes. Try helicopters, with the same variations. Try to switch the red and the blue side. The only requirement is that your FACA is called FAC. The rest doesn't matter. You'll see that the su-24MR equipped with the kopyo radar pod does not make a lot of difference. You'll notice some performance lag after a while when speeding up time, but that is caused by the tyre placement logic (statics). Enjoy exploring. FC Am interested in your findings and thoughts, so feel free to post. DET-900 - Detection Test with RED FACA.miz

Twisted with an su-24MR and the pod, but don't see a significant different detection from the normal su-25T. Maybe I do something wrong. I'll post a demo mission.

thank you Shagrat, sorry for asking, but is there on the red coalition also an air unit that can perform recce on a larger scale? Sven

The issue that i see within DCS, there is no vehicle on the blue side in the role of RECCE or FAC, just as on the red side. Other question, are there ANY planes that can be used as recce for detecting ground troops, other than having to use a visual? The F-15E has a ground radar f.e., not sure if such works in DCS through. Any russian planes that can be used for this role?

I see that the MI-28N has received some love by ED. The helicopters now engage with the cannons, which is great news! They didn't do that previously!

Just tested with that vehicle. It gives very bad results. Better is the APC M1043 HMMWV Armament, it detects targets from a much further distance.

What is the UNIT name of the default RECCE vehicle for the blue coalition?

Please send me a private message here on this ED forum. Once received, I can send you a slack.com invitation to join the moose community on slack. thanks for your interest! FC

My pleasure! I enjoy making this framework, but just know that it is not a one man show. Currently other people are helping out with the code too! And sharing ideas etc. Join the club I would say! Let me see if I can help answering them. Okay, let me give some context to all this. CONTROLLABLE is an abstract class that implements methods to control anything that is "controllable" in DCS World. Currently, there are two kinds of objects "controllable" in DCS world: Units and Groups. Controllable provides APIs to make these controllable objects move around and perform tasks within your mission. It hides the complexity for MDs having to use a low-level "Controllable" class as documented in the DCS API, and having to make these "tables" to set tasks. Instead CONTROLLABLE provides you (as you've seen) with methods that are intellisensed to created tasks etc. CONTROLLABLE is a base class. That means, it is not meant to be used directly by mission designers, but it is inherited by the GROUP and UNIT wrapper classes in MOOSE. Instead of using the CONTROLLABLE class directly, you should use the GROUP wrapper class or the UNIT wrapper class to control a group or unit respectively. I see that you've learned a lot from reading the documentation and looking at the example missions. However, a couple of remarks to your code, if you allow me: Suggestion #1: I think you don't need to do the error handling. That is done in the MOOSE classes for you (it should). If not, I need to ensure that this is properly done. Also, you can then embed or nest these calls... So the code that you've written: -- Grab the group whose path represents the 'polygon' PatrolZoneGroupRef = GROUP:FindByName( "PolygonZone #001" ) if PatrolZoneGroupRef == nil then env.error ("DVD: PatrolZoneGroup is nil - Could not find the PolygoneZone #001 group.") end -- Create the ZONE_POLYGON based on that group --[[ PatrolZoneRef = ZONE_POLYGON:New( "Zone #001", PatrolZoneGroupRef ) if PatrolZoneRef == nil then env.error ("DVD: PatrolZone is nil - Did not create zone from the Patrol Zone Group.") end --]] could simply be rewritten as: PatrolZoneRef = ZONE_POLYGON:New( "Zone #001", GROUP:FindByName( "PolygonZone #001" ) ) Much shorter, isn't it? Suggestion #2: The POINT_VEC3 and POINT_VEC2 classes implement methods to create AIR and GROUND waypoints... The method you used PatrolGroupRef:TaskRouteToZone (PatrolZoneRef, true, 500, "Cone") is a something quirky that I wrote about a year ago. Instead, a much better design has emerged that I should ask you to use from now on: POINT_VEC3 and POINT_VEC2 are classes that manage 3D points in space. These classes provide you with a multitude of methods that allow you to "stuff" with a point in 3D space. One of the things you can do is to create waypoints that you can then embed in a route of a CONTROLLABLE (GROUP or UNIT). There is a method declared to manage AIR waypoints: --- Build an air type route point. -- @param #POINT_VEC3 self -- @param #POINT_VEC3.RoutePointAltType AltType The altitude type. -- @param #POINT_VEC3.RoutePointType Type The route point type. -- @param #POINT_VEC3.RoutePointAction Action The route point action. -- @param Dcs.DCSTypes#Speed Speed Airspeed in km/h. -- @param #boolean SpeedLocked true means the speed is locked. -- @return #table The route point. function POINT_VEC3:RoutePointAir( AltType, Type, Action, Speed, SpeedLocked ) And there is a method declared to manage GROUND waypoints: --- Build an ground type route point. -- @param #POINT_VEC3 self -- @param Dcs.DCSTypes#Speed Speed Speed in km/h. -- @param #POINT_VEC3.RoutePointAction Formation The route point Formation. -- @return #table The route point. function POINT_VEC3:RoutePointGround( Speed, Formation ) So, your code PatrolGroupRef:TaskRouteToZone (PatrolZoneRef, true, 500, "Cone") could be rewritten as: local PointVec2 = POINT_VEC2:NewFromVec2( PatrolZoneRef:GetVec2(), 2000 ) -- Returns a POINT_VEC2 object with X, Y coordinates and a height of 2000 meters. local ToAirWayPoint = PointVec2:RoutePointAir( POINT_VEC3.RoutePointAltType.BARO, POINT_VEC3.RoutePointType.TurningPoint, POINT_VEC3.RoutePointAction.TurningPoint, 2000, true ) local CurrentAirWayPoint = PatrolGroupRef:GetPointVec3():RoutePointAir( POINT_VEC3.RoutePointAltType.BARO, POINT_VEC3.RoutePointType.TurningPoint, POINT_VEC3.RoutePointAction.TurningPoint, 2000, true ) PatrolGroupRef:Route( {CurrentAirWayPoint, ToAirWayPoint } ) The seems a bit larger, yes. However, the code can still be optimized and the MOOSE API can still be optimized. F.e., there should be a method that just takes an AIR waypoint and routes to that AIR waypoint from the Current AIR waypoint. But that requires some effort in MOOSe and I currently have other priorities. Hope it helps and thanks for your PM. I will take care of it.

Thanks! You know why these questions are for eh :-)

Thanks. Took an mi-28N, and put the option SEARCH RADAR ALWAYS ON... that provides the expected results. The Ka-50 is also good.

What I'm looking for is an air unit, helicopter or plane, that has a detection capability to detect ground units from "far". If none, what is a good ground unit to detect targets? FC

Anybody have a good suggestion?

local Plane = UNIT:FindByName( "Plane" ) Plane:HandleEvent( EVENTS.Shot ) --- -- @param Wrapper.Unit#UNIT self -- @param Core.Event#EVENTDATA EventData function Plane:OnEventShot(EventData) if EventData.WeaponName == "weapons.missiles.Vikhr_M" then MESSAGE:New("Plane shot vikr",15,"Alert!"):ToAll() local Task = EventData.IniGroup:TaskOrbitCircle( 5000, 450 ) EventData.IniGroup:PushTask( Task, 30 ) end end

Is this problem being considered for a fix?

@GreyEcho, sorry for my late answer. Thanks to all and those who have helped making and testing it. That is normal. I suggest you have a look at the links at my signature or send me a PM with your email, so I can add you to the moose community on slack.com. It is easier to interact on slack than through this forum. You can use MOOSE anywhere within your DCS mission. Forget the trigger system in DCS. MOOSE works differently. You will hardly need the trigger system in DCS if you use the moose framework. You won't need flags, switches and other means to build logic. You can use lua to code your mission logic directly in the script. That makes it easier for you to follow how your mission works and what happens when ... Create one big lua file and include that lua file into your mission .miz file, by creating a trigger in the Mission Editor that will run at Mission Start in a DO SCRIPT FILE ... That lua script file contains all the declarations of the local and global objects, variables, event handlers, schedulers and other mechanisms that the moose framework provides... Then there are a couple of options that you have: 1. You can try to build all your mission logic into that one big lua file. You keep the mission defined in the mission editor "clean" from any scripting. 2. You can use the global objects declared in the lua file at certain scripting points within the mission editor. For example, at a waypoint or at trigger DO SCRIPT logic. The goal of moose is to achieve point #1, but for the moment it is still sometimes required to also do point #2 :-) So think of moose as a toolbox that you can use to: - Spawn stuff - Handle DCS events - Schedule events within time - Score your achievements - Define and use zone logic - Create menus and embed commands at menus - Send text messages to various players with various conditions - Build finite state machines - Detect targets - Build logical missions for players - Create tasks in missions for players - Perform AI "processes" like CAP, PATROL, CAS that are much richer than the DCS default role tasks. - Execute various tasks using WRAPPER classes of the DCS object API. - Build dynamic SETs of objects that you can use to do batch asynchronous processing on these objects. - ... and build a mission "flow". Note that you'll recognise the same functionality available using the DCS api, but MOOSE has built around this API a much more rich functional set of objects. Just added, the POINT_VEC3 and derived POINT_VEC2 classes now also contain Smoke, Flare and Explosion and IlluminationBomb methods. Heres an example how to code an explosion right near your plane: local PlaneUnit = UNIT:FindByName( "Plane" ) -- This can be also other logic, i just need the plane UNIT object! local PointVec3 = PlaneUnit:GetPointVec3() -- This creates a POINT_VEC3 object at the location of the PlaneUnit PointVec3:Explosion( 100 ) -- Explode near the plane with an intensity of 100. Yes, sure, the trick here is to schedule a logic to be executed using the SCHEDULER class. Heres an example, I just copied the code from the test mission and added stuff in red: -- Create a variable PlaneHuman that holds a reference to UNIT object (created by moose at the beginning of the mission) with the name "PlaneHuman". local PlaneHuman = UNIT:FindByName( "PlaneHuman" ) -- Subscribe to the event Crash. The Crash event occurs when a plane crashes into the ground (or into something else). PlaneHuman:HandleEvent( EVENTS.Crash ) -- Because the PlaneHuman object is subscribed to the Crash event, the following method will be automatically -- called when the Crash event is happening FOR THE PlaneHuman UNIT only! --- @param self -- @param Core.Event#EVENTDATA EventData function PlaneHuman:OnEventCrash( EventData ) -- But delay with 10 seconds! [color=Red]local PointVec3 = EventData.IniUnit:GetPointVec3()[/color] [color=Red]SCHEDULER:New( self, function() BASE:E( "Smoking at the position" ) EventData.IniUnit:SmokeOrange() end, {}, [b]10[/b] ) [/color] Can you give me an example what you want to do or achieve? I just added the Explosion and IlluminationBomb logic at the MOOSE framework, under POINT_VEC3. Sync in github and you should have it. My pleasure, and feel free to ask further questions if any. FC

The Anapa airbase seems to be terrible at handling the coordination of airplanes taxiing to the runway from their shelters... Spawn 5 airplanes or more at the airbase. The planes will spawn at the shelters. Slowly the airplanes will start taxiing to the runway. However, suddenly the airplanes will stop. And will keep waiting and waiting and waiting ... No air traffic is anymore possible. Within the moose framework there is a logic that helps "deblock" such situation, but even then, once the airplanes respawn again, they will block eventually. Even at places are they are completely free to go... The planes suddenly stop taxiing and no movement anymore... Check out this video here. The recording shows the planes taxiing and stopping suddenly. The video shows the DCS mission in an increased time lapse. The whole time period is about 30 minutes of mission time. That means, the whole 30 minutes, not even one plane took off from Anapa. Can this somehow be checked. The logic to control the taxiing of planes seems to be bugged. Sven

Dave, if you need help let me know. FC

Si ! :-)

Mission explained by Gunterlund Would like to share with you a very nice video of Gunterlund. He has taken (a lot of) his time to explain you one of his missions, wherein he applies lua mission scripting using the MOOSE framework. His mission has become a dynamic Ground Offensive, where he focuses on the CA module utilization of DCS World. If you're into mission design, I really think you should have a careful look at his work; please take your time watching this video. He walks you through the mission design, explains his lua code that he applied. As a result, you get a comprehensive understanding how to approach a larger mission using MOOSE. Let's thank Gunterlund for his work done here, and hope you enjoy the explanation. FC