CBase

Mine enjoy reentries with their head outside the service bay, so it is not a problem in general. But heat transfer and rotational stability are important to watch, otherwise they get grilled

Thank you, since I only modified parts with MM so far, I did not deal with paths in model and texture nodes. How about allowing ./ for same directory paths ? A small, pretty generic MM extension could then convert these into qualified paths.

Sorry, but I still did not understand why a pathname for a mod needs to be checked / protected. Is it because of reference paths in MM when stuff depends on each other ? Can you provide an example maybe ? I do understand you want to reduce support time spent to fix these issues, but to me it is very counterintuitive that a name of mod install directory matters, so I would rather think how can make it possible and avoid support problems instead of optimising support ?

Staging parachutes during ascent is how to play KSP At least it happens so often to me that the face palm gets softer these days.

Although a pretty straight quadcopter, after playing around with your stock Qcopter and looking at the KAL settings: I found the craft to be hard to control without SAS and I found no way to fly fast forward, since you are missing the collective control and the different KAL overwrite each other, so you can never have two directions at once. An additive control and bound to SAS is really what is missing for KALs for a perfect quadcopter.

Really interesting, could you as well somehow explain how you configure the KAL for axis control ? Redacted is right: channel mixing (or at least addition) is what is really missing as I see it.

Depends I am building quadcopters to move around on planets with atmosphere, but without oxygen for jet engines. So my target is to keep it really simple and light weight and I don't care about realism. However after reading your answer I looked quadcopter definitions up: https://www.dronezon.com/learn-about-drones-quadcopters/how-a-quadcopter-works-with-propellers-and-motors-direction-design-explained/ Since I am building in VAB, I had a different understanding of roll and yaw. Only a forward facing command module in SPH will conform with standard definitions. In regards of the official terms for quadcopters, you can roll and pitch with MCS for blades. Yaw is tricky as I doubt KSP Control Surface Control understands it right. But maybe... I will test it... Anyway adding blade angle via servo control and a KAL will work to influence rotors as described in above report. Just keep in mind that you need to mentally replace RPM with angle of incidence for the blade since KSP motors are to sluggish for RPM control.

In my current career game I landed nearly everything and tried hard to be as close as possible to the runway as bewing said. And it made a big difference: After 3 launches I wasn't fund restricted anymore and very soon I had enough money to launch for contracts in parallel.

I just discovered some really great enhancement not mentioned in the release notes: You can now alter deploy angle independently from authority limit ! Great improvement for all rotors and landing spaceplanes.

If you ever watched an early Falcon 9 launch, you might have noticed that they got very excited about something called MaxQ and relaxed once they passed it. Actually especially with SRB this might be part of your problem. As others pointed out rotating the big fairing sideways does increase drag a lot. Speeding up in thick air increases drag as well. So do turn early, but only few degrees (maybe 3-5) and watch dynamic pressure in aerodynamics stats window (Ctrl + Alt+ F12 > Physics > Aero > Display Aero GUI). If it starts to flip, throttle down a little in the next try until atmosphere gets thinner to keep dynamic pressure low. Or simply reduce TWR and add dV for the aero loss. Draggy, instable stuff likes a more vertical launch trajectory than the optimal gravity turn of slim rockets, but you can launch almost anything into orbit

Actually for roll the easiest solution is to simply use a reaction wheel. The required torque for roll is usually small enough and KSP reaction wheels are strong You can make pitch and yaw work via authority limit from the blades if deploy them. Depending on rotation you might need to reverse deploy and/or use negative autohority limit. This way you can keep part count and rotating mass down. Angle Prop sounds like you added a servo to control blades. Although it does work mostly, SAS will not affect these. Basically disable all control and enable only these: p | y - + - y | p I do have two KAL on my quadcopters: one for engine control, which spins up RPM and torque and one for lift (collective) which controls authority limit. The engine control is bound to simply switch control key and collective to throttle control. This way it controls very much like a rocket engine VTOL. For figuring out the right configuration use F12 aerodynamics and very low RPM, so it stays on ground and does not crash, but you will see forces direction.

If you read the two tutorials about VTOL and helicopter, you will find that they mainly use the blade angle to control lift exactly for the reason. This is even more true for quadcopters as you can use yaw and pitch directly if choosen well.

Why would you waste money block the beautiful view with a fairing ?

One of the best guide on manual gravity turns I have read was: Turn 10 degree east after reaching 100 m/s (which makes rocket stable) and push time to AP up until it is about 45s. Then throttle down and hold time to AP at 45s until AP is high enough (e.g. 80km), then stop eninges. Throttle back up at about 10s before AP and keep AP 5-10s ahead. The learning effect is to keep AP in front, so you always raise PE and AP and get a feeling for balancing the split between AP and PE via time until AP. Later on you can keep full throttle and vary the ascent angle to balance orbit eccentricity until 30km alt, then just boost straight and use bewing nav node methode to circulize. When starting with KSP getting into a circular orbit is desireful, as it allows to split the task of ascent to space from hitting your destination. Placing a nav node in a highly eccentric orbit is a pain, while easy to drag around on circular orbits. After dozens of ascents you will slowly blend ascent timing and target navigation, but for now allow yourself a step in between.

And another for even more https://imgur.com/gallery/h18YkdQ

MPL are more useful on interplanetary missions, where transfer times are several 100 days. I tend to double or triple collect any science on interplanetary trips, transfer one into lab and hold rest for Kerbin, so nothing is wasted if my discoverer returns before all science data is processed. Although you get 25% bonus in research lab when processing science from the Mun, since your scientists are at most level 2 you will only get ~14 sci/day if it is full of data. Returning science in a box to Kerbin is way easier and helps you to get more science faster. Not to forget the hassle to land a MPL back on Kerbin.

I just discovered that you can get missions to ferry tourists to a station for a few days. If they are in Kerbol orbit, even very close to Kerbin the rewards are huge. So I put a station with lot of crew space just slightly ahead of Kerbin in same orbit, which I can reach in about 7 days with less than 1500 m/s ∆v and waited for a contract. It came: 10 tourists, 34 days: over 80 000 000 funds ! After digging around I found that a viewing cupola make getting these kind of contracts more likely. For the desired destination to qualify as a base you need antenna, power generation and docking port as listed in every construct base contract.

I am no flight pro The 14 m/s ∆v was after the landing when I discovered that there is no ore below me to refill. To be honest the retries until I made a safe landing where I could mine ore did vastly improve my suborbital flight skills.

Most embarrassing moment: Minimus science hopper: hopped into a biome without ore. Darn, but no problem, i refill on the next. Just barely made the biome change with 14 m/s dV left in a crater, deployed mining drill and again no ore. Note that I did have survey scan in orbit, but who needs to look. Second attempt to a different biome and landed high north in the shadow of a mountain: no sun, no drilling. Most frustrating: Modified trajectories mod to include deployed wings and orientation. Somehow messed it up when switching to Quaternions and unfortunately I forgot to commit the best working code before. Couldn't pick up so far. Proudest moment: My First landing at KSC runway from orbit with rocket first stage in Falcon 9 style recovering 100% value.

I just observed that travel itineraries are not updated if the passenger is inside a Long Passenger Cab for orbital and sub orbital objectives. Fly-By did work for some strange reason.... Stock passenger parts work fine. Any Ideas ? Actually this cabin is smallest and most lightweight except for external seats :-)

Thanks, this is a damn good reason. Makes throttling even worse, which is kind of critical to landing, even when you neglect the gimbal problems. The dual-bell noozle sounds interesting, but as he is rushing for time it is no surprise that it is not in the current design. This is actually a claim that I don't understand, if the stage altitude is not way lower than for Falcon 9. Currently the Merlin 1D Vacuum has 934kN for roughly 100 t second stage or 9.3kN/t TWR and seperates around 80km altitude. A starship with 4 Raptor Vac engines would have 4x 3500kN for 2400t which is only 5.8kN/t TWR, but you get a much better ISP in return for the gravity loss with longer burns.

Anyone has an idea why the hell they build sea level raptors in a second stage ? I mean for landing burn they showed around 50 m/s dv. Even with a big ISP penality I would have thought that vacuum raptors are less weight with more fuel than carrying around 3 SL engines.

I did make some progress to decrease fuel usage by changing descend angles: I did release some preview builds to test: https://github.com/cbase2/KSPTrajectories/releases/tag/AtmoLanding_0.1 https://github.com/cbase2/MechJeb2/releases/tag/AtmoLanding_0.1 Known Issues: Deorbit optimization is distracted by turning control surfaces as Trajectories takes their current angle into account -> Disable and reenable bevor hitting atmosphere Course Corrections sometimes is highly unstable -> very distracting as Angles jump wild, still hits KSC usually

If someone is interested, I made some progress on landing on atmospheric planets. It connects MechJeb with KSPTrajectories for target predictions as most players do. It is still highly experimental, only debug builds work as I still have stuff left in that section within KSP Trajectories. You can pull current work from https://github.com/cbase2/MechJeb2 and https://github.com/cbase2/KSPTrajectories/tree/retro. I tested simple rockomax first stage with direct retrograde landing, rockomax and kerbodyne angled reentry using deployed control surfaces at tail which act as canard on retrograde entry. All landed at runway or KSC, but still may need more or less fuel depending on educated reentry parameters for PE and target undershooting Trajectories predictions. However canard attitude control seems not working, so I had to disable all controls and manually adjust deploy angle to keep pitch. This is what I am currently working on, so I can simply enter some angles in Trajectories and MechJeb uses canards to follow it. My fault, for control surfaces in retrograde use, you need to set authority to negative values, even with manual control. Next is to alter Trajectories pitch angle to improve aerobraking instead of thrusters use.

I had some time to get into kerbal modding and looked into the source and found that it seems related to wheels and landing legs special colliders. The bounding box checks are fast enough for me, so I just replaced the troublesome line with ship / vessel complete part list, which fixes the issue. Change is pushed into my fork, feel free to add.