Boris-Barboris

For rocket engines it's 0 to 1 frame delay. It all comes down to module's FixedUpdate ordering during update work cycle. If the code that sets the throttle is ran before ModuleEngine's code that applies the thrust force than you get zero effective delay.

Blocked on https://bugs.kerbalspaceprogram.com/issues/23911 for now.

@ProgradeInProgress Let's look at the log then. AA is borked on some designs, but pitch is almost always solid. A screenshot or two would help as well.

Sorry, nothing comes to mind. Does adding the tail-fin (I know, I know) fix the problem?

For the enthusiasts, I just found an interesting old technical topic right on this forum, can't beleive I haven't seen it before: Just an interesting think tank on SAS topic.

If opinions could be mapped to a sphere, ours would count as two poles. 1). Yes, performance must be worked on all the time, with constant vigilance, through the whole development cycle, to keep those features yes-men PMs promise at the bay called "Reality". I expect game developer to constantly think about performance while typing every line, every function, day and night. I expect planning and budgeting techniques to be applied to performance/time/memory aspect of the game. My expectations are not changed by the fact that modern gamedevs rightfully don't care about my ideas or wishes. Subjectivity is implied. 2). No, you don't need a finished game to start working on performance. You don't need all the game systems implemented to optimize one game system. 3). I must have missed the proof that it is a debug build. Pre-alfa != debug. 4). I don't evaluate, I speculate based on marketing material and domain knowledge. If the features are missing, I can rightfully expect the release to be even more laggy, so this particular argument is just as ridiculous.

"60 fps on this particular test PC in this 20 game situations" is a valid requirement. I refuse to accept this "optimize later" doctrine, it reeks of webdev oversupply-induced absolutism. There are methods to budget frame time to different subsystems. Prototypes gives reliable estimates on how much does a feature cost. Yes, it is work, but it must be done: fps is a requirement. Not to mention the obvious downsides of late-stage content-cutting is inefficient (you've spent months on content that is not shipped) and sometimes unethical (false advertizement, trailers feature some other game, not the one you ship). That's why you optimize early, to optimize design. 10 fps + 25% is still 13 fps. I've never seen a trailer to the game lag and then the game shipping with no performance problems. Something's gotta be wrong. I seriously hope it's just too many trees with no LOD in the background.

Optimization must be started on design stage, because: 1). "Running at all" is only one part of the goal, "running correctly and fast" is the goal. Games are not business software where you can just wait, performance is critical and is part of business requirements. 2). Performance requirements shape the set and scale of features that can be running. You DO design gameplay around performance, then you make gameplay correct, then you tune constants to converge to acceptable compromise. 3). Multiplayer MUST be completely shaped by performance requirements. There is a very small, strict subset of normal gameplay loop that can achieve good multiplayer performance in KSP-like game. Performance is the master here, not what the people want. Low performance of demo is a red flag. You have no need of debug build or debuggers running in background to film a small gameplay teaser. In fact, you absolutely want to get as smooth a video as possible, and developers failing to do so is not a good sign. I mean, come on, at least lie and speed up the video to create an illusion of 60fps. Rapid verbal evasion maneuvers on multiplayer and Linux questions are another red flags for me. There is no "later", such things shape the whole project from it's core. They must be certain at this point, and if they're not, they're gonna crash and backpedal on release. And if they are certain and design is shaped at this point, why withhold the information. I'm afraid I'm even less than sceptic at this point, but I wish the new team best of luck, we're all counting on them.

Windows status = activated.

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.

0.95 is default