Starwaster

You already asked that on this very page.... do you have short term memory loss? Use the arrow keys in that field to move to where you want to put a digit. It's not really that hard to do.

RSS because that's where I'm doing my primary development of these parts. A non-RSS rescale will be available when I release but currently it's scaled around a 10 meter diameter scale. (!)

Entering numbers into that field can be a bit tricky, but honestly, it's not THAT hard. It's not 'ten minutes' hard. Or at least it shouldn't be. If you need a value smaller than 1 when the current value is 1 or higher, then try this: click in that field and press the home key to move the cursor to the beginning. Then press . to put a decimal in front. Then type the numbers you want and press delete to remove any numbers to the right of the cursor.

Docking port parts have the module ModuleDockingNode, which has several properties that you could track. Look at docked craft in your save file so you can see the changes that happen when they dock. Two properties in particular that I notice changing are: state dockUId state has 4 values that I've seen. Ready, PreAttached, Docked (dockee) and Docked (docker). The last two should be self explanatory; those values are set when the the port gets docked to another port. One of those two will be the docker and the other the dockee. As nearly as I can tell, at that time, dockUId is set to the uid of the part to which it is docked. However, dockUId is not reset to 0 when the the craft undock. (so by itself, dockUId means nothing. If state = Docked * then it's the part id that you're docked to but if state = Ready then it just means that you were docked to that part at some point in time) PreAttached AFAIK is set if the craft is spawned from the VAB with two ports already docked to each other. dockUId is set to 0 in that case. I'm not sure for your purposes that you need to deal with PreAttached ports at all, but assuming you do then you would look at what's attached to the port part's nodes. (top node by default but that's not engraved in stone)

Make sure not to put the ladder collider too deep. Still playing around with exact values but at the very least make sure the center is outside of whatever you're putting it on.

Does the status line (moving foward, backing up, moving to docking axis, etc) say that it is moving at 0.0 m/s? If so, turn off the option to conserve RCS fuel, or change the threshold number to something lower. If you don't see those options then use the custom window editor to add them to an existing window or make a new window that has them.

I've been thinking for a few days that it should be possible for a Kerbal to grab onto the truss and climb it on EVA....

Sea level thrust correction is built into the plugin. Thrust on the pad will always be smaller for Real Fuels. If you have another thrust corrector plugin you should remove it when using RF. Clarification: Rehash for any readers unware: Stock thrust behavior is to increase fuel mass flow based on current Isp which varies according to atmospheric pressure. (Isp is lower at sea level and reaches its max value in vacuum) Correct (real life) behavior is that thrust is reduced whereas fuel flow generally remains constant unless the engine is throttled. Real Fuels keeps mass flow constant and reduces thrust when in atmospheric pressure conditions.

I found out about that when I was looking at the ModuleDockingNode definition in Visual Studios. You can learn a lot that way though it's not always apparent what some things do. There's another parameter for the actual docking node which as near as I can tell lets you reference a transform that is named something other than 'dockingNode'. I was unable to get that one to work but I did use the controlTransformName to tell my drop tank part that its control transform is different than its forward (up? I forget actually) transform. For instance, it's oriented one way but its docking node is oriented 90 degrees off axis so its was necessary to add a second transform and set controlTransformName to that transform name. That apparently affects everything queries the part about its transforms because prior to doing that, MechJeb would not properly dock, and would give a status message saying that I needed to control from an actual docking node.. (or something to that effect)

Sorry but it's going to be quite a bit longer than 'hours'. I can't commit to a specific time period (needless to say) but hopefully not too long. But, this is what I'm thinking of doing. An initial pack release of: 2x saddle trusses (1 x full length + 1 half length) 1x Ring Adapter to fit fuel tanks. This part has built-in battery power and is a command part. Has an attachment point for docking rings. 1x drop tank scaled to fit the full length truss. (both fuel tank and truss will have built-in docking port so you could refit a tank to the truss. specifics TBD but likely left up to the individual as to how or if they do that) 1x male docking ring 1x female docking ring 1x hab adapter to fit either end of either trusses. The adapter would take the place of a docking ring and provide two attachment points. One outside the truss (i.e. an inflatable hab) and the other inside the truss. (for logistics or as a docking garage) A set of optional config files for ModuleManager to tweak other parts that might be useful with the truss. The pack would come in at least two flavors, one scaled more or less to stock and the other scaled to Real Solar System. (this would offer a config that rescales the hab. This is what you see in the screenshots I've posted. The hab is double sized) The hab adapter will also have 4 attachment surfaces for solar panels if desired. Progress: All meshes for the above are done. Some need some fixing up, like bad polygons need fixing and UV maps for some need reworking because I really did not know what I was doing with the UV maps when I started. Especially the docking rings, which I want to do some minor tweaking of the model and some texturing of. Fuel tank needs a collision mesh.

Launch them empty you mean? And then... what, fuel them in orbit?

If I had time I'd go into the actual formula, which involves square roots and not squares.... to determine exhaust velocity which is where you get Isp from. The bottom line is that all other factors being equal, your Isp will always be lower for an exhaust with high molecular weight compared to one with low molecular weight. Always. Increasing mass could increase thrust if you're talking about mass flow, but just increasing the density of the propellant will lower Isp. If you want you can increase chamber temperature until your propellant completely disassociates into its atomic components which would help but none of that applies to the rocket motor being discussed which is derived from researched technology whose abilities and limitations is very well known.

It's not that I missed the point. There is no way possible that the resource LiquidFuel would give a high Isp. To be at all realistic LiquidFuel needs replacing with a propellant that is much less dense and requires a higher volume tank to contain the equivalent mass. Isp is derived from exhaust velocity which in turn is derived from exhaust molecular mass. That's why H2 gives a high Isp by itself. There's nothing realistic about the situation and it can't be made realistic just by slapping a RAPIER mode in there and swapping out thrust / Isp. Assuming that the relevant module can provide that functionality. I haven't looked at it but I'll assume since you brought it up that it is possible. It changes nothing It's just swapping one magic engine for another. For those who use Real Fuels btw realistic NTR engines are available. Not everyone likes the realism involved but that's another can of worms entirely.

Thrusters only while in spacedock?

I just tried to rotate it on my screen. Needless to say, it didn't work.

There are three problems with that assumption. Pick two. Propellant density. Specific impulse rating Thrust level. The stock LV-N has 60 kN of thrust, 800 Isp and 5kg per volume unit for both fuel and oxidizer (0.005 tons per volume unit). I'll leave aside the argument as to what the volume unit is but simply put that cannot possibly match the stats of a LANTR which uses liquid hydrogen + liquid oxygen as its propellants. The problem here is that liquid hydrogen in a typical NTR has an Isp of 850-910. Somewhat higher Isp is possible. Thrust of 60 kN is on the low end for a smaller NTR but within range if we're only talking about hydrogen as the propellant In a LANTR, liquid oxygen is injected into the nozzle into the supersonic exhaust stream right after it exits the throat. This has the effect of lowering Isp and raising thrust. The exact amounts depends on ratio of LOX/H2. Ratios of 1.0 to 7.0 have been calculated which drops Isp to the low 700s for a ratio of 1.0 (LOX to H2 by mass, not by volume) and into the low 500s up to a ratio of 7.0. Thrust would be increased into the mid to high 500s. The numbers just aren't even really close to convince me that the LVN is actually operating in LANTR mode. Isp is too high and thrust is too low. (Edit: and propellant is too dense. Low density exhaust = higher Isp. Higher density exhaust = lower Isp. Thrust tends to be higher for high density propellant because it's based on exhaust velocity x mass flow) This page here has some decent information the data table has been floating around for years in various proposals for NTR usage. http://www.nss.org/settlement/moon/LANTR.html

Says you! I am totally going to make a parachute material that models fishnet leggings so my Kerbals can parachute back to KSP in style.

OH! That's that inflata-base thing that... someone... requested early on! Awesome-sauce. ... Was that punintended?

For #1 isn't it sufficient that you can already initiate burns that set apoapsis / periapsis to arbitrary altitudes? If you don't like where the maneuver node is then drag it around on the map until your ap/pe is where you want. Or use the node editor. Some variation #2 & #3 is under consideration as the subject has had recent discussion. You're late to the party.

Actually might not be glued down... or at least not to the tank itself. They'd likely have spacers to keep as much of it out of contact with the tank as possible. Or, maybe not since they would be planning on active refrigeration for ZBO. I dunno. One thing I'm finding is that the ones that look nice in Unity's editor don't always look so nice in KSP. So I need to get each one in there and give it some 1 on 1 time with Jeb on EVA. (ultimately, you have to understand that the final decision is in Jeb's hands, not yours or mine)

If you have ModuleManager installed you can also do this: careerModeMissingParts.cfg @PART[*]:HAS[#module[Part],~TechRequired[]]:Final { TechRequired = start //TechRequired = advRocketry entryCost = 1000 } Make a file with the name specified above or name it whatever you like as long as it ends with .cfg, edit it as a text file (I use Notepad++ in Windows) and paste the above code into it. As written above it will place ALL missing parts into the start node on the tech tree. Notice I commented out the line that would have put it further down in advRocketry. You can easily comment out one and uncomment the other so parts unlock later. Other more robust configuration files are possible, such as putting all missing command modules under one of the control nodes or science parts under the science nodes or engines under one of the propulsion nodes. Etc etc.

I have an idea about that actually.... use a conical stretchy tank. They're fairly adjustable as to shape style. Make sure they're empty so they don't add too much mass. (or not, if you want the added fuel capacity). Which AFAIK, the shape is properly recognized by FAR if you use that so you get the aerodynamic benefits.

No doubt the patients ARE never ending... let's hope the patience holds out.

LOL gotta love Peter Stormare!

Doesn't the eyeball inspection also involve sledgehammers?