Dunbaratu

Rather than implement a messy newline stripper for what I'm certain will just be a temporary problem, I'll just stick to 0.7 until 0.8 is patched. If it takes a while because of vacation, that's fine.

I suppose that since I edit my code outside KSP and run it through a comment stripper I could add the newline stripper to it just to get it to work... But I don't know if the persistence save file will tolerate that. (Code stored on a vessel's drive instead of the archive becomes lines of text in the persistence file. I don't know how well it will like having one VERY long line in the file.

Further testing shows: It works in INTERACTIVE mode but not in a file. i.e. type at the console: if 1 < 2 { print "works". }. and it works. Put the *exact* same thing in a file and run the file, and it doesn't. Also, if you put a space between the ending curly brace "}" and the period, then it doesn't work even in interactive mode either.

The new features of 0.8 look neat, but obviously it's unusable until the brace parsing is fixed. Back to 0.7 for now...

Yeah the UNTIL syntax is broken and also IF. It's actually not the UNTIL or the IF that's wrong. It's the curly brace block parsing that's wrong. ANY curly-braced section that spans more than one line isn't working. So both of the following parse correctly: if x < 2 { print "x is less than 2". }. until x < 2 { print "x is sill not less than 2". }. But both of the following fail: if x < 2 { print "x is less than 2". }. until x < 2 { print "x is sill not less than 2". }.

Define how its broken. I suspect if it's broken that badly it will likely get a quick patch fix. Hardly anyone can do anything if looping is impossible.

I think the requirement to use global variables does make things a bit messy but it also is in keeping with the idea of ancient klunky programming practices. My only annoyance with that is that I can't make a library of re-usable routines to share if I have to constantly worry that I might be using a variable someone else used in their code that calls my code. For now I'm using namespaces to get around this, i..e "all the variables in this routine will begin with a prefix of 'tf'".

I think there's a categorical difference between a mod that exists for reasons other than KOS that happens to have some KOS hooks in it, versus a mod that exists entirely for the purpose of doing nothing but containing KOS hooks (like the sensor reporter mod). Basically, the type that only exists to provide KOS hooks could in theory be merged in with KOS itself, if the authors are amenable to the idea. That's the key difference between them.

Well I wish I knew why everyone's getting different behavior then. One possible explanation for why it's not exactly the same for everyone is that the code in question that does the initialization is inside a hook function that KSP calls whenever a spaceship part (like the KOS computer) is loaded into the full physics engine, and this seems to be called multiple times in some cases. Whatever it is that causes the KSP game to sometimes call the initializer more than once, it would mean that in the cases where it's called only once it would fail (because the selectedvolume is set AFTER the initCPU happens), but in the cases where it's called more than once it works (because the selectedvolume was set on the previous call when initCPU happens the second time.)

I can verify that it does help for me. Launch a new craft and type "LIST." as my first command and the terminal freezes in exactly the way you describe. Launch a new craft and type "SWITCH TO 1. LIST." and it doesn't.

I do agree. People have tried many times in the past to achieve some sort of a utopian programming language in which you just let people write their commands out in "normal English". It *NEVER* works. Ever. It always ends up being a language that superficially looks sort of like English but is just as hard as any other programming language is and you still have to memorize its syntax as being something distinct from English. And people keep making the mistake of thinking that the reason it didn't work out in the past is something deficient about the programming - that with better computers or better software it can be solved "this time around". They fail to understand that the specific implementation isn't to blame, English is to blame. You can't make English into a formal logical language. Its just too sloppy. And this isn't just English that's like this. ANY natural language will have been built by a long history of logic fighting against incorrect sloppy common usage, and incorrect sloppy common usage winning every single time until eventually its been common long enough that its no longer incorrect. Natural languages are by the very nature of how they come into existence, NOT logical. This is why they don't work as programming languages. Next time you're tempted to try making English into a programming language, open up the license agreement on a bit of software, or read a legal ruling online. That monstrous lawyer-speak is what a natural language turns into when people are trying to use it in a way that removes all ambiguity from it. That mess is that way because otherwise the flexibility of the English language itself would leave behind major loopholes in the legally binding text.

No that's different. IF's are fine as they are. IF means "check this right now and if true at this very moment do this thing once. ON means "set up a continuous check that will check again and again after each and every statement to see if this has become true, and if it has become true then escape out of whatever you're doing to do this one thing, then go back to what you were doing (and stop the continual checking this statement did as well - remove it from the watch list). I agree with you about Action Groups being a precious resource, but the ON command can be used on ANY boolean variable including ones you make up yourself. It doesn't have to be used with Action Groups.

No, you're not dumb. This is a bug that's not your fault. All KOS CPU modules have a concept of "SelectedVolume" stored internally. (It's the variable that tracks the result of the SWITCH TO command.) The bug is that when a ship is first loaded onto the launchpad, although it has a Volume on it, it hasn't had its SelectedVolume variable initialized to point to it yet. It still points to null. There is a fix for this in the development version so I think we'll see it in the next release. In the meantime, to avoid it, just make sure the very first thing you do when you start off a new craft is go to all of the KOS-enabled parts installed on it and bring up their terminals and have them all do a SWITCH TO 1.

Oh THAT is how you use wheelsteering!! I kept trying to use it like you use steering - to lock it to a direction rather than a location. I assumed it was just like steering, but in 2D instead of 3D, so you just give a heading compass angle only. That would make sense (and actually be useful). Any chance we can make wheelsteering work by a heading too? Since KOS knows the types of objects it should be able to distinguish between being given a string (a named target), a LATLNG( A location), or a single number (a heading) and behave accordingly.

That sounds like what's happening.

In numerous examples and code the ON command has been used wrongly. Very Wrongly. I suspected it didn't make sense how people were using it when I first saw it but since everyone was already doing things this way I assumed it must just not work the way I intuitively guessed it did. A recent issue raised in the github made me go back and revisit that assumption. I started suspecting again that my original suspicions were right, given a complaint about how loops get very slow and memory usage leaks when a loop has an ON statement in it. I made a test to see if it works the way I originally thought it did, and it does, and the way we've been using it is VERY wrong. This small example program illustrates the problem: done off. until done { on ag1 print "action group 1!". on ag2 done on. wait 1. print "loop iteration.". }. Looking at the code and thinking the way people writing their KOS code have been thinking, you'd think it would just loop forever one second per iteration, and then when you press ALT-1 it will print "action group 1!" and then when you press ALT-2 it ends, like so: loop iteration. loop iteration. loop iteration. loop iteration. loop iteration. action group 1! [color=red]<- user pressed ALT-1[/color] loop iteration. loop iteration. loop iteration. action group 1! [color=red]<- user pressed ALT-1[/color] loop iteration. Program ended. [color=red]<- user pressed ALT-2[/color] This is in fact NOT what it does. Each time you execute the ON command it inserts a brand NEW event trigger into the watchlist even though one was already there. Therefore what the code actually does is this: loop iteration. loop iteration. loop iteration. loop iteration. loop iteration. action group 1! [color=red]<- user pressed ALT-1[/color] action group 1! action group 1! action group 1! action group 1! loop iteration. loop iteration. loop iteration. action group 1! [color=red]<- user pressed ALT-1[/color] action group 1! action group 1! loop iteration. Program ended. [color=red]<- user pressed ALT-2[/color] It prints out the statement once per iteration of the loop that had previously occurred since the last time AG1 was pressed. This is because each time ON... is being executed it's inserting a NEW hook into the condition watcher. My example makes sure the numbers are small so you can see what's happening, but now try it again with the "wait 1" removed. Now it spews out a LOT of "action group 1!" lines because the loop was running at full speed and running the "ON" command a lot of times. It also was inserting lots of the action group 2 triggers as well, but since all that trigger does is set the boolean variable "done" to true, you don't notice. If it sets "done" to true once or does so 100 times the effect is that same in the end. So this has been happening all along and we didn't notice. This goes back to a comment I made a long time ago in this thread about how we don't REALLY have the ability to set up a trigger that re-executes EACH time a condition is true. This practice of putting an ON inside a loop is NOT enough to fix that problem, as it creates this new problem of clogging the mod with zillions of redundant pointless trigger hooks. I think we really could use a way to differentiate "EACH TIME X is true do Y" from "JUST THE NEXT TIME X is true do Y just once". in the language. In the meantime, I *THINK* this might fix the problem (I don't have KSP running right now so I can't test it. But you can see what the logic is meant to be): Change instances of this: until blah { on AG1 someCommandHere. restOfLoopBodyHere. }. To this instead: insertAG1Hook on. until blah { if insertAG1Hook { insertAG1Hook off. on AG1 insertAG1Hook on. on AG1 someCommandHere. }. restOfLoopBodyHere. } Basically it only inserts a new AG1 if an AG1 hook has just happened. If the previous one has not triggered it won't make another one.

Kevin's been making some changes to try to make it so that expressions work universally the same everywhere instead of this weird thing where valid expressions are recognized in SET statements but not in other places. I suspect this ended up being part of that. Once PRINT AT is changed to expect (expr,expr) instead of (num,num) then you get the use of variables for "free" with that.

All a maneuver node is is a direction, a location or time at which to do it, and a delta-V magnitude. The other information you see in the user interface is derived from that (like how many seconds it thinks you'll burn - that's not stored in the node, It's calculated based on your current active engines, current mass, and estimate of how fast that mass will change as you burn given your ISP.) I figure all you need to do to add maneuver node setting to KOS is make a routine that lets you pass in a vector and a number of seconds into the future at which to do it. The vector gives you both a direction and a magnitude, and in this case the magnitude is the delta-V you want from the maneuver. The seconds would let you specify where the burn happens (it happens at where I'll be in N number of seconds from now). I'm in the middle of looking at the github code on KOS to see if I can add some of the functionality that I currently have as side scripts that I really think is basic and missing, like letting the script writer seamlessly translate vectors into directions and visa versa. You shouldn't be having to resort to running the matrix algebra in KOS script (like I am now) to perform transformation rotations just because the language is missing the ability to do things like cast a direction into a unit vector.

Yes. I thought it was the problem I was having with my program but it appears to be unrelated. I fixed it in my local copy and made a pull request for it on github, but my other problem sill persists. The problem is this: When you first bring the vessel into the full physics engine (i.e. put it on the launchpad). the KOS mod initializes each SCS part on the vessel by doing (among other things) the following two activities: Hi! I'm an SCS CPU. Here is my initialization I'll be doing: 1 - My variables start off as null. 2 - Initialize all the variables that track my state, including the variable that keeps track of which of the volumes I can see is the one I've selected. (I can see more than one volume if I'm not the only SCS CPU on this vessel). 3 - If I'm brand new (not loaded from persistence file) such that I don't have a hard drive yet then make a new hard drive for myself. The problem is that steps 2 and 3 need to happen in the opposite order. At the moment it initializes "which drive am I pointed at" the line right before it creates it's own local harddrive. So it's initializing the current selection to null. At the moment the only way to avoid the bug you describe is to make sure that the very first thing you do on the disk is SWITCH TO 1 -even though 1 is meant to be the starting default Volume it isn't at the moment.

At least you've gotten SWITCH TO to work. My recent KOS project is on hold because something is really broken that I'm fairly certain I didn't cause but is some underlying bug in KOS that my code is triggering. When I run my latest attempt at a program it just makes all of KSP freeze and here's the weird thing - not always at the same place. I even went as far as installing Visual Studio and learning just enough C# to insert debug printing statements in the mod to discover exactly where it's getting stuck. I still haven't worked it out - it gets stuck somewhere outside the actual language processing code. Somewhere in the Update event handling system that executes one line each clock tick just gets hung completely halfway through and I have no idea why. I still haven't been able to trace down the set of conditions that cause it to happen but I know it only happens with the code that does copying and switching and volume renaming along the lines of what you're doing. As far as your change, I like the idea in general.

Have other people seen this effect? I'm driving a rover up out of a Mun crater onto the rim, and when I get to the top and move out onto the first flat polygon atop the rim, it behaves like it's made out of slow muck or sand. The rover gets slowed down on that top polygon a LOT such that I can only make about 0.3 m/s trying to drive it at maximum speed. I have to creep slowly off that terrain polygon onto the next one before the wheels finally break free and it starts driving normally again. I thought it was just a fluke the first time but I've done enough rover driving now to see that it tends to happen a lot on the edges of lots of different craters. This polygon bogs down rover. | | | .----. _____ crater / \__ rim / \__ / \__________ / \ | / \ | / / \ | / / These polygons act correctly. /

Making them is cool. I was worried about the idea of making them "automatically". Giving me the ability to write KOS code that lets ME set maneuver nodes *I* calculated is great. I was worried because I thought the goal was to find a way to let the mod calculate it INSTEAD of me. What makes KOS so great is it lets me make my autopilot instead of somebody else's autopilot. Mechjeb would appeal to me a lot more if I was the one who wrote it. Since I'm not, it feels like I'm abdicating part of the game to someone else to play it for me.

There's a certain point at which if too many features are added to KOS it becomes just mechjeb. Right now there is a VERY important difference between mechjeb and KOS, and that is that KOS makes you write your own autopilot rather than giving you a working one out of the box that someone else wrote for you. I like getting information on the positions of planets so I can calculate intelligently when to perform transfer burns. I'm not so sure I like just being handed the transfer burn predeclared on a silver platter though. Giving us more access to the game's data than KOS gives is good, but making decisions for us sort of takes away the point of using KOS over using mechjeb.

Well that's backward. You have to do to "Advanced" to get it to do LESS. Erm Okay. Well anyway thanks for the heads up.

So many things to mention: 1 - LOCK STEERING TO TARGET should instead be LOCK STEERING TO TARGET:DIRECTION. ("TARGET" is a string - the name of the vessel being targeted.) (edit: okay stupid bbcode, look, not everyone who types a punctuation mark meant it to be a stupid smiliey!!! STOP DOING THAT! The smiley you see above is a colon followed by a letter "D".) 2 - "Out of Range" means you are trying to manipulate files on the archive drive but the archive drive is too far from the craft and you don't have antennae to reach it. More info here: http://kos.wikia.com/wiki/Remote_Updates 3 - I have seen KOS bug out in such a away that you can still type but you can't SEE that you're typing until you hit ENTER. Then you finally see your text appear, but it never gets executed or does anything. I have no clue what causes this but sometimes rightclicking the SCS on the ship and selecting "toggle power" off and on again will unstick it. It's definitely a bug though. Because the bug sometimes gets triggered by manipulating the volumes and switching volumes that might be what you encountered. When the bug gets really bad, it can hang all of KSP and require you to CTRL-ALT-DEL and kill ksp.exe. But I've never seen it get so bad you have to actually reboot the computer.