FlightControl

Ha yes, even worse then ...

Hi Bushmanni, Thanks for your feedback, your comments make a lot of sense. There aren't that many people in the DCS world who would be interested in this upgrade, indeed ... Only a few, and myself included... :music_whistling: There is no compelling reason why this upgrade should happen, as I wrote in the mail before. But, if such upgrade would be doable, and backward compatibility would be guaranteed, it would be able for a bit more elegant lua in a couple of areas. The first is how finalizers would be coded ... A finalizer is a piece of code, that gets executed when a table gets garbage collected. It is almost like a destructor, only that a destructor gets immediately executed, while a finalizer gets only executed when garbage collected... Let me give an example why a finalizer is useful ... If I set a menu within lua, using MOOSE for an alive group, I can do this as follows: local Plane = GROUP:FindByName( "Airplane" ) -- Find the group of a Client ... Menu = GROUP_MENU_COMMAND( Plane, "Report", nil, ReportFunction, {} )I would like to have the behaviour that, when the Plane gets destroyed, that then also the Menu is removed automatically... Within lua, i am able to simulate this by adding the following code: function Plane:_Destructor() Menu:Remove() endSo, when I execute the following command: Plane = nil collectgarbage()then the _Destructor method is executed ... Within lua 5.1, this behaviour is implemented in a "ugly" way, by using the newproxy method. See the method here: function BASE:_Destructor() --self:E("_Destructor") self:EventRemoveAll() end function BASE:_SetDestructor() local proxy = newproxy(true) local proxyMeta = getmetatable(proxy) proxyMeta.__gc = function () env.info("In __gc for " .. self:GetClassNameAndID() ) if self._Destructor then self:_Destructor() end end -- keep the userdata from newproxy reachable until the object -- table is about to be garbage-collected - then the __gc hook -- will be invoked and the destructor called rawset( self, '__proxy', proxy ) end This is what i have currently in the MOOSE framework written, to implement a finalizer... The code could look more elegant like this in lua 5.2: function BASE:_SetDestructor() self.__gc = _Destructor end So, is not having lua 5.2 a showstopper, hardly ... The second reason to have lua 5.2, is to be able to work with ephemeron tables... setmetatable(mem, {__mode = "k"})This construct is not possible in lua 5.1. The value is strong, but the key is weak. This function would be really helpful in the event dispatcher in MOOSE. It holds references to all kinds of classes that catch events... Once the key to the object is nilled, these objects should also be removed from the event catching table ... In other words, this problem solves the publish-subscribe reference problem. But i am able to solve this in lua 5.1, but need to code extra for it... About the multi threaded, i think you've misunderstood my writing ... lua is not pre-emptive multi threaded. But i just wonder whether in lua 5.2, the yield() would work when a scheduled event re-schedules ... In lua 5.1 i get a crash. But again, am able to work around this ... FC

Guys, really. Is nobody reading my messages? https://forums.eagle.ru/showthread.php?t=153773 Check the date of my post. The 12th of January 2015..., that is almost 2 years ago now? Note that this USED TO WORK till DCS version 1.2.14. When destroying the Group, also the burning units were destroyed, belonging to that group. But from 1.2.14, this behaviour got removed ... I had made a CLEANUP class in the moose framework, that could easily clean up polluted airfields with crashed planes ... I had that CLEANUP class working, until that bug appeared ... It is on the wishlist now. And this behaviour has remained throughout till DCS version 1.5.5. FC

Hi Kyridious, I found the reason why it did not work! There were two reasons, and both were my mistake in the MOOSE framework :doh: Fortunately, I could correct them both. :music_whistling: The reasons where: 1. In the CONTROLLER:TaskFollow method, I had the groupId field accidentally renamed to controllerId in the params structure... I replaced all controllerId fields in the CONTROLLER class file back to the correct groupId field. 2. The second was a bit more complicated. I should set lastWptIndexFlag to false. But I accidentally set it to nil ... So, I correct this in the method CONTROLLER:TaskFollow, and also did this correction in the method CONTROLLER:TaskEscort... So, now all works again. Ensure you replace the Moose.lua with the last version that I've just published on gitgub master. Just resync github, and reload Moose.lua in your mission. A few more explanations are required..., because there is one more important thing to know about DCS ... The reason why spawned units are not following when you execute a setTask command, is that a spawned group needs a bit of time to "start up"... So, when you spawn a group, and immediately after spawning you execute a setTask, then that command won't be executed. This is solved within MOOSE though :smartass: By using the GROUP:SetTask() method, which works just like the Controller:setTask function, there is an additional behaviour what GROUP:SetTask() does: It waits for one second before executing the command... In that way, the spawned group has time to activate, and after one second the command is executed ... Note that within the GROUP class, you don't need to use a Controller at all. The GROUP class encapsulates the Controller classes. GROUP derives from CONTROLLER. Also UNIT derives from CONTROLLER. Thus, using the same CONTROLLER methods, both GROUPS and UNITS can be controlled... Find the code below: [color=Green]--Create Spawn Groups[/color] [color=Purple]local [/color][color=DimGray]SpawnPlane1 [/color]= [b]SPAWN[/b]:New([color=Blue]"Plane 1"[/color]) [color=Purple]local [/color][color=DimGray]SpawnPlane2 [/color]= [b]SPAWN[/b]:New([color=Blue]"Plane 2"[/color]) [color=Green]--Spawn Groups into world[/color] [color=Purple]local [/color][color=DimGray]GroupPlane1 [/color]= [color=DimGray]SpawnPlane1[/color]:Spawn() [color=Green]--local GroupPlane1 = GROUP:FindByName( "Plane 1" )[/color] [color=Purple]local [/color][color=DimGray]GroupPlane2 [/color]= [color=DimGray]SpawnPlane2[/color]:Spawn() [color=Green]--local GroupPlane2 = GROUP:FindByName( "Plane 2" )[/color] [color=Green]--Create Task for plane2 (follow groupPlane1 at Vec3 offset) (Note: I think I need to be using controllers here) --i.e. cntrlPlane1 = groupPlane1.getController(groupPlane1)[/color] [color=Purple]local [/color][color=DimGray]PointVec3 [/color]= [b]POINT_VEC3[/b]:New( [color=Red]100[/color], [color=Red]0[/color], [color=Red]-100[/color] ) -- This is a Vec3 class. [color=Purple]local [/color][color=DimGray]FollowDCSTask [/color]= [color=DimGray]GroupPlane2[/color]:TaskFollow( [color=DimGray]GroupPlane1[/color], [color=DimGray]PointVec3[/color]:GetVec3() ) [color=Green]--Activate Task (Either PushTask/SetTask?) -- PushTask will push a task on the execution queue of the group. -- SetTask will delete all tasks from the current group queue, and executes this task.[/color] [color=DimGray]GroupPlane2[/color]:SetTask( [color=DimGray]FollowDCSTask[/color], [color=Red]1[/color] ) Note the last line above... The last parameter of SetTask is optional, and reflects the amound of seconds to wait before running the command. If not provided, the SetTask method will wait one second. hope this helps, FC Moose_Test_GROUP_TaskFollow.miz

Hi, I've been looking into this, and find that there is something strange going on in the simulator. I am neither able to make the group follow the other group. This is the code that i used in the attached mission. I need to dig on monday a bit deeper into this and maybe this is a bug that needs a report. --Create Spawn Groups local SpawnHelo1 = SPAWN:New("Helo 1") local SpawnHelo2 = SPAWN:New("Helo 2") --Spawn Groups into world local GroupHelo1 = SpawnHelo1:Spawn() local GroupHelo2 = SpawnHelo2:Spawn() --Create Task for plane2 (follow groupPlane1 at Vec3 offset) (Note: I think I need to be using controllers here) --i.e. cntrlPlane1 = groupPlane1.getController(groupPlane1) local PointVec3 = POINT_VEC3:New( 0, 0, -10 ) -- This is a Vec3 class. -- This statement returns a structure. local FollowDCSTask = GroupHelo2:TaskFollow( GroupHelo1, PointVec3:GetVec3() ) --Activate Task (Either PushTask/SetTask?) -- PushTask will push a task on the execution queue of the group. -- SetTask will delete all tasks from the current group queue, and executes this task. GroupHelo2:SetTask( FollowDCSTask, 10 ) Sven Moose_Test_GROUP_TaskFollow.miz Moose_Test_GROUP_TaskFollow.lua

Sorry, it is a little bit hard to follow what your thinking is. Can you pls elaborate a bit more? These kind of problems have to do with the internal mechanisms of the simulator. I don't think upgrading MOOSE will solve this problem. But I think now with the latest 1.5.5, this problem may have been fixed. I am interested if this is the case, and if not, pls do a further confirmation that this bug needs to be solved. thanks Zarma for your support, FC

I understand your question, but need to take time to answer it. Just dropping this note that i saw your question and understand the issue. You make a few mistakes, but want to show you a good example with a test mission. A good example explains it the best, no? So bare with me and hopefully tomorrow i have time to provide you an answer.

Suggest you retest the group bug in 1.5.5. I think it is somehow solved now ...

Hello dwpenny, First of all, let me give you some confidence that you are highly likely not crazy. It is glitchy software that can make you crazy, and probably I am the root cause of this fenomenon ... Let's have a look ... This code looks okay. Here I have a question... There these names in RedRoutes defined as Groups or as Units? You use UNIT using the UnitName defined by the Random Process. The problem is, that UNITs don't have routes. GROUPs have routes. Not sure if this is the root cause of your problem. Ohh, now i see it. So you spawn a new group from the position of a Unit, and then route it using the ... No, wait a second ... UnitName should be a GROUP Name. You're mixing the two. Have a further look into this. This may solve you a lot of problems. Pls check first the code I indicated, if that is okay, but it did not solve the problem, we can continue our search. Hope this helps.

You mean, the ir sams detecting other objects of the enemy and reporting it? like whisper suggested? Moose utilises indeed the dcs detection mechanism. But additional filters could be added to make the detection more "realistic". As i said, like defining some zones where units are less likely to be detected, add a detection "fog" % parameter etc. It is not the idea that we just copy over functions from existing scripts, because that would not be fair and there it's no immediate benefit. I believe in a good requirement discussion first. If you want we can put this dev item on our "todo" list on the MOOSE github. Maybe somebody can extend the current detection capability class with more parameters. Should be quite easy to implement. In order to do that, who is interested needs to craft a summary of the goal or requirements. This can be done on this forum, sharing the discussion. And once the requirements are clear, this can be taken as a co-development under my help and supervision. Good idea? So, ... who is interested to spend some time in this item. Fc

Hi Drexx, Thanks for your feedback. Who did you meet and why is meeting people relevant in this discussion?

Nobody?

Hi Looney, There is a DETECTION class that is the worker class for detection. Can you elaborate a bit further what class you have in mind? The detection class will detect what the unit is capable off. That being said, additional filters and randomization logic can be applied. Was also thinking on maybe put certain zones where detected units cannot be detected at all... Like forests. Should be possible with the use of polygons zones. And yes ... Back in the saddle, but this time a pony. Not a speed race horse like before ... However, making some good progress nowadays. What I am preparing is complicated, and requires a lot of testing and additional development (like onforeseen events I did not think of, only during tests). So, my current priority is the implementation of the orchestration of: Head Quarters (per coalition) <-> Coordinating Multiple Missions <-> Having Multiple Tasks with multiple achievements <-> Multiple Groups <-> Multiple Units (players) that can execute the Task belonging to the same group or different groups ... Implementation is done using Finite State Machines. Currently working on the reporting side, coordinated from the HQ to: - Provide a status report of all active and inactive missions. - Provide a detailed status report of one mission (showing overview of Tasks). - Provide a detailed status report of one task (showing overview of achievements, and who got which achievement and when...). ... The core is finished, but working now on the pheripherals. Sven

Dear ED, Suggest that together with the move to 2.5, DCS world also upgrade the lua version from 5.1 to 5.2.4. One of the main reasons the move would make sense is that 5.2.4 implements table finalizers (destructors). In lua 5.1 I need to help myself with the ugly newproxy undocumented function to build finalizers. The other advantage would be to be able to set ephemeron weak tables. Also note that there are issues with building multiple threads in DCS. For some reason a yielded function crashes when it is resumed through an event trigger. With crashing I mean really crashing... Hehehe... DCS stops working. Highly likely there is either a problem with the local stack of the thread, or the thread got garbage collected... Don't know... Anyway, I have workarounds for both the finalizers and the yield problem. But it would he really nice to upgrade to lua 5.2.4. This is what lua 5.2.4 provides additionally: Lua 5.2 was released on 16 Dec 2011. Its main new features are yieldable pcall and metamethods, new lexical scheme for globals, ephemeron tables, new library for bitwise operations, light C functions, emergency garbage collector, goto statement, and finalizers for tables. The last release is Lua 5.2.4, released on 07 Mar 2015. Fc

I suggest you hold back using materials from development branch for the moment. You'll need to wait until the pieces have fallen into pace. If I release now, some people will get slightly angry :-) Structural changes have happened how the files are organized. When the new stuff is released, all will fall into place. Sven

Lua is a very nice language, and it has a lot of capabilities not found in many other scripting languages. C++ knowledge is not (yet) required to use MOOSE :). Just gain experience in lua. In order not to get lost in lua, I suggest you have a look at the following tutorial pages in order to understand the language constructs of lua. https://www.tutorialspoint.com/lua/ Learning lua is indeed fun, and using MOOSE is a nice way to do that. I'll be posting next year some new videos and rework some old ones, in order to make the learning curve more smooth. But before I can do that, I need to get that new MOOSE release finished and published . Sven

This code you write, could become a function that is added to the MOOSE framework, what about that??? By the way, I see you are using env.info lines. Know that in MOOSE there is a tracing implementation. You can write like this: group:E( "This line will always be traced" ) group:T( "This line will only be traced when tracing is on and level 1 is traced" ) group:T2( "This line will only be traced when tracing is on and level 2 is traced" ) group:T3( "This line will only be traced when tracing is on and level 3 is traced" ) group:E( { "Parameter 1", "Parameter 2" } ) -- this traces 2 strings. local parameter1 = 1 local parameter2 = { key = 2 } group:E( { parameter1, parameter2 } ) -- this traces 2 variables. group:F( { parameter1, parameter2 } ) -- this traces 2 parameters at the beginning of a function... The function name is traced too! group:F2( { parameter1, parameter2 } ) -- this for level 2 group:F3( { parameter1, parameter2 } ) -- this for level 3 Tracing is documented at the BASE class here. Each moose class IMPLEMENTS the BASE class, so it can be TRACED using these tracing functions! I follow your suggestion for the code snippet. Where would you suggest to locate this? Also, your function... After some rework, this could be added to the library in a contribution on github. Good idea? Feel free to post feedback. FC

Hi Shagrat, Thank you for your appreciation. (Feel free to give kudos :D). If you like, you can have a look at the test missions (described one post above) to learn a bit more about the MOOSE framework beyond spawing groups. There is also a youtube channel. My intentions were never to replace mist, but to be complementary with it. In this way, people are served with additional capabilities, and can choose what solution is the best of both for varying mission design scenarios. Have fun FC

No comments :-) Welcome to the club. It is never late to try something new. Just know that this framework contains hours and hours of effort, and encapsulates a lot of complexity to write good missions using lua in DCS. I am about to release something that may be a game changer for mission design in DCS soon. So, you're just on time, not too late at all. Have a look at this video on my youtube channel. This is the way to go. Also know that there are test missions with example lua files. You can learn a lot from these test missions.

Maybe also have a look at this video. It is a bit long, but worth it to have a closer look which tools to download and install and how to setup your development environment. You can explore more videos for further explanations. Some of the videos are a bit old (they need to be reworked when the new release will be published). Check this video: FC

This is fantastic news BSpike, and the way to go. By trying things and playing with the available classes, you'll get a good feeling how these classes work, interface and behave with other classes. Note also that in the MOOSE framework, some test missions are embedded, which have their own examples. You can find these test missions here on github: Test Missions The PATROLZONE function does not work in this version, and neither does the test mission. But the good news is, I have completely reworked the AIBALANCER and the PATROLZONE classes in the upcoming release. In the new versions, the AIBALANCER and PATROLZONE classes work like finite state machines also. You can find the test mission here if you are interested, but these are still in the development branch. I suggest you await a bit the delivery of this release, which I am pushing to deliver in December (finally) while testing PATROLZONE. The development branch with the modified PATROLZONE class is here, but it uses other classes that will be published in the new release upcoming. The reworked test mission in de development branch for the new PATROLZONE is here. It Spawns a new airplane, which when returns to the nearest airbase, spawns a new airplane, which will patrol another zone... Implemented using state machines... Thanks for watching the videos. Suggest you start playing using the SPAWN class. This is the most obvious class in the MOOSE set to learn. While learning, you'll understand better the APIs, and how MOOSE interfaces within your program. If you want to try out something more advanced, suggest have a closer look at the ESCORT class. This class allows to let AI planes escort a player unit. (Standard DCS does not allow to do such), and includes many options to "control" the escorting AI. You can setup 4 escorting AI to follow your human plane. Try helicopters and airplanes. There are no boring questions concerning the framework :pilotfly: Thanks for asking. As you may know, I have had health problems, and was out for a couple of months. But would like to finish this framework, and this is the right tempo. Reading posts, and just replying when I have time. Hope the above helps a bit. FC

CONTROLLABLE is a base wrapper class. Both UNIT and GROUP derive from CONTROLLABLE. CONTROLLABLE implements the DCS "task" functions, encapsulating the DCS Controller object. So, the state machine STATEMACHINE_CONTROLLABLE can govern the behaviour of a group or unit through state transitions. Happy you like the initiative. There is still some work to do before publishing. But thought of already introducing it and obtain feedback. Todos are: - make references to processes weak, to allow garbage collection. - when a task finished, all contained objects should be cleaned up nicely. No process may run, no hanging events etc. - test missions workflow. - complete SEAD and A2G task templates using the new API. - revise DETECTION and automatic task assignment. - document changes - document functions added - retest test missions - make release note - publish Then make training videos and that is where the fun starts.

Let me give a simple example. We will create a state machine to control a unit. local FsmUnit = UNIT:FindByName("unitname") local Fsm = STATEMACHINE_CONTROLLABLE:New( {}, FsmUnit ) -- Now we create 2 state transitions. Fsm:AddAction( "Stopped", "Start", "Moving" ) Fsm:AddAction( "Moving", "Stop", "Stopped" ) -- Set the initial state as Stopped. Fsm:SetInitialState( "Stopped" j -- Nothing happened till this point... -- But now, we fire the event "Start". -- 2 Start and two Stop functions are automatically added to the Fsm object. -- Fsm:Start() will fire the Start event immediately. -- Fsm:__Start( 1 ) will fire the Start event asynchronously after 1 second... -- Similar with the Stop event... -- Just remember that event functions starting with __ are asynchronous. They get a parameter indicating the seconds to wait until the event is fired. -- But now, we fire the event "Start", asynchronously. Fsm:__Start( 1 ) -- So now, the Fsm will transition from state "Stopped" to state "Moving". -- But unfortunately, nothing will happen unless we program the Fsm to control the given CONTROLLABLE, in this case FsmUnit. -- For each state, we can build a method to catch the state transition when it enters the state, or when it leaves the state in the Fsm. -- Build a method starting with onenter concatenated with the State name, and this function will be called before the state transitions. -- Build a method starting with onleave concatenated with the State name, and this function will be called when the state transitioned. function Fsm:onenterMoving( FsmUnit, Event, From, To ) FsmUnit:Start() self:__Stop( 5 ) end function Fsm:onenterStopped( FsmUnit, Event, From, To ) FsmUnit:Start() self:__Start( 1 ) end -- This implementation will start FsmUnit in 1 second, stops FsmUnit after 5 seconds, and repeats this process... This is a simple example, and Fsm hierarchies have not been touched upon yet... Note that this functionality in moose is not yet published on the master branch. It is hiding in the branch Spawn-Randomization. You can try this out... I am a little bit worried how this new functionality is to be explained to a large audience of varying lua and DCS experience... But that is a worry for later. FC

Gents, Small update on the MOOSE framework ... In the background during the times when I was not sick and feeling good, I've been slowly working on API improvements for the new Tasking module set. Now today, I finally got it working, although it is not yet published. Find the underlying example task script to coordinate a SEAD mission. The advantage of this is now, that one can use pre-defined process patterns as sub processes to implement a task. These are these PROCESS_... type of classes that are given as a parameter. local Mission = MISSION:New( 'SEAD Targets', "Strategic", "SEAD the enemy", coalition.side.RED ) local Scoring = SCORING:New( "SEAD" ) Mission:AddScoring( Scoring ) local SEADSet = SET_GROUP:New():FilterPrefixes( "Test SEAD"):FilterStart() local TargetSet = SET_UNIT:New():FilterPrefixes( "US Hawk SR" ):FilterOnce() local TargetZone = ZONE:New( "Target Zone" ) local TaskSEAD = TASK_BASE:New( Mission, SEADSet, "SEAD Radars", "A2G", "SEAD" ) -- Tasking.Task#TASK_BASE --:New( Mission, SEADSet, "SEAD Radars", TargetSet, TargetZone ) local FsmSEAD = TaskSEAD:GetFsmTemplate() FsmSEAD:AddProcess( "Planned", "Accept", PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ), { Assigned = "Route", Rejected = "Eject" } ) FsmSEAD:AddProcess( "Assigned", "Route", PROCESS_ROUTE_ZONE:New( TargetZone, 3000 ), { Arrived = "Update" } ) FsmSEAD:AddAction ( "Rejected", "Eject", "Planned" ) FsmSEAD:AddAction ( "Arrived", "Update", "Updated" ) FsmSEAD:AddProcess( "Updated", "Account", PROCESS_ACCOUNT_DEADS:New( TargetSet, "SEAD" ), { Accounted = "Success" } ) FsmSEAD:AddProcess( "Updated", "Smoke", PROCESS_SMOKE_TARGETS_ZONE:New( TargetSet, TargetZone ) ) FsmSEAD:AddAction ( "Accounted", "Success", "Success" ) FsmSEAD:AddAction ( "Failed", "Fail", "Failed" ) TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 ) TaskSEAD:AddScoreTask( "Failed", "Failed to destroy all target radars", -100 ) TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 ) TaskSEAD:AddScoreProcess( "Account", "Fail", "failed to destroy a radar", -100 ) function FsmSEAD:onenterUpdated( TaskUnit ) self:E( { self } ) self:Account() self:Smoke() end -- Needs to be checked, should not be necessary ... TaskSEAD:AssignToGroup( SEADSet:Get( "Test SEAD" ) ) Mission:AddTask( TaskSEAD ) The above is a declaration of a workflow. It is in fact a "Hierarchical Finite State Machine (Fsm)" implementation ... You declare a Task using TASK_BASE. Later, task templates will be added in derived classes. The already existing TASK_SEAD and TASK_A2G in the MOOSE framework need to be reworked to this new method now. Each TASK_BASE instance has a Finite State Machine (Fsm). It is embedded within the Task, and serves as a template when Units (Players) join the Task and are assigned to it. When a player joins a unit, that is belonging to the Set of Groups that can be assigned to the Task, the Task will allocate a new Finite State Machine for that Unit. In other words, each Task has multiple running Fsm as there are Units assigned to the task... The Task itself is also an Fsm, but governs the status of the task, meaning, the results achieved and whether the task is planned, ongoing or failed. The function local FsmSEAD = TaskSEAD:GetFsmTemplate() retrieves the template. This template Fsm needs then to be filled with state transitions and sub processes. The function FsmSEAD:AddAction ( "Rejected", "Eject", "Planned" ) adds a state transition based on an event. Read like this: Allow the state of the state machine to be transitioned from *Rejected* to *Planned*, when the event *Eject* happens. Other example is: FsmSEAD:AddAction ( "Arrived", "Update", "Updated" ) ... Then the question comes, how are these events fired? Well, ... Each Event declared within the Fsm can be catched, each State within the Fsm can be catched, by declaring separate functions with your own logic. The example underlying catches the change of the state of the Fsm, when the state changes to *Updated*. function FsmSEAD:onenterUpdated( TaskUnit ) self:E( { self } ) self:Account() self:Smoke() endWhen the FsmSEAD reaches the state Updated ( therefore prefix onenter ), the function is executed... Within this function, you'll see the line self:Account() and self:Smoke()... These 2 lines fire the events Account and Smoke within the Fsm. Next ... The function FsmSEAD:AddProcess( "Planned", "Accept", PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ), { Assigned = "Route", Rejected = "Eject" } ) adds a Sub Fsm to the master Fsm. The class PROCESS_ASSIGN_ACCEPT:New( "SEAD the Area" ) is a state machine itself and the reference to the instance is given as a parameter to the AddProcess function. Read the line as follows: Add a Sub Fsm to the master Fsm, and when the event Accept is fired, execute that Sub Fsm... The return states of the Sub Fsm can be Assigned or Rejected. When the return state is Assigned, the master Fsm state will be set to Assigned, and the event *Route* will be triggered AUTOMATICALLY! Similar, when the end state of the Sub Fsm is Rejected, the event Eject will be fired automatically! In other words, Sub Fsm classes implement predefined Fsm patterns, do some processing and return a resulting state... Many different types of Sub Fsms can be constructed now, which mission designers can use within their missions. Scoring ... Because we have state machines, we can add scoring events to the state machine. When an Fsm reaches a certain state, one can use a couple of functions to set a score, with a text, that is displayed to the coalition for which you are playing for. The examples are: TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 ) TaskSEAD:AddScoreTask( "Failed", "Failed to destroy all target radars", -100 ) TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 ) TaskSEAD:AddScoreProcess( "Account", "Fail", "failed to destroy a radar", -100 )The function TaskSEAD:AddScoreTask( "Success", "Destroyed all target radars", 250 ) adds a score of 250 when ALL of the target radars are destroyed within the test mission. It is given when the *master Fsm* reaches the state Success. The function TaskSEAD:AddScoreProcess( "Account", "Account", "destroyed a radar", 25 ) adds a score of 25 when ONE target is destroyed within the test mission. It is linked to the state change within the Sub Fsm under the event Account. When the Sub Fsm reaches the state Account, the score is added, and a text is displayed to the coalition for which you are playing. Why all this explanation? Because this provides now a VERY DYNAMIC mechanism to implement quickly missions, re-using pre-defined workflows (Finite State Machines), which are tested and used within several missions, and that are working. You can build you own flows for a task, you can build multiple different tasks, and assign them to a mission. You can implement multiple missions, with multiple tasks assigned to different groups... That goal is coming really close now.

Does the M818 have a route and did it move towards the HMMWV? Or is it just spawned and sits there? Also, is the M818 of the same country as the HMMWV? Try to spawn the HMMWV using the EXACT structure as in the mission file. check if that works.