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.

Here we go:

So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. And, while we are at things like that, if I may make a feature request... So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.

Feel free to PM me the original existing icons, if any, and what modifications to make to them or what new things to create. I will do my best.

The option that allows selecting Body-Fixed mode could have a third option, "Automatic", which would do exactly that. The icon could change background color when Body-Fixed is enabled, whether explicitly by the user or internally by the automatic mode. While this does not make immediately clear what the background change does, it could be mentioned in the Readme and be a useful and well visible indicator for users that know what it means. I would be glad to provide an edited icon for this.

I simply rolled back yesterday's mod updates and it seems to have fixed the issues. I probably shouldn't have done this, now that I think of it, but I have also removed the file from Google Drive, that's why you couldn't see it. I'm sorry for the disturbance, the error was on my end.

If so, I presume it is some mod compatibility issues somehow dependent on the MM version... Could anyone give me a hint on what to look for in the log to see which mod breaks things?

Are there any up to date IDE packs for kOS? I see there is that old GitHub repo (https://github.com/KSP-KOS/EditorTools), but it was last updated two years ago, and the language has changed pretty significantly since then. What do you guys write kOS with today?

MM 2.8.1 breaks the game on my extremely heavily modded install, that is, at least sometimes on launch, the vessel doesn't work, because at least some modules don't get patched, plus the date is set to Y999 D499 5:59:59. Switching back to 2.8.0 fixes it. The log is 4 MB large, so here is a Google Drive link: https://drive.google.com/open?id=0B7ucLuOwxKVYN2JyOERsdms5ZEU Also, feature request: Could MM move the cache, checksum and similar files to some folder in GameData? I may be alone with this, but the bunch of files at the end of my GameData folder do bother me...

How feasible would it be to implement own failure modes configuration? That is, a place where you can specify what kind of module should fail and how it should fail in some cfg file? I am asking, because I believe it should be possible and it will allow custom support patches for virtually anything.

The problem here is, the lift calculation requires much more precise knowledge of the vessel shape while being a comparably small effect, and I don't think implementing that outside of KSP itself would be feasible and worth the trouble. What I could possibly do is create this tool in kOS rather than JavaScript, which could account for lift and be precise with drag, though. On second thought, this seems to be the only feasible way to do it, actually. I am sorry, but I don't think I can help with that. I will be glad to help if there is anything I can do, though! :-)