Gaalidas

I feel like I've missed something here... what the heck is the APU now?

I don't know if this has been discussed earlier in this thread, but my brain is itching to make this revelation here and I'm running out of time to go get my starbucks drink while allowing my mother to pay for it (need caffeine fix now!) so here goes... I was reading a bit on the first page (yeah, I know, that was like... forever... ago) and I thought I should point something out here that is being ignored by the majority of people out in the add-on development world with respects to module manager. Module manager does not only look at configs which are formatted for it's own patching process. In fact, it can read configuration specifically made for it's patching process from within the configs of the parts themselves. What this means is that you can take something like this: MM config: @PART[partnamehere]:NEEDS[neededmodhere] {[INDENT]MODULE {[/INDENT] [INDENT=2]name = neededmodule[/INDENT] [INDENT]}[/INDENT] } And turn it into something like this: PART config: PART {[INDENT]name = partname part config stuff here ... MODULE:NEEDS[neededmod] {[/INDENT] [INDENT=2]name = neededmodule a bunch of other parameters[/INDENT] [INDENT]} MODULE:NEEDS[!neededmod] {[/INDENT] [INDENT=2]name = alternativemod a bunch of alternative parameters[/INDENT] [INDENT]}[/INDENT] } So, what's happening here? Well, module manager will look at this and compare those needs to what it can tell is installed and it will then remove the one in which the needs cannot be met. This is done without having to ship an external cfg file that contains just a few lines of code to patch a module out of a config. This also cuts down on the time it could take to remove a module from a config and replace it with something else, or anything else you could need to do in a patch. You can also put a needs section following the PART entry at the top of the part config to force it to only become available in the VAB/SPH if the needs are met. Also, the above code, used in context of my own modding needs, works without a hitch. I use it mainly to replace ModuleAnimateGeneric entries with FSanimateGeneric entries based on the status of Firespitter.dll, which could theoretically disappear from my install if an alternative for the texture/model switch and animations makes itself available. I don't want to have to search for all my various module manager configs to eliminate any pre-needs-filter patches that are replacing modules with firespitter-specific modules. If this is all old news, then please disregard. I just thought this little bit of information could help to make the parts in this kind of project compatible with any number of different situations without requiring half a dozen separate module manager configs, some of which would need to be removed by the end user if the mod they apply to is not installed (if the config somehow gets past quality control without a needs filter in it). Standard disclaimer in my signature applies here... in the extreme sense.

If all else fails with that hatch, there is one more thing you could do. Granting the fact that it won't fix the lack of immersion, for the sake of actually having a way of bringing your kerbals outside the craft after launch, you could model a customization module to house a secondary hatch. However, I had an interesting idea while writing that last comment. A while back there was a mod created which allowed you to give the command seat an internal kerbal assignment slot in the VAB, which would then eject the kerbal and automatically strap him into the seat upon loading the craft into the simulation (aka. launch craft button). While this is not a quick fix as it stands for this problem, it could serve as inspiration for a possible work-around here. My idea is this: You want to grab a kerbal and stick it inside the docking bay if your craft. Transfer kerbal from the command module to the metaphysical (aka. invisible) command seat. Right click on a part that appears to have no use other than to look awesome. Click on the option presented that will say something like "cycle airlock." Plugin takes over the process of ejecting the kerbal from the metaphysical space to the real space, and then strapping him into a specialty-modeled command seat which will look like the docking-bay's hatch door, and feature the kerbal appearing to be holding into the door (maybe, more liekyl he will appear to be sitting in the air, which is okay considering this is a gravity-free zone here.) The position that the "command seat" places the strapped-in kerbal is now located outside of the "obstruction" that is causing the problem in the first place. You can now eject the kerbal from the "command seat" and he/she will pop back into controllable existence just a few feet away from the chair with only some minor issues with possibly getting his helmet fused with the side of the docking bay and having contortionist-styled seizures before ripping a hole in space-time and ending our suffering once and for all. Not a good chance... of ripping a hole in space-time anyway. The seizures... well, that's a problem for another day. An important disclaimer exists in the signature area. Also, if this route were to be attempted by someone with any clue how to code this sort of thing, it could delay this project by... well... a lot. That could really suck, so... if you decide to take that route the rest of the community might try to kill me. I'm okay with that. Just try to give them something to chew around with so it doesn't come to that. Okay, now I'm getting paranoid. Gah!

What are the other features?

Awesome... now quit torturing me and get that prepared for a new release. I swear, the day I starting trolling the development forum was the day I realized there really is something worse than... well... okay so I didn't think that one out far enough to make sense of that comment. For an explanation, see my signature area.

Y'know, I could be completely mistaken because, honestly, I have a horrible lack of experience in these matters but... I was noticing in those shots that a few of your engines are reporting less fuel available than others. Now, I have no idea where each of those gauges are in reference to their actual engines, but I do know that something could be out of balance there. I know from my experimenting that even the repulsors are still subject to balance issues. So, my theory is that the repulsors are still working, they're just under a heavier load than the other side of the craft and are buckling under the strain. The repulsors on the other side of the craft are being lifted off the ground (just imaging them as wheels with actual contact with the surface of the planet) and, as happens when the wheels on one side of a vehicle fail, the craft teeters off to one side and looses a heated argument with the pavement, so to speak. However, I am just speculating here.

While I doubt anything would explode if you used them together, the plugin, and thus the parts and the module they reference, will be different and will likely not work "together" so to speak. Unfortunately those older tracks don't work too well under the current KSP build.

Ah HA! I found the solution to the emissive situation. Woke up this morning with enough energy to sift through the entire thread. Whew!

Add those missiles and cannons with the BahamutoD weapon kit. Just stroll through the add-on development threads, you can't miss it.

I, as a relatively uneducated believer in the superiority of the Kerbal mind (which automatically makes me less intelligent than dirt in a world where dirt is the highest life form), can say that using Uranium as a material for struts makes complete sense. See, when using a volatile substance for a strut, you remove the need to add explosives to your stage-sequencers. You also remove the need to use anti-freeze in the cold reaches of space. And... oh this one is so good... if everything is going horribly wrong, you can rest assured that any attempt to destroy the offending vessel will be catastrophic and quite spectacular. Okay, I admit I feel less intelligent just typing that...

Nothing like an awkward pain in your ass to really make you feel alive.

So, I noticed this is now compatible with "Spaceplane Plus." Good stuff... except... one little teeny tiny problem. Lit windows. As in, they don't light up anymore. This is the same problem that I encountered when trying to make the B9 cockpits work with this stuff, LLL as well has this problem. It seems the shader completely disrupts the window emissions. I remember there was a fix a while back, but I'm way too lazy to search all 38 posts for that reference.

Hah! "treading" carefully! Ahem... well, I thought it was funny. ... ... y'know, "treading" water? okay, fine.

Considering the post previously to yours was from several years ago, I don't think dredging this old thing up was really well thought out. EDIT: Ahh crud! I'm a complete and utter moron today. I looked at someone's "join date" and in my brain it said "that's when the last post was made." Just shoot me, it'll be less painful.

So that's why the dark room looks even darker when I put an unlit light bulb in it! Jeb said it was because my brain is too small, but now I've got him pegged! Super-scientist my arse!

Gotta make that first nudge count then, eh?

You've discovered the new and totally super secret feature designed to give you the feeling that you're on some seriously hard drugs without having to pop a single pill. No warranty provided, consult your neighborhood witch-doctor before using, common side-effects include "freaking out," "violent seizures," and "more-challenging-than-normal death." Not for use by mothers or women who may become pregnant or anyone without a history of insanity.

Okay, I am by no means an expert in this, and I have a number of MM-related websites on my quick-links bar, but here's an attempt to possibly limit the copying of the parts: $PART [*]:HAS[@MODULE[MuMechToggle]:HAS[~freeMoving[True]]]:FINAL { @name ^= :$:_uncontrolled: @title ^= :$: (uncontrolled): @MODULE[MuMechToggle] { @freeMoving = True @servoName = <Uncontrolled> @jointSpring = 0.0000001 !keyRotateSpeed = dummy !rotateKey = dummy !revRotateKey = dummy !motorSndPath = dummy } } So, what I added was the ":HAS[~freeMoving[True]]" part in there which, in theory, will only match if the parameter "freeMoving" is not equal to "True" and will apply the copy the way you need it to. Documentation on the "~" operator is a little sketchy however, and it might actually be checking to see if the parameter "freeMoving" doesn't exist, instead of just checking for the value of "True" but I have yet to actually need this kind of check personally. Also, technically you shouldn't need to add "= dummy" to the end of the deleted parts, but I do not believe it will hurt it either way. If this method does not work correctly, you could replace the "~freeMoving[TRUE]" with "#freeMoving[False]" however this would only work properly if all parts that are not free moving actually had the parameter present to say that they are not, instead of assuming that parameter's value is just false by default. You'll have to experiment a bit here and there to see what works.

Now that is something I'd love to see in the same scene as that giant walking robot. Lets see if we can kick a football into orbit!

So, technically it was emitting, but emitting black? funky.

Amen to that. Granted, this won't be covering every situation and completely superseding the right combination of stock and other modded parts for a complete experience... but this one giant horse-pill alone will solve almost 97% of the problems I face when trying to even conceptualize any sort of colonization pod. I almost wish I had not found this work-in-progress thread, because since seeing the first sample image I cannot enjoy KSP in the same way again until I see this in action in my own simulation. EDIT: I concur with the above statement and add to it: Great Jebediah's-Mother's-2nd-Cousin-Twice-Removed's Ghost!!!

Indeed, for Gawd** hath ordaineth't that we, the green creatures of this terrestrial body, go forth unto his universe and proclaim the fallacies of the wheel, proclaiming the good news of a new covenant in rolling technology, giving them hope and showing them how badly their old-ways of rolling-around-on-things have done their jobs. I remember that day, as if t'were but a day before, when behold the clouds before us did part ways... and a piece of debris from a failed rocket launch swept from the heavens and obliterated our third companion... whatever his name was, may the heavenly tadpole have mercy on his soul if he had one... and then we went home. But the next day the clouds parted again and we were sore afraid... but instead of death and smashed-ness we were presented with a new vision for the round things we use as landing gear, and the occasional crashing-gear. It was then that I knew we were destined to do great things. Then I belched and fell on the ground. t'was beautiful! Or was that a really nutty dream I had after a failed orbital insertion left me stranded for three days with nothing but noxious fumes as breathing air? Either way, it was profound. ** GAWD (noun, G-ahh-d, heavily accented replica of a common word for a supreme creator and ruler of the universe)

Interesting... this has spawned an interest into how exactly a kerbal is supposed to be "canned" so to speak. See, the problem lies in the life expectancy of a kerbal enrolled into the KSP launch rotation. Nearly 90% of the rockets/crafts created by the KSP engineers explode at some point in the launch, and out of those nearly 52% explode on the launchpad... at least of the ones that are actually reported. Paperwork is not a common thing to get out of the people in the launch control division. So, it seems to me that the only way a kerbal can be fired without being killed, an event which would surely be extremely troubling to any kerbal who's devoted the last few minutes of his pathetic life to the furthering of science, is by being put into a defective rocket with no windows and a slight... bugged... navigation system marking Kerbol as something that the kerbal in question would choose to visit, such as a ski resort on Duna (inside joke here in the Kerbal Longevity Research division, aka. KLR). This way, the inevitable death of the "canned" kerbal cannot be legally (at least on Kerbin) traced back to anyone because, technically, the kerbal punched in the destination himself and fired the rocket which, in turn, caused his own death. The evidence of tampered equipment is melted down with the kerbal, and all is peachy. So, in conclusion, no kerbal is ever truly "let go" without meeting an untimely demise.

I thought the pun was scary, until I went to the next page and read about you humping a laser, lo-fi. This is not only getting more and more disturbing, but quickly approaching down-right dangerous.

Daang, I take a few days off and you pull this kind of stunt off on me. Do that more, please.