phoenix_ca

If you mean over-writing the textures...well it's just that easy. Go to the Squad folder and for each part you want to replace textures for, replace them with Proot's. No config-finagling required at that point, although, the process is inherently a very bad idea because of how difficult it would be to reverse it. I'd suggest instead using a Module Manager patch to adjust the configs for them all to point to the default location of Proot's textures, for two reasons. The first is that there's no file management of each part necessary to make it work, and undoing or fixing your changes is easy. The second is that it's much more future-proof. If Squad changes their configs any changes you make won't be overwritten.

Wait a sec. How are you guys planning on dealing with the crossover with TAC for "Oxygen" and "Water" resources? Or will the fuel cells actually just use the same resource and convert it to water which would then be sent to TAC water tanks too anywhere on the ship...or am I missing something. Curse all these resource names. I wish Squad would just publish a standard resource name table we could all work from so everything is agreed on a cross-compatibility is the norm.

It's worth saying. As I laid-out in my posts, it's possible, though unlikely, that he really did mean everything is required for even one bit of the pack to function. Unlikely, and quite apparent to be untrue while looking at the pack, but many people won't be able to do that so it shouldn't be taken for granted (either you're reading it on a mobile phone, or have a slow-as-molasses internet connection, or something else). Proot: I'd suggest just adding a short line after each dependency you list. For example: Instead of just "Environmental Visual Enhancements", say "Environmental Visual Enhancements (Required for planet atmospheres and clouds.)". That gets across useful information, while also implicitly telling people that if they can forgo installing EVE but miss-out on the pretty atmospheres and clouds you add. Edit: You can see this kind of clarity on the ALCOR page. Alexustas lists all the dependencies, but also what part of the mod they are for. A user can then easily infer that not installing say, in this case, ScanSat and ScanSatRPM, would lead to not being able to see maps in IVA. Could still use the pod though. You needn't make a pretty chart. As I said a simple "Required for [feature]" would serve to clear things up.

I dunno. It's got some other merits, like being able to move science experiments around without EVA (seriously that bit I've always found silly). It'd be easier to fix if we knew what was wrong though. What do you mean that the modules aren't recognized? Can you not move crew into or out of them at all, or is it just a CLS thing?

@Biotronic: Good luck. That sounds tricky, not even sure how much support there is for adjusting modules with TweakScale. Obviously it can adjust resources because Gaius uses it for fuel tanks. But if that could work for complex parts, that'd be a huge boon for everyone to reduce part counts.

Install Ubuntu. It's easy. There are piles of guides for it on how to go about partitioning your system drive (it's less scary than it sounds) and installing Ubuntu from a variety of different systems. The tricky bits are in finagling vendor-specific hardware to work (my iMac's backlight isn't adjustable with Ubuntu 14.04 and nothing out there has fixed it), but most of the time things will just work without problem. As for KSP, there's this thread. Be sure to apply the memory-offset fix if using lots of addons is what you're after. Using KSP on linux isn't a smooth ride but it's the only way to get lots of addons without memory errors. Hell, its sometimes the only way to have even a few mods without memory errors. And once you get it, if you're savvy with PCs as you say, it might make you long for the the days Windows actually had a respectable command line.

Manufacturing a straw-man argument is by definition dishonest. Prove to me that you weren't putting words in my mouth and I'll retract the statement. The language being used is English. No offence to non-English speakers but a person's capability in speaking the language is beside the point. I say the same thing to people when I'm speaking French. If I say something wrong in that language, it's wrong. If I meant to say "go over there" and I actually said "go over here", I shouldn't be afforded latitude and it just be assumed that I meant "go over there", others should point out the error and ask, as I did in my initial post. My edit to that post was only an addition, though it was made without me seeing your post in response. Vagaries of the internet, I'm afraid. I have so far only directly argued your comments, so I'm not sure what "others" you are talking about. Again you are manufacturing support for your claims from nothing. My initial post to Proot was questioning, not complaining. And no, not everything is a dependency for the pack. While you are correct in saying that having all of the mods listed are required to use the entire pack, that is still not an argument against providing clearer information in the OP. The OP's wording suggests that in order to use any part of the KSPRC pack, one must have all of the mods listed in the dependency list to work. This leads to logical conclusions of this sort: "In order for the extra Chatterer sounds to work, I must have Environmental Visual Enhancements installed." The reason I bothered asking in the first place is because this conclusion is fallacious. As you said "common sense and even minimal knowledge of mods" is all one needs to determine that. That's why I even bothered asking, on the off-chance that in fact, my conclusion that the OP was wrong was wrong. It's not inconceivable that someone would do such a thorough up-rooting and re-coding of all of those mods and their functions that they really are all required for anything to work right. Highly unlikely, but I've seen it before, hell I've done it before. Asking for more specific information about what is actually meant by "dependency" should in no way have led you to make the assumption that in fact I was saying anything akin to "Proot should assume that people only want parts of his pack and should design around it." Edit: Eh, let's chalk it up to bad cross-cultural communication. Please see my "for the record" part of that post for a better explanation of what I'm trying to get at. @Space_Kraken: You're telling me. But if there's one thing I can't stand, it's someone putting words in my mouth.

Wow. That's just dumb. I guess I'm back sooner than expected. You are an idiot, or at the very least you are straw-manning, hard. On top of that you're assuming things to be true that you cannot reasonably assume. I actually did read through the entire thread, and that post was well in line with what I intended to say. If you wish for me to be more succinct: Stop being an *** and over-reacting to things that no one said. You, Ignath, certainly aren't helping by manufacturing straw man attacks: "Why should Proot assume that you're coming here to only get part of his package?" I never said that. Obscessed never said that. Please, point me to exactly where I said that in my post and I will eat my words. The problem here is that you are responding to something that was never said. You're manufacturing an argument where there is none, and worse still, to distract from what was the real point of my original post. All I was pointing to was that the use of the word dependency seemed wrong in the OP. Proot even went on to (I think), in some way, say that that was true. And yet you continue to harp on something that should be a non-issue, pretending that it was I that made it one. That's just dishonest.

Well ****. Sorry I dared to ask if Proot meant dependency or not. You know Proot, you could easily avoid the question by adding in the "dependency" list a line after each saying "(Required for [feature].)". I don't see how that is deserving of a reaction that seems more suited to if I had asked for you to turn water into wine and feed the world in a day. I won't be coming back here anytime soon. This community is usually pretty clear-headed and friendly, but man, is this thread ever the exception. For the record: you are using the term wrong. A dependency, as used most commonly in English, means something that is absolutely required for any part of what you are talking about to work. Think of say, Minecraft. It is dependant on Java. Without it, no part of Minecraft would work. That's what "dependency" means. What you have are various requirements for particular features. And by using it as you have, you're putting across the notion that using, for example, the planet artwork for EVE is dependent on Chatterer to work. Hence my own confusion. I recognised what you were saying to be very likely false.

Trigonometry? Eugh. You know the math involved in this is pretty heavy. Still. Trig. Ew. Terrible at it, I am. Now, hand me an integral... I appreciate that it's you swimming in the sea of maths to code this beast.

Oooooh. Those are some nice textures tommy. I do believe I'll be replacing mine.

That makes no sense. In fact it rather defies logic. But deleting the settings.cfg did indeed work. Wacky. Now if only I could get my backlight controls to work I'd be golden.

Your memory serves you well. I did search the thread and found that post (you replied to it too), but since I don't use Lazor nor the Mission Controller Extended, I'm at a loss. Part of why I suspect that it's just bad memory management, what with having soooooo many mods. I'll have to see what I can do with it later. If it is bad memory management, reducing the texture quality significantly via in-game settings should solve it. Probably. Or it might not and I might have to go through all my mods, one-by-one again, now actually checking performance in-game. That has to wait though while I try to repair my blasted Win7 partition, which has decided to go kaput with the weird "missing operating system" error. Yeah, right. I BOOTED YOU USING PARALLELS JUST FINE DAMMIT! Edit: Deleting the settings.cfg sounds like a rather strange fix. O.o

Of course now I'm having problems with the camera. It seems specific to some mod or other, because the stock install isn't affected, but the camera lags terribly when I move it around. If I'm honest, it's probably crappy drivers causing it though. Clearly a graphics problem. I wonder if anyone has managed to make KSP work well with lots of mods and an AMD GPU.

Talk to us when you've run a clean install with RC and SDHI to see if it's specific to the mods or not. It's entirely possible that something else is throwing a wrench in things. But people are going to just stop trying to help you if you keep on being belligerent in your posts on these forums. I've seen you post in various other add-on threads, almost consistently in an angry and righteous tone. Eventually, others will catch-on and not bother.

IIRC, no, it doesn't. Edit: That said I could be wrong. There are some things KSPI does in the background and some, very similar things, that it doesn't, like Tritium-to-He3 conversion. The wiki has no info on whether or not ISRU collection can work on a ship that is out-of-focus. @bonesbro: Agreed with your entire post. He-3 collection is just depressingly grindy and painful. Realism be damned. Your ideas for it being a mined resource on certain moons/planets is a pretty great one. He-3 mining is actually a possibility for our own moon, come to think of it. It's far, far, far, far, far from practical at the moment, but who knows, maybe in the future. We need a way of getting large payloads to the moon and back that's way less costly. Maybe a space elevator would fix the issue. ... Okay, I'm on a wild tangent now. IIRC, at some point, Fractal or WaveFunction made mention of it being possible to simply make the parts tweakable, like He-3 and AM tanks. Someone asked about it a few pages back. So it should be possible to make He-3 available in the VAB. Part of the issue there is that career mode is far from done, so the ability to balance that ability with high cost per unit isn't here yet. (He-3 in reality is a spectacularly rare resource. We're actually having serious problems keeping-up with global supply. Not that realism should rule KSP. Ever.) As for harvesting rates on Jool, I think you might have some options there. The atmospheric scoops use the following module: MODULE { name = ISRUScoop scoopair = 0.6 } Increasing the scoopair value would probably increase collection rates quite a bit. The downside is that it would impact them globally for all resources, so common things like oxygen and nitrogen might fill instantaneously. The other, probably far better option, is to adjust the values in /GameData/OpenResourceSystem/PlanetResourceData/atmosphericresourcedefinitions.cfg . See this section: { name = JoolHelium3 guiName = Helium-3 celestialBodyName = Jool abundance = 0.00000137 } The important bit should be obvious, abundance. Increase that number to be in line with deuterium at 0.00003, or perhaps just a smidge below, or increase both. I'd go for both to cut-down on collection times across the board. For mining on planets, you could go the easy route, create a small PNG pure white (well, probably not for balance), add that to Open Resources, define it in /GameData/WarpPlugin%-somethingIcan'trememberrightnow%, and ta-da. Done. Alternately, create your own greyscale maps with say, Gimp.

Releasing a non-evil-persistence-breaking version is generally preferable, I'd say. >.> But you say it'll work on new saves? I want in on that action. I'm starting a new save right about nowish so that'd be great to get my paws on. (Pwetty pwease! I'll give you bug reports! Assuming I find any bugs. Given my luck, I will. Almost definitely.) That's an amazing feature list though. Here's hoping you guys can swing it before you'll be away. If not...leave us the source. Someone might fix it up unofficially. What I really like is that I was totally happy with this mod as-is. And then you go adding features I didn't even know I wanted desperately. Talk about a quality-of-life update.

It's there, but it's disabled by default in the most recent version. Actually that sounds like it might be a bug. That or a mistake with staging. That shouldn't be happening. Buuuuuut you'll need to give more info about the craft and how it's being flown, when you see the message first, etc.

It means the parachutes are armed but they're waiting for you to actually start falling before they deploy.

I'm a little confused about some of the "dependencies". At least, it would seem that some of them are soft dependencies. Like soundtrack editor. Maybe I don't want to mess with the soundtrack at all, so why not just, not install it and the associated files from this mod? Similar goes for Active Texture Management on a Linux 64-bit system. Doesn't seem much point. Dependency means "this will absolutely not work at all without this". Not "A part of this mod/program won't work without this but the rest will work fine." The working makes we a little concerned that there might be really, really, weird hinky stuff going on but I doubt that's the case. ALCOR's "dependency" documentation is clearer.

Oooooh, I'm not joking when it comes to being annoyed with realism-purists, because I haven't seen an argument for realism in KSP that actually stood on its own. Faulty premises abound.

This is pure awesome. Docking should be less boring now.

Oh good. I don't need to shoot you. Or rig a rocket full of depleted uranium to hit your house. Nice. Now I can spend that money on cupcakes. It means that it's fudged. The consumption of out-of-focus craft is calculated for every craft. Once you make it the active vessel again, as I understand it, TAC then takes that info (how long since it was last active) and figures out how many resources should be left. It's essentially playing catch-up when you make the vessel active. It does a decent job of it, so much so that it really shouldn't effect gameplay at all.

What I would give for a stable 64-bit version of KSP. Unity, has been full of much disappoint the past few years. Hopefully that all finally changes this year when Unity 5 is released. The funny thing is though this Linux install of KSP has way fewer weird issues for me now. My Windows install can't actually open the settings menu... >.>

A memory fix in the whatsit of the who now? >.< Yes...clearly I missed...whatever it is you're talking about. Do you mean this stuff in the code box? Edit: Well ****. That fixed it. Thanks for putting up with me Sal. Might I suggest adding to that post some example cases? In this case, I had no idea that the root issue was that memory error, or that that would fix it. For those of us who jump to "This is probably a particular mod crashing this" instead of "This is a segfault in the program itself, log files be damned".