AccidentalDisassembly

Change the ride height to 100 and apply settings, then go slowly onto the water (if you're going from KSC, downhill slope makes you shoot into the water if you're going fast). Ride height is lower over water than over land, it seems. - - - Updated - - - I don't know anything about KSP programming, but I am guessing this would take much time and effort. So my reaction is a resounding "meh." One unusual behavior I notice - this may just be a property of how tracks work, and not a bug, I'm just curious: Let's say you have a vehicle with four medium tracks where wheels would usually be: Picture Mk2 cockpit, long fuselage behind it, medium tracks stuck on sides (kind of the bottom-side, rotated). When you come to a stop, you can turn in place, slowly. When you move forward without steering, no problem: accelerates fine up to 10.6m/s or whatever the top speed is (can that be tweaked by the end user? that would be neat. TURBO TRACKS! Is that what torqueCurve does?). However, in a certain range of very slow speeds while moving forward, turning one way or the other seems to lock things up and make motion of any kind much harder. When moving relatively fast forward, turning seems OK.\ Is this basically how a set of four tracks would work IRL? You can turn while stationary, but you can turn a lot easier if you've only got one track on each side; you can turn OK while moving relatively quickly (when you've got 4 of them total), but you can't do much at really slow speeds? Intuitively, seems like they might work that way - I mean, they aren't actually turning like wheels, just applying different torques or whatever, so that would seem to make sense: really hard to turn in place with a vehicle with four tracks, but maybe possible; hard to turn when going real slow. EDIT: Also, with respect to the GUI thing - the weird logic from my non-programmer perspective isn't that the icon would duplicate when you reload the database. That would actually make logical sense from a purely intuitive perspective, but it doesn't. Reloading the database is the trigger for it to then duplicate on every scene change. Oh, code!

Oddly, I am having a hard time reproducing it, but I think this will do it. I think that the fact I was twiddling with cfgs (node_attach values) and reloading the database is involved. Not positive. 1. Load KSP, new sandbox. 2. Make craft, repulsor parts on it, save. Launch or don't, either way. I don't think anything about the craft matters, and I'm not even sure you have to make a craft at all. 3. Space center -> Alt-F12, database, reload all. 4. Go to SPH, load craft, launch craft. Now there are 2 instances of the KF icon and every scene switch will create one more. 5. To verify, go back and forth between KSC and runway (or whatever). Going to see if I can replicate it WITHOUT the database reload. EDIT: Can reproduce reliably. Has nothing to do with craft or part types. Just load KSP, go to KSC, reload database, then scene switching will duplicate the button. Somewhat of a false alarm apparently, sorry!

There was definitely some reverting to launch involved... possibly a few explosions.

Well, my part-testing GameData directory just has CIT's nodehelper, BDAnimationsModule, CRP, FS, InterstellarFuelSwitch, KF, KJR, Klockheed Gimbal, and SmokeScreen in it, but I don't think it has to do with those at all. I remember Pilot Assistant having an icon-duplicating problem at some point that they somehow fixed...

Oops, one more: reverting, relaunching etc. duplicates the KF icon in the app launcher.

Only issue I notice is the unusual direction of node_attach stuff. Altering node_attach values should make it so that the tracks are right-side up from the start when placing them in the SPH. I think...

Very minor detail, don't know if it's worth it: latest ModuleManager is 2.6.7, one included is 2.6.6.

Is it... is it happening?? Looking forward to the next iteration!

With FAR at least, lowering masses like that was the only way of not having the CoM really far forward on normal-looking craftf - I kept having to put wings RIGHT behind cockpits to get things balanced, or adding non-canard wings to the cockpits themselves, just to pull the CoL up near the CoM! Happened for me with lots of parts though, yours aren't different in that respect. Not sure why it works out OK in Stock...

Just a suggestion regarding the parts, and just an opinion, so take it for what it's worth: the masses of the cockpits (especially the Reaper) are crazy for anyone using FAR. A patch could be included that changes them only when FAR is present, like this, though obviously you might have a different idea of what the masses should be: Just by way of comparison: the reaper drone pod weighs 2.5 tons. That's 5500ish pounds. An entire real MQ-9 Reaper, wings, fuselage, engines and all, weighs 4901 pounds (without fuel) according to good ol' Wikipedia. Not so much a problem in Stock, I guess, since stock parts also have insane weights for what they are. They seem fine and all, though sometimes silly-high cockpit weights (or engine weights, or whatever) make for some funny configurations to make the CoL anywhere close to the CoM. But in FAR it makes it impossible to get planes off the ground at anywhere near reasonable speeds even with gigantic wings.

With respect to contra-rotating props, I'd been fiddling with RetroFuture parts and there's one with contra-rotating props that DOES work. This is from its config re: the FSplanePropellerSpinner bits:

What about for other parts than that particular one? NO parts, or just not for that part?

Love the engines, seems like a good idea. To add to wasml's comments: 1. Fix for Tethys: node_attach = 0.0, 0.36426, 0.0, 0.0, 1.0, 0.0, 0 2. For the VC10 and VC8, the smoke trail effect could be speed = 1.0 1.0 without much degradation I think. Had 4 engines going, was laggy with smoke as is, maybe just me. 3. The VC5's flame effect seems (subjectively) kind of far from the nozzle, could be set to localPosition = 0, 0, 0, or localPosition = 0, 0, -0.1 4. VC10's flame can be set localPosition = 0, 0, 0 as well if your preference is the same as mine. The VC10's nodes are better as size 2 I think, but I guess the 3.75 top node could be size 3 too: node_stack_top1 = 0.0, 0.05032, 0.0, 0.0, 1.0, 0.0, 2 node_stack_top2 = 0.0, 0.52256, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom1 = 0.0, -3.55378, 0.0, 0.0, -1.0, 0.0, 2 node_stack_bottom2 = 0.0, -4.46285, 0.0, 0.0, -1.0, 0.0, 2 The Catalyst's nodes should be: node_stack_top = 0.0, 0.10819, 0.0, 0.0, 1.0, 0.0, 3 node_stack_bottom = 0.0, -1.24048, 0.0, 0.0, -1.0, 0.0, 3 (IMO) An odd note: Staging the VC-10 on the launchpad ejects the cowling thing... strange. EDIT: Changing them to isFairing = True seems to stop that. Very cool work you're doing! ONE MORE EDIT: Here's a TweakScale config you can include if you're interested: https://dl.dropboxusercontent.com/u/59567837/VanguardAstrodynamics_TweakScale.cfg I chose the smaller of the two sizes for the multi-attach engines as the basis for the scaleFactor, so that's arbitrary.

Well at least I think I now finally understand why planes aren't behaving like I would expect under FAR! hah. An entire Cessna Skyhawk weighs a bit more than a KSP cockpit: http://cessna.txtav.com/en/single-engine/skyhawk (~1100kg loaded, says the website).

All right, I imagined there was some value in a config somewhere for atmosphere density. I see now that FAR quadrupled the mass of the innermost wing parts I attached to my latest craft, reducing that slider helps quite a bit. The added mass of all of the wing parts represented a 50% increase in the weight of the craft compared to the normal mass values (4 tons to 5.8 tons). EDIT: What you say makes me wonder about the mass of stock parts. Would a 1.25m inline cockpit really weigh 1,030kg? Maybe that's part of my problem as well. Not that it was the same diameter (and definitely not pressurized), but come to think of it I'm not actually sure that my dad's entire sailplane weighed 1000kg.

Ferram, what variables would I need to tweak to create some kind of balance between FAR and stock - like 25% of the way in between FAR's atmosphere and stock's? I feel like my planes barely decelerate flying level at 100m/s at sea level and don't make much lift off of relatively large/long wings =( EDIT: Maybe it also has to do with the radically increased wing mass under FAR...?

All you have to do is start up KSP, do the things in question (make a ship with a piston, launch it, see what happens, try things out, make it break), then close KSP. Look in your KSP_Win directory for a folder called "KSP_Data". In there, you'll find "output_log.txt" - this is your log, and it's always created every time you play, no need to do anything yourself. Use Dropbox or Pastebin or something like that to make it available.

Nils, would you mind telling me a little about your textures? I have been re-sizing textures in various mods in order to reduce RAM footprint, but certain textures don't respond well when I do. Specifically the textures on the gangways, for instance - what exact parameters are you using to create those? Is there alpha involved - and if so, how do you go about making effective alpha stuff on textures? EDIT: And the normal maps, too! I just can't figure out how to re-size DDS normal maps without completely borking them. =(

That might be true for engines, what with "#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }" (whatever that does), but it's not true for most parts (like fuel tanks) - from the ScaleExponents.cfg: Unless I have a funky ScaleExponents, that is... Do I have a funky ScaleExponents.cfg...?

The weight (or thrust, or solar output, or whatever else) you get from scaling a part is defined in the ScaleExponents config in the TweakScale folder. They work like so: Weight: exponent is 3 (mass = 3 in that cfg, so everything scales with volume). Scale a part to 2x size: new weight is (2^3 * the original weight). Solar output: exponent is 2 (scales with area). Scale a part to 9x size: new solar output is (9^2 * the original power output).

I've also got the issue with the heavy RCS blister. Nertea, is yours the same as ours? Is its node_attach = 0.45212, -0.0105571, -0.0059382, 1.0, 0.0, 0.0?

I have to second this. I've never had CKAN do anything except wreck my GameData directory and succeed in not telling me at all whether any of my mods are out of date. Sorry CKAN =(

Something to think about for the textures - I don't *think* KSP has any particular problem with textures that aren't powers of 2 on a side, so some textures that don't really need to be 1024 could be 768x768 instead: 25% reduction in linear resolution for 50% reduction in RAM.

Is anyone else experiencing a ridiculous drop in framerate when attempting to adjust the gears in the VAB? Happens when the "Toggle adjustment" menu is open. Wondering if it's a mod conflict of some kind or if ALG itself is doing it...

Just a heads up for anyone with Bahamut's adjustable landing gear - the BDAnimationsModule in this will wreck adjustable landing gear if you've got the BDAnimationsModule from that installed. They're apparently very different... The one in the Mk4 DL is 15KB, other is 80KB.