Starwaster

The vast majority of it is just parts. The only way that will break irreparably is if Squad also breaks their own parts. The few bits of B9 that are dependent on any plugins can already be replaced either by stock PartModules (the Saber engines work fine with MultiModeEngine) or have alternate plugins available to pick up the slack. The sky's not in danger of falling. Chicken Little... is safe.

CRAP! B9 is broken?!?? Dang, I guess I better uninstall it then. And it seemed like it was working for Porkjet-1 so well too

It needs a fuel line? That's news... the included craft doesn't use one does it?

Constellation was a rocket program that could encompass a variety of missions. It wasn't for the moon or Mars specifically. Ares was to be the launcher developed to meet Constellation's needs. Its exact specifications have changed over time as well. Originally it was to use the shuttle's SRBs and SSMEs but that changed (that's pre-Ares). The exact diameter changed as well. Driving factors were changing payload requirements. So it started out as 8.38 m diameter and then expanded to 10 m and required the RS-68 motor instead of the SSME. Which is why launch dates kept getting pushed back until eventually it was cancelled. Edit: now that I think about it, Mars was added in later when they needed a launch system to get the Mars components into orbit. That's not even Copernicus specific either I don't think. There's been a number of proposals over the years and it's hard to keep them all straight. That's why there's this confusion about Constellation I think. Do the cutouts the way engines do fairings. Attach decouplers to each engine bottom and the 'fairing' appears. Not sure how that gets implemented except that there needs to be a separate mesh for it in the engine model. I'm sure there's details on it knocking around the forum. Hmmm actually come to think of it, that's only a valid solution if you were going to model specific engines for this. That would prevent players from using their own chosen engines. Do them as a separate mesh with attachment points in the cutout holes in the fairing so you can mount them on? And put decouplers on the cutout pieces so you can separate them.

Does this really require a new part? Just put a ModuleDecoupler on the cockpit.....

Yeah I gave you bad information on the surface attach nodes. Size does have effect but, AVOID very very high levels of attach node sizes. On a whim I decided to increase surface attach size on a pair of SRBs to 24. After all, it must be 8 times stiffer than size 3 right? WRONG. It flexed like you would not believe. I mean they were warping in and out away from the fuel tank a good 10 meters. And the number of joints never increased above 3. So, you could try varying attach node size; you can go above 3 and it does have effect but obviously weird things happen if you set it inappropriately. But I still think you're better off making them stack nodes. Edit: Proot's comment has set off this weird thought that keeps playing in my head now. Rockets don't kill Kerbals. Players kill Kerbals....

I had some debugging code in my node resizer that provided feedback on joint count. I could reactivate it and try running some tests with it I guess

Hey! That was NOT my fault. That could have happened to anyone I never saw snacks explode before either...

BTW ialdabaoth, did you ever figure out how to find which RCS are firing? If not take a look at MechJeb's code. There might be something in there...

I'm not quite sure how KSP deals with surface attachments (attach nodes) except that it deals with them differently from stack nodes. Attach nodes (AFAIK) don't allow for different node sizes so it basically deals with them all the same. Even if you were to use a plugin to change their size I'm pretty sure it wouldn't matter. Stack nodes on the other hand: the higher the node size, the more attachment joints it creates. And either it makes them stiffer or just having more joints makes it stiffer. Each joint also has an associated breakForce / breakTorque (sounds familiar right?) and the larger the attachment node size, the higher the breakForce / breakTorque value. Maybe that's what actually affects stiffness, I'm not sure. None of that happens in the VAB or SPH btw; joint strength is irrelevant there, it all happens when the vehicle is actually spawned and offrails. That also has some bearing on your trusses BTW. You might want to increase their node size a bit, especially when they start getting attached to larger rockets of greater mass. Have you found them wobbly at all? I found my 10m (which was actually the default size) to be wobbly when KJR isn't installed. And I could not increase node size very much because I had several nodes too close together and it was making it hard to snap them. All my truss node sizes are 0. It led me to create a small plugin that allows me to keep my node size as small as I want for the editor but once it launches and before it goes off-rails, it increases node size depending on configurable values for each node. Do you think that's useful to you?

When you say it's floppy, the legs, I take it you have to attach them? What are the node sizes? Joint strength and stiffness are (as of 0.23.5) controlled by node size.

RPM's configuration files most likely.

What weirdness? You mean how the texture is stretched at the poles? That's to counteract polar 'pinching' of the texture coordinates. Because of the way spherical objects are (usually) uv mapped, the poles tend get distorted.

Is the pod supposed to have that eyeball thingy? I had a look at it (for the first time ever) the other day but couldn't figure out how to make the eyeball work. Is it broken and it requiring config work?

Looks like

I'd lower reflection for starters. I'm thinking 5% (0.05) ? If you happen to know otherwise feel free to substitute. Then it needs ablative to be set to the ablation resource to be consumed + some keys to tell it when to start ablating, how much heat shield to ablate away and how much heat to dissipate. dissipation is heat dissipation and I'm not sure if the value below is high enough for your needs. If you find it is not then increase it. (just the second key. This is just the module code, not the part filter. If you're doing this to the B9 parts just replace the module section with this. MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.05 // 5% of heat is ignored ablative = AblativeShielding loss { // loss is based on the shockwave temperature (also based on density) key = 650 0 // start ablating at 650 degrees C key = 1000 64 // peak ablation at 1000 degrees C key = 3000 80 // max ablation at 3000 degrees C } dissipation { // dissipation is based on the part's current temperature key = 300 0 // begin ablating at 300 degrees C key = 500 180 // maximum dissipation at 500 degrees C. (500 is the shockwave temperature. If you play with Real Solar System, increase to 800. Increase value from 180 if you're burning up) } }

BTW, he did post a log. I took a look at it and didn't see anything definite and the errors he was concerned about was just the nullref in OnDestroy. Nothing really major. It was late at night though and I only gave it a cursory looking over so feel free to take a look. It's on page 629 smunisto: installing MJ2 was likely just coincidental. If you have low RAM make sure you close anything resource consuming in the background.

When a new dev version hits, I usually just replace dll. If it acts up then I exit to Space Center and delete any craft specific MJ2 config files. If that doesn't work only then do I consider deleting the master config file. (the one that holds all MJ2 settings and window configurations)

Suddenly, I'm flashing back to Portal, with GLaDOS saying, "Maybe you should marry that thing since you love it so much. Do you want to marry it? WELL I WON'T LET YOU! How does that feel? "

Caveat: I have not gone through every single B9 part to verify that this is true for all of them. But as long as every B9 part's name (which is a unique identifier) starts with B9, then this should work. @PART[B9*] { MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored } }

The engines in the ARM pack use ModuleEnginesFX, but Raptor's configs use ModuleEngines for those parts

That's because it's a conceptual vehicle which is part of a series of proposals which continue to evolve over time. 7...8...10 meter designs. The long saddletruss has been described as anywhere from 22m - 27.7m in length and in the most recent proposals (DRA 5) 10 meters in diameter. The length in particular was a major pain in the neck for me in modeling my parts until I accepted there was no point in trying to reconcile the artist's CGI rendering with what was described in the documents.

Not likely. Note the function the error occurs in. That's a callback to .OnDestroy() which is something that gets called when game objects are being destructed for any reason. Like the ship it's attached to being deleted, game being shut down or game crashing. In other words, the crash had already happened by the time you see that error. Really, OnDestroy() should have a nullref check or have its code encapsulated in a try/catch construct, but it doesn't actually hurt anything. Anyway, need to look at the whole output_log.txt file to have any idea what happened, but out of memory is a good guess and you might want to check into the active memory reducing mod.

It's hard to tell what's going on with that right now. Just from looking at the network graph (fork map) it doesn't look like the two code paths have been rebased at all since Sarbian took over. On the other hand Ialdabaoth could have merged them by hand before commiting 2.0. Would be nice to know for sure what's happening...

Crap! It looks like I only fixed the generator issue on one of the engines in Squad_NTR_modularEngines.cfg Nobody said anything about it still being broken