ThomsenX

Reading this made me realize how fortunate I am to run KSP sans Steam and not have to admit how many eons I have spent playing this game. On a side note, +1 for Denmark... It's nice to see I'm not the only Kerbal commander in our country

I mostly design and assemble orbital stations, so here's my planned Koviet Union naming series: The name of our current station is Aksinya, derived from hospitality. It shall be referred to by its name or, in certain cases, its abbreviation: AKS. Each module has a Russian/Slavic name derived from its function, e.g. Prokopy (means: progress or advance, is: science lab) or Zoya (means: life, is: life support module), and is usually shortened to its abbreviation, number of permanent instance and, if replaced, lowercase letter noting revisions, as well as other notable characteristics, as such: Zo-3bT ...meaning that it's the 3rd Zoya life support module on the station, it has been replaced once (thus: b) and is temporary (T). So in general: [Abbreviated name of craft] - [# instance] [revision] [additional tags] The space program works with a limited number of standardized launchers, e.g.: Li-25 Sirius ...where Li indicates a lifter class vessel, 25 indicates a 2.5 meter rocket and Sirius is a designated name of a star. This is my first time working with truly specialized modules and thus an actual naming program. For the record, I do not speak a single word Russian, so all names are based on internet sources! Now, I should probably launch the first module soon...

Magnificent idea! Will try this out at once

Hey all, I've been following Bob Fitch's space station building videos over on YouTube, and occasionally he mentions editing docking nodes out of the persistent.sfs file (i.e. removing their docking ability, thus they become structural parts like any other) if he knows the modules will be permanently attached. Doing this greatly reduces lag. Question is, with many identical docking ports on my space station, how can I know which docking module in the file corresponds to which docking port on my station? Also, are there any other things I should be aware of when removing docking nodes?` Cheers, - ThomsenX

The root part is the large stock radial probe (L01), attached in the orbital stage (which serves as a rendezvous tug too). Nothing too uncommon there, I guess. EDIT: i wonder if an 'ignore tag' could potentially be applied to certain parts, which MechJeb would recognize and ignore? I know it'd take a few lines of code from the dev, but it would be incredibly useful.

I realize now that my wording wasn't very clear I wasn't using Stop at stage # because I expected MechJeb to not trigger fairings prematurely (because a lower stage's engine was burning on autopilot at the time). Stop on stage # works like a charm, and I ended up using it in defeat, so finally my space station received its load of snacks and supplies. My inquiry was more related to this question: why does MechJeb stage off the two upper stages (containing only fairing decouplers) when [1] there's already an active stage with an engine burning and [2] there are neither fuel tanks nor engines in any of the two stages above the active stage?

Even when a lower stage is already active? Seems counter-intuitive to me, but you're probably right

What I'm trying to find out is why MechJeb stages past the active stage (i.e. stage 2). The Stop at stage function should, in theory, not be relevant to my situation as long as there's an active engine on the current stage - which there is... EDIT: Ah yes, Smart Parts are great - using them for timed parachutes when dropping reusable boosters occasionally. Now if only I could voluntarily jettison my fairings, only then would I think of using such luxuries

(cross-post from Procedural Fairings thread, as I suspect the problem lies with MechJeb) Hey all! I've been having this bug with Procedural Fairings and MechJeb lately... I carry out a lot of routine launches, so I often outsource the tedious work to MechJeb (running v2.1.1), but I ran into this problem recently, where MechJeb would stage (i.e. jettison) my payload fairing walls and decouple the built-in decoupler in the payload fairing base. To see exactly what I mean, . Basically MechJeb will jettison/decouple all Procedural Fairings parts at some point during launch. In the video, I used a rocket with this staging: 0: Fairing walls (had them set up to jettison on Custom01, so I wanted to keep them out of reach of staging) 1: Fairing base 2: Orbital injection stage, main launch stage separation 3: Main launch stage, 4x SRB separation 4: Initial 4x SRB stage, to get us off the ground Moments after decoupling stage 3 and activating the orbital injection engine, the fairing walls would pop off and the decoupler deactivate, thus leaving me with a freely floating payload post-injection burn. I have never seen MechJeb interfere this way with any other parts, so it seems (AFAIK) to be MechJeb and Procedural Fairings somehow clashing. Does anyone know of a fix? If you do, I beg you to post it here. I'm on the verge of desperation, as FAR dislikes my rockets unless I use fairings, and I can't use them under the current circumstances Cheers, - ThomsenX EDIT: Was informed in referred thread to use Stop at stage #, but MechJeb's autostage function should stop at stage 2, yet it activates higher stages (0 and 1 simultaneously) while using stage 2.

I know of that option. Problem is, there is an engine on stage 2, which it correctly activates and uses, but it continues staging past this during the burn (where it shouldn't autostage). Apart from using Stop at stage #, is there a fix for this? I'll probably cross-post to the MechJeb thread, but any assistance here is much appreciated.

Hey all! I've been having this bug with Procedural Fairings lately... I carry out a lot of routine launches, so I often outsource the tedious work to MechJeb (running v2.1.1), but I ran into this problem recently, where MechJeb would stage (i.e. jettison) my payload fairing walls and decouple the built-in decoupler in the payload fairing base. To see exactly what I mean, . Basically MechJeb will jettison/decouple all Procedural Fairings parts at some point during launch. In the video, I used a rocket with this staging: 0: Fairing walls (had them set up to jettison on Custom01, so I wanted to keep them out of reach of staging) 1: Fairing base 2: Orbital injection stage, main launch stage separation 3: Main launch stage, 4x SRB separation 4: Initial 4x SRB stage, to get us off the ground Moments after decoupling stage 3 and activating the orbital injection engine, the fairing walls would pop off and the decoupler would decouple, thus leaving me with a freely floating payload post-injection burn and a new stage 0 consisting of the engine and the already-activated decoupler. I have never seen MechJeb interfere this way with any other parts, so it seems (AFAIK) to be MechJeb and Procedural Fairings somehow clashing. Does anyone know of a fix? If you do, I beg you to post it here. I'm on the verge of desperation, as FAR dislikes my rockets unless I use fairings, and I can't use them under the current circumstances Cheers, - ThomsenX

Because of how subassemblies work, I tend to build space station modules inverted and then attach my launcher platform. This is what happens when I forget to choose another command module, and MechJeb thinks the rocket is facing downwards on launch

A little late to the party, but happy birthday asmi! The new ECLSS is looking goooood

AFAIK, yes. See this link for instructions on how to. The link covers how to convert sandbox to career mode, but you can reverse the process too, using a bit of logic. It's also possible to convert to sandbox mode with the science system enabled, while having all parts available in construction (to prevent missing parts issues with current ships/stations). PM me if you need any help

Yay, I love the sound of that! Is there any chance that one can edit out the 'remove RCS on EVA' part of the plugin, as a temporary fix until 2.0 is released?