[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[AppleDavidJeans]

java version "1.8.0_20"

Java SE Runtime Environment (build 1.8.0_20-b26)

Java HotSpot 64-Bit Server VM (build 25.20-b23, mixed mode)

[bk2w]

java version "1.8.0_20"

Java SE Runtime Environment (build 1.8.0_20-b26)

Java HotSpot 64-Bit Server VM (build 25.20-b23, mixed mode)

Ah, I believe that Java is too new for MCR R2013a. You'll need to remove Java 8 and install Java 6.

http://stackoverflow.com/questions/19039752/removing-java-8-from-mac talks about how to remove Java 8. You can get Java 6 from http://support.apple.com/kb/DL1572.

-Brian

[Drew Kerman]

Ok I have the longitude problem band-aided since I know that the meridian on Mun is 53-ish degrees East to KSP. So just have to do a bit of conversion from there. I still don't know if this is a bug or what, certainly makes things overly difficult IMO.

New problem though - why is this??

Also I realized belatedly that this tool is useless to me in this instance since I am actually orbiting about Kerbol and there's no option to choose that in the Orbiting About dropdown. Not a big deal, I just had an excuse to check it out with an upcoming burn as I had never played with it before.

Still haven't gotten around to messing around in Excel using the data export from the graphical analysis

[Arrowstar]

Ok I have the longitude problem band-aided since I know that the meridian on Mun is 53-ish degrees East to KSP. So just have to do a bit of conversion from there. I still don't know if this is a bug or what, certainly makes things overly difficult IMO.

This is actually a bit strange. My information says that the prime meridian of Kerbin is 90 deg to inertial axes of the universe and the Mun's is 230 degrees from the same. How did you come up with the 53 degrees? Btw, the parameter in the bodies.ini file you want is the "rotini" entry, specified in degrees. That gives the initial rotation of the body at time = 0.

New problem though - why is this??

http://i.imgur.com/cCOGPVl.png

Also I realized belatedly that this tool is useless to me in this instance since I am actually orbiting about Kerbol and there's no option to choose that in the Orbiting About dropdown. Not a big deal, I just had an excuse to check it out with an upcoming burn as I had never played with it before.

Still haven't gotten around to messing around in Excel using the data export from the graphical analysis

I... have no idea. Anyway, I've corrected this and the lack of bodies showing up in the dropdown list for v1.1.7. Expect it to drop some time this week.

---

Oh, since people are forever asking, I figured out how to hack Kerbin time into KSP TOT. You're welcome. I'll need to know about any bugs with it ASAP though, because they won't be easy to track down (probably). You'll be able to change the Earth/Kerbin time selection in the Edit menu on the main GUI. This change will be in v1.1.7 as well.

[Drew Kerman]

This is actually a bit strange. My information says that the prime meridian of Kerbin is 90 deg to inertial axes of the universe and the Mun's is 230 degrees from the same. How did you come up with the 53 degrees?

I used the graphical analysis tool to see at what time my craft would be at 0 (or close, 0.0133 or something) and then took a screenshot at that second and noted the body location readout from VOID. I just did it again - the relevant bits are circled:

If you want the orbit file for the craft, it's here.

Btw, the parameter in the bodies.ini file you want is the "rotini" entry, specified in degrees. That gives the initial rotation of the body at time = 0.

If the longitude readout will be remaining the same (0 to 360 instead of -180 to 180), can these values at least be exposed in the Celestial Body Catalog for easy reference?

Edited September 17, 2014 by Gaiiden

[Arrowstar]

So I think the issue might be on your end some how. Here's why. I did an experiment where I loaded an orbit from an SFS file and compared the longitude from the Mission Architect read out. Here's the result:

Notice that my longitude and latitude match the long/lat in the sfs file. Not sure what to tell you then... is your orbit in MA correct? Can you be sure the read out in that GUI in the lower left is correct?

EDIT: Here's a similar example around the Mun:

Edited September 17, 2014 by Arrowstar

[Drew Kerman]

I'm shutting down for the night but will experiment some more tomorrow. But for one last look I loaded the orbit into MA, set a coast to Pe with no prior revs, and the Final State box told me 263.9E degrees. If I load up the big map in SCANSat (so a diff mod) it shows the Pe marker for my orbit and has it placed at -46W degrees. I'm too tired to do the math. Let me know if that adds up.

[Arrowstar]

Some quick math suggests that the two measurements are off by the same 50 you mentioned above. However, interestingly enough, the initial rotation of the Mun (230 degrees) is 180 + 50 degrees. This works out too well to be a coincidence, I think. So maybe ScanSat has something flipped? Can you check with them on the ScanSat thread and see what they think?

EDIT: Screwed up the math. -46 W is the same as +46 E. So it looks like you're off by 218 degrees. Or at least I think. It's really early here.

Edited September 17, 2014 by Arrowstar

[Drew Kerman]

later tonight I'll do a check and see if VOID, Engineer and SCANSat all match up properly at Pe. It's highly unlikely I think that all 3 mods would get the coordinates wrong. I know they are accurate for Kerbin - I've used the Lat/Lon readout from VOID to navigate to the other side of the planet from KSC to fly over the badlands biome - got exactly where I wanted to go. Also used VOID data from launch videos to plot my course over land.

[Drew Kerman]

Ok here is my Pe pass, when the Final State of MA after coast to Pe tells me I should be at Lon 263.9577E (orbit file)

Additionally holding my cursor at Lon -46 on Kerbal Space Maps (can't link straight to the Mun map, but that's what I did use) corresponds to the location SCANSat had my Pe marker on.

Edited September 18, 2014 by Gaiiden

[Arrowstar]

Ok here is my Pe pass, when the Final State of MA after coast to Pe tells me I should be at Lon 263.9577E (orbit file)

http://i.imgur.com/BGkXxZK.jpg

Additionally holding my cursor at Lon -46 on Kerbal Space Maps (can't link straight to the Mun map, but that's what I did use) corresponds to the location SCANSat had my Pe marker on.

Okay, thanks for the information! I guess I can poke around some. Can you try this experiment with MA and ScanSat on a few other bodies so I can get some more data points? Maybe I can pin down where the difference is. I redid the math on your initial case, btw, and my hunch was correct: the difference between KSP TOT and ScanSat is 50 + 180 = initialRotationOfMun + 180 degrees. Given how I match KSP's SFS files, this does suggest that there may be a flaw in the way ScanSat is computing the value...

---

In other news, here's a sneak peak at what's coming in v1.1.8:

Version 1.1.7 will hopefully have some contributions from RadarManFromTheMoon that improve the net code of KSPTOTConnect, so that will be released (with all the other bug fixes and enhancements) prior to my finishing and releasing this shiny new thing.

[Drew Kerman]

Okay, thanks for the information! I guess I can poke around some. Can you try this experiment with MA and ScanSat on a few other bodies so I can get some more data points? Maybe I can pin down where the difference is. I redid the math on your initial case, btw, and my hunch was correct: the difference between KSP TOT and ScanSat is 50 + 180 = initialRotationOfMun + 180 degrees. Given how I match KSP's SFS files, this does suggest that there may be a flaw in the way ScanSat is computing the value...

I'll give it some more looking tomorrow. You've noted the flaw may be in ScanSat but what about the fact that VOID and Kerbal Engineer also come up with the same value? I doubt three independent mods would be making the same mistake.

In other news, here's a sneak peak at what's coming in v1.1.8:

DO WANT! That is quite fantastic

Version 1.1.7 will hopefully have some contributions from RadarManFromTheMoon that improve the net code of KSPTOTConnect, so that will be released (with all the other bug fixes and enhancements) prior to my finishing and releasing this shiny new thing.

While you're at the bug fixing I have this MAT file for you to look at, which contains the non-0 MET issue in the graphical analysis. It also affects using Time as the independent variable. This issue popped back up after I imported an updated orbit into the Initial State for my Duna mission file. The mission file prior to importing the updated orbit does give me a 0 MET starting value in the graphical analysis, as well as an accurate starting time when Time is chosen as the independent variable. I closed and reopened MA but the issue persisted - the original file is still fine but this updated one I'm linking to still no longer begins the graphical analysis at the very beginning.

(Duna mission is coming along swimmingly, BTW. Just did my correction burn (with signal delay) and now I'm all set to enter into my target orbit when I arrive to deploy my satellite. Perfect-o!)

Edited September 18, 2014 by Gaiiden

[ANWRocketMan]

I think I asked this once before a long time ago.

But would it be possible to alter the planets and their orbital properties to suit the Real Solar System configs? That's just about the only thing I'm missing from my realism install is a proper method of calculating/predicting/planning my missions.

[Arrowstar]

I'll give it some more looking tomorrow. You've noted the flaw may be in ScanSat but what about the fact that VOID and Kerbal Engineer also come up with the same value? I doubt three independent mods would be making the same mistake.

Yeah, it is a bit strange that everyone else more or less agrees, but no one agrees with the KSP SFS file except me... maybe it's just a different way of computing it and we're both right.

DO WANT! That is quite fantastic

Glad you like it. It'ts very incomplete at this point, but stay tuned for more updates...

While you're at the bug fixing I have this MAT file for you to look at, which contains the non-0 MET issue in the graphical analysis. It also affects using Time as the independent variable. This issue popped back up after I imported an updated orbit into the Initial State for my Duna mission file. The mission file prior to importing the updated orbit does give me a 0 MET starting value in the graphical analysis, as well as an accurate starting time when Time is chosen as the independent variable. I closed and reopened MA but the issue persisted - the original file is still fine but this updated one I'm linking to still no longer begins the graphical analysis at the very beginning.

I'll take a look, thanks!

(Duna mission is coming along swimmingly, BTW. Just did my correction burn (with signal delay) and now I'm all set to enter into my target orbit when I arrive to deploy my satellite. Perfect-o!)

Glad to hear it!

I think I asked this once before a long time ago.

But would it be possible to alter the planets and their orbital properties to suit the Real Solar System configs? That's just about the only thing I'm missing from my realism install is a proper method of calculating/predicting/planning my missions.

It is indeed possible to create one. From the Main GUI, and with KSP and KSPTOTConnect running (in the Flight Scene), File -> Create New Bodies File From KSP. This will poll KSP itself for the bodies information and generate the file for you on the fly. Give it a try and let me know if you have issues.

Btw, having any luck with the KSPTOTConnect net code?

[RadarManFromTheMoon]

Btw, having any luck with the KSPTOTConnect net code?

RadarMan here, I guess you mean me.

I'm on it. It's a bit more complicated than I thought, but I'm making good progress. I have some questions though. Will send you a PM soon.

[Drew Kerman]

Okay! I have two matches and two misses for you.

Matches: Eeloo and Duna

Eeloo

MA said 5 degree Lon

Duna

MA said 138 degrees Lon (woah wait - WTF?? Check Engineer's Lon reading. bah? I reported it in their thread)

Misses: Eve and Laythe

Eve

MA said 347 degrees Lon (10 degrees off)

Laythe

MA said 312 degrees Lon (74 degrees off)

Those were the only 4 I took time to sample, just happened to pick two right and two wrong. Go me Hope this helps. All orbits were slightly eccentric for a clear Pe reading and 20 degrees inclined (I used Hyperedit to jump around)

Edited September 18, 2014 by Gaiiden

[Arrowstar]

Okay! I have two matches and two misses for you.

Matches: Eeloo and Duna

Eeloo

http://i.imgur.com/FRnMOpS.jpg

MA said 5 degree Lon

Duna

http://i.imgur.com/3oKpWNO.jpg

MA said 138 degrees Lon (woah wait - WTF?? Check Engineer's Lon reading. bah? I reported it in their thread)

Misses: Eve and Laythe

Eve

http://i.imgur.com/sliROfi.jpg

MA said 347 degrees Lon (10 degrees off)

Laythe

http://i.imgur.com/n9TIr05.jpg

MA said 312 degrees Lon (74 degrees off)

Those were the only 4 I took time to sample, just happened to pick two right and two wrong. Go me Hope this helps. All orbits were slightly eccentric for a clear Pe reading and 20 degrees inclined (I used Hyperedit to jump around)

Okay, thanks for the data. I seriously don't know what to think. Can you link me to your post on the Engineer thread? I'd like to follow that.

Btw, your issue with Graphical Analysis missing the first data point is now resolved and the fix will be in v1.1.7.

[Drew Kerman]

Cool, glad the graphical analysis issue was resolved.

Engineer discussion begins here, although the response for now is "not an issue".

[Arrowstar]

Roger roger, I've replied, so let's see if it gets us anywhere.

[Arrowstar]

And another sneak peak... if it works...

EDIT: The red marker on Kerbin is the KSC. This is a visualization of a mission plan to a geostationary orbit above KSC.

Edited September 19, 2014 by Arrowstar

[RadarManFromTheMoon]

And another sneak peak... if it works...

http://i.imgur.com/pwXYcHO.gif

Now, THAT is nice.

I just had an idea for a feature. constraining for day/nighttime. For when it's undesired to land at night, or if it is important to have enough electricity through solarpanels at a particular time.

[Drew Kerman]

And another sneak peak... if it works...

Awwww yisssss - I didn't even have to ask for the annotations. Awesome!

I just had an idea for a feature. constraining for day/nighttime. For when it's undesired to land at night, or if it is important to have enough electricity through solarpanels at a particular time.

What are you constraining, specifically? This is also possible already through the graphical analysis tool in MA - you can check for eclipses to see when you are on the day/night side of a planet and for how long

[RadarManFromTheMoon]

What are you constraining, specifically? This is also possible already through the graphical analysis tool in MA - you can check for eclipses to see when you are on the day/night side of a planet and for how long

I'm not sure actually. Was just an idea. But if it can already be done this way then there is probably no need for an extra constraint.

In the apollo missions they tried to perform the landings while the sun is low so that they could better see elevations on the ground.

[Arrowstar]

Yes, the graphical analysis tool can be used to do what you're asking.

Final preview for the night:

[diomedea]

...

Final preview for the night:

...

Now, that new feature is impressive. Would like to know if the mission animator will be limited to one mission segment at a time, or will automatically switch segments as time goes for the whole mission.