diomedea

I am sure that same guy (hint who he is! ) now knows much better, and not only about that feature.

Knowing there will be nothke making those parts, I would not like to not have them. But, many "computational" tools were questioned because of their reliance with parts (MechJeb, Protractor, Kerbal Engineer Redux, kOS itself, to name a few). I would propose the possibility to have two different setup for the same functionality, and believe it may be as easy as to set a switch or a config value, to let the user decide if Jebnix is made dependent on its parts or not with that user install.

@ regex: I would like to ask for a very minor improvement. PreciseNode main window (the one that automatically appears when a node exists in map mode) has those two buttons marked (by default) O and K, that open options and keys panels. Those two tiny buttons remain active while the relative panel is open, so I would expect them to be used to toggle the same panel off. You may smile at that, but it is so more natural to me, I always try to use those buttons, instead of the ones on the panels (quite less visible). What about changing their behaviour to toggle mode (on/off)?

@ Mildmicah: You want to find the distance among three satellites, all of them moving along the same orbit, their mean anomaly exactly at 120° one another (perfect triangle when orbit has eccentricity = 0), this orbit having period (T) = 3 hours? First, you need to find the orbital radius "a" (in case of a perfect circular orbit, both semi-major and semi-minor axes are the same as the radius). This formula gives it: a = (µ (T /2 À)2)1/3; µ = gravitational parameter; À = 3.1415... In case of Kerbin, with T= 3 hours = 10800 sec, that formula gives a= 2185.176028 km; given Kerbin radius = 600 Km, the altitude is 1585.176028 With the orbital radius "a", you can find the side of the inscribed triangle, with this formula: side = a 31/2 , that is = 3784.835903 km.

While you or others may want to implement any other feature, stress for me is relevant in relation to Life Support because a stressed kerbal consumes more oxygen (and of course produces CO2 in the same amount). The most important factor for "stress" will be, for me, to have it proportional to the perceived G (acceleration), with a minimum set to 1. Yes, that makes life a lot less comfortable while living on a massive planet, but also would have effects while in flight.

Hi Toadicus, installed version 0.6.0. over the previous one, it seems to have issues with decouplers and stack separators, they don't appear in staging and computation of engines thrust seems broken (believe as a result). When reverting to the previous version, all returns normal. My output_log.txt and a screenshot. BTW, thanks for this mod!

@ LameLefty: concur, both on keeping sarbian in a good mood, and in general about the "precision" thing. More than 99% of my flights, I am just fine with a mild correction burn anyway. On the other end, I am not even sure if a correct analytical solution to this problem is computable. If not, either MJ is able to find solutions by recursion (and I have no knowledge if that's the case), or we have to accept lower precision, similar to what I may obtain by simple projection of the destination planet position at a time equal to the amount spent to fly all orbits required to complete the burn. If I know how much DV I can put at each passage, I can compute the orbital period of each next orbit, so that time is rather easily computed. My method only holds in case the planets are on low eccentric orbits and I don't even dare to make a transfer with an inclined orbit that way. But, if I want to get to Eeloo with a low-thrust engine, I may really depend on a tool like MJ to find a better solution.

Understand you are concerned with precision, and thinking if you split evenly the burn, one orbit before and one orbit after the correct burntime, you would still get the same. However that isn't the case. After each partial prograde burn, each orbit takes longer, and therefore the equivalence does not hold. If possible, MJ should compute the phase angle to the destination planet with a trajectory that takes the time of all the single orbits summed up.

Certainly that example helped a lot to make it clear, thanks for that. That resembles to me how methods and properties are parsed by the editor in a modern IDE. Hope that is doable also in Jebnix, sure it gives a lot of "programming power" to the user. A lot more powerful than what a simple script would allow.

Uh, sorry, slow down a bit, I'm not following what you mean... "we can code to invoke an action of a part..." not related to the action group system, to me means you want to invoke a specific part.module and those are coded in the KSP.exe (the native ones) or in plugins built to support those parts. But that means to me, Jebnix should be made aware of all part.module definitions (even for future parts!) and include some way to call the methods in those plugins. That certainly requires coding, but by Jebnix author, not by a user who will just create scripts to be run in Jebnix. So, if I'm wrong or missing something, please clarify your idea.

That was really fast! And now works perfectly for me. Many many thanks.

Thanks Majiir for adding that feature. However, it may need one little improvement. After having been in map view, the Kethane button is shown on a toolbar in all scenes (including SpacePort, Research Facility, VAB/SPH). Believe this is due to a missing check while setting the button like "ToolbarButton.SetButtonVisibility" that should return true only for the scenes where the button is required (e.g., "GameScenes.Flight").

That is absolutely right. Actually I was not thinking to have the update done from within KSP, but did not elaborate on that. A possibility could be to have an external tool, the user may choose when to run it, or it may be configured to be run before KSP. Or, only version checking would be automatic, new versions would be flagged for the user, then the user may choose when to download and when to install each newer ones.

You must be kidding. Not a lot using the toolbar? Just look at the list of the mods using it with the first post. I keep track of some 70 mods, currently, of those only 3 have buttons and not yet using the toolbar (one abandoned, two because the developer has no time and made no update yet). And about your rant with the mods lifecycle, how is that tied to this anyway? Apart that many a mod here with KSP have been supported by new developers when the original author had no more time for them, if a mod is abandoned it makes no difference at all if this was using an update tool or not.

This would really be a major improvement over kOS. It would make programming much easier to be able to enter angles directly (Pitch, Roll, Yaw), instead of rotational vectors from a reference direction, as in UP + R(0,0,180) + R(0,pitch,0). It took me days to figure how kOS (and KSP) handles the internal frame of reference and it remains an unneeded complication to me. Just as KSP keeps that reference for internal purposes only, but shows angles that are consistent with the relative orientation of the craft (IRT the main body), the same approach would be best if used by Jebnix.

@ blizzy78: I believe here above is a fine way to see this "update facility". Developing from this highly successful toolbar and its now proven concept as a tool offered to other developers for implementation in their own mods. What if you would create another tool, its purpose to allow automatic checking and seamless updating for any mods, that other authors may choose or not to use?

That concept is interesting. I see that not much in the way of a "distributed intelligence" to each single part, but about specific actions for each part triggered by different events, all those "scripts" active concurrently within Jebnix CPU. But to implement that, I hope those actions can be executed independently of the standard 10 action groups + standard switches, or we run out of possible actions pretty fast.

Of course you're right, and I thought about it. Nothke's 6s tubes do work for this purpose. Clearly, we would want to see them in all diameter sizes, or to have them fitting diameter and height procedurally. But also, should those tubes be textured differently then a "all-purpose storage compartment", when used in this fashion? Yes or no, your's and nothke's take. What I really was about, is the modular system instead of those cylinder parts that kOS uses.

To your final question, though I use VS Express rather than MonoDevelop, it is just a matter of providing the references to the UnityEngine.dll, Assembly-CSharp.dll and Microsoft.CSharp.dll with the project with this sourcecode, then you're set to have a successful compile (unless of errors because of new code). A suggestion: avoid any hard dependency with any specific key-combination for the terminal open/close functions. Better to have these configurable, one never knows if those key-combos will be used by other mods or Squad itself in future.

That would be really nice, and I have no doubt about nothke's ability to make those parts a reality. However, the Saturn V IU to me seems like a ring able to hold, support and power the instruments, rather than a cilinder "block" with a fixed set of instruments inside. That IU should actually allow, in KSP, to hold other instruments just as easily (to name, any part with existing mods that provide data and guidance, like MechJeb, Kerbal Engineer Redux, Protractor...as well as some of the measurement tools from standard KSP). Therefore, I believe this "unit" should be modelled as: - a set of rings, in varying diameters, to hold and support instruments of different kinds (Jebnix or not related); - a set of instruments, to be internally attached to a IU ring, to provide CPU power and harddisk storage, specific to Jebnix.

Yes, you're absolutely right. Unfortunately I wasn't in "debugging" mode while making that landing and did not think about saving the output_log.txt, then I tried another thing so it got overwritten. I may have to reproduce that landing again, but if I note something, I will provide the log next time.

I found MJ landing not working correctly, too. I have to manually set the deceleration burn, while having already MJ on autolanding. Moreover, MJ doesn't seem to decide how to orient the ship. Having then the blue marker over the red one because of my manual setting, and after having manually oriented the ship retrograde, MJ will execute the planned burn at the correct time. However, it doesn't stop the burn at the required DV, I have to retake control and kill the burn myself. All in all, better not to let MJ do any autolanding as it stands now (this was with MJ devbuild 157).

The above is, in a way, similar to the idea of "stress" I pushed some time ago. IRT comfort, the lack of it would be one of the causes for stress, and I still want to see that implemented, together with a range of other variables that effect how kerbals would act and be proficient during a mission. Comfort, or stress, would be just one value to be considered in Life Support, but to be managed in one or more other mods.

Did you change something in the toolbar source? Last time I asked, you confirmed me the toolbar rect was to remain a private class and therefore unavailable for modders to reference it.

OK, thanks for clearing RT2.