diomedea

Yes, you explained that very well and I am in agreement with your points. I had not proposed anything like multi-orbit searches, but sure that would be useful if done within some limits. If different orbits have comparable solutions in terms of required Total Delta-V and Total Flight Time, I would certainly like the possibility to have them shown together, would help choosing when and how to make a mission. The best I can do currently is to figure myself what kind of orbits may do the job and have FF or KSPTOT find solutions for each one, than put the best solutions from all different orbits together by hand (in a sort of agenda of launch opportunities). But, in particular for manned missions, I never like trips that take too long. I would say that, with reference to the Kerbin-Duna transfer, I want to arrive on Duna using the least DV possible the earliest as possible: as the synodic period is 227days and the best transfer time 66 days, I can't have to wait longer than 227+66= 293 days to arrive; then, any orbit that takes more than 293 days is not of interest. Actually, I would also discard orbits taking longer then the time left to arrive on Duna (taking in account the current day, so to know how long it is before the optimal window for direct transfer). With other planets, the situation may be somewhat different. If I want to arrive on Eeloo, there may be a lot of different trips to consider, most using less DV (thanks to grav assists) than a direct transfer. And quite possibly some of those trips may also take less time. In that case, I may be fine with waiting that "perfect alignment" so to use Eve, Kerbin and Jool as waypoints, even if it takes years to come (while the direct transfer window, not counting the eccentricity of Eeloo, represents every 113 days). So, my rule of thumb is to use the most massive planets as waypoints, and see what solutions they give: if the trip duration is acceptable (not too longer than the direct transfer), that trip is useful and the relative windows get into the agenda. Other trips may be even better (e.g. K-E-K-E-K-J-Eeloo ?) but what tool is able to find solutions with 7 different passages? So, there is another limit. If all those limits are to be observed (let say: no more than 5 passages; no more DV required than a direct transfer; flight time not much greater than direct transfer; and total time to arrival no greater than what would be required for direct transfer, unless of very significant gain in DV) than probably a logic could be built for a tool that implements multi-orbit searches. However, it would be a lot of work and require refinements.

Nothing at all to hold this masterpiece from being released , and allow all interested users (even ones wary of beta or pre-releases) to enjoy.

About the colored text, would suggest to check VOID from Toadicus, it does allow both to have colored text and to change that color based on user interaction. Protractor as well has colored text. Another one is ScienceLibrary, text changes color based on situation. ScienceLibrary also has resizable window. Other mods do, but are much more complex, so I would look at that first. VOID includes the ability to change skins. Other mods do, more or less with similar effect. Can't really say about changing the anchor-point. I reckon Toolbar (by blizzy78) has some mechanic that allow it for toolbars touching an edge, a solution I would consider adequate also with AGX.

Sure I also like the option of grouping AGs together, even conceived that idea but didn't tell as I believe it to require a lot more work. I don't know enough of Unity to help. I see other mods can do something similar to what I suggested, so believe those are possible. If needed, I may try to find what other modders did in sourcecode to implement similar features (though, you are probably better than me reading code, once you know where to look).

Time to consider final touches with this mod, then (about features, those are really awesome ). Having played plenty with it, I would like some options to better configure its GUI. I tend to keep its window with the AG list open in flight, but situations change with each vessel so some configurability options could be of help. 1. The anchor point for the AG list window seems to be its top-left corner. Fine if the list goes to the top of the screen, not so if to the bottom (either tht list is too long and goes outside, or too short and stays too much in the middle). ALready have lots of tools that are better in the top, so need to place AGX in the bottom, would be perfect if the anchor point was the bottom-left corner. Maybe make that an option? 2. Skin and Font used, would be nice if changeable. 3. Size of the list windows: would be nice if could be enlarged, both vertical (so o choose how many AG are shown, rest to be scrolled) and horizontal (so to allow more or less of strings to be displayed with AG names) 4. Would be real nice if a color could be assigned to each AG, and the string of that AG name shown in that color. Would help distinguish different sets of AGs (e.g. a color for basic controls, another for scientific experiments, a third for engines management...)

Great improvements, as always . Comments time. 1. My first thought, one can't have too many tooltips: moar tips (so to cover most significant objects shown in the plot window). My second thought (scratch the first), tips can not always be that good: the datatip at the cursor position is nice to show actual data, not so much if keeps displaying what that data means (after twice, users know that). My suggestion would be to put that tip (about the Delta-V shown) with the Delta-V scale, if possible. 2. Nice. And of course now one has to try both the normal transfer plot and the MFMS for ballistic trajectories. And wonder why results are not the same. Then check again, find what was left out, correct the entries. Then marvel at the accuracy while both tools show exactly the same . 3. Very useful those bounds in Flight Time also for MFMS. 4. Nice touch. Beyond the content, now KSPTOT also has the appearance of a professional tool (let me add, thanks for the mention, too kind ).

While I personally don't want modstatistics (nuked that from my PC), I also checked its code and can confirm that: 1. it is conceived to have only the highest version running of all the ones found; 2. it does not create files outside of the KSP folder. Of course it sends info to a remote server, that info is collected in files (but no rule forbids remote servers holding anonymous info). But, I may have missed something: if you know of any rule breach, may I remind that it would help to report the offence to the moderation team (by use of the little triangular button below the offending post) ?

Just discussing the engineering of the plants so to have all needed parts modelled, if possible (heating, filters, valves, thermal insulation...). No need to also have the micromanagement, though if it could be possible to just put a value in a config file (e.g. electricity required = something) to have that and so allow users to change as they like, could be even better.

Perhaps a simple text (or a tooltip) with both axis to remind the user the time displayed (departure date, time of flight) is always relative to the whole trip, while the title about the leg shown is only about the way solutions are displayed. Sure after figuring it, it becomes easy and natural, but I kept thinking each plot was showing dates relative to the specific leg. Wasn't for your help, I would not have figured it . Sure some users (me first) are not astrodynamicists. Even knowing what V-inf is in hyperbolic orbits, to have it not included in a solution leaves me that "totDV" that is somehow less easy to figure (also, because thinking "Total", I figure all DV required for the trip is accounted). From what you wrote above, I have a sketchy idea this "totDV" is the amount obtained from all gravitational assists + all the burns done at flybys, leaving out the initial burn (ejection from the starting orbit) and the final burn (injection in the arrival orbit). If that was correct, this "totDV" value is golden, absolutely important to know. Just need to properly figure these values, then. No need to change how the V-inf selection boxes are managed once the concept is clear. Thanks for explaining .

Fine. Thanks for shading light on that. It's just the way data are shown, it was written it was Total Delta-V for the trip but I figured the axis were meant for only the selected leg - so I expected a marker to mean something specific to a leg, and that had to be in match for the other legs. If my choice was the point @ 2,6 on the first leg, I had the idea to be selecting a specific flight time with that leg, so the start point on the next leg was fixed. But if the plot on leg 2 if the same range of solutions, just shown differently, then clearly the choice is unique for all legs at the same time. Useful anyway to have the markers. Unfortunately, I still must include V-inf for the plots to make sense to me. I accept what is shown is Total DV, but again when a plot is almost flat with values less than 65 m/s for a flyby, those values make me wonder what I'm reading. If I use the MFMS to compute the same flyby, it finds a single solution that requires some thousand m/s. The flyby plot has no correct data about the starting orbit, but still I would expect something more closely related to that MFMS solution (actually, I would expect to find that solution and no better one in the range of dates used by the MFMS, but similar solutions at regular intervals of dates due to synodic periods matches). I fully agree about showing Total Delta-V. The plot allows to choose a best solution in a range of dates when you need to make that trip, and to see how the solution gets better or worse with time, but the choice is because of Total Delta-V so that is the correct thing to show.

@ John FX: yes, I can see a number of advantages in the arrangement you depicted. Would say it is most useful for a spaceship or space station. Can't say for sure that this could always be the best, have to think if e.g. a Mun base may require different solutions. Much depends if storage has to allow an uneven flow of a resource, so the excess has to be stored while it can't be used. And the cost of keeping that excess must be kept to a minimum. So, to allow such possibilities, I tend to accept the idea (from Chris_Pi) that water may be kept also in ice form, instead of being all liquid as I stated in my post #244.

Keeping reference to the item # previously established. 6. Scrollbar: much better now (only thing, a user must already know its function, as there is no label about it: possibly a popup giving a tip?). 9. Perfect. Also the contour levels number works great . 10. I should have better explained. The marker lines work, but keep track of just the departure date: if that's day 161, the line is found at date=161 on each leg now. But if I select a specific point with the first leg, I'm taking both a departure date and flight time; then the marker with the next leg should be placed at the date= departure+flight time, that is when the encounter occurs. And if the solution is unique (I mean, with selecting the specific point on the first leg, I am actually choosing one specific solution with all the legs involved in the trip), then also the flight time with the second leg is selected, so it would show as a single point on that leg. And so on, unless some trips allow multiple solutions: in that case the user may have to be offered the option of choosing which. Can't say if it could be done entirely, however. 11. Sure there is something I am missing here. I expect information from the flyby porkchop plot to have some resemblance with the transfer porkchop of KSPTOT. However, V-inf choice only exist for the first, while departure DV is used for the second (then perfected with knowledge of initial orbit parameters). I expect V-inf to tell me what speed my ship goes outside the SoI (at infinity actually), so if I include departure V-Inf I should get the whole speed I should have for both exiting SoI and the planetary transfer (no departure burn actually, but MFMS gives that nicely). I expect to find help from the plot to choose when best to depart (and to arrive), and that includes leaving SoI. I may be totally wrong, but if Delta-V shown was only the planetary transfer part (under the Sun influence alone) that may explain why the plot appears quite flat (when no V-inf is selected). It may mean something to others, but a flat plot means less than I like to me, and therefore my preference for including V-inf.

Already very good with 4 planets. Very interesting the K-E-K-J combo. Pity the tool can't work for moons, would be quite useful to find how to build enough DV to leave the Jool system using some gravitational assists. Interesting the idea about zooming in. Works, and greatly so. Sure if a feature existed to automatically enter proper values for the zoom, from the flyby selected from the table, it would make zooming a lot easier.

There are definitely different advantages with keeping a substance liquid and others with letting it get solid. For normal water, believe there is no contest that it has to be liquid to allow its use. Bar that. For waste water, having it liquid allows flowing. If we are just to store waste water to keep weight onboard, sure, we could let it solidify: but what is the advantage there? Should be better to just let it out of the ship. Instead, waste water could still to be considered a useful thing, if the ship has some treatment plant (including those hydroponic greenhouses). Sure waste water should then be made liquid to let flow, pass through some filtering device, let some chemical reaction to occur. Not the whole amount stored, but at least the amount to be used. Of course, any piping should not allow ice to form, so heating around pipes/valves could also be considered. However, keeping liquids heated requires energy, so it would be wise to limit heating to only what is strictly required. Separate vessels for solid/liquid phases could be a solution. Probably not so much a single vessel with a liner bag, cause the heat exchange would be very high and doesn't allow to keep separate phases: or heating is good enough and so the whole is kept liquid, or not and the whole becomes solid, blocking the system. Better to use different "bottles", each one with a separate heating, so only the one to be heated will consume energy and have liquid inside; all the rest can be let go to ice. Another consideration, thermal insulation. Probably is best to have the whole compartment with those devices insulated and kept at a relatively high temperature, than to allow different vessels inside it with very marked temperature differences. The energy required to keep a high temperature differential would probably be more than any benefit in logistics. So, if a plant with different "bottles" is designed, the bottles to be kept warm should go together, while bottles to let cold in another area of the ship. Other thing to consider, pressure. Liquid phase exists only within limited pressures; for water, from 612 Pa to 2.2 GPa in the range of temperatures suitable for life. So the vessel (and connecting pipes) has to be a pressure vessel for water to be liquid. Those are real serious problems in aerospace engineering.

I take reference from the points # as numbered previously. Happy about 1, 2 as implemented. Great . About 3, Delta-V scales correctly now. About 4, happy for the implementation. Would suggest to shrink the combo-box (too wide now to show just a percentage) and put some text like "Delta-V fraction" close to it. About 5, changing waypoints in the table works (somehow it didn't for me with pre-release #1). About 6. Yes, I believe that scrollbar is confusing. As a minimum, there is no need to have it spanning the whole X-axis, I would reduce the size, that will both free some space on the window and make the scrollbar appear untied to that X-axis. About 7. I keep monitoring KSPTOT. It now shows RAM use when doing a multiple flyby, and it skyrockets. Good thing is now KSPTOT tells to have gone out of available RAM (probably that also happeded before, but silently). Then, reducing the number of points per axis allows to remain within the 4GB limit, and a plot is generated. About 8, better so, the plot shows great! . New things: 9. Also the entry box for the number of points to be plotted is too wide. At most, it would hold 3 digits, so I would reduce it and align it to the text line "Number of Points Per Axis", to be shortened a bit. 10. I would suggest to show a marker on each leg that ties in time with markers on previous and further legs. It would help to see, if I am interested in a specific point in time (possibly, because I spot a nice DV minimum on a leg), where my choice brings with the other legs, by showing markers at the appropriate time and duration on them. For planning purposes, it may even to useful to have a possibility to mark different spots on a plot (so, a number of markers, maybe in different colors), so the user may check what each one would bring with the other legs. 11. A bit worried that sometimes data shown are less than correct. The plot below shows a Kerbin-Eve leg, all points have solutions with Delta-V less than 65 m/s (I notice the ejection burn for a Kerbin-Eve transfer requires > 1000 m/s). Note that V-inf boxes were not selected. If results are uncorrect, possibly V-inf should be always selected (not even de-selectable?). I'd like also to show how good and significant plots can be generated now: this one really helps!

Daishi, glad to see the mishap with your PC has not put you down. Nice drawings, serve to remind that an artist is such with or without tools. Grey/Waste water container, IMHO, should be quite similar to a normal water one (certainly not a can or barrel-like), as the issues with storing a liquid while in space would be similar. And that brings me to think, probably those containers for water should also have some heating device if the water is to remain liquid.

Hope what follows is useful and not a simple list of features still to be implemented or improved that you already know about. 1. As could be expected, the flyby porkchop plot does not put the cursor at any specific location in the graph (unlike the transfer plot does for the least Delta-V point). Though, a minimum Delta-V point may probably still be shown within the current plot. What is really missing is however the data box from the transfer plot. I notice MATLAB allows to create what is called a "Datatip" inside the plot, but currently what it shows are X, Y, and Level values (instead of Date, Flight Time and Delta-V, and possibly other relevant info pertaining to the specific point). Also, it seems the datatips appear not exactly where the cursor is placed: another MATLAB quirk, perhaps. 2. While the Zoom feature in plot works great, it appears less easy to pan the plot. Numerical limits for dates and Flight times certainly do, but are less easy to use. 3. While using Zoom-recompute, the scale of Delta-V should adapt to the range of values present in the new plot. That would help a lot make out areas with different Delta-V. 4. Remaining on the theme of Delta-V scale, there is currently no bound that the user may select. Some plots show large areas with a Delta-V at the bottom of the scale (dark blue) and only small areas with higher Delta-V. My impression is, 10% of the points plotted take 90% of the color scale. I would easily use an upper bound at 20% of the current limit for Delta-V, and redraw the plot not caring of those little areas outside the bound (those would not be of interest anyhow), then having more variety for values on the scale. So the suggestion is to allow the user to define at least an upper bound (if not also a lower one) and balance the color scale within those bounds. 5. Changing waypoints in the table (as well as adding or removing ones) currently seems to not have effect. Recomputing a plot with a different set of waypoints still gives the original one. To draw a plot for a different set, is needed to close and reopen the flyby plotter. Then, to alter the waypoints and see what could differ is not really possible; but is not even possible to open two different instances of the flyby plotter at the same time so to compare. 6. The scrollbar below the plot (actually used to select the different legs) being placed just below the dates axis and aligned with it, seems intuitively to hint at being used to scroll the range of dates. If MATLAB does not allow a better way to make controls for selecting legs, at least that scrollbar should be moved to a different part of the window. 7. Multiple flybys aren't easy. Tried a number of times to make a plot with 4 waypoints, when computing initially KSPTOT shows briefly "Generating Flyby Porkchop Plot. Please wait..." but then nothing appears with the first leg selected, and scrolling to further legs brings up that dialog again apparently without ever completing. KSPTOT does not crash, but uses very low amounts of CPU power and has no impact on memory (monitored by Process Explorer). 8. The "Porkchop Plot Information" textbox on the right of the window is not updated. Should I say, I am actually thrilled by how fast you implemented that plot? The list above may seem to suggest there is still some work to do, but the amount already done is impressive .

It is simpler to make your mission as a sequence of burns aimed at achieving a specific goal. If you already are in a circular low orbit around Kerbin (LKO), the next step would be to make the inclination match with Minmus: set Minmus as target, so the line of nodes appear; then open a maneuver node on either the Ascending or Descending node and add some Delta-V to the normal component: when doing right, the inclination shown for the orbit after the burn will get down, you should aim to make it close to 0.0. Form the orbit already on the same orbital plane of Minmus, the next step would then be to plan the Hohmann transfer (that I bet you know about). It is not mandatory to make separate steps, and some steps may not be needed at all: you will make an encounter with Minmus also with an inclined orbit, if the encounter point is with one of the nodes.

It was tied to the Kethane overlay, it didn't show on the big map, all others were working fine. Even rebuilding the Kethane map wasn't of help. Updated both (Kethane to 0.8.6; SCANsat to 7.0rc2.3) now everything seems to work. So, that issue probably isn't worth further effort, maybe some file wasn't put in the correct place (in which case, it could prove impossible to recreate the issue after the update). Thanks for both the suggestion and the update that solved this .

Happy to see the Flight Time bounds and a name for the plotted leg. Pity Total Flight Time can't be done, but you were already telling; as long as the kind of clear plot you showed with the second image on June 6th can be achieved, I will be happy with that . About data for legs beyond a given body if that was deleted or another body added before. My first idea was about deletion of all data beyond that body, but then not all flybys are the same. The effect of flybys can be so very marked (an Eve flyby is certainly so) to radically change whatever comes next. But, with other flybys (Duna while aiming at Jool) the change is limited, so data about the legs further than that body may be worth keeping (question: could also a passage close to a moon, like Laythe, be considered a flyby while going to the parent body, Jool ?). So, a criteria could be the relative gravitational parameter of the bodies involved: Duna's being lesser than both Kerbin's and Jool's, its flyby may be added or discarded without a radical change to the whole flight plan; Eve's is greater than Kerbin's, so adding or deleting it will be markedly different. However, gravitational parameter alone may not fit, and would be better to compare gravitational pull at periapsis? Returning to a previous subject, may I ask, have you already checked feasability with exponential scale for Delta-V?

Confirm the issue found by dtoxic, Kethane 0.8.6 is not compatible with SCANsat. Made KSP crash when entering flight mode, very similar log. Reverted to Kethane 0.8.5 However, I am having another issue (indifferent to the Kethane version), with SCANsat 0.7rc2.2 (and a ton of other mods installed, but can't say those are involved). I am getting a long list of "MissingFieldException: Field 'SCANsat.SCANcontroller.ResourcesList' not found." lines since entering flight mode. From the sourcecode I have sure this ResourcesList field is effectively defined and handled by ScanController, though I can't find where the exception is generated. Savegame seems to be in order, and I can't find any relationship of that field to other mods. Here the output.log; if required, I'll provide other files to help debug this.

Given we have multiple possible plots with any flyby, I would suggest a title showing what the plot shown actually is. In the image you linked, I bet Flight Time gives out the plot is about the first leg (Kerbin-Eve); but for other flybys I would not be sure. From the above, I note there is need to have a selector about what leg I want plotted (or, option for the whole trip plotted). Indeed the most easy spot to put a selector is close or embedded with the table of the waypoints (left center in the window). If embedded, no other way then to have selectors on the same rows of the bodies, so the question is only if going with the departure or the arrival body to represent a leg. Because in one or the other case, the first or the last row has no associated selector, it would not be all that confusing. If possible to have a line of selectors not embedded with the table, those may be spaced so to appear at the conjunction of two waypoints in the table. Please note, I don't know what is possible to design in terms of GUI using MATLAB, I write with knowledge of different visual application development environments that make possible to link graphical elements in your code. Of course, those selectors are mutually exclusive (what generally known as "radiobutton" in Windows GUI terms). Somewhere, the selector for the whole trip has to be positioned: could be below the table, as it requires one line of text explaining what it is. Below the table and the [+] [-] buttons to add/cancel waypoints, would go the entries for minimum and maximum Flight Time valid for the selected leg (or whole trip). That association of Flight Time to the selected leg makes it almost compulsory that those entries are very clearly shown to be referenced to what is selected. How to make so depends largely on what MATLAB allows in a GUI. If it was truly programmable, a possibility would be to draw a line connecting selector and Flight Time entries. All the above are shown in the image below (I edited your image to add the elements proposed). Excellent, still improving. Can hardly wait for KSP TOT v1.1.

The easiest way I know to set a specific LAN is indeed to start from a flat (incl=0) orbit. When a vessel burns in the normal direction along its orbit, it changes the orbit inclination making it raise at the longitude 90° next from the burn (if burning +normal; the inclination raises at the opposite longitude if burning -normal). The ascending node is more or less positioned where the burn is with a +normal, 90° before that point where the orbit is raised. Then, to set the LAN at a specific point of the orbit, the vessel must burn +normal at that longitude. Looking at the figure n that wiki page I linked, you see the ascending node in red, where the inclination angle is drawn. The point where the orbit is raised is 90° beyond that, and would appear placed more or less where orbit meets the violet line (actually, that violet line is the periapsis distance, not related to the LAN in any way). If starting from an already inclined orbit, one should figure how burning normal will alter the orbit inclination: it will also make the LAN rotate if the burn is done at a point different from where the orbit is raised the maximum (from the reference plane). However, in KSP I can't find easily the Reference direction (AKA the direction of the Vernal point), that is the origin from where the LAN is measured. The Vernal point in KSP has no feature to make it recognizable, and is just an internal frame reference for positions of objects in game. So, to make a specific LAN, my suggestion is to start with a very slightly inclined orbit, use one of the many tools that give orbital parameters (e.g. Kerbal Engineer Redux, or MechJeb, or VOID) to read the current LAN, and calculate from that where the LAN you need would go (so, if you read LAN=30°, and the desired LAN is 90°, that means it is 60° CCW on the orbit from where the Ascending Node is placed now). Then, set to burn +normal at the desired LAN (or, 60° beyond the current LAN n that example). That should do the trick.

@ Javster: if I read correctly your list of mods, you don't have HullCamVDS installed. That is a mandatory mod to have installed for Cacteye to work (as indicated in the OP). Can't say if that is the root of your problem, but you may try. And yes, confirm what you and JeffreyCor said, Cacteye is a great mod! EDIT: please note that with the latest release 0.3 of HullCamVDS, you must also update the Cacteye plugin to the version AlbertVDS posted a few days ago.

Longitude of Ascending Node. One of 6 Orbital elements used to specify the orbit of an object in space.