NathanKell

Cool! You'll need to dump the texture that the warp UI is using; you should find it has, presumably, 4 distinct areas (frames) on it. (Unless physical warp and rails warp share the same texture?). Anyway, resize it to have the number of frames you need (and paint the frames as desired), then you'll need to add a piece of code to load that texture and replace the original. Incidentally, that's why RSS just changes warp rates rather than adding new ones: because I didn't want to go through that bother.

KIDS rescales thrust based on what it recorded the engine's thrust at, onstart (before AJE did anything). AKA AJE and KIDS are fighting each other, and KIDS wins.

Also, does Padishar's latest help? http://forum.kerbalspaceprogram.com/threads/72062-Test-of-continuing-KER-developments-0-23-5?p=1160511#post1160511

Ok. Sounds like there's an issue in Padishar's code then. I'll take a look when I have a minute.

No, they really don't mean something entirely different. In fact, they mean the same thing. Let me try again. You get that TANK is a wrapper for RESOURCE, right? It's like a RESOURCE node with some extra information. If you open a saved craft (or your SFS file) you will see all the various TANKs in your tank part, with their correct amounts and maxAmounts. When you edit the TANK in a TANK_DEFINITION, however, you are editing the default values. Then, and only then, can amount and maxAmount do some extra helpful things. But then and always, they correspond (and thus share the name) with those in RESOURCE nodes (that are, in fact, generated from TANK nodes).

Thanks! ...huh. That's weird. It appears to be from native code, as Padishar says. Try disabling VERBOSE_DEBUG_LOG and see if it goes away. It may be that Contains() will print to debug if it fails to find the module. With VERBOSE_DEBUG_LOG, does it disappear? If not, does it disappear when you remove KER?

You can remove it from the component list and then call DestroyImmediate on the reference to it? That's how I destroy PartResource components in RealFuels, and it does seem to actually kill them. Oh, don't worry about the above stuff until you have your shaders done, I'd say; it was just "easy stuff you can paste in hopefully" that I wasn't sure I'd mentioned. For blending...actually, here's another suggestion. I first saw this a long time ago (the early days of Morrowind modding IIRC), using textures' alpha channels to blend between them on boundaries. So with your landclasses, assuming you have fewer than 2^16 landclasses, you could use only some distinct shades for landclasses and declare the inbetween shades (which would result due to texture filtering) as blend landclasses; the shader would render from both landclass textures, blending based on their alpha channels. I'm not sure of the mechanics of detecting the gradient (i.e. which way, on the quad, is "towards landclass x" and which "towards landclass y") but it's worth thinking about. That would, obviously, lose using the alpha for lights, but it might be worth the tradeoff.

For ion engines, you might like HoneyFox's Orbit Manipulator: it supports on-rails ion thrust.

JewelShisen: do you mean graphically or cfg-wise? Graphically, it's just a standard part. You can use an animation if you like if you want an inflatable shield. CFG-wise, you can copy the code from an existing shield. Due to how KSP handles heat (it stores and adds/removes temperature, not heat) the loss rate should scale linearly with the amount of shielding (which should scale at roughly the square of the diameter), and dissipation should scale inversely with loss rate (so loss * dissipation = a constant). Starwaster: that sounds like the right vector, yeah. IIRC the Mk1 cockpit has that direction.

I don't touch cameras at all. Maybe KSP/Unity auto-sets clip planes? Although it's odd that it affects only water, not land. The only possibly-related things I do are: *Set atmosphereDepth in PQSMod_AerialPerspectiveMaterial (a KerbinOcean PQSMod) to 7500 (from 5000), following the change in scaleHeight. Though I'm not sure what this does, exactly. *Set atmosphereDepth in PQSMod_AltitudeAlpha (a Kerbin PQSMod) to 6000 (from 4000), ditto as above. Regarding atmosphere: as I think (hope?) I mentioned, feel free to just rip out the AtmosphereFromGround section from RSS; we even both use confignodes for it. You might also want to support replacing atmosphere ramps (you can see how it's done in the Alternis Kerbol source). I keep meaning to add that to RSS, but it's much more your department. Finally, regarding cities: I have to say I agree with Hyomoto here, and I'm coming around to your idea of using alpha for city lights (to avoid having duplicate textures). I'd much rather deal with orange/yellow-only city lights (with perhaps some shader-supplied color variation) and have two different city textures, than only one day and one night one. Therefore I suggest rather than having "city" and "landclass," you just have various levels of urbanness *as* landclasses. That would still limit us to only one type of texture per 4.9x4.9km square (well, a smaller square than that on Kerbin; I'm talking Earth) but that should be decent.

Thank you so much for scaling nodes by dividing by the large diameter step, not by a hardcoded 1.25!

frisch: at one point Nertea was going to RO-ize the ion engines; I gather Nertea's been busy since. I don't know much at all about high-end stuff, so if someone would volunteer, that'd be awesome. I certainly have no problem including near-future stuff in RO. AndreyATGB: thanks! Will include.

Interestingly, when I gave the engines their prop radius in feet, performance became much closer to what I expected. So I think it should be given in feet, and just a few of your entries had the radius specified in meters by mistake. However, there does remain clearly something wrong in the engine modeling (either the model or the stats fed to it), since, for example, the R-1830 Twin Wasp develops 0kN of thrust above 260mph at sea level, despite the F4F-3 Wildcat, which used it, having a maximum speed at sea level of 270mph (and lord knows the Wildcat was a tub, so you'd need a fair amount of thrust to overcome drag...). It's not something that can be fixed by futzing with drag, since even with 0 drag, at 0kN thrust you're not going to go faster... (It took a much cleaner and ~400kg lighter aircraft than the Wildcat to get to about 240mph at sea level; I verified the 0-thrust thing by climbing then diving to get to about 400mph level, and seeing when thrust went above 0.) At any rate, the issue seems *very* [inversely] proportional to air density, since as I mentioned at high altitude engines might even over-perform.

Zyglrox: I'm going to need the actual output_log.txt (or player.log if non-Windows); that just tells me errors are occurring, not the stack trace or the context.

phoenix_ca: those are *default values*. Each TANK, because it is essentially a wrapper for a RESOURCE, has an amount and a maxAmount. You know RESOURCE nodes in part cfgs have amount and maxAmount values? Well, so do TANKs, because TANKs are wrappers for RESOURCEs. While the various other values in the TANK are permanent, amount and maxAmount are merely the default values used when converting the TANK to a RESOURCE. You can make them whatever you like ingame. I don't get why you think this is arbitrary: you have to think of a TANK as, essentially, a wrapper for the RESOURCE node in a cfg.

RSS does actually support doing this; that's all the (commented out) bodyName = whatever lines in the cfg. They're commented out because, yeah, science, but also because for example EVE relies on bodies retaining their names and CB name matching scaledspace transform name. There's also the question of PQS name. On the whole I've held off digging too deeply because so much is actually tied to the CB's name (other mods, sure, but also I fear some internal stuff). However, very little depends on the Sun itself (and by the time this mod fires, anything referencing it will have a pointer, not a string, referring to it anyway), so this usage should be ok, other than science obviously.

In a TANK node, amount and maxAmount control, respectively, the default amount and maxAmount of the resource in the tank. They are given as they are to correspond *exactly* with the amount and maxAmount in the RESOURCE node that MFT will create from the TANK entry. However, so as to support proportional amounts, MFT will allow you to specify a percentage in the maxAmount field. Instead of specifying an maxAmount for that RESOURCE in units, it will specify it as a proportion of the total volume available in the part. Further, due to this added support, amount behaves somewhat differently than in a RESOURCE node. Instead of requiring you to specify exactly the number of units the RESOURCE will have, it instead is read as a portion of maxAmount. amount = 1.0 (or amount = full) means that the RESOURCE's amount will be set equal to its maxAmount. At 0.5, it will be half full; etc.

Also: I note that your prop radius (r0) for the BMW engines and for the Packard V1650 is only 1.75ft. Are you sure that's not meters and lacking a conversion? Especially since that's exactly correct for the BMW engine's FW-190 prop radius in meters...

The screenshot was chosen somewhat poorly, as I get the same issue at about 270mph with that engine. Further, while planes made entirely to spec perform as they should or perhaps slightly better at high altitude (meaning the turbosupercharger modeling at least is working fine!) they uniformly underperform at sea level, by about 50-100mph.

Liking the new stuff, *especially* the cities on the scaled-space texture. So awesome! Having a water issue though, presumably to do with near camera clipping? The nearest water quad isn't shown at all, apparently. Also, am I correct that there are still no clouds in scaledspace, or is that an RSS issue only?

I do SetConfiguration both OnLoad and OnStart, to be sure to catch cases where only one and not the other is called. The tweaking is supposed to be non-persistent, is it? Otherwise you should just change the confignode.

So...I think something's wrong here, perhaps? Should I really be getting 0 thrust here?

All Kido Butai carriers, yes.

Yep, some engines have multiple ignitions based on TL: in a CONFIG block, a negative number means "TL-this = ignitions" and 0 means infinite (Note that this is the opposite of Engine Ignitor itself, where -1 = infinite). Your best bet is to check out Calcs.xls (link in 2nd post in RF thread) which is what I generate RftS from. The first (docs) page explains what stuff in the ignitions column means. For orbital maneuvering systems like SPS, I tend to give them infinite ignitions because while in practice you probably couldn't ignite SPS more than, say, 50? times without risking a failure, you'd be out of propellant before then anyway.

This is actually supremely important for RSS, since ideally RSS would have 3x8192 per body.