marianoapp

Variables with asterisks are function pointers used by locks, so I'm betting you are locking mysteer to an expression somewhere on the script. We'll have to find a way to deal with this identifiers that are used both as variables and locks in the same script.

The problem is that as soon as your periapsis is higher than your apoapsis the periapsis becomes the apoapsis and that's why the "wait until periapsis > 80000" statement doesn't work as expected. This subject was discussed previously, starting from this post.

Actually the new version is not based on that branch, the code is in the new github organization here. The grammar and syntax of the language remain the same, the changes were made in how that language is interpreted and executed. Anyway we now use a formal grammar to describe the language, and you can find it here.

Fixed By the way this project was merged with kOS so now all the bug reports should be reported in this thread (dev) or this other thread (release). Also the development was moved to a new github organization (https://github.com/KSP-KOS) so you can report the bugs there too.

I found an issue using ModuleManager that spammed the log with exceptions but I thought it was an isolated case. I'll look into it.

I bet on the parenthesis You have to adjust the direction all the time either by locking steering to an expression or manually controlling the yaw. Of course if you don't have enough torque there's no way to move the rocket.

@SBaL: wrap the two IFs with a loop, something like "until false { .... }". Oh, and add parenthesis to the expressions, they work like they should most of the time but there may be some weird behavior with operator precedence.

That was added in the last update (v11.1) so it may no be in the documentation you're reading (it's in the release notes here). To access the thrust limiter you first need to build a list of engines (LIST engines IN [variable name]) and then you can read/write a bunch of parameters of each engine, including the thurst limiter. The now official kOS project location is https://github.com/KSP-KOS and there's a dedicated documentation project where you can find more info (in this particular case here).

You can add the relevant engines to a list and then use the FOR command to iterate over it and set the thrust limit for each one (you don't need to use LOCK)

That is in my (informal) TODO list, you better add an issue in the github tracker (here) so we don't forget about it.

Are you using v11.1 or the 12.0 prerelease? We made a major rewrite of several parts of the mod and in the new version you can raise a number to any power you want.

[TARGET]: DIRECTION is the direction from your ship to the target ship, but in this case the target ("SHIP") is your own ship, so the direction is zero "R(0,0,0)". What you need to use is SHIP:FACING that returns a rotation that represents the direction in which your ship is pointing.

The exact moment to start the burn is when your are at the apoapsis of the suborbital trajectory (the top of the parabole after launch), but since the circularization burn takes time you have to start a little early so you burn evenly before and after the apoapsis. And yes, the ship mass and thrust affect the burn time and therefore how early you have to start the burn. My execnode script is this, it calculates the burn time taking into account the ship mass, thrust and engine efficiency (isp parameter). declare parameter Isp. set Ispg to Isp*9.82. set maneuverNode to nextnode. // lock the steering to the node sas off. lock nodeDirection to (R(0,0,0)*maneuverNode:burnvector) + R(0,0,180). lock steering to nodeDirection. // calculate burn time set finalMass to ship:mass / ((constant():e) ^(maneuverNode:burnvector:mag / Ispg)). // adjust thrust so the burn time is at least 1s. set burnThrottle to 1. set burnTime to 0. until burnTime >= 1 { set massFlowRate to (ship:maxthrust*burnThrottle) / Ispg. set burnTime to (ship:mass - finalMass) / massFlowRate. if burnTime < 1 { set burnThrottle to 0.75*burnThrottle. }. }. print "Burn time: " + round(burnTime, 3) + "s @ " + round(burnThrottle * 100) + "%". // throttle up delay set startDelay to 0.97. wait until maneuverNode:eta <= ((burnTime / 2) + startDelay). // start burn lock throttle to burnThrottle. wait burnTime - 0.02. lock throttle to 0. unlock steering. sas on. remove maneuverNode.

I approached circularization from a math point of view, so I first calculate the velocity needed to achieve a circular orbit and then the difference between that and the velocity I will have at apoapsis is the node deltav. Snippet of my circularization program // orbitAltitude = desired altitude of the circularized orbit // g_bodyRadius = 600km (kerbin) // g_bodyGM = 3531600000000 (kerbin) set absoluteOrbitAltitude to g_bodyRadius + orbitAltitude. print "Target orbit: " + orbitAltitude + "m". // calculate required orbital velocity to achieve a circular orbit set requiredOrbitalVelocity to sqrt(g_bodyGM / absoluteOrbitAltitude). print "Required orbital velocity: " + round(requiredOrbitalVelocity, 3) + "m/s". // calculate orbital velocity at apoapsis set SMa to (alt:apoapsis + alt:periapsis + 2*g_bodyRadius) / 2. set apoapsisOrbitalVelocity to sqrt(g_bodyGM*((2/absoluteOrbitAltitude)-(1/SMa))). print "Apoapsis orbital velocity: " + round(apoapsisOrbitalVelocity, 3) + "m/s". // add the node set nodeDeltaV to requiredOrbitalVelocity - apoapsisOrbitalVelocity. set maneuverNode to node(time:seconds + eta:apoapsis, 0, 0, nodeDeltaV). add maneuverNode. // execute the node (execnode is a program I wrote for that) run execnode(Isp).

I'm not exactly following his project, but a quick review of the planned scope leave it very close to what kOS already has, or that could easily have if we decide to add it. Point by point review: Done - Compatibility with KerboScript 0.9x - Simplified codebase - Formal language specification - Better error handling, which provides the script name and location of the error - Enhanced WHEN... THEN capability. Unambiguously allows an entire block of code to be executed on a WHEN... THEN instance - Arrays: (with lists) - Enumerators: (with lists) - Boolean values - Extended math and physics functions. - Expandable memory - Distance delay - Multitasking (there is a development branch that have threads support) - Interprocess and intercomputer communication - Easier pitch/yaw/roll system Easy to add - New operators. Operators for not-equal, bitwise AND and OR, bitwise and logical NOT - ELSE and IF ELSE blocks - Persistant WHEN... THEN: (I want to add this for ON commands as well) - A MEMDUMP keyword - Leaving scripts early A little more of work to do - Subroutines blocks with a SUB or FUNCTION keyword: locks internally are already functions, so it wouldn't be that hard to add custom user functions - Runtime exception handling. A TRY... CATCH block would be handy - Return values - Variable scope. Variables created with the LOCAL keyword would exist in their local scope - String escape sequences - String operations - User prompts - Script names storable in variables as function pointers.

Already works like that The whole config is a structure that you can modify from a script, so writing a command like "set config:ipu to ##" changes the execution speed, although there's no real need to slow down right now.

Yes, that would be interesting, right now all the configurations are plugin-wide and apply to all the savegames.

Right now there is a config option that limit how many instructions per update the CPU can execute, and you can change it to whatever you want (the default is 40 but I think it should be higher). That means that if the game is running at 30fps you can execute a maximum of 40*30=1200 instructions per second. You have to be aware that these instructions are actually CPU instructions, so for example a command like "set a to 1 + 2" ends up as 5 instructions after being compiled. If you change the config from 40 instructions per update to only 1 (still running at 30fps) you'll be barely able to execute a few commands per second, and it would be impossible to run, for example, a hovering script. In fact I think that the extra speed has to be taken into account when writing a script, because it can happen that a simple control loop is executed more than once in a single update, and that can mess with PI controllers for example that store the accumulated error.

All the features of v0.11.1 were successfully merged! Now both projects should have the same features, including the RemoteTech integration. There are a few differences in this version regarding the RemoteTech integration: - The integration is controlled by a config flag which is disabled by default (use "set config:rt2 to true" to enable it and then reload/change the vessel so the config takes effect). - The progress bar is only shown when the delay is bigger than 0.5s to avoid the flashing on the screen. - When the connection is lost the queued commands remain until the connection is re-established (the deployment of commands can be cancelled with ctrl+c/break). - When the connection is lost running programs keep running but they can't move the ship since RT2 is blocking all input (but they can print stuff on the screen). I also added a new config key "Start on Archive volume" that sets the Archive as the default volume when you reload a ship (no more "switch to archive" every single time ). To enable it use "set config:arch to true" (To view the state of the current config you can list all the values with "list config") [latest bin download]

I used module manager to add a kOS module to all of the stock command units just for aesthetics reasons. This project is a heavily modified version of kOS, but we are now in the process of merging it with the main version of kOS to have the best of both worlds

You could use a Rotation for the steering that is the result of adding your vector to a rotation that only has a roll component (similar to the "up + R(0,0,180)" that is in most scripts). If you don't know the roll before hand you will be able to get it from ship:facing:roll (this feature is in my fork of kOS but it will be merged soon).

Don't worry, I already did all the heavy lifting merging v0.11.0, this should be a little easier

Great! I just finished merging all the changes introduced in v0.11.0, so now only remains to merge v0.11.1 It's going to be a busy night...

Yes it is, you just have to create a new class that inherits from kOS.Compilation.Script and override the Compile method.

I'm all for collaboration, in fact right now I'm rearranging the project to make merging with erendrake's kOS easier. I'm going to keep adding the features that were included in kOS after my fork trying to keep both as compatible as possible. Once both projects are in sync feature-wise we can merge them into a single great one. Talking about keeping projects compatible and I already deviate when I added the capability to run programs on other units of the same vessel. This wasn't into my plans but I really wanted to make a dropship that released drones.