diomedea

Very nice mod and presentation . I have until now used active lights (from Aviation Lights mod) as visible markers (I like to mark docking ports and the like), but sure I prefer markers not to illuminate other parts. So I am interested in using your GlowStrips. However this 0.1 version has a few characteristics I would like to see improved. Below are a few suggestions. 1. Mass. Most data in your parts config seems to be identical to stock illuminators, that include mass = 0.015. Actually, you should scale mass with size, your 6 mt Glowstrip has the same mass as the 1 mt one. But mass also brings to use of physics. I want to note that since version 0.23.5, Squad made a number of parts act as massless to simplify physics (unfortunately that also removes those parts from calculating total mass and CoG with a vessel). If I am correct, that is because of the added line "PhysicsSignificance = 1" with those parts. Stock illuminators are now "massless" due to the above, so you may consider if your strips should also mimic that. Your choice. 2. Scalable size. For use as markers, I need parts less "bulky" than your strips. Probably the largest I would use is 0.50 cm (with similar reduction in width and height). Probably scaling your model is enough for making the trick work for me. But I believe it could be an added benefit if you could make the size a tweakable, others may find that useful. 3. Actionability. Tried to add actions related to your Glowstrips to some Action Group. The only action available for AGs is "start glowing", unless I have already started it and then the only action available is "stop glowing". That means to me there is something to revise in your module. I would expect to have both "start" and "stop glowing" as selectable for AGs, or better I would like a "toggle glowing" action to reverse the state (like many other actionable parts have).

Many thanks. I had a suspect the coincidences had to be numerous (and I hinted before at the resonance being a cause) from the findings with your tool, but certainly didn't run any analysis with the relative frequencies. You're totally right, it works because of the amplitude of each transfer window. Fields where I have more knowledge are telecommunications and cryptology, where the "amplitude" (the acceptable phase-shift) is small or null thence solutions are highly selective (or just one). Interesting, the first thought I had after reading of those coincidences above, was about the Harmony of the Worlds. Seems like KSP was engineered in a way to truly mimic our solar system, even on these levels. Or, just by coincidence... Absolutely like your plan. And I like you show interest with that "porkchop". Sure you're right, JPL runs these things on supercomputers. One thing that encourages me, is that the raw power (and memory) of the computers they used back when planning flybys for Voyager, is quite probably only a fraction of the power (and memory) of my desktop. Certainly, 300 MB or more seem a bit eccessive even for my desktop. I need one bit of info: while computing a "normal" porkchop, KSPTOT shows to be calculating 2500 "entities", and then sorts/refines the 20 best solutions. Like it is applying the algorithm to a initial matrix of 50x50 (I guess the matrix links to departure and arrival time, thence with the positions of the two bodies involved). For one million solutions with one flyby, that means the matrix is 100x100x100 (threee bodies involved ?). However, is the relative position of each body totally unrelated (so needs a whole time dimension to represent) or some of the "solutions" are actually impossible? When solutions are impossible, they should be pruned, no memory required other than a "discarded" marker. Definitely, to solve such kind of complex problems, some optimization strategies have to be devised. I hope to be able to think at something, will let you know if some ideas come. About the execution time. Definitely you're right, if I am running any process for more than a few seconds, I want to have some indication of progress. Would be nice if telling how much already done against how much to do in total. If the objective function never returns a value until done, maybe a little complication could be required: would be possible to call the objective function from inside another loop, restricting the range of the objective function at each call, so it is returning quite often, then the external loop would update a progress report? About the display of information. Any diagram (porkchop or else) is actually a limited presentation of a subset of data. 3D diagrams have the higher number of dimensions we can represent at once, though often 2D diagrams are more readable. With a porkchop the choice is in showing DeltaV or characteristic energy as a function of time (start, duration). I am interested in total duration of the trip, but having all the info stored from a range of variables, it could be possible to select other "dimensions" to show on the plot (time for each flyby, DV change for each flyby). So, I would make the "dimensions" selectable by the user, from a list of those available after the solutions are found.

Indeed it is the minimum total DV what I like to have shown. I can easily concur minima with each body involved rarely align (or we would be able to launch Voyager-type missions quite often), but the above tells me instead of a few very good solutions, a plot would show very rare optimal ones, and large areas of suboptimal ones. Am I correct to think that, with just one single flyby, the optimal alignment occurs only once (unless of resonances) in a time equal to the product of the synodic periods of each couple of bodies? So, in the case of a Kerbin-Eve-Duna flyby, that time would be 169 x 228 = 38532 Earth days, or more than 105 Earth years? (BTW, just the worse of all the flybys, involving the two planets with the highest synodic period in the Kerbol system). Well, I certainly don't want to wait 105 Earth years just to have that perfect flyby, so I am happy enough with some suboptimal solutions. This is what I expect to find form the kind of porkchop plot I was suggesting, showing some perfect solutions, but enough acceptable ones so to allow a choice without waiting for Jeb's grand-grand-children to follow his steps. KSP TOT has one very good point (among many others) that wasn't told enough till now. It is a very solid program, able to keep running in the background for hours, if needed. So, yes, I believe you are right it would take a long time to draw the kind of plot I was suggesting. But if I am serious enough in planning a mission using all the tools KSP TOT provides, I should also be allowing the time to make those computations. It won't take longer than the people at JPL did in reality. Anyway, it was and remains a suggestion. Before being the author (and therefore the only person able to make that in reality, if you like) you are also an expert in the subject. If your experience is such a feature isn't useful, that's enough: I can't pretend to know why until after I take the time to develop better knowledge on this. Nothing broken till now with the pre-release, however I haven't tried about the new constraints yet. For me, it works nicely as expected.

Now, please don't change your release plans for the next version, but I have another suggestion . In case it was possible, the porkchop plot with KSP TOT main window (or another window built on purpose) could be modified so to show Delta-Vs with a selected flyby? From a GUI perspective, it would only require to add the list of flyby bodies, between the departure and the arrival parameters. Certainly it would be a lot more difficult functionally, but I suspect some of the code already solving the MFMS algorithm could also be of use here.

Very interesting method, and very good knowledge. I am using your tool and KSP TOT to manage flybys (not that I have done a lot of them yet). Your tool is perfect to find the "flyby windows", similar to transfer windows but with the slected flyby accounted for. So, I am looking for flybys with the minimum "Total Boost". KSP TOT is able to find a good flyby, and provides quite accurate data. But it also has an optimizer built in Mission Architect, using that is possible to further refine the navigation plan. But with that tool alone currently I can't search for different flybys and select the one I prefer. So, I can have various "flyby windows" shown with your tool, and then restrict KSP TOT to solve for only the specific flyby I am interested in, with the accuracy I need.

That inclusion of v-infinity in the objective function has to be considered a key improvement, I couldn't think the difference being so marked. Definitely, yes, another impressive improvement with MFMS. Another thing to thank you about for having implemented (and thanks to others for their suggestions). Definitely yes, I like this KSP TOT version a lot. But certainly pressing you about making the MFMS isn't worth a mention, not more than the many others who contributed with their ideas.

Jaw dropped . Can't believe the speed. Watching the window while that "genetic algorithm" works, with all the scores changing in parallel, and computing generations so fast one can't follow any single one but just watch the values moving... Did a try with a very awkward multiple flyby, from Kerbin to Eeloo passing around Eve and Duna, and even if the alignment was awful, the algorithm found a viable solution within one minute . What more could I ask? Now, I am not yet sure if I am living a dream after having seen that. However, there is one aspect I would like to be investigated. To compare the relative speed I made the same flyby with both the algorithms: a "simple" Kerbin-Eve-Duna, same starting condition and initial parameters. The multi algorithm found a different solution, requiring much less DV. Here the screenshots of the two. The plot of the transfer orbits is very similar (though projected to a different angle), and the single flyby plot is more "feature complete" currrently, showing planets positions. But information in the windows to the right is not similar.

I was driven to the idea of a measure of flyby efficiency by considering the possible benefit of gravity assist instead of a direct transfer. Actually, if beneficial, the flyby will let me use less total engine DV than the sum of the burns for a direct transfer. And however, I was only thinking about one specific flyby instead of the whole trip. You brought me back to reality, yes required engine DV is what must be considered, but would be meaningless if not considered over the whole trip.

Wonderful new version, toadicus . However, I may have found a small issue: both the new panes of the advanced HUD actually show the same info, there is none about the next burn as depicted in the image you posted days ago. (EDIT: also, version in the VOID window is not updated: 0.11.0).

Almost too good to be true... but it is! Thanks Malkuth, those are great fixes .

Simple testing done, up to only 50x timewarp: ElectricCharge is consumed (and generated) correctly. Tell me if you need more, I have no reason to suspect something may break at higher timewarps. Thanks for making clear about those config. I have to check few things to see how better go. WIth those configs and your dll I had KSP resources showing a value, and TAC LS panel showing another. Nothing wrong with either dll or configs, just seems two different methods of handling a problem.

The liters config I mean is the one made by Coolbeer (here). Still unclear, until the OP returns, if TAC LS will implement liters or stay with the units representing time*consumption/creation. I will look at theTimewarp and ElectricCharge. Let me a bit of time, I have to make a new game to test that.

Confirm it worked fine for EVA, with your dll and modding the settings. Great work! (Now, I have to retry with the standard units for TAC LS, as I switched to using the liters config, and now those units show differently).

About the EVA, I get the amount is tied to the settings (LifeSupport.cfg), default amount is 43200 sec (12 hours; 0.5 Earth days but 2 Kerbin days). Have yet to try your dll, if it gives all results correctly in Kerbin days then it is what I have been looking for since KSP 0.23.5 came.

Really glad to see an initiative at sharing functions useful for a wide variety of plugins. I entertained the idea this was to be made possible, but couldn't do it myself lacking the needed skills. If correctly implemented, this will result in less code with each mod, making them easier to maintain, while loading in less memory. And, I expect these functions to be of the best quality, because many more modders will see them and contribute to their improvement; therefore less possibility of bugs. I always think at how many mods implement a part parser for their internal needs: a single parser with KAE may prove useful.

That seems good, experience with the tool may suggest if more could be useful. The current Flyby sequencer provides almost all the info required, so keeping that format will be great. The only additional info I am considering is that total Delta-V obtained in a Flyby. I am considering values that may tell how effective a flyby is (so to help in planning) and my guess is total DV would be a nice way to measure that. The Flyby sequencer provides data about the transfer orbits around Sun before and after the flyby, but not the speed components (I assume what is meaningful is the speed at SoI transition with the flyby body), the difference of those speeds is mainly due to gravitational effects and burn at flyby, though some change is also due to distance difference to the central body. The effectiveness of the flyby could be given by the amount due to only gravitational effects from the flyby body. Probably other values could be used (perhaps eccentricity difference of the transfer orbits around Sun) but have to crank out some numbers from that to make in a sound "efficiency" value.

Knowing Erendrake is "in the mix" for the continuation of RT2 is a very good sign as well.

Arrowstar, that multi-flyby is wonderful, excellent work! Just because you are asking for feedback even at this early stage, though some features are not in yet. Believe a set of data shown with each flyby would be nice (like, periapsis distance and UT, inclination, and sure Delta-V required as suggested by teal'c). Not sure if RAAN and Argument of Periapsis would be of interest for flybyers. Could be nice to have a value showing the total amount of Delta-V change due to the flyby, and some may find useful if that DV change could be split into prograde, normal and radial components (perhaps in the reference frame of the orbit before the flyby ?).

For me, that is the best announcement till now since the reopening of the forum. Waiting a new version since KSP 0.23.5 was out (didn't want to try the old version on new KSP).

Please post about your enthusiasm for the forum return in this thread here. No need to have two or more threads for the same subject. CLOSED.

Dropbox link goes to the github source: was it meant as an alternate for the compiled version perhaps?

Hi, welcome aboard. Sure you will have a good time here, and we will see about your usefulness, too .

I have what seems a quirk with missions with optional objectives. Sorry in case this was already shown, but I couldn't find. It is now happening with mission Kiana I (Kerbin SOI missions pack), and happened already with another in the same pack, If I recall correctly was Keres III. Each time I send a Kerbal on EVA, seems like that Kerbal counts against the optional objective being met. My MCE .sp file is spammed with partial objectives met: GoalStatus { id = Kiana I__PART1 vesselGuid = 353bcd92-da96-4b5c-82e7-01b8f3787f21 repeatable = False } GoalStatus { id = Kiana I__PART2 vesselGuid = 353bcd92-da96-4b5c-82e7-01b8f3787f21 repeatable = False } GoalStatus { id = Kiana I__PART1 vesselGuid = 38ec9ba0-0d75-4ce8-99cd-7b8c7e9c839b repeatable = False } GoalStatus { id = Kiana I__PART2 vesselGuid = 38ec9ba0-0d75-4ce8-99cd-7b8c7e9c839b repeatable = False } GoalStatus { id = Kiana I__PART1 vesselGuid = 2c46b5a3-f863-45a1-a5b2-48c419ba75b8 repeatable = False } GoalStatus { id = Kiana I__PART2 vesselGuid = 2c46b5a3-f863-45a1-a5b2-48c419ba75b8 repeatable = False } GoalStatus { id = Kiana I__PART1 vesselGuid = aac17f27-f08c-4406-810a-1cc3d15e3d0a repeatable = False } GoalStatus { id = Kiana I__PART2 vesselGuid = aac17f27-f08c-4406-810a-1cc3d15e3d0a repeatable = False } The real vessel has the ID as in the first couple of those GoalStatus entries, all the others seems to be tied to the "Vessel ID" from the EVA'd Kerbal (that is renewed each time, so even if the condition repeatable is = False, still fires). To my knowledge, that works because the optional goal is coded this way: ResourceGoal { description = Jettison all fuel aboard the vessel. optional = true reward = 30000 name = LiquidFuel maxAmount = 0 } and LiquidFuel=0 is true for any EVA'd Kerbal. Nice way to collect money easily, but if abused kind of defeats the purpose of the mod (so, I edit the .sp file to take all that easy money out).

Excellent news indeed . This really opens the possibility of a viable use for a multibody flyby. Congrats for that achievement. And, in case you need an independent tester for your test case(s), count me on!

Hi, welcome aboard ! Yes, KSP is very addicting, since I began with it I haven't stopped. And yes, it is very possible to configure many parts how you like them. And after some time, those skilled begin to create new ones or to develop addons. You will certainly find all that and more here. Have a good time with us .