mic_e

Unfortunately I have to agree with 5th Horseman - while the Red Marker is drawn correctly (I think), the target marker, which is drawn by the stock game, is unfortunately wrong... One way to fix this would be to prevent the stock game from drawing the target marker, and drawing it myself... Drawing it myself wouldn't be a problem, but how to prevent the game from drawing it?

The main problem is that there are too many differenct orbits. A few examples would be:Keep a satellite in an eccentric orbit from burning up due to disturbances from the mun Keep a keostationary satellite above a certain longitude Keep a satellite from drifting away from a Lagrange point Keep an Aldrin cycler on its correct trajectory I don't think you'll be able to write code that is general enough to cover any two of these cases. You'll just have to offer multiple hard-coded options, and add more as people request them (or leave it to the people to write them). For the beginning, I'd simply stick to an algorithm that does maneuvers on each Ap/Pe pass, fixing Pe/Ap to their pre-set values. If the required burn d-v would be too high (say, > 1m/s), display a warning message and stop the stationkeeping.

You are right, Minmus's orbit should, indeed, be stable... I should have done my math before posting that assumption as a fact. Kerbin's Hill sphere has a radius of over 130 Mm, Minmus is well within that. Have you considered measuring the ship's acceleration by determining the CoM's velocity at the beginning and end of each physics frame? I'm not sure there is such a thing as 'neglegible' accelerations... firing 4 1kN RCS thrusters on a 100t vessel should definitely have an effect... and that only be a few milli-gees... Have you checked whether the phantom gee forces produced by Unity cancel each other out?

oh... Tweaking the masses would heavily distort the balance of the game. I believe the Jupiter system is stable because of orbital resonances, so adjusting the orbital periods of Vall and Tylo might work out. Minmus's orbit however is simply outside of Kerbin's Hill sphere - I don't see any reasonable way of getting it to orbit properly; at best, you might be able to put it in orbit around a Kerbin-Kerbol Lagrange point... Experiments will have to show whether you get a solution that stays stable for the full 80 or so years that KSP spans. Well... from my computer scientist's point of view, it would eliminate the quadratic asymptotic dependency on B, but I have a hunch at why your integrators would get a lot of extra work to do. Feel free to do a series of `lectures`, I'm quite interested in the topic. I do know basic calculus, and I think you should take that as a prerequisite... I've written a few n-body simulations myself (using the 'trivial' approach of v += a*dt, x+= v*dt), and I have a hunch on how RK improves on that. I don't really like C#, and even less its IDEs; I just view them as a neccesary evil when dealing with KSP, so I don't think I'd be the right person to maintain such a fork. Decouples, docking ports and EVA jetpacks provide force, too. As do collisions between ships. Also, don't forget that decoupling while rotating or the pumping-around of fuel will affect your orbit, too (the latter is a bug, though). I think the main cause for fluctuations in stock orbits are just due to the fact that the orbit is not calculated for the CoM, but the center of control, so the slightest rotations of the craft are displayed as g forces. While the craft is non-rotating, the stock integrator is working pretty well for me. If you'd attempt to re-do all those physics, I think you'd basically end up re-writing unity's physics engine, in the process introducing an uncountable number of new bugs, so I heavily recommend against doing that¹. ¹ I think that KSP should indeed be re-written with a from-scratch physics engine in C++, preferrably using fixed-point 64-bit integers for all positions and velocities, but I think that would require an immense amount of work and is entirely unrealistic at the moment.

OK, I just downloaded and tried it, and have a few points to say: - It works like a charm; I congratulate you. Despite you saying that it is a 'proof of concept', I think that this is very much usable, and would use it in my current gamesave, weren't it for the next point: - I didn't expect it to actually do n-body physics for the _planets_ as well as the craft... poor Vall. You might want to add an option to do the classical Keplerian math for Bodies, or a Minmus mission might end up being a Near-Kerbin-Asteroid mission. In addition, this would save loads of CPU time. - It was kind of a pain to build with MonoDevelop, having to hack the sln and csproj files and manually select Mono 4.0 as the toolchain for every project...

This sounds mind-bogglingly awesome; together with FAR, this will put KSP on a par with Orbiter in terms of realism. I can only second Headhunter09's post; I have a sneaky suspicion that you're deep in academia, and this might become your master's or even PhD thesis.

So, how did your LaTeX writeup go? Also, an other interesting graph would be payload/fuel mass fraction, for multiple-use ferrys.

Suggestion 0 remains to use kerbosynchronous orbits. Suggestion 1 is highly elliptical orbits: Pe = 70, Ap just out of the Mun's reach (9000 km). Your satellite will be within 90 degrees of the Ap for 97.5% of its orbit, and within 60 degrees of the Ap for 94.4% of its orbit. For example, use 4 satellites, with their Longitude of Periapsis shifted by 90 degrees each. Your coverage won't be perfect, but it will do in most cases. Suggestion 2 will give you guaranteed connectivity for half the time: Put two to three satellites into high altitude circular polar orbits around the Mun, with their LAN spread equally across 360 degrees. As long as the Mun is visible from KSC, you'll have contact to almost everywhere. Suggestion 3 is to improve your coverage with ground-based comm relays. For example, a relay on the 6-km mountains next to KSC will cover a circle of 8 degrees in radius. A relay on a 100-meter tower will cover 1 degree (I'm not sure how well comm towers work with remote tech, though). Suggestion 4 is to spam Medium Kerbin orbit (~300km) with omnidirectional comsats, and just hope for the best. Should work pretty well, but your computer might hate it. For extra fun, mix prograde and retrograde orbits. Combination of some of the options might yield better results; for example, combine 2 and 3: Put your commsats around the mun in 1000x1000 orbits, and build a land-based comms bridge towards the north pole. Build a ring of comms relays around the pole at around 80 degrees latitude, and your coverage will be precisely 100% (if you put the ring too far towards the pole, the commsats might become invisible while above the mun's south pole).

Ap/Pe don't really matter; if you get them wrong, your satellite's longitudes will just fluctuate by a few degrees during the course of their orbits. The same goes for inclination. All you really need is an orbital period of precisely 6 hours (for kerbostationary orbits) - use Kerbal Engineer or Mechjeb for that. A error in the orbital period of 0.1 seconds (you usually get it to about that precision) will mean the satellite's latitude shifts by about 2.4 degrees per year - pretty neglegible.

I got to agree with John FX, the additional GUI chooser is probably utterly unneccesary - just use equatorial AN/DN if no target is selected, and target AN/DN if a target is selected. On the topic of Lambert solvers, I'd recommend strongly against writing your own one. The issue is highly complex; researchers at NASA and other space agencies have been writing papers on it for 50 years, and yet there is no algorithm that is guaranteed to converge in absolutely every case. Designing your own algorithm would be similar to designing your own crypto algorithm for production use: Either you're an absolute genius, or you're an idiot (protip: the latter is more likely). I'm currently in the process of porting this BSD-licensed MATLAB Lambert solver to python; it actually contains two separate algorithms, with the second one helping out when the first one fails to converge. The algorithms have been designed at NASA and ESA respectively, and so far it looks like they're doing their job pretty darn well.

Sounds awesome. Can't wait to see it! Beware the feature creep! I think such a feature should get its own Plugin. But imagine the incredible awesomeness... I imagine it like this right now: You click Duna's orbit, and a PCP opens up. You click a point in the PCP, and the maneuver node is created.

Is there a mod that will move the launch site away from the equator? The masochist I am, I'd love to be able to/forced to launch from 60 deg north latitude...

I didn't really suggest to copy/paste the code from mechjeb, it's just that it is probably the best KSP API documentation you'll ever find. I feel there is no need to re-spill the blood, sweat and tears that others already have, redoing such a time-consuming and frustrating job as finding out which data field and method of which class does what you want. Also, I think that simply summing up the (world-space) vectors will do exactly what you need, as long as the nodes are close together in time. And, a simple 'collapse maneuver nodes' button is exactly what I want

Here's a line of code that will give you the burn vector (In world coordinates) of maneuver 0: (proudly copy/pasted from kitoban's Enhanced Navball code). To get the summary burn vector, use Now the remaining problem is to convert the summary burn vector back to maneuverNode[0] prograde/normal/radial components. After some research into mechjeb's code, I believe it's simply this: So at all, at the press of the 'merge maneuvers' button, sum up the burn vectors of maneuvers 0 and 1, memorize the maneuver 0 UT, delete maneuvers 0 and 1, and add a new maneuver with the summed-up burn vector and memorized UT. edit: Oh wait, placeManeuverNode is actually a mechjeb-specific function. However, you can find it here. Also, maybe, just maybe vessel.patchedConicSolver.maneuverNodes[1].GetBurnVector() requires a different orbit as its argument, such as vessel.patchedConicSolver.maneuverNodes[1].patch. The fact that none of the API functions is properly documented and it's just a pain in the *** to manually test every single one is the main reason I don't do a lot of KSP plugin writing.

I have a rather large feature request: The ability to merge two subsequent nodes. Often I find myself in a situation where I want to do a combined inclination adjustment + Pe/Ap change. Doing this in one single node is a pain, as changing the prograde direction will also change the inclination of the resulting orbit, and changing the normal direction will change the Pe/Ap. One solution is to create two nodes: One to adjust the inclination, and one immediately afterwards to adjust the Pe/Ap. The problem is that actually doing these two burns separately is extremely inefficient, so my request would be for PreciseNode to sum the two nodes together (This is a non-trivial task, as the prograde/normal/radial directions of the second maneuver are not identical to those of the first maneuver, and depend on the changes of the first maneuver...)

Arrowstar, would you mind allowing tavert to create Linux binaries for KSPTOT despite the non-derivative part of the license? I'd like to test this awesome tool, but don't have any Windows available.

I've searched the MechJeb sources and found that the following field contains the delta time of the current phys frame: TimeWarp.fixedDeltaTime However, I still need to find out whether the game is currently paused. Any help?

Not neccesarily I've developed my NavballDockingAlignmentIndicator mod completely with a bare text editor (vim) and a Makefile.

Hi, how can I read the physics delta time of the current frame (needed for numerical integration of g-forces)?

Nice to know, thanks.So I guess they made EVA prop an extra resource to prevent rover RCS from draining your kerbals?

What harv said at KerbalKon... economy, and maybe even first signs of multiplayer... though I doubt the latter. Also, he basically said that aerodynamics will not happen until after the 1.0 release. So you better get used to the idea of using mods . It's not that bad after you get used to them. Apart from that, I hope and expect to see more biome maps, and possibly a scientific instrument to get science from anomalies (I wanna train my precision landing skills )

Yeah, I heard that at Kerbalkon, too. And in fact, the ressource is called EVA Propellant while on EVA. But I can think of no other reasons why all capsules should suddendly have gained small per-Kerbal monoprop tanks. Also, at Kerbalkon they said that you can transfer EVA prop between Kerbals that are on the same vessel, however it does not display EVA Prop at all while in a vessel...

So in .23, my capsules all have monoprop (10 per Seat). However, EVAs don't seem to use any of that; I can 'get out and push' as often as I want, and still have full monoprop in the capsule/EVA prop at the beginning of each EVA. I'm working on a fresh install and haven't installed any mods yet. Is this behaviour intentional? Then what effect does the change have at all?

Example: Land the lab on the mun, together with a lightweight rover. Rove into adjacent biomes, conduct experiments, return to lab. Repeat. Not only an awesome use for the science lab, but also for roving!

AFAIK, docking involves 9 degrees of freedom: - Rotation relative to the target, as indicated by the alignment indicator position and roll on the navball - Velocity relative to the target, as indicated by the target velocity marker position on the navball and total target velocity number above the navball - Position relative to the target, as indicated by the target position marker on the navball and displayed target distance Thus, all information is provided when using just stock KSP with this Plugin. Well, except for singularities. The most annoying singularity is when the forward velocity is close to 0 m/s. Then, the target velocity marker is invisible, dancing around or at the very edge of the navball, making it unusable. I usually fight this by constantly 'keeping in motion'. A similar singularity would exist when the distance approaches 0, but at that point you're basically docked, anyway. Fighting this singularity would be possible by using the 'forward velocity independent target velocity marker' that I was talking about in an earlier post. Maybe I should make that plugin. Just for the sake of its name: Navball forward velocity independent target velocity marker. Yeah, by this time you can probably guess what my Vessels are usually named like. Edit: There are, of course, 3 more degrees of freedom: The relative rotational velocity of the ship you're docking with. I think if that is not 0 from the beginning, you're screwed anyway