Northstar1989

Are the mod authors aware of this issue? That kind of thing REALLY should be on the release threads for both MKS/OKS and Kabonite... +1 on the Community Tech Tree. Fractal, I REALLY hope you jump in on this. By the way, RoverDude, you linked to an individual post in the thread (http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree?p=1507172#post1507172) rather than the thread itself(http://forum.kerbalspaceprogram.com/threads/98409-Planning-Community-Tech-Tree). Just something to keep in mind, as it makes quoting your messages a bit more tedious/overwhelming with the extra text, and identifying where the link leads to (without clicking on it- not that I don't trust you) a bit more difficult... Regards, Northstar

Those appear to be per-unit prices. Mutliply the number of units by the density to get the mass for the SolidFuel (in metric tons, I believe.) So, just figure out the number of units that comprises a metric ton with the current density settings, and compare them to real-world prices to figure out if they're accurate. My guess is they're too high, based on their relative pricing per-ton to Kero/LOX... (which only comprises 0.3% of the launch costs of a Space-X Falcon 9) As for the Ec, it has been heavily debated what the units are supposed to stand for. KSP-Interstellar make the (slightly generous) assumption that each Ec represents a kW, based on cutting-edge modern-day solar technology (of the sort used on spaceships- where the very best solar panels available are typically used) and everything being Kerbal-scale, whereas estimates based on the MUCH less efficient photovoltaic technology of the 1960's/70's and taking the soalr panel area as what it actually is rather than a downsized version of real panels leads to an estimate of each Ec unit being about 3.3 Watts... @NathnaKell Also, any news on fixing the crew capsules that still carry only Monopropellant? That should be a base-mod fix, rather than anything to do with one of the engine configs... Regards, Northstar

You're right. I updated FAR, and the problems *appear* to have went away... (further testing will be necessary to validate this) I guess I should have updated *before* posting that. Regards, Northstar

@NathanKell/Regex Some crew capsules (in stock, NovaPunch2, and Firespitter) that carry Monopropellant currently haven't yet been configured to carry Hydrazine or act as Modular RCS Tanks (so that we can choose which RCS fuel we want to use, instead of being limited to just Hydrazine) yet. This (along with the fact the KSP-Interstellar's ISRU produces Monopropellant, not Hydrazine, and Dreadicon's new integration config hasn't done anything to fix that yet- something I *just now* left him a post about on his dev thread...) is one of the main issues holding me back from switching over to ModuleRCSFX instead of continuing to use Monopropellant. Currently, I have ModuleRCSFX deleted, as per the instructions on the "Stockalike" engine config (which still hasn't yet done anything to fix the O-10 Monopropellant engines to be able to use RealFuels RCS resources such as Hydrazine) in order to use Monopropellant instead as a result, but would like to be able to switch over to realistic RCS fuels relatively soon... Regards, Northstar

@Raptor831 Hi Raptor, this is your friendly reminder that the stock O-10 Monopropellant Engines still haven't been fixed to use Hydrazine and other RCS resources instead of Monopropellant (when ModuleRCSFX is installed) yet. Also, any progress on the KSP-Interstellar Meth/LOX engine yet? I still haven't heard any hint from anyone that it's being worked on. Dreadicon doesn't seem to want to do it (he doesn't like writing MM engine patches), and I don't have the first idea how to do it myself, but I already provided you with the correct TWR/ISP and thrust values... Regards, Northstar

@Dreadicon Another issues I noticed with the config- this one related to Monopropellant/Hydrazine. Currently, the code you sent NathanKell has changes the KSP-Interstellar plasma thrusters to use "Hydrazine" instead of "Monopropellant" +@ELECTRIC_PROPELLANT[MonoPropellant]:NEEDS[WarpPlugin&RealFuels]:FOR[RealFuels] +{ + @guiName = Hydrazine + @PROPELLANT[MonoPropellant] + { + @name = Hydrazine + } +} The problem with this is, not all players using RealFuels necessarily play with ModuleRCSFX installed. Some, such as myself, choose to delete it, per the instructions on some of the engine config pages (such as the one for "Stockalike") so that we can use Monopropellant instead... Why would I ever choose to delete ModuleRCSFX, you might ask? Because KSP-Interstellar normally includes an ISRU reaction that allows players to make Monopropellant- but not Hydrazine. Also because several of the crew capsules still carry Monopropellant rather than Hydrazive even with ModuleRCSFX installed, and the O-10 Monopropellant Engines haven't yet been fixed to use Hydrazine instead in the "Stockalike" engine config... (despite my having reminded Raptor831 of this issues several times) You could create code to fix some of these issues (a catch-all to make capsule Monopropellant tanks into modular RCS tanks, and a line of code to make the KSP-Interstellar reaction produce Hydrazine instead of Monopropellant- which I think would just be a matter of a MM patch to change the KSP-Interstellar resource name for Monopropellant...), but you should probably also make the change from Monopropellant to Hydrazine dependent on having ModuleRCSFX installed, rather than the base RealFuels folder. Regards, Northstar

@Ferram There's definitely something wrong with the 0.14.3 lift code (possibly one of the things you fixed by 0.14.3.2? I'm not running the latest version yet). I keep coming up with results like THIS: This plane checks out as all green on the stability screen at the relevant air pressures and speeds, yet INSISTS on rolling partway over like this. This is what it flies stably at too- it's not rolling back and forth... (you can ignore the MechJeb setting, by the way- I only set it to -12 degrees roll because it was flying stably at that anyways, and didn't want it to suddenly freak out if that somehow changed...) It's got strakes on the underside, and the wings are multi-part, so it's quite possible it's been fixed with changes in the wing interaction code in 0.14.3. I haven't been able to check yet... Regards, Northstar

You're not listening to what he said. He reported that when adding a second wing on top of the first, the lift icon moved BACK, towards the rear of the plane- which shouldn't happen. Adding a second wing that close to the first doesn't meaningfully increase lift (adding two wings with a significant gap DOES increase lift- by at least 10-20%, however), but it shouldn't CANCEL the lift of the first wing. That's a serious bug with the wing interaction code if the lift icon is accurate. Regards, Northstar

I present the launch of my Mun Mission: This is also my first major launch to take advantage of the modified Mass Accelerators I forked from the Stanford Torus mod recently (and re-balanced to be more in line with real life mass driver designs- which are lighter, stronger, more energy-hungry, and more powerful than the ones in the original mod...) Note that the force has been set to less than 30% of the up-rated maximum (11,760 kN/s, based on the real world Star Tram design proposal)- this is as the rocket design is not aerodynamically stable enough for an ejection at full-force... (I could have used a shorter stack of coils set at higher force levels, but a more gradual acceleration is gentler on the rocket and pilot...) This was also a Space-X style launch (hey, look at that, I combined real-world better-launch ideas!) and the launch stage safely touched down in the ocean east of the KSC (the payload needed extra horizontal velocity, and touching down near the KSC would have been risky, as the electromagnet stack could have collapsed during physics-load...), although the use of LH2/LOX in the launch stage (with its associated boil-off issues) didn't allow for a "true" Space-X launch with a powered touchdown, so I had to rely entirely on parachutes... The net result of all this: I cheaply and intelligently launched my Munar Lander to an elliptical orbit with its periapsis in the right place for an efficient Munar transfer... However, inspection of what was supposed to be the Munar Transfer Stage revealed that a direct plane-change would have actually cost more Delta-V than going to the Mun, and using it for a plane-change. And the main mission vehicle (with the lander and CSM) had needed to launch into an equatorial orbit so as to deliver what is supposed to be a Munar fuel depot (the stage with the surface-attached Clamp-o-Tron Jr.) into an equatorial orbit around the Mun- stationing a permanent Munar fuel depot in a polar orbit doesn't make much sense. (Finally, the return-tug is also in an equatorial orbit, so the Command/Service Module should preferably launch to an equatorial orbit as well...) I decided to re-purpose the "transfer stage" as a fuel tanker (the lander/CSM/depot had more than enough TWR and Delta-V to get to the Mun on its own), and launch it directly into a Munar polar orbit- where it will rendezvous with the Mun lander after the depot/CSM are delivered to an equatorial orbit, and top off its fuel tanks before I attempt a Munar landing (which will likely be two-part, involving a suborbital "hop" from the poles to an equatorial site before launching to rendezvous with the CSM- this actually being cheaper in terms of Delta-V than a plane-change from polar orbit, and netting me more Science points...) The Lander/CSM, meanwhile, transferred to the Mun under its own power, using the small and rather efficient lander engine: In the meantime, I'm working on a polar expedition on Kerbin as well (I felt bad co-opting the mission suggestion of a Kerbal polar mission into a Munar polar landing...), making use of a SpaceShip One style "mothership" launch: http://en.wikipedia.org/wiki/SpaceShipOne http://en.wikipedia.org/wiki/Scaled_Composites_White_Knight Regards, Northstar

I'm trying to fork a single part (a Mass Driver) from a much larger mod and re-release it as a rebalanced version of the part (with credit to the original author, of course). The mod is under a CDDL-1 license, which is a variant of open-source license, and explicitly allows re-distribution and modification of the "product", so long as credit is given to the original author and to anyone who made modifications to it... See the following link for a more in-depth discussion: http://forum.kerbalspaceprogram.com/threads/98284-Creating-an-up-rated-version-of-the-Stanford-Torus-mod-Mass-Accelerator?p=1506431#post1506431 Anyways, since the mod part has no associated files that are not immediately human-readable: .EXE or .DLL files or such, and is just a .CFG file with some associated textures, I was wondering: what qualifies as meeting the forum rules for posting a source code? According the the Wikipedia definition of a source code, it is a human-readable language for files created using a compiler, often in the form of a .TXT file. Since there were no files created using a compiler, and the mod part is ALREADY in the form of a .TXT file (of which a .CFG is just a variant), do I need to do anything besides post the modified part file, and possibly the original version before I made any modifications to it? Any help here would be greatly appreciated. Regards, Northstar

I'll try to message the mod author, but I don't believe he's very active anymore... This just struck me, but would there even *be* a separate source-code for this part? It doesn't come associated with any .dll files or anything- just a .CFG part and some textures. So, it's possible the mod author created the thing entirely from Notepad/Wordpad, and never actually had to *create* a separate source in the first place... (source codes are only used where the file of interest uses a compiler, right?) The license also only requires source files for executable files (of which there are none), so technically the mod author wasn't required to post a source (if such a file even exists). And Squad might not require me to post one for my fork of the part?? Reading the Wikipedia definition of "source code" would imply there isn't one here, as a .CFG file is already "human-readable" and in text form... "source code is any collection of computer instructions (possibly with comments) written using some human-readable computer language, usually as text." http://en.wikipedia.org/wiki/Source_code Forgive me if I sound silly here- I'm not very familiar with programming. Regards, Northstar

Turbojets of any sort (thermal or otherwise) don't work at the relevant altitude and speed ranges (plus their ISP is much too low at the edge of their performance envelope, so going deeper wouldn't work...) We're talking about *satellites* inside the edge of the atmosphere (think between a 64x64 km and a 72x72 km orbit in KSP), either just above or below the Karman line here- not planes. Some type of nitrogen-electric propulsion is necessary to efficiently counteract drag using locally-available resources. Yes, the exact same technology would work on gas giants, That's correct. You'd just be scooping Hydrogen/Helium-3 (enough atmospheric mixing occurs that you could still find *some* He-3 at the edge of the atmosphere- although you'd probably still want to go deeper for higher concentrations...) instead of Oxygen and Nitrogen. And using Hydrogen for electric propulsion instead of Nitrogen... Regards, Northstar P.S. If you didn't infer it from what I just wrote- yes, you can already create Propulsive Fluid Accumulator satellites just inside Jool's atmosphere, using KSP-Interstellar's atmospheric scoops and hydrogen fuel-mode for its plasma thrusters. It works great with FAR installed. But this can also theoretically be done on Earth in real-life, and Kerbin in-game, and I want to see KSP-Interstellar create nitrogen-electric propulsion to enable it in KSP...

@NathanKell Any progress about fixing the boil-off equations to be based on the 4/9th power of tank surface area rather than proportional to maximum volume? Also, we still *really need* the ability to actively cool tanks to reduce boil-off (several such systems have been designed for spacecraft fuel tanks in real life- just not implemented, as it is only useful for deep-space missions or fuel depots using cryogenic fuels, and works best with large craft rather than probes- as the cooling equipment doesn't scale down very efficiently mass-wise, and smaller craft require relatively more cooling for their volume due to the Square-Cube Law to begin with...) The cooling equipment could be a separate part radially/stack-attached to the fuel tanks it cools, or somehow built into the fuel tanks themselves. If it were a separate part, it should come in two sizes- a large and a small variant, with the larger variant being more powerful for its mass to reflect reality (REALLY BIG fuel tanks should need multiple large units, and would thus fail to benefit further, though). The balance of cooling requirements also needs to be account for the Square-Cube law and tank geometry- i.e. cooling requirements should be proportional either to tank Surface Area (if there is a way to find that directly) or the 2/3rd power of tank volume (the exponent at which heat leakage scales- boil-off is proportional *both* to heat leakage and the available surface area for fuel to leak through, and thus the 4/9th rather than 2/3rd power though...) And cooling a tank should reduce (to about 1/10,000th the normal rate) but not eliminate boil-off, like in real life- so larger tanks would still experience relatively less boil-off, and tanks of any finite size could still not hold cryogenic fuel indefinitely. A final note- saying heat leakage scales with the 2/3rd power of tank volume is a *very* rough approximation, even with a cuboidal or cylindrical fuel tank. This is because fuel tanks are essentially pressure vessels (internal pressure vs. vacuum of space), and their walls become thicker the relatively less surface area they have for their volume (this is also why their mass scales linearly with volume, rather than with the Square-Cube Law). So larger tanks not only have relatively less surface area, they also have thicker tank walls- which are inherently better at insulating the fuel (a 2-inch thick aluminum sheet is a better insulator than an aluminum sheet a few cm thick...) And if you add actual insulation (most real fuel tanks have at least a little light added insulation), the insulation mass is spread over a relatively smaller surface area- which means the same relative mass of insulation will be coated on in a thicker or larger number of (thus more effective) layers... In short- heat leakage scales at *LESS* than the 2/3rd power of volume... Regards, Northstar P.S. One of the subtle, and not-so-obvious consequences of scaling heat leakage with the 2/3rd power of tank volume, and overall boil-off with the 4/9th power, is than two 1000 L tanks laid end-to-end actually experience slightly more boil-off than a double-length tank with 2000 L volume. This is actually both expected and accurate/realistic- the longer tank would actually have thicker outer walls than the shorter tanks. Taken to an extreme, compare the wall thickness of, say, a single monolithic tank, and a honeycomb structure of smaller tanks with the same total volume (remember, tank mass scales linearly with volume- and larger tanks require thicker walls) to see drastic differences in outer wall thickness...

For those of you who have never heard of the Stanford Torus mod, it's a great, interesting mod that I stumbled across recently. Here's a link to the CurseForge page where it is maintained/released: http://www.curse.com/ksp-mods/kerbal/221761-stanford-torus-0-5 It includes a Mass Accelerator part, but those parts provide FAR too little acceleration, and have far too high of a per-unit price (in Career Mode), to actually be usable... The mod is licensed under a CDDL 1.0 license, however- an open source lincense meaning that any part of the product can be modified, reproduced, and/or redistributed provided the source is still provided (the license also requires the Initial Developer to provide a copy of the source), and it is noted who the Initial Developer was and who made the modifications to the product... http://opensource.org/licenses/CDDL-1.0 Thus, I would like some help in creating a fork of just the Mass Accelerator from this awesome mod, and up-rating it to realistic force levels (giving credit to michaelhester07 for his awesome original work, of course). The part currently produces 250 kN of force per second (each part produces 250 kN of force for 0.5 seconds, and they can be stacked), whereas a real-world mass accelerator proposal as part of the Star Tram system would produce approximately 11,760 kN of force per second, according to calculations from the vessel size and acceleration (40 tons and 30 g's for Star Tram). The original mod author has the right relation between power consumption and force produced, though: 1 MW = 100 kN/s. Which represents a roughly 10% efficient electromagnet. Basically, I just want help in the right way to set up a thread re-distributing a forked version of this one part, which I will make the modifications to for up-rating its force and power consumption to realistic levels, and reducing its Career Mode costs by *at least* 80-90%... (currently it costs 185,000 per part) As I understand it, a fork needs to include: - The (forum?) name of the Initial Developer, and credit to him for creating the original mod - My name (forum name is acceptable, I presume?), and a notice on the modifications I made - Copies of both the original and modified source code Is that everything? Is there anything else I'm missing? And how exactly would I get the source- I don't actually *see* a file or link labeled "source" anywhere on the mod release site, even though the Initial Developer (the mod author) is legally required to provide it with that license. Regards, Northstar

I've never heard of it, so... However, if you posted a link, I'd love to take a look at- maybe suggest some mission ideas of my own, maybe even steal some ideas from it on how to run this game... EDIT: By the way, more news. I've decided to install the Stanford Torus mod, and created an up-rated version of the Mass Accelerator in it which matches real-world specs (the mod's accelerator only produces a force of 250 kN/s, whereas the generation-1 Star Tram magnetic launch system would produce 11760 kN/s- I uprated both force production and power consumption appropriately, reduced the costs by 90%, and added a hefty entry purchase cost...) Currently, the up-rated Mass Accelerator is just for my personal use, but here is a thread where I try and figure out what I need to do to redistribute it for everyone, since the license (CDDL-1) allows it: http://forum.kerbalspaceprogram.com/threads/98284-Creating-an-up-rated-version-of-the-Stanford-Torus-mod-Mass-Accelerator Regards, Northstar

No idea why the mod author hasn't updated this thread yet, but *apparently* he's continued to update it on CurseForge. Here is the link to the latest version (0.5)... http://www.curse.com/ksp-mods/kerbal/221761-stanford-torus-0-5 Now everyone go forth and enjoy this awesome mod! Regards, Northstar

Actually, there *IS* a benefit to having multiple receivers. It counts as having a larger total receiver area, and you'll get a *slightly* lower rate of transmission-loss. As in, maybe a couple fractions of a percent more total received power. And no two receivers ever have *exactly* the same path-length, or face *precisely* the same way, so there's always the benefits from that... (in fact, maybe the benefits I noticed from having multiple receivers on a single craft, even facing the same way, were just due to that... Although in real life, multiple receivers do amount to *slightly* lower transmission losses...) Regards, Northstar

You're right- methane doesn't need a MM patch, since the resource name doesn't change. I don't know how I missed that earlier- probably because I was writing at 4 AM... As for the hydrogen and oxidizer, I haven't had the opportunity to play-test them yet. Since the config you posted does *NOT* include the DT-Vista, Meth/LOX, or Al-Hybrid engine, but *DOES* include some of the same fixes present in the old config, I can't safely delete the old config and install the new without possibly risking messing up my save. I suggest you get the version you sent to NathanKell, that includes *ALL* of the fixes, posted here as soon as possible, so I can actually test the config for functionality. The first thing I intend to do is launch a ISRU refinery in Sandbox mode, and see if it is still capable of collecting Oxygen on Kerbin without the additional definitions. You're right, it probably works without them- but I just want to be sure... By "issues that aren't confirmed outside theory", I assume you mean the issues with ISRU collection of Hydrogen and Oxygen? There's nothing theoretical about the DT-Vista and Al-Hybrid engines not working without a config- that should be painfully obvious. Just make sure that those engine configs make it to base RealFuels or the "Stockalike" engine config (especially with the Meth/LOX engine, which needs to go to "Stockalike" so it can have its TWR/ISP adjusted- although after that's done I'll also take a peak at the AL-Hybrid TWR/ISP to see if it needs adjustment, so I would advise kicking that over to "Stockalike" as well...) The sooner you get that updated, the sooner I can actually play-test the config to see if it works... Looks good- that would be a simple/elegant solution if a resource definition MM patch proves necessary like it did back when the original integration config was created. Cool to know that you'll look at adding urine/WasteWater electrolysis... It should still produce a *little* Waste, though, as upon further research it appears it eventually leaves some salt (as in NaCl) residue behind... (no, it doesn't produce chlorine gas- the current/voltage levels used for urine/water electrolysis aren't sufficient for that...) Or maybe it's just best to abstract that and ignore it, since it would be less than 1% of total WasteWater mass, and the Electrolysis part already has some inefficiency built in- your call. Finally, I'm also bugging FractalUK to add a Nitrogen fuel-mode for the KSP-Interstellar plasma thruster, and even trying to get Raptor831 to add one for the RealFuels "Stockalike" config (I can't thing of a better place for it...) We'll see if any of that works out... Regards, Northstar

That's because all the power is going to the first refinery, even if it doesn't need it. This a current known issue with the Microwave Beamed Power system. Set up the refineries more than 2.5 km apart, or connecting them with KAS pipes/winches so that they share the same power supply as a workaround... Regards, Northstar

The ISRU Refinery *DOES* require MJ, but the solar panels ARE capable of producing them, if Ec production >> Ec demand. I just tested using an ISRU refinery with nothing but solar panels attached to electrolyze water last night (as part of working to circumvent Hydrogen boil-off in RealFuels- which still doesn't yet have any way to spend electricity to actively cool your fuels and mitigate boil-off...), and it worked fine. Just keep in mind you need a LOT of solar panels- I had 16 of the 1x3 stock solar panels attached, as well as about 24 OX-STAT panels, and the thing was barely moving at a snail's pace (ofc this was INSIDE Kerbin's atmosphere, where solar panels are much less effective). So you'll need a LOT of solar panels to run your ISRU refinery off ground-based solar power on Minmus- at least a dozen Gigantor panels to get any kind of a decent rate. At that point, you're better off just leaving the solar panels in orbit of Minmus, and relying on an orbital Microwave Beamed Power design so that less of the sunlight will be obstructed by Minmus' terrain, since you'll save a lot of mass on landing legs and descent fuel this way (you will also need to set up some orbital relays so you can receive solar power when the satellites are on the opposite side of Minmus- but all those require is a Microwave Transceiver and a probe core to function...) Regards, Northstar

That's all I'm asking for. It would be NICE if the thrust were up-rated, instead of the engine mass decreased, to match real-world TWR (the current Meth/LOX engine is *ALREADY* a heavy-lift engine, so this doesn't change its role- just make it more realistically effective at what it already does), but I'd be happy with either solution. I *do* want the ISP increased to real-world values, though. Regards, Northstar

KSP-Interstellar lets you store Oxygen from scooping Kerbin's atmo, as I pointed out in the OP. The problems with using ion propulsion this way are two-fold, though. One, the stock ion engines have a MUCH lower ISP (though higher thrust) than many of the more advanced real-world ion engines: such as a Dual Stage 4-grid ion thruster (which the NearFuture mod accurately replicates the ISP of, but with higher TWR than the original). Two, Xenon-based ion thrusters are non-renewable in such a situation- you'll have to constantly launch more Xenon propellant for the system to work... Using Nitrogen scooped from the atmo to maintain altitude/speed lets you run the system with no external inputs except power (beamed from the ground or solar power satellites if you don't use an onboard nuclear reactor and occasionally ship up fresh Uranium rods...), and essentially get "free" Liquid Oxygen (LqdOxygen in RealFuels or Oxidizer in the stock game) without any cost other than the initial setup cost of the system. Such a Propulsive Fluid Accumulator system QUICKLY pays for itself many times over- which was the whole point of the originally-proposed design... Regards, Northstar

How many times must I state this. That will *not* work for most parts. They have to be explicitly coded to allow it for that to work. However, in reviewing the KAS file just a second ago (looking for anything called "KIS"), I noticed a file called MM_Squad that I hadn't seen before... As it turns out, this a ModuleManager patch file that *includes just such a patch to the stock radial chute*, making it attachable with a physicsjoint (so that it can actually work to slow the Kerbal down during a skydive) to a Kerbal on EVA. It won't work for parts *without* that explicit coding, however. But KospY included it for the part I was upset about, so I'm happy. As for the challenge thread- I created the thread, and I intend to submit a new entry to it myself in the relatively near future... And when other players see it pop back to the top of the Challenge thread, they'll probably consider making an entry themselves (in fact, since it works, why don't you?) Regards, Northstar

So, KospY, what *IS* all this stuff about "KIS"? I understand that you removed the functionality to auto-equip grabbed parts to a Kerbal's back, but it seems you've broken off some of the new functionalities into what you call "KIS". Is this a separate mode entirely (and if so, where can we find the thread? A link would be helpful for those of us who wanted KAS for some of those EVA construction functionalities in the first place), or just a new module within the KAS.dll? (I didn't *see* any new .dll files, so I'm assuming it's not an entirely new file w/in the KAS folder) Regards, Northstar

NO, NO, NO! No offense to either of you- it was just my first reaction to how wrong you were. You, and Gaiiden (who posted that 10char response before) completely mis-understand the changes if you think that's how it works. KospY was quite clear that only parts which have been explicitly coded to do so can now be equipped on the hands, backs, arms, etc. Which means the stock radial parachutes used for the Kerbal Skydiving Challenge- not going to work anymore (as stock 'chutes, they obviously have not been coded to work with KAS as back-equippable parts!) Regards, Northstar