Dunbaratu

You can get the constant e this way: print "Value of e is " + constant():e. Any value can be exponented with "^", so you can do: (constant():e)^x. I just saw that constant() is missing from the docs as well. I added it as an issue.

I had no idea it was that badly documented before I got my hands on it. The parameters aren't mentioned at all. I'll add it to the TODO list. It's not due to being out of date. It's just not well documented.

New release: https://github.com/Dunbaratu/LaserDist/releases/tag/v0.2 This has a crudimentary PQS terrain solver. It's still not perfect and occasionally does not register hits. That's because the computation expense of getting it perfect is not something I'm willing to burden the game engine with (it would take about a thousand iterations to be sure it always worked perfectly) As it is, I only use 100 iterations, which can cause it to occasionally miss a mountain because it falls in-between sample points of the algorithm.

My VIM syntax highlighting is a bit out of date because I have to manually update it every time the main kOS mod adds new keywords, new syntax, or new bound variable names or new suffixes. So it's a pain to keep it up to date. It would be nice to be able to query that sort of data from the mod directly so it's possible to update it automatically, but right now that's not the case.

Tigermisu was talking about undefined variables, which is slightly different from a variable which is defined and who's value is null. For example this code works: set x to 7. print "value is " + x. But remove the 'set x' line and it errors out: // set x to 7. print "value is " + x. The question was whether there was some way to do a thing like this: if isdefined(x) { print "value is " +x. } else { print "x doesn't exist yet". }.

Ugh. Yes, technically possible. But the Mun's SoI is a pocket inside Kerbin's SoI which is a pocket inside Sun's SoI. So using the technique you describe, a point inside the Mun's SoI would register 3 SoI hits - one for Mun, one for Kerbin, and one for Sun. I'd have to be careful to always make sure that of all the hits I get, I use the one that's at the lowest tier of the tree structure of bodies.

I don't know if this has been mentioned yet or not (I am *not* reading through 106 pages to find out, and a text search of the thread didn't seem to find anything mentioning it). This may be important for people to writing mods trying to support Linux to know. In the kOS mod, some users discovered that the RETURN key wasn't being read by kOS on Linux (pressing RETURN after typing a command is essential for the mod to be usable at all so it effectively blocked all linux users from using it). We've squashed the bug now, but it turns out to have been due to the Linux build of Unity itself, and we had to make an ugly work-around to deal with it. That Unity bug is this: - The correct unicode character for carriage return is 0x000d. - But on Linux, when you call Event.current.character, it returns 0xff0d for carriage return. I think it may be related to control characters in general, because some people were having the same problem with the tab key, and it seemed to be giving a unicode of 0xff08 instead of the correct 0x0008. However, it's not a universal problem with all the low unicode characters (the ascii part of unicode) - only a few special control characters were being padded with 0xff instead of 0x00. Most characters are being padded with 0x00 correctly. Anyway, the workaround we used was to funnel all uses of Event.current.character through a function that looks for when the high byte of the unicode is 0xff, and if it is it turns it into 0x00 instead. There's *hopefully* no keyboards out there that actually use the unicode characters in the range 0xff00 through 0xffff so this should be okay. I posted about the problem over on the Unity forums and it seems to definitely be a bug in Unity. It's not supposed to be doing this.

What the title says. I'm looking for an API method that will let me pass in a position vector (expressed in Unity World Coordinates), and tell me which body's sphere of influence that position is in. I can ask what sphere of influence a vessel is in, but this isn't necessarily a vessel's position - it's just an arbitrary position in space. (Background: I'm trying to make a homemade raycast algorithm that works to find where a ray hits the body's terrain, when the intersect in question is far enough away that the terrain polygons are not loaded so I have to use the PQS controller to get the terrain data instead of using Unity's Raycaster to hit the polygon. One important part of that algorithm is to simply figure out which Celestial Body the ray's origin is located in in the first place.)

Oh, by the way if it's going to take you a while to get around to this, no hurry. I'm not in a position to be ready on my side to implement it yet anyway, as I'm working on other bugs first. Just remind me with a PM when you've got something for me to try.

Has anyone reported this as a bug to SQUAD? It seems pretty major, given that PartModule has API methods to be called for OnSave and OnLoad, to have a situation where you can't actually persist the data. Have you tried looking at the persistence save file on disk to see what it's actually writing out when you save and quit the game? That might give clues about what's going on, since it's normally supposed to store the PartModule's data that way when you load/unload a vessel. For example, here's a snippet of a vessel in the savefile that has a kOS part on it - this is the part of the file storing the kOS computer part: PART { name = kOSMachine1m uid = 3130583856 mid = 3160650642 launchID = 0 parent = 1 position = 0,-0.461709976196289,0 rotation = 0,0,0,1 mirror = 1,1,1 istg = 0 dstg = 0 sqor = -1 sidx = -1 attm = 0 srfN = None, -1 attN = bottom, 3 attN = top, 1 mass = 0.12 temp = -175.5791 expt = 0.5 state = 0 connected = True attached = True flag = Squad/Flags/default rTrf = kOSMachine1m modCost = 0 EVENTS { } ACTIONS { } MODULE { name = kOSProcessor isEnabled = True diskSpace = 10000 MaxPartId = 100 RequiredPower = 0.1 EVENTS { Activate { active = True guiActive = True guiIcon = Open Terminal guiName = Open Terminal category = Open Terminal guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } TogglePower { active = True guiActive = True guiIcon = Toggle Power guiName = Toggle Power category = Toggle Power guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { Activate { actionGroup = Custom09 } Deactivate { actionGroup = None } TogglePower { actionGroup = None } } harddisk { capacity = 10000 volumeName = } context { variables { gt0 = 1000 theta0 = 0 gt1 = 50000 theta1 = 90 maxq = 7000 solidthrust = 1000 liquidthrust = 430 b = Kerbin mu = 0 rb = 600000 soi = 84159286 ad0 = 1.2230948554874 sh = 5000 ha = 69077 lorb = 80000 euler = 2.718281828 pi = 3.1415926535 tset = 0.0339023084802981 ralt = 31.9084739685059 tign = 158.499999999858 t0vsm = 1592.02330798716 t0 = 1753.00213134636 drag = 3.55079036339349 theta = -89.9998993748686 ar = 53151.25 dt = 51.054667705775 vsm = 1595.21901562825 exp = -10.6302496743923 ad = 2.95665986071201E-05 q = 37.619412217597 vl = 6300 vh = 7700 dv = 25.317020411188 da = 3.15866273197437 ta = 26.155287415735 ga = 8.28037904523618 dc = 0.0107218905712116 arr = 0.999326849489796 pda = 1.11805701491496E-06 alt = 80000 vom = 1709.09521461651 r = 669089.06619147 ra = 680070.156316288 va = 1658.47870757092 a = 462533.177782449 r2 = 680070.319430686 a2 = 680035.159715343 v2 = 2278.73482559418 deltav = 620.256118023264 x = NODE(1875.23204280658,0,0,620.256118023264) nd = NODE(1875.23204280658,0,0,620.256118023264) maxda = 26.2232454284736 dob = 23.6528898527336 t1 = 1863.40559788021 oldwp = 0 rt = 0.232024883524446 wp = 0 tvar = 0.101480078682016 np = R(0.024,194.344,0) } } } RESOURCE { name = ElectricCharge amount = 4.99933333330167 maxAmount = 5 flowState = True isTweakable = True hideFlow = False flowMode = Both } } In your case, is it not even saving the MODULE section at all to the file? If so then that's the bug, and that's how it needs to be complained about to SQUAD, I think.

I think erendrake should look over this issue, as he's more experienced with how you do Reflection in C#. Let's leave the question of whether it's cut-n-paste alone for the time being. I'll bring it up with him later. It's a common means of making a static method behave LIKE it was a dynamic one. If you pass in a reference to 'this', and have the static method use that 'this' reference, you can make the static method operate on that instance of the object. For example: // a non-static function that prints the fields myField1 and myFielld2: public void PrintStuff() { Debug.Log( myField1 + ", " + myField2); } // The same thing done with a static function instead: public static void PrintStuff2( TheType theObj ) { Debug.Log( theObj.myField1 + ", " + theObj.myField2); } // Now, instead of saying: // this.PrintStuff() // you can get the same exact effect from: // PrintStuff2( this ); The point is that it lets you use a static method in places where it's required (like a delegate callback), while still actually operating on the instance of an object rather than operating globally like static methods usually do. In this way I wouldn't have to add your member function to my class with cut-n-paste. Instead I'd call your static method, and pass it a reference to my class instance ('this'). Hmm... that will be a problem with kOS. We've been trying very hard to make it possible to run kOS scripts on more than one vessel at the *same time* without switching between them with the '[' and ']' keys. (So you can have two vessels, each running a docking program, where each vessel helps point itself toward its partner vessel, for example - or have two vessels leapfrogging over each other across the landscape, for example, or launch two robotic fire-and-forget missiles and have them both flying at the same time.) To accomplish this, we had to almost entirely eradicate "FlightGlobals.ActiveVessel" from our thinking - because the vessel on which the kOS script is running cannot be assumed to always be the vessel the player has active. Granted, it typically does have to be within 2.5 km of the active vessel, or it gets unloaded and kOS can't function, but it should be possible for vessels near enough to your active vessel to be loaded to be running kOS scripts. Thus we'd need for there to be some way to tell AGX which vessel we meant. We can't just always assume a kOS script is running on the ActiveVessel. Yeah that seems fine.

Hmm, I'm not really clear on why we have to cut-n-paste code in the first place, rather than calling a method from your DLL. Is it because you didn't want to make the method Static? I think it would be a lot cleaner to have a static method we have to pass-in the reference to our "this" as an argument, rather than cut-n-paste code from you to us. i.e. this: AGExtToggleGroup(this, 1). // toggle group 1 on me. As to needing 3 different methods, I really think you can collapse the Activate and Deactivate into one method that takes a boolean like so: AGExtSetGroup(11, true); // activate group 11. AGExtSetGroup(11, false); // de-activate group 11. (or if you use the static method passing "this", as shown above, it would be:) AGExtSetGroup(this, 11, true); // activate group 11. AGExtSetGroup(this, 11, false); // de-activate group 11. I'm not really a C# expert. I only started using C# *because* wanted to join the kOS devs. Prior to that I did do a lot of Java and C++, though, so a lot of what C# does was immediately intuitive and obvious to me as it borrowed from those two languages extensively. But it is a bit less flexible about a lot of things, in ways that I find annoying and arrogant on the part of Microsoft ("because there are ways to misuse this language feature, we'll disable it, thus preventing all the legitimate good uses of this language feature too").

It's possible that Squad did do something to fix the PartModule loading problem in 0.24, but that what they did might require a code change that wasn't properly explained to modders when it was released, so the problem is improved in the stock game's PartModules, but is ironically actually making the problem effectively worse in mods that still do things the old way. Sadly, because kOS has always had messy problems with the kOS computer state (i.e. variables in the pretend computer's memory) not reloading correctly, the fact that it doesn't work right after 0.24 tells me nothing - because it was buggy before 0.24 already. Does it only seem to affect cases where people dynamically added the PartModule at runtime to the part? Does it work okay for cases where the part.cfg file itself is hardcoded to use the PartModule? (that's the case for kOS and LaserDist - the two mods I've had my fingers in - kOS CAN be added to a part with ModuleManager, but only if the user does it themselves - the mod no longer ships with those configurations enabled because we had too many problems with it even in the past.)

Ah, then technically it should be possible to do it with the API that's there already (although I do think it would be a really good idea to change the name of the AGExtActivateGroup() method to AGExtToggleGroup(), which shouldn't be a problem with backward compatibility if nobody else but me has looked at your API yet). If I have access to a toggle method and a query method, then I can use them together to implement a "set to true" and "set to false", as follows: newVal is the new desired value for the action group, either True or False: - If (query-the-action-group != newVal), then toggle-the-action-group. - else do nothing. Thanks for the information. I'm normally reluctant to insert code into kOS designed to *specifically* support exception cases for another particular mod, because I think that crosses a line that can be dangerous given the vast plethora of mods out there. If each pairing of mods had merely 1 line of code in either of the mods of the pair that makes one exception for the other, that would cause the existence of N factorial number of lines, where N is the number of mods existing. It's the full-connectivity network graph problem. But, action groups are *SO* integral to using kOS and *SO* tightly connected to it, that I think making an exception to enable more action groups is worth it.

I wish I could help about the popup editor in Linux but really don't have control over it - the popup text editor is really a Unity GUI TextArea widget, that Unity itself is supposed to do all the hard work to make it function right (although in practice I did find that I had to override a lot of what it was doing to get some basic functionality it was missing, like the pagedown and pageup keys). The point is that the proper capturing of keyboard focus isn't even mentioned in the kOS code at all because it's supposed to be being done by the Unity widget itself already. The difference in behavior between Linux and Windows versions seems to be one of input stacking order, as it were. In Windows the TextArea sees the key event first and only if it doesn't consume it does the key event pass "through" to the rest of the game. In Linux, from the description, it seems that the main game is seeing the key event first and only if it doesn't consume it does it pass "through" to the GUI TextArea widget. It's as if the "stacking order" isn't the same.

Hmm.. the stock action groups operate by being settable to true OR settable to false by passing in a boolean flag. When you press the action group hotkeys 1-9, they actually in fact TOGGLE the action group's state. (If you press 1 twice, action group 1 goes from false to true to false again). kOS makes use of that by binding the action groups to magic variable names, so you can, for example do set AG1 to true. set AG1 to false. I'm not sure how to implement something like set ag11 to false with what you're describing. I can activate it (set it to true) but how do I de-activate it?

I'll take the conversation over to there then, so it doesn't clutter up this thread. Thanks for the reply.

Some kOS users just found one today. I don't think I'd ever heard of this complaint before 0.24 so it might have been introduced with the Unity engine update underneath 0.24. In 0.24, the Unity engine underneath is returning the wrong values for some keypresses when you examine their unicode char values. When processing a Keydown event, Event.current.character is supposed to be the unicode character corresponding to the keypress. But on specifically the Linux build, and the Linux build only, the RETURN character, which should be producing the unicode character 0x000d (ascii 13, CR, with leading zero high byte to turn it into unicode), is actually being returned as 0xff0d instead of 0x000d. (the padded high byte of the unicode character is all 1 bits instead of all 0 bits). Thus checks like this: if (Event.current.character == 13) { do stuff } don't work right on the Linux build. Because the character is coming back as 0xff0d instead of 0x000d, it's not the value 13(decimal), it's the value 65293(decimal). I made the workaround of detecting if the high byte of the unicode is exactly FF, and if it is, then replace it with 00 instead, figuring that none of the unicode characters from 0xff00 through 0xffff are actually characters that would ever correspond to a key on any keyboard in any language. (They're full-width line-drawing font characters for use when you want to print characters that touch each other edge-to-edge without any space between them, like for box drawing. They're not characters that exist on any keyboard, unless you've somehow managed to run Kerbal Space Program on a Commodore 64.).

@Diazo I'm looking at the kOS integration issue from the kOS side of the code. This is the pair of standard KSP API calls kOS is using for action groups. I'll give the example for stock action group 10: To Set: someVessel.ActionGroups.SetGroup(KSPActionGroup.Custom10, (bool) val); To Query current setting: bool val = someVessel.ActionGroups[KSPActionGroup.Custom10]; Can you provide examples of the same two operations as they would be used for one of your extended action groups (Is it as simple as just changing the "Custom10" to "Custom11" and "Custom12" and so on for the extra action groups, or is it more complex than that?)

@jaunasse @kafuka I just uploaded a new experimental DLL to the same google drive location ( https://drive.google.com/folderview?id=0Bxkeai7oN35fY1cyeXNNTkNnX3c&usp=sharing ) Hypothetically this workaround might fix the Linux RETURN key problem, but I can't test it myself to see. Can you give it a try and see if the special characters work (try RETURN and whatever else was failing before). I haven't put it on github yet because I'm loathe to commit code I haven't tested myself, but if you report that it works I'll trust that you're right and commit it. (Note, that DLL also still has the verbose debugging logging enabled too, which would not be there anymore when I commit it for real.)

Well on the Unity forums I got confirmation that someone else got the 0xff0d bug for Linux as well, on something that wasn't KSP, so it's in Unity itself and thus not likely to be fixed any time soon in KSP. KSP doesn't tend to release public patches just to link with a new Unity update, so that means even if Unity fixes it we in Kerbal land will be stuck with it until at least KSP 0.25. So I'll make q pull request with a work-around in kOS, and see if erendrake would be willing to make a pre-release for it. Preventing an entire OS platform from using the mod at all due to something as petty as a keycode mapping is a pretty serious bug, as far as I'm concerned. My work-around will be to simply assume that there's no such thing as a valid keypress event that sends a unicode character in the range 0xff0 through 0xffff, since those are all for drawing specialized super-wide version of normal characters on the screen (and are thus for visual output purposes, not input purposes). Thus if I see any keypress with a unicode value starting with 0xff, I'll clobber the ff with 00 first before continuing on. EDIT: Out of curiosity, what happens if you type CTRL-M instead of RETURN? Does that cause it to send the actual correct 0x000d?

On the Unity Forums I had someone just ask me if it gives the same results in the 32-bit version for Linux. Can you try both the 64-bit and 32-bit and see if they differ? I can't perform the test myself, as previously stated.

That is definitely the problem. The return character is supposed to be just 0x0d (or 0x000d to format it the same way with the full unicode 16 bits). When ascii characters are mapped into unicode, they're all supposed to end up with 0x00 prepended to them, not 0xff. The unicode character 0xff0d is NOT return. It's the long-bar hyphen that consumes the full width of the character cell. I have no idea why the Linux implementation of Unity is returning 0xff0d for Return instead of 0x000d. At the moment I'm confused and I've made an account over on the unity forums to ask why this is happening and what I'm supposed to do about it.

All KSP mods are written in C# (or at the very least, another language that also uses .NET or Mono so it can call the same API routines as C#). One of the features of this is that when they're compiled to a DLL, the DLL isn't *really* machine language like old-school DLLs in Windows used to be. It's much more like how Java Classes work. The DLL contains opcodes in a hardware-abstracted psuedo-machine-language that won't be converted into actual machine language instructions until runtime. What this means is that the mods' DLLs don't really contain 32-bit or 64-bit code. They're abstracted generically. The act of turning them into 32-bit instructions or 64-bit instructions happens dynamically when you launch the game. This is why the mods' GameData folder doesn't have a separate _x64_ version of it for the 64-bit mods like KSP_Data does. In principle, the mods shouldn't care whether they're being run 32-bit or 64-bit. It's only when doing something deeply hardware-specific (like mucking with the OS timings, or communicating with video cards' hardware acceleration) that the difference matters, thus Unity needs work to be 64-bit compatible, but the mods generally don't.)

I'd thought of how it would be nice to combine this with Infernal Robotics to dynamically aim the laser. I'm glad someone wants to pursue that and I'd love to see the results. As to how to read the vector, what I'd rather do is instead of making an exception for LaserDist, make it so that kOS can read the orientation of *any* part. It's already possible in kOS to apply a Rotation to a Vector, so if you could read the orientation rotation of any generic part, then in principle it would be possible to get the rotation transform of the LaserDist part, then apply that rotation to the unit vector V(0,-1, 0) (negative Y is the default "down" orientation of the laser before it is rotated by the part's current transform). erendrake and I were discussing this and it is a thing we want to do - be able to read position and orientation information of any part on a vessel.