hvacengi

Delegates are perfectly legal parameters, and you may set the value to an anonymous function just like your example. I prefer to use a named function however, just to keep everything clean. If the function is a separate block, your parameter declaration is shorter and you can more easily format/comment the code: // functions replacing DefaultManeuverDisplay in calls to ManeuverBurn should // include a single parameter, and should display that parameter to the user // as a sting by some means and/or formatting. function DefaultManeuverDisplay { parameter str. // print message like: "T+30 - Hello World" print "T+" + round(missiontime) + " - " + str. } // setup the parameter to use a defined function, just to keep the code clean function ManeuverBurn { parameter nd, ErrorMargin is 0.1, DisplayBlock is DefaultManeuverDisplay@. DisplayBlock:call("Node Burn Executing..."). // I prefer to explicitly call // execute the node... DisplayBlock:call("Node Burn Complete!"). } function HudTextDisplay { parameter str. // display message via hudtext like: "Hello World" hudtext(str, 30, 3, 18, white, false). } ManeuverBurn(nextnode, 0.1, HudTextDisplay@).

Well I suspect I've found it. In KSP 1.1.3 the OnGizmoUpdated method didn't reference the "gizmo" UI element, but in KSP 1.2.x it does. This is an issue because that UI element only exists when you click on the node to display the edit handles. This is a bit of a pain, because it means that kOS is going to need to replicate the stock logic instead of calling the stock method, so that we can add a check to see if the underlying node has a gizmo attached. The issue should exist for all of the settable suffixes. Because "removing" the node removes the reference to the underlying KSP node, we bypass that section of code. If you have a github account and could post the issue there, that would be great. Otherwise I should be able to post it later tonight, along with a fix.

I think that users of previous versions have reported that modifying the node's suffixes worked. I'll see if I can reproduce the bug tomorrow evening. Can you share a log file containing the error, it should help us track down the issue. If I were to guess, it means we aren't telling KSP's patched conics solver to correctly update the flight plan, but I'm not sure. If I can see your log before I start working on it, it might point me closer to the right direction. A potential work around might be to remove the node, wait one physics tick, and then edit the node, wait another tick, and re-add the node. It might also be that you need to add a wait in between the steps you're already doing. I've found that KSP is picky about how you edit a node. For instance if you add a node in the same tick as switching the map view things go funny. If it turns out to be something like this, we may just want to force any node addition to wait for the next physics tick.

Since the error happens when setting up the toolbar, yes the regular button is likely to break too. The fix would be to remove blizzy's toolbar for the time being, because the issue only occurs when it detects that the toolbar is actually installed. Either that or change line 30 of "src/kOS/Suffixed/Config.cs" to read the following, and recompile it locally: public bool UseBlizzyToolbarOnly { get { return kOSCustomParameters.Instance.useBlizzyToolbarOnly; } set { kOSCustomParameters.Instance.useBlizzyToolbarOnly = value; } } We'll get the fix into the next version of kOS, but I don't intend to do another pre-release unless there's a major revision required to a core feature. Issue opened: https://github.com/KSP-KOS/KOS/issues/1863

That's odd. For some reason something is still looking for the blizzy setting in the config file instead of the new difficulty settings. I'll track it down. Already taken care of We actually had to fix that issue in multiple locations (two of our addons used similar code).

Congrats! I'd say that's a pretty good excuse! Thanks for sharing all that info. I'll try to digest it here over the weekend.

v1.0.2-pre-2 Pre-release Pre-release version of the build with KSP 1.2.1 compatibility. Download: Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.0.2-pre-2 WARNING - May contain multiple bugs. Please report any issues you find! Sub-warning: this update attempts to include unified support for CommNet and RemoteTech, but we need your help in thuroughly testing these features. Please try to test (break) these features so we can ensure that we squash as many bugs as possible before full release. Update to the previous pre-release including: Fix Sphinx doc builds on Python 3 and new versions of Sphinx Settings are now stored in the KSP difficulty settings window documentation Fix issue when mods are installed that use dynamic modules (like ContractConfigurator) Added Trajectories API documentation Fix issue reading from 4 byte files stored on the local hard drive which would erase the entire hard drive KSM files are now stored using GZIP compression to reduce file size (while this change should be backwards compatibile, the kOS team always recommends recompiling ksm files whenever updating versions) Support for CommNet and RemoteTech documentation

My guess is that the ModuleEnginesRF doesn't do ISP the same way, probably because they use a different solver. Could you post an issue to github so we remember to work on it? I don't know when we'll get to it, but we'll try to do so. There isn't really much of a style guide. I try to maintain my C# style for kerboscript as much as possible, just because it's how I'm used to naming variables. But we have users from all kinds of language backgrounds, and I've seen any number of styles used. If you look at my earliest scripts I didn't even bother with camelcase, but as I've written more complicated scripts I've found camelcase really helps with the variable readability. The docs mostly use the capitalized, and I've tried to stay consistent there. But I honestly hate the idea of writing scripts in all caps, it is incredibly painful to read. I'd rather everything was lower case (which is in fact how my early scripts were written) if for no better reason than I don't have to use the caps-lock key (I use that too much already working on building blueprints).

We use Travis to build automatically. The trick is posting the builds somewhere that they can accessed by others. I've been reluctant to suggest getting travis to push as a git release, just because it will bloat the "release" count and the number of tags. I've never used Jenkins, so I'm not sure what all would be involved. Some day, when I clone myself...

If you have access to Visual Studio or Mono Develop and know how to use git it shouldn't be that tough. We tried to document the process of setting up the environment pretty decently. But that doesn't mean it's full proof. I mean, I build kOS about 20 times per day, so it's easy for me to gloss over the details. Check out these links to help out: https://github.com/KSP-KOS/KOS/blob/develop/CONTRIBUTING.md#setting-up-your-environment http://www.monodevelop.com/download/ https://www.visualstudio.com/vs/community/ IF I can get some stuff finished up tonight/tomorrow, I really want to get another pre-release out this weekend. If for no other reason than to let more users than just the devs test out the CommNet before we make a full release. The good news is that we should have some pretty nice new features to go along with the update, so it will be far better than a simple compatibility update. Some day I'd really like to get some automated dev builds posted as we merge new pull requests.

I should also mention that if you need us to expose any specific API methods from kOS to make this easier, we can probably get that done without too much issue. Specifically I'm sure we can provide a cleaner way to figure out if a command is being executed. We might even be able to get MechJeb to be treated like it's own interpreter instead of needing to use reflection. I'll keep pondering how to do that cleanly.

First a question about the concept: Would you consider a parallel effort to expose MechJeb features to kOS scripts? I haven't had a chance to check out your implementation yet, but it seems like we could leverage off of each other pretty decently. You're looking to add script-ability to MechJeb, kOS is a ready made scripting option. While the premise of the kOS mod itself is "do it yourself autopilot", there wouldn't be anything wrong with MechJeb being able to add some hooks to kOS when both are installed. I'm kind of assuming that your system is essentially a window where you queue different actions, and MechJeb just executes them sequentially, waiting for each to complete before moving to the next. Are you offering a way to save up these lists of actions? I wouldn't remove the system you have in place, I think you'll see better adoption if users aren't expected to download another mod, but kOS itself might serve as a nice "advanced" option. A user just starting with scripting probably wants to script things like [Ascent autopilot => circularize => transfer to mun => land on mun]. But a more advanced script might be [Ascent autopilot => circularize => calculate transfer to jool => if encounter with mun or minmus adjust the transfer time => if jool encounter isn't close enough fine tune orbit => if there isn't enough fuel to capture at jool, aerocapture or gravity assist capture]. Second, conversation on the implementation: Absolutely cache everything. There is more cost in walking the methods and creating the delegate than there is for executing the delegate. And just as importantly, repeated call chains to functions like GetType and GetField would be garbage heavy since the object is instantiated and orphaned immediately. I'm not a huge fan of how the kOS-RemoteTech api is structured, but one of the things I really like is how it sets up the API access. There is a class RemoteTechAPI whose properties are Action<> and Func<> types to match up with the RT internal methods. Then it just walks the RT API class using reflection to set the property value to delegates created from the internal API methods. Because the internal RT API uses static methods only one instance of kOS's API class needs to be constructed, which would be a difference in your case. I could see a class definition like the following working well: public class WrappedSharedObjects { private Func<object> GetInterpreter { get; set; } private WrappedInterpreter interpreter; public WrappedInterpreter Interpreter { get { if (interpreter == null) // if the instance is null, instantiate a new one { interpreter = new WrappedInterpreter(GetInterpreter()); } return interpreter; } } public WrappedSharedObjects(object rawObject) { var type = rawObject.GetType(); var interpreterProperty = type.GetProperty("Interpreter"); var getInterpreterMethod = interpreterProperty.GetGetMethod(); GetInterpreter = (Func<object>)Delegate.CreateDelegate(typeof(Func<object>), rawObject, getInterpreterMethod); } } That way you can internally keep track of strongly typed objects (like WrappedSharedObjects). (Warning, I didn't test the above, and didn't take the time to include error catching). Alternatively, instead of storing the delegate itself you could store rawObject locally and getInterpreterMethod statically, calling getInterpreterMethod.Invoke(rawObject) to return the interpreter's object. I want to say that Invoke is slightly slower than a delegate, but I don't recall the source of that info so your mileage may vary. You'll need to use the field's GetValue method anyways, since FieldInfo can't be used to create a delegate, so calling Invoke and GetValue would maintain code consistency. I've actually wanted to set up a templating system that would allow you to create such wrapper classes automatically instead of by hand, but obviously haven't done it yet.

I have recompiled using 1.2.1 locally and everything seems to be working correctly. We'll probably try to get another pre-release out soon, but it won't be until after we've had a chance to address a couple of issues that are currently outstanding (like CommNet). If we weren't so close to having those ready, I'd just post another build. Until then, compiling for yourself from the source should work. We'll try to post binaries as soon as is feasible.

I happened to get pointed to your scripting module for MechJeb, and then found this post off your profile. I though I'd mention the method that kOS has taken to recommending for developing kOS "Addons". The trick I ran into was finding a way to make it so that basic addons didn't need to use reflection or do their own assembly walk (which is how all of our own addons work). Reflection is a pain to work with, and it's easy to break. So I opted for recommending defining the KSPAssemblyDependency attribute on the assembly itself, that way if KSP doesn't find the dependency, AssemblyLoader won't load your assembly. Then kOS uses reflection to create an instance of objects that inherit from a class, or interface, or just have an attribute defined on them. What I really like about this method is that by carefully defining interfaces in your main assembly, you can easily create a utility to interface with another hard-linked dll without throwing errors. The big downside to it however is that you need the functionality to be in a stand alone assembly. So if you wanted to create an addon that interfaced between kOS and MechJeb (oh right, you do ) you would make a shim assembly that hard links to both, and has the KSP dependency for both, allowing all of your classes within that assembly interact with both kOS and MechJeb directly. Your class can then inherit from both the Addon type (or other supported type/interface) and a Mechjeb interface, allowing both to access data from your class directly. It also doesn't help with accessing private/sealed/protected methods/properties/fields. I'm sure we'd be happy to help you with your interaction with kOS. Particularly so that we don't break compatibility with your systems with an update. I'll try to walk through your code tonight to get a feel for what you're trying to do, and see how we can help you interact. https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/AddOns/AddonManager.cs https://github.com/KSP-KOS/KOS/blob/develop/src/kOS.Safe/Utilities/AssemblyWalkAttribute.cs https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/AddOns/Addon Readme.md I should add a note to the readme that exactly one instance of the Addon will be created per processor, and will exist until the processor is unloaded.

Ok, I take it back again. I was able to recreate the issue, sort of. Some configurations of control surfaces seem to result in negative torque values. So I'm going to edit the steering manager to be tolerant of negative torque values. It should be fixed in the next (pre)release.

It looks like we're going to need some more information, like a craft file to test. I just created a similar plane and launched it using your script without any issue. Which makes me think that whatever issue you're running into might be affected by vessel configuration. If you could share I'd appreciate it.

Actually, that is incorrect. In the original script steering is locked to "heading(H, P)." which will automatically update once per physics tick, refreshing the current value of both H and P. While your solution will work as well, the original code is not at fault. That being said, if he was calling that steering lock in a loop I'd be right on your band wagon, because all to often I see people try to repeatedly lock the steering which is redundant. In addition, your method is technically more memory and instruction efficient, because you aren't constructing a new "direction" every single physics tick, just the ones where pitch changes. Do you have a video showing what you describe? I've added a reference to your forum post for an existing issue also asking about the use of control surfaces in 1.2 (https://github.com/KSP-KOS/KOS/issues/1852). The behavior that you're describing could be a product of multiple things, and it may be a need to tune the steering manager, or it may be an internal issue with how kOS calculates torque. I've asked the other reporter to do some troubleshooting to see what we can find.

v1.0.2-pre WARNING - May contain multiple bugs. Please report any issues you find! Download Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.0.2-pre Notes There is no CommNet integration, range and connections will not be enforced. Some suffixes may not actually be right. We have a few To Do notes in the code (see #1835 for a list). RemoteTech support has not been tested. If you select "Require Signal For Control" in dificulty settings (see below) kOS will not be able to fully control the ship when out of signal. Controls should still be manipulated properly if you support partial probe control instead.

You aren't the only one concerned about it. I actually posted a reply regarding the same topic: https://www.reddit.com/r/Kos/comments/570f3g/kos_v101_lets_take_some_input/d8odzcv

It isn't as though we want to cause you to fall further behind, but if it takes us until Thanksgiving to make a release I think I'll pull my hair out. I think we're actually very close to basic 1.2 compatibility, so hopefully a pre-release can be out soon. But I've made good headway with commnet and system setting integration as well. With any luck and no surprises with my own job, we should have another strong update out very soon.

kOS v1.0.1 Let's take some input! DOWNLOADS Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.0.1 Spacedock: http://spacedock.info/mod/60/kOS: Scriptable Autopilot System Curse: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2335982 Why 1.1.3 and not 1.2? We wanted to get the last bug fixes and new features into the hands of any users who might not update KSP to 1.2 right away. Traditionally there are some mods that take a while to update when KSP releases a new version, and many users choose to wait for all of their favorite mods to update before upgrading KSP. By releasing in conjunction with the update, we can ensure that as many users as possible have access to these latest updates. We will be releasing a version of kOS that is compatible with KSP 1.2 as soon as possible after the final build is 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. The stage command/function now implements the yield behavior, waiting until the next frame to return. This ensures that all vessel stats are updated together. (#1807) NEW FEATURES Functions and opcodes can now tell the CPU to yield (wait) based on their own arbitrary logic. This allows future functions to be "blocking" (preventing further execution) without blocking KSP itself. (#1805, #1807, and #1820) New timewarp structure, available on the kuniverse bound variable. This structure provides additional information and control over time warp. The old warp bound variables remain in place. (#1790 and #1820) Introducing a new terminalinput structure for keyboard interaction from within scripts! Currently support is only provided for getting single characters. (#1830) Please check http://ksp-kos.github.io/KOS_DOC/changes.html for more detailed explanations for the new features. BUG FIXES Fix for formatting of time:clock to pad zeros (#1771 and #1772) Fix for not being able to construct a vessel("foo") if "foo" is the name of the current vessel (#1565and #1802) RemoteTech steering should be fixed. At worst you may see a 1sec gap with the controls, as we now refresh the steering callback about once per second. (#1806 and #1809) Named functions defined within anonymous functions will no longer throw an error (#1801 and#1811) lock steering no longer throws an exception inside of an anonymous functions (#1784 and #1811) Compiled programs that include a large number of named functions should no longer throw an error (#1796 and #1812) Fixed the first call to wait after the cpu boots (#1785) Various documentation fixes (#1810, #1823, and #1834)

I don't know what that means, so I can neither confirm nor deny. What does the acronym stand for?

While I like @Chabadarl's solution above better, you could alternatively use the partservos suffix and kOS name tags to look things up. If you can safely assume that there is one and only one part with the given tag, and that the part has one and only one servo, you could use the following code: set servo to addons:ir:partservos(ship:partstagged("name")[0])[0]. servo:moveleft(). But there are two problems with this method: the syntax is complicated (making it harder to read and easier to break) and it requires the construction of multiple lists that are immediately discarded. Both issues are fixed with the previous suggestion. Syntax to access the lexicon is very clean, as is the syntax to construct the lexicon. The only complication is that the lexicon uses a one to one relationship, and neither IR group names nor kOS name tags are guaranteed to be unique part identifiers. At that point, you can choose whichever method you find easier to label/identify. If you go with group names though, I'd recommend storing a reference to the group itself instead of the part, that way you can seamlessly transition to supporting multiple servos: //The initialisation has to be done just once at the start of your program set MyServoGroups to lexicon(). for g in addons:ir:allgroups { MyServoGroups:add(g:name,g).} //then you can use in your code MyServoGroups["TheGroupThatGoesToTheLeft"].moveleft().

It isn't a new limitation, but it was tweaked a few KSP versions ago. Probably the most noticeable difference now is that the value changes depending on "situation" (landed, flying, orbiting, etc.). There is also a buffer distance before re-packing or unloading, so that a vessel right on the limits of the distance isn't constantly switching between the different load/packed states.

There is no concept of null in kOS (for better or worse, that debate has been done many times). However you can find if a variable identifier is define using the defined keyword.