hvacengi

Um, good point. How did I not catch that? That block is all kinds of messed up.

I may have found your problem. That isn't valid syntax. You have to put the "if" information within the code body, not in the "for" statement. Also, the local variable within "for" loop will be discarded once you leave that scope (anything within the brackets). That's the only thing there that I see that would cause an issue. But the error could probably be improved. LOCAL en is list(). LIST engines IN en. FOR eng IN en { IF ship:partstagged("CoreEng") { LOCAL Eng_isp is eng:visp. print "An engine exists with ISP = " + Eng_isp. } }

We do not currently support getting information off of inactive engines. It's a topic that has been discussed multiple times but honestly we have things higher than it on the priority list. I am curious about the error however. Where does it throw the error, in the string addition or elsewhere?

No matter how much abstraction we may provide, you will still need to know how reference frames effect things in order to work with them. If all you mean is that some values are in local coordinates and others in world coordinates, then you can use directions (rotations) to convert between the whatever reference frame you want. You can see a good explaination here: https://www.reddit.com/r/Kos/comments/3kx83f/fun_with_rotations_conversion_to_a_shipship/cv1flsv As for lib_navball, you can find examples of how to use it in the same repository you found the script in, under the examples directory: https://github.com/KSP-KOS/KSLib/tree/master/examples just copy the two scripts into your directory, and either run them from the archive or copy to the processor's hard drive and run them.

You can lock the throttle to 0 and query the initial maxthrust before you first throttle up. Also, you literally nearly gave the steering command already unlock steering. That will release kOS's control over steering.

v0.20.0 KSP 1.1 Hype! This release is functionally identical to v0.19.3, it is recompiled against the KSP 1.1 release binaries (build 1230) BUG FIXES [KSP1.1] Removing a node leaves an artifact (#1572 #1576) [KSP1.1] Toolbar button doesn't display (#1573 #1569) Downloads Download from github: https://github.com/KSP-KOS/KOS/releases/tag/v0.20.0 Download from spacedock: http://spacedock.info/mod/60/kOS:%20Scriptable%20Autopilot%20System Download from curse: http://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files

Pre-release KSP1.1 compatible development release This should be functionally identical to v0.19.3. The only changes made were those required to compile and run with KSP v1.1. This release will only be available from Github and will not be listed on CKAN. Link: https://github.com/KSP-KOS/KOS/releases/tag/v0.20.0-pre-1 If you have access to the KSP pre-release, please test as many of your existing scripts with this release as possible. Just like Squad is using the pre-release to track down some outstanding bugs, we need your help in tracking down hard to find things that may have broken with the move to 1.1. PLEASE SUBMIT AN ISSUE FOR ANY BUGS YOU FIND. Add the prefix [KSP1.1] in the bug title. For the time being, our focus is on things that broke specifically with KSP 1.1. If you have old bugs, or if you want to see a new feature from 1.1 used, please don't tag it with the above prefix.

I'm not sure I understand what you mean by lost code. Git uses a distributed source history system and all contributions can be added from any point in the history, though they almost always originate at the "current" point in the develop branch. There is no system for locking out access to files if a user is modifying it. If you are referring to the commits that merge "develop" back into the pull request branch, that is necessary because we are not forced to follow an order when merging and what once was the "current" point in the develop branch may not "current" when accepted. I'd kindly appreciate it if you didn't imply we don't know what we're doing in the future though, we have put a lot of time and effort into this mod. The only time that kOS touches the thrust limiter is if it is adjusted using the engine's "THRUSTLIMIT" suffix, or is the underlying field is adjusted. I noticed in your screenshot that there are a number of other mods installed. We have had reports in the past of other mods adjusting the thrust limiter (if I recall correctly, it was a mod that adjusted the limiters based on center of mass, or maybe based on TWR). Can you replicated it without the additional mods?

Version 2.6.20 is the current release for KSP 1.0.5. For KSP 1.1, MM has been updated to 2.6.21. What kind of things break for your other mods? Do they package an older version of MM which might conflict?

You have two options to reduce RCS usage: turn off RCS and only use reaction wheels to adjust steering, or tune the steering manager to reduce the magnitude of oscillations. See this page for information on tuning: http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#cooked-tuning If you want to use the RCS for translation or speed control you'll need to do it using the raw steering code (i.e. `ship:control:fore`): http://ksp-kos.github.io/KOS_DOC/commands/flight/raw.html We are working on updates to be compatible with 1.1. You should check the github page fore details on progress. There are 1.1 specific issues identified there. You can also download and compile the 1.1 testing branch if you desire. We will be making one final KSPv1.0.5 compatible release (very shortly) and then we will begin making development builds available on the github page. It won't be available on ckan, spacedock, or curse. We will not be making a full release until after KSPv1.1 is officially released (no longer in pre-release). That's just a function of the fact that Squad is continuing to update KSP during the pre-release period, and we will need to continue to test with each version. When the first development build is available I will post here to alert those of you testing with v1.1. It will be important to remember that just like the v1.1 pre-release is being used to test for bugs, our development builds will also be for identifying and fixing bugs.

As the person who implemented much of the cooked steering, I don't think there's any shame in using it instead of your own PID ;-) If you do try to do a PID solution (I highly recommend that any docking script you have uses PID anyways) you should consider using our PIDLoop structure. It's better if you learn the basics of PID through your own system, but our structure will be substantially better for performance. It took my docking script from 1970ish instructions per update to 190ish, not to mention the actual execution improvements by not running through the translated opcodes. My loop may not have been highly optimized at the time, but I can tell you that the structure is pretty fast. I have a script that does some very similar things to what you a shooting for. If I find some time I may see if I can provide any help. (All bets are off if KSPv1.1 drops this week, cause that will have to consume my non-working time).

Unfortunately our general backwards compatibility message has to be that we simply don't offer support for previous versions of KSP, nor for previous versions of kOS. This is an unfortunate oversight on our part with regard to the version checker details, as I did have it fixed at one point. We will be releasing an additional version before we switch to KSP 1.1 compatibility and I'll see if I can get the version checker stuff fixed at that point. (There are some complications with trying to replace information on already released versions, but I'll see if it can be helped). Regarding your specific problem, I can't really figure out why the launch status broke. The underlying type used by KSP added an integer equivalent for the underlying enum, but otherwise the definition is the same. For that reason all of the boot scripts failed to load until we updated the reference. v0.18.2 is definitely the release where we updated to KSPv1.0.5 compatibility, so you'll need to use a version prior to that.

You should both be very pleased then because I'm planning on making it so that kOS is able to launch new ships from scripts using the craft file name. The intention is to enable completely autonomous station building and re supply runs. We're also looking into a "mainframe" terminal that runs at the KSC and would allow a master script to monitor ships and perform actions as necessary.

When I say pure cooked steering, I mean leaving SAS off and letting kOS's steering manager handle the controls instead of KSP. You can use cooked steering to point at anything you can quantify. In fact, you can lock the steering to either a vector, or a direction (the steering manager will automatically translate a vector into a rotation). Use the vector drawing feature to help you visualize the vectors you want to steer to. In your specific case, a simple command of `lock steering to srfretrograde.` or `lock steering to retrograde.`will work. Regarding the programming, I recommend reading up on the recommended programming patterns here: http://ksp-kos.github.io/KOS_DOC/tutorials/designpatterns.html#sequential-programs since it explains some of the dynamics of loops. I always try to write a program sequentially first, then as a loop, and then I look to add triggers if they will help. But avoid using triggers (when/then or on) until you understand the flow of your program (because they are more complicated than they appear). The deal with the required "loop" is that when a program exits back to the terminal, it will release controls. If you type it in at the terminal directly, these things will persist until you cancel them or reboot, but we have to release the controls and stop checking triggers when a program ends to prevent very unexpected behaviors (imagine every when block you ever add being evaluated forever). It can honestly be as simple as `wait until false.` though I would suggest you make the condition detectable (like `wait until abort. abort off.` that way you can use an action group to end the loop).

when steering = (-1) * Ship:Velocity:Surface then { ... if SteeringManager:ANGLEERROR > 20 { Steering is a bound variable, and will return the direction that steering locked to, not the direction your ship is facing. If you want to use vectors, use ship:facing:vector, but you might as well use the steering manager's angle error suffix since you're already using it anyways. In addition, once you unlock steering, the steering manager will stop updating the angle error (because there is no reference direction to compare to). I'd say you're using your vector condition and steering manager condition backwards. I'm also a little confused by your mixing of if and when without showing a loop. The if block will only be executed once, and it will be evaluated immediately after setting up the when block. If the condition for your if block does not evaluate true, it will pass over it and go to the next section of the program. If there is no additional section of the program, it will return to the terminal unlocking steering in the process. You also don't need to continually set sasmode to "stabilityassist", it defaults to stability assist mode whenever you turn on SAS (KSP limitation, not kOS). Is there a particular reason you aren't using the cooked steering and locking to the direction you desire, instead of letting it drift?

The easiest way is to provide your own exit variable, and disable the `preserve.` call if that variable is true. In addition, you could simplify the trigger execution by enabling different triggers based on the state: list engines in engList. set limit to 220. set running to true. function watchToLock { when GROUNDSPEED < limit - 5 then { for eng in engList { if (eng:GETMODULE("KM_Gimbal_3"):GETFIELD("gimbal") = false) { eng:GETMODULE("KM_Gimbal_3"):SETFIELD("gimbal", true). } } if running watchToUnlock(). } } function watchToUnlock { when GROUNDSPEED > limit + 5 then { for eng in engList { if (eng:GETMODULE("KM_Gimbal_3"):GETFIELD("gimbal") = true) { eng:GETMODULE("KM_Gimbal_3"):SETFIELD("gimbal", false). } } if running watchToLock(). } } watchToLock(). wait until abort. set running to false. wait 0.001. This way your trigger condition is only evaluating fairly simple math on a single bound variable, rather than trying to walk the module tree every single update. When you break execution (return from the program to the interpreter) the trigger will automatically be removed. If you need it removed before returning to the interpreter, you can add `or running` to the trigger condition, and just wrap the entire body in an `if` condition `if running { for eng in...`

Known might be a little strong, but I have indeed run into issues with warp modes both with and without kOS installed. There must be some internal logic that KSP uses to toggle between the two that doesn't always trigger correctly. In my scripts I simply force whatever mode I want to use `set warpmode to "rails".`. I've also been able to fix the display in the past by manually increasing warp to "1" and then back down to "0" using the keyboard.

There is a lot of very complicated math that goes into doing something like that. One of the nice things about KSP mods being open source is that you can always go look and see how someone else does something. So, you can try checking out the Transfer Window source to see how Trigger does the math. Otherwise, you can search for other guides on Lambert solvers. It took me over a month to write my solver, and I am planning on re-writing to use another calculation method that should be faster and more robust. I'm weary of siting specific links without gauging your interest in that level of math, since most of my research involved reading legit calculus, astrophysics class powerpoints from the internet, and master theses.

@noisybit I was trying to look at your source from github and noticed that it looks like GameframerService.cs and Mission.cs are missing. I was wondering if you could post your updated source?

You don't necessarily need to use your own arctan tricks. You can calculate the angle from "up" using vang, and then since the horizon is always 90° from vertical, you can find the horizontal pitch. This way, the trig functions are handled internal to kOS, where they are a little faster. set angleVertical to vang(ship:up:vector, ship:facing:vector). set angleHorizontal to 90 - angleVertical. // or, if you prefer velocity: set angleVertical to vang(ship:up:vector, ship:velocity:surface). set angleHorizontal to 90 - angleVertical.

As one of the kOS developers, one of the things that immediately came to mind when I saw this mod/site was that a kOS script could be used to trigger a record event (including the event's title), or to confirm recording a mission. Have you given any consideration to exposing a simple callback api that we could call using reflection? Something along the lines of `TriggerNewEvent(string title)` `SetMissionTitle(string title)` and `SetMissionDescription(string description)`. I suspect I can find the equivalent of these methods in your code, but thought I'd ask you directly. Personally, I really like this mod so far. I haven't done more than one mission yet, so I don't have much feedback yet. I'm looking forward to seeing how the docking events are handled, as a lot of my kOS scripts are focused on various docking operations (building stations, refueling stations and ships, etc.). Thanks for sharing a great mod!

New Release! v0.19.1 Github: Download Spacedock: Download Curseforge: Download ABOUT This release is a patch to v0.19.0, fixing some things found by the user community in the two days shortly after v0.19.0 released. It also happens to contain a few terminal window features that were being worked on before v0.19.0 but were not deemed ready yet when 0.19.0 was released. NEW FEATURES PIDLoop tutorial section in the docs edited to mention new PIDLoop() function that did not exist back when that page was first written. (http://ksp-kos.github.io/KOS_DOC/tutorials/pidloops.html) New Terminal GUI doodads and widgets: A brightness slider, and the ability to zoom the character width and height. Also made the transparency and dimming of the 'non-active' terminals a bit less severe so you can still read them when un-focused. Also, these new features can be script controlled by new suffixes, however it is unclear if that feature (doing it from a script) will remain in the future so use it with care: (http://ksp-kos.github.io/KOS_DOC/structures/misc/terminal.html) BUG FIXES Fixed file rename bug on local hard disks: (#1498) Fixed boot files can be larger than the local disk (#1094) Fixed a bug where Infernal Robotics would break when switching vessels or reverting. (#1501) Fixes problems with using PartModule's SetField(), and infernal Robotics which had been failing for all cases where the field was a "float". (#1503). There may have been other places this bug affected, but this is where it was noticed. Hypothetically, anywhere the stock game's library insists on only accepting a single-precision float and not a double would have had the problem. Improve steering when small control magnitudes are required. (#1512)

Engines also have `engine:ignition` and `engine:flameout` suffixes. You could use those to find out if the engine is currently active. Personally, I just ignore any engine that has an ISP of 0.

I know that it's a bit of work, but the current implementation of kOS does provide enough information to calculate the anomaly parameters and to predict future true anomaly values based on time (without using `positionat`). I have a script that does so (which is not in a decent enough condition to share at this point, sorry). We have made a conscious decision so far to not expose some kind of "true anomaly at" function. We never really finished that discussion on github (it was discussed internally with the dev team) but you can see that discussion here (including references on how to make it work): https://github.com/KSP-KOS/KOS/issues/153

Well the issue is you're essentially iterating over every single part in the vessel. You're also creating the parts list in a verbose manor. Here is my script for disarming parachutes: function DisarmParachutes { local modList is ship:modulesnamed("ModuleParachute"). for mod in modList { if mod:hasevent("Disarm") { mod:doevent("Disarm"). } } } You can modify that to use parameters if you would like: function DoEvent { parameter module, event. local modList is ship:modulesnamed(module). for mod in modList { if mod:hasevent(event) { mod:doevent(event). } } }