Starwaster

inexplicably, this mod has always lacked any licensing information. By the rules of the forum it should have been taken down until a license was assigned. It's never been cared for or about by its author who left it in this half finished improperly textured state. This parts pack has potential that it will never live up to. Death might be a blessed mercy for it now.

It shouldnt unless you're setting it to something weird. Or changing something other than what I said. (i did say innerRadius; it's singular not plural so if you're setting something other than what I said, or more than one item...)

And remember: What do we say to the god of Unplanned Disassemblies?

Oops no, that should be #minimumCrew[0]

Nope, didn't see that. I wonder if it might not be prudent to post your fixed DREC as a comment on the curse download if PJ doesn't show up soon ....

Depends on what... 'stuff' is. Also, using !MODULE[MechJebCore] as a conditional makes %MODULE[MechJebCore] superfluous. Your conditional is set up to preclude any possibility of ever finding a PartModule named MechJebCore to edit. Also, if you do use % for something, make sure everything inside that node also uses it instead of @ And, finally, you might want to stick a :NEEDS[MechJeb2] in there with the rest of your conditionals. (I don't since I have no installs that lack MJ2 so would be pointless) and finally finally, this is what I use. Still works fine. (I suspect this is what the 'stuff' in your config was for but just in case wanted to provide you with something that is known to work) @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } }

You changed the SP+ parts to match B9 Mk2 stack node? Are you unaware that it is actually the B9 parts that are at fault? They always have been. They don't match up with the stock Mk2 parts and never have. (public domain) That's my fault; I provided the DREC config to Porkjet. I sent him corrected ones but I haven't seen him online since the forums came back up .... problem (as you no doubt discovered) was mismatched number of { to } Make sure you're using the appropriate FAR config. Specifically your SP+ fuselage parts must NOT be type Winglet. You must have a config somewhere that is doing a '@module = Part' for each part that is currently set to Winglet and otherwise strips out fuselage lift ratings... Secondly, airbrakes, airbrakes, airbrakes!!!! I'm astounded that you don't already have them. Everyone that's suggested it is 100% spot on. Thirdly, drag chutes. Either get Real Chutes and install some RC drag chutes on your plane configured to deploy on ground contact or stick some stock chutes and deploy them manually when you touch down. (RC drag chutes is the way to go however) I have a particularly large SP+ plane that uses S2 parts with the giant S2 hangar and I need 4 drag chutes and 4 airbrakes on that. (technically it can land on only 2 of the chutes but it has a long neck and it's too easy for the cockpit to slam into the runway so two of the chutes are forward of the front landing gear to pull the nose up.)

The best way to get rid of (or lower, you dont want to lose it entirely) is to adjust the innerRadius IIRC (rather than mucking with the wavelengths, but you can tweak those in addition for a more subtle look)I forget if the innerRadius variable is exposed in the config or not.

Just keep in mind, as I posted a few posts back, for Real Fuels you're going to want 5x the tank volume of stock (or made for stock) parts. No choice really, density values are about 1/5th. Volume is in liters.

600 seems low for Real Fuels. What was it in the original part?

Let me know if I got anything wrong, this is my first time messing with this. A few gripes: This is something I'm seeing too often among new users of ModuleManager in the past month or so: Deleting a key or node and then replacing it with the same thing. I'm assuming the reason was to avoid accidentally ending up with two sets of the same PartModule. What you should do instead is add a conditional check to make sure that module does not exist on the part. (there have been times in the past where it might have been desirable to do this sort of deletion, when multiple replacements were necessary and proper indexing not available. This is no longer true with recent ModuleManager developments) Second: This is Real Fuels, not Modular Fuels and uses liters instead of KSP's arbitrary volume unit. The values you provided are appropriate for Modular Fuels but not Real Fuels so multiply by 5. Third, you have at least one duplicate part referenced... mk2Fuselage_LFO. Better check and make sure there are no others. The example below shows the short LFO Mk2 section fixed accordingly. @PART[mk2Fuselage_Short_LFO]:HAS[!MODULE[ModuleFuelTanks]] { MODULE { name = ModuleFuelTanks volume = 1500 type = Default } }

Their size is tweakable now. You get several parts, each resizable. If you are in career mode then there are limitations on size based on your current level of advancement.

post the config file you're using so I can take a look at it

yeah it should be @PART

Hmmm, you know there's a mod out there (KSPX maybe? Or some stock alike mod...?) that has 45 degree angled RCS nozzles. Sounds like that would have let you place it away from the porthole

I'm not currently up to date on RSS, but this sounds suspiciously like something I ran into when testing very deep gas giant atmospheres. Except it didn't accelerate backwards. But it's reentry FX did point in a direction that was perpendicular to its velocity vector. If the latest version of RSS is experimenting with realistic gas giant atmospheres then there's going to be problems (probably best not to try to simulate it all the way down to core, just down to the metallic region.... that might be ok)

See the latest post in the Reflection Shader thread. Someone was kind enough to hand you a silver platter with a solution on it.

Right, right! And when the RCS fired, it got really hot and the alternate heating and cooling of the glass cracked. I see...... Oh, nice progress report Sumghai!

I sense coincidence, not causality. You did something differently or even outright wrong when you tried it with docking ports.

Banned for not going to Eeloo. Attempt a landing there.

ascentkomputron.blogspot.ca I haven't actually gotten around to trying it but it apparently can compute optimal launch profiles and then execute them in the game even though it's an external program.

Why does one of your portholes look shattered???

Don't forget that g varies with altitude above the planet (or distance from its center). So what you think of as TWR = 1 might actually be higher.

Concise, simple and automagically follows the MJ Tech Tree integration without having to specify it out module by module. For Career Mode compatibility, I suggest this version instead: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } } @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ProtractorModule]]:Final { MODULE { name = ProtractorModule } }

Deleting the FAR config shouldn't be necessary with the latest version of Module Manager. It has code in there that tells it to only apply the FAR patch if FAR is actually installed.