Amarok_73

I have them, pretty solid, nice feature is that You can set width up to your preference, the only drawback is, that with time, they're becoming little squeaky in the place, where lubrication can't stay for long. If I'd have to spend this money again, I'd preffer the MFG Crosswind with Bf109 footrests.

It’s entirely plausible, for Moose, nurtured by Applevangelist, Wingthor, and their esteemed companions - pardon me for grouping them together rather than listing each one individually - is a creature that evolves with remarkable swiftness. I must admit, it’s been many months since I last explored this fascinating DESIGNATE Class, so I might be outdated a bit indeed.

The script I attached uses parts of the MIST, but it's integral, and there's no need for additional MIST loading. I have prepared it long time ago, being unable to achieve what I wanted regarding designated targets prioritisation. Nowadays, I'd probably build the list of the spotted targets and priroritize it by my preference, staying within the MOOSE in whole. But as we know, Better is the enemy of Good, so I'll refrain from messing with it for a while yet.

It’s deeply frustrating to be caught in a constant cycle of dealing with bugs that seem resolved, only to return again and again. It’s reached a point where I genuinely miss the previous version of the module - one that, while not groundbreaking, offered stability, reliable avionics, and a sense of consistency. I find myself wishing the developers would simply stop altering it. Frankly, I’d gladly trade features like RFI and others still in the pipeline for a system that just works. What makes it even more disheartening is that, in cases as clear-cut as the current one, we don’t see an immediate rollback of problematic changes. Instead, we’re left waiting - often for weeks - for the next patch, uncertain whether it will fix the issues, create new ones, or simply reshuffle the same problems. The pattern is dismayingly familiar: fleeting improvements, recurring frustrations, and an ever-growing sense of user dissatisfaction. And I still have in memory the "old, good times" of the Ka-50 developement, where it was as satysfying as it is right now from the very first day of the deployment...

You're wrong sir I am affraid. Here's what I use for my JTAC drones, and works like a charm: BlueJTAC1 = SPAWN :New("Blue_JTAC1") :InitLimit(1,0) :InitCleanUp( 120 ) :InitRepeat() :OnSpawnGroup( function(SpawnGroup) JTACAutoLase(SpawnGroup:GetName(), 1611, "vehicle") end) sBlueJTAC1 = SCHEDULER:New(nil, function() BlueJTAC1:Spawn(1) end, {}, 10, 10, 0.5) @HungryCoyote Regarding lasing and JTAC functionality, I used a well-made script (not my own), which I’ve attached here. JTACAutoLase.lua

I don't really feel the difference between the behavior of the last patch and the current one. However, I wonder why not just apply lower saturation on the YAW axis, or change the response curve. This is not something that requires PID tunning, but only the sensitivity of the response to one parameter.

Some time ago, I created a script that displays STN numbers for all units using a specific number or just for individual players. Now, I would like to extend this functionality to helicopters, allowing any player interested in cooperation to see who has which number and configure the network without needing to request this information over the radio. This is a basic version of the idea. A more advanced implementation would enable automatic management of the DL network based on player connections and disconnections. However, this would require the ability to write information directly to a client helicopter’s avionics, making the implementation significantly more complex than simply reading the data. Combining this with a password-based system—such as the one visible on the Apache display for Datalink-related functions—would create an excellent mechanism for automated DL network management within cooperating groups. If the API provided the ability to read and write DL addresses and access the password, scripting this functionality would be well within reach for an experienced scripter.

...and there it is, the 8.0.0 version, announced just minute ago to me on Discord by The_Paid_Actor.

@Ladan You have to trim the aircraft precisely to 1G to make him fly more or less horizontaly, but currently it seems to be impossible to trim it so Your vertical velocity will be zero.

I've also received the announcement about the version 8.0.0 on e-mail.

I am old too mate, have a mercy!

Please do cancel Your order, so my Constellation will come faster.

How could it be, that the group located about 10 km from the aiport Marka where it seems to be plenty of streets leading almost straight from the group to target place, instead decides to go for such a roadtrip?

All pleasure on my side.

Looking into the Moose source file as well as into the documentation, in the AI_A2G_DISPATCHER:SetSquadron function I can see, that expected parameter for the airbase is just it's name, as AIRBASE:FindByName is already called from within the function, so try to provide just "LHA" as the airbase parameter without the "AIRBASE:FindByName()".

Can You share the mission here or in private message?

Why don't You try just A2GDispatcher:SetSquadron( "BAI_AV8", AIRBASE:FindByName("ShipUnitNameHere"), { "Atk Harrier BAI" }, 10 )

Another issue I've encountered just yesterday was related to the drawings, that seems to be not copied when selected with this tool. Also, another problem I've noticed, that name of theoreticaly copied drawing was not reflecting the naming convention of the objects that are copied at the same time.

The purpose behind writing this script was to enable all airports on the map to operate in dynamic mode. While this can be easily done using any text editor, I wanted to simplify the process even further. The script modifies only the Dynamic Cargo, Unlimited Aircraft, Dynamic Spawn, and Allow Hot Start parameters, ensuring that the initial values assigned to the aircraft remain untouched. It does not alter the settings in the Liquids and Eqp tabs; however, the relevant entries are included and can be enabled by simply uncommenting them. To use the script, extract the warehouses file from the MIZ archive, place it in the same directory as the script, and run it. If the process completes successfully, a confirmation message will be displayed. Once the modifications are made, reinsert the updated file back into the MIZ archive. A map prepared in this way allows for further adjustments with ease, such as modifying the number of available aircraft using a Lua script, or set the coalition specific planes to non-zero quantities. For this purpose, I recommend getting more familiar with the STORAGE class from the MOOSE function library. SetWarehousesToDynamic.ps1

How about DCS-CODE-INECTOR? Can't think about anything better when it comes to Lua debugging for DCS...

...or, You can employ the MOOSE to this job: https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Utilities.Utils.html##(UTILS).ClockHeadingString

"We the people" humbly ask for positive consideration of this request to add to the API the ability to obtain information about the current STN of aircraft, and Datalink settings in Apache helicopters. At the moment it is possible to obtain information about the STN of aircraft set as static, however in the era of the progressive transfer to dynamic slots, this possibility is becoming insufficient. In the case of Apache helicopters (and probably others eventually), the ability to obtain this information using Lua would significantly improve the interaction between mission participants, especially on servers where there are many players, not necessarily associated with each other within a virtual squadron.

Hello, I'd like to ask if it is already possible to get with Lua from API the DL address of active Apache helicopters?

I did it about 3 days ago, without any trouble. Observe the ACL display and verify if the DATA comes to You.

I noticed it also in the scenario where the sand storm was set to about 9000 ft.