NathanKell

Yeah, them's good catches. When I checked the RO pod patches, I didn't see any LS patches in there, and I didn't connect that the reason for that was that ECLSS (and TACLS) add it themselves...and that by changing usage rates, the provided quantity would be wrong. Hattivat: nope, that's because the Russians, rather than providing ullage motors to their stages, hot-stage them. That means literally lighting the next stage before the previous one burns out and is decoupled. Hence the mesh, so the exhaust can escape. Note that the Titan I and II (maybe later too?) did this too: you can see the gaps here in the interstage

Yes, one mod has to add special handling for the other. Or, they have to recognize when they are being loaded (vs. edited) and not touch positions in only that case. That could also work, I think.

Have a problem? Check the FAQ. If that fails, logs.

Excellent stuff! Quick question about the city textures--I love the new lights, but I'm wondering if you also changed the daytime textures to match? As the existing lights, poor as they were, I at least made sure had the virtue of perfectly matching the daytime texture. Also--the sharp transition. The new RSS didn't help at all?

Both mods modify the position of the tweakscaled part. Sounds like one is doing it before the other resizes, thus the movement is incorrect.

RO includes a tweak to the old 2.x PFairing mass; it may be that the syntax changed for 3.x; I'll check. But the deeper problem is that interstages / fairing bases have a cube-of-radius mass, not any lesser power, which means that mass will scale with the cube of the radius. So while a 5m diameter (2.5m radius) interstage might mass 6.25t, a 10m diameter one would mass 25t. Note that the 12 tons that's been bandied about isn't totally out of line, however; the N-1 interstage between the first and second stages massed 13 tons! Also, what is this about 5m limits? I thought I added a patch to RO to remove that limit. I'll check.

Kitspace: in addition to what jrandom said, a higher ballistic coefficient (mass divided by wetted area, i.e. surface area hit by oncoming air) means that when you do start decelerating rapidly upon hitting the lower atmosphere, while you won't suffer the heat for very long, the heating will be very severe, in contrast to the slower, more measured heating you would receive in the upper atmosphere with a lower BC. In other words, your shielding might not be able to keep up, you'd be heating up too fast. That's in addition to the crushing G forces already mentioned, of course. It's one of the problems of spaceflight (and, actually, one of the few good arguments for winged crew launch vehicles) that an abort mid-ascent will lead to a suborbital reentry, and suborbital reentries are super dangerous. Your best bet once you pass a certain point on your ascent will be an abort to orbit rather than an abort to reentry. Your magic ascent path that always allows "cut the engines and the crew will be fine" may well not exist for some (most) LVs. sebi.zzr: link fixed.

Kitspace: the stock resources are not hidden because, given how modded KSP is, not all parts will ever be converted to RF standards; therefore you can still add the stock resources to RF tanks if necessary. No idea why the real ones are consumed "faster"--You can check the Isp of the RCS thruster under each configuration; the one with the highest Isp will consume the least mass per second of firing. Note I say mass though--maybe you're confused because the real propellants are less dense than MonoPropellant and thus the consumption per liter is higher? (Err, Starwaster said this too.) SpacedInvader: Good point. RO will need to rewrite its patches to account for RF tank presence. ThorBeorn: On the problem craft: 1. backup the .craft. 2. Open the craft ingame. 3. Save the craft. 4. Load the craft again. 5. Check if problem persists. If so, log pls. And thanks!

Is mass still the cube rather than the square (or 2.5 power) of the radius? It'd take a bit of research to figure how interstages actually scale...while the skirting themselves are obviously based on the surface area, the framing...dunno. Also, the N1's first-second stage interstage massed 13 tons btw. (And that was what, 8m diameter?)

In the Dark Ages, you had to symlink. Nowadays the steam client lets you do it itself, as Agathorn says. There are still some advantages to the other approach, however, as it lets you seamlessly move a game from a spindle drive to and SSD and back again, say, depending on your judgment of how frequently you play it. RedAV8R: You might want to extend this FAQ here? Or if not make a FAQ on the RO wiki?

I do mean to do that, yeah. But it'll take a bit of finagling.

This is due to an issue in .23+ where any resource request smaller than 1-e5 per tick for an ALL_VESSEL resource (like IntakeAir or ElectricCharger) will auto-fail, even if the resource is available. And since there are many ticks per second...

Yep! Excellent idea. Although I think you're better off welding it to the decoupler, so when you decouple the SM, the umbilical detaches.

Not odd if you actually read the posts above yours.

They're tangents. Here's how they're used. http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html

Yeah. You might even be able to get by without RSS-class heat shields, since DRE at stock settings is so weak on Kerbin. If not, slowly decrease the HeatMultiplier until shielded parts just barely survive reentry. (Probably best to test at interplanetary speed, since if you just survive reentry from LKO interplanetary or munar reentry will not work.)

griffin247: for the love of Pete, don't double post like that! Also, since RSS has nothing to do with FASA, it's not relevant here. Also also, I already answered your question on the other thread you posted it on. Unless you posted it on a third thread or something.

I use a hacked-together "super-OBJ" format that includes tangent info too. So while you can import it into a 3d package, what you export won't be usable. When wrap = false it will, indeed, not wrap things, i.e. use the original scaledspace mesh. Gilly, like Minmus, doesn't have a heightmap. It just has a pair of noise mods that tweak vertex height (one directly, and one that provides better slopes). When I get done dealing with impending .24 I'll get back to working on the mod adder-loader-remover so a heightmap can be added.

griffin247: make sure you have the latest RO and the latest FASA. tmikesecrist13: discussed on RO thread.

The calculator does not care about heat. If using BTSM, ask in the BTSM thread; BTSM has its own customized settings.

They got deprecated, but since AFAIK tweakscale doesn't play nice with them (since they (a) use ModuleRCSFX and ( have RF engine configs) they shouldn't be IMO.

Open the RealTankTypes.cfg file in RealFuels/Resources. It shows, for each fuel type in each tank, what the boiloff base rate (loss rate) is. It also shows the desired temperature. The actual rate of boiloff is (current_temperature - desired_temperature) * lossrate * tank_max_amount units per second.

Whoops, missed these! Makeone: 1. Why oh why is the RL-10 so BIG? It's so much bigger than the XLR11 but produces the same thrust! Here's why. 2. The LR-21 is the Mini Orbital Bertha from FASA. 3. No idea. Pics? 4. Yes, really. Consider this, then realize (a) it's 1948 and ( it's 2.3x as heavy as Saturn V. Of course, it only would have put 25t in orbit. We could have made ICBMs in 1945. They wouldn't have been accurate, and it would have been Manhattan-Project hard, but we totally could have done it. 5. This is true. Ask dtobi to allow individual rotation of thrust transforms. ThorBeorn: responded elsewhere, but just for completeness: my apologies on being so slow in getting them up on git! I ended up going a slightly different route than you...

A decent hack that Taverius came up with is: if the engine doesn't have symmetry counterparts, default roll to off.

1. On scaling Three things affect scale. First, does the part use MODEL nodes? Skip to part B. A (MODEL node not used; instead "mesh = blah" used) 1. "scale = foo" determines how the first three numbers for each attach node line (the X, Y, Z coords of the node) are scaled. It does *not* affect anything else. Default = 1.0 if not present 2. "rescaleFactor = bar" scales both the model (and its transforms) *and* the attach nodes. Default = 1.25 if not present. B (MODEL node(s) used) 1. Inside the MODEL node, "scale = blahX, blahY, blahZ" determines the scaling of the model and its transforms. Default is 1.0, 1.0, 1.0. It does not affect node positions. 2. Outside the MODEL node, "scale = foo" works as above. 3. Outside the MODEL node, rescaleFactor works as above. HOWEVER, there is a bug in scaling. For parts with MODEL nodes, rescaleFactor is applied twice to the mu, *unless* (a) the part is the root part of the vessel and ( you've reverted to launch (or perhaps switched in flight? Don't recall). All other times, it is applied twice. What this means is that if you have scale = 1.0, 1.0, 1.0 in the MODEL node (or no scale at all), and rescaleFactor = 1.25, then your mesh will actually be 1.5625 as big, but your nodes will be scaled outwards 1.25. For this reason, when scaling parts using MODEL nodes, it is suggested to leave scale (outside the MODEL node) and rescaleFactor both at 1.0, and instead both change the scale = x, y, z inside the MODEL node and manually scale the positions of the attach nodes. 2. On diameters. Engine diameter is kinda meaningless except for those engines that have a tank butt attached to them. (Those big flat or dome-like things at the top of engines? Ain't engines. They're the bottoms of the tanks. Stupid modders following a stupid KSP convention of adding tank butts to engines.) Node size, however, is important. The 7th number in a node_foo = x, y, z, vx, vy, vz, SIZE define (add it if not there) is the node size. In RO, 0 means 0.5m, 1 = 1m, and up from there. Set it to the approximate diameter of the part, so if the engine is approximately 3m in diameter, use 3. Rounding normally should be fine. I wouldn't round >4.5 down to 4 though (and the like, i.e. flooring), since that will make connections weaker than they should be, and make FAR not handle open nodes correctly. Although as RedAV8R's contrary position points out ( ) it's kind of arbitrary where you do the rounding, since FAR's gonna be wrong some of the time no matter how you slice it. Node size, however, has absolutely nothing to do with where a part is positioned or the part's size; it's merely a number KSP uses to (a) draw the green node bubble and ( determine joint strength.