[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Pontiac]

[begin rant @ turning kOS into a compiler]

Based on my experience, back in the day, the Commodore Vic 20 and the 64, and I'm sure the 128 did this as well (Never had the pleasure to play with that one), when the BASIC program was running, it was looking at symbolic code to save space. That is why the literal "?" was PRINT. The question mark was the same BASIC language op-code as the PRINT statement. There were other commands as well, but, its been 20+ years since I've touched BASIC v2.0. (I think even the comparison functions, like, =, <>, <=, >= were a single symbol) [2]

Then you have other languages, like Visual Basic, which uses full words, and not symbols to deal with your language construct. The interpreter would read through and figure out what the developer wanted on a word by word basis. Some versions of VB actually sent the code WITH the EXE. No encryption or attempt of hiding the code of any sort. The "Compiler" would just take the run time engine, put it in the EXE, copied all relevant code directly into the EXE, and off it went.

Between C64 BASIC and VB run time constructs, I personally prefer the C64 method of using symbols to deal with a smaller memory footprint. Assemblers convert written word to the lowest level of symbols a PC understands. However, changing the existing code base so that it uses symbols to "count words" would require(!!!!) to take the existing command set, change them into numeric number and use that as an ID of sorts, then change the interpreter to deal not with words but with the command ID, THEN deal with the instructions as required. Not only is that going to be a PITA to maintain the command ID set, but it is also going to be a nightmare that compounds itself when new commands are added or removed, not to mention you have a HUGE overhead above and beyond with simply

Now, as we developers (Both in the real world and for kOS both in-game and the development team for it) have our choices to deal with this kind of thing. You have notepad, notepad++, VIM, EMACs, ECHO "code" > prog.dat, etc. But more realistically than redirecting your code to a file at a command line, there is a kOS IDE laying around somewhere. It think its mentioned in the first post. Just from observing the IDEs page, as I've never used it, the feature list claims (verbatim)

- it keeps two versions of your script. One is the raw code that you write, the other is comment stripped, line trimmed, excess space removed file that kOS actually uses.

- code highlighting

- cross platform compatible

The other thing we need to be aware of is that people are running so many mods that every BYTE counts. A 10k hard limit does seems small, considering that the C64 had 38k available for programs[1]. 64k was on board, but the other 32k was for fonts, the screen at its different resolutions, software registers, etc, etc. But then you look at the Vic 20 (Older model) that only had 3k of memory available, worked at 40x23 text mode (It had graphics mode, but I think it was something like 160x200?). People are running MODs that cause KSP to crash and burn due to memory constraints. A few KB here and there, meh, OK, but when you have 10 drones flying around with 10 different kOS scripts actively running, you're now looking at 100k, and that COULD be the difference between a crash or not. Not to mention the general overhead of running said scripts.

The other thing I just thought of is that the 10k limit MIGHT be a limitation of C# holding onto different entities. Perhaps not on the number of bytes used in a string, but perhaps the number of lines of code. There might be something that kOS just can't handle when things start to get "too big".

So in MY humble opinion, please stop asking for this INTERPRETED language to become a compiler. It just isn't going to happen with the existing code base. There are other projects around here that do this kind of thing that are more low-level.

[end rant]

**

[1] - http://en.wikipedia.org/wiki/Commodore_64#CPU_and_memory

[2] - http://en.wikipedia.org/wiki/Commodore_BASIC#Technical_details

[mossman]

Is it possible to send specific instructions for attitude control (ex. torque p,y,r ) instead of just lock to a heading?

I'd very much like to write my own steering logic.

[Dunbaratu]

So in MY humble opinion, please stop asking for this INTERPRETED language to become a compiler.

I can't stop doing that which I never started doing. What I suggested was to count the code limit in a way that simulates the effect compiling would have on the code footprint by using the actual symbolic grammar token count rather than the length of whitespace, comments, and variable names that never would end up on the craft. I'm aware of the existence of external tools to throw comments away and extra whitespace away. I wrote my own in Perl. I'm also aware that they are solving an artificially created unrealistic problem.

To use the C64 example - the C64 had a lot of video games for it. They weren't written in the C64 Basic interpreter that you saw when you played with it at home. They were either written in raw machine language or if they used another language with source code, that source code did NOT have to fit in the 64K of the computer because it was cross-compiled from a more capable computer to a target C64's executable.

(And the claim that the C64 had only 38K of ram for programming was false. To make it become a true statement you'd have to insert the caveat "when using it's built-in BASIC interpreter". If you didn't need that interpreter because you were using machine language, or because you were cross-compioling to machine language from another computer, you were allowed to overwrite the BASIC interpreter's memory locations and use them as just generic RAM. Although the BASIC interpreter was hardcoded on a ROM, the portion of the 64K memory address range that referred to where that ROM was ALSO had RAM at the same memory locations. You could alter a single bit somewhere down in page 0 to flip the meaning of whether those addresses referred to the ROM or whether they referred to the RAM. You could even toggle between them quickly during execution, to give you access to BOTH the BASIC ROM and the RAM in the same location that it masks off, so long as you didn't need both of them in the same instant.)

Edited February 8, 2014 by Steven Mading

[Dunbaratu]

so if I do this:

set c to 310. // compass heading, i.e. 0=north,90=east,180=south,270=west.
set p to 20.  // pitch, i.e. -90=down,0=horizon,90=up.
lock steering to heading c by p.

Then my craft will turn as expected. However, if I follow with this:

print heading.

I get the value 0. I'm expecting 310 - and the navball in game says 310. What am I not getting?

That the word "heading" is used in this context, NOT as the name of a variable but as a hardcoded keyword in a syntax expression.

Imagine if you tried to print the value of "when" or "then" or "if" or "until". That's sort of what you're trying to do by printing the value of "heading" in the expression: "heading c by p". The keyword "heading" used there is telling the interpreter to parse the following stuff in the heading format, rather than parse it in the Euler rotation format R(…) or in the Vector format V(…) and so on.

You can try printing the value of "steering" but then you'll run into the following problem: In kOS the native form of the steering setting is a Euler Rotation ( R(..) ) rather than a vector or a "heading by". Whenever you use a vector or a "heading by" to set it, it gets casted and covered into a Euler rotation when it gets saved as the steering setting. So when you print 'steering' it always comes out in that format - an R() tuple - regardless of how you set it.

[unWinged]

I have problem with code below. It's simple code for launching suborbital rockets with liquid or hybrid engines. It have to parameters declared on start: heading and target apoapsis.

It always returns error, something along lines "error in line 1: syntax error.

I got three similar codes (for launching diffrent rockets) but only that ones gives error.

I tried to run it with only one parameter, or without any parameter, but still not working...

declare parameter thead.
declare parameter tapo.

clearscreen.
set hdir to thead.

print "launch parametrs:".
print "target apoapsis: " + tapo.
print "heading: " + hdir.
print "----====----".

print "Commencing launch sequence!".
wait .5.
print "3".

wait .5.
print "2".

lock steering to heading 0 by 90.
print "   steering locked".

wait .5.
print "1".

lock throttle to (mass*20)/maxthrust.
print "   throttle locked".

wait .5.
print "0 - LAUNCH!".

stage.

wait until alt:radar > 100.
lock steering to heading hdir by 90.
print "   LIFT OFF!".

wait until verticalspeed > 100.
lock steering to heading hdir by 80.
print "   starting gravity turn".

wait until altitude > 4000.

lock sel to 80*(70000-altitude)/66000.
lock steering to heading hdir by sel.
print "   gravity turn".

wait until apoapsis >= tapo OR stage:oxidizer = 0.

if stage:oxidizer = 0
{
	print "!!FUEL DEPLETED!!".
	break.
}.

lock throttle to 0.
lock steering to prograde.
print round(missiontime) + "   coasting".

wait until altitude >= 70000.
print round(missiontime) + "   atmosfere cleared".

toggle ag1.

print vesselname + " is in space!".
print"MET:  " + round(missiontime).

unlock throttle.
unlock steering.
SAS off.

print vesselname + " is free!".

If somebode can look at it I will be grateful!

[Dunbaratu]

If somebode can look at it I will be grateful!

Might the problem be this line?

print"MET:  " + round(missiontime).

There's no space between the PRINT and the opening quote mark. I don't know if kOS requires it or not, but it looks weird not being there.

[unWinged]

Might the problem be this line?

print"MET:  " + round(missiontime).

There's no space between the PRINT and the opening quote mark. I don't know if kOS requires it or not, but it looks weird not being there.

That helped now program starts smoothly.

Thank You!

[togfox]

How do I determine compass heading from eular notation?

[Panichio]

How do I determine compass heading from eular notation?

Seconded. Been trying to figure that out myself.

Also, is there a way to use "OBT:TRANSITION" so that when it equals "ENCOUNTER", throttle is locked to 0?

[togfox]

Another suggestion - make it impossible to delete files from archive. Is there an in-game reason to want to delete from archive? Is that needed for run time script writing/running on the fly?

(lucky I've got backups!!).

[Camacha]

Another suggestion - make it impossible to delete files from archive. Is there an in-game reason to want to delete from archive? Is that needed for run time script writing/running on the fly?

I am not sure that is the best solution to the 'problem'

[Dunbaratu]

How do I determine compass heading from eular notation?

Here's how I'd try to solve it. (Caveat: I haven't tested this. This is just how I'd try to solve it if I was trying to):

Step 1: Get the tfDirtoUnitV and tfXYZtoENU programs I put on the Wiki here. Using tfXYZtoENU (which in turn calls tfDirToUnitV, which is why you need both of them) you can take any arbitrary vector in the underlying KSP's X,Y,Z axes and get what that vector would be if it was expressed in a frame of reference in which the axes were along your current East, North, and Up directions.

Thus instead of having 3 scalars representing the X component, Y component, and Z component of your vector, you can instead have 3 scalars representing the East component, North component, and Up component.

Step 2: Use tfXYZtoENU to obtain the East,North,Up of your current SURFACE velocity. (Note, depending on what you're trying to do with it you might be interested in the ORBITAL velocity instead. But I suspect you're doing something with the surface velocity if its something where you care about compass heading. The compass heading you get from the surface velocity will be different from the compass heading you get from the orbital velocity in all cases other than exactly 90 degrees (or 270 degrees if going faster than the planet's rotation. If going slower than the planet rotation then a 270 orbital heading will flip to a 90 surface heading).

Step 3: If you think about it, a compass heading is a case of doing trigonometry in which North is the X axis and East is the Y axis. (0 = north, 90 degrees = east, 180 degrees = negative north (south) and 270 degrees = negative wast (west). Therefore you can get your compass heading by plugging the North and the East components of your velocity vector into ARCTAN2().

If interested, you can do the same sort of thing to get your pitch but first you need the length of the velocity vector projected onto the east/north plane. Use the pathagorean theorem on just the east and north components (without the Up component) to get the length of that projection, then plug it into ARCTAN2() along with the Up component to get the pitch (you are obtaining the angle between the direction you're actually going with the Up component present versus the direction you would have been going had the Up component been zero.)

Edited February 9, 2014 by Steven Mading
Fixed broken URL tag

[Pontiac]

I can't stop doing that which I never started doing. What I suggested was to count the code limit in a way that simulates the effect compiling would have on the code footprint by using the actual symbolic grammar token count rather than the length of whitespace, comments, and variable names that never would end up on the craft. I'm aware of the existence of external tools to throw comments away and extra whitespace away. I wrote my own in Perl. I'm also aware that they are solving an artificially created unrealistic problem.

I wasn't pointing a finger any anyone in particular. I can't and don't bother to keep track of that kind of stuff, which is why I didn't bother quoting anyone. I've just seen several comments (Both in here, and in the original thread) all lined up about the memory limitations, making something "compiled", so on and so on.

When requesting the amount of free space in the kOS environment is simple enough to do to get rid of all the excess white space. Loop through, do trimming, chip away at the comments, etc, etc. But that might not solve the underlying problem that there is the hard limit of 10k bytes which is what is stored in memory (Comments and all) because whatever is driving the interpretation may be what the limiting factor is, not the number of bytes the software has available.

To use the C64 example - the C64 had a lot of video games for it. They weren't written in the C64 Basic interpreter that you saw when you played with it at home. They were either written in raw machine language or if they used another language with source code, that source code did NOT have to fit in the 64K of the computer because it was cross-compiled from a more capable computer to a target C64's executable.

To which I wrote a lot of ASM applications via the monitor/assembler and broke away from the interpreter. I still have that brown ASM book laying around somewhere.

I don't doubt better machines were used to develop code, test code, compile code to work with the op-codes on the 64 CPU had. Any machine I developed on had to be bigger and better than the machines I typically distributed to. But the point of the matter is not where the code is written, its what can be actively stored (Comments, spaces, and all) and run on the target platform.

(And the claim that the C64 had only 38K of ram for programming was false. To make it become a true statement you'd have to insert the caveat "when using it's built-in BASIC interpreter". If you didn't need that interpreter because you were using machine language, or because you were cross-compioling to machine language from another computer, you were allowed to overwrite the BASIC interpreter's memory locations and use them as just generic RAM. Although the BASIC interpreter was hardcoded on a ROM, the portion of the 64K memory address range that referred to where that ROM was ALSO had RAM at the same memory locations. You could alter a single bit somewhere down in page 0 to flip the meaning of whether those addresses referred to the ROM or whether they referred to the RAM. You could even toggle between them quickly during execution, to give you access to BOTH the BASIC ROM and the RAM in the same location that it masks off, so long as you didn't need both of them in the same instant.)

I knew about all that. You can replace the entire BASIC interpreter with one of your own making. Although I didn't write something to do that (I was less than 10 when I had the 64) I did have some Computes Gazettes around, and plugged away in MLX to write code that'd enhance my BASIC programming experience, such as auto-line numbering while coding, renumbering, etc. Eventually I did get into ASM and coded up some stuff that simulated what a TSR was on the PC Clones of the era.

... man those were the days....

Nostalgia setting in anyone? heh

[Dunbaratu]

because whatever is driving the interpretation may be what the limiting factor is, not the number of bytes the software has available.

Its not. We know because the original author Kevin Laity SAID the limit was picked arbitrarily.

But the point of the matter is not where the code is written, its what can be actively stored (Comments, spaces, and all) and run on the target platform.

When distributing compiled code instead of source code, the comments, spaces, and long variable names only cost space on the developer's computer, not the target computer. Which is why "where the code is written" does matter. A Lot. If a machine language instruction takes 2 bytes for the opcode, followed by a 4 byte 32-bit address for a memory location to operate on, then the mention of that operand costs 4 bytes in the final executable regardless of whether the operand was called "x" or it was called "myLongVariableName" in the source code.

[jcramb]

But that might not solve the underlying problem that there is the hard limit of 10k bytes which is what is stored in memory (Comments and all) because whatever is driving the interpretation may be what the limiting factor is, not the number of bytes the software has available.

But the point of the matter is not where the code is written, its what can be actively stored (Comments, spaces, and all) and run on the target platform.

The point I was trying to make is that software being used on spacecraft is most likely going to be in machine code and not interpreted on the fly. In which case the program has been compiled, probably with efforts to optimise and reduce the size of the resulting binary. Due to this it is not realistic to have a byte limit on the source code, but rather it should be a byte limit on the machine code. You would only need the most very basic of parsers to achieve a simulation of this compared to just counting the byte size of the source file.

Compared to what other mods are computing performance wise, there should be absolutely no reason why kOS should be technically limited regarding speed or RAM usage. At 100k or even 10MB (which is a ridiculous number of programs) it is extremely unlikely to be the mod responsible for ksp hitting the dreaded 3.5GB limit. That is more attributed to textures / models which take up far more space. Concerning performance, well kOS only runs 5 clock cycles a second which even if you considered an overhead of 100,000 actual cpu cycles to compute that one simulated cycle (a generous amount) then even on the very slowest of computers its only using 0.01% of the cpu.

So in other words, any limitations on kOS are pretty much by design and not due to any feasible technical limitation on computing power / memory.

Edited February 9, 2014 by jcramb

[Dunbaratu]

[...] has been compiled, probably with efforts to optimise and reduce the size of the resulting binary.

Don't confuse matters by brining code optimization into it. Even *WITHOUT* any code optimizations in the compiler - even with just a dumb direct "do whatever I was told and don't second-guess it" compiler you still don't pay any cost for comments, whitespace, or long variable names.

[togfox]

Next question - random numbers. Is there a genuine random number function and if not, can I make a substitute - like the div/mod of the first decimal point in "seconds" component of the universal time or some such? I've adopted that technique in other languages and that tends to be random enough.

[erbmur]

Does anybody know of any script that would allow me to calculate phase-angles and/or ejection angles for transfers to other bodies?

I have been trying different approaches and I just can't seem to get anything to stick!

Any help would be much appreciated.

[Camacha]

Next question - random numbers. Is there a genuine random number function and if not, can I make a substitute - like the div/mod of the first decimal point in "seconds" component of the universal time or some such? I've adopted that technique in other languages and that tends to be random enough.

Just out of curiosity, what are you using random numbers for in kOS?

[mossman]

Asked this already, but it got buried, so I'm re-posting it:

Is it possible to send specific instructions for attitude control (ex. torque p,y,r ) instead of just lock to a heading?

I'd very much like to write my own steering logic.

[Camacha]

Asked this already, but it got buried, so I'm re-posting it:

The short answer is not yet.

It is being worked on by the author of at least one kOS variety, and probably more. The different versions are making everything a bit cloudy though.

[erendrake]

For what it's worth, I too vote against replacing the player's effort in making a PID controller.

Thank you everyone for letting me know that sounds fine to me.

I intend to use the new list iterator to have the script "learn" the parachutes on the craft and use them in atmo drag calculations. Thanks for adding that.

How cool! i am particularly excited to see what people do with Lists.

By the way, thank you on the effort on user documentation.

You are welcome. If anyone wants to contribute to that documentation for content or examples. i would be very happy to accept pull requests

[erendrake]

I have been testing your .11 pre-release

Thank you very much for testing!

"signal interrupted. Transmission lost."

So i assume you are using RemoteTech?

I Keep forgetting to test manned kOS missions

Here is my proposed compromise:

If you dont have a connection through RemoteTech but you have a crew. You can issue local commands and write code locally but you can not copy from the archive?

[erbmur]

Here is my proposed compromise:

If you dont have a connection through RemoteTech but you have a crew. You can issue local commands and write code locally but you can not copy from the archive?

It was locale code I was attempting to when that error was popping up, but if you are stating your compromise as a bug fix, then I am very much for it!

[erendrake]

Is it possible to send specific instructions for attitude control (ex. torque p,y,r ) instead of just lock to a heading?

I'd very much like to write my own steering logic.

We have an upcoming milestone that will address this exact issue. To allow for docking we will have to add more direct access to the FlightCtrlState API.