diomedea

Smart and effective little mod. Thanks for it.

If what you mean if on mouse events related to the toolbar buttons, please know Trigger Au is developing with those for his own mods.

Great! Many many thanks for this development. Will try and see how it works.

The ability to store an array with any kind of variable that is possible to define in kerboscript. Really need that. And thanks. About the bootloader, I will probably never use it, unless there was a way after kOS boots to select one specific program from a list. That would be possible if kerboscript is expanded with the INPUT statement, but as it stands now I can't see a way out.

Does that mean what I read? At last RT2 works with your additive model?

Happy to see you're updating this fine mod. I would even like to see more in this venue of realistic experiments.

In short, I would suggest to make a check with any Command station or communications relay in low orbit around a designated body, such as Kerbin. No other station allowed to establish a failsafe reconnection than the above. These failsafe checks to be conducted only when required (such as with the probe focused) or, if feasible, a random check may bo done every fixed amount of gametime to better simulate what would happen in reality, and the result of the check more successful the shorter the distance from the base station. I hope that is feasible and not too heavy in terms of processing power. Some longer ideas about the above. IMO, a failsafe program IRL would scan the ether to find any valid signal. Will take time if the signal is faint, almost lost in the spectral background noise from stars and cosmic rays. But such noise changes with time (like e.g. Sun activity) so there's no telling (for a probe) when a signal will be heard again. They keep scanning until there is power. Thinking deepspace probes, as the Pioneer ones. Anyway, such deepspace probes maintain some knowledge of their position IRT planet Earth, so they don't have to re-orient the main dish and scan a larger area. Not having to re-orient, saves power. Even if the standard range system would be a limit, I believe that having the probes pointing at Kerbin in failsafe mode is key to a realistic approach. However, with Kerbin I would not limit to KSC, but any Command station on the planet and communication relay orbiting in LKO (at least). I reckon that the angle at which a LKO orbit is seen from deepspace is small enough to be considered almost a point, for this purpose, so a dish on a distant probe would be aimed so to have optimal gain with any signal from LKO. However, somebody may develop a huge communication infrastructure on other planets, then relieving Kerbin from this "central role". One suggestion here: to define a planet/moon as the communications hub in one of the config files (default Kerbin), and let a player change it. Any "lost" probe should always try to connect with the designed hub. EDIT: given the many who like to play without failsafe mode, the mod may simply consider a "null" value for the communication hub in the config as a failsafe switch off.

Disagree in whole. I plan a lot in advance about network engineering, or I would not use RT2 as a mandatory mod with my games. Making things contrary to logic does not improve gameplay. I refuse to believe that the spirit of the mod is to create unneeded and unrealistic difficulties. But you are free to believe what you like.

Have not tried with kOS myself, though I know some about it. kOS includes a function "INCOMMRANGE" that returns the status with comms. Don't know if that would only work with the active vessel or not, but anyway may be enough to let start some form of recovery procedure once the "lost" probe was focused. However, I don't know of anything in kOS to let me give a command (e.g. "TARGET: KERBIN") to a specific vessel part, like a dish. kOS allows action groups activation, but I have never been able to assign the target command with a dish to an action group. Then, there were reports about kOS incompatibility with RemoteTech, at least with KSP 0.22, so I am not sure kOS would work at all to this end.

@ toadicus: excellent. My only gripe is that I must, again, update your TBwrapper source. It seems I will never catch on. You write faster than I can read!

IMHO, it would be fair to assume that any probe has a fairly basic program always running, the purpose of it to automatically search for any signal in range in case of a loss of connectivity. In reality, this program would actually also command a scanning pattern with a dish. Nothing like the ability to directly provide a new target, but the result would be the same. That is, unless kerbals were really so clumsy to send a probe without any fail-back capability...

@ PhaserArray: based on current cryotechnology (on Earth), IMO there is no chance for a spontaneous wake-up (as in idea 1). To revive a subject in cryostasis, it has to be warmed above 0°C, then some form of saline solution must be let in its cells, and let clean them from glycerol. This fluid substitution is pretty slow, it should take days to complete also because the low temperature hinders osmosis. To keep cells from deteriorating during this phase is probably the most difficult aspect in the process. It is a slow, tightly controlled process that requires some continuous power to keep parameters under control (temperature, pressure, salinity...). Actually, it may be less dangerous to suffer a loss of power during cryostasis (as it takes time for temperature to rise in the cryo chamber) than during revitalization.

I can't but notice that the icons with this mod are the same for Crew Manifest (no wonder, you told to be using that as basis for this). Anyway, I believe this one merits to have its own. Though my skills at drawing icons are not all that good, please find here what I propose (loosely based on standard symbology for a manual controlled ball valve) (License: do what you want with that).

Impact pressure = Total pressure - Static pressure (http://en.wikipedia.org/wiki/Impact_pressure) however, the above will just move the issue to "how to get Total pressure" ? Therefore, I would use Dynamic pressure (http://en.wikipedia.org/wiki/Dynamic_pressure), and in particular: q = 1/2*ÃÂ*v2 meaning, dynamic pressure is directly proportional to air density (that is inverse exponential to altitude) and squared speed.

IMO, options 3, 4 and 1 in that order. Further features to add (using typical BASIC keywords here, but not necessarily the same with kerboscript): - INPUT statement, to let the program wait for a value from the user then continue using that value. - GOSUB... RETURN, to manage subroutines within the same program (instead of having to load another program to do that). and with the above, of course, some form of label, to name the subroutines.

@ togfox: here some applications of kOS. But those are just to give an idea. Imagine that any sequence of commands, whatever complex, you will be giving to a craft, you run a program in kOS instead.

@ Camacha: yes, I heard of Progcom and totally concur with what you said. My idea is different mainly because the user will still use kerboscript, and I believe this language is, even as it is now, much friendlier than any low level language like ASM or even simulated machine opcode. Somebody may like using opcodes, but I believe most users would find kerboscript much easier. Sure, Progcom is proof that a similar approach may work.

That would be a solution for people who know how to build plugins. But kerboscript is not confined to be used only by those who already are fluent in C#.

@ Rosco: well, I know what an interpreter is, thanks for trying to explain. And I know what a compiler is, too. Therefore, no doubt kOS is an interpreter for the kerboscript language. I probably wasn't clear enough. Starting from kOS, so possibly keeping the same parts and interface, would it be possible to build a compiler for kerboscript? Of course, then the compiled code would be used at runtime instead of the script, therefore such a compiler must code in a way that the code can be used by a runtime engine working within KSP (UnityEngine ?).

Bingo! Exactly on spot. And i thought to be safe not having copied the 000_Toolbar folder from NavyFish mod, didn't check for another embedded dll by the same name. Thanks a lot.

@ sarbian: I have a weird issue. I use the tooolbar plugin and a lot mods with it, of course including Crew Manifest. In flight mode, Crew Manifest shows a button with the toolbar, along with all buttons from other mods. However, with KSP 0.23, Crew Manifest is the one and only mod to make a second button, in a second toolbar (with just that button). Both buttons work, and no button for Crew Manifest is shown out of flight mode. Didn't happen with KSP 0.22.

Given the presence on this thread of many who may be able to further develop kOS, I have a question for them: would it be possible, at least in theory, to develop a sort of "compiler" running in kOS, so to achieve very fast execution of the kOS code? Many thanks for any answer.

Don't know if it is just with my game, but the active area for toolbar locking/unlocking/autohide is really small and appears to be positioned in the lower right part of the rect where that small triangle appears with the toolbar. I believe that, if correct, the active area with those toolbar functions should be covering the whole part where the triangle appears (e.g. the rightmost part with a horizontal toolbar, where no button is displayed).

ceiling(). I always keep this available (but if I may suggest, those contents should all go with the Wiki).

set PI to 3.1415926. print round(PI,3). // output= 3.142 print round(PI,0). // output= 3 print round(PI,5). // output=3.14159