cosekantphi

I'm once again getting back into making my own EVE configs to tweak things for my own taste, and once again I'm faced with only having trial and error to go on. After years of playing on and off modded KSP, I've gotten the hang of this generally, but some variables still elude me and searching online has been fruitless. Specifically, I'd like to know what this set of variables under macroCloudMaterial controls: macroCloudMaterial { _FalloffScale = _RimDistSub = _InvFade = _RimDist = } As well as these two variables under the general settings: settings { _DetailDist = _DistFadeVert = I've tried playing with these in game via the editor, but even after hours of messing around with them I can't quite grasp exactly what they are doing. Sometimes changing one of these variables does nothing, some times it changes things drastically, and I'm having trouble finding a pattern. It'd really help if I could get a brief description of each one.

Has anyone else noticed that the followdetail option for the original volumetric clouds no longer works? Regardless if it's set to true or false, the particles appear solely based on the main texture and not the detail texture. From my memory, it's been like this for a long time now, but I can't find any mention of the problem elsewhere.

Would it be feasible to increase the resolution by up-scaling the map and adding procedural noise to give the clouds more definition? I suppose the rendered clouds don't need to be a perfect one to one representation of the data provided by KWP, so it seems to me something like this could look great. And I assume maps defining where there's rain and where there's snow wouldn't need to be very high res in the first place since you'll only really see those relatively close up. I'm just wondering what the performance penalty would be of changing the cloud map in real time.

I play KSP with the render quality set to fastest because each render quality step comes with a massive performance penalty. Setting the game to simple, I can expect to go from 40fps down to 15 or 20 in atmosphere with a modestly sized craft of about 50 or so parts. Unfortunately, the stock game limits shadows to simple or above; the fast and fastest settings completely disable them. Not that this is a reason to tolerate the fps loss, of course. While shadows exist on simple, they look like pixelated trash even with shadow cascades set to maximum. So as far as I can tell, shadows seem to be the only thing the render quality settings change. Literally everything else looks the same to me. Naturally, I had assumed for years that this meant shadows were just too much of a graphically intensive task for the non-gaming laptop I play KSP on. But then I tried out parallax on a whim, and it was nothing short of a miracle. Somehow parallax allows for decent shadows to exist even with the render quality set to fastest, and somehow it does it without a noticeable drop in performance (discounting the main features). Even if said main features become too much for my laptop to handle, I can disable them by setting the terrain shader quality to low. This still retains the craft shadows. Is parallax doing some kind of magical optimization here or did it just untie shadows from the render quality setting? In case of the latter, what exactly is happening on the higher render quality settings to eat so many frames? Because it's clearly not the shadows. Texture resolution and anti-aliasing are tied to different settings, so what might be left?

I tried parallax on an RSS install on my low to mid end laptop with an igpu just to get a feel for the performance impact, fully expecting it to either run at 5fps or immediately crash. I was extremely pleasantly surprised! I didn't try it with ground scatters, I only had the terrain shader quality setting on high, not ultra. After taking a quick peek at the moon and Mars, I found they looked much better without too bad of a performance hit. Running the game at 720p, I went from maybe 40 to 45 fps down to around 35-ish. But the most important thing I noticed is that somehow parallax enables craft shadows even with the render quality set to fastest. In the stock game, shadows are locked to simple or above. And despite the shadows looking like trash on simple, the setting absolutely obliterates my FPS. I thought this was specific to shadows specifically since not much else seems to change when I increase the render quality. But with Parallax, I have decent shadows enabled on the fastest render setting without any noticeable drop in performance at all. Had no idea that my machine was capable of it. I went from thinking I'd be giving parallax a quick try just messing around with it to making it a mainstay of my modded install just for the sake of shadows alone. I think the OP should probably mention this for the sake of people with lower end systems, I wish I had given it a try a lot sooner. This was a nigh magical experience, and I'd like to thank Gameslinx for the massive amount of effort put into this mod.

I play KSP on a low-mid-range non-gaming laptop; it has integrated graphics. Nevertheless, I'm able to play an RSS install with 8k planetary textures, RSS Visual Enhancements, and a large suite of part mods at above 30fps in 900p. Provided of course that I set my render quality to fastest and disable vsync and anti-aliasing. Problematically, you don't get any craft shadows at all unless you set the render quality to at least simple, and setting the quality to above fast sends me to about 15 to 20fps in atmosphere with a ~50 part craft. But as far as I can tell, simple and fastest look essentially the same apart from the craft shadows, which leads me to assume the big performance penalty comes from rendering the shadow's shape as a function of the craft's shape and attitude. I'm not a programmer, so I'm here to ask: Is this correct? Because if it is, it seems as though making the shadow a much less detailed shape would save a lot of fps. What if instead of generating the shadow shape on the fly, a mod simply generated elliptic shadows based on solely the craft's size and aspect ratio in whatever initial attitude it is in the VAB/SPH? Most landers are essentially circular anyway, so not much is lost in those cases. I'm very curious if this is a plausible workaround to the performance intensive stock shadows because craft shadows are not just an aesthetics concern. Without shadows, it is very hard to accurately gauge your altitude while landing, so it's very unfortunate they aren't very usable on lower end systems.

I'm trying to build replica aircraft for use in RSS, and to do so I've been using a combination of procedural wings, procedural structural fuselages, and a variety of cockpits from so many different mods. I'm trying to do it as realistically as possible, so I need to be able to find out how much the cockpit of an aircraft weighs by itself. The dimensions aren't a problem since it's straight forward enough to determine from 3-view line drawings, and I can easily rescale parts with MM patches. And in case of a fuselage that's not circular, I can rescale non-procedural fuselage parts along a single axis to get the closest match possible. But in both cases I have no idea how much mass to give the scaled parts. Say I'm building a Boeing 737 replica. Is there any database online where I can look up the weight of individual sections of the aircraft? For example, how much does a single meter of round 737 fuselage weigh? Or how much would the cockpit section weigh (say it's arbitrarily defined as the section between the tip of the nose and a few meters down the aircraft)? I've noticed a lot of RSS/RO command module part configs have a ton of detail in the mass of many individual components within the pod commented into the config. Where does one go to find the same information for aircraft?

Is it normal for the KAMP window to always open up automatically upon returning to the KSC scene?

I'm getting some very strange visual bugs with the gas giants in my install of RSS. It's just the latest version of RSS, 8192x4096 textures, and dependencies as installed by CKAN on a brand new install of KSP 1.12.4. I was trying to get a feel for the performance impact of RSS on its own, so I didn't install RO or any visual enhancements like EVE or scatterer. All the gas giants are extremely bright near their sub solar points, even Neptune at its huge distance from the sun. It gets worse and worse the closer you get to them, to the point where in low orbits the entire visible portion of the planet below you is completely washed out white. Worse than that, the sun is visible through the gas giants in medium to high orbits. The screenshots below use Jupiter as an example. I can't find any indication that either I or CKAN have made a mistake installing the mods, but I also can't find any trace of this problem whatsoever anywhere else on the internet despite my best effort to search. So I'm assuming I've done something wrong here. Help would be greatly appreciated! Here is a dropbox link including logs, screenshots of my gamedata folder and my CKAN mod list, as well as the same screenshots posted above: https://www.dropbox.com/scl/fo/ojabqwg7zq4v0pqa9d39k/h?dl=0&rlkey=oims3m0htjz8qm53hnmtgno1o

I'm getting some very strange visual bugs with the gas giants in my install of RSS. It's just the latest version of RSS, 8192x4096 textures, and dependencies as installed by CKAN on a brand new install of KSP 1.12.4. I was trying to get a feel for the performance impact of RSS on its own, so I didn't install RO or any visual enhancements like EVE or scatterer. All the gas giants are extremely bright near their sub solar points, even Neptune at its huge distance from the sun. It gets worse and worse the closer you get to them, to the point where in low orbits the entire visible portion of the planet below you is completely washed out white. Worse than that, the sun is visible through the gas giants in medium to high orbits. The screenshots below use Jupiter as an example. Also, probably unrelated to the problems with the gas giants, Earth's atmospheric rim cuts off rather abruptly. This one is so subtle, though. Not sure if it's a bug or intended behavior. Screenshot below. Help would be greatly appreciated. Here is a dropbox link including logs, screenshots of my gamedata folder and CKAN, and the same screenshots posted above: https://www.dropbox.com/scl/fo/ojabqwg7zq4v0pqa9d39k/h?dl=0&rlkey=oims3m0htjz8qm53hnmtgno1o

Does the wind have a vertical component to it? Would love for gliders to be viable!

Thanks for the input. So to clarify, the game doesn't procedurally come up with contracts for entirely modded bodies? Talking about things like the basic achieve orbit contract or the contracts where you take science data at random waypoints. In that case, how about bodies that I've moved? For example, I now have Minmus orbiting Jool as a sort of Callisto analog. Will the contract system take that location into account and scale the timing/rewards, or will it continue to offer Minmus contracts in the early game with early game level rewards? Would you happen to know where I might find some documentation on how contracts work in general? If it's all messed up, I think I might be able to get some already made RSS contracts and simply replace the names of each body with the names of the bodies in my system since I'm arranging it to be very closely analogous to the real solar system. It's basically RSS with stock planet aesthetics.

I've been putting together a customized 10x scale Kerbol system by mixing and matching bodies from a few different Kopernicus planet packs. It's essentially a 10x OPM system: Moho, Eve, Kerbin, Duna, Dres, Jool, Sarnus, Urlum, Neidon, and Plock. But I've changed some of their relative sizes, rearranged and swapped some moons, added moons from JNSQ to the gas giants, and replaced Eve, Mun, Dres, and Ike with their JNSQ counterparts for aesthetic reasons. I may replace more of them, but I'll be keeping Kerbin as is. But I just realized I have no idea if career mode contracts will still make sense under an arbitrary system. Is the contract system robust enough that it'll somehow just work or will I need to customize that too?

My god. These are actual in game screenshots? This is KSP and it's somehow giving MSFS 2020 a run for its money. This is gonna be so sick when I can finally afford a computer that'll be able to run this at 60fps, probably some time in the mid 2040s.

I got sorta carried away writing this reply and ended up dumping literally all of my planet based complaints about the game here, sorry about that! I don't necessarily hate them, but I've always found Bop and Pol to be pretty boring. Part of it is aesthetic for Bop, it being nearly indistinguishable from Gilly other than its larger size. But also I think they should have given it a retrograde orbit for variety's sake, I don't think there are any bodies in KSP that do have a retrograde orbit. Then it could be an analog of one of Jupiter's many irregular moons with strange orbits. Either that or give it a much larger inclination and eccentricity than the 15 degrees and 0.235 it already has respectively. Also I find it annoying that it is much more massive than Pol and yet it's not rounded under its own gravity like Pol seems to be. As for Pol, it annoys me that it has the perfect look to be an Io analog but isn't one. That's unfortunate since Jool really could use an Io analog. Io is a very underrated moon in the real solar system. Also, Pol has the same boring orbit problem that Bop has, but in this case its even worse. The three large moons of Jool fill that low inclination, roughly circular orbit, and moderately distant semi-major axis niche well enough by themselves. It'd be more interesting to me if Pol were given a close in orbit far within that of Laythe's. Maybe just outside of its Roche limit. Then we'd have the amazing view when landed on it, Jool absolutely dominating its sky. And it'd give us some lore about Pol being a doomed world in a decaying orbit like Phobos is in the real solar system. Also there is a lack in rotational period novelties. Eve and Moho have relatively short rotational periods compared to Venus and Mercury. It'd have been nice if at least one of them had an extremely long rotational period. And I think it'd be great to give at least one of the planets in KSP a retrograde rotation like Venus has. Again, for variety's sake. I recently found out that's possible without Principia. Weird since it's effectively an axial tilt of 180 degrees and axial tilts aren't possible in stock. I guess the part of the code incompatible with axial tilt doesn't apply to a completely upside down body. The rest of my complaints about the planets in KSP are aesthetic based. Eve and Duna are way, way, way too monochrome. If you've been anywhere on those worlds, then you've been everywhere on those worlds. Eve has nearly the same shade of purple regolith everywhere except for the oceans. Duna has the same problem with almost all the regolith on its surface being the same shade of orangeish-red. At least it has those huge, icey poles to spice things up, but within them you get the same problem, just the same boring off-white ice everywhere the eye can see. Not only that, but its all rolling hills all the time. I know KSP is capable of having interesting terrain, it's really fun flying through canyons, and up and down the sides of mountains, and following along the long, winding rivers on Kerbin. But that level of detail never made it to the other planets. Especially Ike. It has like four or five shades of grey regolith and the same very gentle rolling hills everywhere, it's probably the most boring object in the game, even worse than Dres. The only saving grace for Ike is its uniquely large size relative to its host planet Duna.

The developers of KSP really, really should have added clouds. Maybe this isn't unpopular among all KSP players, but whenever this topic has come up over the past decade, the majority opinion on this forum at least has seemingly been that clouds are merely an aesthetics concern and thus a waste of developer time to add when there are always more important priorities. But I vehemently disagree with that. Clouds aren't just an aesthetic feature in flight sims and games adjacent to flight sims like KSP. They are an important component of situational awareness and context for the environment you're in. At a glance you can use clouds to estimate your altitude by how far above them you are compared to how high they look above the ground. Or by how far below them you are. You can use them to estimate your speed as they'll often be the only near enough objects that you can watch zoom past you. That and they provide the gameplay challenges of having to attempt targeted landings without being able to see your landing site or runway on a cloudy day, making situational awareness more challenging in those specific situations. They can also obscure mountain tops, making it necessary to be careful when flying over unfamiliar terrain lest you end up smeared all over the peak of K2. Not to mention of all of the spinoff gameplay mechanics that could have come of clouds. Weather satellites are a pretty common payload sent into orbit in real life, but obviously unnecessary in KSP. But if we had clouds we could have features where we launch satellites to take weather data that would then give us predictions for where and when we'd have dense cloud cover. That's assuming that the clouds wouldn't just be a single texture rotating about the planet, though. But they are indeed also an important aesthetic feature for maintaining immersion. For example, flying planes without clouds or any degree of atmospheric scattering just feels like you're in a giant void of still, unperturbed air. It just doesn't look anything like being in a real plane. As for space flight, they are a very important visual indicator for the presence of an atmosphere. From higher orbits you have no real indication of Kerbin's atmosphere other than the presence of the oceans without clouds or atmospheric scattering. And don't get me started on Eve (the planet, not the mod). What, it has that extremely thick, dense atmosphere and yet you can still see all the way to the surface like it isn't even there at all? Seeing that really does a number on my suspension of disbelief. The developers themselves understood this was a huge problem. You know how I can tell? If I recall correctly literally every single picture of a planet with an atmosphere in the loading screen contains clouds, either in the fan art images or the gameplay images that have the "This image contains mods" disclaimers. They had to believe clouds were an important visual feature in choosing those images. I know, I know, our wonderful modders in this community have taken it upon themselves to add clouds to the game free of charge. And for that I am grateful to no end, I can't even play this game at all without clouds. But I get the feeling that if the KSP devs themselves had added clouds they would have been able to do it in a more optimized manner. With EVE installed using SVE templates I max out at 35 fps flying about Kerbin with the lowest graphics settings and a craft with 75 to 100 parts. And that's with volumetric clouds disabled. And I can just completely forget about using Scatterer, it brings me down to around 20 fps even with single part crafts. Please, anyone with experience modding KSP let me know if I'm wrong about hypothetical stock clouds having better optimization potential. I'm not a programmer and I have no real idea if that's truly the case. That's just always been my assumption since the KSP devs would have access to the source code. All of that said, it also majorly sucks for console players that they'll never get clouds in KSP1 at all. From what we've seen, it looks like KSP2 is going to right this wrong with its inclusion of clouds. Thank god. I can't wait until the 2040s when I'll finally be able to afford a good enough PC to run KSP2 on max settings with at least 60fps and maybe even a couple of mods installed! Unrelated, but maybe around that time period I'll also pick up MSFS 2020. I've heard some great things about it, including its lovely, fluffy clouds!

Updated SXT to 0.3.29.7 and yeah the problem persists. I opened an issue on github and provided new logs using the updated version of SXT.

Hello @linuxgurugamer, I'm having a small problem with the hatch on the Entente cockpit. I'm running the 0.3.29.5 version of SXT on KSP 1.11.2 so that may well be the cause of the problem, but I figured I'd report it just in case. When I send Kerbals out on EVA they pop out of the hatch feet first while facing upward. It seems as a result they're unable to grab hold of the ladder and so they just fall off the cockpit. I have a short video of this phenomenon as well as logs in this dropbox file: https://www.dropbox.com/sh/x7zdc8axk7nv32i/AAA4jI7hQ_pcEZDVWlWWfbSha?dl=0 This is on an install with just the two dlc expansions and SXT w/dependencies.

Did anyone ever figure out a fix for jet sounds muting at idle? It looks like it was brought up in this thread a couple years ago but was brushed aside as being a problem with the stock jet engine sound configs. But the stock jets definitely have sound at idle. The suggested solution of simply changing the volume curve so it doesn't drop off to zero results in jet sounds even when the engine is shut down.

Alright, I did AtomicTech's suggestion and reduced the density of intake air from 5kg/unit to 1kg/unit. I loaded up a variety of aircraft in the SPH with both modded and stock air breathing engines, and from a cursory look at the KER window it would appear everything is the same. Mass, ISP, thrust, burn time, and delta-V all remain the same in both jet and prop powered aircraft. However, when I launch a craft with an intake, the mass only increases by 15kg instead of 75kg. I may reduce it further depending on whether this still causes big differences in the FAR stability derivatives. For now, I'll consider this a success! Looks like it worked unless there are some more obscure but relevant parameters not listed in the KER window. If I'm missing something please let me know. I noticed while looking through engine configs that all the air breathing engines in both stock and Airplane Plus have: PROPELLANT { name = IntakeAir ignoreForIsp = True Would this account for any changes in intake air mass? Or would the mass affect things beyond just the ISP

I was thinking of doing something like that, but I was unsure if that'd alter engine performance. I don't know enough about how the engines work to know if that'll have a side effect like changing ISP or maybe their fuel consumption rates. Thanks for the config, I'll try it in game to see whether or not that's the case.

Or just a lot less heavy? Neither the stock engineering info nor KER count intake air toward the total mass of the craft while in the editor. For your typical KSP aircraft, this can be treated as a rounding error. But when you're building a decently accurate Cessna 150 with an empty weight of 520kg, it starts to become a big problem. The prop engines I'm using come from Airplane Plus and they all seem to store 15 units of intake air. Intake air has a mass of 5kg/unit, so this means every craft I build has an extra 75kg of unaccounted for mass in the nose. It doesn't move the CoM in the editor, it doesn't show up in KER until after I launch, and FAR bases the in-editor data on the airless mass. I tried simply reducing the amount of intake air stored in each engine by changing their configs, but for some reason it didn't actually change anything once I loaded up the game. The engines still had an extra 75kg of mass even when I changed the air intake storage to 4 units. I know this has to be a result of the intake air because it doesn't have this extra mass if I launch with the intake closed. I was tempted to just change its density in ResourcesGeneric, but I don't know if that'll alter engine performance. Is there a way to reduce intake air mass without messing anything up?

It seems that landing and take off speeds are quite a bit higher than what you'd expect in real life. After reading through a bit of both this thread and the last FAR thread, it looks like it's not a problem with the aerodynamic model, but rather because stock parts are just extremely heavy. As a result, if you want to build an aircraft capable of good low speed flight, you'll need wings that look disproportionately large compared to real aircraft of similar size and capability. I'm looking to remedy this by making duplicate configs of plane parts with reduced dry masses. And so as not to unbalance the space flight part of the game, I'll remove the oxidizer tanks from fuselage parts, remove the monoprop and reaction wheels from cockpits, and significantly reduce temperature tolerances. That should be a good deterrent to bringing these lighter parts into space. The thing is, I have no idea exactly how much to reduce the dry masses by to get realistic aircraft weights for a given size. Is there a general factor that accounts for exactly how overweight stock parts are, or does it differ from part to part? I was thinking of simply copying SMURFF dry masses, but I don't know if those are accurate for both rockets and planes or just rockets.

Is it possible to get Sarnus and Urlum to have ring shadows without Scatterer? I'm not talking about shadows casted onto the planets by the rings, but just the shadows casted by the planet onto the ring Edit: Nevermind, figured it out. There is a config in Stock Visual Enhancements that sets @useNewShader = false for all bodies if scatterer is not installed. Removing that fixed the problem.

Thanks for letting me know, this looks like exactly what I need! I'll give it a shot next time I load up the game.