NathanKell

Here's a more universal solution: @PART[*]:HAS[@MODULE[FSwheel],!MODULE[FSwheelAlignment]]:Final { MODULE { name = FSwheelAlignment } } @PART[*]:HAS[@MODULE[ModuleLandingGear],!MODULE[FSwheelAlignment]]:Final { MODULE { name = FSwheelAlignment } }

Seems like you'd need to do a lot of branching in the shader code then? Might be better off writing your own implementation of PQSLandControl, also then you could control scatter.

Also you might consider adding verniers (like the LR-101) and turning off your main engine(s) gimbal(s) and flying on vernier gimbal alone once you get light.

Bothersome: Actually, I'd ask HoneyFox to update the "lite" version of TweakableGimbal to .24 if s/he hasn't already; that will do exactly what you want (allow tweaking gimbal range from 0 to max gimbal range)

The license means anyone can repost it if they have it. You just can't release *derivative* works without permission.

Cool! Click "Edit post" on your first post, then "Go Advanced" instead of "Save."

Rollins: Can you post the exact versions of all mods you have installed? Then: cause the problem. Quit KSP (if it hasn't crashed). Upload your entire output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log CSVoltage: doesn't this occur without RF? It sounds like stock behavior. RF doesn't touch jets or IntakeAir (other than to change its density so you need a bit more of it). Add more intakes?

It's not luck per se. It's also that win x64 has some serious memory-related and exception-handling-related issues. We can get it to crash on demand (when 32bit will be fine under the same circumstances).

Honestly it'd be great if you split it up into lots of parts. Main reentry module + parachute part + docking ring at top + antenna + RCS +....

thrust / ISP / 9.82 (KSP uses that as g0, not 9.80665...) = fuel consumption in tons/sec (requestedmass) that is apportioned as follows: compute the mass ratio of the propellents as: totalmass = propellant_1.density * propellant_1.ratio + propellant_2.density * propellant_2.mass +.... then find multiplier as requestedmass / totalmass then for each propellant remove multiplier * propellant.ratio / (sum_of_all_ratios) units The key step you're missing is the conversion between fuel flow (in tons/sec) and propellant units, and to convert you need to look at the resources' densities and at the ratios in the ModuleEngine.PROPELLANT nodes.

SQUAD makes a definite choice to put most of their art team working on cinematics rather than adding content.

Diomedea is a moderator (as am I--we have green or blue names). The links were pulled because the files are not in compliance with the new download rules (they lacked licenses in the packages as well as in the OP). I'm sure Lack will reupload compliant versions very shortly though.

edemlama: KSP Windows x64 is very unstable, and for most people with modded installs causes more harm than good. If you're one of the lucky ones, great, but I wouldn't recommend recommending it.

You need to add it to every root node you want affected, i.e. if there are six @PART[blah]:stuff, you need to add it to each one of them.

Right now I really, really don't recommend using a mod manager. They cause more harm than good; a number of install issues dealt with in this thread are due to mod managers messing up installs...

On KSP-Windows, *nothing* is "good and stable" for KSP Windows x64, because KPS *itself* isn't good and stable. It's an unstable release, as SQUAD told us it would be; if you want stable x64, use the Linux KSP x64.

Then apply a bit each FixedUpdate? I guess you should create a floatcurve that relates time-since-explosion to force-multiplier; then track the time since the last explosion, and AddForce(force * curve.Evaluate(timeSinceExplosion)) in each FixedUpdate.

KSP Windows x64 is not a stable release. SQUAD warned us this might be the case, and boy is it true. If you want working 64bit, use the linux version.

Not that high poly counts matter all that much these days (alas, unless you're ferram and are basically the only person KSP is GPU, not CPU-limited for...)

Intriguing! It's like Kliper and DynaSoar had a kid.

Dr. Death, what do you mean by "modmanager tells me"? Module Manager (I assume that's what you mean?) will tell you on the loading screen the number of patches it's applied, and the number of patches it's excluded due to unment NEEDS.... Please give the *versions* of all mods you have installed, and please upload to dropbox your output_log.txt (or player.log): Cause the problem. Quit KSP (if it hasn't crashed). Upload your entire output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log Renegade: While I already wrote an MM patch for AJE that will make it work where RF is not present, camlost is indeed (per NEAR thread) working on exactly that (BJE/SJE, a drop-in, no-tweaking necessary, always-works mod to stock jet behavior).

It's in the latest RO. asmi gave me permission to use his module that does that (for BobCat's Soyuz); I tweaked it slightly.

Part center of mass? That's how it is now, in Stock and in FAR (with the effect I described). If you apply drag at vessel center of mass, then every vessel will have no stability at all--they will continue to point in whatever direction they are currently pointed in, no matter which way "the wind is coming from." Flying will be...kinda tough, if the plane doesn't try to head into the wind at all...

Starwaster: do you have a current version floating around? I have your source from way back, and was going to edit it so we could use it for RO so it could work automatically: read the specified node size onload, store it, and set size 0 if in editor, regular elsewhere.

It's really, really not. Hard to use, at any rate. Sure, you give up KSP's jets being magical (in terms of thrust and in terms of low fuel usage), but you can still very easily make SSTOs because Kerbin's so small. Also, intake spam is prevented. And it's very satisfying indeed making aircraft that would actually fly...