Arrowstar

Can we expect a 0.7.3 or will this go into 0.8?

Okay, I understand what you want. I'll see about implementing this tomorrow. Sorry for the delay, I've been having too much fun with the Kethane 0.72 release. 1) I'll look into it. Not sure how hard it'll be to keep everything synced up, but will investigate. 2) Yes, I need sane defaults. I actually had it doing this originally, but I ran into a bug and the workaround was to eliminate the default setting. I've got an idea to fix it though, will try to get to it tomorrow or this weekend. I'm working on that right now. The math is all figured out and coded up, but the problem is still very tricky to solve. Not sure at this point if it will every make it into the main program. Keep checking this space for more updates.

Was there a live development stream yesterday? Or are you referring to the previous stream last week?

Ah indeed. Yes, one of the most important features of fmincon (for me) is the auto-differentiation. If I didn't have that, I'd either have to write my own, which I grant you would not be too terrible, or try to find analytic gradients for my problem, which I suspect don't exist. It makes my life a lot easier that MATLAB can do this for me, and in a (fairly) sophisticated way. Out of curiosity, what do you do that has you working with numerical problems such as the one you described?

Guys, I think serious thanks are in order here. It appears Majiir just pulled an all-nighter so we can mine digital green gas from digital planets and moons, and that's really a lot more effort than is (or should be!) required to maintain a mod. Majiir, you rock and Kethane rocks. Go take a cruise to the Bahamas or something.

That's the one. Thanks for pointing this out. I had this solver on my hard drive from another personal project a while ago and just grabbed the binary. I've added the license text file to the KSP TOT ZIP file. It's worth noting that I am using a "real solver." Indeed, the algorithms behind fmincon are quite sophisticated. What you mean is that you'd like to switch to a global solver... which is fine. I'm not using one of those here because I spent two years of graduate school working on this problem with MATLAB's genetic algorithm solver (simulated annealing is garbage for this.) It worked... okay, but it's very CPU intensive. As only as I only have 1 or 2 design variables to adjust (such as depart and arrival time) I'd rather just use the very quick fmincon and MultiStart, which works well for what I'm doing. That said, if you make progress, please do let me know about it. I'd be happy to see! Noted. I'll see what I can do. Okay, so it sounds like you actually want to minimize time of flight while allowing the code to shift the departure time to help minimize it further. I can do this. Unless, of course, I'm still not understanding, in which case maybe you could illustrate with an example. Yesterday I added notes in the relevant GUIs to help alleviate this. Thanks for the suggestions/tips tavert, Lone Wolfling. Very much appreciated!

Majiir, when KSP 0.21 is released (soon hopefully), will updating to that version (w.r.t. Kethane) simply be a matter of moving our save folder and Kethane folder from GameData into the new 0.21 installation? Btw, I've been using 0.71 today and with the exception of previously reported bugs, everything looks good!

Hey Majiir, did you mean to have the Resource Info tooltip appear in the flight scene (both while the scanner is off and on)? It feels a bit odd.

Woot! Thanks, Majiir! That's hilarious.

Nice! Can't wait to play with it, Majiir! You're the man! Woot woot! I don't suppose you'll tell us what the secret is? (Yeah, didn't think so, lol.)

Another update: In addition to some of the work I described above, I also added the line of nodes to the transfer orbit plot: By rotating the image, it's easy enough to see which node is ascending and which is descending. I don't want to put markers on the map because things are getting pretty cluttered, so I hope this line is sufficient for everyone's purposes. As usual, suggestions and comments welcome.

Thanks, I'm glad you're enjoying it! I believe so, yes. Let me investigate though. It may be a bit of a hack since that information (time elapsed) is not natively available in the function I use to generate those. But I will see what I can do. EDIT: Yup, not only is it possible but I've just implemented it. In the process I cleaned up some calls to the MATLAB multistart solver and put them in a common function for easy access later. I also standardized the progress bar windows across all computation functions (they all use the same function now, so they all look the same). It's a small improvement that really adds a bit of polish on things. So basically what you want is a "minimize time of flight" function that is constrained by delta-v and varies either arrival time or departure/arrival time? Fixed. I've basically told the code to look for errors when doing so and throw up a nice message box with the error message MATLAB gives if something goes wrong. Fixed. Thanks for noticing. I thought about this, but decided against it. I don't want to force people to remember to set the plot type before they go into that window. My thought was this: even if you're only interested in optimizing the departure dv, you may still be interested the arrival dv as well, because it influences your aerocapture or whatnot. Hence, I made a separate option so people could have flexibility. One day I will have an option where you can alter and add to the celestial bodies in the application. Part of this is their orbital parameters. When I get this done, you could always enter your spacecraft's parameters here and then use it like you would any other planet/moon in the game. Those are the boundary between the Type I (short way, transfer angle < 180 deg) and Type II (long way, transfer angle > 180 deg) cases. The physics works out that you typically get this high delta-v boundary between the two sets of cases. As an example, see this JPL-generated porkchop plot. I believe it's doing this already, actually. On the departure information window, those are 3D plots. MATLAB has a bug in it where zooming in on 3D plots physically makes the axis larger, which means it starts to cover up other elements of my GUI. Hence, zooming has been disabled on those plots until I can figure out a work-around (not likely, I've been trying for years). Not immediately possible but on the radar. I am going to do a type of "burn planner" tool within KSP TOT that will compute the burns and whatnot based on information you provide about your vehicle. Part of that could be a "multi-burn" setup where you put a cap on delta-v per burn or specify the number of burns to break things up into, yes. I'll make a note. Thanks for the great suggestions! Btw, all bug fixes I've specified above will show up in v0.6... ---------------------------------------------------- Now for something completely different! I thought I'd share a picture from my trip to Jool yesterday. I used KSP TOT to plan the journey (of course) and after plunking burn times and delta-v info into MechJeb's maneuver node editor, this is the transfer I got in the game. I don't know about you guys, but nailing the transfer on the first pass without having to modify any of the numbers KSP TOT gave me is pretty awesome, I think.

I'll just leave this here... *whistles*

You know, if you were to release it on Tuesday, not only would you be following a time honored Orbiter-Forum.com tradition of releasing major add-ons on a Tuesday, but then you could play this video when you do.

Can I read into this far more than I legally should and (thus) make hopeful comments about 0.7 being released on/before Tuesday, then?

Nice! Out of curiosity, why the design choice to not show all resources at once on the map?

Sounds great. The new scanner map sounds like a blast to use. I'm also looking forward to the ability to define multiple conversion recipes in our converters, perhaps that will make it into 0.8.

Any other features coming in 0.7, Majiir? Or is the scan map the big thing?

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?