Dunbaratu

Actually that's quite useful. I was annoyed at the fact that there's no proper copy constructor for UnityEngine.GUISkin. The documentation for Unity (which is just about as bad as the documentation for KSP) didn't make a mention anywhere on the page for GUISkin of the fact that the reason there's no copy constructor is because there's a factory method instead for creating GUISkins.... That one piece of the log said a mouthful there.

Pro tip: the queries performed by these can be expensive at times depending on your ship's part count. If re-using the same query multiple times, store it in a variable first for faster execution, like so: set decouplers to ship:partstagged("payload_dcplr"). if decouplers:length = 0 { stuff } else if decouplers:length > 0 { stuff } else { set deploy_device to decouplers[0]. }. Doesn't exist yet. You'll have to wrap things in if checks and set flags to descend to the bottom of the program. Part of the problem is that we don't yet know how functions or procdures will be incorporated into the language, which sort of affects what the right way to implement such a thing would be (there being more than one kind of premature exit - full exit, function return with value, etc - not knowing how that will look in the end is making us not want to make any early commitments to one way over another.)

okay. noted. It will be a while before I get to it, because fiddling with the documentation requires a reboot. (The docs are using a unix system and I normally run KSP in windows. I have to do a reboot to change the docs.).

You're not doing anything wrong. You are encountering an annoying "feature" of the way kOS is wrapping things around the underlying C# api. It's complex to explain, but every time you ask kOS for a "body", it generates a new wrapper around squad's "body" and gives you that new wrapper. The equality operator is returning false because although these are the same body, they are two different wrappers around the same body and it's comparing the wrappers, not the bodies. We can probably fix that and should. Two kOS wrappers around the same SQUAD object should be treated as equal by the equality operator, but currently aren't. I'll make an issue for it. (EDIT: The issue is here, if you want to track progress on it: https://github.com/KSP-KOS/KOS/issues/405 ) In the meantime, here's an idea that might work: It may seem daft, but give it a try: Change this: if ship:patches[2]:body = y to this if ("" + ship:patches[2]:body) = ("" + y) It forces the two body-things to produce a string output of themselves (like the PRINT statement does), and then just compares if the two strings they produce are the same. (i.e. if there were hypothetically two different bodies both named "duna" in the solar system, it would produce a fake "true" when comparing them, for example, because it's just looking at the string names and nothing else. But since that can't occur, this is a good workaround for now.) Unfortunately that same fix doesn't work everywhere that has this problem. For example, comparing two vessel variables to each other has the same problem, but it can't be fixed by the 'string' trick since it's perfectly legal to have two vessels with the same name that are different vessels.

I'm going to fiddle with your indentation to make it easier to follow what's going on: set y to Duna. set i to ship:patches:length. print i at (5,19). set k to 0. if i>{ until k=i { print SHIP:PATCHES[k-1]:body at (5,21+k). set destynacja to SHIP:PATCHES[k-1]:body. set k to k+1. }. lock throttle to 0.5. if destynacja=y{ lock throttle to 0. set faza to 2. }. }. Look at what will happen on the first pass through the loop, where k = 0. If k = 0, then getting the [k-1]'th element from the list will be getting the -1'th element. That's probably the "argument is out of range" that it's complaining about.

Has anyone been using "part:facing" yet? It looks like it's aimed out the side of the part, which is not consistent with vessel:facing, which faces out the top of parts, by default. I'd like to fix it so they both mean the same thing, but am afraid this could mess up other people if they have old scripts that used it. I don't think it was used much because if it was people would have reported this as a bug. It's been this way a while. The proper thing for it to do is have part:facing changed to aim out the top of the part, so it coincides with vessel:facing. (i..e to get the facing of a docking port, it tells you which way it's dockable direction is aimed. Right now it tells you a direction out the side of the part).

I've just verified what the problem you reported is and I see why it happened: https://github.com/KSP-KOS/KOS/issues/392 It should be a very quick fix but I don't know when it will get out in a release.

If you assume that ${KSP_HOME} is the place where your KSP game is installed, it's here: ${KSP_HOME}/Ships/Scripts/ (replace "/" with "\\" if on Windows).

Added as an issue on github. I guess nobody tried doing it in the hardmode where the craft has no torque power.

did you get the zip before or after this post was made by erendrake: http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-0-2014-11-16?p=1547229&viewfull=1#post1547229 ? it sounds exactly like the problem that it fixed.

There should be a fix for the syntax problem @ouch discovered soon: SET arrows[x]:vec to v(0,0,0). I found the problem and fixed it in my own private copy but there's Real Life events that may interfere with the process of getting it merged into the main repository and released, because of... uhm.... things. In the meantime, if you need a workaround, in places where you try to do a thing like this: set foo[x]:suffix to whatever. You'll have to split apart the expression into component parts like so: set fooX to foo[x]. set fooXSuffix to fooX:suffix. set fooXSuffix to whatever. in order to avoid the part where the parser is currently doing the wrong thing when its all combined together.

It's there now. The documentation builder software failed to export that file to the public site and I have no clue why, because the second time I re-ran the builder just now (to try to diagnose this problem and see what happened), it just worked correctly this time around. I have no clue why it didn't the first time. I didn't change anything.

That looks correct to me. The "*" operator on vectors is mapped to the dot product. So you took the dot product of two vectors, which is already a scalar - not a vector, and tried to take its :mag suffix.

Actually that's quite revealing. It seems to be thinking that 'x' is of type VectorRenderer now. Which means that here: set arrows[x] to arr. It did something wrong, and put 'arr' into the 'x' instead of into the 'arrows[x]'. I suspect as I look into it I'm going to find it's a problem with any generic "set somelist[idx] to anything' is going to end up trying to set the 'anything' into idx instead of into somelist because it mangled how it used the stack. In the meantime to get code working, try building the arrows list from scratch each loop instead of overwriting the values in-place and see if that gets you what you need for now. (i.e. just before the "for t in tar" loop, do arrows:clear(), and then inside the for loop do arrows:add( stuff ) instead of arrows[x] = stuff.

Can you try splitting that out into these two lines and see if that makes the bug go away? set arr to arrows[x]. set arr:vec to v(0,0,0). //(t:position - ship:position). If that makes it go away, then it tells me the problem is entirely in the syntax parsing. If that does not make it go away, then it tells me the problem is elsewhere in the system. Oh crud. I just had an idea. Are you talking about code that was saved on the ship while running an earlier version of kOS and now the newer version of kOS says it has zero size after the update? Or is it code you added to the craft after the update was already installed?

In the past the mod was begun in a sort of ad-hoc way and when others took it over and helped further its development after the original author left, we've all been thinking of how to make the sorts of things you're referring to better. It's not quite there yet, but there's the glimmer of an inkling in recent refactors of the code to make the internals more self-aware in a fully "reflective" way, such that automatic generation of the information you're talking about should become possible some day. Having just gone through all the docs in prep for a v0.15 release, I can say that doing it all manually by hand is no way to do it. It's better if some of it can be autogenerated with reflection techniques, and that would also allow us to think about automatic help techniques too. In the meantime, ask away here. Lots of people give helpful advice to the new kOS user. And welcome to kOS.

You are confusing the issue by using the word "Target" which has special meanings. It sounds like the real problem has nothing to do with whether or not you decide to set the vessel to "target", but rather it's about whether you can even get a handle on the vessel you want in the first place. In other words you'd have the same problem if you did this: set thatship to vessel("SHIPNAME debris"). / as you have when you try to do this: set target to vessel("SHIPNAME debris"). The fact that's its the magic "TARGET" ship has nothing to do with the problem. It's the inability to tell the Vessel constructor function which "SHIPNAME debris" you meant. While I understand that it's annoying I still put the primary blame on SQUAD, because the ridiculous rule that you cannot rename a debris vessel was their idea, and it's the main reason you're having the problem. If you could just rename the target vessel the problem would go away. In the meantime, you could try LIST TARGETS IN MyTargetList, and then see if you can go through them and find the one you want based on some known criterion like part count, or a known command core, or something like that.

Not currently, but in 0.15 we have a new "nametag" feature where you can manually assign whatever names you feel like to any part of the ship, and then in the code use those names as your means of selecting parts. you can then just name the root parts (the command cores) of your vessels whatever you like with the rightclick menu. The part will not require power to do so. (I always thought it was utterly ridiculous that stock KSP requires you to have the craft powered up to change its name. Did the moons choose their own names? Did the asteroids choose their own designations? No, the names are decided by ground control, so even a dead ship that's not responding should still be rename-able.) I have to ask why you can't rename the ship in flight. Is it out of power? As to the problem of only having one global ship at a time called "Target", that's a problem inherited from KSP itself. KSP was written to assume it's not possible to control more than one ship at a time, so it was good enough to just have one global target at a time, and then switch what it is as you swap which vessel you're controlling. (each vessel does *REMEMBER* what ship it was targetting, so when you switch to it it will reset the global target to what it remembered, but the rest of the high level logic that goes with having a currently targeted ship doesn't work except on the current active vessel.)

That's truly weird because the internals of that text editing widget are mostly just up to Unity itself. We're just calling out to a stock Unity widget tool. If it doesn't respond right to the return key, then I don't know what to do. What particular OS platform (including bitness) are you on?

You could probably now replace the two steps: set dp to vdot(velvec,upvec). set currentSlopeAngle to 90 - arccos(dp). with just this step now that the language has the VANG operator: set currentSlopeAngle to 90 - vang(velvec,upvec). Taking the dot product and then taking its arc cosine, under the assumption that the two vectors it was made of were both unit vectors, was a sort of hack to get around the lack of a VANG operator.

SHIP:FACING is in fact just a "rotation" operator, and SHIP:FACING:VECTOR is really just giving you the result of rotating the Z-axis by SHIP:FACING. So these three: ``` set shipXvec to ship:facing * V(1,0,0). set shipYVec to ship:facing * V(0,1,0). set shipZVec to ship:facing * V(0,0,1). ``` Will give you 3 basis vectors aligned with the ship's starboard direction, roof direction, and nose direction, respectively. In fact one of those three (I believe it's shipZVec but I'm saying this from memory so I may be wrong) will be identical to saying ship:facing:vector. So you can use VANG, VDOT, and VCRS to get your rotated angles around various different things. It sounds like what you want is the VANG between ship:body:position and the shipYVec I described above. If 180, you are pointed up directly away from gravity. (hint. SHIP:UP is a unit vector always pointing away from that ship's body's position, right at the center of the blue half of the navball. This may be easier for you to work with than ship:body:position:vec:normalized).

Just a general warning about some breaking changes upcoming in v0.15: One of the reasons for the delay of releasing v0.15 has been the fact that we've been stretching the language past some limitations of its original design, and hitting a wall caused by our desire not to break old scripts you've all written. There are a few cases where the original language spec is quite limiting and trying to make old code work without any edits despite adding new functionality was forcing us to implement the new features in rather convoluted and bug-prone ways just to shoehorn them into the old syntax of things. It hit the point where we just decided that what we were trying to do would probably cause *more* user headaches than just telling people to make some edits to their scripts in small places here and there. By breaking with tradition in a few places we gain the ability to actually implement things the right way. And it's actually a lot easier than the messy hacks we were in the middle of trying to make. So when the release announcement is eventually made (RSN?), please pay special attention to the section of the release notes that tells you what the breaking features are. It's going to be important in this particular release. But when you all see it I think (hope?) you'll agree that the breaking changes were worth it to allow the new features. (I'm just trying to manage expectations here.)

@Almoris, What @ouch said. What do all of you, the users of kOS, think of the possibility of implementing implicitly expanded lists based on usage? In a lot of languages designed for quick and easy prototyping, they have this rule: * If the program attempts to assign a value into array[idx], where idx is larger than the array's current size, then instead of bombing out, take this as an implicit desire by the programmer to want to grow the array to become big enough to have an index of idx. So, for example, if you did this: set mylist to list(). set mylist[2][3] to "hello". Then you'd now have a list that looks like this: mylist[0] = list of size zero. mylist[1] = list of size zero. mylist[2] = list containing: list [0] = null, list [1] = null, list [2] = null, list [3] = "hello". It grows the list at the minimum necessary to hold the index given. There are some languages, like Perl, that operate this way. It's an idea I had rattling in my head a while. It makes for very easy to read code when you are trying to populate a matrix of data, but it does have the following pitfall: If you try to do mylist[x], where by accident you had an enormous x, like 9999999, you end up carving out a gigantic chunk of memory and perhaps crashing because there's not enough. I consider that an acceptable programmer error the language shouldn't try to prevent, akin to getting stuck in an infinite loop, but not everyone agrees. Also, that would require that we have the ability to handle user variables that contain NULL, which up till now has been avoided, in order to let people deal with an array which contains nulls for some of its values.

Quick response: this is the thread for the newer kOS: http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-14-2-2014-10-08 Longer Response: I may get back to you later if that's not enough. I am headed out the door and have to make this post quick.

Let me give a few details about past problems the vecdraw had with this, to give a hint as to why I am suspecting this is an old bug resurfacing due to some code being lost along the way and not being merged in, rather than a new one. Problem 1: People routinely claim when talking about the space kraken problem that what SQUAD has done is to place the origin of the coordinate system on the current vessel. This is false. What they actually did is to put the origin NEAR the current vessel, but allowed it to drift away. I don't fully understand the reason for it, but early experiments showed that the position of the ship is never exactly 0,0,0, and that over time the active vessel drifts farther and farther away from the worldspace origin point the longer you stay in flight view at 1x speed. Going to time warp speed seems to cause the origin to reset when you come out of it, so the ships is once again back at the origin exactly, but then immediately starts drifting away from it. Therefore I made the decision that in order for the positions and vectors of kOS to be usable at all, they must shift the origin point to something you can see and relate to in-game. The actual origin is a magic invisible point you have no idea where it is. Therefore every single position kOS returns is in a coordinate system centered on whatever vessel is the one running the computer on which your script is executing. It's just a matter of subtracting the ship's position from the coordinates that KSP gives us under the hood. That solved some of the problems. Problem 2: Under the hood, there are two methods to get the position of a vessel, and it was unclear what the difference between them is because the API is undocumented. (all the documentation comes from the user mod community). One is clearly named findWorldCenterOfMass, which is clear what that means, but the other is just the actual position of the ship.. well. the position of what part of the ship? (It turns out it's the position of the root part of the ship - the command core you used to start building it from, which might be quite far from the center of mass, but this wasn't mentioned and took trial and error to figure out.) The problem was that different parts of the code, written at different times, by different people, used a mix of both types, leading to inconsistencies that you'll only notice when in a context where the few meters of difference between rootpart and center of mass matter. I ran through and changed every one of them to a standard of using center of mass everywhere, and that got rid of the weird vector offsets. At least it got rid of them... until NOW. Which is why I'm baffled that this has come back again. It looks *exactly* the same as a problem I already fixed, which is why I started asking questions about which version number this was. I promise that as soon as 0.15 is out that this will be the next thing I look at for 0.15.1. I fully expect that once 0.15 hits the public, people will find stuff wrong with it that we haven't foreseen, that require a patch, just because it's impossible for two people to fully test every usage case. It's my goal to make the fix of this part of the first patch after 0.15.