Dunbaratu

If it's called "Arm" then it won't be the field called "Status". "Status" is the *effect* of executing the event button called "Arm", and isn't directly set. Chances are you're looking at the wrong Module. Try this printout to see what's available in ALL the modules. They probably have the "Arm" button in a different module from ModuleGrappleNode. // assumes you've tagged the grappling part with the tag name "grapple": local P is ship:partstagged("grapple")[0]. for modName in P:allmodules { print "---- MODULE: " + modName + " ----". print P:GetModule(modName). // should print the members of this module. }

What does "in both cases, the angle error is small" mean? It sounds like we're talking about two different things entirely, since the angleerror I'm talking about would be small in one case and large in the other. (Small if pointed at the "final intention" already, or large if not yet.) One thing that *would* be a problem would be that you couldn't detect what the *script* is doing. It might instruct kOS to steer in a successive series of slightly altered steering targets. (i.e. lock steering to some expression that gives a slightly new value every update, like lock steering to heading(90, 90-0.5 * elapsed_time)). If the script does that, then kOS wouldn't even know it was doing it, so it could fool your algorithm into thinking it was doing "Stability assist" the whole time because each FixedUpdate the new direction isn't very different from the previous one. While you absolutely could detect kOS's "final intention" (steering target), you couldn't detect what the *script's* final intention is when it keeps slightly nudging kOS's steering target a little at a time.

The error message could be a bit better here. It looks for a **SETTABLE** field called "State", and can't find one. There could very well be a read-only field called "State", in which case this will claim it "doesn't exist", because the SETFIELD() command doesn't "see" the unsettable read-only fields. The rule of thumb is this: If the GUI doesn't allow the manual, non-scripted player to directly set the thing with a button or slider or something, then kOS won't let a script do it either. This is so that kOS doesn't end up giving other mods surprises that introduce bugs. (Any other modder's code (or even SQUAD's own code) with an assumption that "this field can't change unless my code changes it" could get very broken if kOS "cheats" by altering the fields in ways a player normally couldn't.)

Yes but does it achieve that "low torque mode" by actually adjusting the torque value the reaction wheel claims to have when the API asks? The kOS PID is constantly re-checking the vessel torque every FixedUpdate to see if it changed. (It has to because, for example, fins have less effect when the air gets thinner, and engine gimbals have less effect when the throttle is lower. It needs to keep re-checking and picking new tuning values again and again.) It could be possible to expose the "angle error" value in kOS. It's an angle between the desired direction and the current direction, which a script can read, so we could put that into an API. It could also be possible to simply expose the most recent result of the lock steering expression as it was calculated to be on the most recent FixedUpdat. That result would be a Unity Quaternion describing the desired orientation (with the resulting "Z" axis of that rotation being the way to point the vessel nose and its "Y" axis being the way to point the vessel "roof". Using that result you would know how far off the error is and you could use that to decide what you want to do with the torque wheel.

kOS uses KSP's own API call to query "how much torque can the vessel do right now if you pushed the controls to their max Yaw? How about their max Pitch? How about their max Roll?" KSP has such a built-in API call that runs through summing up all the torques of all sources, such as reaction wheels, rcs blocks, and gimbals (multiplied by current engine throttle, so the gimbal is properly nerfed if throttle is low right now). Then kOS uses the result of this to choose what PID gains to use. So hypothetically it should work okay with your mod, provided your mod alters the reaction wheel's abilities in a manner that KSP's own API call can "see", trough tweaking the stock variables to new values. (One place where KSP's API call is screwing up kOS is that when someone sets a reaction wheel to "SAS only mode", then it's NOT available to the autopilot control scheme, but *is* available to KSP's own internal steering with SAS, so their API call claims that torque is available for use (it is available, for *them* but not for us), causing kOS to choose bad values for its PID gains under the assumption that torque was usable.)

I don't know Module Manager that well, but presumably it has "not has" rule - so maybe you can say "not has module "kOSProcessor" in the conditional check - thus it only ever adds kOSProcessor if there's not already one there. That might fix the 3 copies problem.

https://github.com/KSP-KOS/KOS/issues/2455 Is it that issue? Maybe the kOS steering doesn't know that torque wheel isn't really available for use, so it assumes it contributes to the overall torque ability of the ship (Which is used to set the PID tuning. kOS queries KSP and asks it "hey, KSP, how much torque is this ship capable of at this very instant?", and calculates PID gains from that. It is possible that KSP is reporting the torque wheel as if it was usable by kOS when it isn't because it's SAS only. (For KSP's own internal purposes it's fine with thinking it can use that torque. Because it *can* - it's steering *IS* the SAS.))

That causes drag, and causes a flex point where there should be a rigid flush attachment. It just really bugs me that people who don't have the DLC are penalized by having to pay the price of extra drag and extra bendiness for a basic construction feature that has nothing to do with the point of the DLC.

Be aware that thrust plates only exist in the Making History DLC, not the stock game (which is annoying - they are an important base part for exactly this reason - multi-engine mounts are a basic rocketry idea dating back to the early days.) Without thrust plates, most engines will refuse to surface attach to the bottom of a fuel tank so you can only mount one engine, in the center of the tank, on the attachment node. The structural parts that fork multi-ways (2-way, 3-way, 4-way adapter) are the only other option I've found without DLC parts, and I don't think they're available at the start in the tech tree.

This mod is basically just ModuleManager configs, is that right? If so, is it possible to have ModuleManager detect how complex the SAS settings for the probe core can be, and trigger different variants of the kOS module settings based on that? The probe cores that let you do stability SAS only are typically lower on the tech tree than the ones that let you do prograde/retrograde lock, which are lower than the ones that let you do normal/antinormal, and so on, so this might work as a generic trigger that will also work on probe cores from mods too (rather than having to make it hardcoded by probe core name, which wouldn't accommodate mods well.)

That is why. We can't fix this on our end. It's Remote Tech. Their API call that we use refuses to see connections if the vessel is purely a manned-only capsule without a probe core. Even though, as you say, they CAN detect the connection in their own UI, they don't expose that connection through their API call unless the vessel has a probe core on it. When using RT, make sure your vessels always have a probe core even if they are manned.

1- Is your ConnectivityManager set to RemoteTechConnectivityManager? 2 - Does your Vessel have a probe core with a Module SPU on it? The Remote Tech API will not show the connection to home if it does not (regardless of what it shows on the UI. It's annoying but that's how it works.) 3 - Which version of KSP and which version of kOS is it? There were some fixed bugs but I don't know if you have them yet.

New Release. Look for it at the usual places. kOS v1.1.8.0 - this is mostly just for compatibility and to make it official that kOS supports KSP 1.7 (rather than it being the case that it just happens to work by happy accident.) Along the way there were one or two bug fixes and documenation cleanups. BREAKING CHANGES Not that we know of, unless you were unaware that some of the bugs fixed were in fact bugs and had written a script to expect that behaviour as normal. (Read the bug fixes below to be sure.) NEW FEATURES Support of multiple-at-the-same-time engines that exist in some mods (but not in stock, as far as we can tell). Stock contains single engines in a part, and multi-mode engines in a part (where only one of the engines in the part is active at a time, i.e. wet/dry mode engines or jet/rocket mode engines). But some mods contain parts that have more than one engine in them that are selected at the same time, rather than toggle-switched like the stock multi-mode engines. One example is the RD-108 engine that the RealEngines mod provides. Its main "straight" engines are one Engine Module, and its smaller "gimbal" engines around the edge are a second Engine Module. Both modules are active at once and need their information aggregated to work with kOS's "an engine part is just one module" system. This PR does so. pull request Special thanks to first time contributer RCrockford for doing all the legwork on this. BUG FIXES The behaviour of LIST ENGINES in regards to multi-mode engines was restored to what it was supposed to have been. Becuase of a small change KSP made, it's been wrong since KSP 1.5, apparently. Prior to KSP 1.5 it worked correctly by giving a list that contains one entry in the LIST ENGINES per engine. But since then it has been returning 3 duplicate instances in the list per each multi-mode engine. This release fixes it, and the previous correct behavior is restored (just returning one, not three). The problem was discovered during regression testing of the pull request, so the fix is inside that same pull request. kOS could be rendered completely inert and broken if other mods not under kOS's control had broken DLL files. Specifically, kOS would abort partway through initializing itself if any other DLL file in the entire KSP game had failed to load during the KSP loading screen. kOS has a "reflection" walk through all the classes that hadn't accounted for the fact that .net apparently keeps a null stub of a class in memory after a class fails to load, rather than it just not existing at all like one would expect. pull request (This was discovered with KSP 1.7 because KSP 1.7 broke some other mod's DLLs making them not load, but the problem was actually there all along waiting for some DLL file to trigger it.) Reworking the position of the Connectivity Manager Dialog box. Our exploratory reverse-engineering of just what the undocumented arguments to KSP's MultiOptionDialog mean, which was used to move the box to fix issue 2456 were still wrong. They didn't do exactly what we thought they did. (The misinterpretation became relevant when the player has UI scaling set higher than 100% and that pushed the dialog box off screen.) Thanks to contributor madman2003 for doing more reverse-engineering on this and submitting the fix. pull request Fix to bug where kOS scripts could no longer SET TARGET to a Celestial Body and could only set targets to vessels or parts. This bug was introduced in the previous release of kOS by a hamfisted typing error while fixing the fact that Body wasn't serializable. It was an error that unfortunately didn't result in any noticable problem when compiling or testing, as it only removed the Body's declaration that "I am the kind of class that knows how to be a target" and it affected nothing else. pull request Several small documentation edits: pull request, pull request, pull request Trying to toggle the panels value on or off would result in infinite log spam if the ship contained a fixed undeployable solar panel like the OX-STAT. kOS was watching for the existence of ModuleDeployableSolarPanel to see if the part could be deployed or not, but apparently at some point KSP started defining all solar panels as having ModuleDeployableSolarPanel, even if they're not actually deployable. Now kOS doesn't treat the panel as deployable unless it also has its animation property defined in addition to claiming to be a ModuleDeployableSolarPanel. pull request

In the case of Wind Tunnel, Wind Tunnel has a new version out that fixed it. (The problem can be fixed on either end because its caused by two problems that have to both exist for the bug to occur: Problem 1: The other mod has to have a Plugin DLL that is failing to load because of some kind of incompatibility with KSP or Unity or Mono version. Problem 2: The kOS mod performs a reflection walk of all classes that didn't protect itself against the exceptions that such a walk will throw when any other DLL didn't load right. I didn't know Microsoft designed their reflection system that way. It's weird to me and I didn't notice the "fine print" in the .net documentation that mentioned it.) If either Problem 1 or Problem 2 is fixed, the bug goes away. I have Problem 2 fixed in develop but not released yet. The reason I didn't hurry to release is that I knew the other mods would have to fix their "Problem 1"'s anyway for their own mods to work, so most of the onus was on them. Wind Tunnel fixed Problem 1 with a new release on their end explicitly for fixing this problem. KAS has a brand new release for KSP 1.7 out, but I haven't had a chance to test it and see if it fixed their "Problem 1" or not.

That really needs more description than that. What does "did not work" actually mean? As in, what did you try doing and what happened instead of what was supposed to happen?

Here is where I wish these fora had a "mark as unread" button like e-mails do. I don't have time to work on this right now, but I definitely want it showing up in my "unread post that's important - go look" list the next time I visit the site.

2 weeks really isn't enough time to draw that conclusion when people are just doing the work in their spare time. When we formed a consortium of users to take over kOS and fork the repo, it was only after a good 4 to 5 months of the original author having "gone dark" without any reply to the pointed question "Do you mind if someone else takes over development?". The author wasn't just silent about kOS, but also had no more posts of any kind to any of his social media accounts (which had been active before and then just totally stopped). We literally couldn't reach him at all through any means we tried, for months, and even so still waited 4 or 5 months of dead silence before deciding it was fair to treat it as "abandoned" without the author explicitly saying so. The point is, 2 weeks is a bit premature to be drawing that kind of conclusion. People have other lives. Being gone for a couple of weeks is normal. Also, you cannot make the assumption, "Oh I posted an issue to github, therefore the author would notice if they were active." If not a lot of users have previously engaged the author through the github repo's issues page, the author may not be in the habit of using that as a channel of communication and might not be looking there as frequently as they look here at the forum.

Okay that's fair. I often forget about the hidden extra nodes you can enable. It's still a bit annoying that fairings aren't allowed to be built straight outward and end up at most being allowed to go maybe 45 degrees tilted outward, and I really wish they'd stop clamping that feature down like that. But yeah moving the next connector (usually a decoupler) up to an interstage node will probably accommodate the inability to make the fairing angle straight out.

Not up. Out. They require that the faring go up which is what I was saying I didn't want. Plenty of real life fairings are wider than the base ring but in KSP when you try to make the fairing go outward it ends up getting jammed in with the part above it because the game insists on starting the fairing shell in between the two parts instead of starting it going outward. To work around the bug you have to make a narrower diameter part above the fairing ring, then go back out to the normal diameter again above that. That lets you make the fairing go up without getting wedged in there, and *then* start having it take a turn outward before it hits the normal diameter part above that. You have to build in this narrowing (which weakens the structure) just to work around the fact that the fairings refuse to be built outward.

I would agree only if SQUAD gave us the tools to override what *they* are doing wrong with fairings, that is: 1 -They require all fairings to angle upward for their first segment out of the ring. They don't let you make the fairing stick out sideways so it will correctly shift out of its slot and not get wedged. 2 - They keep insisting on flinging the fairing *forward and* out to the side, instead of just straight out to the side. I'd like to be able to define the direction vector their explosive bolts push in rather than having it be a random surprise whether the clamshell goes sideways or diagonally forward when staged.

This isn't your fault. Take a deep breath. Whatever the problem is, it seems to be caused by something Squad changed in KSP 1.7 from underneath you. But whatever the cause, it's still true that accord.dll isn't loading right now in KSP 1.7. But this "99% of users" comment makes be think you might have had the misconception that Wind Tunnel only failed when kOS was also installed and so it is working fine for everyone who doesn't use kOS.. I want to help clarify that even without kOS installed, Wind Tunnel causes this message in the log when KSP loads all the DLLs, which for all I know might be causing a lot more problems for your users than just interactions with kOS: AssemblyLoader: Exception loading 'Accord': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 For all I know maybe a mere recompile against KSP 1.7 DLLs is all it takes to make it work again? I don't know. kOS's error *exposed* but did not *cause* the problem where accord.dll isn't loading. kOS had a fragile reflection walk that would fail if any other mod's DLL didn't load. I have now made a PR where I inserted protective exception handling to work around this so kOS is protected if its reflection walk comes across someone's broken Assembly that didn't load. But that doesn't fix whatever the original problem was in the first place that made the other DLL (in this case, the file accord.dll that is included in Wind Tunnel) fail to load.

Is anyone else noticing that if you use arrow keys to move the text cursor while typing in the new type-in fields to edit maneuver nodes, the camera turns? I think the default keybinding to turn the camera is still active when typing in the field.

Historically, it's because tilting a hinged metal flap at the bottom that is utterly unrelated to the rest of the engine operation is a far simpler feat of mechanical engineering. So it was easier to solve the problem that way at first. Gimbaling the engine means needing to feed either cold fuel or hot exploding gas through some kind of pivoting point in the "plumbing", and yet keep the characteristics of that flow absolutely identical through all possible positions that pivoting point can be set to. That adds complexity.

Also, rather than making people guess, or go find it on wiki, can you post the latitude/longitude coords of where this "highest peak" actually is?

In looking through your Readme, I noticed that you mention a mod that adds signal delay to stock commnet without all the rest of the baggage that Remote Tech comes with. I may have an interest in this. Enforcing signal delay is pretty much the only reason I use remote tech, and for everything else I'm entirely happy with just the more simplified CommNet. kOS has an "ConnectivityManager" addon system that is used to model how it has 3 options: PermitAll, CommNet, or RemoteTech. It could be hypothetically possible to make a 4th choice, CommNetAndSignalDelay, to give you the same terminal command delays that Remote Tech has, but it would take a bit of time to study and learn how SignalDelay works, and possibly a small bit of refactoring to "genericize" a couple of hardcoded assumptions here and there in the kOS code that say, "only Remote Tech needs the signal delay counter in the terminal".