NathanKell

Your velocity at geostationary level is very low, comparatively, so plane change burns are cheap, and even cheaper if you do it in combination with your apogee kick burn to circularize. (BTW for some reason it's "injection" for the transfer and "insertion" for when you get there, i.e. GTO injection / GEO insertion, or trans-lunar injection / lunar orbit insertion.) See http://en.wikipedia.org/wiki/Geostationary_transfer_orbit for a good description of the apogee kick maneuver. In fact, for a 40degree+ inclination, you might be best served by a bi-elliptic transfer, like they fly for GEO Proton missions, where you fly into a super-synchronous transfer (like 50,000+km apogee) to get the apogee velocity really low for a cheap plane change, then circularize on the fall back towards perigee.

AbeS: Ah. Thanks! Captain Party: Is that a pic of Woomera, using what I suggested? Wallenberg: Ah, well. I'll Have to lower it then. repositionRadiusOffset does different things depending on whether repositionToSphereSurface is true or false. If false, it's an offset from sea level. If true, it's an offset from the terrain at that spot.

Afraid you are mixing things up--not even KJR uses node size for joint strength (I just checked the source to be sure). It's just FAR that uses it for drag.

Captain Sierra: use KIDS instead of Arcturus for that.

Looking sharp!

tygoo7: follow the instructions I posted for Captain Party here: http://forum.kerbalspaceprogram.com/showthread.php?p=938922#post938922 Captain Party: Uh, sorry, dark. What's the matter? Wallenberg: Thanks! It's hopefully *not* a coincidence--I've been trying hard to match real-world terrain heights.

The probe core in RO is the WAC Corporal nose. The only Explorer core out so far is from FASA, as MedievalNerd says, and RPL doesn't support it yet. You can use RSS to change the body science multipliers... Regarding HTP: Bug. I somehow managed to remove it from default tanks. It'll be fixed ASAP. One of the warheads is from FASA; the rest are from the RftS Pack. They're stuff I made for my mission reports thread. That's why it's called RftS Pack.

Jemtan123, Boomerang: are you playing career or sandbox? Did you install _exactly_ as specified in the readme, not changing directory names or anything? The 2.5m shield has an mbm rather than PNGs because...that's the way nhnifong decided to export textures. And it does not have duplicate top and bottom nodes, it has a pair commented out as well as the actual pair. Given that it is the only shield that uses a MODEL node, it will be the only shield affected by your not installing DRE in the right folder. So that's my guess as to what's going on: you renamed the DRE folder you extracted, or placed it inside another folder, or used that part sorting app that changes folder names, or something. Aknar: the cased/uncased distinction for solar panels shouldn't (AIUI) affect when the break if you specify windResistance. I've considered adding RT2's "MaxQ" functionality, yes. a__gun: Maybe the way generic animations are handled has changed? For now you can just remove the two Animation2Value modules from your patch.

EDIT: Ninja'd by Nazari with a working cfg. MeCripp: Uh, no, no you can't. That's not even in module manager syntax (<> ????), and if it were (@MODULE[ModuleEngines] { @name = ModuleEnginesFX } it wouldn't do what you want. What you want, as I said in the original quoted post, is to update the DeadlyReentry patch file to notice the engines whose modules have been changed, not to change modules itself.

If you remove the toolbar, FAR will no longer work, since it references the dll, IIRC.

Dragon01: whose J-2? SFJackBauer's RealEngines don't come with EI configs yet. If you're getting EI modules while using RealEngines, you didn't follow install instructions.

Captain Party: Yes. Open RemoteTech2_settings.cfg. Note the new groundstations node. Copy the mission control node, change its name to something else, change its location you now have two ground stations.

Given that Ares I failed in real life, it's only realistic if the SRB knocks you apart ingame. :]

It scales the positions in the cfg but doesn't touch the mesh and its transforms. Since physics depends on having joints near the end of the collision mesh, when you move the node away you get weirdness.

I think what was meant was just the 5x engine mount, without the tank above. Like the Nova punch 5x Bearcat but with no engines, just mount points. Which you can do by just using the bottom fifth or so of your S-IC

Snjo, apologies if this has been asked before--how come so many of your parts are Module = Strut? That means they're massless and physicless, as far as I understand it...

As long as those cfgs are somewhere in GameData they should get loaded. You do have ModuleManager in the root of GameData, right? It comes with DRE. To verify that the fix is working, check the mass of the 2.5m pod heat shield. It should be 1.061 tons, not 1.06 tons. That said--if your old version of DRE was new enough to have a shockwave exponent, then you can just use your old doctored parts instead. I haven't changed the parts in a while.

Congratulations!

rbray89: a near-term suggestion. Could you add an option for citylights to, rather than fade out when light, be replaced by a different detail texture? That would at least give us a city texture during the day, even if no 3D buildings. It would be especially useful for RSS, where it's *super* freaky to fly over a recognizable NYC and see no city there.

Yes, it does. Aknar: can't add to other parts since, err, other parts aren't solar panels with the solar panel module. Note that the part doesn't sheer off, just the solar cells break.

Yes. Also, no idea about clamps yet, other than what I assume is going on is that we're now on the "graphical surface is lower than actual groundheight" part of the world rather than "graphical surface is higher than actual groundheight" part we were on before. My usual 2D analogy. Think of a circle. Now approximate it with a polygon. The vertices will be outside the circle, and the sides will spend part of their time inside the circle. Only at very few points will the circle and the polygon intersect. That's what's happening here. The real ground height is the circle, but since PQS is obviously inexact, the polygon is the mesh you see. Since the planet is so much bigger, but resolution is not much better, you get more difference between groundheight and visuals.

Aknar: As I said, Kerbin just isn't that dangerous unless you make the heating unrealistic. Change that shockwave parameter (as it says in the OP). a_gun: here's the annotated MM patch @maxTemp = 1700 // what is the max temp that part can stand. MODULE { name = ModuleHeatShield // add a heat shield direction = 0, 0, 0 // all directions (NOTE: in form of a vector3, x, y, z. So 0, -1, 0 = shielded from below (like a pod). 0, 0, 0 = omnidirectional reflective = 0.25 // 25% of heat is ignored when closed adjustCollider = 0.25 // the attachNode is kinda funky. // play with that value until the closed port properly shields things, but NOT itself. } // these two modules change values based on the state of the part's animation. Assuming that part starts closed, these work. If not, if the port starts open, for the first number after each key =, use 1-that. So change it to key = 1, key = 0.9, key = 0 if they start open MODULE { name = ModuleAnimation2Value animationName = dockingring valueName = maxTemp valueCurve { key = 0 1700 0 0 key = 0.1 1500 0 0 key = 1 1450 0 0 } } //same here MODULE { name = ModuleAnimation2Value animationName = dockingring moduleName = ModuleHeatShield valueName = reflective valueCurve { key = 0 0.25 0 0 key = 0.1 0 0 0 key = 1 -1.5 0 0 // don't leave the shield open. } }

For Woomera, I had trouble with the mapdecal. So leave it unchanged (i.e. leave it at the Cape), but use this for the PQSCity: latitude = -30.9711 longitude = 136.4763 repositionRadiusOffset = 1 repositionToSphereSurface = true (add that last one). You can try something similar with the other site.

Are you trying to change KSPI's precooler, or make your own?

Spanier: You use Visual C# Express if on Windows. Regarding engines: no, I am not using a blanket 1.6x rescale. The point of Realism Overhaul is realism, not "make things 1.6x bigger." I haven't done spaceplane parts at all yet.... Electricity: because the small pod is replicating Mercury and other small 1-person pods, which generally have a large set of batteries and that's it, whereas the large pod replicates Apollo and other 3-person pods that generally have a small set of batteries and rely on solar panels or fuel cells for electricity over time. What did you want to do to the engines? (That text file...open it in wordpad maybe. It looks like Notepad isn't recognizing the linebreaks for some reason.) As to the pic: unknown. What did you place, what mods are you running, that sort of thing. Zyglrox: yup, fixed on my end, but it must not have been in v3 (and thus will come in v4). darcgekco: ask careo, but I think it's degrees per second. Spanier; FAR calculates drag based on part size. You don't have to worry about it. Just make sure that when you resize parts you change the attachnode size appropriately (a 4m fuel tank should have size 4 top and bottom nodes) Zyglrox: I'll check the RealChutes code. They should probably be new parts anyway, not rescales; I just added the file jrandom uploaded as an RO version of RealChutes without checking it much.