AHHans

Members
  • Content Count

    433
  • Joined

  • Last visited

Community Reputation

255 Excellent

1 Follower

About AHHans

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That shouldn't happen, if everything works then you can load any (non corrupted) save-file at any time. Even one saved in another playthrough. (E.g. loading a career mode save-file in a sandbox game.) So I think this is less a gameplay question, but more a case for tech-support. For this I also suggest to have a look at: https://forum.kerbalspaceprogram.com/index.php?/topic/83213-stock-support-bug-reporting-guide/
  2. One neat trick that I got from a Scott Manley video is to put flags at the ends (just outside of) of the runway. That done, you can set the nearer flag as the target and have a much more precise marker for the direction in which to fly to get to the runway - both in azimuth and elevation(!). Then you should position your craft so that this marker is exactly at the 90 deg or 270 deg line of your navball. And finally: training, training, and more training. I, too, used to suck at landing in KSP. But after doing it often enough I now manage to hit the runway (and not crash) more often than not.
  3. Have you tried double-clicking on the craft that you want to target? (In the non-map view, once you are close enough that you can see it.) Oh, are you playing on PC or on console?
  4. Oh, I didn't want to say that it is impossible to run out of Xenon, or anything like that. And having "infrastructure" (i.e. different craft that mine/collect the Xenon and other that actually use the Xenon) is certainly something that can be done in KSP and makes some sense. (Might even make more sense in real life - if we ever get that far to build serious infrastructure in orbit of other planets.) I just wanted to give some possible reasons why SQUAD didn't implement in-situ Xenon mining.
  5. I think another reason - both for in-game and in real life - is that ion engines are not really suited for planetary landers. If a body has enough gravity to keep an atmosphere, then you cannot realistically launch with only ion engines. Distilling Xenon out of the soup that surrounds Eve should indeed be rather straight forward, but then what? You don't have enough TWR to get off the ground. In-game I also didn't feel the need for mining Xenon: it is easy to bring enough Xenon for a couple of hours at full throttle. Mining even more Xenon would mean that I would have to wait even more hours while the craft slowly accelerates...
  6. Don't worry, you were right. The default is the longest variant. But to get on topic again: if you are still struggling, then you can attach the next stage without attaching any engines to see where the attachment node of the engine plate is. That should be a bit easier.
  7. To summarize the answers already given: you lost touch because you left communications range of the HG-5s. (They are only good for communication within the Kerbin SOI.) A very helpful explanation of the communication in stock KSP is the wiki page about CommNet.
  8. One comment: the engine plates have different variants that gives them different lengths. IIRC the default is the shortest variant, in this case the lowest node may not be the one from the engine plate but from the central engine.
  9. Sounds to me like you are having trouble with the "differently curved" issue in LKO. But without knowing where exactly your problems are it is quite hard to give you more specific help. Two more things that might help you: when considering the speed (and thus the amount of thrust I use) with which I move around a target, then I think mostly in terms of "time to target" (and how long I need to slow down with my TWR while I'm still far and fast). E.g. when I'm 1 km away then at 100 m/s it will take me 10 s to get there, at 100 m I need to slow down to 10 m/s so that it will take me 10 s. The other is the "Fine tuning the rendezvous" section in @Snark's: Illustrated guide to docking
  10. There are two effects: one is that at small relative velocities even a small change in absolute velocity can result in a large change in the direction that the velocity points to. This is the reason why SAS will not to prograde-/retrograde-hold anymore if you get below 1 m/s. If it would try to do so and you keep pushing with your engines, then it would start wildly throwing the craft around every which way. The other one if that in LKO the orbit is quite curved and if you are not already at zero-zero with the target (i.e. directly next to it with 0 m/s relative speed), then your orbits curve differently and you'll start drifting away over time. The practical solution is to either use very small thrust (e.g. - but not limited to - RCS), or to just not bother. For your average rescue mission in which you EVA the rescuee over to you craft anyhow you don't need to get to a zero-zero intercept. Being 50 m away with 1 m/s relative velocity is already pretty good and allows you several minutes to gather the the rescuee. For my rescue missions I don't bother getting that close. My limits are: closer than 1 km and less than 100 m/s, but that requires quick reactions to get the rescuee out of their capsule and pointed towards the rescue craft. So I usually get onto a trajectory that brings me closer than 100 m, slow down to 10 - 20 m/s or so, and get the rescuee out of their capsule when I'm 1 km or so away. You do need the zero-zero intercept for docking, but that is another kettle of fish.
  11. In my limited experience the "bounciness" of the robotic parts is a lot less bad than the bounciness of the landing gear. I think that is because the restoring force of the robotic parts is not a (badly modeled) spring but the engine power of said part. Thus my suggestion to mitigate this by reducing the mechanical load on the landing gear.
  12. Not implemented (yet?), see: Bug #23179 Did you do the test on how much engine torque you need, that I suggested? You can also try adding more propeller blades to the engine. To find it you need to find where your copy of KSP is installed, and in there in "saves/<YOUR_SAVEFILE_NAME>/Ships/SPH/<YOUR_CRAFT_NAME>.craft" E.g. my test plane that I just did is in: "/data/SteamLibrary/steamapps/common/Kerbal Space Program/saves/sandbox/Ships/SPH/Prop Plane Turbo.craft" Publish that file on a file-hosting service like Google-Drive, or Dropbox, or whatever, and post the link to that here.
  13. I think I did this after a fashion with this craft: ETS. But I didn't encounter the problems you describe. My guess(!) is that after docking one of the crafts pushes the other one into the ground, and then the landing gear (or legs or wheels) start their (usual ) jumping around. What could help is: a) not having the stationary mining rig on landing legs, but on girders with grip pads. (I.e. retract the legs after landing.) And / or b) reduce the torque on the robotic parts so that they can barley lift the docking boom that they are supposed to move. (In the hope that this will reduce the stress on the landing gear.)
  14. The math is the same as if you use a more traditional staging. The rocket equation doesn't care how many engines you use to accelerate your craft, or where each engine gets its fuel from. It only cares about "total mass at start of the stage", "total mass at end of the stage", and "effective velocity with which the lost mass was ejected" (the latter usually being calculated as "average Isp times 9.81 m/s^2"). So calculating the dV for each stage is straight forward (but tedious): record full mass and average Isp at the beginning of stage empty all tanks of stage in editor record empty mass at the end of stage remove all parts that will be staged away in editor rinse and repeat until you did all stages In reality there are two complications: one(*) is that the dV calculations of KSP get easily confused when you set up complicated fuel transfer schemes. (It usually does well enough when you use the external fuel duct, but often screws up when you manually change the fuel transfer priority.) The other is that you probably don't manage to (manually) stage away the empty parts at the exact moment when the tanks are empty, so you probably still have some more empty mass with you than the idealized calculations were assuming. (*) O.K. I wrote that before I remembered that you don't have that feature (yet, hopefully!) in the Enhanced(*cough*) Edition, but I didn't want to delete it. P.S. If you use engines with different Isp at the same time, then you need to calculate the average Isp, by doing a weighted average over all (simultaneously firing) engines with the rate of fuel flow as the weight.