hvacengi

As near as I can tell the only difference in kOS setting the warp rate directly is that we always tell it to not be "instant" while stock has the ability to change the warp setting instantly. As far as `warpto` is concerned, we call the same method as the map UI button, with the only difference being that the map UI explicitly specifies two parameters while kOS relies on the default values for those same parameters. My first reaction was that those parameters must be the cause, except the map UI values are the exact same as the default values. So in both cases, it literally should be no different than if you had clicked the UI buttons. Which makes sense, as the UI buttons are how I figured out how to implement `warpto`. When I check references to the methods kOS calls, the stock UI calls the same methods. On a secondary note, I'm expecting to introduce a new structure accessible from `kuniverse` that would allow us to expose more information about warp data. That way you could find the actual multiplier and/or timestep, as well as have access to the ability to cancel `warpto` (when that feature was first introduced there was no way to cancel the warp from a mod, that has since been added).

do you mean that this occurs with SET WARP TO 3. or with WARPTO(TIME:SECONDS + 10).?

Remember, kOS is not running in real time. So the 200 to 2000 instructions you execute are all done in one tick. Which means that without a wait, you would execute the same loop again. Assuming 150 instructions per loop, at 200 IPU you would get 25% of the way through the loop before handing off to the next tick, making it so any values you read from KSP after that point would be from the next tick, while the initial readings came from the initial tick. Any wait command will initiate a wait for at least one tick. By passing a parameter of zero, it will end exactly on the next tick. If you're referring to writing a PID in kOS 2-3 years ago, the sensitivity to instructions probably stemmed from the IPU limit causing your PID to actually span multiple ticks. Especially if you were trying to do more than just the one loop. We've also added a PIDLoop structure, which drastically cuts down the number of kOS instructions required for updating PID. My docking script went from 1900+ instructions per update to 270 when I added the PIDLoop structure. Because the IPU limit controls how much code is executed during a single tick, it can also affect KSP's performance. Try to limit the number of expensive calls you make in loops like that. Compiling a script to ksm 50 times per tick will slow the game to a crawl, since the game can't continue until kOS is finished.

For starters, I assume you want to lock throttle to T. instead of locking T to the value of throttle. Second, you need to add a wait to the end of your loop, otherwise it will repeatedly execute until you exceed the IPU instruction limit. As for a dt, just store your last time you updated, and compare it. "Lightning fast" is relative in kOS, since the VM has a lot of overhead. Increasing the IPU from the default 200 to 2000 will probably have a more profound impact on performance than attempting to optimize your code. As with most programming, focus first on getting something working (using good practices) and then see if you need to optimize to squeeze additional performance. set t0 to time:seconds. wait 0. until false { set t1 to time:seconds. set dt to t1 - t0. // do something set t0 to t1. wait 0. }

We aren't planning on releasing a 1.2 compatible version until 1.2 goes public. As KSP is not in a stable release, an automated update to the pre-release could break any kOS binary that is uploaded. And this helps to limit the potential for bugs being reported to Squad that are actually bugs in kOS. Thanks for the info. I haven't tried to look at science info much yet (I almost always play sandbox, so I don't have a testing configuration readily available for it). I'll try to look into it more later tonight, and I'll get a bug report in if I can't find another suitable value.

Interestingly, it looks like the stock version supports a smooth transition, but doesn't do it. They do lerp the position vector, it just seems to be very quick. That's fine though, I mostly wanted to know if I should continue to plan on making an addon to support your mod, or if supporting stock would be the same thing. I'm perfectly happy to support both though. I'll dig into your source revisions some time this weekend.

We won't make a release until KSP actually releases 1.2, but if you are comfortable building kOS I have a branch published that has been updated based on the pre-release/experimentals: https://github.com/hvacengi/KOS/tree/experimentals VERY STRONG WARNING: Your mileage may vary. MM isn't updated, and all sorts of wonky stuff may happen. If you find a kOS bug with the new version though, I'd love to know about it so that we can catch it by the time KSP 1.2 officially releases. MAKE SURE TO ELIMINATE KOS BEFORE ATTEMPTING TO POST BUG REPORTS TO SQUAD.

Does camera focus changer now encapsulate the KSP 1.2 stock aiming, or do you still perform your own math to shift the focal point?

Yes, it has been merged for the most recent release. So feel free to go crazy and come up with some new addons. You can find an example interaction from various addons by @Ger_space or my own Camera mod: https://github.com/hvacengi/KOS-StockCamera (for the time being, my camera mod is essentially the "reference" for an addon, though I have an example prepared that is purely instructional I just haven't had time to post it)

If it is not reproducible outside of physics warp, this sounds like a potential issue in the underlying KSP code. Physics warp is notorious for having unexpected issues. When you say it takes 15 minutes to show up, does that mean you start the 15 minutes at 1e-14, or do you start higher than that? Without physics warp, do you run into issues between 30 and 45 minutes in?

Could you please explain what you mean by "the gimbals don't work"? Do you mean that the gimbal behaves as if it is always locked, with no deflection of the exhaust trails? Or do you mean that kOS doesn't seem to take gimbal into account properly? All that kOS does is ask each engine for it's potential torque (which internally the engine checks the gimbal) and then it sets the control state, as if you had manually affected the controls. RSS/RO dramatically change some of the physics characteristics of the game, so it's possible that they have changed something so that kOS doesn't get the proper information. But as long as they implement `ITorqueProvider` properly and don't change the flight control interaction we should have no problem interacting with those controls. The torque provider method was new with KSP 1.1, so it is possible that it is the root of issues. It is also possible that kOS is actually interacting with the gimbal just fine, it simply does not appear so because the response is small. I would need more information to know what is going on, preferably a video showing your observed behavior. All code in kOS, including steering locks, is limited by the `config:ipu` setting. If your steering logic takes more than 2000 instructions it will run into the next tick before actually setting the value. If you have multiple triggers that add up to more than 2000 instructions, it will run into the next tick. The VM is configured to always run at least one main line instruction before returning to the beginning of the trigger code. So it is very possible to observe windows where the value is not updated. That being said, the internal steering code is not disabled for those "gap" ticks. The steering manager logic will continue to steer towards the last value set until it is changed. So as long as you aren't for some reason making very large changes in steering between ticks the delay will be legligable. My best recommendation is to use a single function for the lock, and cache all of the values read from KSP at the beginning of the function. That way you can try to ensure that all of your math is based on information from the same tick, even if that tick is no longer the current tick. If it is off by one or two ticks, the error should remain small. I also suggest simplifying the code as much as possible. Calling a function takes multiple instructions (it has to push the parameters, and then call the function, and then actually execute the logic of the function) so encapsulating the steering logic itself into a single function will simplify code. Using locks in place of functions can help, but it introduces a complication because you may be evaluating two separate locks that rely on the same data. And calling cascading suffixes increases the instruction count (every call to a suffix has to push the suffix name, and then get the value). My general rule of thumb is that any value that you need to access more than once will probably save time stored in a local variable.

See item 3 here for applicable dlls and location: https://github.com/KSP-KOS/KOS/blob/develop/CONTRIBUTING.md#setting-up-the-solution-dependencies You do not need to download KSPAPIExtensions.dll, that was previously used for utilities that are now included in stock and apparently we forgot to remove that line in the text. I will probably be trying to move this addon into an external addon package soon. I got a notification a week or so ago that trajectories merged CalebJ2's PR there with the foundation necessary for the addon to work properly (rather than needing to compile your own version of trajectories) which means that there shouldn't be an issue with us releasing the compiled addon to the public.

Are you saying that previously the status wouldn't change immediately? In the past, and in my current testing, the status changes the moment that the ship leaves the ground. Could you share your code and a log file for us to review the behavior you're seeing? (via dropbox, google drive, paste bin, or your preferred sharing service if possible to prevent a post on the forum itself from getting too long)

Status appears to be working fine on my local copy. What version of KSP are you using? There was a similar bug when using v19.x with KSP 1.1.x, as well as other combinations.

kOS's Science experiment structure simply returns the value that the underlying science reports as `module.Inoperable` so I would expect it to work. You may be able to infer more information based on events or fields, as only those that are visible in the gui will be listed by the part module. So if there's a button/event for "take reading" when landed and not while flying, checking for that event may work for your purposes. Given the two sections of code that you've posted, it should work. If you can post your error log we can see what the surrounding opcodes themselves look like, and might be able to tell if there is an issue with the sub-program. It's an odd error to get, especially on two short scripts. Do you have any issues with other user defined functions?

That depends on how far down the rabbit hole they want to go. kOS can interact with the throttle directly, or it can adjust the pilot control throttle, both of which are fairly easy to do: http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#the-special-lock-variables-for-cooked-steering http://ksp-kos.github.io/KOS_DOC/commands/flight/pilot.html#ship-control-pilotmainthrottle Alternatively you interact directly with the engine: http://ksp-kos.github.io/KOS_DOC/structures/vessels/engine.html Then it's a matter of figuring out exactly how you want to control the throttle. Reading through the recommended design patterns should help them get a feel for the logic. After that, it's all a matter of recognizing the desired conditions, and telling kOS what to adjust. http://ksp-kos.github.io/KOS_DOC/tutorials/designpatterns.html In my opinion, if all you want to do is cut the throttle at a given Ap or Pe, it would be relatively easy. But It would also be a bit of overkill, since you would really be only touching the surface of what kOS can do. I would expect that any one who starts with something that small would quite quickly move to automate more of their flight. I should warn though that kerboscript is not your typical programming language, and it has some quirks. But the forum and reddit page are usually quite helpful.

For starters, it doesn't look like you are using the most recent version of kOS (we are on version 1.0.0 right now). I'd recommend updating to the newest version and trying again. If it still doesn't work, try running kOS in a clean instal of KSP. You have a lot of mods installed (a number of which are throwing errors when trying to initially load) so the important thing is to make sure that one of those mods isn't conflicting. You may also want to make sure that all of the other mods are up to date as well.

I personally use the following syntax: function ActivateAntennae { if addons:rt:available { local modList is ship:modulesnamed("ModuleRTAntenna"). for mod in modList { local excludeTags is list("", "empty", "none"). if mod:hasevent("Activate") { mod:doevent("Activate"). } if mod:hasfield("target") and not excludeTags:contains(mod:part:tag) { mod:setfield("target", mod:part:tag). } } } else { local modList is ship:modulesnamed("ModuleDataTransmitter"). for mod in modList { local part is mod:part. if part:hasmodule("ModuleAnimateGeneric") { local mod2 is part:getmodule("ModuleAnimateGeneric"). if mod2:hasevent("extend") { mod2:doevent("extend"). } } } } } This allows me to use the same function regardless of whether or not remote tech is installed. It also has a really nice benefit: you can specify a target in the VAB with the name tag. If the tag is in the "excludeTags" list it doesn't try to set the target (and you can adjust that to your preference) so an empty tag doesn't try to set the target value.

http://ksp-kos.github.io/KOS_DOC/tutorials/quickstart.html#step-6-now-to-make-it-turn This tutorial shows you how to steer, including the use of heading which automatically set the "roll" "top" to be straight up away from the planet. If you want more control to be able to adjust your roll program more carefully, you can use any of the other constructors to modify this value (I recommend using `lookdirup` and some kind of average between the current "roll" "top" and the target "top"): http://ksp-kos.github.io/KOS_DOC/math/direction.html#creation We respect your opinions of the quality of our documentation, but please be more constructive than simply saying it's bad identifying the 1st line of the 2nd paragraph as confusing. Honestly, directions are a complex topic which makes them difficult to explain and document. If you're looking for example code, I recommend looking at the subreddit which I find easier to search, and full of other users who are perfectly happy to answer your questions. There are multiple examples posted there (either as tutorials, or users showing their own code) that could serve as models for you in this instance. While we know that it isn't perfect, we are quite proud of how detailed our documentation is. You should also look at the rest of the document, a failure to include something you are specifically looking for does not mean that the document as a whole is bad. As a project where the developers dedicate their "free" time to working on the mod, we cannot possibly afford the time it would take for everything to be exactly perfect. Instead of implying that we failed because we don't already answer your question, simply asking it would have been received better.

No, setting timewarp directly throws an error. The WarpTo function still works fine, it's just `set warp to 2.` that fails. I would ask that a recompile is not posted unless the version is modified to be lower than our existing version. There are... complications that come with an unofficial release. As GPL, people are certainly welcome to post their own copies, there isn't any restriction on it. It just muddies the waters when we start getting support requests on something that we didn't release. A simple reset of the version number would suffice though, as KSP prints the assembly version inside of the log file. We would like to have some means of automatically publishing "nightly" builds, but as of yet I haven't found a good "free" option that doesn't clutter our git repository's tags and releases. We just found another issue with the current build, but I promise that we're close to release of the next version and are working hard to get it into all of your hands. I highly recommend using this atom package: https://atom.io/packages/language-kerboscript it's not perfect, but it's pretty darn good.

If you look a couple of pages back you'll find this post: A final release is coming, but the release candidate found more bugs than we were hopping for and required additional work to repair.

Since you asked on reddit as well, I'm just going to link to that thread for anyone who sees this question and wonders if you ever found an answer: https://www.reddit.com/r/Kos/comments/4tcvay/vectordot_not_working_like_i_want_it_to/

Instead of using config files, I've elected for dependency based on the assembly name starting with "kOS." (only so that it scans kOS.dll and kOS.Safe.dll properly) and KSP's built in KSPAssemblyDependency attribute (which is used by KSP to determine the order in which mods are loaded). That leaves the decision to support kOS exclusively in the hands of the developer. I'm not sure that there's a need to use MM magic to configure support, since support needs to be hard coded into the dll anyways.

I didn't try to actually launch a vessel with that part module on it, I just loaded the game with the mod installed. It could be that it's broken even though it loaded. Or it could be that only the one attribute is broken, and kOS is the only thing that tries to access the attribute. I'll try to look into it more tonight. I'm not sure that the exact cause really matters all that much, the current system is obviously preventing users from using kOS with some other mods and that is more counter productive than ensuring that addon writers see errors in their loads. I've created an issue on github to discuss how to proceed, I welcome further discussion there: https://github.com/KSP-KOS/KOS/issues/1718 (tagging @Waz and @undercoveryankee since they were involved in the related discussion as well)

Here is the documentation for how boot files work in the current release: http://ksp-kos.github.io/KOS_DOC/commands/files.html#special-handling-of-files-starting-with-boot-example-boot-ks And here is the pending documentation for how they will work when kOS v1.0.0 is release (or how they do work if you're using the release candidate): http://hvacengi.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory