diomedea

What? You *only* played 80 hours since you joined (like 50 more days ago?) . Well, that must be rectified, and you should also be spending more time on this forum (time spent on reddit doesn't help here). So, we want to hear something more from you soon .

One small issue that could deserve some effort to correct: on occasions, PreciseNode window goes blank (I remember to have seen this happening with past versions, at least since 0.9 but possibly before). For blank, I mean the windowrect still displays, and the two buttons marked O and K on the border, but nothing inside it. O and K buttons do work, but nothing else (like e.g. the P key). Now, have observed this happening when, already very close to a SoI change, tried to move the node time so it would happen on the other conic patch. Therefore it appears PreciseNode can't manage a change of conic for the node it is dealing with. From the above, would like to ask: - at minimum, a check to be implemented so to make a node stick with the conic it was generated for (with possibly a warning for users trying to move it out of those bounds); - at best, a way to move the existing node across a SoI change (e.g., could a new node be generated on the other conic, retaining all DV settings of the original that could be deleted at the same time?) P.S.: PreciseNode returns to work correctly after deleting the culprit node and some fiddling with the settings.

Thanks technogeeky for showing the plan. An orbit prediction feature indeed would be great, having it selectable (so to not always be shown, also because I suspect it may take some time to compute). Sure it will require a bit of time to find a perfect match of colors/opacity to render fine on the map. Let me join others in telling, I'm happy to see somebody taking care for this absolutely needed mod (thanks to Dmagic, too). We can't say if, when, Damny will post again, and sure everybody is waiting more from him. But this mod has a lot of promise and it is a pity not to see it being further improved; if you are going to deliver some of what is possible with it (while keeping it as Damny would have done, and sticking with the license Damny chose), than I believe it is a service to the KSP community as a whole.

Ben arrivato tra di noi, StuntMax. Penso che la tua storia sia emblematica, almeno qui possiamo capire la stanchezza dopo giorni passati su KSP .

The idea of making the orbit dots match with the swath width is neat. However quite often I am interested to actually see the already scanned map, and those large dots get in the way. Would it be possible to allow the user to choose between dots of minimal size (just to represent the orbit) and the large ones you did?

Very effective the spinning diamond, Navy. Really like it. Anyway, how good it shows when displayed over an orange part (like the Jumbo-64 tank)? As you already tried changing the diamond alpha value to make it more evident, you certainly already have code ready to change RGB colors, and it could turn useful to create alternate colors of the reticle, making it visible against any possible background. Or even making hue pulses, while also keeping the spinning (believe the most different hue from orange is cyan: what about a reticle pulsing hue orange/cyan?).

Welcome aboard. Well, good you don't like the game. If you liked it, you may forget about having a life beyond Kerbin (whenever I can, I keep spending 12-15 hrs/day about KSP, though not playing all time).

Loads perfectly now, and happy for the updated sourcecode. Many thanks.

Albert VDS, I need some help about the latest version 0.2.9.1. It works fine, when I install it on a clean version of KSP (0.23.5.464). However, on my heavily modded main KSP install (same version), where I already had working the previous HullCamVDS version (released Dec 30), installing the new version (or even only the new plugin from it) causes KSP to hang while loading. In the initial screen, it shows "HullcamVDS/Parts/aerocam/part/aerocam" when hanged. From KSP.log, the last lines: [LOG 01:01:33.245] PartLoader: Compiling Part 'HullCameraVDS/Parts/aerocam/part/aerocam' [WRN 01:01:33.258] PartLoader Warning: Variable impactTolerance not found in Part [EXC 01:01:33.260] NullReferenceException: Object reference not set to an instance of an object Finding what is wrong here is beyond my possibilities, but I hope that warning message could suggest something to you. Not sure if that missing variable is tied to your plugin (but is the only thing changed when the issue is present). BTW, could you please update the sourcecode linked in the OP? It seems to be months old, so I can't find from it an answer to my question above. EDIT: if it helps, output_log.txt; the relevant data seems to begin at line 32180.

I am grateful you keep improving this mod. Version 1.0 means a major target achieved (as stable release, perhaps), therefore congratulations for making that .

As I had the opportunity to tell you already, please ask if you have specific issues. It seems to me you are setting for the more suitable strategy (option 2 IMO) about Molniya orbits, so you don't need much more advice, but just to experiment them in KSP. The kerbstationary orbits may prove tricky at first to get right. Actually (as in reality on Earth) we only need orbits to be within some margin of error to call a success: for kerbstationary, what is important is inclination close to 0°, orbital period very close to 6 hrs, and a very low eccentricity. But success can be called only if you can place the satellite above a specific longitude. So, in my planning to achieve those, inclination comes first, and apoapsis to 2868.75 Km. At apoapsis, I then raise periapsis looking at the orbital period (you use MJ, it gives you that), I know each minute beyond 6 hrs means 1° in longitude more to the west when a full orbit is completed. After one orbit I should be exactly matching longitude and back at altitude 2868.75, so burn to have periapsis at the same altitude and therefore eccentricity =0. I am not sure about the scientific satellites. KSP science is based on situations, like different biomes. So I would use vessels headed to make experiments in all different situations. But I understand you like to simulate realistic orbits (like used on Earth). About the GPS constellation, I am sure you can find all info you need from Internet. GPS-Navstar in reality uses 6 orbits with 4 sats on each (all needed data from that Wiki page), but coverage would be obtained with many other possible configurations (perhaps, not all able to ensure an all time coverage as the chosen ones). If you can successfully make kerbstationary and Molniya orbits, you won't have issues making those inclined GPS orbits too.

I welcome this last feature about memorizing a maneuver node. Some time ago I wanted to have a posiibility to create and compare different navigational plans (post #261), and I reckon keeping maneuver nodes in memory is a needed step towards that goal. Well done, blizzy.

I have the main axis set the same as you, just feels better flying a plane that way. As you know, KSP has no different settings for rockets; in case, it would certainly feel more natural to set the yaw with x-axis. It helps me that a rocket doesn't need to be controlled at all times, mostly I do during ascent and landing, and often using keys instead of axis is enough. With the roll set on x-axis, I use mostly roll, then pitch during ascent (instead of a quadratic pitch/yaw control); for landing, I try to find perfect yaw alignment first, so to then need control pitch and throttle (if done right, only small yaw adjustments are needed). For RCS, my preference is to use the slider control for forward/backward (centered), the big rotary on the throttle for left/right and the small rotary for up/down. But I use also keys quite often, and must say your RCS x/y set on a 4-way hat is a very good solution.

There are 2 excellent tools available to give (also) dates for interplanetary transfers (or, launch windows): - Alexmun's Launch Window Planner (web app); - Arrowstar's KSP Trajectory Optimization Tool (matlab runtime required). Also, the problem can be solved by MrEnigma03 Protractor (KSP plugin), though it is based on angles/time differences rather than on dates.

I have a X-52 pro, and therefore had myself to try how best to make it work with KSP. About your questions: - No way to switch axis based on mode. KSP has absolutely no knowledge of the different modes on a X-52, so the only way is to associate different actions to them with the Saitek programming software. But even with that, there is no way to switch axis (only the behaviour of each axis and button). - KSP is based on Unity (4.3.3 in its latest 0.23.5 version). Unity only recognizes generic joysticks (see the list of Unity keycodes here) and, even if possibly it could handle up to 5 different sticks, it recognizes only buttons 0 to 19 for each of them. Therefore, KSP can't recognize (and is impossible to assign) any button beyond 19.

Tried to land on Jool's "surface". Almost succeeded with a unconventional design... (vessel stationary at 0 altitude) but the state didn't change to "landed" (as expected, though). Will probably keep devising tricks (but nothing like Jool modding or savegame editing), though I am already content with that kind of partial success.

Sure anybody can open *.pas with any text editor. But a proper Pascal/Delphi IDE makes code more readable, and beyond that it actually compiles the .exe (what I actually did, I am not happy when checking if my compiled code is significantly different from what is published). To make a plugin, you will actually totally change how your application works. Please note I am not suggesting you should do that, your tool is conceived so to not require KSP to be runnning, and that leaves out most possible bugs. Beyond that, all plugin functionalities are tied to Unity functions, written in C#. Unless you want to venture into transposing Unity functions in Pascal (possible, but a tedious task), that leaves only C# as an option to write your code.

Hi, welcome aboard. I'm sure your english is above average (being a not native english speaker myself).

You are right about an exe file possibly being malicious, and certainly not working on other OS's. (though, good Pascal compilers exist for Linux too, so if anybody wants, he can make this work from the sourcefile). And yes, .pas files are sourcecode in Pascal/Delphi. But at least for me, I do have that compiler handy (Pascal actually being my preferred language!). So, checked the code and can say there isn't any malicious part in it (very easy even if not commented - the beauty of Pascal being so easy to read). No bug checking, however. C# has a clear advantage, due to Unity interface with plugins, but there's no rule against any other language.

Many many thanks, Codepoet and Papa_Joe, for clarifying. I am indeed happy with things as set now. I reckon a new version of CLS may come out anytime, as well as ModuleManager, so my preference is to have separate downloads. It is already a hardship to keep the Toolbar mod updated, while other mods still package outdated versions of the same (thus, overwriting the newest version if those mods are the latest installed). If you agree, Papa-Joe, I would like the dependencies in the OP be listed along with their version (the latest you are sure works with your SM version). Something like you already have with the Toolbar (though 1.7.1. and 1.6.0 versions are both reported).

Thanks for this great improvement! I would like some advice about the CLS integration/dependency. I had both CLS ans SM installed and working before, and now am keeping CLS installed with this new SM version. But if I get it right, now CLS is integrated in SM, so there's no more need to have it as a separate mod installed. Is that right? Anyway, CLS allows me to highlight the connected spaces in VAB as well as in flight, while I can use SM only in flight. So I may keep CLS installed anyway, if there's no conflict from having the same functionality twice.

Probabilmente sì, c'è un bug (però ho controllato, non è riportato tra i bug aperti che Squad conosce). Mi ricordavo di aver visto tempo fa qualcosa di simile, ci ho messo un pò ma alla fine l'ho trovato in questo post e quelli successivi. Ma siccome làsi tratta di un mod, non hanno potuto correggere quanto è ritenuto un bug in KSP.

From the readme.txt in your KSP install (line 191): * Maneuver handles can now be fine-tweaked with the mousewheel when hovering over them. I know the readme is for dummies, but I'm sure other goodies can be found reading it.

Dunque, mi hanno dato qualche rassicurazione circa l'apertura della nostra sottosezione. Ci vorràqualche giorno, forse anche qualche settimana se si verificassero altri contrattempi, ma la "cosa" è pianificata. Probabilmente ritengono terminato il mio "periodo in prova" ed ora decideranno se va bene. In ogni caso, ti ringrazio per il pensiero. Avere almeno un altro moderatore era anche l'idea che avevo indicato all'inizio, quando mi hanno "fatto il provino". Speriamo quanto prima decidano di ampliare il team. Comunque, le mie assenze sono sempre brevi, e l'impegno non manca. D'altra parte, le sottosezioni spagnola e polacca sono tuttora senza un moderatore ufficiale (ci sono moderatori dediti ad altre sezioni che conoscono quelle lingue, ma non sempre possono controllare tutto), quindi la continuitànon è condizione necessaria. Inoltre (l'ho anche fatto presente) tra di noi attualmente non si sono mai visti problemi che richiedano l'intervento di un moderatore (mentre di interventi ce ne sono, eccome, in altre sezioni - a volte anche da parte mia). Cambiando argomento: docking port lontana dal CoM: fatto, senza tools, ma un vero incubo (era un SSTO in "visita" ad una base orbitante, con la docking port sul dorso ma vicino al muso), tra l'altro avevo anche posizionato gli RCS ad occhio e non erano perfettamente bilanciati. Assolutamente manovra a vista, cercando di mantenere l'orientamento corretto (ci avrò messo almeno un'ora).

There is a tool I once used that could come useful to allow to see how a process (KSP.exe being a single process) uses memory: Cheat Engine. Though, trying to get good readings without knowing how the data to be tracked is called, is probably quite difficult. Never tried on KSP myself.