NathanKell

As long as you mention in your docs that RSS is by me, you absolutely don't have to include my readme

Wait what? No, the turbopump is a part of the engine; as the picture I just showed you demonstrates, it's OK to leave it hidden if you aren't up to modeling it right now. What I was saying that you should model are the exhaust pipe (attached to the engine--you know how the LV-T30 and 45 have exhaust pipes? So does the RS-27. You can't just randomly surface-attach an exhaust pipe...), and the two surface-attachable verniers. Those verniers are on the left and right of the enginebell (the turbopump exhaust pipe is above the engine bell)--they're the things that look like the small KSP radials (24-77s) except they have a gray jacket, not orange. I know you will, and I look forward to it. Now, regarding scaling. There are basically three options: mush it to fit Kerbal standard sizes (it will look squished or stretched), make it a uniform downscale of real life (64% of real life size is often used, because the MK1-2 pod is 64% of the width of Apollo, and the Mk1 is 64% of the width of Mercury), or make it true-to-life size. The latter two are preferred for historical replicas, because even if you make it 64% of real life scale, others (who use RSS and need real-size rockets) can scale it back up again without things being distorted. The argument for the first option is that then you can use regular KSP parts with it, seamlessly. Since the core stage is 2.44m in diameter, that's quite close to 2.5m...

Backups? What's in Backups?

Lack: Doing it that way is fine; I needed something to push me to switching to 2.x synatx anyway And I even already have the nodes in my sheet so scaling them will be easy(ish). Thanks! I actually have a whole album of these things (and I'm increasingly using your radial intakes, and rescales of them). Haven't yet given your jets AJE configs though. You wouldn't happen to have AJE configs for the engine would you? And the wheel parts would be great, as you can see my selection was limited!

Ferram, a very good point. It's very tiring to include "not that log, no, your other log" in just about every request, and half the time have to say again (when the wrong log is inevitably posted) "no, not that log..."

Quite right. Derp. You'd want scale = 0.5, 0.5, 0.5 in the MODEL node...rest should be ok though.

Splooshman: Use thermal fins. On the science tab. They cool off your tanks. Also? Welcome to #realspaceproblems ========== Regex, White Owl: Yes, rebuilding the scaledspace meshes is desirable any time radius and/or PQS mods changes. This is because, if you rescale a planet up 6.4x but its max elevation only goes up 1.6x, peaks and valleys will look different. Also, I'm working on a system (like ATM) that caches the rebuilds, so there's only a 20min startup the first time. :]

Lack: ah, that part! Didn't connect its use. And, ooh, purty engine. Very nice! The way you're doing it will mean that engine packs for RF will need to get rewritten, since their rescaling of stock engines depends on the part not using a MODEL node. Then again, the only RF packs that will be rescaling engines will also desire your models, so. Although really we can just use MM2.x functionality (NEEDS etc) to get around this. Also, thought you might enjoy: a few uses of your plane cockpit: The RftS universe version of the Gloster E.28/39 A land-on-the-VAB plane I made for a challenge. Like a Cessna 150 or so, though I called it the Cub.

I do mean the stuff on top of the engine (the turbopump assembly), yeah. Also could use a couple verniers, too (would need to be separate surf-attach parts). And even if the turbopump assembly is hidden (a fine excuse for "not doing it now") it'd still be good if you could do the turbopump exhaust pipe. An image of a model of the bottom of a Delta II:

HAS[@MODULE[ModuleReactionWheel],@MODULE[ModuleCommand]] That will restrict it to command pods / probes only.

...there are TKS parts? I did not notice TKS parts. Which are they?

Bumper-WAC: All-solid, no attitude control (modeled on Lambda):

You need to add references to KSP_Data/Managed/Assembly-CSharp.dll and same/UnityEngine.dll

Anything and everything generates lift, including pods. It all depends on angle of attack.

1. Remove the scale = 0.4, 0.4, 0.4 line 2. add rescaleFactor = 1.0 (place it under scale = 0.5) 3. Multiply the first three numbers of each node_stack or node_attach line by 1.25 (you didn't show what these originally were, so I can't tell you what to change them to).

Since, um, a long time ago, apparently. It's only just come to my attention, and I just noticed it's also affecting the Freyja. Stock unity may be compressing PNGs that don't end in _NRM too; dunno. Anyway, this can be done via entries in the NORMAL_LIST{} node in the ATM config for NP2 so you don't have to rename existing files; I'd just suggest going forward naming things that way. The point is detecting normal maps. Given how ATM works, it needs to know whether a file will be used as a normal map, since Unity stores normal maps internally as RGBA with R=G=B= Y axis color-inverted and A = X axis color-inverted (IIRC). (That's why many parts have those gray rather than purple normal maps btw; they're already in final form). The issue is that due to how ATM caches textures and override's Unity/KSP's normal loading, it needs to know what files should be stored as normal maps and what files shouldn't; if it gets it wrong, then a normal map is compressed (big whoop) but, much more relevant, it's stored in the wrong format and Unity can't use it as a normal map. For example, a DRE shield texture I haven't fixed yet: "GameDatabase: Texture 'DeadlyReentry/Parts/deadlyReentry_1.25Heatshield/model001' requested as normal map but texture is not a normal map and is not readable" This means, of course, that your normal maps won't get used by most people using ATM.

1. remove the scale = blah line IN the MODEL nodes. 2. add a line rescaleFactor = 1.0 3. Multiply each of the first three numbers in each node_whatever line by 1.25 If the rescaleFactor line already exists, instead: 1. remember this value as oldRF 2. set rescaleFactor to 1.0 3. multiply each number in each scale line INSIDE a MODEL node by oldRF (oldRF = 0.5, scale = 2.0, 2.0, 2.0 -> scale = 1.0, 1.0, 1.0) 4. multiply the first three numbers of each node_whatever line by oldRF

Well, here's *why* ATM isn't configured for NP2. It turns out that normals need _NRM (that's with the underscore), and at the end of the filename. So FreyjaNRM.png fails, as would Frejya_NRM_texture.png. Only Frejya_NRM.png will properly be detected. (I got bit too, asked rbray, got clarification).

gleedadswell: you saved it as a file ending in cfg, right? And you don't happen to have extensions turned off, do you? (So you can verify it's named whatever.cfg, not whatever.cfg.txt)?

From the post with the link, it says "download and place in your Real Fuels folder." So download the link (right-click, save as / save link as / save target as / whatever), then move the resultant file to your RF folder.

Change to @PART[Courier?Solid?Rocket] // Courier I SRB (It has spaces originally)

Changelog v6.1 \/ *Fixed only changing things if radius differs *Fixed to work on non-Windows platforms (regex) *Fixed many atmosphere and temperature curves (eggrobin) *Fixed misc typos *Added Moon retexture from SpacedInvader *Added bodyName support *Parsing changes, using stupid_chris's ConfigNodeExtensions *Added KSCSwitcher from regex: can switch KSC to other presets in the Tracking Station *Added many, many launch site configurations (compiled by eggrobin from the work by Captain Party, ferram, and others) *Added new descriptions to all Celestial Bodies, thanks to TheKosmonaut/SpaceAnt *Speedup in timewarpchecker from swamp_ig *Added support for PQS->scaledspace wrapping (for real this time; didn't work before). *Added support for replacing scaledspace meshes with spheres (use this for now, importing is broken) *Added support for compressing normals (defaults to true) EXTRA NOTE This release should work on Macs / OSX out of the box. However, that means it defaults to 4096 textures maximum. Therefore, if you want the 8192x4096 Earth Color texture (as well as the 8192 normal map) you will need to grab it from the OP (or keep your existing one). Also: now includes Module Manager.

It absolutely is, yes. Although IIRC wasn't one of the proposed engines for OXCART originally LH2 and then reconfigured for kero? So maybe not. (The point is that it's nice to be able to model more engine types with fewer parts, basically; and hey, the LR-87 is a nice example of how not-too-hard it is to switch fuel modes for a RL rocket engine.)

Used for RPL.

camlost: re 2, the point that ialdaboath is making is asking whether you can make AJE check that. Let's say I have an engine with Kerosene. AJE should detect the propellant is kerosene, and use kero's fhv. If I switch the propellant to LH2, AJE should detect it's LH2 and use fhv=48900. The use case: adding RF switchable-fuel-mode support to AJE engines.