Dunbaratu

Oh good so it's not just me. I got the same problem trying to view my bookmark to my most common search page.

I have a problem that deals with the Remote Tech API as it is called from kOS. Is this the right thread for it? Do any of the maintainers of RT know of anything that might have caused this call to the RT API from kOS to now give a different answer than it used to? var hasFlightComputer = Instance.HasFlightComputer(vesselId); The specific difference is in what happens when the vessel being tested for is unloaded. Now in order for HasFlightComputer to be able to return True, the vessel must be within load distance of the active vessel. Any vessel more than about 2.5km away is always returning false for this API call. I don't think it used to work that way back in 2016 when our code dealing with this in kOS was last touched. The kOS github issue is this: https://github.com/KSP-KOS/KOS/issues/2457 If I'm wrong, and that API call always worked this way, then I guess I have to look elsewhere for the cause of this bug on our system.

Arrrg dangit. In order to fix the rotating map problem, I had to lock out a few more input locks in the terminal in the recent updates to kOS. (I am 100% convinced the rotating map problem is because someone at SQUAD used the input locks as an indirect side-effect test that presumed we are not in map view if the locks are set a certain way, and therefore the camera should rotate to match the ship when the target lock is set.) It makes zero sense that the ability to change target by clicking is the test for being on map view, except it seemed to be doing exactly that. To stop the map view rotation bug, I had to change how the terminal deals with the input locks. This may be a side-effect of that because it's possible I ended up locking out the ability to alter time warp too. Can you write up a good careful description of what triggers the problem (basically what you wrote here in the forum) over on github? I am away at the moment reading this on my phone so I can't easily do it myself. Auto-landing of stages is a very complex operation - one that I don't think Mechjeb does for you. kOS *can* do it, but only if you write a program (or have one someone else wrote) for it. It's not a problem with a simple "out of the box" shrink-wrap solution. (Any such solution will *also* involve having to install the FMRS mod as well, which is needed to avoid the problem that Kerbal Space Program doesn't work if you try to extend the physics bubble" too large to be able to have the 1st stage and 2nd stage both actively thrusting at the same time while 60km apart from each other.) I assume Gudlifer is a native Russian speaker, from the cryllic text in the post. I know there are a few people fluent in both English and Russian in this forum thread. Can someone do me the favor of making a good translation of what I typed above for Gudlifer?

Yeah I see what happened. It now seems that the purpose of that later post must have been you saying, "Let me follow-up that original post by going back and describing more things about what happened just before that first post." But it only seems that way now in hindsight. I took the phrasing about "Followup to the problem" to mean the events being described in your post were a series of events that occurred after the original problem, as part of your follow-up to the problem. That might seem like a minor difference, but getting the order of events swapped around makes all the difference in the world. i.e. instead of "Blizzy was installed when I first reported the problem, in which only Blizzy's icon was broken and the stock icon was working but fuzzy", it sounded more like "Blizzy was installed after I reported the problem, as part of my follow-up to the problem. I discovered that Blizzy's icon was broken too, but the weird thing is that after installing it the stock icon got fixed."

Was it at hard difficulty settings? The building costs are cheaper on the easier difficulties, and the contract payouts are much more lucrative. In the stock game, the intent of scaling it up to hard is NOT to completely cut off, in a strictly Boolean way, access to certain contract types. The intent of "hard" in the stock game is to just make the contracts harder to accomplish because of these limitations, not refuse to even offer them in the first place. This is why I think it doesn't feel right for GAP to require a building upgrade before allowing a certain contract type to even exist at all - especially one that's so low on the tree of prerequisite contracts that it cuts off access to like half the mod.

After reading this, I checked for that problem and yes, there is a mistake similar to the one you describe that I see in the code, but the mistake I see doesn't match your description quite exactly, so I'd like to ask for a clarification to see if it's really the same thing. Question: When you quoted the filename in question as being "launcher-button.png" did you *actually* mean "launcher-button-blizzy.png"? Because if so, then what I see in the code would match your description perfectly. But if you did literally mean the relevant file was "launcher-button.png" (no "-blizzy" in the filename) as you wrote, then what I see wouldn't quite be the same as the problem you describe so I'd still have to look further to find the problem. (What I see in the code would imply that the normal stock toolbar button should work just fine, and the bug I see should only affect the Blizzy modded toolbar, not the stock toolbar.) @infinite_monkey - in your first description of the purple icon, when you said the icon was purple in "the toolbar" did you mean the mod "blizzy's toolbar" rather than just "the toolbar"? If that's what you meant then it all becomes clear. I thought you were reporting it being purple in the normal toolbar - the stock one, and I couldn't reproduce the problem at all. If the stock toolbar was working just fine all along, and only blizzy's toolbar wasn't, then that would fit what I'm seeing. (They are two different image files - the blizzy icon is a smaller version of the image, in a separate filename, and it was that filename that has the problem.)

The problem with any such list as this is that the reality is that these tasks are not pre-requisites in that order. Someone does not need to be able to return from Eve before they're skillfull enough to rendezvous and dock. (iIn fact, being able to rendezvous and dock is almost a necessity before a return from Eve is even something to consider, as the dV requirements of a direct one-stage land and return are enormous compared to doing an orbit rendezvous with detachable lander). How do you rank someone who can do all the things in level 4 but not all the things in level 3? That's a very real possibility. The notion that the skills come in this exact order isn't really true. A better ranking would be each task is worth a score. All the tasks you can do get added together. If the score is above X you are in level Y, etc. That way a person who can't do an "easier" task but can do a "harder" task isn't getting zero credit for that harder task like this ranking does.

I *did* try to use prop engines before jets. The firespitter prop engines are in the same tech tree node as the starting jet engine, which is why I mentioned firespitter by name in my earlier post. When you install GAP on CKAN, GAP recommends also installing FireSpitter, which I did. You say that getting around the stock tech tree not giving any airplane parts till later is outside of GAP's scope, except that then if that's true why do the GAP prototype contracts exist at all? I thought they were there specifically to get around the stock tech tree putting aircraft things too late in the tech tree. I was just saying that to be effective at doing that, at least *some* engine has to be gettable that way, and right now they're not. If it let you get into the firespitter prop engines only, and not the Juno jet, that would be perfectly fine, and make sense. But both props AND jets end up having to wait because the prototype contracts don't unlock any prop engines either, and props are in the same tech tree node as jets. As for the helipad landing, if it does turn out to be the case that upgrading the SPH would have worked all along, then I think the text description of the pre-requisite bullet point might need editing. It would probably need to say "VAB or SPH' where it currently just says "VAB". But even that doesn't really change the fact that that upgrade is *expensive*, even if it's the SPH upgrade, and a player is still left wondering how on earth they're meant to earn that money first while still tootling around on Kerbin and not getting to space yet. The helipad landing contract should be doable without a building upgrade, IMO. It should be just "land on top of one of these buildings", without caring what upgrade level the building is at. Even without the upgrade that marks the top of the SPH or VAB with a big "H", the buildings' roofs are still flat enough to be landed on.

The 450,000 fund VAB upgrade is a bigger problem than the 45 sci point tech tree node. The 45 science cost node is annoying because it requires you to exploit the silly space center building biomes but at least that IS do-able early game to get yourself bootstrapped. The 450,000 fund building upgrade, however, is not. Getting the sort of payouts to pay for that means getting to at least a Mun flyby. Which is still playing the rocket game before the airplane game. (and it's not even a building you *want* to be upgrading if you're playing the airplanes first. playing an airplane career where you upgrade the VAB FIRST and the SPH afterward doesn't make any sense.) It seems like an unfair hurdle to put in the way of what was meant to be a mod that affects the *start* of a career.

Is the purpose of GAP to allow someone to play a career where they do the aircraft stuff before the rocketry stuff? (To fix the problem in stock that by the time you can do effective airplane contracts worth about 20,000 funds you don't care anymore because they no longer matter.) Because if fixing that is the purpose of GAP, I still see a few areas where it needs a couple of changes to achieve that goal: 1 - As mentioned above, the GAP contracts require an air-breathing engine before they will spawn, and while GAP gives you these "prototype contracts" designed to let you bypass the normal tech tree ordering to get some required airplane parts early, it seems GAP forgot to make an "air breathing engine" prototype contract, so you still need to get all the way up to that 45-science-cost tech node to start playing the GAP contracts. The other "prototype" contracts don't really mean anything if you have to unlock the airplane tech nodes through normal means anyway first, so you already had access to most of those parts before you could start working on the GAP contracts. This could be fixed by adding a prototype contract that unlocks either the first firespitter prop engine if firespitter is installed, or unlocks the Juno engine if playing on stock. You've got to have at least *some* air-breathing engine to start the GAP contracts, even if it's just a weak prop engine that would at least let you get started, which right now you sort of can't. 2 - All the rescue contracts require first doing the helipad landing contract, which in turn requires having spent 450,000 funds to upgrade the VAB once to make the helipad exist. If you're playing planes before rockets, then the VAB is the wrong building to be spending your first upgrade on (it should be the SPH), and anyway once you can afford a 450,000 fund upgrade like that, you're already in the stage of the career where you don't care about the small contracts that GAP pays out. It really seems like forcing you to upgrade the VAB first before you can even take the small basic seaplane rescue contracts is, again, forcing you to play rockets before airplanes. I think this could be fixed by making the first helipad landing contract not require the building upgrade. Just let you land on the top of one of the other buildings with a flat top, even when it doesn't have a marked helipad yet but at least has a flat top. Requiring a very expensive building upgrade before you can get started in GAP seems to defeat the purpose of Giving Aircraft a Purpose. Because of the above two problems, I found that to play GAP, I have to play the normal stock "rocketry career" first for a while before those two requirements (45-science airplane tech tree node, and 450,000 fund VAB upgrade) are met so I can start playing the GAP career. And then I just have to sort of ignore the fact that I'm already past that stage and just pretend that I still care about small contracts for the GAP roleplaying feel.

Thank you for updating this mod to KSP 1.6.1! Yaay. The last time I tried using GAP was back when Contract Configurator had those bugs where Kerbals GAP was trying to spawn on the surface kept spawning in midair and falling to their deaths instead (which the player was blamed for, failing the contracts). It made it unplayable. I'm happy to see that it got updated. One weird thing with the "contracts" to buy prototype parts though: There's a prototype part buy for the small circular intake, but no prototype part buy for any of the associated engines that would use it. This renders the air intake prototype kind of pointless since the same tech tree node with the air intake also gives you the Juno engine so.... if you have to get that tech tree node *anyway* to get the Juno engine, then pre-buying the air intake with the prototype contract doesn't do anything. This was a problem when I took the contract to build the first airplane, and then was forced to fail the contract and take the penalty because I was unable to actually get an air-breathing engine until later in the game when I unlocked that tech node in the normal rocketry way instead of the airplane way.

In order to keep the main KSP game from seeing your keypresses in kOS as commands to the ship, kOS has to turn on almost all the input lock flags in the game while the terminal is focused. This is probably what is messing up this mod - it's probably not updating when certain input locks are on.

try using parethesis () to hint the compiler that that its a function.

I passed on a notice about it to the other dev who works in that area of the code, however he has very little free time these days so I might end up having to dig through that code and understand it.

That would be a lot of work. It's not impossible - just that it's enough work to detract from time spent on the mod itself. It's the sort of thing that would be better to take up by someone else not working on kOS itself.

Yes, I second this. One of the key mistakes made by the stock game is denying you access to the fairing that is mandatory for a Stayputnik launch to work until after you have better probes than the Stayputnik, thus causing the Stayputnik to have no purpose whatsoever in the game. In the very first Sputnik launch, the USSR already used a fairing, and it's not like a fairing is some mysterious advanced technology.

It's a kind of long involved admin thing. Maybe if we can find a webpage that gives a summary we can link to that. My concern with giving a step by step instruction is: 1 - It's different for each OS platform, multiplying the complexity of the documentation. 2 - Just like with assuming we sanitized every input perfectly to avoid the issue, if we assume we covered every problem in our setup instructions, once we declare "do these things and it protects you", we will open ourselves up to accusations its our fault if someone gets hacked because our instructions missed a step. Giving out security instructions when you're not a security expert is like giving out legal advice when you're not a lawyer. Generally it's better to say, "Don't take my word for it - the onus is on you."

Actually that sounds like exactly the problem. Probably the reason the targeting is only allowed within 200m is that this is the "pack" distance the game uses for parts to become fully functional. There's probably lots of other things the this 200m distance effects since its the range at which the ship changes from packed to unpacked. New release: The only difference in this release is an update to Folder Protection (keeping scripts from escaping the Ships/Script folder). # v1.1.6.3 Folder Path Protection Built for KSP 1.6.1 This is a patch for protecting against some kinds of file folder access that concerned us for those people using kOS to set up "Twitch Plays kOS" streams. Although we try to block a kerboscript's ability to access files outside the ``Ships/Script/`` folder, we cannot (and *will not*) guarantee to have thought of every trick a clever person might come up with to fool the system into allowing access. As always, be wary that if you allow any random arbitrary person to run scripts (in any system, in any language, really) on your own computer that you have not read through and vetted yourself, that you are doing this at your own risk. ### BUG FIX: If you currently have a "Twitch Plays kOS" stream, or plan to set up one in the future, PLEASE see this writeup: * https://github.com/KSP-KOS/KOS/issues/2439 Get it at the usual places (see first post of the thread). Many thanks to @lucaelinfor doing the majority of the legwork on this problem.

Test where center of mass is on the target ship. One way is to take control of the target ship and rotate it to see where the pivot point of rotation is (that will be CoM). When targetting the whole ship, the game's UI highlights where the control point is. When picking the position of the ship, kOS uses its CoM. If you have a really long part, the center of mass could be quite far from the control point. This is one of those things that if we had the luxury of redesigning kOS from the ground up without any legacy backward compatibility support to deal with, I'd probably have liked to see changed. I'd choose the control part as the ship's position, and make the ship's CoM be an optional suffix call you can make if you want to know that.

To check if the ship has docked, I use ship:parts:length. When the count goes up, that it docked with the other ship and added new parts to itself. When using RCS with a PID loop, be aware of this fact that I discovered the hard way: KSP imposes a 5% null zone on RCS translation. If you do: set ship:control:top to 0.05. it will have the same effect as: set ship:control:top to 0.0. you have to set it to at least 0.050001 for it to do anything. This is something KSP is imposing that we didn't know about before. And it can confuse a PID controller that doesn't realize it's requested controls aren't being obeyed when it tells you "please set control to 0.04" and it's actually getting a zero.

Although we don't have "atomic sections" to force two adjacent lines to be in the same tick, you can still guarantee it happens in the same tick by forcing a WAIT 0 right before the two lines in question, so you know even at a low IPU setting there will still be plenty of IPU to fit both lines in before there's a break, by starting a new update right before the section in question.

I don't know if I'll have the time to check this out, but I fully support the idea of users doing this. The more public examples there are, the easier it is for new people to see how things can be done. @RizzoTheRat I don't think I'll be able to fix it, but I can at least document the problem you ran into. The issue is here: https://github.com/KSP-KOS/KOS/issues/2435

Assign the target to a variable of your own so the game doesn't rip it away from you and change it. As for the weird difference between the terminal being focused or not, I think I may have an idea and it's annoying because I'm having to work around a stock KSP bug. Do you remember the behaviour kOS used to have where if you have the terminal focused and are looking at the map view, the map view would rotate if your ship was rotating? Remember how annoying that was? Well, it turns out after much trial and error that what caused it was the targettting input lock. KSP has 64 different individual boolean flags for allowing/disallowing UI inputs to work. There's a flag for keyboard input, a flag for steering, a flag for the throttle, a flag for switching vessels, etc. One of these flags is for allowing picking a target. In the past (when the rotation bug existed) kOS was always unlocking target picking at all times, so that a script can always do SET TARGET even if the player cannot through the UI (the UI flag banned even a program from doing it - because KSP melts together UI issues with low level API issues a lot of the time). Now, what made no sense is that KSP caused the map view to rotate for some weird reason when that targetting input lock was unlocked. (which happens as a side effect of switching focus). There is no reason for that to make any sense, but I proved this is exactly what caused it. When I made ONLY that one flag differ and none of the other input flags, that changed the map rotating behaviour. So how to solve the problem of the rotating map? Well I decided that the targeting input lock really only needs to be unlocked when setting the target. So I did this: When you run SET TARGET TO WHATEVER, kOS *temporarily* unlocks that input lock so the game will allow the target to be set, then puts it back the way it was again when the SET TARGET command is over. That fixed the rotating map bug. But now it looks like putting the target input lock back again after the SET means the UI code will re-assert itself and rip away the setting you made when it next runs between pysicks ticks. So it looks like I can either get rid of the targeting bug, or get rid of the map rotating bug, but not both. For some ridiculous reason, these two unrelated things are melted together somewhere inside KSP's hidden code - both being triggered by the same boolean setting. The rule "cannot pick a docking port target > 200m away" is meant to be a UI rule, but that UI rule is affecting all calls to the API routine whether coming from autopilot software or from manual player control. And so when the KSP game runs code in between kOS ticks, it sees "oh look the target is set to a part but we are >200m away, I will therefore re-assign the target to the whole vessel" because it's assuming that target had been set by a player. At this point I'm going to just document it, rather than fix it - because it's hard to fight the KSP game's own behavior on this one. Just use your own variable instead of TARGET, I guess.

@RizzoTheRat Are there any of these in your code which aren't being shown in the forum? ON ____ { } WHEN _____ THEN { } LOCK STEERING TO ..... LOCK THROTTLE TO ...... Those are all things that can fire off between ticks and execute code between ticks. OOOH. There's one other possibility - the KSP game refuses to allow setting target to docking port except when within a close distance. If you drift a bit farther away, it may force the target to be the whole vessel instead of a part. It could be that it forces this to happen between ticks.

It should work, yes. The only thing I can think of is that target *must* be getting changed to something else somewhere, and that change is happening maybe from one physics tic to the next which is why it only happens when you have longer code (that allows a physics tic to happen between setting it and using it). Maybe this test might help - put this statement between each line between the setting of target and the line that errors: print "AAA: target type = " + print target:typename. but change that AAA to BBB, and CCC, and DDD, etc on each subsequent line so you can tell the lines apart and tell which line of code printed which line of output. At some point in there, the target has to be getting changed to another type, and discovering exactly when that happens might help. Once you have that test set up, and you see where the type gets changed, then try this: Leave the code alone, but change your config:IPU to other values and try again to see if the place where it changes ends up *moving* when you do that. If changing the IPU causes the change to happen at a *different* line, then that would confirm that its something that happens when a new physics tic starts. If it is something that happens when a new physics tic starts, then that might be a kOS bug, or it could still be a script problem if your script has any triggers like WHEN or ON, or LOCK STEERING, that might execute code between tics and cause Target to change to something else. Either way, narrowing it down will help (either me if it's kOS, or you if it's the script) find the cause.