Firov

Very nice! I'll take two!

I rather expect it was done for aerodynamic and weight savings reasons. The aft end of the service module wasn't exactly aerodynamic, so if they would have flipped the Command Module/Service Module upside down they would have needed to hide the Service Module's engine under an aerodynamic and structural fairing, which would have added additional weight (beyond what the boost protective cover took on the CM). Additionally, it wouldn't have really resulted in an easy to enter CM. And related to that last point, having the SM sitting on the CM would have made the launch escape system VASTLY more complex, or maybe even impossible, which is a huge strike against it. Having the CM sit on top meant the launch escape system only had to pull the command module away from the rest of the stack. Since the maneuver to dock with the Lunar Module was relatively simple, it made more sense to have the CM/SM undock, flip around, grab the LM, and pull both free. At least that's my theory. I haven't read if that's the actual reasoning.

Interesting bit of trivia, even our skeletal structure is constantly being dissolved and rebuilt by special purpose cells called Osteoclasts (dissolvers) and Osteoblasts (builders). In adults, this happens at a rate of around 10% of your skeleton per year. So over time your entire skeleton is replaced, and even in old age no part of your skeleton should be more than 20 years old. To my (admittedly limited) knowledge there are very few cell types in the human body that aren't replaced over time. Even tissues that were thought to be static, such as cardiac muscle, have recently been found to regenerate very slowly at a rate of roughly 1% per year. So if you're looking for tissue that isn't changed and replaced over time, I'd look towards your nervous system.

Hey technogeeky. Dtobi and I had a discussion about this when I first created the new altimeter logic. I considered adding an option to do ascent only, and really, the only reason I didn't is because it's going to be a bugbear to get the GUI to work properly with the three way toggle. That, combined with the lack of good use case scenarios is the reason that feature was originally dropped. I'll see if I can't upgrade the altimeter to support it though, since it's now been requested. I'm just going to need to figure out an elegant way of doing it, since I don't necessarily like the idea of a 3 way toggle, which isn't at all intuitive to the end user... Hmm. Actually, I just had an idea on that. I'll need to do some tests but I think I can make it so we can have our cake and eat it too. I'll just split out the "Both" mode into a separate "bidirectional/unidirectional" toggle button that hides the direction buttons when it's in bidirectional mode. It's going to add another button, but it's the best way to do it, I think. Anyway. Yeah. I'll work on this. (Along with the gear thing, which I haven't forgotten about. )

Thanks for the report. I've been pretty busy lately, but I actually do have intentions of looking into the landing gear issue when I have a chance. It's been reported a few times previously. I just always seem to get distracted implementing some shiny new bauble with the development time I do have available... If you could upload a craft that always experiences that bug though it would help me troubleshoot. If you do upload a craft though, please try to use only stock, B9, KW, or Pwing parts though.

Okay. I've got a quick hotfix for the timer issue. Just replace the km_SmartParts.dll in the mod/plugin directory with this one. It's no longer necessary to manually reset the timer if you use an AG or GUI button to start it. As such, timers can now trigger one another repeatedly. Kaa, let me know if this fixes your issue. https://drive.google.com/file/d/0B9K8KY8RgD-qSU9XaUt0OWVDRTg/edit?usp=sharing

Interesting. The reset via AG should work, even if it's called by another Timer Smart Part. I'll look into this when I have a chance. Thanks for the report!

It's actually already capable of doing this. Just ensure that it isn't set to fire only on descent and select the altitude you want it to activate at. I use it to jettison fairings at ~50km, for example.

In the US technical grade KNO3 costs around 20 dollars per kilogram, assuming you're only buying one kilogram. If you buy it in larger quantities, the price per unit starts to fall. Source - http://www.skylighter.com/potassium-nitrate-powdered.htm

Hmm. Thanks for the tip. I gave it a shot but in this case unfortunately it resulted in a "[Exception]: NullReferenceException: Object reference not set to an instance of an object" error message. I tried using both of the below, and both generated that same error. this.rigidbody.AddRelativeForce(particleEffect.rigidbody.transform.rotation * Vector3.up * appliedForce * 1); this.rigidbody.AddRelativeForce(valveEffect.rigidbody.transform.up * appliedForce * 1); Something so simple as getting the vector direction of an emitter is surprisingly difficult. I'm still amazed that "particleEmitter.localRotationAxis" doesn't do anything.

If I'm trying to determine the direction of an emitter, for the purpose of applying a force relative to it's y axis, is there any way to do that? I've tried every way I can think to determine the y axis of the emitter, but the only thing that seems to work is "this.rigidbody.AddRelativeForce(0,-particleEmitter.localVelocity.y,0 * appliedForce * 1)" Honestly, that works pretty well, but I'm told that it's also "wrong". So, with that knowledge in hand I tried various other possibilities, like particleEmitter.localRotationAxis.y or particleEmitter.transform.rotation.y. None of those produce results. I'd really appreciate some help in getting to the bottom of this. I'm running out of noodles to throw against the wall.

I was going to respond, but then noticed the edit. That's too bad. Are commercial motors also outlawed? Anyway, I'm not sure a rolled card type motor would really work for KNO3/Sugar anyway. As I said, it actually burns relatively slowly under normal pressure. It's only when the motor gets up to pressure that it starts generating noticeable amounts of thrust, and that's one of the issues I ran into with mine. I had to develop an igniter that could get the motor up to pressure fast. Anyway, the reason that won't work well with a rolled tube motor is that you're not really going to be able to effectively contain pressure in that. That's one of the reasons, I suspect, that other paper tube motors like Estes use black powder. It burns fast enough, under even normal pressure, that you don't have to worry about building, or maintaining, high pressure in the motor casing.

I assume you're talking about KNO3/Sugar rockets, AKA candy rockets? I made a rocket powered by a "G" class KNO3/sugar engine for my senior project in high school, in 2006. It worked remarkably well, considering that I didn't really have any experience with model rocketry outside of Estes up to that point. I basically had to conduct my own crash research and development program to develop the fuel, casting method, igniter, motor, and rocket body. Now that I think about it, I'm kind of amazed my instructors, or the school board, approved that project. Anyway, what are you thinking of making the rocket casing out of? Metal? Or are you going for a disposable, but more easily constructed, design such as a PVC casing with a graphite nozzle? If you have access to a machine shop, or wouldn't mind contracting out to one, I'd suggest you go with the metal design since it's reusable. I used low carbon steel (AISI 1018) for the nozzle and forward bulkhead and electrical metallic tubing for the motor casing. I don't remember what I used for the bulkhead screws, but I do remember ensuring that it had a lower shear limit than the EMT casing, which would result in an axial explosion (up/down) rather than a radial explosion (pipe bomb) in the event of an over-pressure failure. Anyway, take a look at the following link. It's a site run by Richard Nakka that I discovered towards the end of my project. He's about the closest thing to an expert on KNO3/sugar fuel you'll find. I'd suggest taking a close look at the A-100M rocket motor design and test data on there too. It's an excellent starting point for making your own KNO3/sugar rocket motors. Plus, when you're getting started with these, you really don't want to jump straight into a large motor. It takes time and practice to perfect your methods for casting fuel grains into the motor casing. Another benefit is that, as a metal motor, it's basically infinitely reusable and that fact combined with the low cost of the key ingredients (powdered sugar and potassium nitrate, as a minimum) means that it's very easy on your budget to fly these. http://www.nakka-rocketry.net/ Finally, I would be very careful with the fuel mixture when you're casting it. While it might be called "candy rocket fuel", it's not something to be trifled with. That said, as long as you're careful you're not going to blow up a city block with this stuff. It's designed to burn. Not explode. Even if you dope it with red iron oxide it's still relatively slow burning. Furthermore, there are fuel casting methods that are designed to reduce the ignition risks until the very final stages of fuel casting, and even without those methods it takes a lot more than going over the correct temperature by "a few degrees" to ignite. Just be careful, take it slow, and consult with Richard Nakka's site early and often. Finally, if all of that sounds too much, consider the commercial motor route. It's going to be more expensive in the long term, since you'll be dependent on mostly disposable motors and proprietary fuel grains, but there's no faster, or easier, way to launch rockets.

Well, good news. This is added. I did end up reusing the dual scale system from my altimeter improvements. I went through the trouble of developing it, after all, why not use it everywhere I can? So it now supports 2 different time scales. 0-30 seconds in 200 millisecond increments, and 0.5 to 60 minutes, in 30 second increments. It's not quite as granular as I was hoping for, but any smaller increments resulted in some values being unselectable on the slider.

Hey Fellipe. This is a known issue. It's caused by the new altimeter firing action groups or stages from "OnFixedUpdate" rather than "OnUpdate". When I created the new altimeter logic I didn't think it would matter where events were fired from. I was wrong. Anyway, I developed a fix for it, which is going to be in the next release along with the a fix for the empty stage bug. In the meantime, I put up a hotfix .dll in this post. Hotfix Try that and see if it fixes your issue.

I think the best, quasi-realistic, estimates I've seen to get to Mars fast use an electric propulsion system, specifically a VASIMR plasma drive, coupled with a massive 200 megawatt nuclear fission reactor. Such a vessel could, in theory, complete a trip to Mars in just under 40 days. However, that would require putting a stupidly large nuclear reactor into orbit. Plus, even as efficient as VASIMR plasma drives are, it would still need a fair amount of fuel for the trip. From what I've read about this proposal we do have the technology to build it, but it would be amazingly expensive, and we'd need to figure out a way to put such a large nuclear reactor into orbit. Keep in mind, the largest reactors put into orbit so far have been in the tens of kilowatts range.

Heh. Nice use of the timer z26. Actually, I like the idea of more granularity in the timer. I don't know that it's going to be necessary to have multiple different scales as I did with the altimeter. I'll have to think how I want to implement that. Either way, it's a simple change, so I'll try to have this in the next release (not really sure when DTobi has planned). Honestly, I'm not even sure how I'd go about implementing complex logic while still keeping the mod simple, or even with the current tweakables GUI. I'd have to create a whole new GUI to allow that kind of sophisticated logic, and I think at that point you're going to be looking at a more complex, but more capable, system like kOS anyway. The one thing I've considered implementing is a system that allows smart parts to directly trigger another smart part, or group of them, without having to use the limited action groups by using a tweakable "reference number". Sort of like the way channels currently work with the radio smart part. However, I'd have to do some pretty extensive tests on that one to make sure it still fits in with the original vision of Smart Parts. So even that is pretty far off in the future. I'm thinking my next project is going to be to create the AP/PE detection smart part which was requested, since I can see some nice uses for that.

No mention of me? I'm devastated! Just kidding. Dtobi did the lion's share of the work. He did a great job making the parts in the first place, afterall. Me? Well, I don't make the parts... I just make them better. Exactly right. It monitors whatever fuel tank it's connected to and performs an action (staging, action group, or play a sound) when it's empty. Very useful. The mod also has a bunch of other parts beyond that. The information in the OP here is a bit out of date. For example, the altimeter doesn't only work on descent any more. It can be used to, as Hyperbob pointed out, jettison your fairings or extend antennas when your craft hits a specific altitude during ascent. Also, we've got another release coming soon that fixes a couple of bugs and adds tweakable staging and thrust to the fuel valve. Just the ticket for nudging your shuttle's external tank away without having to use solid rocket boosters.

First, good news all around everyone! I finally solved the empty stage creation bug, so with that perpetual thorn in my side finally removed I was able to devote a bit of time to adding new features. Which in this case means... you get (minimal) thrust from the fuel valve and it supports tweakable staging!!! Just the thing for nudging that heavy external tank away from your shuttle without having to use unrealistic solid rocket motors! I'm coordinating the next release with DTobi. I'm not entirely sure when it's going to happen, since he's got some thing's he's finalizing for his SSE mod. Should be soon though. Honestly, I like this idea. I really do. It's something I've thought about, in fact, but I just don't see any way to make it happen without turning the tweakables GUI for the altimeter into a horrible mess. I'd likely have to use some sort of slider to select the target celestial body like what is currently done with the action group. It would be messy. If you can think of some way to make the GUI work though, I'd be happy to consider it, and I can definitely see a use case scenario for it. This is an interesting idea, if you're suggesting what I think you're suggesting. A smart part that can activate or deactivate fuel tanks on staging or an action group? The main use I can think of for this would be RCS tanks, which feed throughout the entire vessel. So this would allow you to prevent the service module from stealing monopropellant from your lander, for example. However, the main problem there is that the small RCS tanks don't support surface attachment, which would be required for something like this to work. Frankly, I don't even know if it's possible on parts that do support surface attachment, but I suspect that it is. Cakeofruit, how do you envision this part being used?

Alright. Well, I guess we can close the case on this one. I can't find a good way to do this, so I'm just going to stick with manually activating each part in a stage, moving that part to the vessel's current stage, which removes the visible empty stage, and then using Stage.ActivateNextStage() on the active vessel to remove the invisible empty stage. Not pretty, but it does seem to work. Thanks for the input Faark.

Still no progress and I've tried just about everything I can think of. However, an idea just occurred to me. I'm at work at the moment, and so can't really investigate, but can't KOS stage non-active vessels? I seem to recall watching a video of a dual launch that involved simultaneous staging of the active vessel and it's KOS controlled counterpart, which was flying around 500 meters away. Anyone know if it's remote staging system also leaves empty stages, or if not, how it works? Once I get home I'll investigate this some more.

Okay. Well, I'm still trying to figure out a solution to the staging creating an empty stage bug. Unfortunately, it's proving to be much more difficult to fix than I would have thought due to the nearly non-existent API documentation and poor staging logic in KSP. In the meantime however, here's a hotfix for the non-physics eject bug. Just replace the DLL in the SmartParts plugin folder with this one. Let me know if this fixes your issues, Benoit. https://drive.google.com/file/d/0B9K8KY8RgD-qNTFTTVNhbHVwVTQ/edit?usp=sharing

I'm curious if there's an elegant way to trigger a stage event on the non-active vessel. Simply using "Staging.ActivateNextStage()" isn't an option unfortunately, since it always stages the active vessel, and there seemingly isn't any way to feed it a vessel variable. I had high hopes for "vessel.ActionGroups.ToggleGroup(KSPActionGroup.Stage), but it apparently does nothing useful. I've looked into a few other, less elegant options, such as iterating through each part in a stage and manually activating it, and while this does work it doesn't clear out the stage, since KSP thinks that stage is still valid. Deleting the stage after that and redrawing the staging icons also seemingly didn't work. So far, every alternate method I've found of staging a remote vessel comes with it's own set of serious downsides. Anyone have any ideas?

I'm curious. Does this happen with any of the other smart parts? For example, try firing that action group via timer. See if it still happens. Also, what would really help is if you could make a craft that experiences this bug out of stock parts, procedural fairings, and the smart parts. Then upload that craft file somewhere publicly accessible, like Google drive. That way I can test it on my end and hopefully recreate it. Right now fixing it is going to be tough, since this isn't something I've experienced and so I don't really know what might be causing it. EDIT - Actually, nevermind that. I think I found the problem thanks to a bug report on GitHub. Apparently staging events have to trigger from OnUpdate rather than OnFixedUpdate. This is super simple to fix though, and I'm testing it now. EDIT2 - Okay. Yeah. One bug down. If only they were all that easy to fix. Anyway, I'm going to be looking into some other bugs such as the staging event leaving empty stages, so once I get that fixed I'll go ahead and put up a hot fix download. Hopefully tonight. I don't have access to the OP though, so it's going to be in this post probably.

First, sorry for the delayed responses, everyone. I've been so busy settling into a new job that I just haven't had much time to deal with KSP lately. Anyway, back on subject, that's very unusual Benoit. I've had no problems using the altimeter with procedural fairings and, indeed, that's one of my primary uses for it. Can you put together a test craft that uses just stock parts, the procedural fairings, and the smart parts mod that displays this behavior? I'd like to look at it. From a game perspective there really shouldn't be any difference between a smart part firing an action group and it being done manually. Still, perhaps you've found some really obscure bug that I need to fix. Thanks for the report.