Starwaster

Was this during ascent? In atmosphere? Because it's not possible for MJ2 to make the rocket do ANYTHING during a normal (non-physics / on-rails) warp. Where exactly did this happen and what sort of maneuver? Edit: Sorry, missed your earlier post. So it was doing a physics warp.... ok.

Get out! GET OUUUUUUT! All Kerbals man your rockets! Nuke the place from orbit! Leave warning buoys!!! Edit: Seriously I have no idea. I have never seen this thing before. Very strange.

So look for the RPM files for the Orb and edit them. Find any directory references (if there are any) and update them.

I can't find those... what pqsmod is that in??

I use every single part of the carcass!

Get Notepad++

Yes, it just generates a float based on the pixel values and multiplies by deformity. Confirmed that. Awesome, can't wait! Though I am finding some bizarre issues when dropping into Jool when I configured it as described. Thinking that instead of scaling it down to 'core sized' to maybe scale it down to its metallic hydrogen layer. Seems like if the atmosphere is too deep that 'weird' thing happen such as graphical issues with AeroFX and camera gimbal lock issues. I'm also wondering if there's not some hidden PQSMod that got missed with Jool because I experienced similar things when I munged Duna's heightfield parameters and dropped below a certain altitude. Pretty sure you should post there. It's probably the result of scaling Kerbin up. There might be something in VE's configs that can be adjusted to fix it, which would filter back to RSS in the form of a config file fix. (RSS has config files that alters VE behavior for cloud layers for instance)

I checked those out and I can't find a problem with them. Checked both ports (stock/chute combo and IACBM/chute combo). Both show up as shielded and survived the reentry. Could not reproduce. Ok, firstly, please let the record show that I have never 'washed' a star. Especially not ever. Secondly, just to clarify, what I posted on page 125 doesn't increase difficulty, it provides tougher heat shields if you are playing with increased difficulty. You have to have already increased the difficulty. And the way you do that is by either: Going into the DeadlyReentry folder (<KSP Folder>\GameData\DeadlyReentry) and editing the custom.cfg file. Find the line that says @shockwaveExponent = 1 and change the 1 to 1.12 While playing DREC press Alt+D+R and DREC's debug menu appears. Find Shockwave Exponent and change the 1 to 1.12. Click save. Close the DREC menu. Then you go download the RO files (keeping only the heat shield files if you don't want the rest) or use the solution I posted. IIRC, the problem with the solution I posted is that it applies the same amount of heat reduction to all affected parts regardless of their size so some parts might get too much protection.

Kerbal kurrency should be kalled Kraap

Unfortunately, we might need to use clouds to to have actual gas giants that don't have a (reachable) solid surface. Ultimately what I'd like to do is shrink the radius of Jool/Jupiter to something the size of Earth (1.0-1.5x Earth size) and give it a set of pressureCurve / temperatureCurve that approximate what we know (and speculate) about Jupiter. You'd be able to probe the upper reaches but then temperature would quickly rise and destroy you even without Deadly Reentry. I've done some work on that experimentally but visually it looks like crap because you can still see the solid surface, which looks really strange with the atmospheric shell pulled out to Jupiter's radius. A series of volumetric and cloud layers might be the way to go to make it look right or at least to hide the 'core'.

He definitely needs better RCS placement there. Note the constant counterfiring on the RCS. That's happening because the ship is offbalance and when it tries to translate it's going to move out of alignment. That necessitates firing the ports on the opposite side. However, that also means that the force spent keeping alignment is counteracting the effort expended in translation. The net gains will either be small or non existent depending on how much force it's having to spend to keep it aligned. That said, the last build I tested demonstrated flawed logic in the docking process where I could take a small craft with perfect RCS balance and place it in front of an identically designed craft. Not quite in front mind you, a little off-axis such that the procedure taken should have been: Align, translate to axis, move forward. Instead it was thrusting away under RCS power until it was outside the 200m limit. I hate to say but I'm still using build #168 compiled for 0.23.5. With some very minor tweaks to the docking AP. (like, 2-3 lines of code changed). Using that build, I can take my RCS test craft, undock, switch controlled from port and target port such that they're basically back to back. I can't even describe to you how beautiful it is to watch. Very delicately and precisely, the one craft just translates up a bit, backs up until it's on the right side, drops back down and moves forward and docks. Unfortunately I lose some recent promising changes in the latest builds but for testing purposes right now, it's more important for me to have craft that can dock reliably, especially when I'm testing something harder to dock than my little test targets. Edit: Decided that there's been enough builds since the last time I tried it to try again, using my standard docking targets. (download them here if you want a quick simple stock craft to test with) Definite improvement over previous builds. I'll try it with something a little more massive that represents what I might need to dock in actual gameplay.

I don't think you're crazy, I've been thinking along those lines myself. I think we need the maximum possible range of shades in the heightfield maps. When you stretch out the elevation (which is what you're doing when you scale deformity up) the gradation between elevations is going to be steeper if you're using a narrow range of shades than if you were using the full range of available shades. Put another way, if the lowest point on your map is represented by 32 and the highest point represented by 128, that's a separation of 96. Taking the separation in meters between high and low, that's 306.11458 meters between steps. That's not very much detail. So you want the maximum possible range of colors utilized in your heightfield map. For accuracy you probably want to use something like Matlab like Ralathon's been using as opposed to just photoshopping like I've been doing for Duna. Unfortunately, because we're using grayscale here, we're only going to get a maximum of 256 range of colors. That's a separation of ~114.8 meters between elevations. You're still losing a lot of detail Basically we're dealing in 8 bit.

Ferram your mailbox is full

Oh ok so SSTScale = 1 is ok? (good thing I didn't get around to commenting it out on mine...)

Actually, no. This subject has come up previously with certain Real Chutes parts which I'm seeing mentioned again. The problem seems to be centered around them protruding a little too far into the parent part and they don't show up as shielded. Raycasting failure? This was the solution that worked for people afflicted. I suggest we roll this into DREC in a MM config file @PART[RC_radial] { MODULE { name = ModuleAeroReentry adjustCollider = -0.015 } }

And a smoldering one at that!

I call it tough love. We love you guys and sometimes we gotta get mean to demonstrate our affection.

Ok, that does it. You are hereby required to upgrade to a larger launchpad before any more launches can proceed from your facility.

That sounds like you're asking me to redistribute other mods, which I'm not going to do. I will compile a list of useful links to other mods that I used to build Copernicus style ships. Mostly those are Stretchy Tanks, Procedural Fairings and Porkworks inflatable habitats. I also like to use Lionhead Aerospace just for the round solar panels. (I don't use much else from those packs) And I've also used AIES and RemoteTech for the nice looking communications dishes. None of those last three packs are crucial since they're just stylistic. I said earlier that I was going to put up some more craft files which I haven't done yet. I'm working on stability issues with the larger 10 meter parts which have very small attachment nodes that makes them too weak when attached to very massive parts like 10m fuel tanks. Unfortunately if I make the attachment nodes any larger they envelope the other attachment nodes making it hard to snap to the right ones. I have an idea for that which I'm pursuing that will allow small nodes in the editor that get scaled up when you load the ship into flight mode. It's a plugin that I'm working on which will be useful in any situation where you might want to have small nodes but can't because of the weak joints that they have. So far it's not working though But anyway when I put up the new craft files I'll update the front page with links to useful mods to have.

Maybe I'm thinking about something else but I thought SSTScale needed to be commented out for that to work?

We have one! Check inventory or make sure you have latest version.

Make sure you are attaching to the UPPER node not the lower node. (of the interstage) The lower node decoupler is a dummy node for compatibility purposes with other mods (that depend on knowing what parts are decouplers). As is, you would need to attach a decoupler to that node first. Instead what you do is attach to the upper node. If the upper node is not where you want it you can relocate it in the editor. Check the part description for how. When using the upper node as I described, the upper stage will detach when ALL fairings are detached from the interstage. Currently, the PF parts are limited in career mode by having to be unlocked. Larger sizes unlock later in the tree. Even the variable sized interstage has its size limited such that you have to unlock more and more of the tech tree in order for larger sizes to be available. What more do you want for career mode compatibility? If you can actually think of something, it would be more constructive to suggest that instead of proclaiming that it has broken career mode.

Patience, I think he and SpacedInvader are actually working on those. Give them a few days.

You can have an engine with two modes of propulsion. You have two options. One is MultiModeEngine module that the RAPIER uses. It's built into the stock game so no other mods required. The other is RealFuels ModuleHybridEngines, which mean that users of your VASIMR would require another mod.

WOW 38 pages of this? Come on, time to close this thread.