Boris-Barboris

moder_cutoff_ias of pitch/yaw angular velocity controller governs the instrumental speed below which the pitch/yaw moderation is completely turned off automatically. The default value is 10m/s. You could simply increase it. No other way.

In this particular screenshot you are pitching up, wich is evident by elavator position and control widget in the left lower corner of the screen. Other than the fact that the plane is too stable and is barely capable of holding level flight AoA on maximum pitch, I can't say much more about your problem or lack thereof. The gui that is open is not from AA btw, it's TCA's gui.

K, i'll have to process your issue later, tomorrow probably, i'm currently, dare I say, indisposed. In the meantime, please do tell what did you expect to happen and what didn't happen.

85 degrees is the border IIRC Is your neo_gui flag in global_settings.txt set to true by any chance.

Oh, wow! Yes, that's intentional. Heading mode switches to level mode on high latitudes because course makes no sense anymore. Sorry for the lack of docs, but what you see was explicitly coded by me. Just use waypoints or level near the poles.

Sorry, but I'm afraid I can't reproduce your problem. Your logs seem fine.

You definitely know better than getting sad over bittervet wine on mexican fartpillow launching forum. Enjoy what you enjoy and keep your head up.

Didn't enjoy it. Unflyable without reaction wheels, no roll control, barely any yaw and pitch even with reaction wheel. Thrust too inert. Squad's Linux joystick support still absent. Doesn't sound like a helicopter.

And I am saying that it is difficult only because the thing that was done shouldn't have been done in it's current form in the first place. Other than that, I understand your points. I think the solar panel that automatically turns towards the sun is a better comparison: it is built with complete user scenario in mind. Blades, judging by the the looks of it, at most received "well, they can tweak authority limiter so they'll be fine". Yes, no problem with that, I just don't like that such development approach suits the tinker player, not the flyer/pilot. I am afraid it is the reason behind about a third of user screenshots and videos, that involve new rotors, demonstrating significant part of player's screen blocked by ugly tweekable panels and aero debug overlays. Enjoyable flight needs no UI. Not to mention the flight itself, wich I have found in no way enjoyable.

When you program the game, you are in complete control and you are allknowing. You bend the reality of the game to your will, not bounce off with "oh, but how do I control this now?". If the system you have created is too complex, you simplify it to the point it either needs no control or you clearly see what additional input it needs. There is nothing to prevent a dev from writing a propeller module that receives desired lift as inpult from the global throttle control and and follows this setpoint with internal logic. Click, select number of blades, select AoA range for blades or fixed. Module has the invertable fomlula that can be used to get desired blade position from airspeed. If you're lazy or overcomplicate formulas, slap a PID on it. Rpm, lift, drag, inertia, stall, visuals, fuel consumption governed by module under complete control of the programmer. Cyclic control? Easy, I'll just add torque here, with magnitude based on my formula. Sound? Here it is. I know my rpm and blade count, that's how many samples to overlap and how to modulate them. Main helicopter rotor torque compensation? I just make a UI where i click on tail rotor, press "compensate torque of..." and then select main rotor. And guess what, i know what the uncompensated toqrue is now, i have it calculated here, in the module class, so I just produce the lift on the tail that creates the desired counter-torque. In no way it is hard to get a functional, controlable helicopter in a lego simulator. You just need to pick the right building blocks.

That's not "visual", the part's collider is where part's model is in KSP/Unity. That's not the guidance that is missing but the core game subsystem. Imagine if KSP was a game where there was no centralized throttle, and you had to modify each engine's thrust by hand. Or solar panels that must be manually oriented towards the sun. That sounds terrible, but I think this is exactly the level of propeller feature maturity: core without a shell. At this stage you transfer the system to UI/UX guys, not players. Unless, of course, Squad thinks that it's the modders that must step in now, wich is doubtful. They will probably just observe our struggles for a couple of months and come up with some simplifications in the next patch.

https://github.com/Boris-Barboris/AtmosphereAutopilot/releases/tag/v1.5.15 Changelog: Do not replace control surface module for parts that contain "propeller" or "blade" in their name. Default 0.95 value for dir_strength. That should suffice for DLC blades.

There is a bug that breaks dlc propellers, if you want to try them delete AA.

IMO part per blade was a mistake. Both the PhysX engine and old part module code are not up for the task. Lifting surface module was written on the different assumptions. Part joint system is unfit for blade placement (look at the effect of time warp on this 10-second segment: https://youtu.be/2EiyoE2Z1qA?t=668) , integration time step is too large to precisely perform cyclic control on high rpm... It should have just been a new module with the ability to shape blades and change their count. Most bits of detail and simulation can be done better in the module, with the exception of per-blade damage I guess.

Try removing AA mod, it modifies control surfaces.