FlightControl

+1 I agree.. Done now about 1100 posts, contribute a lot and the system of reputation is clearly bollocks. :doh: But was just wondering, hence my question :music_whistling:

The only thing is, they block airbases. All stops moving...

Ib think I have a solution for you... It would be similar as the SEAD class in moose. Catch the shot event. When it is a human shooting, deactivate the ground immortality... Or, measure the distance when a human player is near... When near, deactivate the immortality...

How is the reputation calculated that is on your user? I received some reputation mails? And the reputation is growing, but slowly. More slowly than how I receive reputations etc. Any idea?

On this one I completely agree. If you're looking for an alternative method, have a look here: This will simply your mission building a lot.

Hi there, you wrote that lua doesn't do a lot... Can you elaborate a bit more on this? I mean, why do you say such. Am afraid you're missing out on the good stuff... FC

On top of my reply, there is a link higher at the page too... That one works.

Thank you. The one at the bottom of the page right? I'll check it and fix it. At least now I know somebody is reading those manuals. ::music_whistling:

2. If you don't know the group... Let me tell you, you always know your group... And you always know the amount of units inside the group. In moose, just search for the GROUP object using the method :FindByName( "Name" ) or, if you have the DCS Group object ( From the DCS API), you can get the corresponding GROUP wrapper object using :Find( DcsGroupObject ) You get the DCS Group object for example when you develop a DO SCRIPT at a waypoint in the mission editor. The DCS Group object is given in the ... "Variable" (yes. 3 points), so when you want to control the group for which the waypoint is, you can just write MooseGROUPObject = GROUP:Find( ... ) as the first statement in the DO SCRIPT. Having the MooseGROUPObject, you can retrieve the amount of units with AmountUnits = MooseGROUPObject:GetSize() Note that you can also write ...:getSize() to retrieve the amount of units in a group, using the DCS API. Fc

1. RTB event: The AI_ classes send the AI back to base in 3 situations: - The group is out of fuel beyond a given treshold. - The group is damaged beyond a given treshold. - The RTB event is programmatically called... In these cases, the AI will land. Now... When you're using the AI_BALANCER to have the AI being balanced, the AI_BALANCER class will automatically respawn the AI, using the SPAWN object provided in the :New() constructor of the AI_BALANCER. In this situation, you have to do nothing. When you're using the SPAWN class or the GROUP class to respawn your AI, YOU'LL HAVE TO RESET your AI_PATROL_ZONE, AI_CAS_ZONE or AI_CAP_ZONE objects. The objects will have the state "Returning" due to the fact of the RTB event. You can reset the objects easily with the :__Reset( 1 ) or :Reset() event triggers, which reset the AI_ objects processes asynchronously or synchronously respectively. Note however, that you'll need to restart the processes again using the :__Start( seconds) or :Start() event triggers. Or maybe you can make it up yourself. Let me know. Let me try to write a demo showing this. FC

Just published these modules on github. Also new videos of the CAP module demos (including how to code) have been published on YouTube. So, subscribe to the channel if you want to receive updates Fc

Added some new videos to process a CAP, CAS and PATROL All, Please find these new playlists on the youtube channel, explaining the concepts behine 3 new classes that will be added to the MOOSE framework very soon: AI_PATROL_ZONE: Patrol a zone, detect targets, don't engage. AI_CAP_ZONE: Patrol a zone, detect targets and engage intruders through Combat Air Patrol. AI_CAS_ZONE: Patrol a zone, detect targets, and engage within an Engaement zone to prform Close Air Support. These classes are currently in beta stage, meaning, they will have issues, BUT, as people start using them and the issues are resolved, these will become very good objects to heavily simplify mission building using the MOOSE framework. Demo missions and videos will be added ... So, subscribe to the channel if you want to receive updates. Here are the new playlists to watch out for: Patrolling: Combat Air Patrol: Close Air Support: kind regards, FC

Good question. First of all, ED should not change things without an early notification. We can keep the assumption that the DCS API is backwards compatible from version to version. So, the framework should provide a stable future. That being said... If ED does change a function (this has happened), then there is always the risk that the framework needs to change too. But there is some difference in what moose does and what mist does. Moose models processes, and wraps complexity. So does mist, but at a lower level. So, the risk that if ED changes something, that moose also needs to be adapted is less than with mist. It also helps to overcome bugs. I was able to overcome the client group bug without having to change syntax in the moose framework. All was solved internally through a workaround enabling at least to set menus on groups and send messages through obtaining the group id through the templates. Of course, could not solve all, but neither could mist, but it did help the guys who used CLIENT as the class managing slots. The risk with moose however, is that since I am not perfect and don't have a glass bowl, that I made a mistake in a design and may have to ask you to change somethings. These changes will be well communicated and will be limited to textual changes. But since your mission script that you developed using moose is in one file per mission, change management is a lot easier. As classes are more used and optimized, the risk that something has to change will decrease over time. So, in a nutshell, the risk will always be there, but I really try to minimize that risk. On the other hand, as history shows, dealing with ED bugs is a suffer for all who do scripting, with or without moose or mist. It speaks for itself that there is a trade off to be made for those who want to use a framework, having the advantage to do complex things faster, but with an extra dependency on some code written by a Belgian. Those who don't want to take that risk i advise to stay away (never trust the Belgians). Just know that the code is managed and I hope that in the near future there will come some recognition from ED to provide better means to foresee the future.... Like sharing an early release of dcs for regression testing using defined use cases. Ib promise you however that the AI_PATROLZONE will change, Hehe my question, who is using it? Sven

Send me a PM with your email. You'll receive an invite from slack.

Guys, who is using AI_PATROLZONE already in their missions? Would like to rename the class to AI_PATROL_ZONE, to get the naming consistent. I guess not many people are already using it, right, as it is new. Sven

Whooo, Wingthor, you need some training, are you on our slack channels already? Sv.

There is a very easy solution. Suggest you learn the SPAWN class in the Moose framework, and you'll be doing the show in no time... A bit of very simple lua coding is required.

Yes, but it is disabled by default in dcs to prevent other embed malicious code in their missions. On the server side however, there are more possibilities. Modify the missionscripting.lua file. Erase the sanitisation of io and os modules. And you have a lua function called os.execute.... Check here... http://www.lua.org/manual/5.1/manual.html#pdf-os.execute

Try a lua framework. These help to put trace of variables etc, which can be conditionally switched on and off... Like this one: http://flightcontrol-master.github.io/MOOSE/Documentation/Base.html Hopefully this helps.

Hi there, thanks for your interest. You understand the idea, but it is normal you're having difficulties with the syntax and coherence of the objects. A good example tells a thousand words. Ok see if tomorrow I can provide you with an example link. Maybe have a further look in the meanwhile to those videos posted today.. Gori valley may he out interest to you. Fc

GORI VALLEY Started with some real handson sesssions how a complete mission is created: Gori Valley. For this, refer to the following playlists on youtube: FC

@Ignition, I understand where you are coming from, but maybe the way you formulated it is a bit harsh. The mission editor is good. It has many functionalities that allow you to create nice missions, without having to code anything. It also is a great platform to "try things out". I mean, it inductively does more than you think. There are indeed things we want to see improved, but still, it is what it is. Not going into details here, as other posts and threads are for this. Let's call it that the ME has its limits. For those who want (to try) more, there are solutions. It is either: - Use the core DCS API. - Use frameworks like MIST or MOOSE. - Use both. Learning lua is not a bad thing to be honest. If you learn to code, you'll find a new world and it will open your horizons or just for plain amusement. I know not everyone will agree, but that is normal too :-) It is very hard to create a mission editor "that can do all". And if such would exist, it would become so complex, that this fact would hold off people from the product too. Wouldn't you agree? FC

MOOSE ... Spoiler

CARGO - Board / Unboard / Transfer cargo groups and units Hi, find some videos explaining how to board / unboard and transfer cargo in the form of groups and units. More will follow.

@BIGNEWY and @GRIMES, I promise you, I will keep in the background silently observing the progress. There is challenge enough with the MOOSE framework to continue its development and manage its user base. But I do have this hope, that one day, the AIRBASEPOLICE and the CLEANUP classes will function, and that TASKING will work for clients more than 4 units... So that this functionality can be fully released to the people who are awaiting it, and that my friends, is not just me. It is a larger group of people. That being said, if I find other self declared urgent bugs, I will report them discretely..., in the trust that people DO care, and will solve them. Sven