phoenix_ca

Has MJ's docking ever been passable? The only downside of Q-Struts (THAT'S RIGHT I SAID Q-STRUT...and I have no idea why that should be a big deal...it probably shouldn't) is that they drain some power. Granted, if you have oodles of power it's not a big deal. They also require a fair amount of forethought, lest you end-up with a pile of them that are unnecessary and do nothing but add to your part count.

I would...if I had any idea how those values were calculated. >.> Unless they were done experimentally. That'd actually be quite easy to determine. Not with the same accuracy as pulling out the code and interpreting it would be, but close enough.

How dare you! No empathy is allowed in ksp! And everything is evil cheating! And stuff! Or something!

Cool beans. >.>

So what's involved in that? Get to say...1,000m up or so and launch a grappling hook?

AFAIK, KSPI atmospheric scoops don't work when not focused.

Well. That's an elegant work-around. I like it. And I'm kinda facepalming at myself right now for not thinking of it. I've seen demos of other applications of similar tech. Detect where the other things are and move your object away from them. Ignore collisions.

It'd certainly be interesting if the SrfLanded status could be faked above ground for the purposes of stationary airships.

Well. That's unfortunate. But possible with KAS you say? So it might be doable.

What you're talking about would involve a lot of real-time physics calculations of collisions, depending on the accuracy of the collision meshes. You could just make them a big box for that purpose. It wouldn't look very good, but even then there would be a lot of physics calculations going on just to figure-out where they should be. It's kinda the same problem that there is with ropes/chains. If you want them to look right, you need to have a lot of little pieces. Every little piece adds more calculations that need to be done in real-time, and it all just gets harder and harder on any CPU from there. Think of what happens when a largish ship collides with the ground in KSP. The game freezes as it figures-out all the physics involved before it can finally say "Yup, everything got blown to bits...except for this piece, and this piece, and this piece, which are going in that direction and this direction and this direction". You'd be doing something similar to that for the entire time the parachutes were deployed, and the more chutes you add, the more work necessary.

Cool beans. So here's a question, and apologies for not testing this myself but my computer with KSP on it is in for repair: What happens to airships when they're put on rails? When I saw these parts I immediately thought "this would be perfect for He3-gathering in KSPI on Jool". The idea is to drop a large airship in Jool's atmosphere, with piles and piles of scoops on it to collect He3. Then I could send a spaceplane down to collect the He3, assuming I could figure-out a decent way to get the resources transferred. Fuel lines to transfer resources means docking, docking means bad, bad things in mid-air. But none of that matters if the thing will just drop from the sky when it goes on rails. Might need to find a way for the airship to put itself into orbit instead.

Install breaking? That sounds...unfortunate.

Hrm. Still seems like something that'd be better served by an RTG, or some other part like a fuel cell from another mod. At least, if part count is something you care about...which it should be, unless you have a liquid-cooled extremely OC'd CPU...probably even then.

Thanks. I really hope there's a sentence or two added to the OP though, for the benefit of others. Digging through threads in the hope of finding a description of the mod the thread is about is...less than ideal.

I'm confused. If you have a giant nuclear reactor, presumably you need it there because you need large amounts of power. So you'll have a generator for it anyway. Which means you don't need a small radial generator because all you'll be doing is adding to your part count. If you don't need large amounts of power, you could use a small reactor and generator, or beamed power. Or you'd be better off with the RTG or solar power if small amounts of EC is all you need. I'm just not seeing the supposed niche you're trying to fill.

http://forum.kerbalspaceprogram.com/threads/35043-0-21-FusTek-Station-Parts-Expansion-%28R0-03-5a-stable-X0-04-3-DEV-BUILD-via-blog%29 CLS is a dependency for those parts. "Fixing" that (i.e. removing the dependency) would be far and beyond mere config edits. It'd require rewriting the code and recompiling it, at a minimum. Which leads to the conundrum of wanting to use Ship Manifest in conjunction with those parts. If you do, well you're stuck with CLS. Which in-and-of-itself is not a bad thing; I actually rather like the idea of CLS. But not having an override in SM's settings in order to appease "realism purists", who may or may not exist, is what gets me. It's faulty reasoning, which is why I so aggressively addressed it. Especially since SM already contains many elements that such a "realism purist" would consider cheating. Like being able to transfer resources between vessels without a fuel line, or being able to fill or empty crew without using the current game mechanic of EVA'ing the entire crew one at a time. The entire SM mod is a giant convenience package, which is why I find the idea of not implementing a simple flag because it would be a convenience contradictory. The bottom line here is that any "realism purist" playing KSP has to, necessarily, not use the "cheats" already available to them in the Alt-F12 debug menu. If they are capable of that, then there is nothing stopping them from not using a particular function of a mod they installed. That is not a choice that needs to be enforced by mod authors.

I know what the airships do, that's fairly self-explanatory (thankfully) and there are videos but...what do the squid landing gear actually do? Is there a description...anywhere?

Screw realism purists. Being able to change that setting without having to reload the game would be extremely useful for debugging. Instead of saying "Oh, that part isn't passable", flipping a switch and continuing on while noting the part (or possibly parts, because you'd be able to keep testing) and fixing it later, one has to stop the game, fix the problem per-part, restart the game (a lengthy task even if one has an SSD), and then see if the fix worked. We're talking about a pretty basic feature here, like DREC's ability to modify settings in-game. Or EVE's. Or you know, the stock game's. Adding that ability would do no more "damage" or allow for any more "cheating" than hitting alt-F12 does. Realism purists shouldn't be listened to and they shouldn't influence mod development unless your mod is supposed to be a "realism" mod, whatever that means. The whole "your mod not being realistic enough for me means that it's very existence is ruining my fun" is a bogus argument, and has been made ad nauseum with regard to other mods (e.g. MechJeb). Find me a realism purist that even uses this mod and I'll eat my words, but I doubt there is such a person. They'd have to put-up with a lot of cognitive dissonance. "Realistic" gameplay would involve getting an entire team of friends together to plan every mission in pain-staking detail, planing every single maneuver and calculating every little minutiae to make sure it'd work. And then not even simulating a mission in KSP because it doesn't use anything close to a realistic flight model, nor a realistic gravitational one. At this point, I don't know why realism purists would even play KSP at all. Instead it'd be more fun for them, and more productive for us as a society, if they'd just go do these missions for real. It's not all that costly anymore to get into space. Do a lot of fundraising and you might get somewhere. This is a game with little green aliens for goodness' sake. And as for people knowing about CLS integration...they could read. It's in the first post. I mention all this because CLS is currently being used as a dependency for part mods. That being the case, the option here is to either semi-permanently disable CLS integration with SM so that one doesn't run into problems with various mod parts, or not and...run into various problems with mod parts. And then fix them. And restart every time. It's...a bit much, especially if it could be solved with a simple settings menu.

Which requires one to download the pack and read the configs. I don't think it's really all that much to ask that there be some sort of description beyond a short title and name in the first post. There are other mods and plugins guilty of this sure, Modular Fuel Tanks comes to mind, but that doesn't make it any less annoying. Figuring out what a mod is and does shouldn't required downloading or even going so far as installing the mod.

For those of us who do use KSPI, an MM config for the wedge with the Double-C in it that enables the KSPI experiment would be nifty. It might even be possible to just include that as default behaviour if KSPI is installed using a MM config file...though I haven't looked too much at how it parses things. I don't know if you can get the equivalent of an if-then with it. Maybe though.

Uhhhhh...unless I'm mistaken, it already replaces the stock chutes.

Well without any further explanation of exactly what you're doing there's no way anyone could help. If you're using B9 and KW together, you really should at least have Adaptive Memory Management or whatever the hell that's called, and possibly even a texture reduction pack on top of that. But if you actually need to start with a fresh copy of KSP after installing KW (and just installing KW), that can't be fixed by just removing it instead, then you've encountered a severe game-breaking bug and should report it. I highly doubt that's the case, but you haven't given any information to go on. Like Spears, you need to give more information. "Not working" is equivalent to saying, "I have twelve chickens in my kitchen" in terms of utility when trying to offer support.

With Cm being so high, I doubt it'd make a difference; that should be negative, at least if stability is what you're after (it's possible to engineer something that'd be super maneuverable with a positive Cm curve, as long as you have substantial thrust vectoring available). The obvious problem with that SSTO is that the CoL is in front of the CoM, which is going to make it pretty unstable at any speed. Get it behind the CoM (not tooooo far) and it'll work far better. Watch this video:

The file structure for the OS X version of KSP should be exactly the same as the others.

I'm still mad. MAD I SAY. How dare you ruin perfect clicking-work for the rest of us! Or something. Where's the challenge? Or something.