Dunbaratu

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".

You are 100% correct that it's dumb to work this way, but it does, because Microsoft. Yes, I agree that the exception should only happen when the DLL is first being loaded, not *again and again* every time someone uses reflection to look at the classes. Once someone is using reflection to look at the classes, the classes that don't exist simply, well, shouldn't exist. Not "sort of halfway exist enough to break GetTypes() and make it throw an exception." There is a fix, though. What MS, in their infinite wisdom, decided to do here is make GetTypes() throw an exception despite the fact that it worked just fine. And then, because it threw the exception, that means the return value is inside the exception object instead of being returned in the normal fashion. You can see what I did to fix it here: https://github.com/KSP-KOS/KOS/pull/2492/files

That's a weird way to phrase it. kOS not working with Wind Tunnel is *already* how it is. I think you added a "not" in there by accident that flipped the meaning. Also, just to make it clear, getting an update to kOS that has this fixed *still* doesn't mean you'd have a working Wind Tunnel mod. The problem happened because Wind Tunnel's DLL file won't load in KSP 1.7, and kOS can be broken by any other mod's DLL failing to load because I didn't know how weirdly Microsoft implemented its reflection GetTypes() call (When a DLL didn't load one of its classes, GetTypes() still works anyway but it does so by throwing an exception and moving its return value into that exception's fields instead).

I know it's mostly moot now that a new KAS version is out that works with KSP 1.7, but I wanted to report that I found the cause of this error in kOS and it was *sort of* caused by the fact that KAS didn't load, combined with me not understanding the really weird way GetTypes() works when DLL's fail to load. I would have assumed that "Failure to load this Type" would only throw an exception once - at the time the DLL is being loaded. Then after that if you trapped the exception that the loader generated and keep going (as KSP itself does when trying to load mods), then from then on the Type would simply not even be present at all, because it failed to load. But actually there still is an empty stub of the class there when it didn't load - just enough of one for GetTypes() to attempt to do things with it, and then to make GetTypes() work you have to trap the exception and pull the information from elsewhere to work around the fact that one of the Types that GetTypes wants to return isn't "really there".

I believe I may have a workaround for this "can't open terminal" problem so it doesn't happen again in future versions (i.e. kOS doesn't get ruined by *another* mod's DLL incompatibility). My fix which seems to handle it - making it not crash even when the broken versions of KAS or Wind Tunnel are installed, is this: https://github.com/KSP-KOS/KOS/pull/2492/files This doesn't actually fix the original problems with these other mods failing to work - that's on them - but it fixes the problem of their failure to load in turn causing kOS to fail to work. The comments in the code are verbose, because I may want to show this to other modders who had the same problem, and I want to explain it to them. The actual code lines are not many.

Microsoft has bizarre alien ways of thinking. I find their techniques a weird random hodgepodge. It would seem more intuitive that if the actual error occurs at the time the DLL is loaded, then that's when to have an exception to get a developer's attention, and if that exception is caught and ignored by the dev, then from then on make GetTypes() just return the classes that really exist, or have it be considered normal for it to be populated with some incomplete Types that have some kind of "loaded = false" flag on them that you have to protect around (or a bitflag set of options to GetTypes, as is common in other reflection calls, one of which explicitly says "only get the ones that are loaded, please".) There's other ways to do it that wouldn't have had this weird "If there's a warning it still works anyway but you have to retrieve the return value from *over there* instead of where it belongs.". Anyway, thanks for the information. It makes the problem fixable.

Okay I've *never* seen an exception work that way before, ever. So basically, its saying the exception didn't interrupt the program flow at all, and GetTypes() continued doing the rest of its work on the other classes before it finished. It still built the rest of the list. You just have to look inside the exception to find it, since it didn't return in the normal fashion. That's utterly bizarre way to use an exception but at least it's a workaround. (It's weird to me because it's basically using an exception for something that's a mere warning, rather than using it for an error that actually broke program flow.)

It's as if the system is contradicting itself, by saying, "that class is doesn't exist, so I can't include it in GetTypes()" and "that class exists, so I will include it in GetTypes()" at the same time. If it doesn't exist, then why is GetTypes() including it and therefore bombing out? Is there any set of flags, or another call I can use, that tells the system, "When I say GetTypes(), what I meant was the ones that are really there. Get me the Types that you actually loaded. If 1000 classes were attempted to be loaded, but 1 of them failed to load, then fine, at least let me see the other 999 of them." I feel like I'm still going to want to protect myself from this in the future, even if KAS and Wind Tunnel get a 1.7 upgrade to fix this one instance of the problem. I wasted a lot of my own time debugging a problem that wasn't "mine" to fix, it turns out. If I cannot find a better version of what GetTypes() does that actually executes it safely, then I'll just have to trap the exception and issue a message to the user along the lines of "Some Mod, which might be kOS or might be some other mod, I can't tell which, has tried to load a class and it failed. This is going to break kOS, but kOS can't fix it - check your error log for the first exception that looks like this: ....... and remove the mod it's talking about." The bettter solution (but much uglier) would be to have a safe way to query all the type names that GetTypes() *wants* to return, in a fashion that won't break, and then try accessing them one at a time with a try/catch wrapper around each attempt, so that when the attempt fails I can at least report which class it is that's causing it, rather than just having GetTypes() in general fail overall.