FlightControl

KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPrefixes( [color=Red]{ "DAR", "SAM" }[/color] ):FilterStart() Mind the {} !!! I am having a bit a difficulty to understand why you are asking this or your question overall. Why is it important to know if a unit has been late activated and Destroyed? Can you bring some light on the context for this requirement? Hope this helps, Sven

Your nose is in excellent condition Gunterlund!

Excellent Idea! I'll make work of that! 1. A link to the documentation pages that are relevant! 2. A link to the test missions that are relevant! You see gents, I know the framework is used. But this thread is always a bit silent. I don't have a real visibility who is using this framework :-) So great!

Now I understand your confusion... I am sorry, I should have thought about this ... So the return values are confusing, and result the debug to react strange. So variables which have the value "nil" aren't traced anymore in the dcs.log. So once the Red group is destroyed, the method GROUP:IsAlive() will return nil, which means that it won't be traced anymore. ... I will update the demonstration mission to make this more clear. I had to implement it this way, because late activated units aren't alive but they do exist. So GROUP:IsAlive returns false when the group is alive, but late activated. It returns nil if not existing anymore. The three return values come in very handy though ... You can test the "extra" bit ... 1. Test if the Group is alive: if Group:IsAlive() then ... end 2. Test if the Group is alive, but inactive... if Group:IsAlive() == false then ... end 3. Explicitly test if the Group is destroyed: if Group:IsAlive() == nil then ... end And there is a 4th test that is actually very handy now: 4. Test if the Group is destroyed or late activated... (not alive): if not Group:IsAlive() then ... end So, the not operator will interprete nil as "not true" and false as "not true". A nice property of lua, but you need to be careful and know this. As this may provide some strange results... This is the kind of stuff that i really love to help with :-) (Hope this helped!) Sveni

Testing GRP-100 now ...

Ha YES! Late activated units are live, but actually they aren't! So, what i do is, i let IsAlive() return 3 possible values: Return values #boolean: true if the Group is alive and active. #boolean: false if the Group is alive but inactive. #nil: if the group does not exist anymore. So, it will return false if the Group is Alive, but inactive... It will return nil if the group does not exist anymore. See the documentation here: http://flightcontrol-master.github.io/MOOSE/Documentation/Group.html##(GROUP).IsAlive Is this what you are looking at? Sven

Suggest you do format c: and d: And take a vacation like I am going to do.

Just released a patch towards version 2.2.1. This patch brings a change how the Defender AI controlled by AI_A2A_DISPATCHER (namely in the A2A tasks) are defending themselves when being fired upon. Changed the Rule of Threat from Passive Defense to Evade Fire for the airborne AI. This upon a request by the Mudspike squadron. Download the latest version from the Release: https://github.com/FlightControl-Master/MOOSE/releases

Indeed. Look at (most) the examples of the MOOSE demo mission and it uses a mission start trigger to load moose and a mission start trigger to load the mission. But indeed, one can opt to make one mission start trigger with two actions. The result is the same. What is not okay, is to have a "run only once" trigger being used. That is incorrect, because there is a slight delay in that trigger, which may give problems. Thanks for sharing these best practices Stonehouse.

Just note gents that release 2.3 will be a lot about cargo handling in the moose framework .... - infantry loading, unloading - Slingloading from pickup zones and to deployment zones - cargo tasking (players handling cargo)... - cargo transportation of AI - cargo handlers, which do medivac, manage cargo respawning, etc. - cargo coordinate management (location in LLDMS, LLDDM, MGRS, BULLS, BR) - menu system - player achievement scores of cargo transportation goals - coalition achievement scores of cargo transportation goals - and that in the moose philosophy and existing framework principles and capabilities, which means: 1. Cargo handling is done through finite state machines. That means that at specific fases of cargo management, there will be events and states exposed, which can be "handled" by the mission designers and add custom logic. for example, upon a deployment of a cargo at a deployment zone, a message or a new spawn or activation of units can be done easily. 2. Extendible ... A framework class hierarchy which will allow future expansion into other modules. 3. Simplicity. An easy setup with a lot of defaults. 4. Use the LDT environment for IntelliSensed coding, and fully documented. 5. Multiple layered, which means that different classes will be involved that handle cargo, and at the top system all these classes are used; But the Mission Designer can choose to make its own CARGO handling system by using the more lower level cargo classes only. There are already some cargo components in the system, but it will be expanded. Sven

It never worked actually. It never did. On top: getPlayerName() is returning a blank string for CA units in MP. So you don't know WHO is in the CA unit. I will post a test mission to resimulate this problem in MP. One that clearly demonstrates why this is needed, which is: 1. One cannot detect which player is in which CA unit, which impact the scoring. 2. Menus and other settings are generated upon the S_EVENT_PLAYER_ENTER_UNIT event, which is not detected, and therefore, no menus are generated. I have tried every workaround imaginable that i could think off. And it just is not doable to work around this issue. 1. BIRTH events are working for planes, but are not valid for CA units, as they are already alive. 2. getPlayer returns a blank string, which means that you can detect that there IS a player in the CA unit, but you don't know WHO. 3. coalition.getPlayers() is neither returning the player. So, in a nuttshell. Until this issue is fixed, ground operations support in MOOSE will be very limited... - No scoring for players hitting and destroying CA units. - No group menus set for players entering a CA unit. - No messages upon specific events directed to CA groups where the player is in. In other words, tasking for CA units is simply not working and is not functional. Only for planes and helicopters. ...

So this is the answer: From BIGNEWY: https://forums.eagle.ru/showthread.php?p=3260553#post3260553 Okay, is there a good understanding what is the impact of this error at ED?

@ED, Can we please get the S_EVENT_PLAYER_ENTER_UNIT problem investigated? It is blocking the functional consistency for CA units in missions. It cannot be detected in MP if a CA unit is occupied by a player. It works perfectly in SP. Can you please watch this video.... Un9S67NDoLg This impacts proper scoring, menu setting for groups etc. Sven

Are your planes loaded with weapons at start?

Guys... Start the server. You have the detailed logs. Jump into a plane... Simulate a connection loss... ( drop internet or hard close client in Windows). Does that generate the crash?

Yup. Good you found that. DESIGNATE does work. But there may be a few things you would wanna see improved or different. So feel free to write feedback or additional ideas. Note that if you want to change the coordinate formats from BR to LLDMS or LLDDM or MGRS, you need to use the A2G settings menu. The default settings can be managed at the HQ unit using CA module (jump into the hq unit). 3 persons have been providing a lot of feedback already on DESIGNATE, as the issue logs on GitHub show. If you later implement A2G tasking, you will see additional stuff... Use TASK_A2G_DISPATCHER, for that.... I like to let helicopters performing FAC, patrolling in a zone detecting targets. Especially the AH-64D or the MI-28N are good units to perform that role as they have ground radars... Let them fly low and slow., and do pop ups once and a while.... Sven

In the FAC template in the mission editor, add 2 commands at the first route point: Invisible, Invulnerable. The commands are taken and executed when the plane SPAWNs. Fc

It depends how you use SPAWN. When you use the InitLimit() method of SPAWN, all groups are spawned late activated in advance. When you use InitArray(), it even makes them visible before start... Nice to make large battalions visible in missions. Unfortunately, DCS had a new bug introduced in multi player. When groups are visible before start, dynamically spawned but late activated and visible, and when clients connect, the group activations on the server are not synced to the clients. The server will have active groups, and the client won't see them... But this only happens when visible before start. Another fix for ED todo. This issue was with dcs before, and it has returned:-(

2.1 has a completely revised parking spot logic implemented. I know, because I've been building the "SpawnAtAirbase" method of the SPAWN class in MOOSE, which behaved different in 2.1 versus 1.5.7. So I found out that 2.1 is adding 2 additional fields to airplane templates in comparison with 1.5.7...

Moose SPAWN ensures that it has all units spawned at the start of the mission. Late activated. Then it activates them when the spawn every is called... Without performance impact indeed. Like 600 units with various options like random routes, random zones, random templates, random .... http://flightcontrol-master.github.io/MOOSE/Documentation/Spawn.html#SPAWN

The stuttering has been fixed. We found the root cause and ED fixed it.

Hi all, You knew it was coming, well, here it is ... Release 2.2.0 of MOOSE The new Release 2.2.0 of the MOOSE framework has a focus on bringing or extending the A2A and A2G capabilities! It brings a lot of fixes and optimizations. The latest moose.lua file can be downloaded from the MOOSE Release Page ON GITHUB Download the moose.lua and include in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework. Find here a short summary of each added major function block, with a link to the documentation. 1. Setup an advanced AI Air Defense System The AI_A2A_DISPATCHER is a new class, that brings a GCICAP capability to be used by mission designers. It is very versatile, introduces squadrons located at specific airbases. The GCICAP is not a one to one conceptual copy of the existing GCICAP script, a lot of new stuff has been added, lots of improvements have been made, and more flexibility has now become possible to tweak the behaviour. Per squadron defined, specific options can be set: Execute Control Air Patrol (CAP) at defined zones. Execute Ground Control Intercept (GCI) towards intruders. Define the defense overhead, meaning, the amount of defending planes to be spawned based on the attackers counted. Define the grouping of the defenders, group per 1, 2, 3, 4. Define the border zones Define the take-off methods. Define the landing methods. Resource management. Airborne Refuel management of CAP planes. A derived class from AI_A2A_DISPATCHER is AI_A2A_GCICAP, which brings a more end-user friendly implementation, where noob users can configure easily a defense system and visually place the squadrons on the defending airbases and define the zones. A lot is defaulted. 2. Dispatch INTERCEPT, ENGAGE, SWEEP tasks to online players The TASK_A2A_DISPATCHER defines tasks for human players to engage upon in order to accomplish a larger mission, and is the human counterpart of the AI_A2A_DISPATCHER. The system provides a true dynamic environment for mission designers and players to define exciting missions. The system uses the DETECTION_ class suite to detect targets, which are reported to a COMMANDCENTER. The COMMANDCENTER is then collecting and grouping the detections and planning or assigning tasks to individual players who are logged onto the server. A complete menu system is defined that allows players to interact with the tasking system: enquire the briefing, enquire reports on the different tasks, enquire status and engage/abort tasks... The TASK_A2A_DISPATCHER works together with the SCORING class to setup exciting scoring schemes to allow mission designers to accomplish individual scores on a score board. 3. Dispatch CAS, BAI and SEAD tasks to online players The TASK_A2A_DISPATCHER is built on the overall TASKING system, which also the TASK_A2G_DISPATCHER is using. As a result, the TASK_A2G_DISPATCHER has also been improved, especially the menu system and the overall coordination of the different tasks. 4. Settings and Options management for online players The SETTINGS class is a new capability within MOOSE that allows to define various settings for different moose classes, and are kept persistent per server for players. The current settings that are modeled are for A2G and A2A formats used during communications, like BR, LL, MGRS, BULLS, BRAA ... Additionally, an imperial and metric measure system has been setup. So players can use this menu to configure their own preferred settings, and automatically the system will use the right communication format during routing, briefings etc. On top, COMMANDCENTERS will have menus to setup the default settings for a server. The system is automatically included within the MOOSE system and these menus will be automatically available when you design missions using MOOSE. 5. Keep airbases clean from clutter and debris This class has been a while in MOOSE, but has now been completely revised and improved. Use the the class to keep your airbases clean and to guarantee airbase operations (airbases stop operations if a plane crashes on the runway, or if any missile or bomb is dropped on the runway). 6. Let online players Transport Infantry to various locations The release 2.1 of MOOSE introduced the TASK_CARGO_TRANSPORT capability. The system has been heavily debugged and more functionality has been added, like automatic respawing of cargo when it is destroyed in the field, or when a carrier crashed when the cargo was loaded in the carrier etc. The menu system to transport cargo has been optimized, and the overall workings have been improved and bugs have been resolved. 7. Setup Random Air Traffic, make use of the airspace! The new RAT class, which implements Random Air Traffic, has been added, and is a development of FunkyFranky... (Frank)... He has done a magnificent job and I really encourage you all to try this out. I will let Frank introduce further the RAT class in a separate post! 8. Reduction of moose.lua file size! Based on a great idea of Shadowze, an optimization has been done to reduce the moose.lua file size from 2.1 MB to 0.8 MB. This results in faster mission loading, faster performance. We hope that Release 2.2.0.pre of MOOSE will even more increase the fun level for DCS fans while using the MOOSE framework. Thanks to all those who have helped and contributed! Thanks, FC and FunkyFranky

Is there a lot of work left on the new caucasus? Also. I would expect 2.5 to have fixed all serious flaws introduced since 1.5... Wouldn't you agree? Sven

Szia Tamás, nem nehéz. Itt a 1.5 verziót lehet megtalálni. https://www.digitalcombatsimulator.com/en/downloads/world/stable/ Csak installálni kell és működni fog! Szia, Sven

Have you tried beta?