Dunbaratu

Can you show us the script you were running, for debugging purposes?

There has been no change to the folder location. Where are you trying to run it from?

Well the intent is to show the user the same scale in both so it looks clear and obvious (so small vectors don't show on the map view, deliberately. switching to map view is for seeing things like "is this position vector really pointing all the way to the Mun from my ship like I thought it was?" Since the vectors are sometimes used as positional coordinates it's vital that people be able to see them in the right scale so that where it looks like the vector's tip is in the map view is really where it is in the world. Any idea why ScaledSpace.LocalToScaledSpace() isn't giving the right scale? I'm using that to ensure the right orientation and translation, but it dosn't seem to be getting the right scale.

For the record, the credit and bragging rights for the new parser, and the awesome speed increase from the k-RISC system, belongs entirely to @marianoapp, not me ("Dunbaratu" is my other username in certain contexts, for those who don't know). I'm a total newbie to the project (I've been a user of kOS a while, but not a programmer for it). I only just barely started getting involved in contributing code changes, with a bit of a bumpy start being new to both C# and to github, well after marianoapp's kRISC system was already done being merged into the project. It would have been there whether I was involved or not. I just modified a few bits of syntax here and there after the system was already in place. (I feel a bit embarassed by the implication that we have a new parser "thanks to" both of us when it's really 99.99% him. Feels like I'm steeling credit.) Oh, and to go along with the release announcement, the documentation is updated a little bit as well: http://ksp-kos.github.io/KOS_DOC/

Thank you that works great. Another question is - how do I query the scale of the map view? For example in the in-flight view a line that is exactly 1.0 units long appears as 1 meter long. But how long is a "unit" of 3-D space in the map view? 10 kilometers? 100? etc. (Also, is there any sort of API documentation SQUAD provides for modders for things like this?)

Okay, so I've gotten quite a long ways along with this but I'm still running into a problem. When I'm on the flight view, then this seems to work as a way to show the vector centered on the ship's center of mass: GameObject lineObj = new GameObject("Line"); GameObject hatObj = new GameObject("Line"); if (onMap) { lineObj.layer = 9; hatObj.layer = 9; } _line = lineObj.AddComponent<LineRenderer>(); _hat = hatObj.AddComponent<LineRenderer>(); _line.useWorldSpace = false; _hat.useWorldSpace = false; // Default the vector's origin to the current ship. // (user can modify this using VECTOR:SHOWSTART) Vector3d shipPosFromOrigin = FlightGlobals.ActiveVessel.findWorldCenterOfMass(); _line.transform.localPosition = shipPosFromOrigin; _hat.transform.localPosition = shipPosFromOrigin; _line.material = new Material(Shader.Find("Particles/Additive")); _hat.material = new Material(Shader.Find("Particles/Additive")); When I do that, I cause the _line and the _hat objects to be LineRenderers who's frame of reference matches the ship's position in its local XYZ space, If I for example use them to draw a line from (0,0,0) to (10,0,0) then I'll get a 10 meter line along the x axis sticking out of the ship. That's great. But now I want to do the same thing in map view, but the map view uses some other sort of coordinate system in which the XYZ space moves with the camera. When I use the same code then the origin is wherever the camera is, not wherever the ship is. How do I get the vector to be drawn with its origin at the current vessel instead of where the camera is in map view?

Yes. I find that "revert to launchpad" doesn't quite clear everything out and reset it correctly, while "revert to VAB" does. I get the same effect when all the ship parts are "in-line". If every part is on the same axis through the middle of the ship, then the steering's attempts to keep it aligned around that axis go haywire and roll the ship back and forth in a see-saw motion around that particular axis. I found that I can make it stop by designing it with some mass being off the central axis. (i.e. slap a couple of fuel tanks on the side with 2x radial symmetry, and use yellow hose to feed them to the actual engine). Once there exists some mass that is NOT on the central axis, the wobbly steering goes away. I don't understand the steering code myself but given the effects I'd guess that somehow the LOCK STEERING algorithm doesn't deal very well with cases where the ship has a very low angular inertia around the axis in question. It tends to oversteer in that case, and gets stuck in a loop constantly trying to overcorrect itself, making the wobble get bigger and bigger over time.

Test that it really is the correct directory you're putting it in. Test that by doing this: Inside kOS, type these two commands: SWITCH TO 0. LOG "LINE OF TEXT" TO PROOF. Now it should have created a file called PROOF.txt in your folder, containing the one line "LINE OF TEXT". If you don't see that file in the same folder where you put the Roll.txt file, then you're not putting it in the same place that kOS is looking at for programs. (Do you have more than one installation of KSP and you're putting it into the wrong one?)

It's sounding like user input is going to probably be a dedicated release target unto itself at some point. There's enough bits and pieces that go along with it to make it worth dedicating a release entirely to it alone. The light speed delay issue gets back to a thing I was thinking about before about user input: There's really two types - blocking line-at-a-time and immediate key-at-a-time. And there's useful places for both. There's times when blocking line-at-a-time input is more logical ("Please type the name of your landing site, captain:"), and places where key-at-a-time input is more logical ("Press A to abort program and return to manual control at any time."). I am picturing that a remote mission in which there's no crew on the craft would be effectively restricted to the line-at-a-time type of input, because key-at-a-time would mean waiting several minutes between key presses, while line-at-a-time would allow you to type it all and hit enter and only wait after that.

If it says file not found when trying to "run roll." then there's something more wrong than just the fact that the editor no longer works. Question 1: Is the file named "roll.txt"? The ".txt" ending is needed. Files in-game do not have the .txt ending, but kOS looks on disk for files with the .txt ending corresponding to them. Question 2: What OS do you run KSP on? I've wondered myself about case insensitivity in the file naming convention and whether or not the mod works right on case-sensitive filesystems, but haven't had the chance to check it. Question 3: Is the archive folder in the right place? It should be {KSP_HOME}/Plugins/PluginData/Archive, which is *NOT* where things normally go in the KSP mod system (it's not using the GameData folder).

Do you have the latest version of kOS from gitHub, which is newer than from spaceport? I'm asking because the text editor ability of the terminal has deliberately gone away. (But might be revived in a later version). The way the terminal was altered and re-implemented meant that to make the text editor work would have required re-writing it. Now the only supported means of editing program files is from outside KSP, with an external text editor working on the files in the Archive folder. I'm not entirely happy with the fact that there's no longer an in-game text editor. Granted the text editor was terrible for doing any serious work, and anyone trying to work in kOS very quickly decided to use an external editor instead. But it was still useful to give new users something quick and dirty to play with to get a feel of how things work. Also, it worked on local volumes, while editing externally only works on the Archive. I'd like to see something done addressing this, but I'm not sure what. Reviving the old text editor probably isn't such a good idea, but maybe a crude generic text area GUI widget window can be popped up - one that just directly uses an existing widget instead of trying to build a text editor from scratch.

A related question to consider: if kOS ever gets around to implementing keyboard input, should it operate on a lightspeed delay - If ship has no crew, then assume the operator is typing from far away and cannot interact in real-time to prompts on the screen?

Not only does it not appear on the mini window, the mini window doesn't pay any attention to the fact that it has been clicked in the big main window, which I would call a bug. If you click the hide button in the main window, then change to the mini view, in the mini view the hidden goals are still showing. I think it's a user interface "bug" that there's no indication that a goal has been done other than that button. What if each goal had a line at the bottom that just said "Goal Completed? : False" and then changed to "True" when it's done? On that line could be a smaller button that says "view/collapse goal" that makes the goal text (including the completed true/false line) collapse down to one line, like the way a folder viewer in a file browser lets you collapse or expand a folder's view.

True, but you will also need a way to type the characters in before it would be useful - real 64's did it by holding down the "C=" key - a sort of extra shift key like ALT. Or a way for a program to build a string from ascii codes (which can't be done right now - you'd need to be able to do something like SET VAR TO "HELLO " + CHR(140) + CHR(162).

Font file which lets you see the underscores properly. This is a PNG image file: http://imgur.com/tzh1NQw It might not look like it because it's showing white foreground on transparent background, and the forums use a white background, but if you rightclick that empty space above this text you'll see there is an image file there. If you copy that image file, and use it to replace this file: GameData/kOS/GFX/font_sml.png Then you'll get the underscores to show up properly in the window instead of having them look like left-pointing-arrows. (Standard caveats apply: save the old file somewhere first in case you screw it up, and updates will overwrite this with the original font again.) This is in no way officially supported by the mod - it's just a thing I did because I was tired of them looking like that and I wanted to use underscores in variable names. The syntax allows underscores but they look messed up in the terminal because of the default font image file. The reason the underscores looked like they do is that Kevin Laity used a font taken from the 0-127 ASCII portion of the Commodore 64 character set, which used that symbol in place of the underscore character. (too bad it didn't use the other 128-255 extended part of the character set, because that's where all the nifty drawing characters were - for making boxes and lines around things).

It's a known bug on the github. It's on the list of things to work on for 0.12 release.

I would argue that you are violating the meaning of "Kerbal space program does it" when the limitation preventing it is the standard way the game works. It does change the way the game models orbital physics to make it model a craft as more than one point mass.

But does it work with KSP unmodded? I've never gotten a long spaceship to tide lock, no matter how long it is.

You have it 100% backward. When a real space station has a side that always faces earth, it's not because it doesn't rotate. It's because it does rotate. It rotates very slowly at the rate of one revolution per orbit. If it takes 2 hours to finish an orbit, it's rotating at 1/7200th of an RPM, or 1 rotation per 2 hours. Just like the Moon, which orbits once every 27 days, and is rotating at a rate of 1/27th of a rotation per day. Thus the same side always faces earth. And the reason this 'coincidence' happens a lot in astronomy is no coincidence at all. The same effect that causes the Moon to distort Earth's shape, resulting in ocean tides, also causes the Earth to distort the Moon's shape, and when an orbiting object is no longer entirely 100% spherical, but has been squished into an egg shape, there's forces causing it to tend to rotate toward an orientation where the longer dimension is pointed toward the primary body pulling on it. This, over a LONG time (and the moon has had a few billion years of time to work with), will tend to make the orbiting body conform to a rotational rate that exactly matches its orbital period, so it keeps its longer dimension radially aligned toward the primary body all the time. More here: http://en.wikipedia.org/wiki/Tidal_locking And the reason KSP stations don't do that isn't because they do rotate. It's because they don't rotate (the game doesn't remember rotational inertia when a ship goes on rails). That, and tide locking isn't implemented in KSP, but even if it wasn't you could still try to manually make the ship rotate at the right rate to keep it facing the right way, if not for the fact that that rotation gets killed by going onto rails.

EDIT: NEVER MIND. Found it. It only appears as an option if you click the toolbar settings while in flight. You can't configure it ahead of time in the VAB or space center.

I tried that already. The only buttons I can enable are the ones from the MCE mod that were always there prior to installing Chatterer. My config for Chatterer does definitely show all sorts of toolbar settings so I know it's supposed to have them. Here's a screenshot. You have to click on it and blow it up bigger to read the window.

Hmm. There was one version where CTRL-C didn't work, but I've lost track of whether it was the version under final release as 0.11, or one of the pre-release 0.12-ish builds. There's been a lot of development on the pre-release side of things since the last official release (and supposedly it's going to be released as 0.12 Real Soon Now but there's one sticky problem still remaining with the two types of steering.) But one simple question is: is the terminal window focussed or unfocussed when you press CTRL-C? If it's unfocussed then CTRL-C won't work because it will be sent to KSP itself rather than being sent to kOS. It's a bit confusing about the focus, but weirdly all keypresses OTHER than action groups require the window to be focussed for kOS to notice them, while the action group keypresses like ALT-1 need to be done while the window is NOT focussed in order for kOS to notice them. This seems contradictory at first but there's a logical reason for it: kOS isn't really reacting to the keypress "alt-1". It's actually reacting to the event "KSP has activated action group 1", so KSP has to see the keypress so IT will activate action group 1, for that event to happen.

How am I supposed to make the user interface appear? I installed it, and it wasn't doing anything, so looked through the package for some type of documentation, and on the first page of this thread as well, and I just couldn't find the answer - there's a readme but it only describes version change history, and is not a manual. Looking at the config I can see what look like settings for window positions in the Toolbar Mod, so presumably it uses that, but I can't seem to find them on the screen. I do have Toolbar installed, as I'm using Mission Controller Extended, which uses Toolbar. I also saw that there's some type of green microphone icon for use in the toolbar so presumably it's supposed to appear somewhere. By reading the config file I determined that I should be able to get some sounds by hitting the apostrophe or doublequote key, and I did so and confirmed that I did hear some electronic bleepy sounds and some voice sounds but they were very quiet (thus why I'd like to get to the user interface to look for a volume slider).

If you use 'Vim' for your editor, this may be useful to you. I just updated my syntax file for Vim for kOS scripts to use the newest keywords and terms coming in 0.12 : https://drive.google.com/#folders/0Bxkeai7oN35fV2xCa0Y1RThSYkU

Simple geometry might have something to do with it. As the radius of a cylinder increases, the volume increase per inch of radius increase goes up exponentially by the square of the radius. So the amount of additional radius needed to support 3 instead of 2 passengers is less than the amount of additional radius needed to support 2 instead of 1. And the radius increase drives air resistance, craft instability, and so on. It may be the case that once you get past the big leap from 1 person to 2, that it's less of a big deal to go a bit further to 3.