m4ti140

Since they've likely solved problems of time sync (they're adding multiplayer) maybe they can implement special relativity? If we're getting realistic interstellar travel (no FTL) then we're going to need something to keep us subluminal during long trips. Running objects on rails at different time step than the focused ship should be possible after all. Lorentz contraction could be a bigger problem.

Save imports have been a thing in RPGs for a while. Baldur's Gate, Mass Effect, Trails series. Still, don't know how it could work in this game, we probably won't have the same parts to convert the saves.

How does the transition between day and night city detail textures work? Does it display both layered on top of each other and increase the light opacity as the time of day changes? Or does it slowly fade the day texture as the night texture gets brighter? Also does the night texture support transparency? Or is black treated as transparent on it?

So... I decided to try the Astronomer's pack and during a night time flight around the KSC one thing didn't look quite right to me: Ignore the scaling, I'm using a rescale mod so I had to use a custom detail scale. Anyway, the lights looked too much in-your-face to me and upon a closer inspection I realized they're literally inverted: the streets etc. are dark while huge empty flat areas as well as roofs are glowing. Now I assume there's some reason for this, but just wanted to point it out.

Noticed the same. KSP doesn't account for rotation in Z axis when calculating lift. The new parts would be way better with FAR but with stock aerodynamics... well yeah, I guess modding in some segmented blade parts is in order. I was actually working on a mini mod (configs only, since I don't have 3d modeling skills) for turboshaft engines, where stock jets were modified to produce little thrust, as well as a new "energy" resource (so that based on its rate you could do power balancing) and "driven" rotors that ate this resource instead of electricity. This allowed for main and tail rotor to be driven by the same engine. Still, the new parts do introduce some possibilities. I will try incorporating them into this scheme. Maybe even write some plugin that would tie the "free" power generated by the new turboshaft engines to the power consumed by their own rotor. Maybe even some sounds while we're at it. Also, if someone could check and confirm: I'm pretty sure the lift vector is literally reversed on the small prop parts. As a side note, I managed to make a smaller helicopter (1.25 fuselage size) using your method of designing control rods (two hinges connected by a strut) by modding the parts I used for blade elements to have artificially high lift. I also gave up on collective for the tail rotor and just directly controlled rotor servos instead. I've also introduced flap and lead-lag hinges into the rotor blade design, as I noticed it actually calmed down the Kraken a bit. The increase in lift was necessary was because the speed had to be around 100-120 RPM max, otherwise even at the lowest physics dt the blades wouldn't keep up with the movement of the pusher rod. Even as it is I had to rotate the whole swashplate assembly because the struts aren't a real physics constraint (they're force-based instead, otherwise the tree structure of the vessel wouldn't be possible) and the hinges used to tilt the swashplate have a lot of off-axis flexibility, so the blade pitch lags around 60-70 degrees behind the value expected from the geometry. If the small heli parts were to be modded in, they'd have to have ridiculous lift, just like the stock parts (possibly with some way of poisoning it if someone tries to cheat and use it outside of its application). So yeah, segmentation of the blade is what gives a lot of potential to the stock helicopter flight model even with stock aerodynamics. With FAR, the only thing that wouldn't be simulated would be VRS and ETL, as well as ground effect - all of those would either require real time CFD (lmao) or special treatment within FAR code.

Disregard, the rotors seem to hold set RPM rigorously in the new version.

Wow this is massive. I started working on a mini mod to make the rotor parts more appropriate for helicopter usage, you guys have just added most of what I was doing into the game now. This is all us prop/helicopter builders have dreamed of. Guess we'll spend another few months without leaving Kerbin

Maybe the 1.7.2 incompatibility might have something to do with the axis action groups?

Having played around with the rotors, their config files and having attached various different parts to them I came to a realization that the RPM limiter does not actually limit the RPM. Instead it arbitrarily limits the torque based on RPM and RPM limit setting, but does not actually care for what the end effect of that adjustment is. If there is literally anything draggy attached to a rotor the RPM limiter will limit the RPM way further than it should. E.g. after modifying smallest rotor to have a ridiculous max torque (750kNm) in order to remove that part from the consideration and attaching a pair of I beams to two of the rotor nodes, I noticed that the max RPM was actually roughly half of what I set the RPM limit slider too. I think it's quite obvious why this is a problem: Not only is the rotor (and probably servo as well) output unnecessarily limited significantly reducing its usefulness, but any changes in loading will change the RPM with no regard for the RPM setting. Timing rotations is impossible in this case as well. We need a proper RPM governor that will actively control the torque based on feedback, or at least change the current one so that the external torque applied to the rotor is measured and then added to the calculated torque limit, the current solution is downright broken.

OK, having massed around with rotor configs (I set the torque on the smallest rotor to something ridiculous, attached stuff to it and observed) I came to a realization that the RPM limiter is not actually an RPM limiter at all. It simply adjusts the max torque using a pre-calculated function of whatever you set on that slider and current speed, with no regard for rotor loading whatsoever. If there's literally anything attached to the rotor it will never reach the RPM value you set it to, because whatever method they use to calculate the slope of that function is only applied to an empty rotor, not to the actual craft upon lunch. It will apply the same torque at the same RPM regardless of what the actual torque requirements to maintain that RPM are. This is broken and is the reason both why everyone seems to have massive issues building props and the reason for the glitch in the OP. An RPM limiter has to be an active controller, the current solution is simply broken.

How do you bring up the GUI for runway creation?

Building props yourself out of rotors and aerodynamic surfaces gives you a more accurate simulation of props/lifting rotors than a jet posing for a prop engine would and therefore gives you more insight into what's happening in rotating systems like those - which is what we want from an educational game like this in the first place. Firespitter does fake rotors already and it's bad. Look up the Mi-26 craft someone made with Breaking Ground with fully articulated rotor hub and a swashplate - it accidentally got an almost X-plane tier flight model due to each blade section's aerodynamics being individually simulated. Of course they could make them procedural and simulate all of the effects (like center of lift shifting to the left in forward flight) instead, but I don't see them doing that. What they should do is "just" fix the rotors themselves and change the way physics calculations are done for the parts attached to its nodes (i.e. use radial coordinates, constrain radial direction so that they don't "fly away" due to centrifugal force and perhaps do multiple physics loops per frame for rotating parts, basically give the rotating section its own physics grid that rotates with it - all of which might require circumventing how Unity handles stuff in one way or another, thought it's not like they haven't done it before).

Why are the output units for the rotors "kilonewtons"? Rotors produce torque, shouldn't the unit be kNm or Nm instead? If it's given in kN, what is the moment arm? 1m? If it's 1m, why are the rotors so weak, 75kNm directly on output shaft is a lot, the rotors shouldn't just stop due to rotor blade drag. EDIT: I've just realized those are kNm indeed. How come they come to a halt so easily despite having such a high torque? EDIT2: I think I realize what's happening now. After modding a rotor to have 10 times higher torque I realized that it didn't change the max RPM at all. What seems to be happening is that the RPM limit does not actually limit RPM - it limits torque using some weird linear function that does not account for the actual rotor RPM. It doesn't account for loading of the rotor, it just limits the torque to pre-calculated values. If there's literally anything attached to it it will never even reach the max value.

Well, guess what you can build now

If I may suggest something - if you're going to do the split-rudder airbrake, split the vertical stabilizer and the two halves of the rudder into 3 separate parts, so that it can be easily made FAR compatible.