APlayer

You, Sir, revived my most favourite mod. This makes you my most favourite developer, or at least very close to that. Thank you.

Another problem I encountered is figuring out the aerodynamic properties of a vessel. I have not found any direct command in the documentation which would yield, say, the drag constant given velocity, altitude and atmosphere for a prograde motion. The next step was trying to record it from the stock aerodynamic GUI as a function of Mach number, and from that function calculate it on my own, but I failed at that too, because there is no way to get the temperature (required for Mach number calculation) at a given altitude in a given atmosphere. So I am forced to record both, the drag constant as a function of Mach number and the temperature as a function of altitude in order to calculate basic aerodynamic properties of a vessel. Is there any efficient workaround to this problem? Or am I missing some actually existing command?

Don't worry! :-) I will meanwhile try the button grid workaround, and see what "resolution" I may achieve before things slow down too much. And if that doesn't work I will simply skip this part - the already existing GUI offers alternatives to images and plots, even if they are not as visually appealing. Also, from totally zero knowledge on that matter - would it be possible to create a canvas from some element's background image by editing and reloading the image file/object/whatever during runtime?

From this documentation, I derive, I can at most create a grid of buttons with colored backgrounds and this way plot an image and record click coordinates? I guess this is possible, if the large amount of buttons does not break something. Is there no better way to do this, though? If so, is perhaps some sort of JavaScript-style Canvas GUI element planned for the future of kOS?

Is there a possibility, even if it requires abusing something, to plot raw image data/individual pixels in a kOS GUI, and perhaps even get mouse hover/click coordinates? I am looking for such a thing to create graphs to help visualize and choose trajectories and/or flight plans.

Hi there! I've been wondering for some time, is there a library, or even a command, to calculate the total available RCS/Reaction Wheel torque? I found this Reddit post, but this seems like re-inventing the wheel and not really reliable. Is there something people already created?

Okay, good to know. No worries, it's not too bad. While you're at it on this module, may I also suggest a thing? I think many players make sounding rockets in their early career games for a small science boost. But the experiment module prevents this by requiring lots of time to gather the science. I think it would make more sense to split the experiment modules into two pieces of data (the kind of data that you see when you click "Data" on a probe core): The "initial" data - which is collected immediately and makes up say, 1/3 or 1/4 of the total experiment's science value and 1/10 or 1/20 of the total data size (I am not sure, something quickly transmissible anyway). And once this initial data is collected, there would be the "Long term observation" data, which makes up the rest of the science value and data size. This would happen per biome, that is, if you enter a new biome and the experiment switches to observing it, it creates another piece of initial data. What this is for, are suborbital rockets in the early career game and fast flybys (Moho, hehe ) later. Currently, one cannot collect any meaningful science from those, which may prevent or at least discourage this kind of missions. The proposed system, however, would ensure an immediate science gain, but still encourage longer term observation missions by reserving most of the science for them. This also adds some realism - you get some knowledge about a place by looking at a momentary set of data, but you truly learn about it when you observe it over some time. And I believe it will only require comparatively minor changes to the experiment module's code to implement.

I tried this with KScale64 and the clouds seem to be an altitude of about 30 km. Obviously seeing clouds in almost space is not nice. Unfortunately, I do not understand the configs myself. What value would I change to adjust this?

If I recall correctly, Kerbalism creates ModuleManager patches on the fly. Changing settings would not work in-game - you need to do it when unloaded, for them to take effect once KSP starts up again and Kerbalism creates the new patches. Also, I believe my last question went unnoticed. I tried looking in the settings and the Wiki on modules and found that the science experiments should not require a crew (there is an option to do that, but it is disabled). Is it me doing something wrong?

I am currently trying out the "Experiments" extra. I have a probe in orbit which is basically a command pod, reaction wheels, solar panels, a battery, an antenna and three science experiment parts: Radiation Scanner, Barometer and Thermometer. Whenever I try to run one of those experiments, I just get a yellow text "no operator", but it did work on an earlier craft with a crew, which unfortunately was only suborbital. Do I need a crew to run those simple experiments? Is there a way to disable that, for at least some of them?

This didn't work either, but, taking a closer look, it seems that the throttle actually gets set to 0 for a second, but immediately resets back to 1. With the help of oren on IRC, who reminded me that WHEN blocks finish running in one physics tick, I managed to fix it by moving things around: // Falcon 9 second stage script // Launches the rocket LOCK THROTTLE TO 1. LOCK STEERING TO HEADING(90, 90). WAIT 1. STAGE. WAIT 1. STAGE. SET launchProfile TO LIST( LIST(500, 90), LIST(5000, 65), LIST(10000, 45), LIST(25000, 30), LIST(40000, 20), LIST(50000, 10), LIST(60000, 0) ). SET prev TO LIST(0, 90). FOR pair IN launchProfile { SET a TO (pair[1] - prev[1]) / (pair[0] - prev[0]). SET b TO prev[1] - a * prev[0]. UNTIL ALTITUDE >= pair[0] { SET targetPitch TO a * ALTITUDE + b. LOCK STEERING TO HEADING(90, targetPitch). IF APOAPSIS >= 75000 { BREAK. } IF STAGE:NUMBER = 3 AND STAGE:LIQUIDFUEL < 2600 { LOCK THROTTLE TO 0. WAIT 2. SHIP:PARTSDUBBED("s1-CPU")[0]:GETMODULE("kOSProcessor"):ACTIVATE. STAGE. WAIT 3. LOCK THROTTLE TO 1. } } SET prev TO pair. } // circularize

So, I'm making this automatic launch vehicle and programming it with kOS. But I am having trouble with the code - a thing that definitely should work, for some reason does not. I asked a few people on IRC and they couldn't help either. What am I doing wrong? // Falcon 9 second stage script // Launches the rocket LOCK STEERING TO HEADING(90, 90). WAIT 1. LOCK THROTTLE TO 1. STAGE. WAIT 1. STAGE. WHEN STAGE:LIQUIDFUEL < 2600 THEN { LOCK THROTTLE TO 0. // this line is not working WAIT 2. SHIP:PARTSDUBBED("s1-CPU")[0]:GETMODULE("kOSProcessor"):ACTIVATE. STAGE. WAIT 3. LOCK THROTTLE TO 1. } SET launchProfile TO LIST( LIST(500, 90), LIST(5000, 70), LIST(15000, 45), LIST(30000, 30), LIST(40000, 15), LIST(60000, 0) ). SET prev TO LIST(0, 90). FOR pair IN launchProfile { SET a TO (pair[1] - prev[1]) / (pair[0] - prev[0]). SET b TO prev[1] - a * prev[0]. UNTIL ALTITUDE >= pair[0] { SET targetPitch TO a * ALTITUDE + b. LOCK STEERING TO HEADING(90, targetPitch). IF APOAPSIS >= 75000 { BREAK. } } SET prev TO pair. } // circularize The line I commented as not working is, obviously, supposed to stop the engines from burning during staging. But the throttle just stays at 1. The line does get reached, I checked that with a HUD message. Also, it is not a matter of using SET or LOCK, both don't work. The rest of the code performs as intended too. Could anyone help me out?

Try making the patch :FINAL. The problem may or may not be that Kerbalism overwrites your patch.

Yes, yes and yes. What do you mean by semi-transparent? What should the opacity be? And what buttons are needed for the GUI?

I have used the Habitat Pack whenever there was a working version, since I found it ...and you just made a working version. Thanks as much as the internet can convey, man, you're really amazing for maintaining all those mods! This. Absolutely.