MisterFister

Have there been any thoughts to hosting this mod on KerbalStuff?

Dude, this is absolutely, without a doubt, one of the mods I categorically refuse to play without. How can anyone hope to assemble a correct-looking space station without the rotation indicator on your mod? NavBall alightment indicators don't provide anywhere near the precision needed to cater to my OCD tendencies. Speaking of OCD, any thoughts on perhaps hosting this plugin on KerbalStuff? I think that's vastly a better repository for the end-user, especially with update tracking. And thanks for the great mod!

Any plans to host this on KerbalStuff? (Same for Universal Storage, I saw the dummy file there directing me to your site, and truthfully that makes sense because of the mix-and-match part packs. What are the pros and cons, to you the modmaker, for hosting the entirety of the US / 64K mods on KerbalStuff, with deletable sub-folders?) Otherwise, awesomesauce on both mods!

This mod looks promising, but the KerbalStuff feature page is devoid of any flavor text, explanations, pictures, license disclosures, or links to this forum thread. As a result of the last item, at least, I think you're losing out on much-deserved exposure, because like I said, this mod seems awesome. I'll be downloading it shortly!

Don't get discouraged too easily. I plan to run some extensive testing with this nifty little utility. I'll load KSP stock-only, and record the baseline footprint. Then I'll load my first mod, record the size, and calculate the footprint difference from baseline. Then I'll uninstall that first mod, and individually install a second mod, record the size, and calculate the footprint difference from baseline. Then I'll reinstall the first mod alongside the second, record that size, and see if the resulting footprint corresponds to those two mod's footprint differences combined. If they match up, I'll consider the process proved. Note, however, that plugin-heavy or plugin-only (mods light on parts) tend to have very "bursty" or variable memory consumption, and typically idle at levels much lower than during flight. Malah, do you have any ideas how to track this in-game? Otherwise, thanks for a truly utility! It purports to fill a VERY longstanding need.

*sigh* These reports mean absolutely nothing. You could be throwing silent errors and NREs. Please provide your entire error log (not just portions of it) to the mod author so that they can identify if your install of this mod really is actually working properly. (A car engine can have serious issues, but the vehicle runs smoothly on the highway.) See http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-(READ-FIRST). Oh my goodness what he said! [big fan of your videos, Matt, btw.]

Hello all. I just tried downloading this mod from the OP, and I get a download-specific error in Windows advising me that "ModularFueltanks_v5.2.3.zip might have been moved or deleted." I saw in the download interaction that the file originates from "taniwha.org". Manually visiting that page results in a blank browser screen that reads, "It works! This is the default web page for this server. The web server software is running but no content has been added, yet." I get the impression that either I'm doing something wrong, there's a problem with the download link in the OP, or something funky happened to the repository at the other end. Can someone please advise me how to proceed? Thanks. edit: After posting the above, I saw a "retry" option and clicked it. After some "waiting" messages, I seem to have downloaded the file with no further problems known to me at this time. Is there any further info I can provide to make this into a useful report? Thanks.

I really do respect this answer, and appreciate the obvious desire to help behind it. That said -- I'm a power-user of Windows with more than twenty five years experience using it. I have other always-on programs that I use on an employment basis that are Windows-only that will not port to Linux. My willingness to this point to use Linux at all (read: formatted and repartitioned my ssd to accommodate a dualboot Linux partition) has been for this specific task -- making mod-heavy KSP videos. Please understand, I recognize the whiney nature of my post here. I'm not complaining about KSP performance directly, I'm complaining about interactivity, which is NOT Squad's problem. I get that. I've run into references to JACK and other utilities. I don't doubt that they would be very useful -- if I knew how to frickin use them, which I don't, and cannot afford to invest the time to learn. It'll take two weeks to tweak a Linux desktop to my preferred settings. Antonio Banderas acted in The Mambo Kings in 1992 without knowing any English -- he had to learn his dialogue phonetically, on a per-syllable basis. I can't do that with my computer, still enjoy what I'm accomplishing, and maintain my offline responsibilities at the same time. Have you seen the smug attitudes on even the Ubuntu forums, let alone those on Arch? Microsoft evolved away from command line command interfaces twenty years ago. I still can't seem to disable duplicated HDMI audio devices, I do NOT have an innate understanding of Terminal or bash commands, and it took me four days of pulling my hair out to finally discover that this "sudo apt-get" nonsense was actually case-sensitive for all terms and operands. The fact that my NumLock key won't cooperate, and cut/paste don't work the same as I have learned to expect, only add fuel to my ire. tl;dr Thank you. I've tried what I'm willing to try in Linux. One might as well suggest to me, "Have you tried buying a MacBook? The Mac x64 version of KSP works pretty decent, too." I haven't tried that, and I'm sure there are Linux things I haven't tried. (If someone were willing to actively work with me -- I like the idea of learning Linux more thoroughly and becoming more of a power user -- please PM me. I'll me happy to invest some more time.) My question here is in parallel to all of that: while I lick my wounds and try to make up for twenty five years of Linux-ignorance in doses of a few hours per week, what's the state of Win64? We all know that by the time I get stable and usable in Linux, Win64 will be here, and I'll have to migrate back. :-\

This isn't intended as a complaint thread. I know Win64 sucked in 0.24.2 despite it's ability to "seem" like it worked, which created a horde of headaches for mod supporters. I also know that it's even worse in 0.25. But 3.6gb is not enough. I want FAR, I want B9, I want EVE and BA, KAS, and all the other gizmos and doodads. They're awesome, really. Yes yes, switch to Linux. I want to record my gameplay, too. I cannot replicate my recording environment outside of Windows. Sorry, I can't. I use Virtual Audio Cable and a few other items to make it line up right, and other programs that are not available outside of Windows. I installed Ubuntu, Gentoo, and even tried to work with Arch -- no dice. What's the state of the Win64 builds of Unity and KSP, please?

Despite this post being in the unmodded support section, I still feel it would be helpful to briefly mention that even if you did revert to a previous build of the game, almost all mods have since evolved beyond that previous version. Legacy versions of "many" mods may still be available for the sleuth-user, but I wouldn't go so far as to wager than "most" would be.

We know how that ended up. I've been trying to allow Linux into my life for specifically this reason. My problem is that even if I could get to the point where I'm comfortable enough with my settings to run KSP, my issue remains that I want it be able to record videos of my gameplay, and I simply cannot replicate my windows recording environment in Linux, Virtual Audio Cable being a major component of that. I have no problem recording in Linux and editing / posting in Windows, but this is getting ridiculous. Does anyone have any info on if Win64 will ever be a viable option again? 0.24.2x64 was passable at least, though yes, I recognize that i was a silent and unhelpful minority who refused to flood modmakers with 64-bit help requests. I don't blame modders like ferram4 for affirmatively disabling Win64 play. Still sucks though.

Tune in weekly to view the educational gong show! Loads of info, light on the pre-planning, but it wouldn't be KSP otherwise, amirite? - - - Updated - - - [reserved for future use]

I think it's perhaps overstating things a tad to say that the stock-preferring chap was "bashing" FAR-play. That said, it's likewise easy to overlook the fact that stock aerodynamics might as well be digital mayonnaise. I'm glad that the OP got the answer he was looking for. Simply, when you get used to playing in one physics regime (for this OP, that was apparently stock aerodynamics) and you make the switch to literally any other environment (again, in this case, FAR) there's going to be a learning curve that might at times not seem so obvious. tldr; With FAR, you have to widen your approach lineups and start your final wayyyyy sooner than you'd otherwise have to in stock.

Um? Legibility notwithstanding, here's the real no-crap answer to your question: you provide zero useful information on your scenario. To give you ANY answer that is ANY more useful than the generalities already displayed in this thread, you absolutely must do one or more of the following (the more you do, the more helpful your answer): 1, post the craft file. 2, provide an extremely detailed and exhaustive list of your mods. Listing "FAR, MJ, and some other mods that are not in use with this craft file" will most definitely not cut it. "But some of these other mods won't have anything to do with the parts available." Perhaps narrowly accurate, but the mods modify the game, and as a result, modify your available options for a solution. Without this mod list, downloading the craft file will not accomplish anything. 3, describe this vessel's intended mission profile, preferably with the role it'll play in your overall save. (Specifying sandbox / classic / career could help, too.) "But what does that have to do with my boosters whacking into my fuselage?" It has everything to do with why you need such payload capacity as to necessitate boosters to begin with. -- If this is a career save, perhaps consider posting the savefile as well, so as to replicate your available tech tree and partlist. 4, provide detailed and annotated screenshots of your launch in progress, including, if possible, several angles during the booster sep. Yes, this will likely mean a few launch attempts, along with a likely several quickloads mid-launch (I suggest alt-quicksaving to a point when you have less than 150m/s remaining in your boosters -- you said you run MJ). You're asking an extremely situational question. We can likely examine it and provide a detailed working answer that covers what you're asking, but it would involve us understanding your situation. For that, we need the above info.

You only have one photo that shows your undercarriage. Is your problem that you tip forward and tumble on the runway at touchdown? If so, your undercarriage wheelbase is WAY too short. Send your nose gear farther forward to counteract this. Note that landing gear are physics-less parts. Yes, they show in the SPH as having mass, and that mass will manipulate the CoM indicator, but it's important to ignore this. (Finish all aerodynamic changes to the craft BEFORE adding the undercarriage.) When physics load on your vehicle, your landing gear (as well as other things like ladders, struts, fuel lines, and many other things) will be treated as not-there, massless, dragless, non-entity items. Their collision mesh will still exist, that's how landing gear keep you elevated form the runway before takeoff roll, of course. With your wheelbase so short, your plane on touchdown will have almost no rolling-on-ground pitch stability and I can imagine that it would result in faceplants. Also, get used to flying at low speeds higher up. 260m/s is more than half the speed of sound at sea level, as indicated by other commenters here. FAR will have some useful readouts in the SPH to indicate flight and pitch stability across multiple performance envelopes. Try experimenting with those across a .1-.2 mach speed range. To get a decent idea of your stall speed, try experimenting with it during your takeoff roll. Use quickloads to try to ascertain exactly what the minimum slowest takeoff rotation speed is. Feather your throttle, or even tweak-limit your max thrust for greater feathering precision. If you nosedive off the far end of the runway into the ocean at, say, 180m/s, then your stall speed is faster than that. If your stall speed is anything faster than 100m/s, then I would question your design's airworthiness in general. (And even then, stall speed of 100m/s would make landings hellacious-at-best. Doable, but would require lots of whiteknuckle.)

This mod will help you with porting assemblies in-game between VAB and SPH (basically by allowing you to switch build-modes within one or the other -- "technically" you're not shipping anything, you're just using one or the other at all times with the flexibility of both editor-modes within the same instance.) Switch between VAB and SPH mode with the TAB button. Takes some getting used to, but I PROMISE you it'll do EXACTLY what you need, and much much more -- you'll wonder how you survived this long without the mod. http://forum.kerbalspaceprogram.com/threads/38768-0-24-Editor-Extensions-v1-3-19-Jul-2014-(EdTools-Editor-Tools-replacement) This mod, separately, will allow you to redefine the root part of any assembly of parts, thereby making it easier to assign subassemblies without having to remove cockpits and whatnots. Also a must-have mod, AFAIC. http://forum.kerbalspaceprogram.com/threads/43208-0-24-Jul18-SelectRoot-Set-a-new-root-part-0-24-new-UI

Not quite correct. ferram4 and other mod authors have specifically disavowed the Win64 build, full stop. As in, when you load Win64, the FAR (or NEAR, or KJR, all of his mods) plugin will detect the game version and actually disable itself. This means that there is categorically no way to use any of his mods in Win64. More than a dozen of the "major" mod authors have followed suit. Win64 0.24.2 was terribad, and 0.25 just made it an entire order of magnitude worse. There are countless mod-related forum threads discussing this. Not quite. Collision mapping is affirmatively disabled on combined craft. Any door, engine fairing, any part can clip other parts on the same vessel with utter impunity, and this has been the case at least since 0.19 AFAIK. Part clipping becomes a HUGE problem, however, when craft separate. Parts from different "vessels" (as the term is used inside the actual savefile) clipping through each other will cause violent explosions. There are four ways this can happen. First, of course, is a generic collision course between objects / craft, either piloted or dead-stick / debris-type collisions. No explanation needed for this type. Second, is during staging events. If a stage sep would split parts that began clipped, then at the time of stage event activation, the clip-collision would render detected, and there would result in either an explosion, or if the clip threshold were "minor," the craft would be forcibly and violently repelled from each other, often at a momentary 5+ G-load acceleration. This "minor" clipping event is why EVA kerbonauts will sometimes bounce wildly off of the capsule ladders -- it's reacting to a minor-threshold clipping event. Third, is after manually releasing a docking node. This would result in the same behavior as the second type, above. And fourth is during RSD (Rapid Spontaneous Disassembly). If your craft is disintegrating for any reason (more likely in FAR-atmospheric flight profiles, due to aerodynamic failure) and previously-clipped parts are then separated, then this would result in similar behavior and collision results as items two and three above.

A fair point. In my quoted snippet, I was speaking explicitly toward the OP's indication that MechJeb was set to track terminal velocity, and what kind of flight behavior that would result in with a FAR-environment. Beyond that, you are exactly correct.

This picture is absolutely insufficient to help you diagnose your problem. We need to see closeup shots, preferably from several angles, of the offending sepratrons in question, preferably in flight, and preferably during stage events. This last part is exceedingly difficult, though is doable with repetitive quickloading to get the right shot. Alternatively, you can post your craft file with an exact list of mods used and a description of your flight / launch parameters, so as to allow someone else to recreate the problem. Wow. Ok. Yes, that is your exact problem. With FAR enabled, with or without DREC, you must key your TWR to no more than 1.42 at liftoff. For optimal fuel efficiency, try to key all subsequent stage TWRs to match across stage events. In other words, if MECO is at TWR 2.0, do what you can to tweak the next stage's TWR to the same number, since I've found that mid-launch aerodynamic failures can be made more likely by herky-jerk G-force changes across stage events, moreso than actual high G-load. (High G-load itself is a problem for DREC, but that's a separate issue.) Keep in mind that MechJeb is explicitly and exclusively familiar with stock aerodynamic values, not FAR or NEAR aerodynamics. Indeed, the whole reason that stock aerodynamics is so awful is that it essentially simulated flying through mayonnaise. FAR-atmosphere is much thinner, much more "wispy," which much less drag on most designs (FAR calculates drag by aspect ratio and collision mesh values with respect to the airstream, and takes some other calculations with respect to the size of the attachment nodes [the green spheres where parts interlock in the editor] whereas stock just does a flat calculation based on mass and only mass and nothing but mass -- an aerodynamic nosecone, having mass, will only INCREASE drag, for example.) This means that MechJeb is calculating terminal velocity based on how fast you'd have to be going for stock aerodynamics (digital mayonnaise) to cancel out your acceleration and give you a constant speed, which requires ENORMOUS comparative thrust. Since you're flying through FAR aerodynamics, which tends to be much less atmospheric drag than stock would present even at high altitudes, your MechJeb-governed throttle is WAY in excess of what would otherwise be called for to limit your acceleration to below terminal. It's important to know what terminal velocity even is. Even if you know what it is, some readers of this thread won't, so I'll explain it anyway: thrust accelerates you forward / away from exhaust, drag accelerates you backwards / away from aero-dynamic prograde. When thrust EQUALS drag, then speed doesn't change, and you continue flying at that speed until the balance between thrust and drag is upset. When drag is greater than thrust (or thrust drops below drag) speed in direction of travel decreases, resulting in a net acceleration backwards. When thrust is greater than drag (or drag drops below thrust) then forward speed increases, resulting in a net acceleration forwards. The math can get frustrating, especially during vertical launch, because downward gravity is ALSO acting parallel to drag, thereby effectively increasing it -- which is exactly why in a FAR-model ascent you want to begin your gravity turn asap, typically before 1000m altitude, to begin the process of splitting the gravity value from the drag value. In stock, since the aerodynamics are GREATLY worse than the gravity losses, it's important to get out of the lower atmosphere (highest drag envelope) asap before turning horizontal, which is why you see people going from 0-45 pitch at 10,000m altitude. MechJeb has some devbuilds that can more or less fake their way through FAR-based calculations, but since FAR itself is a mod and is constantly being updated to keep up with changes in the game, it's difficult to accurately peg MechJeb's inner workings to compensate. Generally, in FAR-regime launches, you have to learn to control your ascent manually. Using MJ to circularize at apoapsis is fine, however, and these problems would obviously not present in vacuum (relaunching from Mun / Minmus, for example.) Alternately, you can manually program in a series of vector changes in SASS, or manually modify the launch curve int he default MJ launch ascent module, though that's not for the faint of heart. As a further alternative that most assuredly will not solve your problem but will minimize the inconvenience of the symptoms, is to use tweakable settings on your launch and mid stages to limit your thrust values to a TWR of ~1.3 at liftoff as I describe. Below 1.2, and you lose way too much dV to gravity. Above 1.4, you run a very heavy risk of aerofailure toward the end of the stage, where TWR spikes (because thrust remains constant but mass decreases due to empty fuel tanks, yielding higher TWR.) It bears mentioning that overreliance on sepratrons can itself be an inefficient way of coping with other design flaws, as elsewise suggest above. That said, using sepratrons is not necessarily a bad thing. One possibility is to aim them differently, perhaps at 80 degrees to vertical instead of inward at hard 90 -- 10 degrees up would result in slight retrograde thrust, pushing the booster aftward much quicklier, 10 degrees down would blow the booster slightly forward to compensate for airstream drag during sep.) Similarly, altering your control inputs to allow for stage sep in the final moments BEFORE booster cutoff (allowing the boosters to still be under thrust at time of sep, allowing them to not be so violently smacked by the retrograde airstream) or, the opposite, cutting throttle at booster cutoff so as to coast through booster stage sep, so that can drift outward on decoupler force alone, before re-maxxing throttle to fly off (total coasting time typically ~3 seconds, +/-, if well timed).

I really think this accurately characterizes my frustration. Update: For what little it's worth, I haven't given up on this, and I do appreciate everyone's help so far. First off, I established a proof of concept in a VM environment and did manage to load to the KSP title screen. As was repeatedly suggested to me, this instance had poor performance, but like I said, it was the proof of concept and Linux-learning laboratory I needed. (For the record, not only did I never disbelieve the advice suggesting that this wasn't the way to go, I also kinda knew it to have been the case from the outset. What made me -- admittedly -- very visibly chafe was the from-some-sources-sarcastic insistence on pointing out that it would not be a sustainable solution instead of actually answering a question.) For other unrelated reasons that are very unsexy and outside the scope of this forum, I already had a slowly brewing excuse to reformat anyway, though in the process I did lose some raw Fraps footage I'd generated of a really awesome (and successful!) station deorbit. I repartitioned, and have a functionally complete dual-install of Win7 and Ubuntu. I'll spend a few days finishing the setups for my Win7 messenger apps and other software before, as this thread title suggests, taking the plunge headlong into actually learning Linux. To the Linux cheerleaders out there -- the discussion threads and other resources out there do seem to be somewhat noob-hostile, and I suppose that I (an admitted "power-user" of Windows) maybe just never noticed that Windows is the same way. There's also some sort of undertone in some of the reddits of derision toward migrating Windows users specifically, or at any rate it's a lot less pronounced toward migrating Apple users. That said, I'm looking forward to expanding my horizons.

^^ Apparently I'm blocked from adding more rep to you, but I would if I could. Yours was the first answer completely useful, but... still dead end. Listen, folks, obviously I'm in the wrong place, and getting frustrated with this great KSP community is not the way for me to go about things. I'm about an hour of final desperate attempts to make progress before I actually say screw this, and restrict my KSP and KSP-vidmaking to v0.24.2 for a few months until Squad and / or Unity decides to uncork the awesome. At this point, even Google hates me. Apparently, "I am new to Linux" implies that I know something about Linux, because all of the answers it seems to yield, either here or on Google, is "oh well, do [something I don't understand how to even begin doing] or [something else that provides no context whatsoever] but first you have to identify if [unintelligible circumstance X] or [unintelligible circumstance Y] exists because that would determine how you proceed from there." I'm not trying to sound angry here, but perhaps I have been inarticulate to this point. I. Have. Absolutely. No. Frame. Of. Reference. Here. I know in general, MS-DOS / Microsoft terms what a command line prompt "is," but I have exactly zero knowledge of how it works, or how to use it. I can transcribe character strings and repeat back to a helper the output error messages, or even post screen snips (ONLY made possible by the fact that I'm running a VM instance in a Win7 host, thank you) but I have no ability to make any substantive use of any help provided so far, at all, period, zilch. You might as well give me phonetic instructions how to order a meal in Klingon, I can repeat the sounds, but I will have no greater ability to "speak Klingon." I can watch YouTube videos of major abdominal surgery, but I won't have any idea how to practice medicine. I can perform some pretty daring feats in KSP, but I am wholly unqualified to fly to the ISS in orbit, or to advise NASA on Project Constellation. I have watched the movies Crimson Tide and The Hunt for Red October countless times, but that doesn't make me qualified to operate a United States Navy submarine. I am untrained, unexposed, and ill-equipped to even pass coherent information through to those that are legit trying to help me. I can offer to have a live call on Skype, with screen sharing, and have someone talk me through the process, but even then, see the above examples of Klingon = language or abdominal surgery. Thank you to all for your help so far. I apologize for not being able to use your help.

For some reason I went Xubuntu first off. Ubuntu will be the next guinea pig. As for drivers not working, I don't know what else the problem could be, then, because I have a thirty-come-odd inch monitor display in a native windows resolution of 1900x1280, but the Xubuntu desktop is stuck with unnamed graphics drivers at 640x480. My visible workspace is literally three inches across by four inches tall, and there are buttons and functions not visible through that peephole. I can tab through them with my keyboard and select them blindly on a trial and error basis, however. I have a quad core CPU, 16gb of ram, and 3 crossfired graphics cards that are capable of running Crysis at full-bore highest settings including 16x AA. I question the presumption that it's not possible to get a larger workspace so that I can navigate the Xubuntu desktop.

Because I have VOIP setup on Windows. For KSP multiplayer. Because I have other multiplayer games set up. Because my vidcap software is windows based. Because my audio virtual cables are set up to allow me to share not only my screen over voip during vidcap sessions, but also system sounds, and my sound levels balanced, so I can have remote commentary on the first take. Because I have remote access provisions allowing someone else on another continent to help me edit those vidcaps into final productions. Because I am always-on-call for my job and part of my contract is that I receive job notifications through proprietary messenger software. And because, if I decide that the VM is not high enough performance for me -- and, really, frustration aside, I am pragmatically willing to believe that it might not be -- I want to establish proof-of-concept within a VM environment, period, because investing money in hardware for another machine without even proving that I can manage the operating system on a testbed basis is... "inefficient." I appreciate the obviously-well-intended suggestions I avoid VM. I recognize that I may not end up, ultimately in VM to do what I want to do. But VM is my toolbox for now. I respectfully put forward that advising me that I need better tools doesn't help me.

Hello. I'm new to Linux, attempting to run Xubuntu in a Win7 OracleVM. The VM portal doesn't seem to be giving me issues at this time. I'm not sure how to use the above-quoted information. I've downloaded the .run file in question from AMD.com, and it seems appropriate to my 3x RadeonHD 4895 cards. I'm currently dealing with a 640x480 peephole desktop on a 1900x1280 display, and there are buttons below my field of view that I can tab to and activate, but I cannot read them. I've stumbled upon the command line environment, but the "--buildpkg" argument seems to be rejected. In running the file from the desktop, I can get past the sudo permission challenge, but either of the two install options throws a "vcdk is missing" error. I feel like this is a simple problem, but I'm a Linux virgin. Can someone please help me?

*sigh* I'm stuck on a 640x480 little peephole of a desktop until I can get my AMD drivers installed on this thing. And most of the control buttons seem to be below my visible field.