Dunbaratu

Has anyone else encountered problems wherein remote tech disagrees with *itself* about whether or not you have a connection on which to send manual controls? These pieces of evidence indicate Remote Tech thinks I have a connection: - There is a "green line" path drawn on the map from the vessel, through a hop, to the KSC. - On the upper left of the screen, the indicator is green. It does NOT say the red "no connection" text. But these pieces of evidence indicate Remote Tech thinks I do NOT have a connection: - Using manual WASD keys, or throttle shift/ctrl keys, does nothing (this is while the vessel is in orbit of Ceti (a moon of your homeworld in Galileo Planet Pack), where the speed delay for manual control should still noticeable but still be less than a second. - Right-clicking a part and trying to do anything from its right-click menu, like taking a temperature reading for example, does nothing and gives the message on the screen, "no connection to send command on". So... do I have a connection or don't I? And if I don't, I have no clue what else I'm supposed to do to change this, given that I already have a green line path to home shown on the screen. This vessel has kOS on it and I've had to resort to typing kOS commands manually at the terminal prompt to activate things like the thermometer to get around this (I don't think this is cheating, because this behaviour feels like a bug. Given that I see a connection existing on the map, I don't think the controls are supposed to be getting locked out.) But I admit to not knowing how RT "thinks" on the inside. The only thing I've done that might be a problem is that I used ModuleManager to add RemoteTech's ModuleSPU to all the kOS CPU parts. I did this because by default RemoteTech is incapable of calculating a path/delay to home for ships that have manned capsules instead of probe cores, and that the reason is because such vessels lack a ModuleSPU, and for manual gameplay you don't care if they have a connection home because they're manned. But for kOS gameplay it matters because when kOS detects that you have RT installed, it defers to RT to use its API call HasConnectionToKSC () for the sake of deciding if it's allowed to copy files between home and the vessel. When there's no ModuleSPU on the vessel, RT always answers that API call from other mods with a "no" whether that's really true or not. So I added ModuleSPU to all kOS parts to fix this (which it did - now RT answers the API call HasConnectionToKSC () correctly when used on such a vessel). But now I have the problem mentioned above and I have no clue if this caused it. Note, the above adding ModuleSPU to all kOS parts was done to fix the problem "RT thinks I have no connection on manned capsules when I do", but that situation is NOT the case where I'm getting the problem mentioned above about the locked out controls. The above problem with the locked out controls is happening on a more traditional probe-core based probe where the connection is needed to have manual control because there's no crew capsule on board. I only mention this ModuleManager tweak, and why I added it, to ask if it can cause a problem. If you need more information, I can provide it, but I don't know what information you'd find useful yet until prompted.

[homer]Mmmm.... Lunch script.....gggrrrggggllllllll.[/homer]

That's a LOT harder than you might think. The reason the current KSP game doesn't allow things to happen "off camera" was that the entire physics system breaks down and invokes the Kraken when using large magnitude numbers that aren't as precise as low magnitude numbers when dealing with floating point values. The solution was to only fully invoke all the physics interactions when the ship is "near" the origin point, and to move the origin point with the active vessel. Most people think that cutoff point is 2.5 km or so. It's actually even tighter than THAT - the real cutoff point is at about 300 meters. You can *see* vessels within 2.5km but they're still "packed" meaning not all the PartModules fully work yet, until they get "unpacked" which is really at 300 meters. To make a script able to actually run things on the vessel while the vessel isn't nearby, would require somehow solving this problem first in the new KSP 2.0. And I suspect *THAT* would be the harder problem - much harder than actually implementing the automation itself once that's solved. I'm not sure how I'd feel about the programming system being done with graphical bits like that - it usually ironically makes things *harder* to do them that way. There's a reason flowchart graphical programming languages never really caught on despite how many times people have tried to do them. Also, there's my fear it would turn out like the finite state machine used in the Making History DLC, where there is ZERO retention of information whatsoever so you can't do anything variable with it.

@Lookersky I started asing about it over in the IR Next thread. I hadn't noticed the existence of IR Next before now.

@Lookerksy informed me that this no longer works with kOS. (kOS has some support for other mods where it looks for the existence of their Assemblies and if found it adds some additional hooks into their API's. This system was last updated before this new infernal robotics "next" project was started.) I noticed the beta of this mod's DLL is called "InfernalRobotics_v3.dll" rather than the old name "InfernalRobotics.dll". My question is this: is that "_v3" at the end going to be the new official name of the Assembly going forward or is that just a temporary thing while it's still in beta and it will go back to the old name later on upon full release? If there's been a major overhaul to everything in the IR API I may need to inspect the code in kOS that speaks to IR and see if anything needs changing. I didn't write that code but it's sort of fallen on me to maintain all the kOS code so I'm often having to delve into things I didn't write, like this.

The most important command to remember - get used to typing it fast, is this: set ship:control:neutralize to true. Because unlike with lock steering, with raw control the controls don't unlock when the program ends. If your program crashes, the controls are still set where you left them and it can be hard to recover manually. Typing that line gets you the manual controls back.

You didn't say it was an airplane. That's highly relevant. The cooked steering is optimized for rocketry. i.e. you want to turn left? Then just yaw left. But planes aren't like that. if you try to turn left by just hamfistedly yawing left, the plane starts to roll funny. The stock steering system in kOS doesn't understand how planes need to bank to turn, not yaw to turn. You can use kOS for an airplane, but you'll have to design your own steering algorithm and take control of the controls directly with your script (i.e. set ship:control:roll to -0.1. that sort of thing.) The built-in "training wheels" of cooked control assume you don't have to bank to turn, and you can wait till you're pointing the right way before bothering to adjust the roll axis.

No idea. The probe core isn't upside down is it? You mentioned it aiming south when trying to point it north.

Do you have SAS on? You can either steer with SAS or steer with LOCK STEERING. Not both. They fight each other.

Sending your computer's basic specs is only its secondary purpose. The primary purpose is to gather data on which ads were most effective at causing game sales. The steps required to accomplish *that* (i.e. the game looking at your online history files) is what had most of the complainers complaining.

Removal of Red Shell really should have gotten top billing on the announcement, not just be one tiny bullet point buried deep in the changelog - Because it's the major reason for the recent downward trend in the Steam review score. It was killing your ratings on reviews, SQUAD, and those poor scores might have been afffecting sales (I don't know your sales so I don't know) It just seems that if one single thing is the cause of such a large amount of down-rating, and you remove that one thing, It's in your best interest to have that removal be blatantly sign-posted.

This is a great idea, but I want to pro-actively nip something in the bud before it gets too much of a following among kOS users in this thread - don't rely on the '#' operator here. If you want to use this, this is the only officially supported syntax: lexiconobj["key"] and this syntax is not officially supported: lexiconobj#key They do the same exact thing (literally, they compile to the same kRISC opcodes), but the second one uses deprecated syntax that has been *documented as such* for quite some time now. It is dependant on an accidental hack-y side effect that the kOS devs didn't know about. This syntax was originally made for numerical (thus the "#") list indeces but uselessly required hardcoded literal values in the source code. The hack-y side effect is that it also accidentally works on bare-word hardcoded literal keys for lexicons so when @whirlwind is trying to layer OOP concepts on top of the Lexicon type, @whirlwind used the "#" as if it was the member separator. The first syntax is a bit more typing, but it's also correct, whereas the second is depending on a side effect in the implementation of the compiler that was unintended, and not even documented. (The fact that you can use `#` for numerical literals for array indeces was documented (but documented as deprecated as we inherited that from the old original stuff and only kept it for grandfathering), but the fact that it accidentally worked on Lexicons was not even known to the devs themselves and wasn't even documented.) KUnit is a great wonderful idea - but please please please stick to the officially supported syntax when using it and don't force me to have to keep supporting an old broken misfeature.

My screenshot looked identical to yours and it had no fuel feed. Then I detached and re-attached the engine in the same spot and it worked. Then I noticed - there's two green attachment nodes at the bottom of the service module in exactly the same location, one is a bigger green ball and the other a smaller one - but they are in exactly the same location so I have no idea how to tell which one I'm connecting to. As far as I can tell, one of those two has the fuel feed and the other does not - even though there's nothing the player can do to tell it to pick one over the other. That's really bad design.

The problem is that Take 2 uses the same generic boilerplate stuff for all EULAs even when it makes no sense and doesn't apply. Kerbal Space Program doesn't even access the stuff the EULA claims they now need this new permission for. (i.e. how exactly does KSP know your phone number?) The reason this text is in the EULA is that they make it a one-size-fits-all EULA and not only apply it to all the games but also to the *website forum*. Website fora need some of these permissions so people can't come back later and say "I hereby rescind your right to show the content I composed and typed into comments on your forum. Delete all my posts now." MMO's also need some of these permissions in order to ensure player identity is what it says it is (no sockpuppet accounts). But by also using the same EULA on all games they publish it ends up looking very scary indeed. Yes, the people who don't like the new EULA are right that it looks very bad. But the reason is laziness, not malice. They don't want to bother writing a different EULA for every different game's individual circumstances.

How are you meant to use the SM-25 service module part? It claims to be good for putting fuel inside it. No it isn't. Because if you attach fuel tanks to the interior attachment nodes inside it , then attach an engine to the bottom of the service module, that engine does not have access to that fuel and is shown as being out of fuel. The system doesn't seem to see that fuel as counting as being in the same stack as the engine and it won't feed to it. There are no rightclick options for "enable crossfeed" or anything like that either.

Good luck. I'm sorry the documentation page neglected to mention the TTY keepalive heartbeat. For others following this forum thread who weren't there for the stream - a summary: A telnet client being asked "what is your terminal" by the server is required to respond with the answer in a timely fashion to be in keeping with the RFCs about the terminal type protocol. Technically this is true throughout the entire life of the connection, but in practice it usually only happens during the initial negotiations between client and server. Then it typically never happens again. However, the spec technically says the server can ask this question at any time whenever it feels like it and the client is meant to respond. I ended up using this as a homemade keepalive heartbeat signal so I could disconnect the server if the client just outright hung. Why such an indirect way to make a heartbeat signal? Well, because after much searching I just couldn't figure out how to make the .NET/Mono api let me access the more low-level TCP/IP socket's settings. It seemed that .NET was providing a bit *too much* abstraction here. There's a keepalive feature for sockets, which is the more appropriate place to be doing that sort of thing, but I couldn't find the way to get my hands on it while still staying in the portable OS-agnostic subset of Mono that Unity allows. So I just did the 'heartbeat' at a little bit of a higher level - using the fact that the RFCs state the server can ask for the TTY type any time it feels like and expect a timely response from the client. The effect that @Crimsyn saw was that the server sent a TTY type request every 10 to 15 seconds or so, which he thought was the server being stuck in a broken state, and when his client didn't respond, after a little bit the connection was closed.

The end of the top post says this: I came to this thread late so I didn't see when that [UPDATE] got added, and there doesn't seem to be the usual "edited on ___date___ " caption at the bottom of the post. so I'm not sure what the phrase "next week" actually means. (To know which week they mean, the [UPDATE] text would have had to have a timestamp on it, but it doesn't). If the [UPDATE] Text appeared a week ago, then "next week" could mean this week. If it just appeared today then "next week" would not. Can someone who's been watching this thread tell me when the [UPDATE] text first appeared?

It didn't even occur to me that anything else was allowed because I fixated on the word adapter in the description. Calling it an adapter makes it sound like it modifies a hatch, not makes a new one from scratch. Yes, if making a new hole in the side of the ship is what it does, then it has a purpose, but that purpose is not being an adapter and the description isn't quite right.

The expressions evaluate using a stack, like an RPN calculator, if you've ever used one of those. set z to x / y + 1. for example ends up being like this: push ident string "z". push x push y divide push 1 add store (top of stack now has Z and the value on it, this pops those two things from the stack, storing the value in the variable) Every intermediate step along the way is temporarily on the stack as it goes through the expression.

If that was happening to everyone we'd know about it. Others are able to use it. There must be something wrong with the installation. Can you put the output log in a pastebin somewhere and show it?

Just get the kOS version for KSP 1.4.1. It works on KSP 1.4.2 just fine - it's just that CKAN and Spacedock and Curse don't know that. If you ask them to allow you to install "incompatible" versions so it will list it, it works.

It attached to something that is already a hatch in the first place. Before attaching the part, I have a hatch that leads outside that a kerbal can hold onto the ladder of but you can't really fly the ship while a kerbal is hanging on. After attaching the part, that hatch is obstructed by... a longer hatch that a kerbal can hold onto by being inside of, but you still can't really do anything while they're in there because everything is off-center making the craft uncontrollable. Without the docking port functionality, all it would add is length to the same functionality that was already there. The game provides no difference at all in feedback between "part won't dock because it's the wrong size" and "part won't dock because it's not a docking port". Given that it didn't *say* it was a docking port (calling itself an "airlock"), it's a reasonable conclusion to draw that it's not one when it doesn't behave like one.

I'm well aware of that, but all it does is mimic the look of that historical part without actually *doing* that part's job. When I was trying it, once it had previously been extended, it would refuse to ever collapse again, even when the kerbal wasn't in it anymore. This meant it would screw up the re-entry as the capsule has this thing sticking out the side I can't get rid of. Admittedly that was in KSP 1.4.1. I never used it in KSP 1.4.2 to see if this was intended behaviour or a bug that was fixed. (Because I didn't know it was a docking port, it appeared to have no purpose at all so I stopped using it.) That's not a minor problem. It's major. Because that's the *only* purpose the part has is to be a docking port, and when you don't realize it's a Jr sized port, the conclusion the player comes away with is *not* "I guess I got the size wrong". The conclusion the player comes away with is "I guess it's not a docking port after all. I thought it was but it's not acting like it so I guess it isn't.". You get no feedback that tells you it's a docking port when you try connecting to the wrong size. It acts the same as it would act if it wasn't a docking port at all, so the player has no feedback to realize the problem.

That would still error out when calculating the division by zero, before it got to doing the min(). A better approach might be this: If you think that X / Y might fail because Y might be zero, and you'd like a bignumber result when Y is zero, try maybe doing this: x / max(y, 0.0001) In other words, limit how close to zero the denominator is allowed to become. The example shown wouldn't let it get closer to zero than 0.0001. - Warning: the above example presumes Y is something that isn't expected to become negative. Because max(-900, 0.0001) would return 0.0001.

The stock game has zero concept whatsoever of the notion of an "airlock" because all hatches already allow egress into a vacuum with no consequences. There's no such thing as worrying about emptying the air into space or of kerbals suffocating when this happens. In Gemini, there was no airlock and the doors just opened right into the cabin. Therefore when one astronaut went on a spacewalk, the other had to also have his helmet on since the cabin would lose all its air when you open the hatch. But Kerbal doesn't model this idea because nobody takes their helmets off anyway. The point is there is zero concept of the difference between an "airlock" and "just a hatch" in stock KSP. Therefore a part that is nothing more than adding an airlock to an existing hatch isn't providing *any* functionality at all when airlocks aren't even implemented in the game. Thus I have a problem with the statement 'It's an airlock first". No, transforming a hatch into a docking port is the only *game effect* it actually has. As an "airlock" it does the same exact thing the hatch already did to begin with.