![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
Dunbaratu
Members-
Posts
3,857 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Dunbaratu
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
I've never been able to start a root part as anything other than a command core. The other parts are greyed out until you put a control part on. Has that behavior been changed and I didn't notice? -
I said it isn't because of that. IS NOT. Stop engaging in a strawman fallacy and trying to convince yourself I said the exact opposite of what I said, no matter how much mirth that strawman fallacy may bring you. And as to it just being an opinion of the way you play and everyone can just play their own way, my point which still stands is that the entire thread is ABOUT which mods should no longer be a choice but instead should always be present in everyone's game. There is an enormous difference between arguing why you prefer one autopilot over another for your own play, which is what you claim you were doing, versus arguing that it should be in the stock game so everyone should be required to have it installed too, which is what you were actually doing because of what the thread is about. And that's why there's always these arguments in threads about what should be stock. Because people *think* they're just saying "this is the way I like to play" when what they're *actually* saying is "this is the way the game should play for everybody." When arguing for what should be in stock, you *do* need to take into account whether or not the mod makes things mandatory which previously weren't, so you have to be very careful about what you suggest. I'm getting started with RemoteTech 2 and I like it, but I'd never recommend that it has to be in stock because that dictates people's play style and not everyone will like it. Whereas something like Kerbal Alarm Clock doesn't really dictate play style at all, and can be added without stepping on anyone's toes.
-
Yeah, let's just ruin the fun of those people who do like kOS by putting another autopilot in its way as the stock standard. The reason an autopilot shouldn't be stock isn't because autopilots are unrealistic, but because they should be a choice. Not just a choice about whether or not to have one, but more importantly, a choice about WHICH ONE to have - one somebody else made for you or one you make yourself. Most of these "these mods should be stock" threads are just a masked way of having an "everyone should play my way" argument.
-
Why does Unity's Physics.Raycast keep hitting Kerbin at the wrong angles? It doesn't hit Kerbin when aimed at Kerbin, and DOES hit Kerbin when not aimed at Kerbin. Here's some screenshots of what my laser distance measurer is reporting: (-1 is what I display when I get no hit). Note it DOES show a hit when not aimed at Kerbin, and does NOT show a hit when aimed at Kerbin. I have checked my logic and it's not just a case of inverting the logic, because it does work when hitting nearby objects like other vessels, and it doesn't *always* claim to be hitting Kerbin - just when I'm aimed near but not at kerbin. If I aim up at the sky it goes back to showing no hit. The distance of the hit is also rather weird, but I'm going to tackle that issue next. First I don't even understand why it's registering the wrong hit in the first place. (Rightclick the images and pick "view image" to see them at full-res, to see the text.) This is the call to Physics.RayCast(): if( Physics.Raycast(origin, pointing, out hit, maxDistance, mask) ) Where 'mask' is this: mask = (1 << maskBitDefault) + (1 << maskBitWater) + (1 << maskBitPartsList) + (1 << maskBitScaledScenery) + (1 << maskBitLocalScenery) + (1 << maskBitKerbals) + (1 << maskBitDisconnectedParts) + (1 << maskBitPartTriggers) + (1 << maskBitWheelColliders) + (1 << maskBitTerrainCollidres) ; and those bit fields are these: private int maskBitDefault = 0; private int maskBitWater = 3; private int maskBitPartsList = 8; private int maskBitScaledScenery = 10; private int maskBitLocalScenery = 15; private int maskBitKerbals = 16; private int maskBitDisconnectedParts = 19; private int maskBitPartTriggers= 21; private int maskBitWheelColliders = 27; private int maskBitTerrainCollidres = 28;
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
The problem is that the node needs to actually be attached to the vessel's flight plan before you can apparently move its ETA, it seems. That's a bug to be reported. You should be able to adjust the ETA and then attach the node, although it seems like a weird way to do it it should be legal. For maneuver nodes, the name of the suffix is the full spelled out word "ORBIT". Only for Bodies is it the abbreviation "OBT". This inconsistency comes from having different people work on different parts of the system. I think the fix probably going to have to be to allow either spelling everywhere, to keep things backward compatible. How the heck did you make the lab be the root part? It's not an allowed command module in KSP (you can't pilot from it). -
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
That wiki should be considered dead. It was only ever maintained by the fans rather than the developer, so most of what it said was raw guesswork, and the new dev team has more official documentation here: http://ksp-kos.github.io/KOS_DOC/ If anyone else feels like updating the wiki, go right ahead, but I won't be doing it as that would mean writing the same thing in two different formats. -
If that's true then the Unity documentation needs fixing because it says "parents" rather than "ancestors", implying it doesn't go more than one generation up (it doesn't say "grandparents"), and that perhaps the reason it's a plural is because they're violating the tree structure a bit and giving some nodes more than one parent. I never wrote any examples using Part.FromGO. I was trying to work out whether or not GetComponentInParent worked like you showed it working or if it worked like the both its name and the Unity documentation implies. By using the word "Parent" rather than "Ancestor", it carries the meaning that it only goes one level up and stops. That terminology *means* something in computer science and it appears Unity is using it slightly wrongly, if what you're saying is true. At any rate, Unity's documentation isn't your fault. Thanks for the information.
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
Hmm. No but it might be possible to add it. -
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
The reason for "hello world" being the most common starting point is that it requires no explanation of the language and is immediately obvious just looking at it what it does. This frees you up to examine the other surrounding details about the system like how to write the program, how to compile it, how to run it, where the code gets stored, how to get the system set up, and so on. If you look at the hello world example I wrote, its not really teaching how to use the print statements. Its teaching how to edit and where the archive is and the local volume and so on. These are basic things people have had problems with in the past that trip them up and prevent running any sort of program at all. As to being intentionally terse, its not. Its just a question of where to spend the time. When BOTH the examples AND the reference information aren't there yet the reference information is the first thing to write. Get it right first because tutorials without complete ref docs is even less useful than ref docs without tutorials. Thats what we had before version. 0.9 and it was painful to use. -
What documentation? It's not documented. I have to guess from the name of the method and its signature. Wait, so are you saying that Part.FromGO() does NOT scan through the children of the Part's game object to see if the GO passed in is contained inside the part's GO? That it only works if the GO passed in is at *exactly* the tree depth that the Part object is connected to? If so then what you posted wouldn't work either, would it? It only works if the tree structure looks like this: ... | +-- GameObject | | | +-- A KSP part | | | +-- GameObject A | | | +-- GameObject B <-- ray cast hits here. | | | +-- GameObject C | … It doesn't look like it would work if KSP modeled the part in a more complex way with grandchildren or great-grandchildren, like so: ... | +-- GameObject | | | +-- A KSP part | | | +-- GameObject A | | | +-- GameObject B | | | | | +-- GameObject BA <--- ray cast hits here | | | | | +-- GameObject BB | | | +-- GameObject C | … Isn't a tree walk upward still needed to handle that case? Or is there some guarantee that KSP never models any of its parts that way - that they all have exactly one level of depth only and no more?
-
Ship:facing:yaw:vector doesn't work because ship:facing:yaw is just a single scalar number. I can't even guess what result you were expecting here. Did you want a vector pointing out the side of the craft? I'm just trying to figure out what you had in mind. If you want a vector pointing out the side of the craft (again I don't know if that's what you want. I'm trying to guess), you can do: Now, before erendrake releases the version with the direction*vector fix in it, you have to do this: SET sideDir TO SHIP:FACING * V(1,0,0). SET sideVec TO sideDir:VECTOR. Soon, after erendrake releases the version with the direction*vector fix in it, you will have to change that to this simpler code: SET sideVec TO SHIP:FACING * V(1,0,0). (The bug is that multiplying a rotation by a vector should rotate the vector and return it, but currently it rotates the vector and then converts that back into a direction and then returns that, so you have to convert it back to a vector again, thus the extra line of code difference between the two examples above.) Using this rotate-a-vector method to get a vector relative to the ship's orientation works like this: Use the X axis for left/right sides. Use the Y axis for top/bottom sides. Use the Z axis for fore/aft sides.
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
Two good ways to do that: 1: Use the definition of acceleration - change in velocity over time: Presumably you have a big loop during the flight: use it to record the previous iteration's velocity vector and previous time:seconds. Then do a vector subtraction of the current and prev velocity vectors, and divide by the delta time of current time:seconds and prev time:seconds. Keep in mind the 'frozen update' problem if you do this and make sure you take your measurements immediately after a "WAIT 0.00001" statement. 2: Put the science instrument accelerometer on your craft. Then you can query SHIP:SENSORS:ACC to get it directly from the KSP Api. Warning: this doesn't seem to adhere to the CPU vessel convention, and IMO that's a bug that needs to be fixed, but as long as you're running the code on the active vessel only it should work. (snipped hexdump) I'll see if erendrake can deal with that when he gets back. Not to sound rude, but I don't have the patience to deal with the weird way you're posting the reports, where I'd have to go around installing extra tools to extract it. I don't want to deal with the old days of usenet and having to uuencode everything, and this feels like very much the same thing. There's plenty of places that you can host a binary file. -
@xEvilReeperx - It looks like the existence of the Part.FromGO() static method, and it's purpose, is what I was missing. So much undocumented stuff in KSP's API.. sooooo annoying at times. They appear to have included very little explanation in their xml-comment tags so most of the documentation is fan-made by guesswork and trial and error. "Some sort of way to get the Part that a Unity GameObject is a component of" is exactly what I needed and it looks like that's exactly what that does.
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
Sadly I just discovered as part of the documentation update when I walked through all the structure's Csharp code by eyeball, that it looks like SHIP:SENSORS is violating this rule. It checks whether or not the current CPU Vessel has the right sensor, but then if it does it pulls the data from the flight globals for "current state", which of course KSP thinks of as the where the "current vessel" is, not the CPU vessel. That was the only such place I found, though. -
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
I just finished a major walk through the documentation adding a lot of missing stuff and making sure all the suffix fields are in the same format, with the same information about them. Documentation link: Important updates in that documentation: * All suffix terms explicitly mentioned, after a long walk through the code. * I had a page for the LIST BLAG IN FOO command and had never realized that it had never been linked to from anywhere and was never included in any of the git commits so it was missing from the public site. No wonder there were so many questions about how you get to the Engines and so on. * Better organization of the inherited things like Orbitable->vessel and body, and Part->Engine and DockingPort * List of bound variable names and what they do. Important since so many of the things you do in kOS are done through these variables. * More structure pages have examples, and all of them mention how you go about getting an instance of the type in question. I didn't like doing this but there weren't good places to put that information some of the time. * Removed very misleading sentence from the front page that obfuscated the difference between instances of structures (i.e. SHIP, TARGET) versus the structure itself (i.e. VESSEL). Once upon a time the structures list was a mishmash of SOME things being something there can be multiple instances of and SOME things being hardcoded structures there was only ever one instance of. That sentence was causing undue confusion, I think, and must have been leftover from a much older version of kOS and never removed. -
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
I haven't done it for that purpose, but I did make a simple docking script and then test that it functioned while I was focussed on the target vessel receiving the dock rather than the vessel running the docking program. It should work, but the vessel running the code does have to be fully loaded into the physics engine or the kOS computer won't be given any update notices by KSP, and it will freeze execution. (In other works, the kOS CPU has a clock speed of zero while the vessel is on rails, so it's not particularly useful unless the other vessel is near enough to stay fully loaded.) We went through and tried to diligently find all the areas where the old Kevin Laity code wasn't making the proper distinction between the CPU's vessel and KSP's current active vessel, and tried to fix all of them. I hope there aren't any we missed. -
I have a laser distance measurer that does a ray cast and returns the distance to the first item the laser hits along its beam. Finding that distance works great. But now the problem is that Physics.Raycast is a Unity routine at a low level underneath KSP. Thus when it finds a hit object, the hit object it finds is a low level Unity primitive like "Cylinder". But what I'd like to report to the user is the name of the KSP object that was hit. i.e. not "Cylnder" but "FL-T200 Fuel Tank". I know that I can walk up the tree of GameObject's, as in "this object is part of this other object which is part of this other object which is….". The problem is that I don't know how to detect when to stop that walk. Ideally what I'd like is a flag that tells me "this GameObject is one of the GameObjects the user sees in the user interface, like a Part from the parts bin, or a building name, or a planet name, rather than a low-level primitive they never see like "terrain polygon na039103r12"
-
[1.3] kOS Scriptable Autopilot System v1.1.3.0
Dunbaratu replied to erendrake's topic in KSP1 Mod Releases
engine is a type of variable, not the name of a variable. You get a list of them with LIST ENGINES IN MYVAR. For what you want, try this: lock throttle to myvalue. // pick a myvalue in the range 0.0 .. 1.0 print "cur thrust is " + ship:maxthrust * myvalue. works if all engines are liquid fuel. solid fuels are maxthrust regardless of throttle so that doesn't quite work if you have any of them. -
Acquiring a position vector
Dunbaratu replied to Felger's topic in KSP1 C# Plugin Development Help and Support
Space Kraken. The problem is that while centering the universe on the Sun is mathematically elegant, it's not so elegant when dealing with floating point representations of numbers in a computer which have a fixed limit to the number of significant digits they can represent. Because they're stored with a mantissa/exponent format, with a fixed number of significant digits in the mantissa, the precision gets worse the farther from zero the numbers are. At zero you have the ability to store the difference between 0.00000001 and 0.00000002 meters. But when those numbers get big and you're talking about a billion meters, then it's a problem that you don't have that precision anymore. Trying to calculate whether or not your fuel tank has collided too hard into your command pod when the numbers you're using to perform the calculation have to be rounded to the nearest 10 centimeters or so tends to make your ship blow up. It tricks the system into thinking the part has suddenly moved really fast in a fraction of a second as it "snaps" to the next available number. Thus ships used to just unfairly blow up when you started getting too far from the sun and the position values became less precise. Moving the origin of the universe to always be near the ship is how SQUAD fixed that problem. The thing I don't understand is why the *rotation* of the axes had to be made to change all the time. -
Erendrake, the current leader of the kOS project, has expressed a strong interest in getting kOS and RT2 to work better together. In principle they should get along well - they seem to perform useful complementary activities. RT2 to control the delay and connectivity with telling the craft to run commands, and kOS to run commands once it gets to the craft. But in practice there's been problems with kOS having a hard time getting RT2 to allow it to 'sanction' all the things it wants to control on the craft. I don't know where the state of this situation is at the moment, and Erendrake won't be around to ask for the rest of the holiday weekend (well, holiday in the US, anyway).
-
Acquiring a position vector
Dunbaratu replied to Felger's topic in KSP1 C# Plugin Development Help and Support
Yes. I consider the orientation of the world reference frame odd. When I say "odd world references" I mean "what KSP chose to tell Unity to use as the world coord system, which keeps changing orientation." -
Yes it's 0.23.5. I think you're right about the cause of it. I think the root of the problem is that the user contracts are not stored in a per-savegame way, so when a new savedgame is started (which is exactly what I was doing, yes), it tries to bring up the previous user contract that's referring to things that don't exist in the new game. (that doesn't seem to be true anymore, never mind) IMO if the user contracts refer to things that only exist in one of the saved games it sort of makes sense for it to not be quite as 'global' as it is. Is there a way to just delete the pending user contract entirely so it stops trying to bring it up and starts afresh? I think that would be easier than trying to name a new asteroid to match the one in the mission from an older game.
-
Yes but only after the problem started happening, hoping it would force the plugin to recreate it (which it did, by the way). The missing file is not the cause of the problem because I only removed it after the problem happened and the problem looks identical now to what it looked like before I did that. Can you just tell me what the section for the user contracts window is *supposed* to be called? Then maybe I can manually add it to the config.xml file [edit] It seems to be bombing out when trying to do something called: System.Collections.Generic.List`1[MissionController.AsteriodCapture].get_Item So I now think that what's happening is that it's trying to bring up an old user mission (an asteroid capture) that's no longer valid so it dies before it finishes drawing the window. If I can find where that is stored in the save file I'd just get rid of the leftover record of that mission so it stops trying to bring it up.