FlightControl

Birger, can we talk about this please? Sven

Check here for the menu options in moose. http://flightcontrol-master.github.io/MOOSE/Documentation/Menu.html Menu test and example missions here: https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/MEN%20-%20Menu%20Options Overall documentation here: http://flightcontrol-master.github.io/MOOSE/ Have a look if this is something you are looking for... FC

Tomorrow we'll get your stuff together Hafody :-) We're almost there, aren't we? FC

I create test missions to have existing test scripts and test missions available for regression testing per release or conducting major changes in the framework. It is a lot of work, but it has helped me a lot and has avoided me wasting time cleaning up the damage after an unwanted publish. These test missions provide a valuable source to guarantee functional stability and also provide a trainer and teaching platform for users of the framework. FC

Maybe contact me if you are interested. I am not going to advertise here the framework, avoiding to step on unwanted toes, but just send me a PM if you're interested what we are working on... FC

Found in a test mission at an MBT M1A2 Abrams cannot be destroyed by AI KA-50 with Vikr. This is an annoying and unusual problem. Suggest the team to have a look at this. I'll post a demo mission today showing the problem... Sven

Anybody using CONTROLLABLE:EnRouteTaskEngageUnit()? Because I am reworking that API.

Thank you very much for your very informative and well written document. The pictures are of great quality. Fc

THANK YOU! BIGNEWY, Thanks for making this thread a sticky on the eagle dynamics forums. To the forum moderators, thanks for supporting this. It has been quite a ride, a bumpy one but we're still driving! One day got into this crazy idea to start making an object oriented framework. I had been experimenting with the OO capabilities in lua, and was sold. A good OO model I thought would be an ideal way to simplify things for mission designers, who want to express their creativity designing missions in a more advanced way than what the off-the-shelf mission designer functionality can provide. The framework is now about 1,5 to 2 years in development. The main challenges were to get a small motivated user base and extend the framework while it was being used... Slack.com has proven to be an enormous asset achieving this. Right now, there are about 59 people on Slack, of which (I think) 30 "active" users. On top, various social media like YouTube, the ed forums etc have helped to grow the user base. There are right now 128 subscribers to the moose channel on YouTube. So, as you can see, the development of this framework was in multiple fases. Right now, one can say that the FOUNDATION of the framework has been developed. On top of the FOUNDATION we're BUILDING all kinds of appliances. That building process may take easily another year or two. There is sooo much that can be built ... AI orchestration, TASK orchestration, FUNCTIONAL mechanisms etc. So, the framework today, is there, and more will be added into it in the future. And not only by myself, but also by some motivated users who know how to code lua and who are TODAY looking into adding their ideas into the framework. We've had fun discussing ideas, requirements, designs while providing support. In other words, if we are patient, work together, and carefully plan the added developments, I am sure this framework will become an important asset for DCS mission designers. You who are on slack know what this means by now :-) I would like to say my thanks to: Pikey, Delta99, whisper, entropy (132nd), looney (132nd), dooom, gunterlund, stone house, wingthor, afinegan, gromit190, Dutch baron, dwpenny, hijack, mechanist, quax, ripcord, stuka and many other virtual squadron members and individuals! Some know 2016 has been a hard year for me due to medical reasons, but 2017 is looking good! Before I end this email, would like to express a special thanks to Grimes for his continuous support and patience. If he wouldn't have documented every API and DCS feature with the quality that he does, the development of this framework would not have been possible. I hope that one day we may join forces somehow... Thank you! Fc

moose example Not an answer with mist, but with moose... local PlaneSpawn = SPAWN:New("Planegroup") PlaneSpawn:InitRepeatOnLanding() PlaneSpawn:Spawn() Once the plane group lands, it will be respawned at the original position defined in the mission editor. Check here: http://flightcontrol-master.github.io/MOOSE/ Fc

Thanks David, These pics were really helpful. The devil is always in the details, isn't it... I think I know what the problem is. The video explained you to create a workspace under your user. Something like C:\users\user_name But, that seems to conflict with the moose project data, which is normally stored in C:\users\user_name\documents\github\moose Now the problem is, I think, that when you create a workspace in C:\users\user_name, it will think your whole user directory is a workspace. Maybe it is better to create the workspace under C:\users\user_name\LDTworkspace I think then your problem will be solved. Fc

Ahhh. I think I understand the problem ... When I did the video, the LDT project files were does on my PC already... Try to configure a new project then. See how that goes. Ill look into this issue when I get back home. Fc

Guys, about the 2 hard drives... This comes to me as a total surprise and I can't test it at the moment. Is the anybody who has LDT installed on C:, workspace on C: and moose integrated on C:? Who can help with this? Sven

You need to press the next button down below. If that does not help, Do a screenshot of the dialogue box and put as a reply.

Dunno. Suggest you try it. I would be really surprised if this was the case.

Hi Scott, First of all thanks for your efforts and very detailed answer. This is a long post, so suggest to comment on quoted fragments and then make a summary at the end. If I say something that is not correct, pls react. Yes, the concept of the moose framework is to provide components that allow you to exercise the basic process, but provide flexibility to extend the process with own mission specific steps within that process. And that with a standard interface and API. So other moose components may tailor the process to a more complex one. You are right, the current implementation of the detection handling of AI_PATROL and CAP will is for each plane separate. That being said, GCICAP was neither written on one day, completely bug free containing all the functions. So, the EWR network consisting out of AWACS and ground radar stations is not yet implemented in moose. But... There are a lot of components already in that can be extended and applied to enrich the patrolling and cap process... Thinking of an interface where an EWR network would become a separate component derived from the existing detection class, that takes a set of units that form the network and filters targets based on detection parameters (altitude, speed, distance, type). This EWR component can then by applied by the mission designer by creating an object from it. The object can then be "attached" on the different patrol and cap objects to receive it's detection source. The COMMANDCENTER component in moose can be used to extend it's functionality to governing the target assigning by creating maybe an EWRCC class. Details of the design to be further distilled. This kind of functionality is already implemented through AI_BALANCER in combination with AI_PATROL/CAP. so, you mean, additional caps will spawn, right? Ok. Yup. And a logic is needed which plane goes RTB, based on damage, fuel, arms state. Various parameters exist to set the moment when to rtb, when to respawn. It is up to the mission designer if he wants to randomize between does asked how to do it for the moment... Point taken. In moose, you have the ZONE classes, with model does out various types with various behaviour. Polygon, circle, moving circle. Other side type implementations can he added. On what you describe above, a couple of switches could he implemented in the ZONE be class, that allow to "switch on", "switch off" a zone. This would he detected by the command center, right? Thre moose "moving zones" will moose the AWACS flying in it. Ok. So, to wrap up, components are to be added within moose to: 1. Govern target detection through ask EWR network. 2. Govern target assignment through a well thought algorithm, represented by a command center. 3. Deal with Airport captures. 4. Various "hot" scramble and RTB scenarios. 5. Resourcing. 1 and 2 seem to me the most useful to he implemented in the short term. The components to implement 1 is already in moose, but needs to be tailored to EWR. The implementation of two will be more effort. Let us contact each other on the MOOSE slack channels to discuss the details, or we can use this thread too. Overall this seems to me a fun thing to look into (this year), maybe something beautiful will come out with added value/functions. Sven

Hehe. Have fun guys! Happy you enjoy.

Thanks for communicating this. didn't know. If you have more questions, just ask

Tell me, what are you missing out after watching this video: Fc

Ehhh... Your workspace does not have to be on the same drive letter. In the video I advise you to store the workspace on your user profile. Hope that helps.

Hello ENO, Where are you looking regarding the 5.2? The IntelliSense should popup immediately when it should popup. What is meant with auto generate? Sometimes however, because the IntelliSense parses the documentation in the sources combined with the sources itself, it seems to hang when it would popup a window. And then nothing. When you see that happening, retry and then it will work. A small annoyance in a huge area of advantages. Fc

Right click on the Moose_Framework project in the project list. Select preferences or settings. Check if the source directory (the directory with the sources) has a reference to "Moose Development/Moose". You can recognize this source directory on the form of the icon. It has a hash mark in it. Check an example in this link: http://flightcontrol-master.github.io/MOOSE/Installation/LDT_Moose_Framework_Finish.JPG Contact me on slack in case of further problems. Fc

Nono. The development environment of dcs is lua 5.1. Check this post here on the subject. Not many people had a clue what I was trying to say i think though... https://forums.eagle.ru/showthread.php?t=177732 Fc

Okay, have a look what delta99 wrote. He may also have valuable info. Check what is in the Moose Development/Moose/Dcs directory.

Okay, I see... The source path in Eclipse should be: Moose Development/Moose Under the Moose directory you should have the following directories: - AI - Action - Core - Dcs - Functional - Tasking - Wrapper It is the DCS directory that is not synced automatically. I have been writing up an installation manual. It contains screenshots what to follow. http://flightcontrol-master.github.io/MOOSE/Installation.html I urgently need to redo these install videos and remove the old one. Out is confusing people. But since I am a father of a large family, my time is limited. The earliest you'll see these videos is Tuesday to Thursday.