hvacengi

I don't think that's what he is saying. I think he's just saying that if you add a bunch of triggers all evaluating simultaneously, their combined power draw can add up very quickly. I assume (but would like confirmation) that the EC/s of 10 active button "pressed" triggers is equal to 10 times the EC/s of a single button "pressed" trigger. @sebseb7 please correct me if I am incorrect in that assumption. Again, I would need to look at your script to be able to comment on the performance. If your "house keeping" uses a lot of "wait" commands to pause execution, yes it will be more power efficient. A straight "wait 1." command will consume a total of 2 instructions over the entire 1 second wait period. The cpu already "underclocks", it effectively reduces the clock speed to be exactly the number of instructions that you want to execute that physics tick. And "wait" is the power save mode. If you instead poll ag1 from inside your wait loop, you'll save a large number of instructions. If the loop waits only 1s, you should see about 1/50th the EC/s for the polling and there would not be a substantial delay. We have talked about allowing kOS to call user delegates based on certain game conditions similar to events. But it requires a change to how instructions are currently executed. Given the existing backlog of features and bugs, I don't know where it falls on the priority list. But that's a discussion best suited for Github, where we can track and assign the issue, as well as keep the conversation around the feature in a single thread. You would have hated the prior EC usage model, which was based solely on the size of the current hard disk. It didn't matter if you used 1 instruction or 2000, the EC/s remained the same.

How do you come by that figure of how much EC is consumed by the various portions of the code? Depending on the timing of the mission and how complex your other script logic is, it is very possible that the trigger is executed often enough to be a significant contributor to the total EC usage. So my question is: when only the `on ag1` trigger is running, what is the value for "kOS Average Power" on the right click menu of the cpu part? I'm trying to figure out if you are observing higher than expected power consumption, or if you're just commenting on/observing the intended behavior that an idle waiting processor still consumes power. If the power consumption is higher than expected I will want to test the script you are running, preferably with the original craft file and/or a save file. If our power consumption is broken, we need to fix it.

I'm not sure what exactly you mean by "99%", do you mean over time it consumes the full storage capacity of the probe or that it consumes 99% of the largest "kOS Average Power" field? By default the parts that ship with the mod consume 0.000004EC per instruction. If you look at the profile of the `on` trigger, you'll see that every tick it evaluates the condition. I just checked the simple example of `on ag1 { reboot. }` with no other program running and read an average power of 0.003EC/s. If you are still executing logic at the same time, the other instructions will also add up. Even if you are not executing any code at all, there is at least one instruction executed every tick (the end of program instruction) so there is no way to reach exactly 0EC/s (though it's pretty close when not running a program). If you have a bunch of other triggers active at the same time as your AG1 trigger, each condition evaluation will consume more power. If you're seeing the EC/s always maxed out (the max should be 0.4EC/s at 2000 IPU and 50FPS) and your program should be idle, we might need to look into potential wasted instructions in the script somewhere. Do you mean that by unlocking the two controls you can prevent the error entirely? Or do you mean that the effect is that the steering and throttle both get unlocked upon docking? This is "more" possible with throttle than steering, since the two use separate methods to subscribe to "autopilot events" (for now), but may still be possible with both if the previous vessel, the one that had the locks enabled, is not the dominant vessel. That is to say if the ship you're flying technically gets destroyed because it's merged with the 2nd craft it is possible for the timing to be such that the locks are thrown away. But I'm more curious to see if it removed the error messages entirely. And if you could clarify: did just the throttle/steering lock issue happen every time, or did the error message happen every time? I haven't tested docking on the ground much, but I have extensive docking tests in orbit and haven't seen that error message, so I'm curious to see if I need to add a new test case. There's also a chance that the claw is complicating things. While it is very similar to a docking port, it isn't exactly the same. I just found out that it doesn't increase the count of "elements" on a vessel. So it's possible that it's "docking" behavior is enough different that we get unexpected behaviors.

The issue isn't the strategy for recognizing that the cache should be invalidated, but rather the implications to the internal program structure. When you run a program it is turned into a list of opcodes, which are then added to the existing list of "program" opcodes. That means ever time a program is compiled and run a second time, it adds more instructions to the list. And if we remove the old opcodes, the instruction pointers (essentially index references for the list) have to also get dynamically updated. It's just a situation that the virtual machine was not designed to handle, and changing that would be a major undertaking. On a more direct note, I'm not really sure what you're trying to do with section of code, but if that code were put into a boot script like below, it would work: run "file". on ag1 { if homeconnection:isconnected update_file_from_archive("file"). reboot. } wait until false. But if all you want to do is change the behavior depending on changes to that file, why couldn't you set up the script to watch for parameters in that same file (using json, or readln or the like). That way you don't need to write a whole new file, but can instead just dictate what to do next. In my own scripts, if I want to change "logic" (switch from a station building script to a transfer to Duna) I change the boot file for the core and reboot. But when I'm waiting to change the behavior of an existing script, I just write the script to understand what to do based on messages, or changes in orbital parameters, or file changes.

Are you by chance using Linux or Mac? The game for some reason handles key presses differently between platforms. I tested on my Windows computer because the built in editor is not often used, and it appears to work for me on the current release. I highly recommend using an external editor instead, personally I prefer Atom.io with the kerboscript language plugin installed. Support for gravity turn would need to be built using an Addon. kOS now supports 3rd party addons however, so you're welcome to write an addon to allow for controlling gravity turn. Unfortunately we already have a pretty decent backlog of features and bugs to work on, so I wouldn't expect kOS to get built in support for this mod for a while.

If you do the same thing from the interpreter it should work. However programs that have already been run once by the program context are always run as the cached version. Part of the reason is because calling the same program 100 times would literally load each instruction into memory 100 times. We do not currently have a solution available for unloading a program. The only workaround available is to re-run it with a new name (maybe copy it with a `random()` number appended to the name), or to reboot if you have a bootscript that will pick up where you left off. Does this reliably happen to you every time? I had a similar error one time (but only once) in a convoluted set of steps (dock with station in orbit, transfer to the mun, undock, try to land, crash into the surface destroying the entire lander, revert to launch) so I wasn't able to reproduce it. The method itself that throws the error is actually pretty simple, and I thought it was already null safe. I suspect that it is somehow related to docking (since both of our instances involved docking) but I'm not really sure how that's possible. I only see one error in the log you linked, did I miss the first one somewhere, or are you referring to the AGExt error? The AGExt error is in a set of error fixes that are pending for the next release (and I really need to finish making the review edits). That error has a fix pending to be merged: https://github.com/KSP-KOS/KOS/pull/1902

I can't wait to see your "crazy things" that come next! I'd love a chance to check out the code you used to go with that script. Some of the logic may come in handy when working on targeted landing scripts. And most of all, thanks for reminding me to go download the reusability expansion!

For a period I actually rebooted between each of my "phases" because there was a bug that was misaligning the stack for really long scripts. Hopefully yours isn't an issue like that

It's a little complicated to explain without pointing you directly to the opcodes (which is the direct answer to your question, every opcode is an instruction). Basically every math operation is an instruction, as is evey variable set, and function call, and the like. The underlying execution is much like any traditional program, except that built in functions themselves only count as a single instruction (pushing each parameter is an additional instruction). If you want to get an idea of how kOS is performing, you can check the built in code profiling tool: http://ksp-kos.github.io/KOS_DOC/bindings.html#profileresult That's also the best way to understand how script translates to instructions.

I think I've managed to figure out how fix the Blizzy Toolbar support, but at least it stops throwing exceptions. But I can't get the toolbar to show up for me to test... @kcs123 and @MaxRebo if I PM you a link to try can you test the build to see if it works with your local copy where the toolbar is working?

Yes, among other things you could set kOS to respond to action group input (easiest when the terminal is closed, since the action group buttons go to the terminal if it's focused). You only loose manual control when kOS is trying to use the same control. So you can't both lock steering in the script, and still control pitch/yaw/roll manually (though you can write the script to pilot input like that). And once you have your macros configured, you just need to write a script to recognize the same condition you use to decide to toggle that action group. Then you can write your script to perform the action without your manual input.

I'm just gonna throw the first quotes in a spoiler tag, cause I'm not going to address them specifically, I just want to provide a reference to the paragraph that follows. I had a more in-depth specific reply prepared addressing each point individually, but the forum ate it and I don't feel like writing the whole thing again. If there's an issue with the Blizzy toolbar, we deffinitely need to know. It is a supported feature (I don't think we ever said that it should be considered unsupported) but it is a feature that is not tested very thuroughly. I myself stopped using Blizzy's toolbar shortly after the stock toolbar was implemented. I do see the appeal, it just was one more thing to have to manage. The previous error was an oversight on my part because I don't have Blizzy installed. This doesn't seem to be completely unrelated, in that it's still an issue with how kOS interacts with Blizzy, but it's a separate issue with a separate error. Anything you can do to get me more information about the error (logs, screenshots, videos, etc.) would help narrow it down. When kcs previously reported the issue in this thread, it was implied in a later post that it was related to the GUI alpha, so I stopped thinking about the issue. This is one of the reasons I prefer to have bugs reported as github issues (at least eventually), as github allows us to have a separate thread for every issue ensuring that all of the information pertinent to that issue doesn't get lost in data for other issues. It just makes things a little easier to track. I'm revisiting this now because apparently this issue isn't related to the GUI alpha release. If I'm understanding your correctly, the kOS icon is available and works from the Blizzy Toolbar when you first load at the KSC, but disappears when you visit an editor or flight. What is happening with the stock toolbar at the same time? The only error I see is in an attempt to access the save game settings from the main menu (which would explain the error, since there is no saved game loaded at the main menu) but if that's is causing the issue I wouldn't expect the button to work at any point, KSC or otherwise. I also am surprised to find that the button is available to Blizzy on the KSC scene, since the stock button is not available for that scene. I'll have to look at that. I'll try to install Blizzy's Toolbar tonight and confirm my above observations, but if either of you can confirm any of the behavior before I do that would be great too.

v1.0.3 (for KSP 1.2.2) Make a little noise! (Part Deux) Downloads Github Spacedock Curse Also available via CKAN Summary This release is nearly identical to v1.0.2, except that it was compiled against binaries from KSP v1.2.2 (released just before we published) and the version numbers have been advanced. While it appears that kOS v1.0.2 is compatible with KSP v1.2.2, we wanted to err on the side of caution and provide an explicitly compatible release. Please review the changelog for v1.0.2 if you are upgrading from an earlier version

Go figure, they updated KSP between me creating the archive and finishing tests so I could click publish... I'm working on testing for KSP 1.2.2 and will post another update quickly if we need to recompile against the new version.

v1.0.2 Make A Little Noise! DOWNLOADS Github Spacedock Curse Also available via CKAN BREAKING CHANGES As always, if you use the compiler feature to make KSM files, you should recompile the KSM files when using a new release of kOS or results will be unpredictable. Most in game settings are now integrated with KSP's difficulty settings window. You will be prompted to migrate existing settings when you load your save game. Telnet settings are still stored in the old config file, but everything else is now stored within the save file. pull request | documentation Calls to resource suffixes on the stage bound variable are no longer rounded to 2 decimal places. Previously they were rounded to assist in detecting "zero" fuel, but they cause inequality issues when comparing to the newer stage:resources list or stage:resourceslex values. The behavior of the resource suffixes on the stage bound variable has changed with regard to asparagus staging. If you have smaller tanks that can be staged, stage:liquidfuel will return 0even if you still have an engine firing. This is a break from previous versions of kOS, but is aligned with the current UI design. Previous versions also aligned with the KSP UI, but the UI mechanic was updated with KSP 1.2.x NEW FEATURES Official release for KSP version 1.2.1! kOS now has a procedural sound system! You can use it to play customized error tones or make your own musical notes. pull request | documentation Support for CommNet and modifications to make RemoteTech and CommNet use similar systems.pull request | documentation Trajectories integration enabled via new ADDONS:TR pull request | documentation Added new setting for default terminal brightnes, and updated default value to 70% pull request | documentation Added VELOCITY and ALTITUDEVELOCITY suffixes to `geocoordinates pull request | documentation Added TONUMBER and TOSCALAR suffixes to string values for parsing numerical values pull request | documentation New steeringmanager suffix ROLLCONTROLANGLERANGE to dictate the maximum value of ANGLEERRORfor which the manager will attempt to control roll commit | documentation KSM files are now gzip compressed internally, dramatically reducing the file size. Existing KSM files should still load, but see above for the recommendation to recompile all KSM files. pull request BUG FIXES Fix for throwing errors when another mod uses dynamic assembly pull request Update Blizzy toolbar wrapper to the most recent version pull request Fix for local kOS hard disks breaking when loading with 4 byte long files pull request kOS no longer uses a write-only lock when writing to the archive, preventing an error when accessing a file opened for reading by another program pull request Fix for duplicate functions/locks breaking ksm files pull request Fix for null ref error when editing node suffixes on KSP 1.2.1 pull request Fix for issue where a body with the same name as one of our bound variables would block access to said variable (specifically Eta in Galileo's Planet Pack blocked the eta bound variable) pull request Fix for getting the science value and transmit value in sandbox mode pull request Fix error where unlock all inside a trigger will try to unlock functions too pull request

You should check out some of the scripts by @Ozin, I think that's how he does his quadracopter script, and I'm pretty sure he did another one using rocket engines themselves. https://www.youtube.com/user/Ozin370/feed I'm not sure what the steering manager would do with asymetric thrust like that, but you could try adjusting the thrust limiter based purely on the pitch and yaw error suffixes on steering manager. I don't recall if those errors are signed however.

What are you trying to do with the output from the Torque PID? I have a suffix for "actuation" on the structure, but it's only enabled for debugging mode. It simply returns a vector of the [-1...1] control output of the steering manager. I don't see why we couldn't move that to be user accessible if you need it for something. I didn't expose it initially because I can't think of a reason outside of debugging that it would be needed. @kcs123 is right, the rotational velocity PID won't update unless steering is locked. Even then, you can't get a good idea of the torque applied because it depends on available torque and moment of inertia, neither of which are exposed to the user.

I would need to see the full log in order to tell anything. From the portion you have shown, I don't see any errors with kOS. You're right, there are a large number of kOS messages, but that should be normal if you have a large number of vessels in flight (KSP is set up so that it destroys and re-creates vessel modules on every scene change, our logging is there for tracking the life cycle of the vessel module). If KSP is hanging though, it is possible that the last few log messages are not getting written to the log file. I'll see if I can find some time to install KAC and check out the feature myself.

In theory, as long as the unlock statement isn't within the triger's "{ }" braces, it should work fine. So you should be able to use a user function to call unlock instead.

As long as you don't call "unlock" of any kind from within a trigger ("on" or "when") you should be fine.

I ran the attached scripts with the debugger, and there is indeed a different error in this instance. 1st, the notable error isn't the "declare parameter" error, instead it's a "replace label" error. 2nd, it isn't a problem with steering locks but rather with an attempt to "unlock all", which is trying to set the user function "dislplay_block" to a default value (which doesn't exist, because functions don't have default value and they should be unlocked). I'll try to find some additional detail and post to github. I honestly didn't know that unlock all was still valid.

This was noticed just the other day, and there is already a fix in the works. There is no work around however until that gets merged. But it should be in the next release (which we keep saying will be "soon", but I think it really be soon). https://github.com/KSP-KOS/KOS/issues/1887

Or we could expose a way to get a "max scalar", since you can probably reliably know that you won't overflow the double precision floating point number, and if you do you'll break all the math in kOS anyways.

I only see one output_log.txt, and it has the error for "run", not the error you mentioned for steering. Not a huge deal at this point I suppose, since I'll be able to test it myself when I get home from work. As Drew points out, kOS itself does not provide the support for RasterPropMonitor, so we don't really know how gui objects are instantiated there. I honestly cannot see this working well in the raster window, simply because of scale. That doesn't mean that we can't look at keeping a certain level of abstraction available so that it might theoretically be possible. But I wouldn't expect that to exist in the first incarnation. After the GUI system is working we can look at pulling out the necessary components so that it can support any kind of UI system available.

Yes, sort of. Yes, foreach uses extra allocations that generate garbage, and yes it can have an effect on the game's FPS. However it's fine when used intermittently. The problem is when you call multiple foreach loops every single physics tick you're accumulating extra garbage. That has the effect of increasing the frequency of garbage collection, but isn't technically a memory leak (because when the garbage is collected, the memory is freed). Calling it when an object is created or destroyed should be perfectly fine, unless for some reason the objects are constantly being created and/or destroyed. (For what it's worth, we do have a true memory leak, that I'm working on fixing but I don't know if it will make the next release or not) I'll have to install the toolbar to check this behavior. Can you post a log file? Interesting, in my experience the UP variable didn't really vary all that wildly. Given that it's created the same was as vector:direction I can't say I'm surprised. But regardless, kOS already does provide you a way to prevent rotation: http://ksp-kos.github.io/KOS_DOC/math/direction.html#function:LOOKDIRUP lock steering to lookdirup(up:vector, ship:facing:topvector). I'll try to run your scripts at some point to test. The error from the log should be thrown before actually parsing the script file, so changing the content of the script shouldn't matter. But I'll need more information about the steering error. There are a couple different points in the steering code where it may throw an error, and some of them should continue to display the error message on every tick. Can you provide that log file? Did you make any changes beyond removing the two action group triggers before you started getting that error?