phoenix_ca

My bad, yes setting DepositCount to 0 would do. But honestly, I don't view that as worth the effort. I'd go with ORS simply because it offers more control. You can, for example, create a water map for Minmus so that water is only available in its flats. On top of that it supports atmospheric and oceanic resources. In other words, ORS already supports what you requested in the link, and more.

So I guessed right. Yay me I guess. To be honest, my head starts to hurt when I look at aerodynamic calculations too hard. More than it gets when doing orbital mechanics. Rocket science strikes me as rather simple compared to...that.

http://forum.kerbalspaceprogram.com/threads/73236-WIP-Loading-textures-only-as-required

You have the resourceName in your definition set as "Minerals", when the name clearly says "Substrate", for one. Confusing, but if the scanner works. *ponders*

MKS has a water-on-every-planet approach right now, but that can't be helped as it's part of Kethane. RoverDude is working on ORS support which will give him the option to simply not have water on certain planets, as it already does. ORS' distribution of resources tends to make much more sense than Kethane's. Edit: DAMN YOU ROVERDUDE! I got ninja'd. As for changing LqdWater to Water and back, that's easy. Just use an MM config like so: @PART[TacWaterPurifier]{ MODULE { name = TacGenericConverter converterName = ISRU Water Filter // Number of units to convert per day (24 hours) conversionRate = 2160 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = LqdWater, 1.8, ElectricCharge, 20 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Water, 1, false } } @PART[TacWaterPurifierLarge] { MODULE { name = TacGenericConverter converterName = ISRU Water Filter // Number of units to convert per day (24 hours) conversionRate = 2880 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = LqdWater, 1.8, ElectricCharge, 20 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Water, 1, false } } @PART[TacCarbonExtractor] { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer In // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxidizer, 1 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxygen, 11.65, false } } { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer Out // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxygen, 11.65 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxidizer, 1, false } } @PART[TacCarbonExtractorLarge] { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer In // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxidizer, 1 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxygen, 11.65, false } } { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer Out // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxygen, 11.65 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxidizer, 1, false } } Then you can use the TAC Recyclers to convert KSPI's LqdWater to Water and Oxidizer to Oxygen and back.

That's a much cooler answer. I like.

I'd assume that is an approximation of the vortices that are created at a wing tip. But that's just a guess.

As a general rule, unparking cores is dubious at best. Usually CPU cores aren't parked anyway so it's a non-issue. I highly suspect your "FPS increase" was caused by other factors. Every rigorous test I've seen on the issue has come-out in the "doesn't do anything useful" category. As for loads on cores seeming equal, are you sure that's what you're seeing? It seems highly unlikely for KSP. It's possible its simply switching the thread between them very quickly, which is entirely normal. An H100i pales in comparison to the thermal performance of a custom loop that's properly constructed. Those all-in-one units are good for noise reduction, but not if what you want is good heat dissipation. If that's what you're after then money is better spent on a more expensive but complete cooling system (preferably with the highest flow rate you can muster...biiiiiiig pumps are good). Yes, the best option is to wait. This should be fixed by this year's end (finally). That, or you could try cooling with liquid nitrogen or liquid helium. I mean, that's pretty esoteric, and extremely expensive, but hey, it's possible. And you could run KSP for a few hours smooth as silk.

So, no point in me publishing complete tables for the entire Kerbol system? Because I was contemplating doing just that using your code. It's quite handy but...annoying to use. And there's a lot of setup involved with getting Octave to work on OS X (have to compile Fink from source now, as it turns out...I miss the days of having a binary installer for that ; doing that requires XCode which is a 2GB download). (Edit: Or I could read more and find-out that Octave itself has an installer for OS X.)

It would be nice to see in the base game, certainly, if only to significantly reduce part bloat. Why have three different parts with the same model when you can have one that is tweakable to have the functionality (and even textures) of all the originals? Until then, have you seen the Modular Fuel Tanks mod? That might be what you're looking for. However, there hasn't been any widespread adoption of it by modders, unlike Module Manager, for example.

I'm pretty sure Procedural Fairings added just such a device (called a "thrust plate" or something like that) in it's recent 3.0 update.

It's certainly an annoyance. Until then, are you aware that there is a way to work around the problem? Get the camera into a position side-on to the node, and then grab the part you want to attach, and hover the cursor close to the part you want to connect to but not touching it. The game will automatically snap the part to a node-to-node connection.

*groan* Let's hope Unity 5 has greener pastures this year and Squad embraces it completely.

If Squad wasted time making weapons in KSP, I would decimate the KSC with them and then remove all of those parts before playing again.

Yes, but you can safely assume there is a lot of programming awesome going into intelligently determining when and where those calculations need to be done. I highly doubt that the lowest engine of a rocket is doing any collision detection with the top part, unless they actually get in proximity to each other.

Nope, and there are other mods that add that. Starting to shape up to a LOT of other mods adding that. KSPI (via ORS and with a bit of MM tweaking for compatibility), Asteroid Cities, Hollow Asteroids, Modular Kolonization System...the list isn't getting any shorter. Just pick one.

Not true. Several things it did were rendered redundant, yes, and those parts were set to be disabled by default. But things like the ramping of physics on load are still relevant. Update it, sure, but getting rid of it entirely is rather hasty. It still has its use in preventing Kraken strikes.

Nope, you're going to have to fiddle with individual PART arrays yourself. Unless I'm completely mistaken. I could always be completely mistaken.

Oh hoh hoh! Well aren't we special!

It's pretty clear that Unity (or maybe it's PhysX, what do I know), or at least KSP does have that kind of optimization, given the massive slow-downs when you crash a vessel into something. It's fairly clear that it went from a state of not doing many calculations to suddenly having to do ALL THE CALCULATIONS. To the OP: Given your specs, you only have two, maybe three options to get any improved performance that doesn't involve removing a lot of parts (which, for the love of god, at 1,400 parts in a scene you really should anyway). One is to wait for Unity 5 to be released and Squad to update KSP to it. Unity 5 will come with the PhysX 3.3 SDK which means multithreaded physics support, which means huge potential performance gains for people using multi-core processors. With Unity 4, physics is stuck on a single thread, and a 32-bit one at that. With KSP being such a physics-heavy game, this bottleneck eclipses everything else that the game is doing. The increase to 64-bit instructions probably won't give all that much of a performance boost but it will solve some issues. The second is to upgrade your processor. Usually an i5 is perfectly fine for gaming. In this case though, getting the absolute maximum performance out of the single CPU core being used is essential. An i7 might increase performance, very slightly. Really only an option if you have lots of money to throw away on something that isn't a sure bet. It's possible you'd get a lesser performing chip that can't overclock nearly as much as your current i5. I'm only mentioning this because the i7 series processors are all built for higher clock speeds than the i5 processors. (Also, unparking cores really doesn't do anything other than waste power. The internal control on Intel's chips is actually amazing.) The third option, if you haven't already, is to build an appropriate custom liquid cooling system. Lots of rads, lots of fans, total overkill, and then see if you can eke-out a few more hundred MHz from the CPU. That's a similarly large undertaking that may have absolutely no payoff in terms of making KSP run any faster. Edit: Fourth option is a work-around. You could use Time Control to slow the game clock down so that you can maintain a usable frame rate. Doing so will make movement look kinda choppy, but the point is that you can actually control the game.

That's certainly the main problem with it. While I really like that parts get unlocked progressively, the science collection feels very much like a memorpeger (MMORPG), and that's a horrible way to do things, especially in a single-player game. I'm actually using MM right now to change that, so that all experiments give 100% of their scienceCap on their first use (seriously just clicking, transmitting, repeating, and then doing a return anyway is boring), and they either transmit 100%, or they require a sample return. It makes things more interesting, since there's an actual decision to be made when constructing a probe, instead of just spamming all the things.

I'll take a look. Woot.

Sooo, unfortunately, :HAS doesn't work inside the @PART {} . Trying to use it to adjust only certain modules of the same type based on a parameter inside it: @PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[temperatureScan]]]:FINAL { @MODULE[ModuleScienceExperiment]:HAS[#experimentID[temperatureScan]] { @xmitDataScalar = 1.0 } } @PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[barometerScan]]]:FINAL { @MODULE[ModuleScienceExperiment]:HAS[#experimentID[barometerScan]] { @xmitDataScalar = 1.0 } } @PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[seismicScan]]]:FINAL { @MODULE[ModuleScienceExperiment]:HAS[#experimentID[seismicScan]] { @xmitDataScalar = 1.0 } } @PART[*]:HAS[@MODULE[ModuleScienceExperiment]:HAS[#experimentID[gravityScan]]]:FINAL { @MODULE[ModuleScienceExperiment]:HAS[#experimentID[gravityScan]] { @xmitDataScalar = 1.0 } } While that works perfectly for the parts with only one ModuleScienceExperiment module, it falls apart on parts that have multiple one with different experimentIDs. Changes will only be applied to the first one. Which is unfortunate because now I need to do it on a part-by-part basis. >.< Edit: Node indexes start at 1, not 0, right?

Sigh. I don't see what the problem is with paying for content added. The people at Squad need to eat, you know. As for planes. Well, not likely. The game is very much about space exploration. You can already make planes, yes, but I doubt that'd become the focus of KSP...well ever. If you want plane parts, there are lots of mods for that.

It would be a nice way to ditch some part spammyness. One part for each shape, any texture you want. That'd be swell.