FlightControl

There was an old thread about this item on the forums, explaining the weather in details. Maybe it got already archived?

MOOSE Release 2.3 alpha - (EARLY ADOPTERS VERSION) FlightControl-Master released this 20 days ago · 103 commits to Release-2.3-alpha since this release This update brings a new class ATC_GROUND to the MOOSE framework. Consult the documentation of the ATC_GROUND classes for more information how to use. This capability is designed for public (and clan) servers to make players "behave" on the runway. The exact location of all the runways at the maps Caucasus, Nevada and Normandy have been assessed and this information is incorporated in the ATC_GROUND classes in order to make this mechanism work. This results in 3 classes for you to use: - ATC_GROUND_CAUCASUS - ATC_GROUND_NEVADA - ATC_GROUND_NORMANDY If you have a public server, and you want to ensure that players are: - Not speeding on the taxi ways. - Not taking-off on the taxi ways. - Only take-off on the run ways. - Stay on the taxi ways and don't rally on the grass lol Then this may be something for you to try. dAiZXRHMepw Note that this version of MOOSE contain prototype methods, and are bound to change. However, when methods are changed, I will communicate that, so you can adapt your missions. I will try to keep the changes to the minimum. The MOOSE framework come delivered in one lua file. There are two versions of this file, but with different file sizes. Moose.lua (with comments) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments) ... For runtime environments, to facilitate quicker downloads of mission files and performance. You can download the files in the Downloads section below. To use, include the Moose.lua 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. Downloads 2.32 MB Moose.lua 887 KB Moose_.lua

Release 2.3.Alpha - Introducing ATC_GROUND MOOSE Release 2.3 alpha - (EARLY ADOPTERS VERSION) FlightControl-Master released this 20 days ago · 103 commits to Release-2.3-alpha since this release This update brings a new class ATC_GROUND to the MOOSE framework. This capability is designed for public (and clan) servers to make players "behave" on the runway. If you have a public server, and you want to ensure that players are: - Not speeding on the taxi ways. - Not taking-off on the taxi ways. - Only take-off on the run ways. - Stay on the taxi ways and don't rally on the grass lol Then this may be something for you to try. dAiZXRHMepw Note that this version of MOOSE contain prototype methods, and are bound to change. However, when methods are changed, I will communicate that, so you can adapt your missions. I will try to keep the changes to the minimum. The MOOSE framework come delivered in one lua file. There are two versions of this file, but with different file sizes. Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. You can download the files in the Downloads section below. To use, include the Moose.lua 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. List of changes: Ensure that ATC_GROUND classes in the :New() constructor return itself! Added new ATC_GROUND class. Downloads 2.32 MB Moose.lua 887 KB Moose_.lua

I've made a mistake on the release pages of the MOOSE framework. I had put hyperlinks in the release text from where you could download the files, but when you would do "save as...", these files would contain html :-( Thanks Frank for telling. As an action, I've updated the latest release 2.2.4 (Patch 4) where I've removed the hyperlinks of the Moose.lua and Moose_.lua files, but have attached them physically to the release page in the Downloads section. For those who have been struggling with Moose.lua not loading properly, sorry guys. My fault. Release 2.2 - Patch 4 (LATEST VERSION) FlightControl-Master released this 2 days ago This patch brings a change on the SPAWN class: Modified :SpawnInZone(), :SpawnFromVec2(), :SpawnFromStatic(), :SpawnFromUnit() specifying an optional MinHeight and MaxHeight as a parameter, so that the mission designer can choose if he wanna use the group height set in the mission editor for spawn or a random height specified by the parameters. The MOOSE framework come delivered in one lua file. There are two versions of this file, but with different file sizes. Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. You can download the files in the Downloads section below. To use, include the Moose.lua 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. Downloads 2.18 MB Moose.lua 837 KB Moose_.lua

Can you drop your mission here in attachment? I can look at it tomorrow, or somebody else can check and help.

Chris, i don't think there is a mistake on our side. First of all, the ~mis00006118 file is located on your temp directory. Can you go into T:\Temp\DCS\/~miss00006118 (or in another run, the file name may be different), but open this file, and check what is in it? Can you drop this file here pls as an attachment? I also suggest you join our slack site for support. Send me a private message with your email address. We'll get you on slack.com, which supports code sharing etc.

Chris. I think this is my mistake. Sorry mate. I had to do a difficult merge and think i skipped a < sign. I will check and come back. I guess you download the latest version less than an hour so or a mission?

Excellent. Let us know how it goes. A satisfied customer is a good customer :-) Once you got CAP working, we can look into auto refuel in air of the CAP AI. Sven

Release 2.2 - Patch 4 (LATEST VERSION) FlightControl-Master released this 28 seconds ago This patch brings a change on the SPAWN class: Modified :SpawnInZone(), :SpawnFromVec2(), :SpawnFromStatic(), :SpawnFromUnit() specifying an optional MinHeight and MaxHeight as a parameter, so that the mission designer can choose if he wanna use the group height set in the mission editor for spawn or a random height specified by the parameters. All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes: Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc. Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance. To use, include the Moose.lua 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.

Tamas, can you code? I mean, you have experience with programming?

I have read your sentence a couple of times, but have a hard time to clearly understand what you wanna say, the words are mixed. Let me try to explain a bit further. Forget about Overhead for a minute. There is a distinction in how the module handles CAP and how it handles GCI. CAP CAP lets planes get airborne in a zone. CAP is time driven, meaning, it monitors at specified times, if there is sufficient CAP in the air, and if not, it lets CAP spawn. You can specify how many CAP you wanna SPAWN. There are 2 methods that influence CAP. And I think this is not well explained in the documentation, so that is maybe an area of improvement on my part. 1. GCICAP has a method called SetSquadronCapInterval... This allows to specify how many CAP (not planes, but CAP), and between how many seconds it needs to check if a new CAP is required to be spawned. 2. GCICAP has also a method called SetSquadronGrouping ... This will specify in the case of CAP, how many planes will spawn in one CAP spawn. These planes will form a group. So, you spawn 1 plane to 4 planes for CAP. GCI GCI is event driven. It will kick in when there aren't enough planes airborne to defend from intruders. That is where the SetSquadronOverhead comes in. It specifies how much overhead will be assumed in case of intruders. SetSquadronGrouping will "group" the spawned defenses in "groups". So, I hope that this answers a bit your question. FC

fIp2VdvRXQw Watch these video series: - (There are more videos!) Watch the documentation: - MOOSE online documentation! kind regards, FC

Hi SNAFU, This is the documentation. http://flightcontrol-master.github.io/MOOSE/Documentation/AI_A2A_Dispatcher.html#AI_A2A_GCICAP There are 2 methods I think you are looking for: 1. AI_A2A_DISPATCHER:SetDefaultOverhead(Overhead) 2. AI_A2A_DISPATCHER:SetSquadronOverhead(SquadronName, Overhead) The first defines for all the squadrons you have setup the overhead. The latter allows you to define a specific overhead for a specific squadron. Note that you can "randomize" the overhead, by making a scheduler and at regular intervals call one of these methods and select a overhead from 1 to 4. Does that help? FC

How many client type of units are in the group? So how many units in the group with skill set to client? Also.... It may depend on the weapon used. When in mp you hit with a bomb or cluster, the structure is different... EventData.TgtUnitName may have a different value in some cases by dcs. Is the target a static, scenery or a unit? Can you do the test again and send me the dcs.log? Thanks. Sven. Fc

Ok! Great! You can use the borders in 1.5.7 missions because it does not crash there. 2.1.1 seems indeed to have issues with these borders... Something for ED to look into, which they have confirmed they will. Because if they won't fix it will come back in an other form sooner or later. Sven

Always. As long as the bait is kept fresh! It is not hard. Send me your email in a private msg. There is a forum to learn stuff... Also have a look at the MOOSE for dummies videos if you have time. Maybe they help to get started... Suggest you look into SPAWN and RAT as a start. There are easy classes that show quickly fun results.

Off the shelf in DCS no.... But! Have a look at ZONE_POLYGON class as part of the MOOSE framework. Can you code? Sven

I am structuredly confused about this post and am afraid it takes away the momentum of the message I wanted to give. We are talking about planes controlled by AI here. Are you also? FC

I know unfortunately, however, are these issues reported to @ED? Know that in this thread you can find per airbase a test mission to resimulate the issues. So this saves a lot of time for ED to look at these APC issues. So we did our part, I hope the team can take some time to look at these issues reported. The list of airbases is only growing in DCS as a product, and as such, the urgency of working airbases is only increasing ... Don't know if it is useful to add [REPORTED] to this thread? Here is a summary of the issues: - Planes crashing into each other at the airbase. - Planes blocking each other at the airbase. - Planes not landing, even when the airborne planes should get full clearance to land. Planes are not landing sometimes for 30 to 40 minutes!!!! - Planes stopping for no reason while taxiing, and not restarting! - Planes disappearing suddenly from the airbase (without a DEAD or CRASH event logged). - Planes waiting for ever at the runway before takeoff. - Specific airbases really bring down the DCs simulation performance during APC operations. I mean, really bring down! I hope these issues can get resolved some day ... FC

Ok, when you are running this game at 1080 on a single monitor, I guess then 1920 x 1080 and you get only 40 fps, that is WEIRD, when you are using an NVIDIA 1070 GTX! Can you do a test, and make a single player test mission. Fly in a zone without buildings etc. On the 1.5.7 version totally in the north of the map, there are no objects there. And us ALT-PAUSE to check the framerate. Use PRT-SCR (when running DCS) to save screenshots. The screenshots should show the frame rate in the upper left corner. The screenshots are saved by DCS in the user/Saved Games/DCS/Screenshots folder. Upload them using www.imgbb.com. Then you can include pictures in this forum using the forum TAGS, imgbb provides you facilities to do cut-paste these tages with hyperlinks included. Also take a screenshot of the DCS graphics settings panel. You can also do this using PRT-SCR and upload from the Screenshots folder to www.imgbb.com. Open your NVIDIA configuration panel. There is an option in the menu Desktop, that allows you to add a pictogram icon in your taskbar to show the GPU activity. Run DCS and click on the icon. You see DCS mentioned in the list? Run a dxdiag and attach to a reply in this post. Sorry, but 40 fps on a 1080 NVIDIA resolution is SLOOOOW. I run here on my MSI the sim 1.5.7 on a 1920x1080 resolution on an NVIDIA 880M and I get 60 fps in crowdy cities, clear skies, high settings. FC

What resolution are you running the SIM on? What are your graphics settings? Are u using VR?

You are right.

First of all, a +1 appreciation for this. Weather randomization is a long overdue item on the DCS wishlist now for years. The value for the sim and ED in general, to have kind of weather randomization mechanism included would be: 1. To train pilots using the same mission scenario in various weather conditions. Especially great to train pilots in the military facing unexpected weather. 2. In multi player, people may join a great mission, but quickly disengage because "they don't" like the weather. When weather randomization would be applied, people may join this mission later again. So, @ED, please consider a requirement like this, but please "read between the lines". Let us also be a bit realistic. Weather randomization on the fly may be a bit too difficult to build into the sim at this moment. So don't know if the following breakup of the functional requirement would make sense, taking into account mission design and the "mission flow". Weather randomization could be applied in various ways: - One that is existing now, I think, or can easily be made: Put a random weather "injection" in the mission file. this basically will create the structure as you outline and create a new mission file. Easy to do. I'll contact you on slack for that. - Built into the DCS ME GUI, a new functional panel could be created that creates a "random weather scenario" which would be activated at mission start. So each time a mission runs, a random weather would be "generated". I can imagine some boundaries would be applicable and some options to allow the randomization to apply to... - The Scripting Engine could have some kind of weather randomization APIs? Regarding the mission flow in case the ME would : - Random weather could be applied at mission start (so when loading the mission either in SP or MP). So instead of loading a struct, first generate the struct based on parameters set in GUI or SSE, and then load or generate the weather. - Don't know if the sim can change the weather on the fly when it is loaded and generated? How much work would this be? Please indeed, @ED try to consider the requirement from the author who started this thread. At least consider it taking into account the value outligned above? thanks! FC

@ED Is there any feedback what actions are planned to solve these malfunctions?

tn_prnteye, An open question, can you code? I mean, you have programming experience? There are alternatives when it gets complicated. FC