Steven Mading

Members
  • Content Count

    3,615
  • Joined

  • Last visited

Community Reputation

724 Excellent

2 Followers

About Steven Mading

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  2. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  3. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  4. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  5. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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
  6. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  7. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    @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.
  8. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    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.
  9. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    Huh? That makes no sense. Hmm. Can you trim it down to two very basic example code snippets that differ only in saying target:ship:velocity:orbit in one versus has target:velocity:orbit in the other? Either this is a bug in kOS, in which case the example will help diagnose it, or it's a problem in the script... in which case the example will help diagnose it. Your posted code shows the part where target is set, but not the part where it gets used where you report the error. I can't see what other code there is in between those two things, and that could be relevant.
  10. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    In working with KSP's API, we've found a number of places where it seems the low level calls only serve the needs of the user playing manually through the user interface, and not the needs of external programs trying to call them. One very common problem is when you expect an API call to do something immediately but it turns out that what it really does is just schedule something to happen "soon enough" to keep the human player happy, but not "right away" as far as program code is concerned. (i.e. "make this thing happen some time over the next physics tick".) One difficulty is that sometimes an update to the UI will add additional delay that wasn't there before (i.e. it takes 2 physics updates to guarantee it happens now instead of 1), and we don't notice until someone tries using that one obscure feature. This is a difficult thing to try to make a unit test for, since it requires the game be up and running and specific actions to be taken in-game. And it's not just the KSP API. Sometimes its interfacing with other mods. In my own scripts I've taken to adding a 2 second wait to the top of every boot file, because I'm using RemoteTech. When loading a vessel by switching to it, if you start the boot program right away, then Remote Tech will claim there's no connection to home, even though a second later it will claim there is. It just spreads out its initialization work across several updates, taking time to get fully set up after a vessel load. For a human player, that's just fine. It's not even noticeable. But for a program, it definitely requires some special work to slow the program down so it acts more like the human player would.
  11. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    That's kind of a generic open-ended question. Yes. There are people here who know how to use this mod. Although I doubt that's really the answer you were looking for. If you have specific questions, people here can help. Do you need to get started? There's a "know nothing" tutorial walk through here: http://ksp-kos.github.io/KOS_DOC/tutorials/quickstart.html (although, reading that I just realized, we may need to update the .craft file it tells you to use. That hasn't been changed in many KSP versions and I don't know if it still loads today. At any rate, you can look at the screenshot of the rocket and just make one like it yourself.)
  12. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    Sadly the issue is a lot more messy and complex than that. See my reply to your reply on the PR. It appears to be an instance of the old file sizes *accidentally without our realization* avoiding a buggy step KSP does on loading them. In the PR that "fixed" the file sizes but kept them as PNG, that made it possible for KSP to attempt its buggy conversion, when before the oddball file sizes meant it didn't try to invoke its buggy code that does the conversion, and left them alone. The irony may be that the original old files worked better *because* they failed conversion.
  13. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    Dealing with this issue has been really frustrating - because whether the icon images work fine seems to be randomly varying depending on the user's exact setup, there's never an indication of anything being wrong on my end or any other people who work on the project, so it's impossible to tell what changes need to be made to fix it. This all started because I was told that using PNG textures is bad and they need to be made DDS precisely to fix this kind of problem, and doing that actually made things worse. I wish I could figure out what to do to fix this problem but I can't make it happen on my own computer.
  14. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    Which icon? There's a few different ones I can think of. Also - just to be sure, wipe the entire GFX folder out, then re-install it from the ZIP - so we know if it's an issue in the actual project or just in how it got released.
  15. Steven Mading

    [1.6.1] kOS v1.1.6.3 : kOS Scriptable Autopilot System

    Another quickfix release - v1.1.6.2 "Feature"?: The terminal's background image is now much darker, increasing the contrast you see with the text so it is a lot easier to read. BUG FIX: This fixes the issue some people have on some graphics cards with Direct3D in kOS-v1.1.6.0, where image textures wouldn't load and the icons were blank black rectangles. It has to do with the step KSP takes to convert images from PNG to DDS not working on some people's graphics cards (it uses the GPU to perform the conversion at runtime, apparently, not not all cards support doing it at all resolutions). So we just published the files as DDS ourselves to bypass that conversion step that doesn't quite work right. People with cards that had the problem have reported to me that this change fixed it.