Arrowstar

Nice! How are you handling displaying overlapping resources? We'll be able to hover over a deposit and see location, size, depth, etc?

I've just uploaded version 0.5. It will be online shortly. Feedback is appreciated as always.

Time for a nice development update! A bunch of new features have been added in the past two days. Starting basic, I've added a data cursor that pops up after generating a porkchop plot. It displays the best point on the graph in terms of delta-v. (Which delta-v will be discussed below.) This is the same data cursor you could manually add before, I'm just pre-setting it to a particular point on the plot. Note that it now also shows transfer duration. The position of the data tip is also passed in the departure calculation screen as initial inputs for departure/arrival time. I've also added the synodic period between the two selected bodies below the depart/arrival parameters. I've also added a global optimization feature that tries to find the best departure/arrival time. This is currently run when the porkchop plot is generated, but I will likely make it accessible elsewhere. The output doesn't do anything at the moment, I still need to figure out where to go with it. But it does work, it's just a design problem at this point. Previously, I mentioned that the optimizer will attempt to minimize a delta-v of a type you select when you run the porkchop plot generator. Which delta-v you minimize is based on what you select in this box: The default is departure+arrival delta-v. But if you going to a place where you plan to aerocapture into orbit, you can select departure delta-v only, and it will ignore the delta-v needed to arrive in orbit at the destination. I also put arrival delta-v there for completeness. This option impacts the entire application (except the data cursor, which shows dv based on which porkchop plot you're looking at), so make sure you change it if you need to. Moving to the departure calculation screen: Per a request, I added an option to compute the best departure for the input arrival time. This is in addition to the ability to find the best arrival time based on the input departure time. I also added the ability to find the earliest departure for an input delta-v: When you select that, a box comes up that asks you for a delta-v magnitude. Note that if you enter a delta-v that is too small, the solver will kinda freak out and spit out an error. It will still provide an answer, it just won't be very good (most likely). Finally, the transfer orbit map has gotten a minor addition in the form of markers for apoapse and periapse. Markers for ascending and descending node will come later. A marker for the location of your destination planet at the departure burn was also added. Finally, the last change I made was to go through and fix/update/add to the list of bodies that the program knows about. I've now got all the moons of Jool in there, as well as corrected orbital parameters for the main planets. My next major task is to rewrite the Lambert solver (as I said earlier) and then we'll go from there. What do you guys think?

I'm glad you like it! I'd rather you didn't port it to anything at the moment. The application is still under heavy development and you'd be chasing a moving target. I'd rather not have conflicting versions of my tool out "in the market" until things firm up. Thanks for the offer, though! I may take you up on it in the future if you're still willing. (Note: the license actually forbids derivative works, of which a port would be, at the moment for this reason.) True. I'll see what I can do. Yeah, I'll get ascending/descending nodes on the map at some point. I can see how they're valuable now. It'll be a bit in the future, but they'll come. I'll probably have checkboxes in the departure information GUI that you can use to turn them on and off at will. When you say adding it as a box to the departure burn calculator, do you mean as a button or as part of those context menus that come up when you right-click the departure and arrival time fields? Done! I've implemented an option that dictates the behavior of the solvers (that is, which delta-v they attempt to minimize) globally across the application. The one setting impacts all calls to the delta-v minimization code, so be careful and change as needed... Err, I don't know what you mean? You are surprised I wrote the MechJeb Lambert solver?

Thanks! Please let me know what you like and dislike so I can make improvements as necessary. It might be possible for me to perform some sort of sensitivity analysis. To be honest, though, I guess I don't see the purpose. True, it would show you when your "long" burn might significantly change your answer, but this is KSP... aren't we all just going to go for it anyway? I've added the apses to the orbit transfer map tonight. I'll have to think about the nodes, because you need to pick the correct plane for them to make sense. There's a fair bit of thought, design, and math that needs to go into plotting those. Honestly, they will probably come about later, if only because they're a very small feature that requires a lot of work. Thanks for the suggestions! I'd be happy to hear more if/when you have them. Indeed. I apologize, I wasn't intending to come across as cheeky. It just struck me that what you were asking for is exactly what the porkchop plot is for in the first place. In any event, I think you're right and some sort of indication of an optimized departure/arrival date/time is a good idea. Tonight I wrote the code to actually perform the optimization. It's just a matter of how to let the user call that. Right now I have it tied to the porkchop plot generator method: it generates the plot, then finds the optimal point within the plot. (Or, really, within 1 synodic period of the best point in the porkchop plot.) Do you have any suggestions on how I might present this "optimized" information to the user? I'm not sure I can use the data cursor thing I've got showing the best point computed for the porkchop plot, but I'll investigate anyway. Assuming that's a no-go, any thoughts? I'm thinking I either write it to the text box below the porkchop plot or bring up a pop-up box with the times in it. Would either of those be acceptable? Thanks for the suggestion! I'll consider it, though I have to admit, the plot is getting pretty cluttered with just the orbits and transfer orbit periapse/apoapse. We'll see. Some updates: I implemented the following requested features tonight: Find optimal departure for given arrival; Add transfer orbit periapse & apoapse to the orbit plot; and Find optimal arrival/departure on a generated porkchop plot (partial: result of optimization run needs to be displayed to user still). Tomorrow's agenda is the following request: Find earliest arrival for provided delta-v. Btw, I'm assuming that the delta-v provided is for the full round trip: departing one place and arriving at another. If I just use the departure dv, that could make things a bit optimistic in some cases. Do you guys have any thoughts on this? Which delta-v (the departure + arrival delta-v or just the departure delta-v) would be more intuitive for you? I'm also going to rewrite the Lambert solver at some point using the code I gave to R4m0n for MechJeb (yep, that's my Lambert solver) as a base. The current solver I have now is fine, but it seems to die at odd times and I'm sick of troubleshooting it. Thanks for the great suggestions/ideas, guys. Keep them coming! If I have time tomorrow night, I'll put out the v0.5 (pre-)release for people to play with.

Sounds good, thanks for the suggestions. I can probably add the apses and the nodes. The location of the target at the burn time is also very doable. I shouldn't need to show another view, since the transfer orbit map is actually 3D. I just didn't show that. Thanks! Glad you took the jump and downloaded it. It is a fun little tool, yep. Certainly. I'll add this to the feature list of 0.5. This isn't something I'd usually look for because I usually pick my departure and go from there. But this could be useful too. Great suggestion! Also possible and I can see the utility of this. Sounds good! Added to 0.5 feature list. This is actually the point of the porkchop plot, so I would suggest looking at that. Good suggestion. I'll do this tonight. EDIT: Nevermind, finished it. If you have more than one data tip on the plot, it will take the last tooltip you created. Coming in v0.5. This is a bit trickier, but I'll see what I can do. I'm not sure how capable MATLAB is in this regard. I'll investigate. Thanks for the great suggestions!

Yesterday I put together a new feature in the Departure Information window: a map of your orbital trajectory during transfer orbit from one body to another. It does two things: first, it shows you that the trajectory you're on actually does what you want it to (namely, finds the target body); and second, it can be used while playing the game to verify you're on the right path. I realize at the moment it's a bit sparse. I could use some suggestions for additional information to annotate the map with. Anyone have any thoughts?

Hurrah! Any chance you can record the show for those of us on the wrong coast who will be at work then?

Yes that is a planned feature. I have the math already worked out, just need to implement. It's probably a few releases off yet. Give me a week or two.

I've updated the application 0.4. As the change log in the OP indicates, the following has been added: Fixed bug where departure calculation window would not refocus after selecting departure/arrival times from porkchop plot. In departure calculation input GUI, added ability to right-click on arrival time input and select option to optimize that time based on what's in the departure time box. Added application-wide input checking. The second point is pretty big. What this means is that all you have to do is enter the departure time you want, right click the arrival time box, select the optimization option, and wait a few seconds. It's pretty handy. I've checked the results against the porkchop plots and they look pretty good, minor variance in optimizer results aside. It's a feature I wanted myself and really like now that I have it. To demonstrate: Right click on the arrival time box, select optimize option. Wait a bit... Voila! The best time is computed and input into the box. That's all there is to it. As always, comments, suggestions, and bug report welcome.

Hi The Lone Wolfling, And that's perfectly fine. I realize that it's a bit big and not everyone has the bandwidth and time to download the MCR. For those people, there are a plethora of other tools out there that offer approximations to what my code can do. No worries.

Thanks for the feedback. So here's the thing: I didn't come up with or put together the MCR. The nice folks over at The MathWorks developed it as a way for people like me (who write awesome MATLAB code) to distribute products to people without MATLAB. I don't have any control over what goes into the MCR, sadly. It's large size is an outstanding issue that people have complained about to The MathWorks developers. I wish I could have my application download the file at first run. However, since the application requires the MCR to run, having it try to download and run the MCR would be a bit of a catch-22. That said, you are correct in noting that most of the features in the MCR are features that my application doesn't use. (In fact, all I really need is access to the core MATLAB runtime evnviroment plus the optimization toolbox.) This is something we MATLAB developers have complained about, but like I said, there's not much I can do about it. Some type of runtime library is needed to execute MATLAB code, and unless someone comes up with a solution to customize the MCR package at compile time, we're stuck with the all-inclusive solution we've got now. I wish I could do something about it. I would urge you (and everyone else) to not give up on this useful little application just because of file size. I realize it's big, but if you're interested in working with the most accurate and detailed maneuver planning software on the KSP market, stick with it and you won't be disappointed.

Hi there! You can use the tool now, it's ready to go. I'm going to make some updates today w.r.t. input error checking and a Secret Feature I've thought about adding since I started using the tool myself. Should make it even more useful to use. I guess I'm a bit confused: there is a standalone executable (no need to run the MATLAB .m files by themselves). Unless you're talking about needing to grab and install the MCR package? In that case, no, sadly, the MCR must be installed separately. It's a large package, unfortunately, but you only have to install it once. I don't want to package them together because it will make updating to a new version of KSP TOT more painful (having to re-download the MCR each time would suck). That's why I leave it as two separate packages. Do you have any suggestions on how I could simplify the install process for users?

Nice, I look forward to watching!

I've completed another update to the code and updated the ZIP archive containing the relevant files in the first post. Changes includes: inclusion of basic computational options, accessible from Edit->Options, fixed a bug where datatips on the main porkchop plot would not always display estimated delta-v, added a custom display for datatips on the porkchop plot, added time past periapse to the burn information on the departure display GUI. My test with Eeloo yesterday went well. I've noticed that occasionally to get an intercept you need to adjust the departure time by +/- a few fractions of a second. The smaller the SOI you're aiming for (and Eeloo's is small), the more likely it is you'll need to adjust the departure time. This is to account for the fact that the patched conics assumption assumes that the SOIs of the body you're leaving and arriving at are very small (essentially 0 volume), whereas in reality they do have some size. Also, you never truly depart at the exact moment you planned to, so error creeps in there as well. Last major item of business is input checking. Right now you can enter anything into any GUI box and it'll try to work with it. This obviously is not good. I'll fix this up tomorrow most likely. Really now, the functionality is all there and working as far as I can tell. What I really need are testers and feedback. Anyone game? I can't offer much except my appreciation and thanks in the program's future README, but any help would be appreciated.

Sounds good! Are you planning on demoing features or will you actually be developing code live?

I took a little time tonight to work on two aspects of the code that needed attention. First, I added context menus to the time entry fields on both the main GUI and the departure calculation GUI. If you right click those fields, you'll be presented with an option to enter date/times as year/day/hour/minute/second combinations exactly as they are shown in KSP. This should make working with those fields much easier. Second, I did some validation of the calculations. I must say, I am pleasantly surprised by just how close I got. A quick screenshot of my results: The main thing to note is that by entering the burn values into MechJeb's node editor, I was able to get the targeted intercept with Duna. I had to eyeball the true anomaly of the burn, of course, and use MechJeb to adjust it until I was close enough. That didn't pose much of a problem, though, and was quite easy. I did notice that the flight time was a bit different from what I predicted, but I put that down to my orbit and departure time not being exactly entered into KSP TOT. It was within a few days, which is "close enough" in my book. I'll probably try a trip to Eeloo tomorrow as another form of validation. Since it's inclined, I expect it will make a more interesting challenge. Thoughts?

I've updated the application to version 0.2. (The URL location of the KSP TOT package remains the same, however.) This update is primarily focused on providing additional information for analyzing departure orbits from a particular planet. I've provided a new dialog box that is used for this purpose: This is accessed by computing a porkchop plot and then tapping the "compute departure orbit" information. Enter the information in the box that comes up and away you go. Protip: in this dialog box there is a button labeled "Select Departure/Arrival Date." If you tap this and then click on the porkchop plot you previously generated, it will fill in the departure/arrival times with the point you clicked on the plot (so aim for somewhere blue!). As usual, feedback and comments are always welcome and requested. Please let me know what you think!

Sadly I did not, no. Not for lack of trying, though. By the way, Fyrem, could you continue any discussion or posting you might do over on the new thread I linked to in post 96? That'd be awesome. Thanks!

Cool! So there will be a way to define recipes in the context of the converter module? I can't wait!

So will we have the ability to define multiple converter recipes? Any idea when we might see this in Kethane?

How do you compute the delta-v costs for each destination?

I think we're talking about the same thing. Your last paragraph is precisely what I'd like to see, as well. Speaking of which, has anyone tried adding new resources into the game with Kethane?

Hi everyone, I've noticed that on the wiki, most of the entries for planets seem to be missing RAAN and argument of periapse in their orbital parameters information. Does anyone know where I can get that data from? Or better yet, does anyone have those two parameters available for all the celestial bodies in KSP?

Ah, I should clarify. I don't mean that you should be able to use arbitrary resources to get arbitrary resources. Reactions should be defined and have set inputs and outputs. If the same part is used for those reactions, well, not a big deal in my mind.