m4ti140

No, that one appeared with Kopernicus installed, without it the only issues are with the 2D layers being lit in faint orange at midnight, the volumetric clouds popping in rapidly at certain distance and also being greyish white at night, and with "disable ambient light" option not working and doing nothing. I am using cloud textures and configs from AVP though, I'll try the default textures/configs set from legacy EVE. Also I had a lot of mods installed at the time, so maybe Kopernicus wasn't the trigger but I can't think of what else might have been. @dok_377 exactly what I encountered, are you using Kopernicus by any chance?

Clouds are like this for the entire night, as if sun was shining through the ground. Happens even with just EVE+configs+scatterer installed. Volumetric clouds are bright and render on top of the aircraft. Haven't seen it happen at day, which is weird, it's only visible at night and it's hard to see on a screenshot, when it's not moving. Also the ambient light option in scatterer settings doesn't do anything. This one is weird, it looks like the mun is rendering on top of clouds but behind the aircraft, producing a hole in the volumetric clouds where mun should be even if it's behind the aircraft. This and the above is what I meant, I don't know jack **** about rendering so I don't know what the correct terminology should be Couldn't find any nullrefs.

This is a really amazing mod, thank you for this

The mod does not seem to be compatible with axis action groups, and therefore is of limited use for Breaking Ground DLC. Fields assigned to axes controlled by AFBW are not altered when moving the controls, even though the control indicator and throttle indicator do show deflection.

Trying 1.10.1 + scatterer and eve + experimental Kopernicus build and so far the ground and atmosphere ambient light intensity slider doesn't work (at least on kerbin), the planet is treated as airless. Not sure if it's Kopernicus breaking things or 1.10. EDIT: Nevermind, it only seems to be the case at night.

I'm having some issues with latest EVE + Scatterer. First of all, the volumetric clouds pop in instantaneously instead of fading in, second of all they render in the foreground, on top of the craft. Finally, as you can see in the album below, you can see the moon shading through the craft, as ambient light was forcefully applied to areas of the screen not covered by other celestial bodies, but was still present everywhere else. I'm using AVP configs and the Distant Object Enhancement, it's a heavily modded install (most notably, I have the experimental version of Kopernicus installed) but the issues were present even with just the visual mods installed. https://imgur.com/a/er2NcAw EDIT: Apparently the lighting on the clouds past the terminator is also permanent, initially it disappears and then as it gets darker they start glowing in faint orange well into the night. I'm running DX11 EDIT2: Tried Planetshine, and it also seems to have issues with adjusting Ambient Light. actually it works as intended, it's just Scatterer failing to disable it despite disable ssal option being turned on. Overriding it to -100% made things better, but clouds are still orange for the entriety of the night. I'll try removing Kopernicus later EDIT3: Upon removing Kopernicus and Distant Object Enhancement seems to have solved the depth buffer issue, but the problem with clouds being lit from below at midnight and volumetric clouds suddenly popping in, brighter than everything else when at night, persists, likely due to disable SSAL option not working. For now forcing ambient light to -100 through settings and using PS to override it at day seems to be a requirement.

I wonder if this could be used for warp effects in KSPIE

One more thing I'd suggest, again from practical balance standpoint: The MK1 cockpit and passenger cabin don't really make much sense that far down the tree. The reason why it's the starter aircraft cockpit in stock is because it's both cheaper and only has one node. I understand that the reasoning behind this was biz-jets, but that's far from the only use for those parts. Mk1 should essentially be made available when the first jet engine is, cause the only reason to chose it over inline is 1. aesthetics, 2. lower the part count by one, which is soon to become a moot point by this point. The cabin on the other hand can be replaced with 2 inline cockpits, again forming an ugly monstrosity and circumventing this limitation for the cost of one additional part and own sense of aesthetics, it doesn't accomplish what it's set out to do. What is an actual limiting factor is availability of engines and wings, passenger cabins and cockpits of form factor similar to KSP size 2 have been a thing since WW2.

I found a potential issue with Breaking Ground compatibility: The small head electric rotors (rotor_0*s) are missing from the patch. Moreover, they make way more sense in aviation tree, as their primary use is for electric rotorcraft - in fact that's the only use for rotors in the game period, everything else is better served by servos and wheels. EDIT: Alternatively put them into "Stability", because another use for them - and the primary reason to make them available around the same time as helicopter blades and big turboshaft - is as tail rotors. currently there's no way to drive secondary rotors that are not connected to the main shaft in any other way than with electricity. I'm trying to make a mini mod that will avert that (essentially introducing excess power from the turboshaft engines as a weightless resource similar to electric charge that can only be used with special, clonned rotor parts) but as it is, those parts are necessary in vicinity of Early Aviation, otherwise the helicopter parts introduced there are useless - there's no way to build a stable helicopter with just those parts, unless you go for a tandem design (which has its own, massive issues, such as inability to yaw with just the rotors themselves due to how much the mechanics of rotor are simplified in BG.

I wonder if this could be used to add aeroelasticity effects to wings (without having to separate them into tiny segments). Is the effect only visual, or does stuff like collider, nodes etc. move as well?

1.9 and the issue is still here

I found a significant glitch with the current version (though I think it was there before) - if I use the upper attachment node, the tower fails to jetison - it gets stuck on top and the "jettison" option can be spammed forever, triggering decoupler sound but not actually jettisoning the tower. EDIT: actually, now that I tested it a bit more, it seems to be actually triggered by the offset tool as well. And when using the lower node, the tower sometimes just separates and flies off during abort, or gets stuck regardless. Overall, no matter what I do the tower fails to separate 9/10 times. EDIT2: I managed to fix this by removing one of the nodes from the config file, at least as long as I don't use offset tools. I cloned the part to have one version with normal node location and one with higher (I actually moved it 0.2 up so that it aligns better in Apollo configuration). This might be the best way to avoid this bug, it seems that the plugin responsible for abort sequence goes awry when there are more attachment nodes present.

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.