marianoapp

Well since you are already using our formal grammar then there's no need to expose the parser itself. Yeah! And we are also both working in related projects... what are the odds, right?

We could eventually expose an API in kOS to allow access to the built-in parser, that way Saturn can parse the code and get an AST that is up to date with the latest changes in the syntax.

We could add it, after all we're not using the lower part of the texture (the booting computer kicking animation part).

When you reach that part of the code the Tlvl variable is set to 1 and the vertical speed is less than 124m/s (because you limited it to 110m/s before) but the script keeps incrementing the variable even if the throttle is already at maximum. So when the speed is finally over 125m/s and the script try to decrease the throttle the variable is going to have a value bigger than 1 making it seem like it's not doing anything. You should add boundary checks to all the speed validations, something like IF VERTICALSPEED < 124 AND Tlvl < 1 { ... } IF VERTICALSPEED > 125 AND Tlvl > 0 { ... } Also you could move the wait out of the IFs, there's no point in asking if the speed has gone over a threshold 50 times per second.

It's not, I just haven't had much free time lately. I'll review your pull requests today or in a few days max. Try with SHIP:FACING

The throttle is a special case which requires to be updated in every update (every frame, by design of KSP) so when you lock the throttle to anything the program also adds a trigger that evaluates the lock on every update and sends that value to KSP. Due to the way the program gets compiled the trigger is added if a throttle lock exists anywhere in the program, even if it never gets executed, and since the throttle hasn't been locked to anything yet the trigger returns the default value of the throttle variable (which is zero).

I already added an issue to the tracker basically asking what the correct behavior should be. On one hand locks are like variables and variables don't have scope, but on the other hand locks also behave like functions and I'm not sure I like having functions without scope. We'll have to talk it over to find a solution we see fit.

@Xty: The problem is that locks declared in a parent program are not available in a child program. There's an explanation for why adding the "unlock throttle" line in the child program causes the throttle to unlock but that is more suited to the development thread, so I won't enter into details here. Try changing the "unlock throttle" for "set throttle to 0" which has the same effect and shouldn't have this problem.

It shouldn't, at least I have never experienced it but there's an issue in the tracker about a NaN crash even after the we added the validations. I think the parts that could be compromised are those who deal with KSP directly (like the steering helper when you lock to a steering) that are executed in the OnFlyByWire update.

Even if KSP returns a NaN sometimes it doesn't like when you send them back. Trying to, for example, operate with a vector which has a NaN or Infinity component causes KSP to crash with a black screen. I agree that the current solution is too restrictive but it was the safer way to solve this situation. If we allow NaNs back we'll have to add validations everywhere to avoid KSP from crashing. Other option I was considering is to add a config option to disable this "safe mode" and allow NaNs and Infinities back, and give the script writers a couple of functions to check for this special values. Along this we should add validations in most critical places to avoid a crash but it would be a best effort kind of thing, so you shouldn't rely on kOS catching the NaNs you missed.

@Cpt. Kipard: You are right, UNLOCK ALL is not supported due to an oversight. I just added a new issue to the project tracker so we can fix it. On the other hand I tested the "set throttle to 0." command and it unlocks the throttle as expected.

Yes, MAX and MIN. Actually my script is very similar to the solution you proposed, with the difference that the throttle ramp-up area is left to the game's own throttle up delay. The burn is then executed a little short and after it finishes a throttle ramp-down is performed proportional to the node's remaining dV (or orbit eccentricity, as Steven suggested). If you want to control the ramp-up rate you could use a lock that returns the throttle as a function of time, but bear in mind that the code won't necessarily be executed in exact intervals and that could introduce some errors.

@Steven Mading: Beware that the VECTOR suffix doesn't necessarily work with all rotations, only with those that were (internally) created using a vector. (In your old script you are calculating a bunch of stuff that is later multiplied by zero, so the script could be simpler). @Cpt. Kipard: Check the node execution script I posted here. It reduces the throttle so the burn takes at least 1s and that allows the script to time it more precisely, and also has a throttle up delay to start the burn a little early (determined experimentally, may be different for you).

@Cpt.Kipard: I just tried the "print altitude." code and it worked as it should. Please post the whatever error appear on the screen or in the debug menu so we can track the issue. @theSpeare: If you mean the dictionary error then we are aware of it and working to fix it, but it only happens when you lock the same variable to different expressions in the console, so don't do that (inside a program you can lock anything all the times you want). One of the side-effects of this error is that the console remains in an inconsistent state and every following command will throw the same error. If you toggle the power of the unit everything starts working again.

dm/s as in decimeters per second? One thing you have to take into account is that all the dV formulas assume an instantaneous change in velocity, but since that is not possible you always end up needing some extra dV to compensate for the burn time. What do you mean with "raw variables"?

A lot has changed from that release, you should try the latest pre release of v0.12 available here

You'll need to download TinyPG from here (that fork that has some improvements over the original). The auto-generated files are "ParseTree.cs", "Parser.cs" and "Scanner.cs" all of which are in the Compilation/KS folder. Once you generate the new files you'll need to manually remove the "RegexOptions.Compiled" flag from "Scanner.cs" before compiling because it's not supported by mono. As long as you don't add or remove expressions (in the "expressions" section) you shouldn't have to modify the compiler. I think that you can achieve this by just reordering some of the expressions so the "AND" and "OR" are processed after the comparators.

No, every lock es calculated completely every time is called. I think the problem may arise from somewhere else because when the game crashes the altitude goes nuts, and the pitch lock may end up calculating the square root of a negative number (and returning a NaN). If that's the case then the pitch NaN is a consequence and not a cause of the problem. You could try replacing the pitch parameter in all the headings with a fixed number and see if you still have the problem.

That's a dependency from an experimental feature which is disabled by default, so you could comment all the references to it if you don't want to add the library. In fact I think we'll have to analyze if we want to keep that dependency in the future. What do you mean? You can access it using the "THRUSTLIMIT" suffix of the engines.

I found a simpler way to reproduce the error, just lock the steering to a rotation that has a NaN component and launch (for example "lock steering to R(sqrt(-1),0,0).")

You're right, it's a bug in your script I found that you are calculating the terminal velocity using the ship's pressure sensor, but you don't have any sensor. So the density ends up as zero, the terminal velocity as Infinity and when you pass that to KSP everything crash. Changing the line "lock dense to ship:sensors:pres * atmToDens." to "set dense to 1." everything works, well, until some bug in the staging code make the rocket fail in a spectacular way We'll have to add some code to sanitize what kOS sends to KSP to avoid this kind of problems in the future.

Maybe, you should try first modding the cfg manually and if that doesn't work then use the part. Regarding the RT2 integration we already have an issue in our tracker to fix that.

Are you using ModuleManager to add a kOS module to the probe cores? Don't know why yet but that was generating problems similar to what you describe.

Which one, the problem with ModuleManager or with RT?

This happens because the script is compiled prior to be executed and "locks" are just a language construct that internally works pretty much like a function without parameters. So every time you use a locked variable in the script it gets replaced by a call to this function (all of this happens in the compilation stage). And since you can lock the same variable to different expressions a function pointer is needed (the variable with the asterisk) that gets updated every time you lock/unlock that variable.