Dunbaratu

Calling out to other programs works just fine. Variables are global so whatever the child program sets the parent program should see. There's a few things that don't cross the program boundary correctly - like triggers (you set up a WHEN/THEN trigger in a subprogram and it won't trigger in the parent program). As far as performance goes, the very first time a program runs it will take a moment to compile the subprograms which takes a bit of time but from then on it never re-compiles it so it will be faster after that.

The problem I'm having isn't detail level, it's aim. It's hitting kerbin when not even aimed anywhere near kerbin. I can aim the ray up 60 degrees above the horizon from an orbit of 100km and still get a "hit" on kerbin, and not get any hits when aimed right at kerbin from there. This is making me think the coordinate reference frame the function call expects its arguments to be using is not really the Unity World coords they're named as if they use. This is where Squad's insistence on not documenting their API, combined with their insistence on making it illegal to decompile the DLL, makes some mods nearly impossible to write. You have nothing to go on for what an API call does other than it's name, and the types of its arguments, and the hope that another modder has already worked out what it does through trial and error, so they might have documented it on one of the fan-made API documentation sites. In this case those clearly aren't telling me what the call actually does. I had a good search through other mod code available in github to see if anyone else is using this method and nobody seems to be.

What the subject says. I can't get the thing to work at all, and I suspect it's because unlike what the parameter arguments say, it's not *really* expecting me to use coordinates in in Unity world coords, but in some other system it's not telling me what it is. When I use the exact same coordinates that work for local raycast collisions, which are supposedly using world coords, the same coordinates don't work with the pqs controller attached to a CelestialBody. They keep finding hits where there are no hits, and failing to find hits where there are. I was wondering if there was anyone, anywhere, who had used this method before. Every place I expected I might see an example of it working, the mod in question wasn't using it but using something not quite right. Most mods that do a similar thing to what I'm trying to do seem to get an intersection with the SPHERE of the planet, and then get the altitude at that location, which isn't quite right, as the diagram below shows:

What you're seeing is an underlying C Sharp error bubbling up to be exposed to you. In C Sharp, "Out of Sync", despite the name, has nothing to do with timing or threading at all. It means that while using one of the built-in collection looping operators, the collection itself was changed, which C Sharp's iterators are too simple to understand how to handle, so it throws up its hands and spews this error whenever it happens. The kOS equivalent would be trying to make a FOR loop over a LIST, and deleting items of the LIST inside the FOR loop. Since your code doesn't appear to do any looping of its own the problem must be happening in kOS's own Csharp code. Can you say what the version of kOS is? This problem used to happen a lot and it was fixed, but it's been so long since a real release that this fix might not be on the public curse release.

That is not true. WHEN/THEN allows the body to be either a singleton statement or a block of code with squiggly braces. Much like "C" and "Java", the squiggly braces are optional when the body only contains one statement. If what you're saying was the problem, the error would have been a syntax error rather than a runtime error. Granted, it's often good programming practice to use the squiggly braces anyway even where not needed, but that's another issue. One thing I see as a deficiency in the language is how the rules about requiring squiggle braces are not consistent between the different places they could be used. SOME places allow them to be optional when only one statement is in the body. Other places require them unconditionally. Optional: WHEN/THEN, ON. Required: IF, UNTIL. The old-time C programmer in me wants to see them optional all the time, but that would probably require adding the required parentheses around the condition in the if/until cases that C has, which it has specifically because it needs some way to mark where the conditional expression ends and the body begins when there's no squiggly braces. Basically, fixing the inconsistency would break some backward compatibility no matter which way around it's fixed. Making the braces required everywhere would break old WHEN/THEN's and making them optional everywhere would necessitate adding required parentheses to the Ifs and UNTILs.

That pastebin is showing what the code looks like WITH the "<" and ">" marks, not what you did to try to remove them. You say you removed them and then got the error, but you didn't show what it looked like after the removal. Did you literally JUST delete the '<' and '>' and therefore I should assume that the code you ran with is what I see with those singleton characters removed? If so, then that's the problem. "<liquidfuel>" needs to be replaced with "ship:liquidfuel", not just merely "liqudfuel". If that's not the problem then you'll have to show what you did to remove the "<" and ">" marks and give a pastebin of THAT.

Honest people know your characterization of my motivation is incorrect because they can read the thread and see that where we disagree is over the very point of whether or not the inclusion of the mod will affect other people or not. You can disagree with me all you want on that, and that's fine, but when you tried finding other more selfish motivations for my stance, instead of actually believing my claim that I don't agree with you about that premise, you stepped across the line into trolling. Disagreeing with me about my claim that it would affect other people is fine. Pretending I agree with you about that premise, so that you can ascribe other motivations instead to why I don't agree, is not. So I've had my say on it, and I'm done. Alamovampire was derailing the thread back when he first suggested including Mechjeb and rejecting kOS in a thread who's first post explicitly said not to talk about mechjeb, so I shouldn't have risen to the bait.

Has anyone tried using RayIntersection() ? It looks like it's almost exactly what I need, but it doesn't actually seem to work like I'd expect. You call it like this, apparently: body.pqsController.RayIntersection( origin, rayVec, out hitDist ) But the vectors origin and rayVec, when expressed in Unity World coords, give the exact same false hits that I'm getting from Physics.RayCast, and I verified that they are where I think they are by drawing a line with LineRenderer to see if the coords are what I think they are.... they are.

I get that. The problem is that I'm not actually aimed AT the planet and it's hitting it. that's not just a difference of scale - that's a difference in rotation, I think.

The things I've been saying only apply to the pre-release not the normal release. If you are using the normal release you'll get the V(0,0,0) problem. It's been such a long time since a full release that a lot of important features are missing from it.

Ah, so basically pqscontroller.GetSurfaceHeight(v) gets the height above sea level at the position that vector v's ray intersects the surface, assuming the vector's tail is origined at the body's center? The reason I ask is that getting the lat/long is actually quite indirect, while working in the world of unity 3d World coords is actually more direct and involves fewer conversions, given where I'm starting from. I was assuming I'd have to do the work to get it into lat/long terms. If I don't have to do that and can live entirely in the world of 3D coords that's great.

The reason it doesn't mention it on the previous line is that kerboscript, like most programming languages, does not constrain you to have to put an entire statement on the same line. Just because it failed to find a period at the end of a line doesn't mean its an error yet. It's not known to be an error because maybe the next line has the period on it, or maybe the expression wasn't over and it continues like so: WAIT 1 + y*3. Only once it gets to the first thing that isn't a valid continuation of the math expression can it be certain the period wasn't going to be coming.

I see hints that the thing called the "PQS" is what you use to get the terrain height for a body when the body is too far away for its terrain polygons to be fully loaded into Unity. (That seems to be roughly near 30-40 km altitude on Kerbin). Can someone point me to the right way to use it? Say for example, I have the following givens: a CelestialBody called 'b'. A latitude 'lat'. A longitude 'long'. Given B, lat, and long, how do I find the altitude of terrain at that position of the body?

okay so apparently it's on layer 10, which I *THINK* is the mapview layer... but....but... I'm not *on* the map view. So that's weird that it's seeing hits for it. At any rate I'll remove that from the mask list. I still can't figure out how to find a hit when the terrain polygons are unloaded for being too far away, but at least no hits is an improvement over wrong hits.

Line 41 doesn't look *exactly* like that in the body of the code you posted. It looks like this: WAIT 1 (Lacking the period (.) in the actual program.)

I apologise, my suggestion was misleading, as it seems. You can't set the PITCH of a direction after it's made. Directions are immutable and their components can only be GETted, not SET, and directions can only be changed by making a new one. So change this: set ship_relative_dir to R(0,0,0). set ship_relative_dir:pitch to 5. To just one line like this: set ship_relative_dir to R(5,0,0). Ironically, the reason I didn't say it like that the first time was that I was trying to avoid an error. I didn't want to make the error of getting the wrong part of the tuple for pitch. But I forgot you can't SET the pitch, so by trying to avoid giving bad advice… I gave bad advice.

Sadly, that's not going to work because they aren't off by exactly 90 degrees like that so you can just swap pitch for yaw. It might be that the x axis is, say, 20 degrees left of , and 30 degrees up from, your facing axis, depending. When your ship rotates, the xyz axes don't. When you move to a new position in orbit so that "east" isn't the same direction as it was before, the xyz axes don't rotate to match. (Sadly, they *do* sometimes rotate based on the completely hidden criterion of whether or not you're close enough to the surface to make the game want to render the individual terrain polygons or not, which is confusing as all get-out. When your altitude is low, it rotates the universe and freezes the planet's terrain polygons so it doesn't have to bog down animation rate by constantly recalculating their coordinates, but when you're high enough up that it replaces the terrain polygons with just a flat low-res image map, then it starts rotating the planet and freezing the universe. This makes it impossible to tell you which way the x and z axes are really pointing at any time because it depends on where you lifted off and where you came back down, at what times. A least if they were fixed it would be easier to explain.) I desperately want to add some features to help with this so that people don't need to use the native messy frame of reference if they don't want to, but we're on a feature freeze because of the upcoming KSP 0.24. This constantly recurring question by users about how on earth to use the native xyz system makes me see it as a big problem in need of fixing, and I have an idea how. SHIP:CONTROL is relative to your ship. THERE, the terms pitch, yaw, and roll do actually mean what they say. In the meantime, if you need to see a vector relative to your ship's facing you can do it with vector math and dot products. Get basis vectors of the frame of reference you want (forward, topward, starboardward) in the native XYZ terms, then dot-product them times any XYZ vector to get the terms in your own reference frame. Like so: // WARNING: This pair of statements will become one step after the next update and need to be // changed. This is because the next update contains a new fix that when you rotate a vector // by a direction you get a vector out (right now you get a rotation back which is silly). // This means that each pair of setting dir then setting Unit will need to be combined into just setting // unit directly after that fix goes through. // LOCK foreDir to SHIP:FACING * V(0,0,1). // The Z axis, after rotating to facing, becomes forward. LOCK foreUnit to foreDir:VECTOR. // *(see comment not above! IMPORTANT!) LOCK topDIr to SHIP:FACING * V(0,1,0). // The Y axis, after rotating to facing, becomes topward. LOCK topUnit to topDir:VECTOR. // *(see comment not above! IMPORTANT!) LOCK starboardDir to SHIP:FACING * V(1,0,0). // The X axis, after rotating to facing, becomes starboard. LOCK starboardUnit to starboardDir:VECTOR. // *(see comment not above! IMPORTANT!) // Now the 3 unit vectors can be used as basis vectors for you to play with, and with // dot products you can get those 3 components of any native-xyz vector: SET foreComponent to someVector * foreUnit. SET topComponent to someVector * topUnit. SET starboardComponent to someVector * starboardUnit. (Disclaimer - I didn't try running any of that example yet - I may have left/right swapped on the starboard one. the left-handedness of the coord system always trips me up.)

The terms "pitch", "yaw", and "roll" are a massively misleading set of terms inherited from the underlying Unity system (which is a generic game engine that does not know it's going to be used for actual flight, so it uses those terms in a way that is inconsistent with the actual flight of the ship). What they *should* be is Zrot, XRot, and YRot. They are Euler rotations around the native universe coordinates' x,y,z axes. The native xyz axes are not necessarily lined up with your ship's orientation at all. To transform them into rotations around the ship's actual facing, start from a transformation that gets into ship-facing mode, and then add the other rotations from there, like so: // say you want to pitch up by 20 degrees from where you are facing now: set ship_relative_dir to R(0,0,0). set ship_relative_dir:pitch to 20. set wantdir to ship:facing + ship_relative_dir. lock steering to wantdir. (disclaimer: I haven't actually tested the above suggestion) Be warned that if you LOCK STEERING TO SHIP:FACING + SHIP_RELATIVE_DIR directly without the intermediate 'wantdir' step you'll end up constantly resetting the desired direction to 20 degrees pitched from the current facing, as the facing changes, making the ship continually keep trying to change aim chasing its own tail. Also, be careful about doing the rotations separately to force the order you want. For example if you want to both pitch up 20 and roll left 15, you should have two different rotations - one that is pitch only and one that is roll only, and chain them together like so: set wantdir to ship:facing + pitchrot + rollrot. The reason is that Unity's native rotation system is hardcoded to do it in a weird order you wouldn't expect. It tends to do the roll *first*, if you combine them all into one tuple.

The problem is that while the main game code on github can migrate changes from pre-release branches into full-release later, the documentation system used, a thing called Middleman that I don't really understand, and was already being used before I started doing the documentation, is hardcoded to pick exact branch names for you, so you can't have separate development and master branches. The effect this has is that I cannot edit the documentation in pre-release and then later just migrate it over to full release when a release happens. If I make edits, it's either (A) not there, or ( there in public release. There is no in-between of "pre-release documentation exists but you have to switch branches to see it." So what you're reading is effectively the pre-release documentation. Because it takes time to type it all in, it's not practical to wait until full release before I work on the docs. I have to get started on it ahead of time in preparation for a full release. Much of what you see was written a few weeks ago under the assumption a full release was about to occur right then, but problems discovered last-minute made erendrake decide not to release after all, so for the last few weeks the documentation has been in this state where it's only correct for the pre-release. This has happened enough now (people asking where is the editor because the docs claim it exists but don't mention it's a pre-release only feature) that I think I'm going to address this problem after the next full release in the following way: Although Middleman refuses to let me pick my own branch names, I can simulate the idea of a branch by using a full github fork. So I just fork the entire documentation to a pre-release version and make the edits there, then pull them to the main one later upon release.

I've heard this is being worked on by others - that any Part in the system should be able to give you its coordinates.

That does not follow. There aren't two mutually exclusive competing ideas, both implemented, for how an alarm clock should work, for example. If there were, *then* arguing for including one in the stock game but not the other, like AlamoVampire did, would have the same problem. For the people arguing for just including every competing autopilot mod so you can pick one over the other by which part you attach to the craft, sure that would be fine if it would happen. I don't have the same level of optimism that it would be done in that fair-minded egalitarian way, though.

SAS-based steering is controlled by KSP itself not by the mod kOS. It causes KSP to override what kOS is trying to do. But what you can do is have kOS issue an SAS OFF command, then have kOS do some controlling, then have kOS issue the SAS ON command afterward when its done. This is unlikely to be changed, but the documentation should mention it, so I've made a note of it on the documentation issues page. It's late-binding language, which is the problem causing that error message to be thrown at run-time instead of compile-time. Basically, kOS traps exceptions and prints them out, regardless of whether they were thrown explicitly by the kOS C# code or thrown because C# threw a runtime exception in response to the C# code. What you're seeing is the actual C# exception rather than something the kOS code detected. So the problem is that if we exposed the line number in the exception, you'd be seeing the line number of the C# source code, not the line number of your own kOS script. I'm not sure how to fix that in a generalized way. I have an idea but it's a bit messy at the moment. But in a nutshell, the problem is caused by the fact that the C# code in kOS relies on the underlying system to detect whether a runtime conversion between generic object 1 and generic object 2 will work, and thus it doesn't have the ability to map the error to where it was in your own code. That's not a fix or an excuse - just an explanation of why it's a pain to fix it, and why it can't be a fast fix. The C# exception message itself doesn't tell you these things. I don't know why. Hmm... that's behavior inherited from KSP itself. It would be easier if it worked the way you say, but I'm not sure how to do it. KSP itself, whenever you switch ships, resets the global SAS flag to be whatever the persistence save of that ship recorded it to be. We have the same problem with the special keyword TARGET. Although each ship stores its target in persistence, and KSP switches the target when you switch vessel, at any one given time TARGET only tells you the current ship's target. A keyword for "whichever ship is active vessel" might be a good idea to add, alongside SHIP and TARGET. It should be valid. Can you post an exact snippet of the code and the error message? If it's not working that's a problem. I think the more elegant solution would be to make a third built-in variable alongside SHIP and TARGET. Something like PLAYERSHIP, that returns the vessel the player is currently active on. It would be a very quick edit to the code, (unlike trying to report where a cast error is coming from, which will take more work), and I could probably add it myself in a few minutes after I finish this post. BUT, be advised that the project leader erendrake is on a vacation for the US 4th of July holiday so any changes won't be public for a while even the easy ones. I've often thought there should be support for checking nulls, but currently there isn't, and kOS tries as hard as it can to never return nulls to people. But the alternative is to return a different KIND of thing, which I think is a problem. (i.e. if the object doesn't exist then return a string "none"), and that's a mess because then the kos script code has to deal with the fact that the type of the thing differs when the thing doesn't exist. At least with NULL, its a magic value that is always "the right type" and doesn't cause casting errors. But that's my opinion, and I don't know if that change will ever come. Yup that's is a bug. It's not supposed to be doing that. Thank you for reporting it. I'll add it to the github issues list (it would be simpler if you'd add issues there next time). Multiple types of KOS part is a thing we've wanted to do for a while, but basic bug fixes have had priority. I don't know the state of this, but I'd like to. One idea is to just add support for the mods that add more action groups (there's a mod out there that gives you like a hundred action groups to pick between. It would be nice if you could use them from kOS, going all the way up to AG99.) Yup. That's a problem. Yup. The terminal window with multiple CPU's is messy. Can you describe the behavior in more detail and post it to the github issues? (The link is on the first page of this thread). I'm working on one right now (a mod that is not part of kOS but is designed to work with it, to give you a laser line-of-sight rangefinder), here: https://github.com/Dunbaratu/LaserDist - The problem I'm having is that the ray-cast intersect finder is low level Unity and the KSP stuff on top of it doesn't always seem to match what's happening in Unity correctly. The only way to do it now is to take advantage of the fact that all the variables are global. Set a value in the program and then read it later in the program that called it. But yes, proper function calls would be a good thing I would like to have too, and it's a think we've talked about a lot. This supposedly already exists. You're supposed to be able to name files starting with the word "boot" in the archive, and then they appear in the tweakables choices for the kOS part in the VAB. Whichever one you pick is supposed to run after the craft loads onto the lauchpad. I say "supposedly" because I haven't gotten it to work myself. Supposedly that already exists, but it doesn't seem to be very good at it. The problems you're running into are all related to an area that hasn't received much testing yet - multiple vessels running code at the same time. Only just recently has docking become possible at all, and docking was the thing we were waiting for before multi-vessel issues really came up. If you encounter more problems please report them on the github. The more reporting the better.

Sure, if that could happen, but I'd put the probability of that at about 1%. Implementing both in stock is unlikely. What is more likely is implementing just one in stock and not the other, which is the situation I don't want. I'd rather leave the choice open than bias one choice over the other through bundling. Bundling kills the competition. Anyone who thinks it doesn't is unaware of the history of computing.

I'm one of the devs for kOS and even I wouldn't even advocate for making it stock, for the reason that I want to compete with the other choices for autopilot based on merits not based on cozy bundling with the base game - a strong marketing force that can override everything else about choosing a solution.

The rest of your post proves you are not telling the truth about this. If you meant it you could just choose not to "correct" my statements (which actually don't need correcting) and walk away. A claim that supports what I said about what you are doing - dictating play for others. You wouldn't be able to elect to unload it so it doesn't waste space in your install, and instead use kOS. And I heard the exact same argument from Microsoft back when they killed the superior Netscape by bundling the inferior Internet Explorer and splicing it into the OS in an un-removable way.