nivekk / kos Goto Github PK

I had a program that worked the first time I ran it but then when I ran it a second time it always just hung there until I hit CTRL-C.

I eventually traced the cause to this line in the program:

declare mySpeed.

What happens is that if you run "declare" a second time on a variable name that already exists, kOS just hangs there. So any program that tries to do the right thing and declare variables up front ends up only being runnable once. For now I've changed all "declare" statements to "set" statements instead.

0.34 introduces a regression where the user still types in the terminal although the terminal window is not focused.

Scenario:
1 - launch a rocket.
2 - open the terminal.
3 - control the rocket manually with the terminal still opened.

Hello,

I started to use this amazing projet on kerbal. So i store my programs on the volume 0 (archive). But i don't find the command to remove a file.
Is there one or is it still under development ?

Sincerly.

Again, I don't know if this is intended or not.

Here is what happens:
lock steering to up + R(0,-45,0). - works just fine, ship alters course for hdg 90, pitch 45.

sas on.
lock steering to up + R(0,-45,0). - ship does absolutely nothing, the yaw/pitch/roll indicators in the bottom left stand still, the ship isn't even trying to turn.

I tried this on various ships, and increased the amount of reaction-wheel torque, all ships did nothing.

When setting the SAS to "off" manually, the ship starts to turn and alters it's course to the correct hdg and pitch as if the SAS was blocking it somehow.

It may be intentional but it finally figured it out while napping. I happen to be hardcoded to allman indent so it's very annoying.

when cnt2 < 10 then {}. //sunshine and rainbows
when cnt2 < 10 then{}. //syntax error

I 'fixed' it by editing to the regex to this: [CommandAttribute(@"^WHEN (.+?) THEN(( |{)+(.+?))$")].

On a side note, PRINT .. AT seems to be reversed. (Column[x], Line[y]) is very confusing and always takes me some cycles to figure out. Adding to that, it only accepts int values, be nice it accepted variables. By swapping '[0-9]' for '.+' seems to allow for them. Don't know what type of issues that will cause... Haven't seen any yet.

I need to get back to work. Hopefully this made some sort of sense.

This is probably way down the line, and maybe beyond the scope of what you're aiming to do, but the ability to plot points, lines, circles and/or rectangles on the console would allow for users to create things simple maps, graphs, radar displays, gauges, and many other things... :)

Currently, when program ends, all locked parameters are unlocked. Would be nice to have an option to keep some of them (example: steering) still locked.

I tried to figure out why on earth I couldn't copy a file to the volume and had to resort to reading the source code here to figure it out.

The fact that there's a 10,000 byte limit for a volume is completely undocumented. No end-user who hasn't read the code would realize it.

And when you try to copy the file into the volume, the error message doesn't tell you that a limited capacity is the reason it failed.

Something definitely needs to be added to make it known to the end user.

One simple thing would be if the "LIST" command showed a line at the bottom of the file list along the lines of:

Volume Capacity Used:   5012 / 10000 bytes.

People would at least then know there was such a thing as a limit.

It might be cool to be able to assign expressions or variables in the AT() expression to be able to freely move text around the console.
So things like:

Set x to 1.
Set y to 1.
Until x = 10 {
Print "Hello world! at (x,y).
Set x to x + 1.
Set y to y + 1.
}.

become possible. It would allow for things like cool ASCII graphs!

Right after the 0.5 update I started writing some code for a leader-bot and a follower-bot, both bots are essentially rovers.
Here is a bug i found:

The leader-bot has absolutely no code.
The follower-bot has the following code:

brakes off.

set target to "LeaderBot".
lock wheelsteering to target.

lock wheelthrottle to -1.
wait until ABS(target:bearing)<90.

until 0
{
if target:distance > 10
{
lock wheelthrottle to 1.
brakes off.
wait until target:distance < 10.
}.
if target:distance < 10
{
lock wheelthrottle to 0.
brakes on.
wait until target:distance > 10.
}.
}.

While focused on the follower-bot, I run the program. The follower-bot corrects its heading and approaches the leader-bot. It then brakes within 10 meters of the leader and stops. --Everything is fine up to here.

I now switch to the leader using the bracket keys.
When trying to control the leader-bot manually I notice I have absolutely no control over it. The steering is locked and I cannot turn the wheels, I cannot accelerate, I cannot decelerate. Toggling sas, rcs, brakes, throttle still works..

I switch back to the follower-bot and stop the script execution with Ctrl +C.

I switch again to the leader. I can now control the leader-bot with no problems.

I think it would be very useful if you would be able to use functions like %, CEIL, FLOOR, ROUND, SQRT, POW, ASIN, ACOS, ATAN, ATAN2, LOG and EXP.

And a quick look at Expression.cs shows that the current SIN, COS and TAN are using degrees. However I am used to radians, so it might also be useful to add two types of each, maybe SIN for radians and SIND for degrees?

Adding some mathematical constants with might also be useful, such as PI. And I personally would also prefer to be able to write an AND operation as "&&" and OR as "||".

And finally I think it would be useful to have a more complete list of expressions in the readme file.

Open the terminal window while the engines are throttled up.
Type anything into the window that includes the letter 'x', for example:

set x to 5.

As soon as you type the 'x', the 'x' is also read by the main game as well as by the terminal window, causing KSP to kill your throttle, assuming you have default KSP settings where X is the kill throttle key.

The examples in the readme show the use of comments with "//", but that doesn't actually work in the parser.

Is there some form of comment in the language, and if not can we have one? Sometimes the logic of a script gets a bit messy and it's problematic that I can't describe in the code why I'm doing what I'm doing. At the moment I have some pseudo-comments by saying 'set c to "blah" like this example:

set c to "degrees to radians conversion multiplier.".
set d2r to 3.141559266 / 180.

set c to "multiplier to convert a sweep of degrees of ".
set c to "latitude/longitude to a surface distance given ".
set c to "the radius of the body.".
set c to "Warning: is only accurate for small degree sweep.".
set degToDist to d2r*bodyRadius.

But it seems silly to be having to execute a statement each time I'm trying to make a comment. I know it's an interpreted language so comments always will take a little bit of time, but if there was a dedicated comment syntax it could probably be faster to parse over and skip than a statement that actually does something.

Even an incredibly simplistic comment style like a "#" in column 1 would still be better than what I'm doing now.

Hi!

Would be nice, if it becomes possible to add a commentary to a script, like in other programming languages.

I thought

/* TEXT */

would be nice, like in HTML/JAVA/PHP. Maybe something like !-- TEXT --! would also work.

After putting a small probe into orbit (core + fuel tank + engine + kos + solar panels), then quit to space center and finally go back to the probe via the mission center, the steering completely overreacts when being locked to some direction.

Interestingly this does not happen if you lock the steering directly after the payload separation, in this case the steering finds the desired direction quickly and accurately.

I posted about this in the forum but it's a critical bug that broke every script I wrote that worked on 0.5 and I can't find a workaround so I'm posting it here to be sure it gets seen as soon as possible.

This syntax used to work:
lock steering to up + V(x,y,z).
or this:
lock steering to up * V(x,y,z).

They are no longer supported, it seems. They now cause "Expression error" to try to use a V(...) expression to steer by.

This is critical because now all the available means to steer require that you know the angles ( you can use R() or Q() or HEADING... BY... ) and to get the angles from the vector XYZ lengths requires access to the functions arcsin, arccos, or arctan, which we don't have.

Either of the following two things would solve the problem:
1 - Put support for steering by a vector back in.
or
2 - Add arcsin, arccos, and arctan.

For example, the compass heading and pitch could be derived as follows if we had the arc functions, assuming X is north, Y is west, and Z is up:

set xyzLength to (x^2+y^z+z^2)^0.5 .
set xyLength to (x^2 * y^2) ^ 0.5 .
set compSin to (0-x) / xyLength.
set compCos to y / xyLength.
set compass to arccos( compCos ).
if compSin < 0 { set compass to 0 - compass. }.
set pitchSin to z / xyzLen .
set pitch to arcsin( pitchSin ).
lock steering to heading compass by pitch.

Any chance of adding surface prograde as a builtin? Then you could for example launch with a pitch program that keeps limited AoA, or do a reentry with a fixed AoA.

The orientation of the velocity:surface vector seems somehow fixed to the planet, and not to the local horizon. This becomes especially clear in a circular equatorial orbit, when the surface velocity vector should remain constant (in direction and magnitude). Instead, it varies wildly, depending on your longitude.

So while the length of the vector is correct, it's direction isn't.

I'd like to see an option that allows the targeting of orbital bodies, including the sun.

Running the program screws with KER (Kerbal Engineer Redux) window. I'm not sure if that's KER or kOS problem.

I have an issue where my console fonts look very blurred (including the "close" button), and it's barely readable. I have all settings on max (besides anti-aliasing).

There is a GitHub wiki for the project here presumably typed in by the author Kevin Laity:
https://github.com/Nivekk/KOS/wiki

and there is a community-made Wiki for the project here:
http://kos.wikia.com/wiki/KOS_Wiki

Discuss: Is there a good reason to keep them separated? There will inevitably be duplication of information between them. Right now both are still small and it's not too late to go through the effort of copying the content from one into the other.if that's what is wanted. But as time goes on that will become a larger and larger job if its decided to do it later.

My vote would be that IF it's merged, to use the gitHub one over the Wikia one because it makes for a central repository of everything about the mod, and the Wikia banner ads are annoying and have buggy javascript that hurts my browser sometimes.
.

When a program contains braces and is quicksaved, this conflicts with the persistent.sfs file which also uses braces which kills save files.

These need to be escaped.

This would allow for editing of the scripts outside of KSP.

I'm not sure if this is intended behavior or not.

lock throttle to 1. - works, sets maximum throttle.
lock THROTTLE to 1. - doesn't work, throttle remains at 0.

This is an inconsistency because all other kOs variables are not case-sensitive, eg:
print missiontime. - works.
print MISSIONTIME. - works.

print VESSELNAME. - works.
print vesselname. - works.

I encountered this issue:
set x to 0.
until x = 1 {
set y to 1.88.
print y.
wait y.
}.

This will print the correct value of 1.88, but will never loop back again. No syntax error, just a hung state.

Hi, add prograde and retrograde vectors for all three reference systems:

• ORBIT:PROGRADE (are the same as current PROGRADE)
• ORBIT:RETROGRADE (are the same as current RETROGRADE)
• SURFACE:PROGRADE
• SURFACE:RETROGRADE
• TARGET:PROGRADE
• TARGET:RETROGRADE

Maybe the current PROGRADE and RETROGRADE use the same reference system as the navball is using at the moment.

An additional proposal would be to have those vectors for any other object and not only the current target. So for example when there are three objects in orbit (A, B and Z). When the script is running on Z, it then would allow something like 'A':prograde and 'B':prograde without changing the target every time.

When you rename a file to an already existing file, you get two files with the same name.

This works:
set theta to -30.
set posTheta to abs(theta).
print sin(posTheta).

But this issues an 'unrecognized term" error:
set theta to -30.
print sin(abs(theta)).

This also fails - it doesn't matter which order around they are:
print abs(sin(theta)).

The core problem appears to be nesting function calls inside function calls.

Since you are able to get quite a few vessel stats I thought it would also be useful to know the resulting Isp of your ship.

Would be nice to have this as a flight statistic and, if possible, be able to bind it to target. I guess this might go with adding AN and DN as an orbital geometry value?

With the ability to set a target from within the script the scope of usefulness would become wider for KOS scripting (ie. you could build a script to hunt for a good flight path to somewhere or rendezvous with something).

Open the terminal.
Type this:

    print ( 
    .

Watch KSP lock up entirely requiring the task manager to kill it (or kill-9 if in Linux or Mac). Obviously it's bad syntax but it should result in kOS giving an error message, rather than freezing all of KSP.

I don't know if this is possible, but I'd like to see an option to set the target to an orbital body, including the sun.

The text editor needs support for the tab key, and currently strips leading spaces when saving.

I think I read somewhere that you were going to start work on a new file saving system. I had started working on a new system in a fork before reading the comment, so I'm just wondering if you had started on it yet, or if I should keep working away at it?

PS. Sorry if this isn't the proper place for this question, it's been a while since I used git and I couldn't find a way to message you.

PPS. I've been pretty bored lately and looking for something to do, which is why I started work on making the change for this. Figured I'd maybe help someone out while keeping myself amused :P

Whenever I try to perform a mathematical operation on verticalspeed (or a variable instantiated to verticalspeed, either through SET or LOCK), KOS "crashes" (requiring a reboot of the console).

I noticed that verticalspeed seems to have a higher decimal count than standard variables in the language, so perhaps the math code isn't designed for a decimal that big?

Just to make it easier, here's some example code which crashes the system on my end:

print verticalspeed + 10.

set y to verticalspeed.
print y - 5.

When I try to get a resource tag by calling, for example,

print <LiquidFuel>.

the console prints out the error:

"Unrecognized term: ''." 

(note that those are 2 single quotes with nothing between them)

One of the things about the 10k limit on programs is that while I like having to live with an old-school limit like it's an old computer, it seems a bit unnatural that this limit is based on the source code characters when in a real space program they'd be sending compiled code to the craft. I find myself being unwilling to format the code nicely, or use long variable names, when I know its wasting my 10k limit to do so. And that makes the programs less readable.

Perhaps a solution to this that might still keep the original feel of tight limits would be to generate a program complexity cost based on the number of lines or number of parts of speech rather than the number of characters. That way all the following would cost the same space on the volume hard drive:

set pS to 1.00 .
set pS to 1.
set preferredSpeed to 1.000  // This is a comment.

They would cost the same because they are equally complex as far as grammar goes. They all consist of 4 terms.

I know comments like in that last line are not implemented. But if they were it would be nice for them not to count against your limit, as that would discourage people from using them. And in a sense if this was compiled code, the comments would no longer exist in the compiled form. Just like in the compiled form it wouldn't matter if a variable name was long or short, unless it had been compiled with symbol table information included for debug purposes.

Another place where it would be nice is in indenting:

if x = 1 {
    if y = 1 {
        print "blah".
    }.
    if y = 0 {
        print "blorg".
    }.
}.

if x = 1 {
if y = 1 {
print "blah".
}.
if y = 0 {
print "blorg".
}.
}.

Both of the above examples are identical, but the first one penalizes the user for indenting it correctly by making it cost 32 bytes more (yeah that's not much but if I'd used a larger example with a longer body it would add up.)

Let's say Volume 1 has 8000 bytes on it already, and you want to add a 3000 byte program to it. This puts it beyond the capacity of 10000 bytes.

But the check to deny the copying only happens when doing this:
SWITCH TO 1.
COPY myprog FROM archive.

When you do the same copy in reverse like so:
SWITCH TO archive.
COPY myprog TO 1.

Then the check doesn't seem to be happening and it allows you to overflow the 10000 limit.

This caused me to overload my probe's volume 1 beyond capacity and not realize it until after I'd launched it and then tried to update a program from the archive and it failed. For a while I thought there was something wrong with the COPY command that made it only work in one direction, until I looked at the code and saw the 10,000 byte limit and then worked out that it wasn't being enforced universally in both directions.

: error CS2001: Source file `SpecialValue.cs' could not be found
: error CS2001: Source file `SpecialValueTester.cs' could not be found
: error CS2001: Source file `StageValues.cs' could not be found
: error CS2001: Source file `VesselTarget.cs' could not be found

Files not checked in?

Make a tiny craft with landing gear and a kOS module on it. Put it on the launchpad, open the terminal. Type "gear on." or "gear off." No effect.
The README implies that it's supposed to be implemented. Am I misunderstanding what it's for (is it for landing gear deployment, i,e. pressing the "G" key?)?

It would be nice if there was a way to access what the IJKLHN keys normally do in flight. (sideways movement.) Docking is nearly impossible without it. It doesn't even have to be too fancy- just mimic what the controls do, which I think is boolean thrusting so it's simpler than the THROTTLE interface (no need to set a number between 0.0 and 1.0 just a boolean toggle for the 6 directions:

Any one of these would be fine:
suggestion 1 - direct control of the 6 thrust directions:

rcsleft on. // or off.
rcsright on.  // or off.
rcstup on.  // or off.
rcsdown on.  // or off.
rcsahead on.  // or off.
rcsback on.  // or off.

suggestion 2 - Same thing but use positive and negative numbers so there's only 3 thrust settings not 6:

lock rcsside to 1. // pushing  to ship's relative right
lock rcsside to 0. // drift.
lock rcsside to -1. // pushing to ship's relative left.

lock rcsvertical to 1. // pushing to ship's relative up.
lock rcsvertical to 0. // drift.
lock rcsvertical to -1. // pushing to ship's relative down.

lock rcsahead to 1. // pushing to ship's relative front.
lock rcsahead to 0. // drift.
lock rcsahead to -1. // pushing to ship's relative rear.

suggestion 3 - thrust in a direction, let kOS work the combination of the 6 thrust directions to do it:

lock rcsDirection to ( up + R(45,0,0) ). // push diagonally.
rcsThrust on.
rcsThrust off.

I actually prefer 1 or 2 over 3. Sort of the whole reason I'm using kOS instead of mechjeb is that I want to write my own piloting routines instead of having someone else do it for me.

Can kOS run in multiple instances within KSP? For example, I would be launching a rocket using a script and there is a script running on a probe making its way to Jool?

I would like to request that we be able to use variables in the vector triplets with KerboScript.

For instance:

declare X.
set X = -30.
lock steering to R(0,X,0).

This is the working syntax :

when stage:liquidfuel < 560 then { stage. }.

But this one is crashing the entire game :

when stage:liquidfuel < 560 then {
stage.
}.

Ok, so I found this:

print "1". - prints 1.
toggle ag1. - toggles action group 1.
print "1-1". -prints 1-1.
print "6-1". -prints 6-1.
toggle ag6. - doesn't toggle action group 6.
print "6-2". - doesn't print anything. (anything beyond toggle ag6 isn't evaluated)

I've tested all action groups, this only happens for ag6.

It's very useful to make one program call another, as if it was a subroutine. But when you do so, the message "Program ended." can't be suppressed and it's really messing up my nice pretty displays made with print ... at... statements.

Can the "Program ended." message be either suppressed or directed somewhere else?