Amarok_73

I am not sure what You mean by "skewed", could You elaborate please?

Sadly it's not IC compatible...

I'd like to ask how many of us are flying Apache with what type of joystick base.

This requirement and it's effect is WAY MORE obvious to the FFB users, and even me, used to the FFB, but forced for last year to fly with central trim on spring centered base was pretty tough to keep as routine for helicopter steering, so I am not really surprised, that so many people has problem with Apache stability as I assume, there's still plenty of the pilots between us using spring centered joysticks.

He seems to be not so keen to dance anymore...

Not mentioned in today's release notes, but I have feeling that FM is much more stable now.

Since I said goodbye to my HOTAS Logitech G940 with FFB a year ago and sent it into a well-deserved retirement after fifteen years of active service, looking for something to replace it, I decided to give the MongoosT-50CM3 Base with the MongoosT-50 CM2 grip, which is longer than the one in the F-16, a chance. Over the course of this year, I tried very hard to get used to the clutch and damper mechanisms available in it in various ways so that flying helicopters would resemble the time of flying with FFB and... unfortunately, I finally gave up and until last week, when I bought the Moza AB9 base, I flew in the center trim mode (instant), which was quite uncomfortable, but acceptable due to the lack of better alternatives. And unfortunately, I have to say that if you have flown with FFB and know what behavior to expect from such a system, and what's worse, you have gotten used to it, then a solution based on clutches will not be satisfactory. The worst factor for me was the lack of control precision resulting from the fact that movement along two axes required struggling with twice as much resistance from two clutches than movement along just one axis. Even zeroing the centring forces by reducing the tension on these mechanisms to zero does not change much, because then the effect of the clutches is felt even more intensely. Another thing was the lack of feeling the center point of forces with the hand, to which the helicopter was trimmed and which was the reference point for possible corrections. Especially the latter, although these are very small and subtle changes in the joystick position, becomes a significant distraction on the scale of everything that needs to be handled to keep the helicopter in stable flight or hovering. Especially in such a sensitive to control helicopter as the Apache. Therefore, if you have such an option, I would consider selling this Virpil base, and adding the appropriate amount of money to buy a base offering full FFB.

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.