diomedea

There it is! Can't believe I was so blind . Thought, I don't understand, that cfg.file should be loaded at KSP start, but I am not able to select Hullcam cameras from within IVA. Oh, well, I should be asking Mihara about that. Many thanks:) EDIT: OK, solved. It works. Thanks.

I am unable to find any support for Hullcam, not in the latest RPM release version (0.14) nor in the development version on Github (0.15dev, BTW it seems to be adding support for steerable cameras). As I'm probably missing something, could you please be so kind to show where it is? Question: would it work, to add RPM support, to add to Hullcam parts config files, the same module (JSIExternalCameraSelector) that RPM uses for its JSI camera example? If so, should other modules with Hullcam parts be deleted, to avoid redundant actions, or could all be kept so to use Hullcam parts both within IVA or in normal flight view?

That is quite impressive, really good result. Though, I hope that by "minimizing distance to a target body" instead of "minimizing fuel usage", doesn't mean in the end we can't choose the destination orbit radius, nor have the plan cost more fuel than strictly needed. BTW, I like these updates of how the tool coding proceeds. Also, what strategy this tool is going to use to achieve a desired orbit inclination? In your example, it looks like the inclination was achieved by means of burning DV while entering the final orbit (step 6). I most often try to set initial periapsis from the transfer orbit so that the inclination with the final orbit is already given. If the desired inclination is not possible from the transfer orbit, I would burn retrograde at periapsis enough to lower eccentricity, but still keeping apoapsis high enough; then change the inclination at apoapsis and circularize at the next periapsis. Those are generally the strategies costing me less fuel when it comes to inclination.

@ AndreyATGB: Exactly. The only thing required is a limit on the AoA, to make a decent autopilot. Indeed what I describe is very much FAR stuff, because stock KSP has only very primitive aerodynamics. But they exist in KSP too, as you can see CL and CM differing without having FAR: a wrong profile with a unbalanced rocket won't let reach orbit, you don't need FAR for that. You say to be trying different values to find the correct profile. That is also what I must currently do. Most often, what spells disaster when trying profiles is MJ trying to steer the rocket sideways (mostly due to corrective steering), while it already has built a large speed and therefore lift. MJ doesn't care of AoA, lift, or air density to this end, it seems to maneuver the rocket as if it was outside of an atmosphere. So, the rocket does a couple loops, losing fuel and often speeding in a completely different direction then desired (even by MJ). And often the result is lithobraking, very kerbalish. I am not actually asking MJ to calculate the optimum AoA for atmospheric flight, therefore I don't even want MJ to simulate an atmospheric ascent trajectory. I just need to have the possibility to make a setting, I would jell to MJ "stop pitching" when AoA is increasing way out of safety. Why can I have MJ deal with engines overheating and not with a simple AoA limiter?

I had considered myself building something aiming to deal with Kerbal fitness (and some other abilities, all of them related to training of some sort), and just for lack of both time and skill I didn't yet. That said, I will be following this mod with interest, hoping to see it realize what I wanted. Perhaps, we could exchange some thoughts or ideas about the whole subject. And, who knows, I may even try to find time and bring something useful to this project.

@ Sarbian: the ascent profile as you seem defining it is just the trajectory that the rocket should follow. Being just a trajectory, the physical behaviour of the object is not considered, so it could be the same to launch a sphere instead of a tall cylinder. But a true autopilot must consider the forces applied and how to use or counteract them properly. Sorry if what is below is rather basic, but I better show it or my thinking may not be understood. Pardon me, I grabbed one of your nice drawings and applied some forces to the rocket depicted in it, to show what I mean: drawing here. There you see: - Lift, applied to the center of lift (CL), of course along the opposite direction of the tangent to the trajectory. Lift is proportional to speed squared, so speed os a critical factor here. The angle of lift force in relation to the rocket axis is the angle of attack (AoA); - Weight, applied to the center of mass (CM), of course on the local vertical; - Thrust. As CM and CL are far, this rocket will tend to capsize. AoA must be kept to a minimum here, so to remain within the ability of the rocket controls to keep it stable. There are two possible flight profiles possible for this rocket: vertical one up to such an altitude that lift will then be minimal when turning, or (if thrust allows) a very fast one, so that CL moves more towards the nose and AoA remains very small. Therefore, I hope in a future MJ autopilot that will actually keep AoA under control.

Must say I concur with Steven Mading here. The history of Information Technology is filled with examples of poor solutions, being preferred over some more solid and straightforward ones just to keep backward compatibility. Just look at MS-DOS Memory Management, for one. Would be better to design without such constraints, and if required to allow backward compatibility by means of a dedicated additional plugin.

As I am another follower of FAR, I use ascent with all precautions just as Nathankell explained in his post #5153. One of the main difficulties with MJ ascent autopilot is to find a profile that will not exceed a sustainable angle of attack (AoA) at any altitude. If it was possible to tell a new ascent autopilot a limit in the AoA (that varies with atmospheric density and speed), it would be better than start alt and %. Far better, for FAR users.

As you are going to implement more buttons, may I suggest to have some to store and retrieve numbers in memory ("MS" and "MR")? I would rather have those, than buttons for "3√x" or "x^3" (you already gave us "x^y" and that serves most purposes). As a further step forward (however may require some more effort), may I ask if you are planning to implement some more structured logic than the simple sequential one kalculator now has? Either Reverse Polish Notation (possibly easier to implement, but harder to use) or full algebraic notation with use of parenthesis and operators precedence. I would really love to see "(" and ")" buttons with your plugin.

Thank you and Malkuth very much. While I tried my best to find what the problem is tied to, it was you to go deep in it and find what is at its root. While absolutely consistent (and annoying) with my install, I see this problem was very elusive, but you nonetheless spent a good deal of time and effort to solve. Thank again.

Behaviour on my system is a bit different, but that may be cause I use KSP in windowed mode. I have always used the toolbar against one side of the window, for the scenes where a lot of mods have buttons and therefore I need to make the toolbar hide (VAB/SPH, Flight/Map); I prefer to have the toolbar on the lower side but don't think the side of the window makes any difference with this issue. So, until I use toolbar version 1.4.2, have autohide on and all is well; with toolbar 1.4.3 (and MCE and RCS Build Aid, just them) the toolbar is gone. From just what info I can read from toolbar-settings.dat, the toolbar rect does not move, so I should still be able to find it and have it come back from the edge where I placed it. But what you found could be very interesting, if the toolbar disappears when it is not against the screen edge as opposed to being against the game window edge.

I have no idea why MissionLibrary has anything to do with the issue I described. I found testing everything from my install (over 70 mods, actually) on a clean install, and MCE's MissionLibrary.dll is tied to this issue when in the VAB, but only when together with another mod (RCS Build Aid, specifically) and the newest version 1.4.3 of the toolbar. I did whatever I could to single out if anything else was causing that, but ended with just the above combination (for the VAB; I found the same happens with different mods in Flight). I did a fresh start with the new toolbar version, after deleting its settings, before writing of this issue. No change, the result is still the same. I hope somebody of you mod developers are able to find the cause of this. I appreciate that you spend most of your time caring for your own creations, so you have less time available to try other mods and discover any weirdness like this one above. To find these issues is ultimately in the interest of users who can spend more time playing with a lot different mods. Then, I can only make guesses as to what could be the cause. I reckon that some troubles are caused, e.g., when different mods use the same ID for one object (like a window or a button), but beyond avoiding the ID range used by Squad, you developers can't ensure that your choice is unique. No idea if this issue is in any way tied to a similar mechanism, however. EDIT: Thanks for trying about this yourself.

Found one mod combo that inhibits a hidden toolbar from showing in Flight: VOID 0.9.19 + Targetron 1.3.4.. (Note: not tried VOID version 0.9.20, uploaded today after this bughunt started). As before, the issue won't show unless both mods and toolbar 1.4.3. are installed. Here the output_log.txt for this case.

Found one mod combo that inhibits the toolbar from showing in VAB: MCE 0.43 + RCS Build Aid version 0.4.4.; just those plus, of course, Toolbar 1.4.3 and ModuleManager 1.5.6. Here the output_log.txt with just the bare minimum to have the issue. Now on to look what combos may do the same in flight, but hope that case above is enough to find where the problem is.

This is tricky. The issue does not appear with just toolbar and MCE installed. But, everytime, it appears with my full set of mods and MCE; it does not appear with my full set of mods and MCE but without the "MissionLibrary.dll". So, MissionLibrary.dll has something but only when together with other mods. It will take a while, but will be looking what combos may do the triggering. While I am at that, here the output_log.txt from my testing install when I have the issue and when not due to canceling that dll, sorry plenty of other mods. Steps: start up KSP (I use it windowed) , enter the same game (new one in sandbox mode set just for this purpose, no craft yet), enter VAB. If the issue is present, I cannot see any presence of the toolbar nor make it go out of hiding. If the issue is not, the toolbar is just lurking from the game's window border, and will unhide when the cursor moves there.

Using MCE version 0.43. All well with toolbar version 1.4.2, however with the newer version 1.4.3 I found an issue, positive from extended checks this is tied to "MissionLibrary.dll" with this mod: the toolbar does not show if it was set to "autohide" and can't be recovered unless manually editing the toolbar_settings.dat file. No other mod shows this, so it appears like a mutual interference only among toolbar 1.4.3 and MCE. (I already asked blizzy78 about the toolbar, hope he may suggest what is the root of this issue).

Done. The issue is tied to Mission Controller Extended by Malkuth, that behaviour appears everytime if I have "MissionLibrary.dll" from that mod enabled (the main plugin "MissionController.dll" does not show the issue, even if left in place, however all of the buttons from that mod appear with the toolbar only when "MissionLibrary.dll" is working). Can't say how that is tied to whatever changed since toolbar 1.4.2, it was working, now no more. Question: would you be so kind to let Malkuth know what has changed with toolbar 1.4.3, so to let him update his mod? I am not able to trace this issue further since I have no idea what you did. Good catch by you. Fact is, agises uploaded the new Ingamenotes version, but only the new sourcecode for Kalculator (seems like he forgot to upload version 0.1.1) after you found how to solve the issues over there. I tried to compile from the new sourcecode, but the compiled dll wasn't showing any button to start with, so I had to get back to Kalculator version 0.1. Possibly my fault, I may have done some mistake setting up the environment for the compile, I hope I will eventually find what I did wrong. P.S. I feel a bit sorry, I keep feeding you with issues that are tied to other mods, not to the toolbar. However without your help these issues would never be found, nor solved. Please accept my apologies (but I will keep feeding issues, if you don't mind).

Something is not quite right with version 1.4.3 that was working fine before in my install. Any of the toolbars (a different one for each scene: spacecenter, editor, flight...) that was set with autohide=true is not displaying anymore. No way to get it out of hiding, I had to manually change that setting to false and restart to have those toolbars displayed. Then, I can set them to autohide and they do work while remaining in the scene, but if I leave and reenter the scene after having set autohide on, the toolbar is lost again. Really annoying. As "usual" (longtime customer here), my output_log.txt.

Better than awesome, I can't even think of an adequate term for Mission Architect. I am doing that all by hand, careful checking all needed data and computing what I need in terms of Delta-V for any of the maneuvers, planning them all before launch to be safe I can complete a mission. I am really looking forward to it, to being able to use this masterpiece of software you are creating.

You know you can easily remap keys by editing the settings.cfg in "GameData\HullCameraVDS\Plugins" ? E.g., this is a version ot that file with new bindings coded: HullCameraVDSConfig { CAMERA_NEXT { primary = Minus secondary = [COLOR="#FF0000"][B]KeypadMultiply[/B][/COLOR] group = 0 switchState = Any } CAMERA_PREV { primary = Equals secondary = [COLOR="#FF0000"][B]KeypadDivide[/B][/COLOR] group = 0 switchState = Any } CAMERA_RESET { primary = Backspace secondary = [COLOR="#FF0000"][B]KeypadEnter[/B][/COLOR] group = 0 switchState = Any } }

KER 0.6.2.3 has one small annoying issue, at least in my install. I use it with the Toolbar by blizzy78, but don't think this issue has anything to do with it. Every time I start KSP, with both the build and the flight engineer (if present) in the relative scene (VAB/SPH, Flight/Map), KER main window starts open. Thanks, that reminds I have KER available, but most often I have to close that window and go about anything I was going to do. Looking at how the KER config files work, I see that KER saves and uses correctly the state for any of its subwindows. However, I could not find any setting about the main windows opened or closed, like the state is not saved. I believe that, when the plugin is started, it sets the main window open regardless of anything saved in the configs. My preference would be for a setting being saved/used about the mainwindow, or at least to have the mainwindow closed at start.

Do you have RemoteTech2 mod, perhaps? Somebody on that mod thread wrote it was causing duplication of crafts.

I like those modes. IMO, those cover rather realistically most of possible needs. Mode 3 may be considered able to reestablish a lost connection in emergency, something we were discussing time ago and I consider more realistical than the current "bird lost due to the other vessel it was pointing a dish to for a connection back to KSC eaten by kraken" that somebody finds so enthralling. However, being mode 3 only limited to same SOI, that feature is not completely achieved, I need to park a couple relays outside of Kerbin's SOI to be safe in keeping contact with a probe sent all the way to Eeloo and beyond. Therefore, I would have preferred to see another option, "in case of krakens", so to simulate my probe trying to get any signal from anybody in range.

@ Sir Julio: many thanks. That analysis is exactly what I needed, I hoped it could be possible to extend the relevant class but you know better. I also like that you did test something to this end, so if any easy solution was possible you would for sure have told.

You're the best