AHHans

I don't really understand what you want to do. But if you set the "play position" input of a KAL to the yaw axis and set that to "absolute control", then the play position of that KAL will be in the center if no yaw key is pressed and will move to the start or end of the tracks when yaw keys are pressed. (It will also not be moved by SAS or manual trim due to issue #22946.) So you can have the default value set in the center of the track on that KAL and the left or right yaw values at the start and the end of the track. What keeps you from setting the play length of the KAL that you want to control with another KAL to 1? If you have one value that is controlled by two KAL, then the one with the higher priority will overrule one with a lower priority. E.g. if you have one KAL giving control inputs for 100% and another giving inputs for 0%, then the resulting value will be 100% if the first one has higher priority, 0% if the second one has higher priority, and 50% (the average of all KALs) if both have the same priority. One more issue to note is that KAL don't always generate control signals, they only do that if their play position is set to a "new" value. So if you set the "play position" input of a KAL to an axis with "absolute control", then this "absolute control" will continuously set the play position to the current value which causes the KAL to generate control signals on all its outputs all the time. But if you set it to the same axis in "incremental control" then the KAL will only generate control signals when you are actually moving this axis. When the axis isn't moving, then no control signals are generated and the setting of a target may be overwritten by e.g. a lower priority KAL that is generating control signals (for whatever reason). Has this answered your question(s)?

Ah, I haven't considered that. My approach to that issue was to put the plane into a stable configuration, nose down a bit as it rises over time, and then start answering questions on the forums / browse the web / take a shower / whatever.

P.S. I finally made my 3 person Eve expedition ship available on KerbalX: Eve Anywhere. In particular in 1.8.1 it is rather finicky to fly, but it does work and I use it for what I think is what you want to do. P.P.S. When you want to change your question, it is better to add a new reply to the thread rather than just editing the original post. I only now saw that you changed your question after I wrote my last reply. Well, I made only craft that used the BG propellers to ascend to at least 10km on solar power. From there I need about 5000 m/s dV (at the pressure there!) to get to orbit. And of course a TWR greater than one until I'm in a high enough ballistic trajectory. You want to throw away everything that you don't absolutely need before your ascent. Put ladders, landing gear, and other similar stuff on decouplers and stage them away when/before you start. Part of my design process was to go through every single item on the ascent module and think if I really need it, and it the mission will fail if I don't have it. (Yes, yes, and then I added some extra science experiments, but that was after I saw that it will work.) Another thing that adds extra drag is uncovered connection nodes. Even stacks with nosecones add drag, so try to avoid side-mounted structures if possible. The number of stages doesn't really matter. Allegedly there are Eve SSTOs, but dropping tanks every 5 seconds at the start is also a valid option. Some other tips: Pay close attention to the ISP of the engines in the dense atmosphere on Eve, most people use the vector or aerospike because they suffer the least. Close to the sea level every meter of altitude that you start higher helps - mostly because of the ISP of the engines. Many rocket-only crafts need to start from a mountain in order to make it to orbit. Until you get to 20km or so you just go straight up. You need to get out of the worst part of the soup around Eve before you can start a gravity turn. That also means that for the first stages drag is less of a problem. (I.e. you can have some draggy parts on your craft, if you stage them off soon enough.)

Not really. As you already remarked, when you dock (or attach something with a claw) you are combining two vessels into one. And this will be indeed one combined vessel, with only one root. This new root will be the original root part of one of the two docked vessels, but I don't know how exactly this is chosen. It could be the root part of the older (launched earlier) vessel, or of the one that you were (not?) controlling when the docking happened, or something else. No. (Well, "not dock"...) I believe that the "one root part per one vessel" and "docked vessels become one vessel" mechanic is seriously deep in the guts of the KSP code. Not in the game as is. That would require either a mod or a change in the game. And while I guess that this would be easier to implement than the "don't change root" issue, I wouldn't hold my breath for this to be implemented in the stock game. (Feel free to open an issue on the bug tracker though.) No really good ones, sorry. I'm not sure if suggestions like "launch fewer but bigger parts" or "have fewer docking ports" will actually help you. I do have some mistrust of the modded parts, here the weldable docking ports. But this isn't based on any real knowledge and more on my ignorance of these parts.(*) So it might help to re-build the station with only stock parts, and no autostruts to root or heaviest. But a) I think you probably already tried that and b) I don't really know if it will be better or not. Yes, I think so. If you are low on memory, then more RAM would help, but for this it is mostly single-thread performance of the CPU. But it will only mitigate the problem not completely remove it. I.e. if the station is big enough then you'll always have slowdowns at some point. (And, no, a modern supercomputer also wouldn't help: they get their performance from having many threads, not so much from single thread performance.) P.S. Sorry, that my comment isn't more helpful. I did think about it for a while, but I just don't have a good idea how to solve your problem(s). P.P.S. (*) In German we have a saying "Was der Bauer nicht kennt, dass isst er nicht." The literal translation is "What the farmer doesn't know, he won't eat." but I don't know any good English equivalent of this - which is interesting on it's own now that I think about it, but I digress.

Either that or because you have the control point facing up. The latter should be easy enough to check: are all the wheels running? In the same direction? But from the way the wheels sunk into the surface I believe that the orientation of the wheels is indeed the problem: I think the game doesn't really realize that the wheels are (supposed to be) in contact with the surface. Thus the "sinking in" and if they aren't in contact with the surface then they also don't push your rover around when they turn. I've had similar problems with the landing wheels on some of my spaceplanes on Gilly. Where the game insisted that I was in immediate danger of crashing and thus didn't allow time warp or vessel switching, because it didn't register that the landing gear was already on the ground.

O.K. O.K. I'll put it onto KerbalX. But it doesn't fly well (I think worse in 1.8 than in 1.7.3), and it suffers terribly from bug #23924, so much that I cannot land without using the cheat menu. Edit: You can find it here: Eve Anywhere

There is a scenario "propulsive landing" or so, in which you are asked to land a booster. (Which has been inspired by SpaceX. The main problem in the scenario being that you have very little fuel.) [...] O.K. @Linkageless has already answered in the time I needed to make sure that Jeb doesn't miss Jool. The one thing I still want to add is that don't rely too much on the CoL as displayed in the editor: when you are high and fast (e.g. when re-entering from a (sub-)orbital flight) then the drag can dominate the aerodynamic forces. And if you have draggy parts forward of your CoL, then that can cause unwanted surprises.

I wouldn't call that "lying". Is a strategy game lying to you because it doesn't display a concealed enemy unit in your field-of-view? What is a valid criticism of KSP is that it doesn't actually teach new players all the concepts that are necessary to succeed at it. KSP-2 claims that they will do this better, but how successful that will be remains to be seen. P.S. And if you think that implementing multi-body physics would make this easier, then good luck finding stable orbits around the Mun.

Oh, but I'm 99% sure that an SSTO with the BG rotors cannot be done. At least not without massive part clipping, part offsetting or similar shenanigans. The propeller blades add significant drag but also have a hard-ish limit at 20km altitude on Eve. That together makes it so hard to build an SSTO, that I won't bother trying anytime soon. But that "folding-wing propeller plane" that I was talking about is not an SSTO, why should it be? My version is fairly hard to fly without breaking anything, that's why it isn't on KerbalX (yet?). And, btw., what you call "proof of concept" pretty much describes my Eve Transportation System (including the robotic hinges to re-attach the two parts). P.S. Sorry for the self-promotion, but you set it up so nicely.

Well, in addition to mining it, you could: stick a couple of parachutes on it and land it on Kerbin (try to) land it on the VAB (try to) smash the VAB with it collect a bunch of them and give Kerbin a fashionable asteroid-belt convert it into an airplane: Flying-Rock-Kit Or try to come up with an even more crazy idea. One more thing I just recently noticed: some (all?) asteroids have more than 95% ore, which makes them potentially the most efficient fuel tanks. (You do have the overhead from the drill, converter, ore tank, electricity supply, and cooling, but with a large enough asteroid this shouldn't matter much.)

How high was the AP of your orbit around the Mun? If it was above 2.23 Mm, then you just left the SOI of the Mun. Without having patched conics unlocked the map view will only show you the orbit around the current CB as if it's SOI was infinite. And when you change SOIs then gravity suddenly changes and your trajectory will be drastically different.

Just doing some manual launches. The first few tries were total crap: "Oh, I should have staged that part away ages ago."; "Errr, no. Going horizontal at 12km is not the way to go to space." and so on. My launch strategy is: tilt over by ca. 5 - 10 degrees at 30 m/s, set to prograde at 100 m/s -- 200 m/s (depending on craft and how much I actually turned), burn full blast until AP of 80 km is reached, coast and circularize. My first real contender felt way too flat (spent ages at 16 -- 36 km altitude, AP went down from 80 km to 65 km during coast...), but: 1511 fuel and 3384 m/s The second one was flatter than my usual launches at the start but "felt good" for the second part of the ascent: 1573 fuel and 3440 m/s The third one was more like my usual launches up to 10 km altitude but then felt fairly steep even for my usually steep launches (with a 1000 m/s circularization burn): 1435 fuel and 3312 m/s And the forth one was about like the third up to 10 km, but after staging away the first two stages I throttled down (and up after the 3rd stage) to keep the TWR at around 2, requiring a 610 m/s circularization burn: 1522 fuel and 3393 m/s Same here! What I take away from my tries is: throttling down does save dV when the alternative is a too steep ascent. And: any somewhat decent gravity turn will be within 150 m/s or so dV of an optimal one. (But I guess I knew that already before.)

This bug has been fixed quite some time ago. So I'll suggest to the moderators to lock the thread.

I finally decided to show off the best craft that the engineers at AHTech Industries came up with. All the craft can be found on KerbalX. And today I get the ball rolling with a case of space engineering that was sorely missing from the Kerbal universe: the Very Kerbal Array. For many years Kerbals have looked to the sky, now they are also travelling to the bodies in their own solar system. But there is much more far away: new star systems, star clusters, quasars, new galaxies, giant molecular clouds, supermassive black holes, even bigger bangs, and sooo much more. Since the invention of the radio the astronomers have been listening to the stars on radio frequencies with increasingly bigger and complex telescopes. But now they got to the limit of what can be done on the surface or Kerbin: the atmosphere and Kerbal made interference make detecting weak signals harder and harder. So the solution is to go to space, and the engineers at AHTech Industries came up with the solution: the very Kerbal Array: This is a space based radio interferometer, with 19 of the finest radio dishes that are currently available. We at AHTech Industries developed a sophisticated unfolding mechanism, that allows this to be packed into an affordable fairing and launched with a medium sized launcher. We combined it with a powerful onboard computer for signal correlation, data analysis, and navigation. The antenna spacing gives it a good UV-coverage with low sidelobe levels in the synthesized beam, even for a snapshot observation. For a regular observation it gives essentially filled UV-coverage with even a small fractional bandwidth. And being a spacecraft it can not only point straight at a target - making the quality of the observation independent of the target's declination - but it can also rotate during the observation to either generate more sensitivity on fewer baselines or to fill the UV-plane even during a short observation. Launch this and your astronomers will sell their firstborn assistants into slavery(*) for the opportunity to do observations with it. With a combined antenna power of 910G - or more than 3.6 times that of a fully upgraded tracking station - it can also be used to facilitate communication with weak transmitters in the outer solar system. But who would want to use this fine piece of space exploration hardware for such pedestrian tasks? (*) Which might be to the benefit of the assistants depending on the professor in question. P.S. Inspired by "KSC ‘Chessboard’ ground relay" from TheFlyingKerman, and real life radio telescopes like the VLA and others that I worked on.

@James Kerman: Thanks! And please go ahead and steal my ideas! It's not like I'm not doing the same.

This project started when I got a contract to build a space station around Jool "into" a class-D asteroid. In contrast to KSPs ability to have surface outposts sink into the ground, building intentionally into an asteroid is beyond even the capabilities of the engineers at AHTech Industries. So the decision was made to build the station around the asteroid. Because I'm quite flush with funds in my current career save I decided to add all the bells and whistles I could come up with for a station: plenty of capacity for fuel and ore - This is the main practical value of my stations after all. ore processing capability enough electricity generating capacity to run at least one ISRU unit around Jool - From solar panels and RTGs. big counter-rotating gravity rings - So that I can station lots of crew in the Joolian system without having to worry that they go crazy or too weak to work in gravity. a copious number of docking ports of all sizes - What use is a station that you cannot dock to? having the asteroid integrated into the station so that the Kerbals can view it from their living quarters - Being far away from home you need something to keep you motivated. all the other stuff that a self-respecting space station needs - labs, non-rotating crew quarters (err... zero-gravity gyms), relay dishes, propulsion to get into position The result is the Nauvoo Asteroid Station. Unfortunately it is still too small to house a class-D asteroid, but it can house a mid-sized class-C one. I was also lucky to find a suitable magic asteroid that fits inside. My first idea when I saw the completed station was to call it the Behemoth, but this name sounded too militaristic so I decided to name it the Nauvoo instead. (Yes, totally subtle reference here.) P.S. AHTech Industries does not endorse the following behavior:

Well, my design was also kind of a self-imposed challenge to design ad quadcopter without reaction wheels. After I thought that this should be possible. With the first version - that used extra servos for collective pitch - I could increase precision by reducing the range of the servos. I also always keep a PAW of the blades open so that I can see the actual value. I guess I just prefer the fast and fairly direct control over the climb-/sink-rate over the less finicky control. With the control direction being straight up, I can set SAS to "surface - radial-out" which will keep the quadcopter steady, then I can use pitch and yaw control inputs to nullify my horizontal motion (center the pro- or retrograde marker on the navball). And once it is zeroed out, it stays zeroed out. [Looking at your screenshot] Well, I added a probe-core that supplies "radial-hold" in SAS. You might want to give it a try yourself. One drawback of my design is that the control direction has to be straight up! If you want to change that then you would need to change the setting on the blades (for which direction they act as control surfaces) and the action group that is currently bound to roll control. That makes long-distance navigation rather cumbersome...

Do you still have that problem? FYI: this "#autoLOC_XXXXXXX" is a string in the part (contract / whatever) description, that is supposed to be replaced by the string from the file containing the text for you chosen language. That way you have all the text in one file, which makes it easier to translate it to another language. Which language are you using? (There was recently a bug that the non-English strings weren't correctly replaced.) You should probably also ask in the corresponding technical-support subforum.

I haven't seen that particular kind of behavior (of bug) in an unmodded install, So my guess would be that a mod or a combination of mods triggered a bug in the robotics implementation. But the real answer is that I don't know.

Yes, that would also be my approach. I'd attach the hinge - I-beam - leg to the fuel tank and then the hinge - piston - hinge to the fuel tank. But at the lower hinge of the latter I would also add a cubic octagonal Strut and add then strut that to the I-beam. I tried it, and got it to work after a fashion. But not reliably, something always got stuck after a few cycles. One important thing is to set the hinges and piston to be "free" after a power loss, and not to set autostruts on the robotic parts themselves. Also don't try to extend the landing gear when the hinge between tank and I-beam is not locked! Otherwise I got 100% kraken-bait. And finally: I think just the lower part, without the piston and with an autostrut on the I-beam, would work just as well if you only move it in microgravity - with no forces on the structure - and lock it whenever there is some load on the structure.

Well, there is no right(TM) way to play KSP, so you'll have to decide what you like doing yourself. My comments about the deployed science: I deployed a station on Kerbin mostly for completion, the amount of science you get there is minimal. The most "interactive" deployed experiment is the seismic sensor: that doesn't just give you the science over time, but you need to so something to get the science. Getting the science from Kerbin is easy: all the stuff that just happens to fall of your rockets during launch will trigger enough seismic events to get the full data. Seismic science on CBs without atmosphere is also easy just crash some leftover junk (spent stages) onto them and you'll probably get the full data. Duna was hard, I actually had to build a dedicated impactor craft to get through the atmosphere with enough energy. (And you'll need to follow it through until it crashes, AFAIK it doesn't trigger the seismic detector if a craft is just deleted in the atmosphere.) Eve is a *bleeep*. My first two dedicated impactors that I "just" dropped from orbit gained me a total of 5% of the science. The next two are "cruise missiles" in order to hit close to the sensor, and with rockets for a final sprint to maximize impact energy. But those are currently in transit. There are also the new surface features. Hunting for them on Kerbin and the other CBs is quite fun. (The green sandstone on Minmus is hard to find, but it can be done!) It also gives some invective to rover around Kerbin (which I didn't really do before). And finally there are the new robotic parts. They open up a whole new world of design opportunities. Just flying around Kerbin and doing aerobatics in a propeller plane is fun. They handle a lot different than a jet plane: you can essentially stop a propeller plane midair (or on the runway, if you really have to, ) by setting the blade pitch to zero. Want to build a folding-wing propeller plane to explore Eve? That can go anywhere on Eve on solar power and then ascend through the thickest part of the souposphere on solar power before starting the rockets to get back into orbit? Can be done!

Well, for the time being I've given up trying to get a propeller powered vehicle to work on Duna. (But maybe I should try again with the ducted fans, allegedly they work better than the normal props.) The quadcopter I made for Kerbin (current version here, with most of the instructions here) is controlled in the way that the RPM of the rotors is kept constant and the lift is controlled by collective pitch angle of the blades. Because in a quadcopter the blades are always in the same general direction from the COM of the craft (i.e. the blades of the front left rotor are always to the front and left of the COM during the full rotation of the fan, which is in contrast to the blades of a classical helicopter), the blades can be used as control surfaces without the logic of KSP freaking out. So they can be used for pitch and yaw control (control direction is up). The difference between the two designs is how collective and cyclic (well, control) pitch is implemented: the old version needed extra servos, but since 1.8 the deflection angle and the authority limiter are separate on the blades so no extra servos are needed anymore. Roll control is done by changing the RPM of the clockwise and counterclockwise rotation fans via a KAL.

O.K. Good to know that it works now.

Gnnnaaahh! Sorry, my bad. What I meant with "fixed epoch" was that I believe that KSP uses a fixed reference system, i.e. the reference direction for the longitude of ascending node. In real life the astronomical reference systems wobble around over time, so they are defined at an epoch and you can have fun times (or a computer and a preferably a program that someone else wrote ) converting from one to another. But the reference time for when this set of orbital parameters was valid (in particular: at which time the craft was at the given mean anomaly) is something else. And I didn't see that it was that what you meant. In part because when you set an orbit with the cheat menu then I expect that the reference time taken is that current game time. No, I think you are completely correct.

Kind of what I thought. Is the craft designated as debris or an asteroid (in the craft naming dialog)? (I don't really think so, because IIRC that means that you don't have control of the craft at all when you get back to a craft that is designated like that.) So my best guess is that there is something wrong with your KSP installation. Either some problem with one or more of the mods that you are using, or your installation of KSP itself is corrupted. Hmmm... does the probe use parts from mods or is it stock? If it is stock, then can you put the savefile somewhere where I could have a look at it? Edit: O.K. our postings overlapped. Yes, sharing the savefile might help.