NathanKell

White Owl. Dirt Merchant: apparently that has to be moved to LateUpdate now; see the thread by lttito in dev (and the result on this forum: KTAS finally!)

Since .20 at least? NovaPunch size 4 (5m parts) have always been fine for me with size 4 nodes (which I have edited them to have since I started playing KSP last May, so as to have compatibility with FAR). Node size is just an int. Heck, check out the various part rescales in Realism Overhaul, which often have size 4+ nodes.

ialdabaoth: I gave them that thrust per request, and because they were already the exact mass of the real-life SABRE (though the real-life SABRE is 4.5m in diameter). I need to talk with camlost about how best to handle combined-cycle engines...

http://en.wikipedia.org/wiki/Delta_v_budget

coldblade2000: ksp.log doesn't tell you *what's* causing all that. I need the output_log.txt from KSP/KSP_Data/output_log.txt. Post the *whole* log somewhere. catas4trophy: cool!

Majiir cares if you (a) reuse/modify Kethane assets, or ( reuse/modify Kethane code. Adding converter functionality by Module Manager patch is fine.

Any size node exists (at least up to 20! never had a stage wider than that); however, AFAIK in the new 0.23.5 joint handling, size 4+ gets no special treatment.

Surface attached a rotated gear to the front of the cockpit part such that the bottom of the gear well was above the bottom of the part, then put the nosecone on.

Sure! Sorry, should have just posted this: AFAIK this *should* work... @PART[structuralPanel1] { !mesh MODEL { model = Squad/Parts/Structural/structuralPanel1/model texture = model000, Squad/Parts/Utility/roverBody/model000 texture = model001, Squad/Parts/Utility/roverBody/model001 } } Note you don't need position, rotation, and scale in this case since they default to those values already.

Spanier: Monopropellants are stored under high pressure; you therefore need a tanktype that supports highly-pressurized storage for pressure-fed engines (ServiceModule) rather than a tanktype that stores low-pressure propellants for pump-fed engines (everything else). Since RF works fine with .23.5, and since I've spent the last week or so moving (so many boxes...) I've not felt the urgency to release. Soon Raptor831: thanks! Yeah, since I play with (my own) RftSEngines, you're preaching to the choir here with engine-specific mixture ratios. It's just my assumption is that if you don't want realistic engines, you probably don't want realistic variation in mixture ratios.

First, you need to add !mesh so it doesn't see the old mesh= line but the MODEL node instead Next, since you're adding a MODEL node (and all the things in it), you need to not start with @. @ is for editing existing stuff, not adding new stuff Finally, on the "model = " line you need the full path to the model, sans extension: model = Squad/Parts/Structural/structuralPanel1/model

Aazard: IIRC it doesn't work with FAR, so... Blipser: still lots of random stuff. My suggestion would be to move half your mods out of GameData (well, not arbitrarily half; leave mods in if they're dependencies...) and try KSP. If that works, move some more back in; if it crashes, move more out. catas4trophy: two issues here. First, suborbital ballistic reentries are *very* high-G and thus dangerous for crew. On the shallow suborbital shots used at the start of the Mercury program (only about 180km high) they experienced 11+ Gs. Second, it looks like you're using an extra heat shield on top of the pod; instead, you need the FASA patch from post 2 of this thread, which makes FASA parts fit for RO (and gives pods their appropriate heat shields). One reason why you need that patch--besides getting the right heat shield for Mercury--is that it rescales the pod to be its actual size; stock and non-realism part mods in KSP usually have realistic masses but are much, much smaller than their real life counterparts; this leads to lower drag, a higher ballistic coefficient, and a much worse reentry than in real life. So: Get the realism patch for FASA. Don't use an extra heat shield. And, if at all possible, *Do not* do suborbital reentries; if you must, make them much more shallow.

Aw, thanks so much! Expect it to be prominently featured in RftS, as soon as I make the next chapters.

rbray, as you're messing with terrain shaders, can you add that request of mine a bit back re: city lights, such that there's an option for a day texture as well as a night texture? I.e. instead of making the city lights invisible during the day, make it show a daytime city detail texture instead. It's amazingly immersion-breaking to be flying over NYC and it be all grassland/forests...

Both those sound very useful...

Yes please! Although given what you said the last time I asked, "lazy/get to work" applies to me as well.

A special request: could you do up a RT-10 and a BACC in Soviet green? (Also, if you could remove all ribbing from the normal map for the BACC; I'm pretending they're monobloc not segmented solids...). It's for RftS, where Imperial Russia was big on solids. The KWalike ones are great for the "civilian" versions.

Phredward, very cool! Thanks for these! (And nice album!) I'll stick the shield and port in. Maybe PM SFJackBauer about the CECE? That's (engines) his bailiwick. Blipser: Update Exsurgent Engineering (use the link in the OP) and...well, you're getting errors from Final Frontier. Try updating that, if you don't have the latest version; if you do, let the author know it's casuing a bunch of NREs in EventObserver.Update->FlightGlboas.get_ActiveVessel catas4trophy: sounds like your descents are too steep. From a 300km LEO you want a perigee of >70km, I'd say. Make sure you have one (and only one) Module Manager dll in GameData; make sure you are using the heat shields from RO (or, if using the Mk1 pod, no heatshield since one is built in); follow the instructions in the OP for Deadly Reentry and do NOT edit the settings (RO's heatshields are built for stock DRE settings). After all that if still burning up, picture of your reentry module and post-deorbit burn from map view (final Ap/Pe before atmospheric entry).

When you remove a *node* you need to make it a node. I.e. have {} after it. Otherwise it's just a value, and MM will try to remove the value "RESOURCE[LiquidFuel]"

darkside: I'll see what I can dig up about asteroids. Been busy dealing with aftermath of moving (many boxes, much unpacking, wow!) so I've been operating at slower-than-normal speed. I did verify that all my stuff does at least work in .23.5 so I didn't feel the urgency to roll out an insta-fix. SpacedInvader: Ah, maybe I should back up a bit--and forgive me if this is info that you already know. Celestial bodies other than Jool are rendered in two ways in KSP: via procedural terrain (PQS) when close, and via a static textured mesh (the scaled space mesh) when far away. Jool lacks PQS and has only the static mesh. The static mesh is spherical mesh transformed to fit the planet's terrain and given a diffuse map (the colors) and a normal map (the bumpiness you can see from high orbit). In stock KSP, since the terrain is already known, (and ditto for PlanetFactory IIRC) the meshes are prebuilt to follow the procedural terrain and just loaded as they are; in RSS, each load, I reconfigure the meshes to comport to the PQS. Since these are static meshes with a single texture page each diffuse/normal, so they have a hard limit of 8192 pixels wide for each texture. This means, when you are viewing a CB in scaled space, you literally *cannot* make it less blurry beyond a certain point (well, if you remade the mesh to have *multiple* textures, you could, but 8192x4096 is 32MB of ram each). I do *not*, however, remake the texture on each load (it takes about 40 minutes for my i7 to render an 8192x4096 map of a planet), though RSS can be configured to do that (the Export node in the cfg, when reenabled [i.e. foo removed] will export diffuse and bump maps of the given size for that body). The dynamic terrain is the terrain you can see from very low orbit and from within the atmosphere/on the ground. It is dynamically generated into a sphere subdivided into quadtrees (Planet Quadtree Sphere) and then each vertex (and other things) are modified by all PQSMod components (like a heightmap component, or a simple noise component, or a City component that adds a static mesh...). Once all PQSMods have been applied (in their specified order) the quad can be rendered. here is a previous post of mine detailing PQSmods. If you want to increase the fineness of the terrain (so it doesn't look so flat/angular/low-detail), you can increase maxLevels (it's commented out, IIRC, in v6pre) which will increase the maximum subdivision of the PQS beyond what you have set in Terrain Quality. I run with 14, which means my MET is often yellow but I get very pretty coastlines in Florida. If you want to increase the roughness, your best bet is playing with deformity and frequency of the various PQSMods. So, summary: PQS and its mods is the dynamic terrain (that usually is a heightmap and some noise/fractal-based things to create terrain below the resolution of the heightmap), then the result of that is "rendered" if you will to a mesh and two textures for the static scaled-space object you only see when far away (like, 120km or more--in RSS, 200km or more IIRC) from the body.

Looking very nice in action!

Ferram: can you make the stats toggleable, rather than just removing them? (Apologies if they already are). I *really* like having them, it makes checking for streamlining (and for bugs) much easier. The gear issue...FAR does that for Firespitter landing gear too. I added SurfaceArea=0.001 overrides for them. I think it's the old "look at the size of the object when animation=fully extended" thing that also was a problem with some NovaPunch parachutes. Rottielover: I would love to hear that explanation (I'll give Dirt_Merchant a holler!) since I've been flying sims since before kindergarten (honest! Chuck Yeager's AFT on a Macintosh SE--Dad and I would try to take off in the SR-71 with a trackball and usually fail) and I still don't really grok those stats.

<3 at RT-10. I'll feel so much better about using them now. Can't wait for the BACC!

Isn't it a chicken and egg thing, wherein in order for the plugin that warns about Program Files to warn, it must itself load, which it can't, cuz Windows?

Yup, totally sounds like your write is being clobbered by the internal GUI code's own updates (after all, it, too, has to update the text each frame).