FlightControl

Some more fixes... AI_CAP_ZONE: Fixed issues with CAP engaging (independent CAP so not related to GCICAP). AI_CAS_ZONE: Fixed issues with CAS engaging. This to help Hijack. Ensure you download and include the latest moose.lua from the MOOSE release page: https://github.com/FlightControl-Master/MOOSE/releases FC

A couple of urgent fixes: DESIGNATE: Messages not appearing correctly and crashing the logic is fixed. (due to a stupid typo). TASK_A2G: Tasking is fixed. Status menus are now displayed properly, also when the task is planned. MENU_COMMAND: I found now why DCS is displayer "error in error handler" sometimes when a menu was selected. The error handler is DCS is bugged, so made my own one. This one is to help FubarBundy. Thanks Mechanist and Ramsay for the error reports on github. Ensure you download and include the latest moose.lua from the MOOSE release page: https://github.com/FlightControl-Master/MOOSE/releases

Maybe I am talking another language.... Guys, it was possible to destroy Groups in dcs 1.2.6 etc, right before they would burn. The trick was easy, upon dcs triggering the S_EVENT_DEAD for a unit, you could remove that unit by retrieving its group id, and then destroying the the whole Group object. So right before the unit would burn you could do this. But after 1.5 got released, this stopped working. Many public servers used thus capability to keep a running sim clean from: - Debris - Idiots crashing their planes at airbases And the additional cherry on top of this issue is that since 1.5, the scripting engine cannot destroy anymore a client plane (so a plane with a player in it). There are tricks that can be done on the server code to manage the client slots, but still, having a scripting engine in control of this process will allow: - single player missions to support the same - give missions (= processes and scenarios) control of these things. The thing is... It would indeed be welcome so see some kind of vision statement communicated, or a fix, or a short note ... Not in public and does not have to be official, because 99.9% of the players won't understand what the note will be about. Both issues have been reported as bugs, or requirements I believe.

I am sure that what you wanted to do has a chance for success. My reply rate is low. The trick will be to build a template dynamically based on parameters. And add planes where wanted. SPAWN has all the ingredients to do these things. But now we need to look into a "player" skill setting a bit. Can you give this about a week? Fx

It is raining requirements lol :)))) No, airbase takeover is not yet implemented. But it can be done. Question is, what is the process that needs to be put in place. I wanna make this part of the finite state machine, so that upon airbase takeover, An event is fired that you can catch and do your own processing... For those who don't know what a fine state machine is.... AI_A2A_DISPATCHER is a fine state machine.... S0d0dpyeaWs So after watching this video, think of the possibilities... What would be the process a player would expect to happen? Like resources of airbase change coalition? And what possible extensions could be implemented. I mean, what other processes could happen upon airbase takeover? FC

Hi 132nd, http://flightcontrol-master.github.io/MOOSE/Documentation/Group.html##(GROUP).RouteRTB But here are side effects. There is a BUG in dcs. It is impossible route an airplane to an airbase and make it land using (mission) tasking (using setTask API). When you try this, the airplane will fly to the airbase of your choice, but won't land and will fly back to its home base (from where it departed). So I am respawing the airborne group and making a new route template from its current location that flies towards the base as the base of your choice. Then it will land... The API is very easy to use, if you understand the potential side effects. Please have a careful read through the documentation. The API uses an AIRBASE object. You create an AIRBASE object by finding the relevant airbase as was allocated in the mission editor or on the map. Airbases are Airdromes, ships, farps. You need to use the AIRBASE:FindByName() method to find the airbase from the MOOSE database. The AIRBASE:FindByName takes a string with the exact name of the airbase. for example: PlanesGroup:RouteRTB( AIRBASE:FindByName( "Batumi" ), 900 ) This makes the PlanesGroup fly back to the Batumi base at 900 km/h. Pls don't ask how this was implemented, because it is complicated. kind regards, Sven

Done a couple of new fixed on the framework: Markings have been added to A2G taskings. Spawns can now be done at airbases of choice (airdromes, ships, farps) upon command: Here a high level overview of the changes: MARKINGS: Added markings to the A2G tasking. Now a mark can be placed on the map where detected targets are located and includes target details. There is a new option added in "Join Task" menu that allows to automatically place a marker on the map. Note that the marker is done for the player group only, not for the whole coalition. SETTINGS: The settings menu has been added with display times... Added new functions that allow to configure the display timings of messages. Not all messages that are generated by moose have been converted into this system, but i plan to gradually do this. There are basically 5 different message display types: Update Messages: these provide a short info (like route info, status update info etc.). Important is that these kind of messages can be switched off! Information Messages: these provide information to the pilot. Can't be switched off. Briefing Reports: The briefing reports are typically to be displayed a bit longer. Overview Reports: Reports that provide an overview. Can be displayed a bit longer than normal messages, but not too long. These reports may become large. So, they are not to be used for long-time displays. They are used to generate an "impression". Detailed Reports: Reports that provide details of a subject. These also may need to be viewed longer, as they may contain important information. The SETTINGS menu has been added now with options to configure the display timings of these reports, both on a system level, as on a player level. [*] SPAWN: Updated SpawnAtAirbase() method to fix a couple of very hidden defects in the logic, and to ensure that spawning is now correctly done on airdromes, ships and farps... Ensure you download and include the latest moose.lua from the MOOSE release page: https://github.com/FlightControl-Master/MOOSE/releases

Thanks Grimes for the clarification.

I am not going to bore other people with this discussion and will take this further private. FC

I am sorry Pikey, but I don't agree. One can easily today wreck an airbase in 1 minute... What you are doin here is put the ticket to the ED team that they don't need to bother about it. I don't understand, I really don't why you are doin this. FC

Yes, Invisibull and Shawowze have been testing with me a lot of stuff. I am still working on improvements, like spawning at the airbase etc. But most of it is now functional. There is however a bug that i am still trying to find out with CAP. They seem to work okay, but then suddenly they don't engage, and still don't know why. So in order to find this bug, we need to find a way to resimulate it. And the only way of doing that is by using it, and seeing if it works okay. And if not, please help to explain what went wrong and what was the situation. Be careful with spawning planes from the runway, that is also one that may cause troubles. This stuff is complicated, but we have now a couple of servers live that use the module and have a large audience battling the AI_A2A_DISPATCHER. There is also a lot of tricks in the sleeve that you can apply to randomize units spawned, and to modify the templates etc as the mission goes on. Sven

I think you've just got a nail on a coffin here :-) https://forums.eagle.ru/showthread.php?t=190539

This material is stunning. Very beautiful and a big improvement on the visual aspects of the sim. FC

Is there an update on this issue?

@ED and @DCS team, Is there any way using lua scripting to destroy dead (burning) units from the simulator? It seems, that when units have crashed and are burning, they are dead and report that they don't exist anymore. Any way to overrule that in lua? It used to work to destroy a unit right before it would be destroyed and burning executing the function: UnitObject:destroy()or GroupObject:destroy() This used to work in DCS 1.2.16 ... (that a version before 1.5 got released). When you executed this code, right after an S_EVENT_DEAD was triggered, and while processing this event (so in the same logical unit of work), when you would execute this destroy statement on the GROUP object, the unit(s) of the group(s) would be removed. (Actually, doing this would prevent the unit from burning). And this is not working anymore, since the release of 1.5. This functionality is useful to ensure that: 1. Airbases keep operational in single player and multi player setup. Airbases stop functioning when destroyed units are burning on the runways or taxiways. 2. Debris floating around eats up CPU, so destroying units keeps the running sim clean. An other way of solving this (in the short way) is to keep airbases running, even when units are destroyed, but that brings other problems. @ED this is now in the system for a very long time. Many people are waiting to get this fixed. Please consider. Sven

Is there an update on this item from ED?

Is there an update on this item?

Is there an update on this item?

Hi. First a couple of silly questions from me: 1. Does it help if you set the modulation before the frequency? 2. Can the frequency and modulation be varied in the Mission Editor and does it work then for AWACS? Try an example with a fixed frequency that works in the mission editor. Then try another. Maybe not all frequencies work.... FC

This is great news!!!! Thanks for this message! Fc

T-14 can run on Mars...

Yup. This is indeed an issue. Could also resimulate it. It is a relevant issue, because important structures need to be hidden on the map, avoid becoming detected or easily to be found. Otherwise the enemy coalition knows where the friendly coalition is hiding and where your FARPS are etc. Not advisable. Could someone please have a look at this too? Sven

Another issue found with Markings. It seems to have issues with \n embedded in the provided string to be displayed as text in the markings text box. It can process \n, but if too many \n are added, DCS crashes...

Great post! Indeed, little things like this can ruin the experience. @ED pls fix this guys since you are working on the map. If possible, do a (an other) QA check of road connections on the maps, because there are more hidden blocks like this on the Caucasus map and other maps. (Tedious work, i know).

Thanks. Do your think this has a chance that the ED team will look into these suggestions, including yours on the locking of a mark? (If all gets reported and fits the schedule). This is something that if not done today it will never be done... Importance of it will become irrelevant as time goes on... (As with many :-)) Sven