Alioth81

The stock RC drone is very difficult to control. Something is wrong with the probe core orientation and this also made SAS go crazy. I deleted the OKTO 2 probe core and added it again. In addition I moved the center of lift a bit to the back as it was to close to center of mass especially once the fuel tank gets empty. For me this improved the control greatly and I think stock craft in general should be easy to fly I added my craft inside the spoiler as inspiration but other changes may work as well.

I am a long time KSP1 player, just started did the tutorials but now I found some things that were easy in KSP1 but I struggle with in KSP2. Although I like many of the new UI features some things were just not obvious for me and maybe someone can help me? I like the fact that in the VAB I can aim the camera to a specific part with a click with the middle mouse button. But how do I aim the camera to a part in flight mode? Middle mouse button does not work and right click context menue option like in KSP1 seems not available. I some times end up with some kind of confusing free camera but somehoe the aim seems always to be on center of gravity for me. I did not find small/medium engine plates. Are engine plates named differently and are small engine plates even available? There seems to be one for very large rockets and for large spaceplanes but nor for small rockets As I did not find engine plates I tried to use inline fairings as shrouds (I want to use the XS "Spark" on a small fuel tank). How can I porperly connect/close an inline fairing? Pulling with the arrow never achieves a good fit and gives errors all the time wheras when I disable "snap" I can get a good fit but there is no inidcation if the part is properly closed. Is there any indication if the inside is considered "protected" for drag, heat etc? Delta V readout in VAB seems to be in vacuum, how can I toggle/slide between atmosphere/vacuum delta v read out ind VAB? At the moment I have to hit the launch button because on the launchpad delta V is current athmosphere level. Second related question is how do I see TWR of the different stages? Also TWR seem to be sea level compared to delta V which seems vaccuum is this correct? The new altitude indicator has to modes delta ground and above sea level. It confused me that delta ground measures in relation to ocean floor and not water surface, It is probably technically correct as water is not ground but I nearly crashed. How are you using the the altimeter to get always the correct altitude above surface (water or land)? Am I supposed to switch from ground to sea level mode when flying above water for a landing? Can someone explain to me the new center of pressure indicator? The lift arrow (or whatever it is) seems very odd and off centre even on rockets with radial symetric fins

Somehow supplies are not first used from tanks set to a higher flow priority but across all tanks equally. Do I need another setting besides flow priority for life support resources? Or maybe it not intended to work at all?

Thanks @UnanimousCoward I was referring to the controllers and you are right they seem already physicsless and I always thought this means also without drag (which it is not the case, so I learned something ). The values in the config seem indeed very low. However when I activated the debug mode during a launch I experienced it differently. Do you have any explanation for this high discrepancy? Based on the config files I assumed they should be lower than the radial drogue chute? Edit: I did check with the thermometer and the barometer as well. The drag of the thermometer is very small but the one of the barometer is similar to the smart controllers. I guess the high drag especially in the transonic area could be related to shape but then their shapes do not seem that different?

The Smart parts cause a lot of drag when compared to similar parts. Probably 5x or more compared to an undeployed radial drogue chute (which is even slightly larger) Is this intended or do I have a config problem? In my opinion it should be less than the not deployed radial drogue chute and probably even a physics less part like the thermometer to make construction of crafts easier

Any tips how i can prevent burn up during re-entry from suborbital flights of sound rockets early in career? I have no heat shields yet and some times my parachute/science avionics survive but most of the time they do not. The tanks and nose cone always explode

I love this mod and the only thing bothering me was that the original cloud config for Kerbin has the volumetric "popping" in very abruptly. Anyone else had this? In case yes my config is shared in the spoiler below. I made the transition smoother while trying to preserve the thick cloud layer. It works ok for me from a performance perspective together with EVE redux. To use it open the clouds.cfg located in \GameData\AstronomersVisualPack\AVP_Configs\Stock with an editor and replace the object named Kerbin-MainClouds with the config below (it is probably the first object in the file). Make sure you do copy/replace all the brackets as well.

Does someone have a tip how to adjust a config that volumetric clouds are not as bright at night compared to the 2-d cloud layer? Or how to make them same brightness? The 2d-layer becomes practically invisible in the dark whereas the volumetric particles stand out quite a bit at night. I also use scatterer maybe it is related to that?

I posted this in the scatterer thread but reading the last posts here it is probably Distant Objects that is causing this or the sequence KSP renders the objects (therefore I repost it here) I am Running the latest scatterer build based on some AVP configs and distant objects. I just noticed something I never actively saw before. Maybe it was always there but I only notice it now because the atmosphere seems to be larger or it is something that changed. Eve seems to be drawn on top of the atmosphere instead of behind it. I believe this is similar to what was reported with the comet plume correct? Can I do something about it? Maybe instead of black it could be transparent? Would this have any other side effects? (you can also see Moho closer to the sun)

I am Running the latest scatterer build based on some AVP configs and distant objects. I just noticed something I never actively saw before. Maybe it was always there but I only notice it now because the atmosphere seems to be larger or it is something that changed. Eve seems to be drawn on top of the atmosphere instead of behind it. Is this caused by distant objects or scatterer? Can I do something about it? (you can also see Moho closer to the sun)

Thanks for linking that post I was not aware of it. This sounds right the last 3 parameters of node_attach define the orientation of attachment and it needs to be set according to your model. I never used it because all the parts I modified seemed to be oriented correctly. So I learned something new as well. I cannot say if e is incorrect and I do not know what effect it has - No configuration I have ever used had it in. I think it gets calculated automatically if you do not set it but maybe there was a reason it was set for this part.

@Waifu Art Thou Romeo I believe it will use the origin of the part model as center of lift I think you need to include the transform name (not sure if this actually can cause this?) What actually shifts the CoL is "rootMidChordOffsetFromOrig" and I used it for some airplane plus parts. Here is the example for the advanced canard in the FAR config Not sure what "e" is for in your config. As you CoL also looks asymmetric maybe there is more that needs to be done on the part.

@ezequielandrush and @Sherpard2 Just want to show you a quick video I made when getting parts of the Airplane Plus mod adapted for FAR. I already forwarded to the timestamp where I tested some airliner parts. For me the key for a successful landing is a slow landing speed and good stable control (it facilitates breaking, reduces stress on parts and gives you more time to tune your approach). To achieve this I focus on those parts: Ensure you can generate enough lift to fly at slow speeds. This means you have to either have: large wings, flaps or the ability to fly at high AoA (or a combination of those). Flying at high AoA at low speed normally requires powerful control surfaces with high deflection and/or center of lift close to center of gravity. (I will use this opportunity to advertise the dynamic deflection control option that helps with this but many other possibilities exists). I also tune the wing strength and often you can reduce it a bit to make your craft lighter which makes low speed flying easier. I also bind the "deflect more" or "deflect less " commands of the flaps to action groups to have quick access to them. Being able to reduce speed. For this you can use spoilers (and FAR conveniently binds them to the "break" key) and/or flaps which as a side effect of generating lift also increase drag. Be aware that depending on your flap location they can also adversely affect your maneuverability and increase your aircraft pitch up or pitch down tendencies. In the video you can see how I use 4 spoilers to generate very large drag. If you do not want that you can also do some turning to reduce speed or anything that increases drag. Have a good controllable plane. It helps if your plane has some maneuverability and stability to tweak the final approach. This can be done by good design that is stable without continuous control inputs (can also be trimmed) or relying on stability assist systems. The stock and the FAR system are often enough but I personally like the Atmosphere Autopilot mod on default (this also helps with long distance flights to hold altitude). Do not do big maneuvers just before landing and rather go for another round if it does not look good (if you have the fuel for it) With this I find landing in FAR quite easy and for instance the Airliner below lands at a speed of 70 m/s (which is still quite fast but feels slow in Kerbal standards). Hope this helps.

I have problems rotating some parts. (for instance the KS-H1 Fixed Landing Gear or the KT6C "Kitty" Turboshaft Engine) They seem to immediately jump 180° on certain rotation angles and the angle shown in the editor seems to be inverted when changing to the flight scene Dos anyone else experience the same issue? Can this be fixed?

I try to patch airplane plus parts for FAR but when setting the values for the MAC (Mean Aerodynamic Cord) I found some discrepancies between the FAR/Blender tutorial and the formula that is used to calculate MAC on trapezoidal wings on some RC-plane sites. According to the tutorial you add root and tip chord and divide by two (a simple average) According the majority of information I found the formula should be rc x 2/3 x (( 1 + t + t2 ) ÷ ( 1 + t )) where rc is the root chord length and t the taper ratio (root chord divided by tip chord) In my opinion the second formula looks correct. However the stock part patch of FAR and b9 procedural wings seem to be implemented according to the formula in the tutorial. Does anyone know what is correct and should actually be used?

Regarding the latest point I think it is not possible for TURD to recolor top or bottom separate. I think procedural wings uses the same mesh called "surface" which has the same texture for top and bottom, there must be code within procedural wings to decide when to use the top texture and when the bottom texture is used and it is reassigned. I think there is currently no way for TURD to discriminate top/bottom unfortunately.

I created a small pull request on github that adds an option for dynamic control surface deflection. I always faced the challenge that crafts that are agile at low speed become super reactive at high speeds (by a user with keyboard but also by sophisticated PID autopilots) and would quickly disintegrate in flight at the slightest control input. Therefore I created a new option (disabled by default) that allows the user to select a speed after which control input decreases with a selectable exponent until it reaches a definable minimum. Example: if I choose start speed 200 m/s and an exponent of 2 the deflection at 400 m/s will only be one quarter from the one at 200 (e.g. 4 instead of 12). In addition I added compensation for density of the atmosphere this acts against the reduction so that there is more deflection in the thin parts of the atmosphere (again this only counters up to the limit of the original "requested deflection") There is also a minimum value that can be set to ensure a minimal amount of deflection even at high speed. I created a small video showing this change in action and a graph showing the approximate reduction in control input. The video shows that the planes keep low speed maneuverability while reducing the control input at higher speed. One example is a high speed plane the other a WW2 style fighter. First the regular case and then at 1:30 the same flight profile with dynamic deflection control surfaces enabled The graph show the expected control input reduction (at sea level) for different exponents in relation to start speed X

I just made an expedition to Kerbin's north pole and the landscape seemed quite grey and rocky. Is this normal or is this a problem with my installation?

@physicsnerd and @SpaceFace545 I opened an issue at github and it was closed again solving my problem with the textures not correctly displaying. It was a mistake on my side but its resolution might help you as well as you experienced something similar. I was missing ModularFlightIntgerator (which is required by kopernicus) When upgrading from an older KSP version I installed Parallax (and kopernicus) but uninstalled FAR. Somehow I managed to confuse my CKAN and it still had the checkbox from modularflightintegrator ticked although the folder was not present anymore! For me uninstalling everything and then starting again with parallax letting CKAN install all dependencies properly worked and I can enjoy the mod in all its beauty

No I am not. I am playing with the stock planets and using the parallax stock planet textures

I have trouble in KSP 1.11.2 , textures look white and blank (similar to what Zensei seemed to experience). I use the latest version of kopernicus stable and parallax. It works fine if I copy the kopernicus and parallax folder into my old KSP 1.11.1 installation. Did the 1.11.2. update break something? Does someone has an idea what to do to fix it?

Can someone tell me if this is an effect from parallax? It happened when I installed it but it could also be a side effect of another visual mod? Edit: It seems EVE caused this. Switching to EVE-Redux seems to have solved it in this case. It feels like playing a different game and finding anomalies is really difficult now as I was used to look for little shadows. At some point close to Minmus the beautiful Parallax texture blend in but it is a pretty rough transition from greenish to greyish. To some degree this happens also when you move closer although the shift in color is not as noticeable but features of the planet seem to jump around when more details appear. I run on 1.11 with the following visual mods: EVE, Scatterer, DistantObjects, Planetshine, RealPlume, Spectra

I intend to update the effect of the kodiak engine (or any engine I plan to use in tight clusters). As the engines are tightly together I thought about saving particles by having less emissions per engine but some random component in z to maintain a continuous overall flow. I believe random cone emit or initial offset only works in x and y. How can I do something like this in z? Edit N°2 and probably best solution: Using a plume with "partTransform" instead of "thrustTransform" in the case of the Kodiak for aspects of the plume that can be merged across all 4 nozzles. Edit N°1 (original experiment): From my short test (and maybe this interests someone else): vRandPosOffset Spawns the particle somewhere between the original emission point and the selected offset (in m) The particles all have the same speed and travel in the same direction - it looks more or less uniform (with some randomness) randConeEmit All particles spawn at the original emission point (so it looks pulsed in the first few meters) Particles seem to spawn at different speed and overtake each other and also travel in slightly different directions An alternative that also leads to blurring of the original pulsed emission but looks a bit wilder and flame like as particles which are at different decay stages and very different speeds Here a picture on how this looks if emission is set very low on a Kodiak (1 engine 4 nozzles that "pulse" at the same time) Another picture of 5 Kodiaks confirms that randConeEmit gives you a flame like effect whereas with vRandPosOffset it looks more stream like. With high emission rates I prefer the normal look but if reduced emission rates are needed some randomness with vRandPosOffset gives engine clusters an acceptable look in my opinion. The only down side is that randomness can "break* the stream look. Another solution would be to have the particles within a multi-nozzle engine spread out similar to the "declutter" effect instead of spawning all together in a big blob but this is probably no achievable with configuration only?

I have the breaking ground expansion and it seems I lost the terrain features like the Olivin rocks on minmus where i parked a probe before I installed the mod. Does anyone have an idea what the problem could be? Edit: it seems they are just located at a different place now In addition Minmus looks great but somehow its surface features start moving when I approach. Is this normal?

When having a MK1 command pod with a parachute and a Flea booster somehow the cross section of the MK1 pod is ignored leading to very high transsonic drag. Interestingly if you add basic fins to the flea booster the cross section seems to be calculated correctly. Tested in 1.10.1 with the latest FAR