GreeningGalaxy

Assuming they have similar densities to male kerbals (just with the visually-apparent lower volume), then no, it wouldn't make any difference. The game already considers parts that would be fairly heavy on that scale to be massless (or if it doesn't anymore, then no one can tell) so there's really no point. Plus, there's also that little detail that, last I heard, kerbals don't actually contribute to the vessel's mass at all while they're inside a capsule.

Well, only the middle layers are pea soup as we know it. The upper atmosphere is mostly water vapor and suspended frozen peas blown about on strong winds, while the lower layers have been squashed into super-dense metallic green sauce.

Can most iPhones and Android devices actually run KSP? Sure, some devices will, but would it be enough to make it worth it? KSP is such a CPU-heavy game, and while phones have great graphics these days, I just don't have a lot of confidence in a 2-GHz ARM for a task that x86 CPUs of equal or better frequencies struggle with. Even with substantial optimizations and simplifications to the part physics and other heavy calculations, I'm inclined to suspect that KSP would be a slow, battery-draining game on even the best devices. Maybe an iPad Pro could handle it, but I wouldn't bet any money on a playable experience on my perfectly decent Nexus 5. What we probably should do is wait and see how the console editions work, then decide if mobile editions are worth pushing for. If successful, a mobile version could push the game into the hands of more "casual" players and those without ready access to a powerful-enough computer, which certainly wouldn't hurt anything.

I do rather like the idea of multiplayer in KSP, but on further consideration, I also wonder how long its charm would last for a game like KSP even with a perfect implementation. As I see it, KSP isn't really a game that has a good use for ingame interactions between players. There's no real way to do combat (yes, people will try, but don't talk to me about Macey Dean - actual real-time space combat in multiplayer, even without the inevitable lag, would be boring, chaotic, and frustrating), not much to gain from collaboration, and no real opportunities for fun competition (races to the Mun will just end up being a game of whose computer can handle more ridiculous giant rockets). Dark Multiplayer is a cool experiment, but it's mostly used by people who understand its limitations and don't expect a lot from it other than what it says on the tin. If multiplayer functionality were integrated into the stock game, even with perfect solutions to the timewarp/quicksave and lag problems, there would still be the the expectation for Squad to provide something to do in multiplayer. Sure, collaborative contracts and joint missions to other planets will be fun for a little while, but what's next after those get boring? If Squad decides that multiplayer makes sense to pursue after considering all the potential issues, I'll be just as excited to see what they come up with as anyone else, but I also don't think it's worth clamoring for. The technical details of multiplayer games are already quite a bear to deal with, and KSP just doesn't seem like a game that stands to gain as much from turning online as games of other genres might.

There are three main ways to answer this. 1. The hard way: Bother people who like statistics and see if you can find anyone who collected complete data on how long it took, on average, for mods to update in past big version releases. Failing that, start trawling GitHub pages and look at version histories individually. With a big enough sample, you'll probably get a fairly good idea of what it will be like after 1.1 drops, if it's important enough to you that you're willing to spend a few tens of monotonous hours on that sort of thing. 2. The easy way: Don't bother asking. Mods will update when their creators get around to updating them, and not a moment sooner. There's no way to predict the future on that. 3. Get someone to to tell you their general opinion based on past experience. My guess is that there will be a few categories of mod update characterstics after a release as big as 1.1 promises to be: - Mods which are small enough to work fine in 1.1 without any tweaks from previous versions. Probably a pretty short list, given how much is slated to change. - Mods which only require a few obvious fixes and need only a few minutes of their maintainers' time before they'll work. Expect these to update within hours or days of the release. Also probably a pretty short list, limited to small mods that don't have a lot of stuff in them to break. - Mods which need substantial effort to work. Big mods (I.E. B9 Aerospace, KSP Interstellar, MechJeb, etc.) which add a lot of new material will take much longer to update. In the past, we've seen updates come around for big mods within a week or two of the release, or not until several months later. It varies a lot depending on how much time a given modder has to work on their project. - Mods which never update. Some mods may have had their creators move on from them sometime between the last big release and now, and simply will not have a maintainer around to update them, while for others, it's quite possible that the new version will break them so thoroughly that their creators will give up on them. Generally speaking, mods will update after a time roughly proportional to how complex they are. Simple mods that add one or two parts might just work right off the bat, while ones that significantly restructure the game will need more attention before they'll work. Don't hassle modders to get their updates out faster - Rest assured that they're already working on them as fast as they care to, and are unlikely to speed up if you bother them about it.

I use Linux full-time, and while I don't at all think that it's hard to use, I do understand that most lifelong Windows users are uncomfortable with the idea of partitioning their hard disks, booting from external media, and doing all of the other low-level and risky-if-done-wrong things that go into installing Linux. Sure, Ubuntu and Mint make those steps ridiculously easy, but it's still a fair time commitment for first-time users, and often a complete impossibility for users who play KSP on family systems that they can't tinker with. Yes, installing Linux is free and easy if you're willing and able to try it out, but as a Linux user, I know very well how frustrating it can be when a different OS from the one you're using is the only one that a given piece of software will run on. While I might not have joined the crowds clamoring for Windows 64-bit support to be the number-one development priority in the months before the Unity 5 announcement, I also don't think that "just use Linux" is a good general solution for KSP's community.

It does not matter if your OS is 64 bit. KSP for Windows is a 32-bit application at this time, meaning that it cannot make use of more than about 4 gigabytes of RAM in any circumstances, even on 64-bit operating systems. If you mean that people should upgrade to Linux, well, I can't say I don't share that opinion, but I also understand that most people don't want to put in the time it takes to install and learn how to use Linux, and I can't really blame them for that.

I've been able to trigger this most reliably by firing the EVA pack against the fall just before impact. I can't tell if you did that here, but it always works in my game. It does work on other planets, by the way, but don't expect to be able to come down at orbital speeds and live.

Could Starkiller Base work? Short answer: No. Longer answer, more relaxed on realism: Sure. Clearly what Starkiller Base was doing in TFA was taking in all the hydrogen and helium from that star, fusing it into iron all at once, and using the vast amount of energy to accelerate the resulting iron to high speed (exactly how high should be easy enough to calculate if you're familiar with all the stages of fusion between hydrogen and iron, but I'm too sleepy to bother now). That would certainly be powerful enough to destroy planets, considering the amount of mass involved. The gun would probably have to be much bigger than a measly planet to hold that much iron inside it, but hey, whatever. Handwave that away with your favorite nonsensical jargon. Interesting answer: According to the Boom Table, destroying planets outright is very pointless. It would take the energy equivalent about 359 exatons (359,000,000,000,000,000,000 tons) of TNT to overcome Earth's gravitational binding energy and destroy it completely, but only 77 petatons (0.077 exatons) to blow off the atmosphere into space, which would have most of the tactical/shock and awe effects of complete destruction at a fraction of the cost. If the Empire/First Order were keen to make the most of their resources, they might consider building the Death Star's mass in the form of a droid army of BB-8 or R2D2-like droids with weapons, fighters, support ships, etc., which would have the following notable advantages: Overwhelming firepower: Nobody can fight off a droid army when it's big enough to literally blanket the planet. Great individual durability and mobility. Unmatched loyalty and resourcefulness. Day-and-night endurance. Complete invulnerability to the kind of one-shot blow-it-all-up attacks that took out all the previous superweapons: the Republic/Resistance/Rebellion would have to take out each one individually. ("droid control ships" don't count, boo prequels) Improved manufacture rate: It's easier to crank out small droids and fighters, rather than try to piece together a moon-sized space station. Selective precision: Destroy only the enemy, leave everything else, and you get to keep the planet afterwards. Outright geocide is wasteful. The only real disadvantage would be speed of destruction, which would be notably slower than *ZAP* *BOOM*. It still wouldn't be stoppable, though, so that's not really an issue.

Pretty sure there's a way to override the onDestroy behavior for parts. BDA manages to make its bombs explode when destroyed; it doesn't seem like there are technical reasons against this. KSPI's antimatter explosion works just fine - the only problem is when it's triggered. 17 minutes won't save you at any particularly high time warp, but I guess its nice to have some lenience there. If nothing else, it'd be nice to see it configurable in the tanks' part.cfgs.

If possible, I think the antimatter danger mechanics could use a bit of tweaking. In particular, the tanks last much too long unpowered - a minute or two seems reasonable, but 1000 seconds (~17 minutes) kinda takes all the urgency out of it - and they also, for some reason, don't make a big explosion when destroyed. This isn't especially urgent since it only really affects what happens when things go wrong in a very specific way, but if it's not too hard, it'd be nice to see a fix - this has been a pet peeve of mine in KSPI since I first started using Fractal's original version back in 0.23.

There was a small aerodynamic stability problem with a spaceplane powered by an antimatter-initiated fusion reactor. Gildrien ended up floating in the water, while the remains of the aircraft (and the antimatter bottles) sank towards the bottom. She lived, but probably got enough of a radiation dose to ground her for life.

What did you try, and what didn't it do?

[spoiler=Disregard me, I don't know what I'm talking about]I don't know why your astronaut complex is broken, but unfortunately, renaming kerbals won't work very well to help you remember their classes, because changing their names will [I]change[/I] their classes - class is not currently settable within the persistence file and is just determined by a hash of the name. You could randomly change the name until you get the class you're looking for, but that's a lot of game restarts and is probably not worth the effort. I don't think it's known exactly [I]why[/I] Squad decided to make kerbal professions impossible to gainsay by editing the save file; to me, it seems like a shoddy anti-"cheating" mechanism that really has no good reason to be there. In the meantime, you might try the [URL="http://forum.kerbalspaceprogram.com/threads/107471-1-0-5-TextureReplacer-2-4-11-(17-11-2015)"]Texture Replacer[/URL] mod, which adds the ability to have different-colored suits for each class, so you can tell them apart without looking in the vessel info box in the map view. I agree that it should be easier to see a kerbal's profession while in flight, though - hopefully this will be added improved in a later version. [/spoiler] [B]-- EDIT --[/B] [quote name='SchweinAero']A kerbal's name is used as a reference in many places throughout the file. If you change some but not others, the game will lock up over missing kerbals.[/QUOTE] Ah, that's it. If you change the name of kerbal assigned to a vessel, you'll also need to change the name on the vessel roster. Try using whatever text editor you're using to edit the file to search for all instances of the kerbal's old name and replace them with the new name. [B]-- EDIT EDIT --[/B] After opening up the persistence file from 1.0.5 and actually looking, it appears I am out of date - there's a Trait = (scientist/engineer/pilot) option for all the kerbals. So anyway, yeah, changing their names should actually work to tell them apart by profession; just make sure you catch all instances in the persistent.sfs.

I've hyperedited multiple 405-GW antimatter powersats into orbit and used them to power planes up to escape speed (over 3100 m/s) while skimming the wavetops at less than 100 meters above sea level. This was before reentry heating was added, but switching to liquid fuel mode always tore my plane apart no matter how careful I was with the controls. KSPI's lack of limiting factors on microwave power can be pretty amusing.

KSPI has already been a fairly dense mod. Figuring out the finer details is probably best done through trial and error, but here are a few points to push you in the right direction: - Reactors make heat; they do not make electricity. This is what generators are for (last I looked, you had to attach them directly to the reactor, but I think Freethinker may have given more wiggle room there). Some reactors, namely fusion ones, will [I]require[/I] electricity in order to make heat, and therefore must have a generator in order to run at all. - Generators make electricity. "Megajoules" is effectively the same thing as ElectricCharge, just [I]more.[/I] Megajoules will freely convert to ElectricCharge at a 1:1000 exchange rate, but the conversion doesn't currently go the other way as far as I know. - Generators will not work without radiators. If you're building a small atmospheric ship, you can get away with a few of the small radial ones, but if you're making something that will need to run at full power for long periods in space, you'll need to add big radiators (the folding ones are generally the most effective) until the numbers in the VAB thermal helper (press T last I looked, or use the toolbar button) turn green. - Thermal rocket nozzles are like generators, but they make heat into thrust instead of electricity. The specific impulse depends on the core temperature of the reactor they're attached to, and the total thrust power (thrust * specific impulse * ½ * 9.8) is [SIZE=2]ideally[/SIZE] something close to the reactor's total thermal output. Note that this means more thrust is gained by reactors that produce [I]more[/I] power but at a [I]lower[/I] core temperature. - Fission reactors, unlike fusion ones, don't have internal controls - a kerbal will need to EVA, fly close to the reactor, and right-click on it before it can be started up or shut down. Reactors will likely be started by default before being put on the launchpad, so you shouldn't have to worry about this unless you need to shut the reactor down at some point. - Some reactors, mostly fusion ones, have two different kinds of output: heat and "charged particles." Fusion reactions produce both charged and uncharged products, both of which will form heat when they strike the reactor's shielding. However, the charged products have the added bonus of being able to be redirected by magnetic fields. If you use a "direct conversion generator" instead of a "KTEC solid state generator" or "Brayton cycle generator" (I don't know what names are still in use), the generator will use the charged products of the fusion reaction to make electricity at higher efficiency than a thermal generator. Note that different fuel schemes for a fusion reactor produce different amounts of power and different ratios of charged products - the standard deuterium-tritium setup will make the most power, but a fairly low percentage of the reaction products will be charged particles. Deuterium and helium-3 will produce less power but more charged particles, and pure helium-3 is completely "aneutronic" meaning that it produces [I]only[/I] charged particles, at the expense of rather lower power compared to other fuels. Unused charged particles will be thermalized by the reactor and turned into heat. Hint: if you use a thermal rocket nozzle with a fusion reactor, use deuterium-tritium mode and a direct conversion generator. The charged particles will power the reactor, while leaving the thermal power to run the rocket nozzle. - Magnetic nozzles are somewhat similar to thermal nozzles, except they use charged particles only instead of thermal power. This generally gives them very low thrust and very high specific impulse. Magnetic nozzles also have the added bonus of being "gearable" meaning that throttling down will [I]not[/I] alter the power output of the reactor, only the rate of propellant flow, meaning that as thrust decreases, specific impulse will increase. (The DT VISTA inertial fusion engine also has this property.) - Antimatter is really powerful. Antimatter reactors provide colossal amounts of power, much of it as charged particles, which makes them pretty much the ultimate power source for KSPI ships. To get it, you'll need to fly an antimatter containment unit and one of those antimatter collectors out to somewhere like Jool, where the magnetosphere traps anti-particles, and wait around for a while to let the container fill up. When the container's full, don't let it lose power, or it will explode and take your whole ship with it! - The "Antimatter Initiated Reactor" can be thought of as a mash-up of all the reactor types - it burns fission fuel, fusion fuel, and antimatter all at once to make power. The disadvantage is that it requires a lot of different fuels (uranium nitride, helium-3, deuterium, and antimatter), but the advantage is that it uses all of these at extremely low rates - modest tankage of the fusion and fission fuels and a few grams of antimatter will last the reactor many years. In general, test your reactor configurations on the launchpad before you toss them into space - KSPI is a bit finnicky with some setups and isn't good at providing information about why they don't work, so you'll want to make sure everything is actually functional before spending a lot of time (or money, if you play career) getting it into space. For some fusion setups, you may find it useful to have a "pilot reactor" on board - a smaller reactor than the one that powers your main engine to provide power to other systems while the engine is off, and, in the case of fusion reactors, to provide the first boost of power to get the main reactor going. Also note that many fuels/propellants, such as liquid hydrogen (and the isotopes used as fusion fuels) will boil off if not kept very cold, and so their tankage will need to be powered at all times to prevent the fuel from escaping. If I left anything out that wasn't self-explanatory, let me know and I'll do my best to explain it.

[quote name='KrazyKrl']There is no really power-hungry application for a reactor in space, that can't be solved by solars/fuel cells/RTGs and battery-capacitor type setups.[/quote] Ion-powered crewed vehicles far from Kerbol (Dres, Jool, Eeloo) are the prime example of such an application. With the new larger xenon tanks, this would be a potentially excellent propulsion system for the late game, and RTGs/solar cells simply won't cut it when the sunlight is low. [quote]Also, what would this add to gameplay? Needing to ship nuclear fuel rods to a ship every 5 years of MET doesn't seem like it adds much. Same with the gradual reduction of efficiency (which takes [I]years[/I], even with the reactor running continuously.)[/quote] Since the very point of KSP is to push boundaries, lots of players will keep missions out for long enough periods of time for this to come into play. I know I've already launched multi-decade missions to Jool (mostly because I'm bad at launch windows, but I doubt I'm the only one). [Quote]The radiation mechanic makes no sense, you're already suggesting automatic shielding; and space suits already have quite a bit of shielding from cosmic radiation. KSP is first a game; and adding more complexity without a reason for it, sounds like a low-reward high-effort tradeoff. [/QUOTE] The built-in shielding would not contain [I]all[/I] radiation on a realistic spaceborne nuclear reactor; the weight would be impractical. Instead it would be a "shadow shield" in which only a small cone (the ship) is protected by placing a small, heavy shield close to the reactor in order to cast a radiation shadow on the habitat. Nearby vessels are not protected, nor are crew in spacesuits - spacesuits and multilayer insulation only provide any meaningful protection against charged particles, [I]not[/I] gamma rays, and the dangerous radiation produced by a nuclear reactor is pretty much entirely gamma rays since the charged particles don't escape the reactor's containment vessel anyway. Blocking gamma rays requires a lot of heavy metal, and a spacesuit won't provide any protection from them at all. Once again, I'm not asking for these mechanics to be extremely detailed, just that there be something more to nuclear stuff in KSP than "just another engine, this time with magic." People have frequently accused nuclear engines of being overpowered (at least before career made them cost money) and there's still talk of giving them absurd reputation penalties for their use to "balance them out." Instead of mucking around with all that, why not give the player some direct, tangible reasons - namely danger and complexity - why using them isn't a perfect rainbows-and-happiness solution to every delta-V problem?

The nuclear stuff in KSP, as it stands, is obviously well-liked. The LV-N is the go-to engine for getting kerbals out to the most interesting places in the game, like Jool's moons, and the RTG is the main way to get power to vehicles where solar panels would be too cumbersome or ineffective as electrical power sources. However, at present, nuclear technology in KSP is still pretty much treated as magic - you never have to worry about fuel life, reactor control, deadly radiation, or anything more than the most basic thermal management. Furthermore, one of the most logical things to have around in a world with nuclear technology, a true nuclear power reactor, still doesn't exist in KSP, which seems a bit odd given how the LV-N puts out power while burning - the technology's clearly there! - and how much use there is for RTGs in large numbers when it comes to exploring the outer planets. Nuclear stuff in KSP seems like it was added as a bit of an afterthought, but given how much use it sees in the kinds of ships KSPers like to build, it might really do well with a bit of an overhaul. To be clear, I'm not asking for KSP to turn into [URL="https://www.youtube.com/watch?v=vziIgAtD66s"]Rogue System[/URL], or for it to adopt KSP Interstellar into stock, or even for anything particularly fancy at all - I just think the game should provide a little bit more of a reminder to the player that nuclear rockets are not magic super-efficient thrust makers that require no maintenance or consideration for upkeep. This could take the form of one or more of the following: - Nuclear fuel, which costs a significant amount and is slowly turned into depleted fuel by nuclear engines/reactors. - Gradual loss of nuclear engine thrust and specific impulse as nuclear fuel is used up (restoration through reprocessing optional). - Ability to run the reactor without running the engine to make electrical power, given sufficient radiator area to dissipate the waste heat. - A separate nuclear reactor module that only includes the electrical generation functions without the engine part (still produces waste heat and uses nuclear fuel). - Kerbal death due to radiation - being aboard the nuclear-powered ship or far enough away from an operating engine is fine, but standing 5 meters away from an engine or reactor operating a full power is not. Non-instant acute death and chronic effects optional. - Radiation shielding for pods and hardware. Reactors and engines should have built-in shadow shields that protect the rest of the ship when mounted inline, but pods and probe cores should not be safe with multiple nuclear engines or reactors mounted radially to them. - More nuclear engines. Need not be anything especially futuristic or overpowered, but a 2.5m nuclear engine has been a long-wanted feature. Note that I don't necessarily mean that [I]all[/I] of the above should be implemented. My argument is simply that the nuclear mechanics in KSP are, at present, very lacking, and portray nuclear power like magic, which is not something I feel is constructive or interesting. So what does the community think? Is the game already complicated enough as-is with nuclear engines how they are, or should they be improved to add a bit more of a challenge to large-scale late-game career missions? Let me know!

Can confirm, OP. Chutes never seem to deploy before I get to the visible part of the atmosphere, and when I get there, everything overheats and explodes instantly! It's like that layer of gray clouds is made out of solid rock or something. I wish the devs would fix this, I'm doing everything right but I still explode. :mad:

Welcome to the forums! If you're comfortable editing part.cfg files*, this should be fairly easy to do yourself - this is most likely what SWDennis did. BDA is exceptionally good about making everything customizable, so you should just be able to tweak values in the part.cfgs of various guns to alter how they behave and look. For different-colored bolts, the projectileColor parameter is likely what you're looking for - change those four numbers to change the values of red, blue, green, and opacity respectively. There are also parameters to change the shot sound (look online for free laser sound effects, drop the file somewhere in the BDA directory tree, and then change fireSoundPath to point to it) and bolt size (I think tracerStartWidth and tracerEndWidth govern this). You may also want to change bulletDrop to false if your energy weapon shouldn't be affected by gravity, and possibly mess with bulletMass, bulletVelocity, and accuracy as you see fit - since you're well into the realm of soft sci-fi anyway, you can pretty much set these wherever you like. You can also change the ammo with ammoName, and the amount used per shot with requestResourceAmount - if you're making sci-fi energy weapons, you might want to change ammoName to ElectricCharge and requestResourceAmount to something proportional to how much damage it does. I don't know if setting requestResourceAmount to 0 for unlimited ammo will work, but you can always play around with it - my guess is it will still require the resource defined by ammoName to be present on your ship, but won't actually use any, which makes ElectricCharge a good choice since most ships that use a pod will have some available by default. BDA is a great mod to tinker with, since everything is pretty open to alteration and easy to navigate - overall, you can probably expect any given edit you make to the config files to do pretty much exactly what it says on the tin. [SIZE=2]*If you're not comfortable with editing part configs, change that! Before you start tinkering, copy the folder containing the part.cfg and model/texture files to a new name (if you're editing the 50-cal turret, for instance, copy the folder Parts/50CalTurret to something like Parts/50CalTurret-1, and then do all your editing in there - that way, if you somehow bork it, you can just re-copy and start over without losing the original part).[/SIZE]

I think the new cockpit makes much more sense for the types of aircraft you're "supposed" to build in KSP - that is, spaceplanes. Smaller windows make more sense from an engineering standpoint (do you really think a glass canopy would survive the kind of flames you put it through on reentry?) and the upper window for docking mode is a great touch which really emphasizes how much the pod is intended for use in space. Don't get me wrong, I loved the high visibility fighter-jet style cockpit of previous versions, but I did feel like it seemed a bit out of place on a space vehicle. Personally, I'll probably be adding the old pod back into my game for the sake of classy-looking fighter jets, but since those are not really the "point" of vanilla KSP, I think it's fair for the main MK1 cockpit not to look like it was intended for such. With the inline pod's fighter-jet bubble canopy to complement the smaller-windowed, space-optimized nose pod, I think it works.

I was afraid of that. Is flex really tied in that strongly with the rest of the physics, or would rewriting just that part be at least somewhat feasible? I also don't have a particularly good understanding of how joint stiffness is controlled - does it set the magnitude of a restoring force on the joint, or the tolerance for wobble?

I'm not sure if what I'm after here is possible or practical, but I'd like to get a few experienced assessments if possible. Part stress physics, as currently implemented in the game, is a headache on a number of fronts: it makes ships twist, wobble, and fall apart when they really shouldn't, it increases part counts with struts and such, and it makes older computers run extremely slowly on high-partcount ships due to the high physics load (and, until 1.1, the necessarily single-threaded nature of said physics load). The old UbioZur Welding mod addressed this to some degree by allowing parts to be fused together into units which behaved like one part, but what I have in mind is a more complete and brute-force solution: disabling part stress physics, either entirely or nearly so. My questions, then, are thus: Is this at all possible with the modding tools currently available? If so, would it be practical? What necessary limitations would there be? Would it be able to meaningfully improve game performance with high-partcount vessels focused? What limitations would this impose on normal functionality of the game? To be more specific, these are the specific behaviors I'm looking for: The parts of complex vessels are locked into complete or nearly-complete rigidity; the majority of joints will not wobble or bend in any way whatsoever. Separating parts, such as decouplers or docking nodes, will remain separable. The vessel, as a unit, will still collide normally with terrain, other vessels, kerbals, etc. and be capable of landing normally. All parts, including engines, landing gear, solar panels, and others whose location on the vessel is significant will continue to function normally or nearly-normally. Some measure of performance will be gained as a result of the reduced physics load. In the most ideal form, this will move the main performance bottleneck to graphics rather than CPU. It seems that a modification of the UbioZur Welding mod to make it automatic could provide these in some capacity, but a complete "relative coordinate freeze" (that preserves the relative origin and external collider of each part, but disregards forces that would move the part relative to its neighbors) is more what I have in mind. In a perfectly ideal implementation, this would mean that vessels would behave normally when landing on surfaces, reentry/engine heat would appear and propagate as normal, and parts could even explode individually due to physical shock or heat; the only change would be the removal of mechanical stress and joint failure. I do not claim to have a very clear understanding of how the code governing these behaviors is structured, and I do understand if a mod as described here would have to be too complex or restructure the game too deeply to be practical; I intend this only as a question: is this possible, and can it be done? Preemptive Answers to Likely/Frequent Comments [READ ME] Yes, it would absolutely be cheating. I, for one, don't care. To be clear, I'm certainly not meaning to imply that mechanical stress as simulated in KSP is undesirable in principle or that it shouldn't be included in the base game - it's simply a feature I would like the ability to opt out of in favor of other potential features. You are absolutely free to dislike and/or refuse to associate yourself with this venture, but please do not use this thread to preach about why you think this isn't "right" or "fair" or "moral." Okay, cool - but why, specifically? I'm totally willing to believe you if you're sure, but I don't want to hear this if you're just speaking on a hunch and don't have any reasoning or evidence to back it up. No. KJR helps half the problem, but doesn't free up appreciable CPU resources. I'm not demanding anything. I don't expect anyone to rush over here and immediately start writing a free mod for me to my exact specifications just because I asked. All I want to do is toss this out as an idea in case anyone who is both interested and knowledgeable of modding is interested in picking it up, and to open up discussion for other people interested in something similar.

You could theoretically do this, but it's hard to see what you'd hope to gain from it. If you wanted to accelerate a projectile in a circle, you'd have to apply a very strong force on the projectile towards the center of the loop to keep it moving in a circle, and the force required for this would get very large for small loops. For something like that launch track someone posted earlier in the thread, it could be practical, but for the case of remotely-portable weapons or anything where size is a particular concern, you'll be much more efficient to concentrate all of your energy into a high linear acceleration than to try to do anything fancy with circular stuff - you'll waste too much just keeping the projectile going in a circle, which won't be free. And practically speaking, coilguns already have enough problems accelerating things to significant speeds; I don't imagine adding a need for centripetal magnets will make things any easier.

I thought I included a config to manually set those? I did in the other packs; if I forgot to do it there I should have time to add it at some point soon. I had no idea that capitalizing K did that. :I Update: Yeah, GGDL_Serious.cfg is what you're looking for. make sure that's in the TextureReplacer directory, above Heads, alongside default.cfg. ...unless this functionality got updated out from under me or something? I've been a bit busy lately and wouldn't know.