AHHans

Well, apparently there is. Otherwise the hinges wouldn't consume power trying to get to their target position. But that also means that the hinges are not locked! If you want your rover to be just packed in and not move until you are landed on the Mun, then I'd suggest to set the hinges to locked in the VAB and only unlock them once you are on the Mun. I'd also suggest to set up (an) action group(s) to unlock them when they are needed.

Thanks!

After many tries the engineers at AHTech industries have managed to wrestle the FMRS time-jumping technology into submission. The clou was not to modify the craft but to change the mission strategy: by pre-positioning a refueling tanker in Eve orbit, the orbital module can rendezvous with it and once it is in physics range on can switch control without FMRS resetting. (And once the orbital module has landed FMRS is willing to merge it into the save with the landed carrier plane.) The (mostly) full photo story of the trip can be seen on imgur: https://imgur.com/gallery/qRW7TlA here are some highlights: The Eve Reusable 3 (yes, a totally ingenious name, I agree) on the runway. And on landing approach after cheating into Eve orbit, de-orbit burn, and aerobraking. After craft separation, ditching of the temporary interconnect, and re-attaching with the Klaw. Using the mining gear on the carrier plane for refueling. It can go under electrical power to above 10 km asl. the next stage is using the rocket engines on the carrier plane to get even higher. This is also when we need to arm FMRS. After separation and most of the burn into orbit. The orbital module coasts to its circularization burn. (With about 250 m/s dV left to rendezvous with the tanker in orbit.) [Note, the following screenshots are from another run. The images above are from before I figured out how to deal with the FMRS issues. For the following I loaded a save with the craft landed on Eve and ready for take-off after refueling with the mining equipment. Unfortunately I also lost the screenshots with the return of the carrier plane to ground.] The rendezvous maneuvers to meet the tanker in Eve orbit have to be done with the orbital module. But once the tanker is in physics range one can switch to it to finalize the docking without FMRS resetting. Refueling the orbital module, de-orbiting, and landing the orbital module is then comparatively trivial. Once the orbital module has landed one can use FMRS to join it with the carrier plane, and the carrier plane can come and pick up the orbital module for another go. In conclusion: this craft has two major drawbacks. One is the strict limits on what you can do while in orbit: no switching to another vessel outside physics range, no going back to the KSC to launch a tanker or so. You are in a state of limbo until the orbital module has landed and FMRS can join the saves. The other one is that the combination of the telescoping pistons and the landing gear doesn't work too well. When loading the craft with the pistons locked, then the actual extension of the pistons is not the target extension that was set. So when they are unlocked they "jump" to their target, and this tends to over-stress the landing gears. And when not locked the pistons are fairly wobbly... But it works! I already have another craft in development, which is kind of the merger of this one and the Eve Infinity by EveMaster. So I don't plan to put the craft file on KerbalX (unless you ask me to), but you can download it here: craft file

The accident investigation team has finished its analysis of the incident. Careful study of the wreckage showed that no remains of the central fuel tank could be found, disintegration of this central part of the craft can also explain the scatter of the recovered wreckage parts. Therefore the investigation team considers the following chain of events to be the most probable course of the accident. At the time of the accident the small (FL-T100) fuel tank at the bottom of the main fueselage was the root part of the craft. It was connected to the central fuel tank (a model X200-32 from Rockomax) via a TD-12 decoupler and a BZ-52 attachment point. When the small fuel tank was detached by triggering the TD-12 decoupler the X200-32 tank became the root part of the craft because the specialized construction of the BZ-52 makes it an integral part of the X200-32. The main cause for the disintegration of the X200-32 tank are still unclear, but it is assumed that the rapidly changing loads of several autostruts snapping to it (including an autostrut from itself) exceeded the structural limits of the X200-32 tank. Once the central tank stopped connecting the different parts of the vessel, the reinforcing EAS-4 strut connectors between the - now separate - parts of the vessel disconnected. Leading to a complete collapse of the structure. It was concluded that the underlying cause of the incident was the change of the design to work around a limitation of the FMRS time-jumping technology. In this change the root part of the overall craft was changed from being on the carrier plane to being on the orbital module. This cause the small connecting part becoming the root part of the carrier plane after the initial separation of the two crafts. As the FMRS time-jumping technology has still proven to be unreliable even in this configuration, this change is now discouraged.

There are some rounding errors when you change from one SOI to another SOI. These can easily change your orbit at the other end of an interplanetary transfer. I believe the errors are minimized when you don't have the transiting vessel in focus (or within physics range in general).

How about you have three KAL-1000: one for walking in a straight line, one for a right turn, and one for a left turn?

I haven't experimented to figure out what the order of the priorities is, but indeed any robotic part can only be controlled by one input at a time. Well, at least with "absolute control", with "incremental control" you can have multiple inputs controlling one robotic part. Ask Squad to change / fix this? There is already a related issue on the bug-tracker: Please allow multiple KAL controllers to steer one device (f.e. for a real quadcopter) P.S. In regards to the pitch / yaw / roll axis groups: please note that they are ignored by SAS. See also:

Yes, how much of the craft has to survive the landing? Just the capsule? And what is your definition of "horizontal landing"? Any landing without the help of parachutes? Is it allowed to use a parachute to slow down, if it is ditched before landing?

Are you sure that you actually locked the hinges (enabled the servo lock), and that the lock was actually set? The lock on robotic parts is notorious for not setting because "the part is still moving", so you may have to try a few times for the lock to actually set. A robotic part that is successfully locked should not consume any electricity. [...] Actually they don't consume electricity when they are not moving and are at their target angle, locked or not. But if they don't have the torque to move to their target angle then they won't lock and will keep consuming electricity.

Well, the maximum range of the servos is not a hard stop, it only limits the range to which you can set the target angle. But, yes, this is IMHO an application for servos, not rotors. If you set the target angle of the servo to the "neutral" (or default) position then you can use the maximum torque setting to set the "spring strength" that will return it to that position. I.e. if you set that to a low but not zero value, then it will return to that position if no other forces are present, but move fairly freely when there is an external force. Or if you set the maximum torque to a higher value then you'll have some kind of spring. (That will keep draining electricity, but well...)

I have the situation, that I have a carrier plane that grabs an orbit stage with a Klaw, flies that out of the worst part of the soup around Eve, then releases the orbit stage and flies back to the surface, while the orbit stage continues until it reaches orbit. I can fly both stages separately but haven't managed to merge them (yet?). Because I use the Klaw, the "master vessel" that I control immediately after separation is the carrier plane. I can land the carrier, and then jump back to the orbit stage and fly that into orbit. But then I cannot merge the orbiting stage to the save with the landed carrier. Is there a way to deal with this?

Quick update here. AHTech's reusable Eve transportation system is still in development. Unfortunately recent testing has been plagued by Kraken attacks. Here is the result of dropping a small, empty fuel tank from the bottom of the carrier plane: The accident investigation is still ongoing. After finding only low to moderate amounts of part clipping, the investigators are currently looking into the Kraken attracting properties of autostruts.

What exactly do you mean by that? You have a target in orbit that you are approaching, and once you get to 2.2km your relative velocity drops to zero so that it suddenly changes its orbit? I don't use mods much so I probably won't be able to help you, but I guess it will be helpful if you could post a list of all the mods you are using.

Hi @Dezeat, welcome to the forums. You cannot change the angle at which they are docked while they are docked. What you could do is to undock, align the vessels better, and then dock again. On its own this is not too complicated, but also not that easy for a beginner. An additional complication are the extended solar panels: they are pretty brittle and tend to break when hit with a craft. So while it is possible to undock, re-align, and dock again, the margin for error is pretty slim.

Sounds good so far. Please let us know how it turns out. You should also consider uploading your craft to kerbalx or so when you are done with it.

OMG, it's full of hinges! (SCNR. ) I just went through and set the lock on all robotic parts. Aaaand, well, it doesn't fall apart on the launchpad anymore, but stable is different. It is also prone to spontaneous unscheduled disassemblies (AKA Kraken attacks.) when you unlock a part, even when doing that in orbit. You might get it stable with careful use of autostruts and locking/unlocking. (Setting robotic parts that don't need to move to unmotorized might also help.) But in general I'd suggest to use a lot less robotic parts. If it doesn't have to move, then don't use a robotic part. (I don't believe that the real JWST has so many moving parts.) It won't look as good, but it has a higher chance of actually working.

Well, if you have questions, then please ask.

Well, there's worse things in life than watching the Gruffalo, and worse things for a 5yr old to watch. My nice is now past that stage... Which also makes it good for interplanetary transfer stages. There are also drawbacks to the NERVs, but it seems like you have them under control. I guess I like to roleplay my Kerbals complaining about the radiation risk, so I avoid them if there are other reasonably convenient options. (Yes, yes. They probably get more exposure from the cosmic rays and solar wind during the transfers than from a NERV at the other end of a big fuel tank. But who said that Kerbals are logical?) Yupp, that's the grindy part of a career playthrough. But it's a good time to fill up your rooster with spare Kerbals. So you can afford to scatter them all over the system later in the game. (I like to refueling stations / mining outposts around every major body.) Have fun. Although I would have thought that a large package of Valium would be more useful than a defibrillator.

Yes, but, e.g., "in flight above 17,000 m" means inside the atmosphere, while "in space above 17,000 m" means outside the atmosphere. Are you familiar with how to navigate to contract sites otherwise? (I mean the "select marker in map view, activate navigation, get there via the navball" part.)

Did you set the lock on all the robotic parts in the VAB? That makes the whole structure a lot more rigid. It also allows autostruts to traverse the robotic parts, though I would not recommend to set autostruts on the robotic parts themselves. (See: https://forum.kerbalspaceprogram.com/index.php?/topic/185699-rotation-servo-m-25-fails-to-move/) But e.g. having "autostrut to grantparent" on the first non-robotic part connected to a robotic part can do wonders for the stability of your craft. (A locked robotic part will also not consume any power, even under acceleration.) I also recommend to not use "toggle lock" on an action group, but use two action groups with "remove lock" and "engage lock" if needed: setting the locks has a high chance of failing because "the part is sill moving" (yeah, sure...), so you may wont to hit that "set lock" button a number of times until all locks are set. P.S. Do it the Kerbal way: Add more struts!

Don't you think that the agency that sent the poor Kerbal into their predicament will want to debrief them before they officially join your crew? I bet there is a lot of paperwork to be done. (Anyway, I don't have a better solution than @Aegolius13: use the cheat menu.)

Indeed, as I wrote on the bugtracker: the yaw, pitch, and roll axis groups behave like custom axis groups that just happen to be matched to the same keys as the controls for the craft. If you are as unhappy about this as I am, then I encourage you to upvote the issue on the bugtracker as describe here:

And they are never tired! They just get (even more?) cranky when it gets late... Although you could think about playing KSP with your granddaughter. There may be more explosions than usual, but she may enjoy it. I don't use the Nerv much, and when I do then for interplanetary transfer stages. (And SSTO spaceplanes, but there also only for the vacuum part of the journey.) I don't recall any lander of mine that doesn't use a terrier or poodle. (O.K. Landers for vacuum bodies. Eve is a class of its own.) Better Rest and Recreation? Man your Kerbals have it sooo good. When mine are not on a mission or in training then I just stuff them into a handy cupboard in the astronaut complex. SCNR! Yeah, we've all been there... And these lazy tourists don't do EVA to use their personal parachutes. Too true. But it might be a reason not to play KSP with your granddaughter.

Herzlich willkommen @Rickental Yes, another German here. I don't usually check the German subforum, so I do suggest to try the general forums first. Your English doesn't have to be perfect, as long as we can understand what you want to say it's fine. And if you are totally unsure, you can add a German version to the English version, then someone will be able to translate. About the fontsize: there are options in the settings menu(s) to scale UI (i.e. the fontsizes). What is IMHO a bit confusing is that the settings are context dependent, so at the KSC, in flight, and on the map screen you get different settings for the UI / fontsize scaling. So if you run into problems: try hitting <ESC>, select "Settings" and check if you find a UI / fontsize scaling slider that may help you.

Welcome to the forums @Dumb kerman. Rest assured, you are not the first one to suffer that particular mishap. Don't worry, Jeb will wait on the Mun until you manage to arrange for a rescue mission. (Kerbals are remarkable that way, they have no problems staying for years in a tiny capsule.) During flight you can also press <F3> to view the mission log. In there it will say which parts got destroyed after a mishap.