Dunbaratu

You should never have to create the output_log.txt. It's supposed to be created automatically by KSP itself. [ EDIT: Some web searching showed me that this is actually a platform difference that comes from Unity itself. Unity stores the log in a different location depending on the OS platform. ] According to another post elsewhere on this forum, For Linux: The log is written to somewhere under here: ~your_username/.config/unity3d/Squad/Kerbal Space Program I hope you can find it somewhere there, or in one of the subdirectories of that location.

This is the algorithm I'm planning on using to solve the PQS terrain hit problem (the fact that Squad appears to have never implemented an API function to find a ray intersect with the PQS terrain - They did create several API methods that seem by their name to do this, but upon using them I've discovered that despite their name they actually just find the intersect with the sea-level sphere of the planet, ignoring the PQS terrain entirely.) Given a point in space, I can query KSP and ask it to tell me the PQS terrain below that spot in space. But the math being used to generate that answer is proprietary and hidden, so I can't solve for the intersect of a ray with the terrain surface function analytically (the math would probably be too ugly to do that anyway even if I could see it). I have to solve for it using a numerical algorithm that approximates the answer. This is how I'm going to try doing it: If I really wanted to be clever about it and reduce computational expense, I could try to take advantage of the fact that I know that from one animation frame to the next, the correct answer must necessarily be very close to the previous animation frame's correct answer, and therefore start the outermost recursion level with an 'i' just one step away from the previous 'i' that hit. (i.e. if on the previous animation frame, I found the hit in slice i=7, then on the next animation frame, don't start with slice i=0, start with slice i=6, on the assumption that in one animation frame its possible for the correct hit to move across the boundary from one slice to the next, but not possible to move as far as two whole slices in a mere tenth of a second or less.)

@jaunasse, @kafuka: I put the DLL on the following Google Docs share drive: https://drive.google.com/folderview?id=0Bxkeai7oN35fY1cyeXNNTkNnX3c&usp=sharing To perform the keycode test: 1 - Rename the existing GameData/kOS/Plugins/kOS.dll file to some temp name that does NOT have a 'dll' extension. (KSP tries to load any and all files that end in ".dll" in plugin directories on launching, so if you renamed it to something like "origKOS.dll" then KSP would still try to load it.) 2 - Copy the kOS.dll file from my google drive URL given above into GameData/kOS/Plugins/kOS.dll. 3 - Run KSP, launch any kOS vessel and open the kOS terminal, and try the exact keypresses shown in the screenshot below. 4 - Quit KSP. 5 - Open the output log file in your favorite text editor of choice. If you are running 32-bit KSP, it will be located here: KSP_Data/output_log.txt If you are running 64-bit KSP, it will be located here: KSP_x64_Data/output_log.txt 6 - Post the relevant section of the output_log.txt file. For reference, here's the relevant section from my test: (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x48 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000065 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x45 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000006c (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x4c (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000006c (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x4c (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000006f (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x4f (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000002e (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x2e (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000000d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) System.Exception: Syntax error at line 1 hello. ^ at kOS.Compilation.Script.RaiseParseException (System.String scriptText, Int32 line, Int32 absolutePosition) [0x00000] in <filename unknown>:0 at kOS.Compilation.KS.KSScript.Compile (System.String scriptText, System.String contextId, kOS.Compilation.CompilerOptions options) [0x00000] in <filename unknown>:0 at kOS.Compilation.Script.Compile (System.String scriptText, System.String contextId) [0x00000] in <filename unknown>:0 at kOS.Screen.Interpreter.CompileCommand (System.String commandText) [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Code Fragment 0000 EOF << (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000073 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x53 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000006f (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x6f (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000006d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x6d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000065 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x65 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000020 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x20 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000073 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x53 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000070 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x70 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000061 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x61 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000063 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x63 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000065 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x65 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000073 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x73 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000020 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x20 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000068 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x48 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000065 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x65 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000072 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x72 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000065 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x65 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000002e (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x2e (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000000d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) System.Exception: Syntax error at line 1 some spaces here. ^ at kOS.Compilation.Script.RaiseParseException (System.String scriptText, Int32 line, Int32 absolutePosition) [0x00000] in <filename unknown>:0 at kOS.Compilation.KS.KSScript.Compile (System.String scriptText, System.String contextId, kOS.Compilation.CompilerOptions options) [0x00000] in <filename unknown>:0 at kOS.Compilation.Script.Compile (System.String scriptText, System.String contextId) [0x00000] in <filename unknown>:0 at kOS.Screen.Interpreter.CompileCommand (System.String commandText) [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Code Fragment 0000 EOF << (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000031 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x31 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000032 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x32 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000033 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x33 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000116 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000034 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x34 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000035 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x35 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000036 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x36 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000000d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) System.Exception: Syntax error at line 1 456123 ^ at kOS.Compilation.Script.RaiseParseException (System.String scriptText, Int32 line, Int32 absolutePosition) [0x00000] in <filename unknown>:0 at kOS.Compilation.KS.KSScript.Compile (System.String scriptText, System.String contextId, kOS.Compilation.CompilerOptions options) [0x00000] in <filename unknown>:0 at kOS.Compilation.Script.Compile (System.String scriptText, System.String contextId) [0x00000] in <filename unknown>:0 at kOS.Screen.Interpreter.CompileCommand (System.String commandText) [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Code Fragment 0000 EOF << (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000031 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x31 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000032 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x32 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000033 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x33 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000114 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000034 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x34 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000035 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x35 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000036 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: UNICODE CHAR: 0x36 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x00000113 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) KEYDOWN IN TERMINAL: SPECIAL CODE: 0x0000000d (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) System.Exception: Syntax error at line 1 124563 ^ at kOS.Compilation.Script.RaiseParseException (System.String scriptText, Int32 line, Int32 absolutePosition) [0x00000] in <filename unknown>:0 at kOS.Compilation.KS.KSScript.Compile (System.String scriptText, System.String contextId, kOS.Compilation.CompilerOptions options) [0x00000] in <filename unknown>:0 at kOS.Compilation.Script.Compile (System.String scriptText, System.String contextId) [0x00000] in <filename unknown>:0 at kOS.Screen.Interpreter.CompileCommand (System.String commandText) [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Code Fragment 0000 EOF << 7 - Delete the kOS.dll you got from my google drive and rename the original one back to "kOS.dll" (undoing what you did in step 1 above). This should restore your installation back to what you had before, with the verbose keylogging removed. The reason I am suspecting that the Linux version of Unity is producing different keycodes for things like Enter is that you described the behavior as showing a "space" for Enter on the screen. What actually happens is that the default fallback if the ascii code of the key doesn't have any special exception behavior defined in kOS is to lookup that ascii code in the bitmap font image file and print out whatever is there. Most of the unprintable control code characters are blank in the font file, making it impossible to visually tell the difference between "It's printing a space character" and "It's printing the blank image corresponding to this control character".

For the people having problems on Linux, would you be willing to perform a test for me? I have a linux machine, but it's old and nowhere near good enough to run Kerbal Space Program so I can't test this myself. What I want to do is detect whether or not the keyboard events are somehow different in Linux than in Windows - if perhaps the keys generate a different set of key codes than the program is looking for. To test this I'd like to compile a special version of the plugin that enables verbose logging to output_log.txt mentioning each and every key code that the terminal sees. Then if you're willing to download it and try using it you could type a few lines of text in the terminal that have the problem keys in them and send me back the resulting log file, with a description of the exact sequence of characters you were trying to type. Then I can compare that to what I get doing the same thing in Windows and see if the key codes are the same.

I can't speak to the spaces problem, but the problem with the 'x' key exists across all platforms and has always been there. KSP traps the 'x' key event at a lower level than other key presses, and mods are not in a position to be able to override that, as far as I can tell. It has something to do with the way the 'x' key works even when other keys are locked out (like when you're in Map View and don't have the navball tab pulled up, normally WASD won't steer the ship, but 'x' will still kill the throttle because it's meant as an emergency key that always works.)

I too don't care for the part testing missions - they seem to be necessary early on but then become silly and pointless very fast and yet still take up the majority of the contracts list. I mightn't feel that way if they ware made a little bit more sensible. Test firing a booster while going 400 m/s at only 10000m altitude requires you to make and fly a rocket that under no circumstances would you ever do it that way otherwise. If you're an experienced player you look at it, and its tiny payout and say "nope, declining that one. The extra expense of designing a rocket that badly is not going to make up for the payout." If you're not an experienced player then the contract just serves to trick you into bad habits and teach you how to play poorly. Also, I think being required to test it using the staging system is a bit unfair. I don't see why it shouldn't count to set up an action group to trigger it - giving you more dynamic on the spot control over when and how you trigger it. Contracts that depend on exact biome would be a better way to handle the early game: - land in a mountain biome on Kerbin. - take a surface sample from the desert. - etc. Another sort of early contract that would be good would be orbit-specific contracts, like: - put a satellite into circular orbit (diff between periapsis and apoapsis less than a small tolerance window). - put a satellite into geosync orbit (provide target periapsis and apoapsis). These have the advantage of teaching a skill to new players that will come in handy later.

I suspect it's happening because the LOCK STEERING algorithm assumes that it should not use too much force if the deflection isn't very far. (i.e. if the deflection from the intended angle is only a few degrees off, it won't use full pitch, as that creates massive oscillations usually.) The LOCK Steering isn't optimized for spaceplane flight where pitch behaves very differently from yaw because a neutral setting tends to pitch down. It's assuming all axes are relatively equal in how they behave. However, you can try to write your own more sophisticated autopilot by controlling the controls directly in RAW mode and bypassing LOCK STEERING entirely. http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

That syntax was removed deliberately for some reason. I'm not going to defend it because I don't understand why it was. You can get the same effect with the alternate syntax: lock steering to heading( compass, pitch ).

This must have been introduced when Vector+Rotation was changed to return a vector instead of a Direction. What it used to do was translate the Vector into a Direction, then rotate it, and return the Direction - which loses magnitude information from the vector, and removes the ability of the script writer to use the built-in system to rotate a vector - an *extremely* important thing for lots of stuff people should be able to do. This was conceptually wrong because when you convert a vector into a direction you lose magnitude information but "gain" bogus manufactured information about which way is the "up" (i.e. the roll information). The "+R(0,0,180)" was a rotation from that false manufactured "roll" information to the one you wanted. It still works, as you found, but now you have to explicitly say you wanted the vector turned into a direction. The odd thing I don't understand, is that it shouldn't give an error. I wonder if it gave an error because the rotation was a rolll - the one thing that vectors can't store.

Because assuming consent from those who don't know what's happening is dishonest. Going with opt-in instead of opt-out makes it so that you have no choice but to be clear to the user that a thing is being enabled because if you don't make it clear nobody knows to opt in. Imagine running an election where every eligible voter who stayed home and didn't vote was presumed to have their vote counted the way you like because they didn't explicitly say they didn't. It wouldn't be like that if ModStatistics were installed explicitly as a separate download, because then the act of choosing to download and install it would constitute informed consent. The problem happens only when it gets bundled with other mods you didn't know were going to include it.

The roadmap for how to integrate this into kOS is this: - It's wrong for kOS to explicitly support this LaserDist with customized code just for LaserDist. - It's wrong for LaserDist to explicitly support kOS with customized code just for kOS. - Instead, kOS should implement a generic way to query/adjust the KSPfields of any part. If it can do this, then it can support LaserDist and a bunch of other things. (A KSPField is a single row of the popup box that appears when you rightclick a part). I was talking with erendrake and he agrees that this is the best approach. But as to when? I don't know.

Updated for KSP 0.24. https://github.com/Dunbaratu/LaserDist/releases/tag/v0.1p5 There is literally no difference in how it behaves and the source code wasn't changed. It was just recompiled. It seems to "work" as well as it did before.

I have noticed an increase in the level of ludicrousness in my rocket designs because of First Contract. I end up designing rockets in stupid ways in order to satisfy a secondary contract's requirement whilst on the way to satisfying the main one I care about. For example, trying to have a rocket that slows down to only 300 m/s as high as 20,000m, and then speeds back up again to get the rest of the way to orbit. I think the random factors can be bounded a bit better to make the contracts a bit more sane.

Can you mention what the error messages actually are? Having to diagnose by guessing is hard.

Vessel:Velocity is not a double. It's a pair of velocity vectors, one called :ORBIT and one called :SURFACE. You have to specify which one of the two you wanted. Notice how, when flying manually without kOS and just playing stock, you still get a different velocity reading on the navball depending on the mode it's in, "orbit" or "surface" (different speed and the yellow prograde marker is in a slightly different direction). That's the exact meaning of the two types of velocities, and that's why you need to specify which you meant.

I figure there must be some things that the 0.24 API changes will break here and there in various mods, and over the next several days there's going to be a lot of modders discovering them the hard way. To help ease the pain, I thought it made sense to start this thread where modders can post anything they discovered in their own mods that they had to change for 0.24 - to help other modders get their mods updated faster without having to do the same trial-and-error discovery themselves. I don't have anything to post yet - I'm going to play stock 0.24 for a while first to get the feel for how it works, so I know which changed behaviors in a mod are correct and which aren't. (To clarify: This thread isn't for making use of brand new features - like adding a button to the stock toolbar or adding customizations to the contracts. This is for "this code used to do X in 0.23.5, but now in 0.24 it does Y instead, and I had to change it in this way to get it to do X again."

Really? It says that? Because it's not true, and if it is true it's really the wrong thing to do. Ship:velocity:surface *should* be a vector, not a scalar. It's a type of single scalar number. (i.e. not a vector). I could go into boring programming details you don't care about, but here's the TL;DR version: There's lots of different ways computers store numbers depending on how they're being used. Two of them in particular are called "float" and "double". The reason one is called "double" is because it takes up twice as much memory as the other one does, in exchange for being more accurate. The names were invented a long time ago when computers were less powerful, and today the kind called "double" is actually the more common default, making the naming convention a bit odd. Because ship:velocity:surface is a vector, you can add a ":mag" suffix on the end of it to get its scalar magnitude value, for your check: If ship:velocity:surface:mag > 200 {... etc...

The image below describes the user interface suggestion that I'm talking about. I've logged about 2000 hours playing the game and I still don't know half the names of the parts. For me most of the parts are remembered as pictures and stats ("The big orange size-3 fuel tank that weighs 64" for example). I've had to continually toggle back and forth and back and forth between the mission control and the VAB to see what the part each mission is talking about is. (And of course that only helps when it's a part I've unlocked in the VAB. When it's a mission to test a new still-locked part (i.e. it will appear with a blue backround in the parts bin if I accept the mission) then I have absolutely no idea what I'm committing to, and can't find out without an external wiki search on the name. Yes, it's easy to see what the part is once you're in the VAB, but it helps to know what it is when making the decision to commit to the mission. In the screenshot below, the part in question was always "the small diameter rust-colored stack-mounted one that does 30 thrust" in my mind, for example. The name was always forgotten: For a player who's played only a few hours of the game they'll have even less of an idea what the part is from just the name.

And this: PRINT "Hello...". ----> PRINT "Hello;;;"; Regular expression-aware find/replace could do it, but if you're talking about an audience of people who are not all experienced programmers, they won't know about it. But basically it's backward compatibility that's the problem. There's lots of users who call it a 'bug' when they have to change code that used to work. And it can be one of the most annoying things about trying to follow other people's posted online examples of code - when the language keeps being incompatible with its own future versions. Having to be meticulously rigid about making sure you've installed exactly the right version of the interpreter to go with the code you're running is one of the more annoying things about Python, for example. (oh, this was written in 2.4 and you're running it in 2.5... thats why it stopped at this line...) Sometimes backward compatibility is broken because a major problem cannot be fixed without changing the way things are called, but breaking it for purely cosmetic reasons, like preferring ';' over '.', seems like it's not an important enough reason to do it. The annoyance of the choice of punctuation mark is minor compared to the annoyance of knowing some users have lost interest because of "yet another breaking change".

PRINT VANG(vector1,vector2).

I was talking about the original suggestion to have outsiders write the GAME's translations, rather than outsiders writing a MOD to the game that provides the mods' own translations. Those are very different things in regards to what I was saying about putting words in the company's mouth.

False. The API to change the strings shown to the user is NOT there. This invalidates your claim that "this is a bogus argument".

It's too complex to go into here, but there's very good reasons to have end-of-statement markers in languages, if they're the sorts of languages that ignore whitespace and line breaks and just treat a run of spaces,tabs,and end of lines as being identical - all get mashed down to just "there is some space here" in the syntax. The languages that don't require them instead have to require tighter rules on what the spacing means, which is a different type of limitation. The only thing I'm not happy with is that period(.) is a poor choice for the end-of-statement marker because of its conflation with decimal points, and how it being used for end markers precluded it from being used for member separators (thus why you say SHIP:FACING:VECTOR, instead of the more normal Ship.Facing.Vector that most languages would have you use for that type of thing).

Actually one thing that always bugged me about the kosscript syntax is how the language syntax makes the filenames be identifiers instead of string values. That means you can't do this: set fname to "myprog". run fname(arg1). and you can't do this: run "filename with spaces"(arg1). There's nothing in the underlying volume system that requires the filenames to be identifiers. It's just the syntax grammar definition that has the limitation.

When "what's in the mod" gets added to stock, it's not just a matter of the mod becoming redundant, it becomes non-working because the way it interacted with the main game is now wrong and therefore the entire design from the ground up needs a re-write, and it's effectively the same thing as starting over writing it again. The fact that some people are willing to do that work doesn't change the fact that it would have been less effort to wait and not start writing code until after the change was out.