MisterFister

Really enjoying the series thus far, dude! Please, keep 'em comin!

Scott Manley is widely regarded as one of, if not the single, best KSP pilot on YouTube. To be fair, the first of those two links is Part 1, which doesn't address your underlying question of flying and maneuvering, but he does showcase some of the new parts in the VAB and demonstrates the new ion engine stats. Worth a look, but skippable if you're jonesing too hard for the answer to your question.

Gotcha. Understanding has occurred. Nice.

So, in technical terms, "huh?"

Follow up question: From your pictures, I can see you've clip-mounted 6x radial clampotrons. Are you also using stack-aligned clampotron sr.'s? I'd be curious to know if the actual number of mated docking surfaces contributes to the actual amount of sproing you encounter. Though, I'd be confident in assuming that moar is better once you clear the pad, so reducing them to counteract sproing might not be pragmatic.

You mention the sproing issue. It occurs to me that since you're scattering launch clamps along the height of your outer shell (sensible, since you need to support it while physics loads and your docking ports lock) you're launch-rest state is of distributed pockets of structural tension alternating with compression. When the engines light from below (especially if the clamps all release at the same time) you're actually compounding your problem by compressing the sections in tension with the thrust and momentarily taking previously compressed sections held by the clamps and exterting tension with the freefall.* My suggestion is to actually stage-release clamps in sections. Cross-possibilities include having liquid boosters radially attached (liquid so that they can throttle to mitigate release sag) at strategic points corresponding to the clamp release stages; lighting the main stack at low throttle to compress gently from the bottom, possibly in concert with an upward-cascading clamp release setup; strutting directly to the launch clamps pre-ignition. Secondary thought -- with such tall clamps as you would obviously need to survive physics-load, the problem emerges of sliding smoothly enough out of your vertical coccoon of released clamp towers. Possible solution: inward-aimed sepratrons at the clamp heads so as to literally knock the clamp heads outward as they release? Leave a rosette starburst of spent launch clamps at the pad? *Note: It's a peculiar testament to Whackjob's kerballing might that such a sentence could even make sense.

I think that was the artist's point of the title, folks.

I read this to mean that the special educational version of KSP allows the user to enter and exit the Metric system. Imperial units, perhaps, idk, arcane or extinct measurement systems?

While I myself am in Brooklyn, I too note that there are few people in my circles who have even heard of it. (I have a lot of RL friends on Steam, however, and some recognize the name from the occasional promotions, so there's that.)

All keyboards have some ability to emulate the numpad keys on the right (even non-English keyboards.) This is most often an issue with laptops due to size considerations, but desktop keyboards can be made without the permanent numpad keys as well. How you go about emulating the numpad keys will vary VERY widely by keyboard manufacturer and the intended market for the keyboard / laptop. Generally, you may note that many of the keys on your non-numpad keyboard have secondary characters in them, often printed in shaded or off-color tones so as to distinguish the keys from the primary QWERTY layout. Often, there is a "secondary function" key somewhere, sometimes labeled "fn" or "{f}", or possibly something in no way similar to that. Worse, maybe the symbol you're looking for has been rubbed off of the key entirely, if it's old enough. At any rate, some careful google-fu will likely tell you how to use numpad key references on a keyboard that has no numpad on the righthand side, but I am absolutely convinced that there is no such thing as a keyboard that is completely incapable of it. And indeed, since use of those secondary function keys often remaps the entire keyboard while the activation key is pressed, this may create for some awkward flying situations in KSP where the remapped key is something you also need access to, like throttle controls or what have you. I know that you can get separate external USB-enabled numpads for very cheap, often for less than $10 over the internet.

TheWinterOwl has a pretty in-depth and entertaining video series on how to design VT/HL shuttles, culminating in a trily brilliant and beautiful design he dubs the Roc. I've downloaded and flown it in .22, and it flies beautifully. I even managed to tweak it (mostly moving fuel around)so that I could runway launch it as well with a payload, and to allow for a payloaded landing (his original design assumes an empty landing, which I can respect.) My own tweaking efforts on his design were of mixed results. He then used his Roc design on a live mission in his Mission Controller video series, with stunningly hilarious results. (Spoiler: The mission fails spectacularly with his shuttle disintegrating into a debris cloud within sight of KSC, but this was due to flight stresses that resulted from a Mach 5 banked turn in atmospheric flight while also running 4x hardware time compression. Without the high speed bank, or alternatively without the time compression unwittingly left on, I am convinced that he'd have made a soft touchdown on the runway with room to spare.)

Big fan of the ROC Shuttle, and also of the Open Cockpit series. Question, I'm trying to run Dynamic Warp on my install, so I can intentionally set time to progress at fractional rates (.25x and lower, in addition to 2x, 3x, etc). My game isn't crashing, but I CANNOT activate anything but the stock time acceleration function. Does anyone know if this is this a .23 problem?

What of your opinion on Kethane / KAS? And speaking of Kethane, I remember months ago the talk about as-yet-unseen career mode being based on resource gathering instead of science gathering. Harvesting radioisotopes from Eve's oceans, jet fuel from Jool's upper stratosphere, etc. The lastest devblogs explicitly renounce this idea. i don't question their right to renounce anything, I'm just disappointed that maybe we couldn't "eventually" get both. Perhaps a planned expansion down the road? KSP 2.0?

Perhaps so, but I think Hodo's point was that maybe if you had ailerons, you could control the uncontrolled roll oscillation. (I'm speaking out my nose here, since I've never experienced your problem, but if Hodo's point was that a lifting surface goes completely without a control surface, then I speculate that shenanigans may result within the game.) My next suggestion is for you to upload the .craft file for us to take a look at. For that to be helpful, we'd need to know more about the mods you've installed beyond just a folder listing in your GameData directory. (Many of those mods that I see are plugin related, and many of those mod writers publish several modpaks that all use the same consolidated folder, so a folder list will not provide a complete idea for a crafttester.)

The main issue causing .23 to hang, from my experience, is the ModuleManager1_5.dll no longer works in .23. I suggest upgrading to ModuleManager1_5_6.dll. Solved the hanging issue for me.

I'm not sure if you're trying to accomplish your project a certain way in terms of folder structure, but what about keeping the endemic "mesh =" format and just renaming the mesh files so they're unique and able to be consolidated in the same folder with no conflicts? I still don't think I'll quite understand why almost all parts, even tock squad parts, ALL use the part.cfg / model.mu filenaming scheme, except to artificially necessitate subfolders. I understand that having subfolders has some advantages, and that artifically necessitating the use of repetitive subfolders is one way to realize such advantages; I just can't imagine that the advantages are so monumental, or so impossible by alternate means. (I recognize that modding is made easier by grouping modpaks into their own folders, I speak only of the enforced need to nest folders and subfolders within each modpak on pretty much a per-part basis.

This works wonders for .craft files that have the same issue -- though the renaming scheme doesn't know how to handle the *.craft filenaming convention, which is easily fixed by renaming the file after conversion.

Here's my version of the same tank you're playing with. Feel free to copy it wholesale, if you like. And FYI, the way you do this is by using the CODE /CODE [in brackets]. PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_long module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 15, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -15.1, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = advRocketry entryCost = 4800 cost = 1600 category = Propulsion subcategory = 0 title = FL-T800 Fuel Tank manufacturer = Squad (Jebediah Kerman's Junkyard and Spaceship Parts Co.) description = GameData\Squad\Parts\FuelTank\fuelTank_long\part.cfg. A stretched variant of the FL-T400, the FL-T800 holds twice the fuel in a slightly stronger container. The black stripes along the side make the rocket go faster, our engineers tell us. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 360 maxAmount = 360 } RESOURCE { name = Oxidizer amount = 440 maxAmount = 440 } } PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_long_mt module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 15, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -15.1, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = advRocketry entryCost = 4800 cost = 1600 category = Propulsion subcategory = 0 title = FL-T800 Fuel Tank manufacturer = Selfmod (Squad) description = GameData\Squad\Parts\FuelTank\fuelTank_long\part.cfg. While this tank is indeed empty, we still don't suggest huffing the fumes from within. At least, not where anyone can see you, that is. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 0 maxAmount = 360 } RESOURCE { name = Oxidizer amount = 0 maxAmount = 440 } }

Oh, and speaking of downloading fresh files -- .23 ships today. If you run the Steam version, the update will happen automatically, and depending on what files get changed, you may lose your modded versions. This is another good reason to backup your files before modding.

First of all, the double-decimal point WILL cause a problem, so I suggest fixing that. At this point, given that I've been in your position before, I suspect that you may want to at least download fresh copies of your files if not installing from them entirely, just so you always have a reference for your modding hijinks. Anyway, I've been on a part-modding binge recently, as I'm trying to find a way to sort my parts in the editor partlists. (I have numerous screens under each tab due to having downloaded several parts-heavy modlists, including B9 and KW.) Why this is important to your issue: I find that it helps to take an existing partfile and adjust the tab alignments so that all the nested arguments are easier to follow. Also, I personally appended the "manufacturer" value so that I could always see, in-game in the VAB / SPH partlist editos, what mod a particular part came from. I modified the "description" value to always indicate the exact folder and filename of any part listed, especially useful since there are some partfiles that come with multiple parts described in them. (Hypothetically it's possible to consolidate ALL parts in the entire game into a single partfile, though this gets complicated and problematic quickly.) What I've done is taken all parts that contain LFO, jetfuel, and monopropellant and self-duplicated them in order to make empty versions. I assemble my payloads with the empty tanks, thereby saving on launch weight, since I launch everything to a fueling station in LKO anyway before they head anywhere. I duplicate those empty tanks into the same .cfg file, and I modify the "manufacturer" to read "Selfmod" so I can prevent accidentally choosing the wrong one while designing a craft. I pasted an example below from the Squad folder. Hopefully, this forum will not truncate it. PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = basicRocketry entryCost = 1600 cost = 850 category = Propulsion subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Squad (Jebediah Kerman's Junkyard and Spaceship Parts Co.) description = GameData\Squad\Parts\FuelTank\fuelTank\part.cfg. The FL series was received as a substantial upgrade over previous fuel containers used in the Space Program, generally due to its ability to keep the fuel unexploded more often than not. Fuel tanks are useless if there isn't a Liquid Engine attached under it. They can also be stacked with other fuel tanks to increase the amount of fuel for the engine below. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 180 maxAmount = 180 } RESOURCE { name = Oxidizer amount = 220 maxAmount = 220 } } PART { // Kerbal Space Program - Part Config // FL-T500 Fuel Tank // --- general parameters --- name = fuelTank_mt module = Part author = NovaSilisko // --- asset parameters --- mesh = model.mu scale = 0.1 // --- node definitions --- node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, 1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 // --- editor parameters --- TechRequired = basicRocketry entryCost = 1600 cost = 850 category = Propulsion subcategory = 0 title = FL-T400 Fuel Tank manufacturer = Selfmod (Squad) description = GameData\Squad\Parts\FuelTank\fuelTank\part.cfg. This is an empty FL-T500. Just remember, if *we* mix it up with the fueled version, it's a "clerical error." If *you* mix it up... *shrug* not so much. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- mass = 0.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 50 breakingTorque = 50 maxTemp = 2900 RESOURCE { name = LiquidFuel amount = 0 maxAmount = 180 } RESOURCE { name = Oxidizer amount = 0 maxAmount = 220 } } Hope that helps!

While I do not endorse the unfriendly sarcasm of the above reply, I'd think the multiple decimal points would be your issue. I ran into something perhaps even sillier than your issue recently: I duplicate all of my LFO and RCS tanks, so that I can assemble payloads and launch them without the fuel weight. By sending the empty payload to an orbiting fuel station, I can save on launch weight, thereby achieving greater overall payloads to orbit. (The added benefit is that, once fueled, my payload is 100% fuel capacity, whereas launching fueled payloads generally means using some of its own internal fuel to simply achieve parking orbit to begin with.) Any at rate, in doing so, in one of my recent edits I accidentally entered "-" (hyphen) instead of 0 (zero) for the fuel content. The load screen got to that part file and just hung. Took a few minutes of trial and error to button down the problem. Always backup your files before modding them, sir.

Wow, such a flame comment. FAR generally displays it for you with one of the in-flight readouts. I recommend spending some time on the launchpad actually reading all of the readouts word for word, and clicking on all the ? buttons as they appear. Same in the craft editor. All abbreviations and variable notations are explained and described in accessible terms. While the numbers are indeed different between FAR and stock, I can say from experience on both sides of that divide that in practice, keeping a launch TWR of ~1.8-2 will be fine. In fact, for the most part, with FAR it is quite difficult to attain tV during launch for extended periods, even at full throttle. (The forces needed for sustain upward tV would usually end up g-stressing your craft if you have DeadlyReentry installed.)

If this had been a game-breaking issue, in a pinch you could always re-download the files (whether or not you reinstall) from Squad / Steam.

Everything described here is true and useful, but I think the OP is also asking "why" this happens. First, it's true that realworld GSO satellites drift and have to consume fuel for stationkeeping purposes over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, realworld orbit perturbations result of myriad underlying causes, including faintly off-kilter calculations to begin with, along with fuel impurities (resulting in slightly-less-than-optimal thurst vectors, resulting in burn times being minisculely off-mark) and outside gravitational influences. Over extended periods for extremely accuracy-sensitive satellites, influences such as the moon's orbit, solar activity, and minute irregularities in Earth's own gravity well (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle). Also, there is something called insterstellar and interplanetary drag, such as the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome, as well as naturally occuring events such as the leonids. Obviously, since KSP is a game, the Unity engine is not designed to (nor could it ever) faithfully model every single one of those conditions. Indeed, in KSO all SOIs are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a featureless gravity well. For example, there is no such thing as lagrange points in this game. All fuel is uniformly pure, as another example. There is one obvious issue with maintaining accurate KSO paths and two subtle issues. The obvious issue is human input, just as with realworld. If you design your maneuver nodes well (which even then is not entirely sufficient for the accuracy we would like due to the two subtle reasons below) it's still necessary to aim and burn them well, too. Good form amd fuel efficiency on maneuver nodes begins with good calculations in the VAB / SPH, and continue to include dividing the total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00 seconds BEFORE the designated time, and end exactly 30.00 AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never exactly possible) and accurately following the node indicator on your navball -- when you are down to the last few m/s of burn, it's generally a good idea to lower your throttle, puff those final m/s out, and actually follow the drifting node marker on your navball whenever possible, since the location of the marker DOES calculate your new trajectory live by applying any burn imperfections into the original node calculations. Generally, everything I've said so far makes an immediate sort of sense, when it's laid out. The two other reasons why KSO orbits drift the way they do are much less obvious, however. First, we can agree that the actual math (advanced conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through realworld space or through KSP space, is highly complex, with numbers that have unending decimal places. Simply put, in order to "work," the game engine at some point is forced to say "that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated time lapses, become significant -- ESPECIALLY in a situation like yours where you have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy teensy discrepancies become more and more noticeable. As if all of that wasn't enough, there's also the fact that when comign into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed... and re-rounded. As you play your game, whether you simply blast forward at 100,000x time compression for 5 realworld days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every realworld second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow when it has to keep track of large and complex craft in close proximity to each other.) So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem. Savefile editing will, of course, come the closest to totally eliminating it, since doing so will eliminate all of the human-introduced and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately, just as in realworld satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot in your coverage, and by launching those satellites with extra RCS for better finetuning over a longer operational life.)

I'm knee deep in experimentation with this. Any idea what the category or subcategory variables do? I've decided to be extra thorough with my methodology, since .23 is releasing today. I've backed up all of my mods and my savefiles just to be sure. I'm working with some selfmade macros to do edits of many files en masse, but in order for that to work (for the moment) I need to have all the part.cfg files formatted the same. Some use indents to indicate argument nesting, some do not, some use tab for indents, some use spacing. One mod in particular, ExtraplanetaryLaunchpads, I have no idea what caused it (perhaps the mod was designed on a mac?) the part files were smooshed together with ... "hidden"? carriage returns? Took me hours to untangle that mess. I formalized my previous notions, of embedding the mod origin in the manufacturer variable and the filename and location in the description variable (so that that info would always be visible from the editor partlist in-game.) This will allow two different things. First, I intend to experiment with what you mentioned, the notion of consolidating parts across many folders in a single .cfg file. This info will allow for reversion, typo and asset tracking, etc. Second, I have re-confirmed that part load order determines editor partlist display order. By mixing and shuffling the folders themselves, I hope to be able to influence this. Before doing any of that, though, I want to experiment with those two variables I mentioned at the beginning.