bk2w

Arrow, One of the minor issues is path delimiters for the splash logo. Windows uses '\' and OSX uses '/'. A simple solution appears to be replacing line 61 in splashScreenGUI.m rgb = imread('images\logo500px.jpg'); with if isunix rgb = imread('images/logo500px.jpg'); else rgb = imread('images\logo500px.jpg'); end -Brian

Those files did the trick. I've been able to build for OSX, and it seems to be running well. A couple of really bizarre UI quirks (menus always appear at a specific point in the screen, regardless of where I move the KSPTOT window) but the calculations are running without apparent problem. Thanks!

Arrowstar, Your progress on KSPTOT is truly amazing. I love this tool. I'm trying to compile the source for v1.1.5 on an OS X machine (with Matlab R2013a) so that I don't need a VM just for this tool, but I'm running into some difficulty with a couple of routines that you have compiled up as .mexw32 files. Since I'm running on a Mac, I can't use the Win32 compiled binaries. ./src/KSPTOT_matlab/getKeplerFromState_Alg_mex.mexw32 ./src/KSPTOT_matlab/helper_methods/astrodynamics/getKeplerFromState_Alg.mexw32 ./src/KSPTOT_matlab/helper_methods/astrodynamics/getStatefromKepler_Alg.mexw32 ./src/KSPTOT_matlab/helper_methods/astrodynamics/solveKepler.mexw32 ./src/KSPTOT_matlab/helper_methods/math/crossARH.mexw32 ./src/KSPTOT_matlab/helper_methods/math/dotARH.mexw32 I suspect the math files are merely compiled versions of the .m files of the same name, but the four Kepler files elude me. It looks like these are your custom vectorized algorithms. Are the source files in the ZIP somewhere of out of the way? Are you willing to share them out? Thanks, -Brian

The quantity of methane in the deposit is randomly chosen between MinQuantity and MaxQuantity. Specifically, var initialQuantity = random.Range(resource.MinQuantity, resource.MaxQuantity); The shape of the deposit is more complex, but still a heavily randomized algorithm. A center location is randomly chosen on the body. A random number of vertices is chosen, between MinVertices and MaxVertices. The vertices are evenly distributed in a circle around the center location. A max polygon radius is randomly chosen between MinRadius and MaxRadius (think of the polygon as inscribing a circle of the random radius). Each vertex is then placed a distance from the center location, randomly chosen between RadiusVariance*max_radius and max_radius. Finally, the randomly shaped polygon is checked to see if it actually contains the center of any of the surface cells. If not, the whole process is tried again, up to NumberOfTries times. For Kethane, this is all in the source code in LegacyResourceGeneartor.cs, lines 85-98 and lines 147-165.

There is a code patch already suggested that lets the Medium Scanner cover more territory when at higher altitude to help make it more worthwhile. -Brian

Ahha! I missed that a new file was added. Thanks! I've been able to build and test a couple of new maneuver planning modes. One to adjust the SMA directly, another to adjust the LAN. I'm also refactoring a third mode to place the vessel at a specific altitude over a specific longitude at a apside node. I've got all the math worked out, I'm just trying to figure out the best way to present the maneuver. -Brian

I'm trying to compile the dev branch so I can offer some code suggestions, and I'm seeing compile errors that I don't quite understand. Lines 413 through 421: ModuleControlSurface cs = (pm as ModuleControlSurface); … Vector3 ctrlTroquePos = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(airSpeedRot * airSpeed))); Vector3 ctrlTroqueNeg = vessel.GetTransform().InverseTransformDirection(Vector3.Cross(partPosition, cs.getLiftVector(Quaternion.Inverse(airSpeedRot) * airSpeed))); The error message from Xamarin Studio is MechJeb2/VesselState.cs(420,128): error CS1061: Type `ModuleControlSurface' does not contain a definition for `getLiftVector' and no extension method `getLiftVector' of type `ModuleControlSurface' could be found. Are you missing an assembly reference? I have the Assembly-CSharp.dll, Assembly-CSharp-firstpass.dll, and UnityEngine.dll libraries from KSP 0.23 as references, and these are the only two build errors. If I stub out the lines, I can successfully build. I see in Assembly-CSharp library that the ModuleControlSurface class doesn't define getLiftVector at all, while the ControlSurface class does. Any ideas what's going on? -Brian

My approach is similar to resonance. I've got some MechJeb code that does pretty much all of this that I'm cleaning up right now. Hopefully I'll have a pull-request later today for you to take a look at. I'll setup an initial orbit with an apside at my desired final altitude. The code determines the longitude of the apside ground track at the time the vessel arrives at the apside. The difference between that and target a longitude is used to calculate how long it will take the body to rotate the correct longitude underneath the apside. I'll then adjust the SMA so that the orbital period is the rotation time plus some integer number of "days", choosing the integer number to ensure that the orbit doesn't dip below the 5x time warp limit. The code I've got calculates the adjusted SMA and drops a maneuver node on the apside. For Kerbin-synchronous, I skip the 100km orbit, and simply launch directly to an apoapsis of 2868.75km. Burn at the apoapsis to insert into the transfer orbit calculated above, wait a full orbit, then burn again to circularize. This reliably puts my spacecraft in a synchronous orbit within an arc-minute of my goal longitude. And has the bonus of keeping the spacecraft above KSC's horizon almost the entire trip.

Certainly you can use 'resonant orbit' to do the job, if you're willing to wait. For that matter, you can skip MechJeb altogether and still do this. But figuring out what that intermediate orbit should be so that you end up in the right place in a short amount of time requires a non-trivial amount of calculation.

I've been playing around with techniques for positioning satellites in constellations, such as putting a satellite in Kerbin-synchronous orbit directly above KSC. Most of this is aimed at RemoteTech-type systems, but might be useful to others. What I'm wondering is whether anyone else would find these useful enough to integrate into MechJeb, or if they'd just confuse with options: - Change orbit to a specific semi-major axis and therefore orbital period (to make synchronous or semi-synchronous orbits easier to achieve); - Change orbit so that the next periapsis/apoapsis occurs with the spacecraft over a specific longitude (to get the spacecraft to be over a particular spot on the planet before enter synchronous or semi-synchronous orbits); - Change orbit to adjust the Longitude of the Ascending Node (useful for offsetting the orbital planes of multi-satelitte constellations like GPS or Iridium). Thoughts? Additional maneuver mode ideas?

Yep, I mean insertion burn, or arrival burn. Do you already have enough information to calculate the orbital velocity of the spacecraft and of the target body at the interception? Then we could calculate the difference between the two and have a rough approximation of what the actual insertion burn would need to be. -Brian

I've recently been using a more analytic version of this, assisted by MechJeb, that lets me put a satellite in a circular synchronous orbit above a desired location on Kerbin in a short amount of time. I can do this by launching into a very carefully chosen parking orbit, waiting for one orbit, then circularizing. For most of my launchers, this means a launch to set my initial apoapsis, one burn to insert into the parking orbit, and one burn to insert into the final orbit. - Determine the longitude you'd like the satellite to be above, note this as target_longitude. - Launch the spacecraft to an apoapsis of 2868.75 km; this is the altitude for synchronous circular orbit, and we'll call it starting_apside. - Determine the surface longitude of the starting_apside. At the moment, I quicksave then warp to apoapsis and examine the "Surface Info" from MechJeb. Note this as starting_longitude. - Calculate the offset of longitudes, offset_longitude = starting_longitude - target_longitude. - Since Kerbin rotates 360 degrees in 6 hours, we want to change our orbital period to be target_period = 6 hours * (offset_longitude/360 + N), with N being 0, 1, 2, or some other positive integer. - Calculate a new semi-major axis: target_sma = cuberoot(kerbin_gravitational_parameter * target_period^2 / (4 * pi^2) ). - Calculate a new apside: target_apside = 2*(target_sma - kerbin_radius) - starting_apside. If the target apside is less than 100km, we need to increase N and pick a new target period. - Reload the quick save, and command MechJeb to change the periapsis or apoapsis to target_apside at the next apoapsis. Change periapsis if target_apside is less than starting_apside, and change apoapsis if target_apside is greater than starting_apside. - Execute, and we'll be in the parking orbit. - Wait a full orbit of the satellite, and Kerbin should rotate to put our target_longitude right underneath. - Command MechJeb to circularize at the starting_apside, and execute. This should leave us on a nearly synchronous orbit very closely above our desired target. - If needed, carefully burn prograde or retrograde to get the orbital period as close to 6 hours as possible. I've been able to use this technique to reliably put a satellite to within 1 degree of longitude over KSC, or whatever longitude I want, usually in less than 12 hours after launch. Hopefully I can get this kind of maneuver integrated into Mechjeb, as I find it very useful for establishing a particular satellite constellation. Now if only we had a good way of directly changing the longitude of the ascending node, then we could easily establish some of the really complex Walker constellations. -Brian

Is there someway to get detail of the final injection burn for either the Fly-By Sequencer or the main Transfer tool? Both tools give me departure burn information, and it's apparent that they're optimizing for departure+injection, but the lack of injection burn information is making it difficult for me to plan some missions for lack of how much delta-v I need for the full mission. -Brian

It seems that the source code in the package did not get updated along with the executable. I'm seeing the .exe report itself as version 0.11.2, but the source code (and anything I compile from it) reports as 0.11. Can you verify that the archive on the OP has the correct source code? I've been recompiling each of these subversions for OSX and they've all been behaving well. -Brian

I'm setting up an interplanetary network, and I'm having occasional outages that I can't track down. Is there any log or way of finding out what link in the relay chain got broken when a probe loses connection? -B

Arrow, I used R2013a running on OSX 10.8.5. 'deploytool' targeting a Standalone Application with projectMain.m as the Main File, everything in src/ as Shared Resources. The biggest hurdle is that the Lambert Arc solver (lambert.mexw32) you have in the source directories was compiled for Win32, and not usable on a Mac. I kept running into problems where Matlab would tap the Map Toolbox instead, getting very confused. I grabbed what I believe is the same source code (http://www.mathworks.com/matlabcentral/fileexchange/26348-robust-solver-for-lamberts-orbital-boundary-value-problem) and compiled it into a lambert.mexmaci64 that seems to work with TOT. End result is a script and executable that sure looks like KPSTOT on Windows. The script is needed to set environment variables that point to MCR, which is a bit awkward, but all the functionality of the tool seems to be working as I'd expect. I'm happy to help out with testing as my time allows. I'm a software/hardware engineer by training and I've used Matlab quite a bit through work for modeling and exploring demodulation schemes, error correcting codes, and DSP chains. Don't have much background with orbital mechanics, sadly, but KSP is so much fun that it's making me learn like crazy. -Brian

Arrowstar, Thanks for making such an awesome tool! It definitely feeds my engineering-side to find elegant solutions. However, since I play on a Mac, I got tired of running a Windows VM just for this awesomeness. I've managed to take the 0.10 source code and compiled a stand-alone application that I can run on my 64-bit OS X machines. I'd like to share it out, if you'd be willing. I'd love to help get your 0.11 working on OS X, as well. The KSPTOT Connect sounds very interesting. -Brian