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?

Exciting news! No more jittery Kerbals afloat in space Does the fix also patch the RCS bug? (see my post on prev. page)

Today, I put three of these bad boys into semi-polar orbits (one in a 90° orbit and one 15° to either side). They are now mapping the surface of Kerbin, and I'm supervising it all from my station.

This accurately describes what I spent numerous lines trying to express...

I reckon it's been too long since I've last used stock pods. May or may not send up a new observation module to my station very soon...

I only use mods that integrate somewhat well with stock parts, i.e. no overpowered engines, no zero-mass tanks, et cetera. Concerning plugins: I run a lot of them, but none that lower the realism. Graphics-wise, Visual Enhancements and TextureReplacer coupled with several additions (8k Kerbin, 8k skybox, white HD EVA suits and so on). Here's how my game looks as of a couple days ago: this is a link.

I love this mod itself, but some of the bugs are killing the experience. I can live with the 'EVA-left-in-space' bug, as I never leave my Kerbals floating mid-vacuum, but the 'disappearing monopropellant' bug drives me nuts. Trying to maintain a station is considerably less fun if each spacewalk removes some 80 units of monopropellant from the station's mere 550 unit storage, i.e. it barely takes 7 spacewalks to empty the entire craft, despite not using a single drop (I never left the ladder). TL;DR there's two issues: Each EVA removes 80 units of monopropellant from vessel, even though each Kerbal only carries 20 units of 'EVA propellant' (which I assume corresponds to 20 units of monopropellant). Monopropellant removed by going EVA is not returned to vessel upon boarding. Not sure if this is the reason for the bug, but I EVA'd from and re-boarded a 3rd party science lab, which in itself does not hold any oxygen or CO2. Haven't tested on normal crew capsule yet. Maybe all crew-capable modules could have your ECLSS implemented in the future, the same way as it was done to all crew-capable command pods. @asmi, could you tell me how to a) disable the function that makes Kerbals remove monopropellant from vessels, or decrease the amount removed and fix the return of spare monopropellant to the boarded vessel, please? I'm digging the O2/CO2 side of this mod, and I sincerely like the idea of the EVA fuel, but the bugs prevent me from using it 100%. That being said, I will continue to use your mod - it's just the best one out there to this date! Cheers, - ThomsenX

I play sandbox mode, with science added, so I feel like I'm accomplishing something, despite having all parts unlocked to let my creative side flourish, haha. Mostly I try to set up and run a small, efficient space program that works well, looks good and isn't overly complicated. This week I built a small LKO research station. I don't like overdoing things, so crew transfer vessels, RCS supply ships and the station tug are all built around the same small platform, the latter two being unmanned. All my efforts go into making it as effective and efficient as I possibly can, and concentrating on (and maintaining) that goal soothes and pleases real-life me, so I guess it's kind of therapeutic... Recently I added the ECLSS mod, and I love it, since it imposes certain limitations on e.g. my station. Like, the limited oxygen supply onboard my station is the reason for manning a 7-crew station with just 3 Kerbals. Even then, it'll only last them for 33 days with a scrubber unit, so resupply missions are required. I also plan to expand the station; I added a scanner arm yesterday for when I push the whole thing into a higher final orbit, and it's likely that more modules will be added in the future. That's how I play KSP! Cheers, - ThomsenX

Favorite as of yet: Edbro Kerman, the current orbital station manager. Spends all day in his pretty CMD module

I absolutely adore that design! Slightly off-topic: How did you make some of your Kerbals wear EVA helmets indoors?

Gotta love a view like that! What pod did you use in the last picture?