phoenix_ca

As far as I'm aware, nope. Best option would be to use the % operator to ensure that should KSPI stop removing the module, your patch doesn't do anything.

They don't prevent the engines from ever overheating. Even if you have a precooler on every intake, they will explode at sufficiently high speeds. This is why those engines tend to explode as soon as you throttle them up once you start reentering an atmosphere. You're travelling at near-orbital velocities (or even higher depending on where you came from).

Nice. Where is the plain button you're working from?

Well that's confusing naming. O.o

Mainly the slowdowns are caused by having more textures on-screen at a time. That KSP doesn't have asset streaming, and Unity 4 is kinda meh on that front too (Unity 5 promises to be much, much better at managing what is processed based on what can be seen from the camera) doesn't help matters. It's true that there are various AA modes. Super-sampling is usually the worst mode, as effectively all it does is render frames at twice the target resolution and downsize them. It's effective and will antialias everything on screen, but damn do you ever need beefy hardware to back it up. MSAA is perhaps still most common, but that also takes a fair amount of processing power, and the calculations required increase exponentially with the number of samples. AA doesn't really every stop being annoyingly calculation heavy. There are some elegant pieces of engineering like temporal and morphological AA, but those have their own problems, and their own hardware requirements.

Why do the tank definitions have what appear to be useless arrays? Like these three for the Fuselage type: TANK { name = Oxidizer amount = 0.0 maxAmount = 0.0 } TANK { name = MonoPropellant amount = 0.0 maxAmount = 0.0 } TANK { name = XenonGas amount = 0.0 maxAmount = 0.0 utilization = 56.0 note = (pressurized) } Those appear to define fuels, but at the same time limit maxAmount to 0 for them effectively making them unnecessary. Unless I'm missing something here. If I'm right though, then it's just a lot of extraneous text that doesn't need to be there and only serves to make the tank definitions harder to read. Edit: And a short description of the mod and what it does would be nice in the OP. It actually took me a while to figure-out what it is intended to do.

No, Unity does AA on the GPU. AA is an extremely calculation-intensive operation, and doing it on a CPU in real-time isn't feasible (and to my knowledge, never has been). That stuff needs to be done on a GPU.

You do have "Realism mode" unselected, right?

You're right, mostly. The one caveat is that the resource maps can be defined using either a logarithmic scale or an linear one. This shouldn't actually matter for mapping as long as all you plan on doing is using a legend of 0-255. If you wanted to standardize it to some unit, you'll need to grab the scale values from the PLANETARY_RESOURCE_DEFINITION for that resource and do some math on it. This'd actually be great for users trying to figure-out relative abundance between different resources. Also strictly speaking the hot spots aren't triggered by values of 255, but rather by absolute abundance times the displayThreshold value which will mark any spots with abundance higher than the result as hot spots. HOW Fractal visualizes this at all so that he can make passable maps with reasonable scales is beyond me. I imagine a fair amount of math was done. That or a fair bit of tweaking. The benefit of his implementation is that it's very easy to adjust the entire map up or down with a config edit, and in a way that doesn't affect persistence files at all.

Every time I try to look at that post my eyes bleed from the colours. @Obscessed: Perhaps they'd be more interesting as sidegrades, similar to the decision between engines where one chooses either high thrust and low ISP or high ISP and low thrust. Though it's a little hard to think of something you could change that wouldn't end-up simply creating a "this one is better, period" situation which is not desired (this mod's existence is to squish that). Oh wait, no. You could balance that with mass and size. Yeeeeessss. So perhaps you could have an ultra-long range and very effective transmitter, but have the thing be big and heavy. That could work. Realistic? Not really. But more interesting. If you do repurpose a few dishes I hope you'll share them.

nVidia's drivers are above and beyond the average quality of AMD's so no complaining.

Can I call it JebJuniorScript then? HalfBillScript? No I'm not being serious.

I would use it as my forum avatar, but it doesn't compress well. And by that I mean the forum limit is 19.5KB and I need 24KB for the image. To get it any smaller requires pretty extreme resizing (20x20px ) or extreme lossy compression (aka turning it into a smudge). It's probably the gradient...but I like the gradient.

enneract, that would indeed be wonderful. Defining variables and then doing math on them. Though this is seemly become its own scripting language. MMScript? KSPScript? JebScript?

That's pretty much it, though it happens with the Mk1 pod, and it does seem to happen usually when EVA'ing, but rarely, it doesn't. O.o But no, no windows open.

Try to remember that there is a limit to how much can be done. Fairings (not to diminish the work done here, because this mod is awesome) are actually very easy, because they don't vary much in terms of texture or general shape. The shape is much more easily defined by math and logic than an engine would be. It makes sense to define them not in hard-coded terms but in mathematical ones. To define an engine like that, you'd likely find that to get an engine that actually looked the part nicely would take-up just as many resources. Though engine bells might be an easier target, who knows. It's kinda like art though. Vector graphics (which are defined mathematically) are great, until what you actually want is a high-detail photograph. Then raster data wins out. And I'm rambling. Now, engines that maintain their unique models but are tweakable in size (and adjust their thrust and fuel consumption accordingly), that's quite doable. Biotronic has been extending Gaius' TweakScale to do that and more these past few weeks. https://github.com/Biotronic/GoodspeedTweakScale

A highly approve of this. I know my opinion really doesn't matter here, but the thought of tweakable engine sizes makes me giddy.

Clicking a tag again deselects it.

Yep. It's actually quite doubtful that a KSP addon could actually cause your entire system to crash. ...That and if you're running Windows, you should be used to BSODs as a fact of life by now.

Probably not. The spectrometers definitely would stop working if you start eviscerating your KSPI install. The magnetometer has this: MODULE { name = DTMagnetometer animName = deploy } ...which if I'm not mistaken is added by WarpPlugin.dll . If you start pulling out files from KSPI, particularly the plugin itself, there's no guarantee you won't end-up breaking your persistence file, or just leave a bunch of junk data all over it.

Can you say, "overkill"? O.o

Well I listed off all of them. Ore in MKS is exactly the same as in ExPL, so they share that resource. Yes. Honestly at this point, from an end-user perspective, I'd say that if you guys can pull-off mapping for Kethane and ORS resources, it wouldn't matter if those mods had their own mapping systems. ScanSat would be a good enough replacement for the entire thing. ScanSat's already well established too (okay, sorta), so anything done with SS is going to be almost guaranteed to be more refined and feature-complete than anything added by Kethane or ORS.

Oh. Well. I don't. So, I guess the reason I haven't had issues is that I read the first post.

How curious. I've had no problems with Texture Replacer. o.O

Modular Kolonization System adds to Kethane: Minerals, Ore, Substrate, and Water. However, RoverDude has talked about adding support for ORS. (MKS is the only reason I have Kethane installed. If he switched to ORS, or added it as an option, I'd dump it entirely. Then again my reason for that is how painful it is to map for kethane.)