Dunbaratu

Another trick you can do with the new logfile feature is to use it to write self-modifying code - because the KOS mod does not differentiate between log files and program scripts. They're all ".txt" files behind the scenes. For example, the following works: log "print x^2 ." to squared. set x to 5. run squared. 25 Program ended.

Does anyone know the height of the launchpad? In order to measure the craft's height on the launchpad I'd have to know how much extra altitude the launchpad is adding above the ground.

Did you have the ability to check memory usage when you were looking at CPU and GPU usage? I've seen the same problem from other mods and I believe the common problem might be that a mod gets stuck in a never-ending loop that happens to be allocating some memory. If I'm right then what's happening is that when a mod causes KSP to run out of memory it then starts making major mistakes elsewhere in the program outside of the mod that end up saved in the persistence file. I've had half the parts on the ship just randomly disappear from existence when KOS gets stuck. The longer I leave it the worse it gets. And since it's a 32-bit program, if you have a lot of RAM it doesn't necessarily need to use up all the memory of the machine - just use up as much as a 32-bit program can use (4GB). This happens with the mismatched quote mark problem, for example. If KSP hangs because there's a mismatched quote mark in the KOS script, then behind the scenes the KOS mod is spinning in an infinite loop and if you leave it like that too long the state of the game gets really broken.

I wasn't aware that planets were stored in the persistence file. I'd assume that since they never come "off" rails that there'd be no need to save anything about them. Everything would just get derived from the game time. But maybe I'm wrong. When I'm back home (I'm on mobile right now) I'll give it a look.

I finally got some video recording software set up, so here's my descender/skycrane dropper in action:

The Wiki is populated with enough information to work out *almost* all of the parameters of the ellipse equations for the orbits of planets and moons. The one thing that's missing is the initial start positions at time zero. (i.e. when you very first start a new campaign of KSP on day zero, hour zero, minute zero, second zero, what are the positions of the bodies? Basically what I'm trying to do is use the new KOS mod to do some autopiloting and there is no ability to find the positions of planets and moons but I just realized that I should be able to calculate that from my own "on rails" equations if I just had the initial starting positions plus the data from the KSP wiki plus the current exact time in the campaign.

wheels just do not steer at all. Does anyone know why this doesn't work? 1 - Land a rover on the Mun. It has an SCS on it. 2 - Make sure brakes are off. 3 - Open SCS terminal window. 4 - type command "lock wheelthrottle to 0.3". Rover starts moving slowly in a straight line. Good. 5 - type command "lock wheelsteering to 60." No change. Keeps going in straight line. 6 - type command "lock wheelsteering to 210." No change. Keeps going in the same straight line. 7 - type command "lock steering to heading 210 by 0." No change. Keeps going in the same straight line. NOTHING makes the wheels turn. Why?

There was an experiment they did on Apollo 13. It's the only part of Apollo 13's goals that was able to be carried out according to plan because all the work the spacecraft had to do for it had already occurred long before "Houston, we've got a problem" happened. With Apollo 12 having installed the corner reflectors and the ability to make seismology recordings from them, NASA realized that the best way to get an idea of what the inside of the moon might be like would be to give the reflectors a good "ping" to measure by just smashing something into the moon. And when they looked at how to get something with good mass to smash into the moon they realized the Apollo mission profiles tend to be set up just right to send the Saturn V's stage 3 at the moon if they're just altered slightly. So on Apollo 13 they did that. Instead of ditching stage 3 and then trying to aim to miss the moon slightly, they instead kept stage 3 attached, used it to aim themselves on a lunar impact path, detached stage 3 while they were heading for impact, and then had the command module push itself slightly to the side to miss the moon.

And we're missing most of the information we could use to actually work out what the native system is. We can learn our velocity in the native system, but not the position. I wasted a lot of hours of detective work to figure out if there is any way to find the underlying system from what little data IS available and I got this sort of worked out: http://kos.wikia.com/wiki/Tutorial_-_KOS_0.61_and_above:_Finding_surface_dynamic_information

Vector math is broken because the system keeps trying to cast all vectors into Directions. (A Direction only mentions rotation angles, not magnitude). The only way I've been able to use vectors correctly is to manually do all the vector math myself by getting the vector components by: set vec to prograde. vec:x vec:y vec:z Then you can add vectors by adding their components, or perform matrix math on them or dot products and so on. But you have to do it all yourself. You can't even just do a simple scalar magnitude multiplication like: halfspeed = 0.5 * prograde. There's a lot of underlying vector operations in the underlying C# api that we don't have access to.

People have had problems with the fact that the steering acts all wonky for a while before it settles down on the chosen heading the first time you activate it. The craft needs to spin a bit around all 3 axes before it "learns" its controls, it seems. The problem is how to have the code wait for that initial wonky steer period to finish before doing anything else like turning on engines, when the waiting period has to be tailor-made to each craft since they don't all rotate at the same rate. Well, now that someone clued me in to the undocumented "FACING" property that's in the Mod's code, I have the better solution to the problem, shown below: // Assume mySteer is an R() tuple of some sort. // You could replace "mySteer" with "Up" or "North" // or any other canonical direction. lock steering to mySteer. // Wait until the aim has lined up before continuing: set align to 90. // anything bigger than 5 will do. until align < 5 { set pDiff to facing:pitch - mySteer:pitch. set yDiff to facing:yaw - mySteer:yaw. set align to abs(pDiff) + abs(yDiff). }. // Now do other stuff like activate the engine. I originally tried this by just putting the entire expression together into one statement like so: wait until ( abs(facing:yaw-mySteer:yaw) + abs(facing:pitch-mySteer:pitch) ) < 5 . But the notoriously wonky KOS parser couldn't understand that so I had to separate it into separate statements like you see above.

I don't have to run them from the archive either just because I edit them in a real editor that isn't crippled. My kerbals write the software at home and then transmit it to the craft. Nobody in their right mind would write the software by typing across a remote terminal connection to a terminal server halfway across the solar system when they could write it at home on the ground and transmit the final result to the craft, the way it was intended. And when doing it that way, you don't bother sending comments to the craft. The comments are for the benefit of the human - the computer doesn't care about them.

I don't think you understand the reason I'm stripping them. It's not because the syntax doesn't support them. It's because they cost space.

I mentioned it a few times so I thought I'd post it. This is the Perl script I use when I want to edit my code and then publish it over to the KOS archive. It allows me to be as verbose as I like in comments and indent as much as I like in comments without those good programming practices costing me anything on the actual part in the game because the code the KOS mod sees has had indents and comments stripped out. I don't see this as cheating because as far as the game is concerned it's identical to what the code would have looked like had I not bothered to make it legible. I just completely reject the idea that removing legibility from the code to make it fit is a valid or interesting challenge. Removing algorithmic complexity to make it fit IS a valid challenge, but removing purely cosmetic legibility features like indentation and comments to make it fit is not. There is one small cost a block comment does still cost with this script but it's small. A line consisting only of comments is not entirely deleted. A blank zero-length line is left behind in its place so that the line number counts are still accurate in those few places where the KOS interpreter actually tells you a line number in an error message. Oh, and yes i know this could have been done with a few regular expression search/replace functions instead. The reason I didn't do it that way is that I'm still entertaining the idea of making the filter do more by having it mangle variable names into shorter forms and maintain a mapping for them. If I decide to do that then I will need to analyze the text with something better than a regular expression search/replace. To Use it: 1 - You need Perl installed. If you're on Windows its not there by default but is downloadable with a google search for "Perl on Windows". 2 - Make a directory on your hard drive somewhere that you want to make your editing of your KOS source code happen. Copy out all the .txt files from your KOS archive directory to this new location, and rename them all to have .ksc extensions instead. I use "KSC" to mean "KOS Source Code". 3 - Edit the program to change the two lines at the top that say: $inDir="C:\\Users\\Dunbaratu\\KOS code"; $outDir="C:\\Program Files (x86)\\Steam\\steamapps\\common\\Kerbal Space Program\\Plugins\\PluginData\\Archive"; To make them point at your own places instead. inDir is the directory where you want to edit your source code (the one you set up in step 2 above) and and outDir is the directory where the KOS archive is stored (If you installed the game via Steam with its default folder locations you can probably use the same outDir setting I have there, otherwise you will need to change it.) 4 - Run the perl script after you make edits to publish the edits to your KOS archive. 5 - BE AWARE that if you adopt this system the Perl script does overwrite .txt files in your KOS archive with the stuff you have in your KSC files, so if you use "EDIT PROGNAME." inside the KOS terminal you'll be editing the temporary version that can get overwritten next time. Other than occasionally trying something quick and dirty to test how a KOS feature works, I do all my editing in my own KSC files now and just double-click the "export.pl" program after I've made edits to get them to appear in the archive of the game. File: "export.pl" : #!C:\MinGW\perl $inDir="C:\\Users\\Dunbaratu\\KOS code"; $outDir="C:\\Program Files (x86)\\Steam\\steamapps\\common\\Kerbal Space Program\\Plugins\\PluginData\\Archive"; opendir(my $dHandle, $inDir ) || die "Can't open $dir as directory to read: $!"; while( $fName = readdir($dHandle) ) { if( $fName =~ /\.ksc$/i ) { $fNewName = $fName; $fNewName =~ s/ksc$/txt/ig; open( KSC, "<$inDir/$fName" ) || die "Can't open $inDir/$fName for input: $!"; open( TXT, ">$outDir/$fNewName" ) || die "Can't open $outDir/$fNewName for output: $!"; print "$fName --> $fNewName: "; $cCount = 0; while( $srcLine = <KSC> ) { $qCount = 0; # number of quotes so far on the line. # Used so that a comment start inside a # quote string gets left alone, as in: # PRINT "THIS STRING // IS NOT A COMMENT". # Since KOSscript only allows one-line # strings there is no need to remember # quotes opened on previous lines. $commPos = -1; # Position of start of the comment on the line. # Remains -1 if there isn't a comment. $len = length($srcLine); $firstNonSpacePos = -1; # For trimming all indentation on the line, # Find the first non-whitespace char and # cut off everything that came before it. for( $i = 0; $i < $len ; ++$i ) { $ch=substr($srcLine, $i, 1 ); $chNext=( ($i < $len-1) ? substr($srcLine, $i+1, 1 ) : "\0" ); if( $firstNonSpacePos < 0 and $ch ne " " and $ch ne "\t" and $ch ne "\n" and $ch ne "\r" ) { $firstNonSpacePos = $i; } if( $ch eq "\"" ) { ++$qCount; } # 0.6 style comments: if( $ch eq "/" and $chNext eq "/" and ($qCount%2 == 0) ) { $commPos = $i; break; } # My own older comment style I was using before # KOSscript had its own comments : # # if( $ch eq "#" and ($qCount%2 == 0) ) { # $commPos = $i; # break; # } } if( $commPos >= 0 ) { for( $cutPos = $commPos-1 ; $cutPos >=0 and ( ( substr( $srcLine,$cutPos,1) eq " " ) or ( substr( $srcLine,$cutPos,1) eq "\t" ) ) ; --$cutPos ) { } # "\x0d\x0a" is for the CR/LF text terminators Windows uses. # Change that part if you run this on a UNIX (including Mac). # Perl is *supposed* to translate "\n" into a CRLF on Windows # but it doesn't seem to always work right so I hard coded # the characters. $srcLine = substr($srcLine, 0, $cutPos+1) . "\x0d\x0a"; ++ $cCount; } if( $firstNonSpacePos >= 0 ) { $srcLine = substr($srcLine, $firstNonSpacePos ) ; } print TXT $srcLine; } close( KSC ); close( TXT ); if( $cCount == 0 ) { print "no comments found.\n"; } else { print "$cCount comments stripped.\n"; } } } closedir $dHandle; print "press enter to finish.\n"; $line = <STDIN>

Status LANDED works but it effectively means the script is "blind" and has to feel the ground to find its height. If what you want to do, for example, is skycrane-drop your payload when it's about 1 meter above the ground - you can't tell what that actually is without knowing how high the SCS part is above the payload's bottom. This is why my skycrane script currently has to actually land on the ground first and then detach the skycrane, which doesn't look quite as cool. And as a bit of advice, any script that checks using status = "LANDED" should probably also add: OR STATUS = "SPLASHED" to the check. Otherwise it will fail when coming down over water. I almost wish that status was a bitwise flag set to handle the fact that more than one thing can be true at a time about a craft. A craft on the water should be considered BOTH splashed AND landed. But without bitwise manipulations it's a pipe dream anyway.

No it doesn't. It's identical to a program with the comments and whitespace stripped which is far smaller. Most of that 7k is legibility not algorithm (and some of it is just the fact that it was written before KOS had some of the features it has now. Like the extra PRINT lines to redraw the menu all over the place is because PRINT AT didn't exist yet when it was first started. Anyway, to allow good editing practices of proper indenting and proper commenting without it costing overhead space in KOS, just make a "compiler" program outside of KSP that takes well documented properly indented code as input and spits out compacted uglified code for KOS to see as output. Since the terminal editor doesn't really work as an editor anyway (wide content is utterly invisible, not wrapping the text old-school style nor letting you see it by side-scrolling new-school style. It is in fact even worse than editing an actual C64 basic program was) anything serious is going to use an external editor anyway. As long as you use an external editor you may as well go that extra step and also edit your code in your own directory somewhere and "publish" it over to your KOS archive through a filter. Then you don't have to write deliberately uglified code that isn't indented and isn't commented. I'd show my little program that does this but I doubt most people have a Perl interpreter installed so I don't think it would be that useful. (I primarily program in UNIX but I use Windows for KSP because the ports aren't that well implemented, but I've got my Windows installation stuffed full of UNIX-like tools like Perl and Bash and Vim.) I'm editing in an external gvim window. I've already got this feeling by setting the colors the way I want and downloading a C64 font to use in the editor.

That is still faster than what happens when you have to button-mash the "<". Using the gui button slows it down faster than holding the "<" key does. When you use the gui button, the game knows it needs to knock the warp down again as soon as it's capable of it after each slowdown. When using the "<" key, the program doesn't see ahead to know this is your intent so it takes the time to get the input system all up and working again after each change of warp before it notices the next "<" in the queue.

As the one who suggested this, I want to say that another thing that would help immensely is to just let us see the full 180 arc of the hemisphere of the navball. Right now we can't see the whole face of it because the ring of labels around it hide the edges. That's what leads to the most frustrating situation which is where you can't see BOTH the pro-and retro- versions of a mark and so you rotate around randomly until you see one of them. Once you see one you can work out where the other one is. But you often can't see either one.

A lot of the stock ships in fact ARE really bad. Now THAT is a thing that should be addressed to help the newbie experience.

Which isn't related to Bizz's suggestions which were all about antenna range from earth to probe and had nothing to do with line of sight. The Command module wasn't being used to shorten the distance to home. The distance savings between earth and command module versus the distance between earth and lunar lander is negligible. If anything if you want to simulate problems of long distance signals then POWER consumption would affect range more so than number of antennae. The tradeoff should be on how much power the probe can muster. Requiring that you festoon the probe with many dishes all over it (such that small probes become physically impossible because you need more space just to get the antennae to fit) is not the way to go.

Your scoring is badly explained. What does: "Finally, apply 3" mean? Is it "add 3"? Is it "multiply by 3"? Apply 3 in what way? "You calculate the score by getting the average of 1 and 3 then add 4" Uh.. Okay.. that's a constant. It's 6. "add half a point per monoprop used" - As of right now KOS doesn't provide access to translation controls. (which makes docking pretty damned hard as you have to rotate and use main engine for each little correction). You never explicitly said so but it looks like you're going for a system where low score is best. You really need to say that explicitly if that's the case. Also, as KOS is under development, you need to state the version the challenge uses, or reset the challenge each time a new version comes out. Each iteration of KOS makes the task easier so it's unfair to compare a score from version X to a score from version Y. You didn't state it explicitly but are you allowed to put a KOS scs part on BOTH ships? That may make this possible, otherwise it cannot be done in the current version as there is no way to query the orientation of a vessel, but if it has its own KOS SCS part on it it can rotate itself to a known position.

Same here. But as I grew up and learned more about programming I also realized that this toy I grew up with didn't represent how language worked out in the real world. The idea that you'd want to forgo function calls to simulate being in the 1980s makes no sense when function calls existed a lot longer than that. Besides, even if you were doing raw assembler in the 1980s you still had access to a lot more of what the hardware had to offer so you could at least manipulate a stack manually and therefore implement function calls with return parameters and everything. KOS is a strange combination of not being able to do it the low-level way and ALSO not being able to do it the high-level way either. This argument would make perfect sense if you had been suggesting something that would make the game more fun. You weren't. Diminishing returns on antennae would reduce fun.

Languages have had functions a LOT longer than the 80's. To give a single reference point for example, the "C" language was invented in 1970. One good idea. It's *already* pretty unrealistic how many antennae are needed. Why make it even worse? Number of relay satellites NASA needs to communicate between Earth and the Voyager probe: zero. The way real space programs deal with the long distances of communication to very weak probes operating on very small amounts of power is simply to build higher-powered stations on the Earth end of things to compensate. Sending a relay probe halfway between Earth and the target probe in order to allow you to get away with lower transmission power on your Earth station actually makes things more expensive overall, because a kilogram of payload can buy you a heck of a lot lot of kilowatt-hours on Earth. This would be good. I'd like it for debugging reasons. It's frustrating that when there's a crash into terrain the stats on the terminal screen are gone and you can't tell what it was printing out. Before key bindings how about just a simple blocking IO 'read line" command for prompted input? I'd like a better way to query what parts are installed on the craft. I.e. type the command: "LIST PARTS". See that? I'd like that available in a data structure the script can iterate over and read. i.e. When writing a landing script it would be nice to check to see if any parachutes exist.

I always assume I will want enough antenna range to copy over replacement code. I may have found a bug or made a better version of the routine by the time the probe gets where its going. The point is that if you have enough range to do a copy, you also have enough range to just run the version that's on the archive itself. About the only thing you can't do this way is have the same NAME for two versions of the same the program like you could if it was in two different places. As long as your two different versions have two different filenames, they can both live on the archive back home. In order for the 10k limit to really have meaning, KOS would have to be changed to only allow software copying from a remote drive and stop allowing direct running of software that's on a remote drive. I'm not sure I'd want to see this fixed though, because the way the limit is enforced I don't think is really fair. While it's true that you get penalized for writing sloppy code that's overly complex, you ALSO get penalized for the good practices of using lots of comments and for using longer variables names, and indenting correctly, none of which would cost a thing if your space was really this tight because if it was really this tight you wouldn't be sending source code you'd be sending compiled code.

Yeah the first step would probably have to be separating everything about parsing the text from everything about executing a statement once you understand what it is. That makes the parsing part more easily changed to a drop-in replacement. Right now it's all kind of mixed together which makes changing the parser kind of hard. The curse of too much success can be a good problem to have.