XLjedi

Haven't had much luck getting the button to appear in the SPH for VV. I do get the message confirming everything is installed... and the Toolbar Controller shows Vessel Viewer on "Stock" but there's no VV button on the stock toolbar. Any suggestions?

As long as they are consistent this time with how the zoom in/out up/down movement works between the SPH and VAB, I'll be happy.

I launched Jeb in a rocket 5km and recovered it.

It's as close as I could get to a hovercraft...

Most recently, I rescued the crew of the Ger-Bal 2 following a last minute bailout after the chute exploded shortly after deployment... I didn't even know parachutes could explode.

My ideal career mode would not necessarily be watered-down... it would be the standard career mode with one exception. I want a "Skunkworks" option where I can build something in sandbox and then purchase it for use in career mode (before the tech is actually available). Each part that is undiscovered tech would cause the price of the part to be jacked up like 5x or 10x as an experimental part. ...and then I have the craft to use, but if I can't recover/reuse it... I lose the parts. Similar to how those "test this part" missions work. This might let me use a favorite spaceplane design in career mode (at a very high cost) to accomplish certain missions for science and funds, but also heavily incentivize me to land the craft carefully and build other stuff to refuel/reload because the thing is too darn expensive to justify using for only one mission. Might let me use the RAPIERs in experimental craft mode before I actually have unlocked the part via science. I think I could refuel, reload, and reuse a spaceplane about 5x before the kraken started to dismantle it.

I couldn't find any bug tracker ticket for it, so I added this one... https://bugs.kerbalspaceprogram.com/issues/24435 If others would mind testing and confirming/upvoting, I would appreciate it!

I have a craft that utilizes two Docking Port Juniors with same vessel interaction enabled. The example might be for a craft with a hinged door that uses docking ports to secure the door when closed. To close the door, the hinge motion is assigned to action key 4. When the door is closed, the docking ports are used to lock it in place. The problem I'm having is that I have tried assigning various combinations of "Undock", "Decouple Node", and "Same Vessel Interaction" to action key 4 so that when the hinges try to open, the docking ports are decoupled. ...but it doesn't work. I can manually in-game right-click the docking port and break the seal using "Undock" but when I assign "Undock" or "Decouple" or both to any action key... it does not work. Should I post this one to bug tracker? It only seems to be an issue when I am trying to use docking ports with Same Vessel Interaction. Although, I have tried toggling on/off the vessel interaction and it seems to make no noticeable difference. For instance, I have no problem getting action keys to undock ports when dealing with subassemblies. Anyone else come across this?

is that a game?

For me... I think the main thing that is missing is some sort of event driven deployment. For example, being able to link play position to speed or altitude. Maybe throw in something related to maintaining balance for a walker? Tie it to the navball maybe? I also feel like I could use maybe one extra set of translation-style X,Y,Z key sets.

@djr5899 Cool ideas! I certainly wouldn't be the first to create a "how to build a plane in KSP tutorial" though. So not sure how much extra value I could add there... I did recently build a very simple dual juno jet plane that you could take a look at. It's also a great candidate for prop-conversion. When it comes to propeller craft dual engine is easier to manage than single engine. I think my one exception to the norm is I very much prefer to map both torque and rpm power curves to the throttle. The KAL-1000 for noobs video would be pretty easy, since we are all still noobs. Hasn't really been around too long for anyone to have gained gifted status. I have not even tried to implement a walker-type rover. I would put that on the higher end of the complexity ladder, and probably questionable in terms of usability. A walker may be something I look into, but for now I don't really see it as a valid type of mission craft. From what I've seen others try, they seem to rely on scripted loops for walk/run and then fall over if you try to stop or turn. So maybe a cool toy, but probably not really mission ready. For KAL usage I would start with implementations that I think are both cool and have valid mission use on craft like: Engine Control Module Mapping Spotlights Tied to Yaw Adding Steering to Larger-sized Landing Gear! Hinged Doors that can be toggled open/close with a single key press Folding Ramps Refueling Booms / Robotic Arms Articulated Pincher-style Claw Hydraulic Braces for Docked Craft Directional Thrusters Variable Geometry Wings* * I haven't been too thrilled with the "floppiness" of the robotic joints so I've put my variable geometry wing designs on hold for now.

Yeah... I've seen it.

The points in my doc are all still valid... although there are a few additional tricks I've picked up along the way and @Squad rejiggered the blade pitch on us in the 1.8 upgrade (although nothing too dramatic). If you have something specific you need help with in terms of how to setup blades or how to use the KAL-1000 let me know. I built a pretty cool articulated claw for one of my rovers to pick up stuff with the KAL, and recently I made a folding ramp with it for a landing craft. I could try to post a short-ish video if you have something in mind? ...although lately my "short videos" have been an hour long.

Well, considering the quality of my videos... that"s probably good advice!

so... I will never add music in a video on youtube. What else should I avoid?

@Brikoleur Yeah, I figured it out... it was actually a problem with the KAL-1000. For some reason, the Pitch/RPM/Torque settings I had in there became corrupted. The only way to fix it was to delete every one of the settings in the KAL and start from scratch. Just took me a long time to figure out that it wasn't the part that was the problem. But thank you all, the pics and descriptions confirmed what I had thought should be the correct mode of operation. So I at least knew there was something else going on here.

@herbal space program Thanks, I think I got it figured out now. Your description was exactly what I had been doing with props and rotors, so it seemed very odd to me that I was not getting the same results. I think the problem I was having related to the way I use the KAL-1000 to map power curves for my engines. I had used radial attachment with my blades on the wrong (smaller side) of the rotary engines I was using. So I first redid the blade attachment with the nodes set to Octo and I forced-snapped them to the nodes this time. This mounted the blades in the correct location. After I did this, the blade deploy angles were still not functioning correctly. After tinkering with several different things, I finally deleted every reference from the KAL-1000 and then reassigned everything and finally it is behaving as I expected it would! So for me, the blades now function exactly the same as the rotor and propeller blades... so I'm happy and have to retract on my bug statement. However, I did not notice a need to set the blade pitch one notch off of flat. I'm using my throttle at 50% as the neutral or zero position and then forward and back is forward and reverse thrust respectively (based entirely on blade pitch). So I may not notice them being off slightly?

@herbal space program I must be doing something wrong then. I dont use symmetry when placing the engines, so what do you mean by “manually”?

@herbal space program if you wouldn't mind posting a link to your plane, I'd like to see if it changes my opinion at all.

No... I don't use symmetry. If anyone has a picture of a functioning counter-rotating ducted fan engine where both engines have the lift-vector stripes pointing in the same direction. Then I may have to concede I'm doing something wrong and will have to ask how they managed it. When I mount these new blades side-by-side with the standard propeller blades it becomes painfully obvious there is something not-quite-right about them to say the least.

You can never get a ducted fan to have the painted surface of the blades all facing in the same direction on counter-rotating engine designs. If it were done correctly, the painted stripes on the blades for both engines would face in the direction of the lift-vector. It works correctly for Rotors and Propellers, it's wrong on the ducted fan blades.

It appears the ducted fan blades are bugged when compared to the rotors and propeller blades. It becomes evident in multi-engine counter-rotating engine designs.

It can be very tricky building stock Mk3 spaceplane wings with the very limited parts available.

Seems like there is something wrong with the new turbofan blades. If you install a pair of the counter-rotating engines, the thrust vector on one side will point in the wrong direction. You end up having to do something screwy with inverting and you then have one set of blades optically facing in the wrong direction (painted stripes facing wrong way). Rotors and propellers work fine in this respect. Anyone posted a bug tracker item for this? (I looked but my keyword attempts came up empty.) Edit: After further review... the turbofan blades are fine. Rather, it was a problem with the KAL-1000 that was causing issues.