robot256

I haven't played RT2 in a long time, but if I recall correctly, that only works when you are far enough from Kerbin that the "cone of visibility" of the dish you have pointed at Kerbin also covers the LKO satellites--typically outside Kerbin's SOI. So if you have a craft in Duna orbit pointed at Kerbin, it will link with anything in the Kerbin system that is also pointed at Duna. But within a system, you have to manually configure the network. I remember setting up a Munar network by putting an omni and three dishes on each satellite, and putting three around Kerbin and three around the Mun. Then each Mun satellite had a dish link to each Kerbin satellite, and omni links to each other, so there was always at least one path available.

I remember seeing at least one engine module, I think it was the latest LazTek Falcon 9 upper stage engine, that had heat shield tiles on the bottom of the fuel tank around the engine. That implies going in engine first is best. I always do it that way on stock + DRE. But as a solution to one of your hypotheses, if you click the "Adv" button in the Mechjeb SmartASS, you can configure it to "Surface Velocity" and "Back". This will point you retrograde with respect to the surface instead of orbit.

Hey guys, sorry to bump the old thread, but wanted to say great work to technogeeky and Pshawn! Sorry I dropped out of the discussion last year after posting my update to Pshawn's script in the original ISA Mapsat orbit thread. I didn't realize you were revising it for Scansat this summer, and tried doing it myself without success (I somehow got it to produce nothing but resonant orbits o.0). technogeeky, I don't know how far you got with the field-of-view/swath width recalculation, but I do work in remote sensing and it would indeed be really neat if they were more realistic. In reality, the swath width would be calculated trigonometrically like mohran's diagram (I used a version of that geometry in my version of the script). You talked about removing the "ideal altitude" and the penalty for being higher than it--I think there is actually a reason that going higher isn't necessarily better, but it can definitely have a better mathematical basis. The main limiting factor of the swath width, after FOV, is the beam incident angle. In reality, you can't measure the altitude near the horizons because your radar pulse would be hitting the side of the mountain, not the top of it. Limiting the beam incident angle to something 10 or 30 degrees would make it so you have to be roughly above your scanning area to get a decent return, and being higher would give you slightly better incident angles but with diminishing returns. But actually, the maximum incident angle is more dependent on altitude, because at steeper angles the reflected signal is a lot weaker, so you would have to get closer to the planet to be able to pick it up. I don't have an immediate idea how to combine these factors into a balanced approach, so maybe what you're already doing makes the most sense anyways. Please PM me if you want to talk about the math, or move this post somewhere else. I'm having a lot of fun with Scansat and can't wait to try out the orbit tables you posted here already!

I remember seeing that bug as well, maybe even in stock KSP. I doubt it is this mods fault. On another topic: Did I read the CLS thread correctly and you are going to include a connected living spaces config in the next update? I had to hack it in myself after I discovered my science station was split into three parts instead of one. o.0 I can post the simple config if anyone wants it.

I'm loving this mod, especially once I unlock Mechjeb's Maneuver Planner. I came here to report the "longitude of ascending node requirement prevents equatorial orbits from being completed" bug, but saw you have already closed that issue this very day! Can't wait for the release with this fix. EDIT: I forgot to mention that the orbit that is giving me trouble includes an encounter with Minmus (is this something that should not be generated?), so I'm hoping the fix comes out and I can complete the contract before it throws me out of whack!

The only thing more pointless than having fairings that don't reduce drag would be to change the drag model and not have any fairings to take advantage of it. My bet is also that the fairings will be added before the drag model changes, so players have a chance to get used to them before they become a necessity.

Keep those thoughts coming! And pay attention in your Geometry and Algebra 2 classes--that's what all this math is based on. When your friends ask why they need to know the equation for an ellipse, show them how to calculate an orbit with it. :-D

Nearly all my MJ landings came within 5 meters of the flag I used as a target. The only time I've had MJ screw up a landing site is when I did something weird, like forget to turn on an engine in time, or eject an engine halfway through so its Isp calculations were messed up, or deploy parachutes (it can recover from that if you have enough fuel and cut them before they fully deploy, actually). I would be interested in seeing what kind of craft you guys are having trouble landing with, since the issue is apparently not obvious without that information.

I used to have something like that happen to me with certain craft because they were too short, or used radial engines positioned too high up. As the fuel drains, the center of mass goes downward toward the center of thrust, and then the gimballing gets all messed up. When it tries to zero horizontal velocity before final descent, the heading controller craps out and that's why you crash. Might not be your issue exactly, but you could try disabling gimbals and also make a custom window with "Heading Error" so you can see if it is trying to do something it can't.

I don't use RTGs very much because the same mass of solar panels and batteries still keeps lights on and produces much more total power. I also have ships that use a lot more electricity than usual because of various mods (RemoteTech, Kethane, Mapsat, KAS).

This bug annoys me too! For my Duna mission I had to calculate all the burn times manually in a spreadsheet and execute the nodes with RemoteTech instead of Mechjeb. Something else that I was annoyed by was on my "drone carrier" craft that had four rover landing pods on radial decouplers. When I decoupled the landing pods, MJ thought there weren't any engines on it, presumably because they were on the "jettisoned" side of the decoupler.

Yes, it's just a matter of PID tuning, but that's not always easy in the middle of a launch So I have my own tuning procedure that's good enough. I usually fly with the P term between 10000 and 20000. If it's not holding heading well enough I increase the P term. The D term is adjusted based on the craft and stage of flight. Starts out around 3000 during launch because higher than that you get oscillations on tall rockets, but when I'm in orbit with a huge craft I set it to be closer or equal to the P term. This effectively limits the top rotational speed and reduces overshoot. You only need the I term if you are doing a burn/atmospheric maneuver and there is an imbalance in your craft's thrust/drag that it needs to compensate for; any other time it will simply decrease stability.

What stupid_chris said. My heavy-lift designs don't have more than five or seven engines on the first stage, but rely on 3.75m sized rockets and fuel tanks from K.W. Rocketry or NovaPunch to pack enough thrust and fuel. A really neat trick I learned from a stock craft is to have radially-staged liquid boosters drop in pairs, where the first tank/engine pair dropped has a fuel line feeding the second tank/engine pair that gets dropped, that has a fuel line feeding the third tank/engine pair that gets dropped, that has a fuel line feeding the central tank. Then the radial stages drop faster, and the remaining tanks are full after you drop each pair, so you expend less fuel lugging half-empty tanks around. Sometimes if I'm really short on thrust right at launch I have to add radial engines, and toggle them at certain times depending on overheating and gravity turns. I've used these techniques to get ~80 ton payloads into orbit consistently, with launch weights only 5 or 6 times that of the payload. Usually I have a first stage that has a giant engine and a bunch of boosters like that, with about 2-3000 m/s in it. Then the second stage is about 1/4 the size, but with a pretty big engine still, and giving another 3000 m/s is enough to get into orbit and circularize. Then the payload has a transfer stage with nuclear engines, and a lander on top with its own fuel reserve. My big interplanetary flights, though, almost always need refueling before the depart Kerbin orbit, and sometimes I even refuel them en route from a tanker in the same convoy. Hope this helps.

I use Mechjeb on all my craft, but I have to reiterate that it's not the magic bullet some people make it out to be. It's a complicated tool, and takes a lot of knowledge and experience to use it properly--not that different from manual piloting. For moon rendezvous, it always plots a collision course, so I use it to time the departure burn and adjust the node manually to fix the arrival orbit. Sometimes I let MJ execute the burn, sometimes I do it manually for better accuracy. I alter the PID parameters for each craft so they don't wobble, sometimes multiple times during a mission. And for the Ascent/Landing guidance systems, there are specific methods to designing your craft, planning the mission and entering the parameters that are required for success--failure is not hard to come by. I use MJ because like many others I am an engineer and enjoy staring at walls of numbers while watching my meticulously-tuned craft fly under its own guidance to complete complex missions--but I'm almost always on the edge of my seat ready to take the helm at the first sign of trouble. The bottom line is this: KSP is a great flight sim, yes, but to insist that it is ONLY a flight sim does a disservice to its creators and to the open community they have fostered.

Other things that may or may not be applicable here: * Ports dock best if you slam them together with ~0.1-0.2m/s of force, or just don't resist the magnets with RCS when they start to pull. * When you undock, you have to back up a certain distance/time before the same two ports will dock again. Presumably this is to make it physically possible to undock, but I haven't figured out the exact distance/time required to reset the docking port magnets.