MisterFister

I notice from the pictures, especially the animated .gif, that your g-indicator seems settled around ~.65g. For the animated tumble-rat display, any properly-modeled acceleration force producing that kind of attitudinal oscillation would produce a corresponding oscillation in the g-meter. This, at the very least, might establish that this is some sub-species of kraken. I'm mostly-sure that you understood what I and others were getting at with root part references, but just for the sake of being thorough, I'll clarify: we're speaking of the actual root part as defined specifically and exclusively within the VAB / SPH scene. This is not the same thing as the control-from-here part active during the flight scene. Hypothesis: redefining a mid-stack root part, perhaps a fuel tank, might change (or relocate, or even multiply) the bend-points. I concur with previous highlights of this. Deleting mod-part-occurrences within the career save is in no way the same thing as uninstalling the mod. This is all the more true for a mod like Kethane which, save possibly for derivatives of RSS or FAR, is quite frankly one of, if not the single most "meddlesome" mod out there, in terms of how much the behind-the-scenes behavior is concerned. One possible troubleshooting option is to leave the kethane part folders alone, but delete / hide kethane.dll and modulemanager. This would likely generate kethane-related errors. Hypothesis 1: this "half uninstall", while likely to be game-breaking on its own, might not even affect this kraken. Hypothesis 2: Uninstalling the kethane plugin might change kraken emergence parameters (when it occurs, at what SOI locations it occurs, precipitating / trigger events) without necessarily changing the kraken behavior once it finally does become triggered. Also, regarding mods: When it comes to plugins (dll) then it doesn't matter if your ship is stock or modded. If the dll is running then it's possible for it to cause problems. (depends on the mod. YMMV). It's not correct thinking that if your ship had all stock parts that it is guaranteed to be a stock KSP issue. The only way to ensure that is to run KSP without any mods installed at all. Thirdly, KSP does not report compatibility issues with mods. EVER. It's not KSP / 0.90 that reported the incompatibility. That was the mod itself. Sorry, I'm not trying to give you a hard time, but three pages, no log files and the whole thing rife with speculation and a few misconceptions. Posting the logs in their entirety will allow those of us accustomed to troubleshooting KSP get a better handle on your problem. The logs tell us everything. What's installed, whether it loaded properly, what errors are being thrown and when and from what functions. This might provide some corroboration to Mr. Starwaster's comments above. Often, especially with deep-seated kraken such as this one, error occurrences at the end can correlate to things WAY elsewhere in the log output. If for no other reason than the extreme difficulty in replicating this bug, I join the above request that troubleshooters experiencing this slinky-kraken provide large, wholesale dumps of entire log files -- FOR SCIENCE! If it's hundreds of megs, no problem, as things like google drive and dropbox have free trials that come with at least a gigabyte of initial space. (Dropbox offers special incentives to people signing up who use a .edu email address.)

I didn't mean to imply that this bug wouldn't occur in stock. Simply, this OP seems to be fortunate (?... odd word, I know) to have a somewhat reliable ability to replicate this, since I think he took screenies of the problem AFTER I asked about them. I say, gather as much hard data and full log traces from him while we can to contribute to this effort.

Other thoughts: does camera orientation, camera mode (free / chase / etc.) or camera mod (enhanced chase cam) influence this behavior at all? Craft orientation? Staging distribution / behavior? Part module classes (especially if root part reassignment is a factor)? Time warp activity while on the Launchpad? You already suggest that the problem tends to go away for a while following KSP restarts. I wonder if there's some kind of silent error being thrown, or nulref, that "accumulates" and clogs a buffer of some kind. What about aerodynamic model (stock / FAR / NEAR -- yes I know the problem is after you leave atmo, but the presence of a physics-changing mod like FAR / NEAR might generate a bug like this, idk.) What about Kessler properties, do you have a crowded LKO or otherwise highly populated persistence file? What about RemoteTech -- I know RT2 had some issues for Bob Fitch in his Project Odyssey series on YouTube that related to root parts affecting whether engines fired, and Scot Manley early in Interstellar Quest had spontaneous craft explosions in a version of RT2. What about launch ascent profiles? Do polar orbit launches produce the same issue (physics modeling of the craft with respect to the rotation modeling of the planet surface)? Do you run EVE, BA, or ATM? What about Modular Fuels / Modular Tanks, or any mod that relies on the RSS .dll files (which are surprisingly legion)? You suggested sending up a test launch of a stock-only vehicle. What about a stock-only launch? Maybe it's an environmental bug moreso than one introduced (or triggered) by any given part or part-mod?

For further experimentation, I wonder how the root part assignment influences this bug's behavior. Is it the root part that "remains" and the rest of the craft is what "bends"? Try redefining the root part (possible before with a mod, now a stock behavior) and see if the origin of the bending behavior moves to follow the root part. - - - Updated - - - Also, perhaps a log output, even though it might not crash or generate an "error" dump.

F9 rescue sounds like a good workaround, but I've read elsewhere on the forums that this too can sometimes fail to address the issue. Perhaps a .craft and a screenie? (I've yet to encounter this problem without the klaw, I think.) I wonder, are you in atmosphere before engaging time warp to apo? I doubt you would be, but if so, you're not in true time-x, you're in phys-x, which carries a whole host of other issues.

See, what you call "bloat" other kerbonauts (myself included, incidentally) call "awesome." :shrug: I'unno. Once you complete a few quests in WoW, you will eventually run into a "then what?" moment. That's what end-game content is all about. My own personal speculation is that destructible (and upgradeable) KSC buildings suggests that we'll eventually get multiple launch sites, each with pros and cons (launch altitudes, longitudes, latitudes, perhaps the possibility for a decent weather mod, etc.) Not only that, if you're restricted by low-level upgradeable buildings, what holds you to that restriction? Knowledge that you can make it go boom if you try to land something overweight on the runway without first upgrading it. Or whatever. I'll have to see how it unfolds. Beyond that, from my own perspective, you're arguing with the wind. Sorry dude.

For those curious -- the OP on this thread is indeed running a 32-bit system, with 3GB of ram (4GB system memory minus 1GB shared video memory.)

Idk about a wording that is quite so stark, but honestly, this is a statement worth Squad's consideration, yes. Windows 7 was released in the summer of 2009, which is now exactly five and a half years ago, and hasn't been available pre-installed on a new computer since approximately the release date of Windows 8, which was August of 2012 -- itself two and a half years ago. Operating systems are only designed for shelf lives on the order of 4-9 years, and in any event, it has been superseded by Windows 8 / 8.1 and the tentatively planned launch and deployment of Windows 10 (successor to Windows 8.1) within the next twelve months. Alternatively, all games have minimum hardware and software specifications to run, and always have. From Sierra's Quest for Glory back in the late 1980s, through Imperium Galactica in the 1990s, through titles such as World of Warcraft yesterdecade, Crysis more recently, and most any title available for release on Steam. (Yes, the older the game, the lower those requirements tend to be, but nevertheless, they all have requirements.) KSP will have its own requirements, whatever those turn out to be. To base one's own expectations, as a customer, as to what those requirements might be, based on how an earlier-alpha version of the game performed, when that game was wildly and properly advertised and disclaimed to be in-progress (indeed, to Squad's credit, KSP is the pinnacle of Early Access they way it SHOULD be run)... seems to me to be poor judgment. Circling back to your original question, which you may have thought was rhetorical; 17% seems to me like a reasonable margin of exclusion. Every title I mentioned above, and fifteen hundred others, were forced to exclude some customers at launch release due to those customers not yet meeting hardware requirements. Hardware and software sales often leapfrog each other for just that reason. Indeed, if [your conception of] KSP WERE to cater conservatively to lower-end 32-bit systems, beholden to customers like yourself limited to three gigs of RAM (yes, you have three gigs of RAM to work with on your system according to the info you've posted) there'd be other buyers excluded because the options were not cutting-edge enough. Listen, I've followed your comments. One of your more legitimate gripes is that there are items that Squad is not addressing -- you specifically mentioned aerodynamics and the infiniglide issue (I agree that the stock aerodynamics are crap and cannot fathom having fun in this game without FAR -- I gather you to be a NEAR-user, which is also fine, I think.) Yet you call "silly" (...quote below) ... calls for improvement to the game that you do not happen to advocate for. Essentially, I paraphrase your statements thus far to suggest that you think earlier versions of KSP to have been perfect on their own, with mods, except for the aerodynamics. Which is fine, but... that's primordial KSP. It's pre-KSP. It's alpha KSP. It's progressing beyond that. Again, I'm not offering the patronizing platitude of, "Oh, it's in alpha, there there, here have a tissue," in fact I think I'm saying the exact opposite: there's a plan for KSP 1.0, and as far as my paraphrase of your sentiments so far, against the apparent trajectory of KSP development, that plan is not one you agree with. That's unfortunate.

Incidentally, note that which I highlighted here. This figure implies that you have 4GB of ram on your entire system. (First of all, if you're running a laptop, you should know that some models "cheat" by affording their video RAM from the shared system RAM.) Bear in mind that, ok, KSP is running a butt-ton of RAM, but other programs needs to run too. Like Windows, and all the modules that Windows needs in order to run. Drivers and whatnots.

+1 ^__^ rep added

Respectfully: This is not a "ship," with a "captain." This is a for-profit playspace, designed ultimately at the pleasure and whim of the designer, with feedback from users, not "input," as your tone seems to imply you want. I mean, if you don't like one set of monkey bars, you hop off and look for another set that suits your fancy, no? I mean, Minecraft is very mod-friendly (and 64-bit compatible, I think.) Lookit, I [thread=76549]feel[/thread] [thread=94259]your[/thread] [thread=100387]pain[/thread], I [thread=94086]really[/thread] [thread=96043]do[/thread]. I think we've identified your problem. At any rate, I for one WOULD like to help you with this problem. Yes, I know that you think you're not asking. I'm offering. My links above, if anything, establish that I'm willing to try, and reasonably capable to get you SOME progress. This is not an error log. Period, it's not. I'm not flaming you, I'm pointing out to you that your info posted above is just as useful for identifying a crash issue with KSP as it would be for me to say, "My car broke down, here's a photo I took of the smoke coming out from my engine compartment." To diagnose my car, the mechanic needs to hook their doohicker up to the electronic port in the dashboard and look at the error codes. The error log for KSP does the same thing. This is extremely wrong. Like, mind bogglingly inaccurate. You're not stupid, as no one was "born" knowing this stuff, but you're not coherently framing your issue. Again, I volunteer to help. Either here or in PM.

I'll try this.

http://forum.kerbalspaceprogram.com/threads/38768-0-24-Editor-Extensions-v1-3-19-Jul-2014-(EdTools-Editor-Tools-replacement)

Ladies and gentlemen, I think I've almost got my Linux house in order [i hope]. My last piece of the puzzle -- vidcap software. Fraps won't work in Linux, or anywhere else outside of Windows for that matter. Any suggestions? Preferably software that generates .avi output files, though exact codec / format is negotiable. IDEAL is something free or low cost, though I'll consider paying, especially if a trial version works out on a few test runs. Better yet is something that can record multiple independent audio streams, so I can divorce live voiceover audio from in-game audio. Any thoughts or suggestions? I've googled the question and being peculiarly new to Linux, and my YouTube experience so far as been as a contributor to others' channels [meaning the actual recording has always been done either in Windows, or on someone else's machine entirely] I'm not exactly sure what I'm looking at.

Ladies and germs, I've decided that 3.6GB of ram is not enough to satisfy me. So, I've gone through the trouble to reformat and partition my hard drive so as to allow a dual boot configuration with Linux, since the 64-bit version of KSP is quite stable in Linux. However, Fraps, the vidcap software I've tinkered with in Windows, doesn't work outside of Windows. So, to Linux-based YouTubers out there, what do you use for vidcap software? (Preferably software that generates .avi output files, though exact codec / format is negotiable. IDEAL is something free or low cost, though I'll consider paying, especially if a trial version works out on a few test runs. Better yet is something that can record multiple independent audio streams, so I can divorce live voiceover audio from in-game audio. Any thoughts or suggestions? I've googled the question and being peculiarly new to Linux, and my YouTube experience so far as been as a contributor to others' channels [meaning the actual recording has always been done either in Windows, or on someone else's machine entirely] I'm not exactly sure what I'm looking at.

I for one also prefer roman numerals to Mk.-series notations. That said, alphabetizing schemes work better with arabic ordinations. Mk. 1, Mk. 2, Mk 3, etc., will all be listed "in order," whereas roman numerals are treated as actual "words" for ordering purposes in most meaningful environments (such as sorting through subfolders in your GameData folder, or sorting through parts in the SPH / VAB.)

Is that from an existing mod, or are they being created anew for 0.90?

This mod looks awesome, and it's an insta-download. The RPM integration looks spot on, from what I can see prior to unzipping and using it. However, I note something curious in the OP by the mod-author. Someone making [awesome] spaceplane parts, who uses the stock aerodynamics system that turns KSP atmosphere into digital mayonnaise. I'm not making fun, I think it's just noteworthy, kinda like Mozart composing operas and symphonies after going deaf. That this mod is as beautiful, and obviously popular, is a testament to the author's skill. That said, just as I would ask Mozart questions relating to how such a feat could be accomplished, I would like to ask here: why the seeming aversion to FAR? I ask not out of partisan debate, but again, genuine curiosity.

My understanding is that vehicle launch weight is already the primary factor. Heat production I can imagine being essentially scaled with vehicle launch weight. As for force exerted on the pad at ignition -- could you be suggesting that a lower TWR (or initial throttle setting until the launch clamps are cleared) would be rewarded with a slightly reduced pad recondition time when compared against just full throttle blasting off with a TWR of >1.5? Intriguing. My follow-up question would be -- does that mean that you can launch with radially mounted SRBs, angled slightly outward? Inefficient as most of your thrust vectoring would be angled outward instead of against gravity, but it reduces Launchpad stresses until the SRBs can be jettisoned by radial decouplers.

I managed to find an old archived version of the converter utility in my backups and forgot to post here with the update.

Do a screengrab, post the file to imgur.com or somesuch, and slap the link here. Also, welcome!

Well... yeah... but please read the first half of the sentence you highlighted. I apologize for not being clearer with my request for help. I am not installing the files to be used within Windows x64. I am physically moving and copying and placing my files on my hard drive from within Windows x64. I have no intent to run any of these mods until after I shut down my system and move over to my Linux install. This was a file decompression error, possibly due to a minorly corrupted filepack on the server end, who knows. I was able to work around the problem by downloading the zipfile from a separate source.

Kerbals and Kerbonauts, I am revisiting this thread because I want to continue experimenting with this idea in Linux x64. However, the XnView conversion utility seems to have undergone an update since v0.24.2 and the last somewhat-playable Win64 build. I'm just wondering if anyone else has any insight as to how to go about converting lots of .tga files to .png across a sprawling GameData that by itself weighs in around 2.2Gb with exactly 133 individual first-level folders, not counting the per-mod subfolders?

Should I manually rename the folder to eliminate the version number? Will it work as is?

Heads up to the author of this [totally awesome] mod: Has anyone else run into this problem? I'm installing v2.6d2 for my new career in KSP v0.25. The install is intended to run on Linux x64, but I am performing the downloads and mod installs in Windows 7 x64. The decompress process (whether I Extract All in place, copy and paste out of it, or any other method) generates Error 0x80004005 for file KW2mengineSPS8bit.mbm, and I am forced to Skip this file. A google search yields this mod's github, and suggests to me that this file is supposed to reside in the KWRocketry\Parts\Engines\2mSPS folder, and I can confirm that this file is indeed situated where it's supposed to be within the downloaded zipfile from KStuff. There was no workaround that worked, even after re-downloading the file. However, I was able to use the Mega alternate download, and that one decompressed without a problem. (I'm aware of the correct install procedure, and how the filename includes the explicit advice not to simply extract the zipfile.) Might wanna check the file on KStuff to see if it's been corrupted somehow. Otherwise, thanks for the great mod!