hvacengi

set srfVel to ship:velocity:orbit. http://ksp-kos.github.io/KOS_DOC/structures/orbits/orbitablevelocity.html#orbitablevelocity

You don't need to write multiple copies of the script with different names. By default, if you have a file named "boot.ks" in the archive folder, it will be used as the boot file on new ships. So you just need a single boot file that changes your settings. Then, when you start to add more boot files you can either include the same text, or move the logic itself into an external script, or include it in one of your library files. See that documentation here. If you already have ships in the game, yes, you would need to copy the boot script to them manually. But that brings me to option 3, use Telnet instead. That way you can configure font size external to the game itself, and you don't even need to display the terminal in game. See the documentation here: http://ksp-kos.github.io/KOS_DOC/general/telnet.html It's highly unlikely we will make a universal boot file. That is only a reasonable option when "start on the archive" is enabled. And installing RemoteTech would kill the feature entirely.

They require manual adjustment. You can however put that adjustment into a boot script (all of my boot scripts automatically set the brightness to 1 and open the terminal for me).

I can confirm that you have a version conflict: Make sure you update Module Manager to the most recent version as well (I think 2.6.24)

I just looked closer at your image. The log will confirm, but it appears you are still using a 1.0.5 KSP version, not 1.1.x. The latest release of kOS is not compatible with previous versions of KSP. Just upload the file itself to one of those services (or paste the entire contents in pastebin).

Dropbox, google drive, paste bin, etc. Pick your poison.

Apparently it's player.log on OSX, per the thread above. I don't know why they have to change things per platform.

As I suspected, the issue is a conflict between 2 modules modifying mass. I've already worked out the fix for it (after discussing with @NathanKell) so we should be goo to go in the future. I'm not a huge fan of StockPlugins. Not because it adds our module to other parts, but because it hides our parts at the same time (including, for some reason, the Cherry Light which isn't a kOS processor). It also only gives 5k of memory, which is far too small if you're removing all of the high memory parts (these days most my scripts require 60k of memory at least). I like the idea, but wish it it was executed a little differently. I haven't had any time to really dig in to it, or even to decide if it matter enough for me to submit a PR to them to change it.

I'm told the output log should be in "~/Library/Logs>Unity>Player.log". You can find a better walk through here (and general tips as well): If the README file doesn't exist, then the installation isn't right. But it looks like the file exists, you're just trying to execute it instead of read it.

We will need substantially more information in order to give you any specific assistance. Please upload your output_log.txt file for us to review. What OS do you have? How did you install the mod? What version of the mod and what version of KSP? Given the only information I know is that you can't open the terminal, I would double check the installation and make sure you placed it correctly in GameData, or install it using ckan. I'll see if Nathan can point us the right direction there. The problem probably comes up when multiple modules try to use the mass, and since RO at least used to install 2 kOS modules (1 of which wouldn't work) there could be all kinds of other weird interactions.

What are you using to determine that the mass is increasing? Can you provide a log and/or a video? kOS only updates the part mass directly twice: once in a method called from `OnStart` and again in the same method in `Update`. It is intended to be guarded against any kind of inflation, as it only adds the "disk upgrade" mass on top of a "base mass" rather than the current part mass. I don't know how KIS interacts with mass however. Are you saying that you had kOS parts in the KIS storage which were growing in mass, or that the KIS storage itself was growing in mass? We will need more information in order to do any analysis. If you simply type it into the terminal, you should see the throttle move up. If you are using it in a script, the throttle will only stay locked as long as the script is running. So you may need to add a `wait until condition.` statement to keep the script running. Please provide logs, scripts, and a description of what does happen (does steering work, does staging work, etc.). It's always helpful to tell us your KSP and kOS versions as well.

Everything except setting the target works with the existing release (compared to for KSP 1.1.0) (as far as we're aware). We have a large number of pending revisions, and want to get them integrated before our next release. Hopefully that will be soon, but it's a lot to review and various devs have been short on time recently. We will be having another release which is explicitly compatible. I would like to have it sooner rather than later, but it depends on timing of reviews.

Glad you caught that, I sat down to type it up an make you an image explaining it and then got tied up here at work. As an alternative, kOS is intending to eventually (Maybe this makes it as good a time as any) expose out our kOSLightModule (the thing that backs the light effects on our processors and the cherry light) for external use. It is able to do the same thing, so you could make a MM patch to add our module if that's installed. (I say that, however for some reason my testing earlier didn't work, so I have to figure out an exact patch).

Doesn't dropping the previous module mean that the light's lens color does not change with the light's color?

Mixing the use of raw and cooked steering like this is not supported (and honestly, should have given you an error). If you are able to make it work in an instance, it probably is related to the order in which you set up the controls. Currently, every time that you call `lock steering` it subscribes to the autopilot events, and the fist time you set a suffix on `ship:control` it will bind to the events. So the two will be evaluated in the order you set them up (this will be changing in a future release as I am updating how steering is processed). Another related quirk is that every time you call `lock steering` it will re-assert itself as the last thing to update (the act of locking will unbind the steering and the immediately re-bind it). So if you set a value on `ship:control` in the parent script, and then `lock steering` in this script steering will always override the setting. If you want to try and re-assert `ship:control` in the order, calling `set ship:control:neutralize to true` will unbind it, so that the next time you set any of the suffixes it will be moved to "last in line". Just make sure that you don't directly call `lock steering` afterwards. Which brings me to a 2nd point. You really should not call `lock steering` repeatedly in a loop like your code shows. This forces an unbind/bind every time through the loop (which is expensive), and it resets the steering manager's integral components (which is actually broken in the release version, but will be a big deal in the next release). A far better solution (especially in your use case) would be to lock the steering to `tatt` before the loop, because it looks like tatt is being updated externally (possibly using a lock or within a when/then block. The whole purpose of using a `lock` object for steering is because locks automatically update (in normal code you don't want to repeatedly call `lock` either unless the code being evaluated is changed). Trim is set by pressing the modifier key (alt on windows) and one of the translation controls. You can reset it using the modifier key and "x". This is not a control listed in the KSP settings, but you can find it on the KSP wiki. I verified that on the save file provided [Alt]+[X] stopped the errant yaw.

Found your problem: CTRLSTATE { pitch = -2.181771E-06 yaw = -6.425296E-06 roll = -9.487868E-07 trimPitch = 0 trimYaw = -0.036 trimRoll = 0 mainThrottle = 0 } Printing `ship:control:pilotyaw` prints 0.035999994502792. The issue isn't the mod, just reset your yaw trim (via KSP controls, not kOS's trim). Toggling the torque wheel off stopped the spinning, so I knew it had to be something affecting the controls.

I think I'm going to need to know the precise conditions where you observe this. Is it once the linked ship reaches orbit? Does your script release the controls during ascent and you're observing the yaw at that point? Could you maybe post the save file with the ship already in the condition causing the error (my ascent script won't fit onto the small processor, so it's hard for me to test it in orbit myself). I tested this by adding surface lights to my geosynchronous satellite build and didn't see any extra yaw during ascent or after releasing the controls in orbit. But that was with 4 lights in symmetry.

When you saw that it's yawing to the left, do you mean that the controls are actively pushing the yaw control to the left? Or do you mean that the ship slowly begins to yaw to the left and the controls do not try to pull it back to the right? Any chance you could post a video, with and without `steeringmanager:showsteeringvectors` and `steeringmanager:showfacingvectors`turned on? Is it always yaw, and never any other direction? Surface mounted lights doesn't have an official 1.1.x compatibility release that I'm aware of. But I know there have been a couple people trying to update it. A quick look through the code makes me think that it isn't doing anything that should affect game physics. In theory, you should be able to make a MM patch that removes the SurfaceLight module, and replace it with kOSLightModule (which offers some similar function) and see if that changes the behavior. Not presently. The run command is very picky, it has to do with a number assumptions made under the hood. We are actively working on changing this, but there are many different sub-systems that all have to change to allow it to work.

This looks like you probably already have observed the goo for that experiment. Doing a quick test on a fresh vessel (and fixing a couple copy/past errors), I was able to observe the goo just fine the first time, but a 2nd attempt threw the same error. If you look at the print of the module, you should see that the KSPAction for "observe mystery goo" is still listed but the KSPEvent is no longer there. If this is not the case, we would need a log file and probably a copy of the save file in order to further troubleshoot. If you continue further down the page, you will find that there are additional suffixes which are much easier for you to manipulate experiments. This includes the ISOPERABLE suffix which tells you if the experiment can be run.

Everything except setting the target works with the existing release (compared to for KSP 1.1.0) (as far as we're aware). We have a large number of pending revisions, and want to get them integrated before our next release. Hopefully that will be soon, but it's a lot to review and various devs have been short on time recently.

It would be an expected behavior that your inclination would continue to change. Because the KSC is not at latitude 0°, launching due east will not result in a 0° inclination. If you would like to reach a true 0° inclination, you will first need to offset the launch angle such that you will cross the 0° latitude mark, and correct your velocity at that point. That being said, it probably shouldn't be continuing to dramatically increase your inclination (if accelerating due East, you don't increase or decrease your North/South velocity directly, so you should be traveling according to the initial inclination). There are inaccuracies in steering (it's impossible not to have them), but in order to comment I'd have to know significantly more detail about your course. Increasing inclination could mean anything from a 30°to 0.03° shift. You can modify the config setting in the configuration file itself (GameData\kOS\Plugins\PluginData\kOS\config.xml) deleting the "BLIZZY" entry. Either that or select the button as visible in Blizzy's toolbar.

Not a new problem, and honestly it's one that I've allowed to persist for too long. It should be fixed in the next release via this PR: https://github.com/KSP-KOS/KOS/pull/1544 If you could actually compile and test that yourself, that would be great. It's a rather uncommon condition that it takes to get kOS to loose track like that, so I want to make sure I've hit as many fringe cases as possible. With changes to the way that `dockingport:undock()` works now, you can call it on either of the ports. If it turns out that you call it on the one without a "decouple node" event, it will automatically call the event on the other port.

Well, more like "don't loop calls to locks". You don't have to use the parenthesis when calling a function without parameters, I just do to remind myself which ones are functions and which ones are variables. It simply makes things easier to keep track of, and it helps if you want to use a function defined out of the current scope (but that's an advanced topic that you don't need to know about... until you do).

Well, for starters you only need to call `lock throttle to thr` once. The purpose of `lock throttle` is that it will automatically update itself every phyisics frame. Which brings us to another option, you have, which is you can have the function `thrott` return the deisred throttle point and simply `lock throttle to thrott.` It is not preferred that you repeatedly `lock throttle` because that internally causes the processor to disable and re-enable throttle control every time you call it. Your until loop doesn't have a `wait` anywhere in it, which means it's wasting time recalculating the throttle until it hits the IPU limit, even though you can only really change the throttle once per frame. And probably the part that matters most to you, if you stop the until loop at 50m/s vertical velocity, you haven't given yourself much space for the 1.6TWR to need to adjust the throttle. After you hit 50m/s up, you the throttle value would freeze. Here is how I would do the part you have shown (you'll need to change the termination of the script, since I imagine yours is substantially longer than this shows): function thrott { set maxTwr to maxThrust /(ship:mass *(ship:body:mu / ((ship:body:radius + altitude) ^2))). set thr to (1.6/maxTwr). return thr. } lock throttle to thrott(). until someCondition { print "throttle is " + throttle. wait 1. }

If you just want to know if the engine is tagged, check it's own tag suffix. local en is list(). local coreEngines is list() list engines in en. for eng in en { if eng:tag = "CoreEng" { coreEngines:add(eng). local eng_isp is eng:visp. print "An engine exists with ISP = " + eng_isp. } } // do something with coreEngines There is a configuration setting for that http://ksp-kos.github.io/KOS_DOC/structures/misc/config.html#attribute:CONFIG:AUDIOERR