VFB1210

^The documentation seems pretty clear to me, but let my try and rephrase it. ENGINE:MAXTHRUSTAT(PRESSURE) = how much thrust will me engine produce at full throttle and without the in-game thrust limiter engaged when the atmosphere around it is at PRESSURE? As I'm sure you know, the atmospheric pressure is highest at the surface, and gradually reduces as you head to space, when the atmospheric pressure around a rocket engine is high, it produces less thrust, because the exhaust has to work harder to move through the air. This also reduces the specific impulse of the engine. The argument PRESSURE is in terms of Kerbin atmospheres at seal level. PRESSURE = 0 corresponds to an external pressure of 0psi, or a vaccum. ENGINE:MAXTHRUSTAT(0) would return the vaccum thrust of ENGINE. ENGINE:MAXTHRUST(1) would return the sea-level thrust of ENGINE. ENGINE:MAXTHRUST(0.5) would return ENGINE's thrust in an environment with half as much external atmospheric pressure as Kerbin at sea level; quick, pulled-out-of-my-ass guess, this corresponds to an altitude of about 10-15km on Kerbin. PRESSURE can also be greater than 1, ENGINE:MAXTHRUST(2) would return the thrust of the engine at twice Kerbin's sea level pressure, or about the same pressure found at sea level on Eve. ENGINE:AVAILABLETHRUSTAT(PRESSURE) works the same as the above, but takes into account the thrust limiter tweakable setting.

Speaking of vectors and directions, I'm having a bit of trouble with them myself. Here's the code: //////////////////////////////////////////////////// //ULV210 Launch script //////////////////////////////////////////////////// //Initializations and such. copy ULV210 to archive. //Program self preservation declare function angleBetween //Returns angle between the two arguments vec1 and vec2 by using the dot product. Returns a value in degrees. { parameter dir1. parameter dir2. local vec1 is v(1,0,0). local vec2 is v(1,0,0). set vec1:direction to dir1. set vec2:direction to dir2. return arccos(vdot(vec1,vec2)). //Calculating the angle between vec1 and vec2 using the dot product. Neglected to divide by product of magnitudes because both are unit vectors. } declare function abort //Redundant here, would execute an abort and parachute deployment in a manned rocket. THIS FUNCTION MUST BE MODIFIED ON A PER ROCKET BASIS ACCORDING TO ABORT PROCEDURES. { lock throttle to 0. toggle abort. wait 10. toggle chutes. } set turnStartVel to 80. //SPEED at which the gravity turn begins. m/s set abortAngle to 10. //Maximum angle allowed between the direction the rocket is facing and its direction of travel. set turnStartAng to 10. //Initial pithcover amount. Degrees. set turnStartDir to heading(90,90-turnStartAng). //Actual direction represented by the above. Current heading is compared against this. set pitchOver to 0. set compThrot to 0. //Variable facsimile of throttle value. set throttleUpDuration to 5. //Amount of time allocated for engine thrust buildup. set ship:control:pilotMainThrottle to 0. //Zeroes out user throttle input before taking control. lock headingTest to ship:heading. //Stores current durection of the rocket. //Actual launchy stuff now. lock throttle to compThrot. sas on. stage. //Activate engines. until compThrot > 1 //Throttle up loop. { set compThrot to compThrot + 1/(500 * throttleUpDuration). } stage. //Launch clamp release/liftoff. wait until verticalspeed > turnStartVel. //Vertical climb. sas off. until angleBetween(headingTest,turnStartDir) < 0.1 //Initial pitchover loop. Runs until rocket is within 0.1 degrees of the desired pitchover angle. { if (angleBetween(headingTest,srfprograde) < abortAngle) { until pitchOver > turnStartAng { sas off. set pitchOver to pitchOver + 0.1. lock steering to heading(90,90-pitchOver). wait 0.05. sas on. wait 0.05. } } else { abort(). } } The issue is with the angleBetween() function I declare at the beginning of the program. The idea is pretty self explanatory, you pass in two directions, it maps a pair of unit vectors to those directions, and calculates the cross product to determine the angle between those two directions. However, I can't get kOS to recognize the parameters dir1 and dir2 as directions, and every time the angleBetween() function gets called, I get the following error: Value is not a convertible object: System.Double to kOs.Suffixed.Direction at ULV210 on 1, line 17. How can I get kOS to actually pass the correct data types into the function? EDIT: It appears that the issue is somewhere else in the script. After doing a (now obvious) debug test consisting of only the function it seems that the function works just fine, and somehow I'm the one passing the double into it. EDIT2: Got the issue halfway fixed, though I'm not sure how. Now it's fine with the argument headingTest (now renamed currentDir), it keeps throwing an exception with turnStartDir, although it won't tell me what. It just ends the program and points to that argument. EDIT3: Changing ship:heading to ship:up fixed it. EDIT4: So the new code works great. Now I'm having a separate issue controlling the ship via kOS. Whenever I had control over to kOS via lock steering, kOS begins inducing huge oscillations, even with extremely restricted gimbal ranges, causing the rocket to corkscrew, so I can't get through the initial pitchover portion of the gravity turn. The rocket handles like a dream under SAS, however of course kOS can't control the rocket at the same time as SAS. The only upside is that it has proven that the programmed abort function works great. Any ideas? I'm using FAR, if that's at all relevant.

No, it isn't. The angle snap glitch is still present. It's the same issue that was present with symmetry which was fixed.

Would there be any chance of getting the fixed .dll? I can't get Visual Studio to open the .csproj file, so I can't recompile it after going in and fixing the .cs file.

Well, it looks like I have the solution to that issue then! Glad to see that you and erendrake are talking. Hopefully you can get AGX and kOS to work together, that alone would create a lot of potential for complicated user controlled scripts.

Well I'm away from my computer right now, so I can't test it, but I seem to remember that it was possible through AGX to bind keys to the default 10 action groups, which kOS can access, correct? So the mapping would look something like the following: AGX Mappings: W->ag1 A->ag2 S->ag3 D->ag4 Q->ag5 E->ag6 and then kOS would interpret the activation of ag1 as a pitch down command, ag2 would be yaw left, etc. But then again, maybe I'm just remembering incorrectly, and should find some other way to passify myself for the time being. EDIT: Or maybe it could simply be done through the game's settings panel, or even an AutoHotKey script in an extreme case. Though I think an AutoHotKey script may be preferable to locking WASDQE to action groups in game, at least AutoHotKey scripts can be disabled with ease.

That could be a possibility. I have action groups extended installed, and I believe that allows me to map my own keys to action groups. I could use the action groups for input and AGX to bind them to the appropriate keys.

Okay, so suspending the initialization issue for the moment since it isn't a huge issue right now, I have another question. My current project is called AAVNAP, or Advanced AVionics and Navigation Algorithm Package. The goal is to create a fly-by-wire and autopilot system for the KSO super25 shuttle. As of right now, the shuttle is unusable because with FAR the controls are too finnicky to be able to control without computer intervention, but at speeds over anout 170 m/s, SAS causes the control surfaces to twitch violently and generate so much fake thrust that the shuttle quickly falls apart. Thus, my own system is needed. Currently, the only plan is for fly-by-wire capabilities, in which the computer takes control of the shuttle to keep it stable, while looking to user commands to determine what the shuttle should be doing. I plan to develop full autopilot capabilities in the future, but crawling before walking &c. My current dilemma is this: kOS locks out user controls while it is in control of the vehicle. This is a feature I want, because I do not want the pilot controlling the vehicle directly, I want the computer to control it according to the pilot's commands. What I want to know is, how can I get kOS to recognize that the pilot is commanding say, a left roll using the Q key, so that it may manipulate the controls to actually make the vehicle perform the maneuver? As far as I know, there is no way to make kOS respond to keypresses. (or even commands entered into the console.) So how may I accomplish this?

I never thought about that. I suppose if all variables are set to 0 when declared it would be pretty trivial. Or if they are given no value at all, wouldn't they be null until otherwise specified? If that is the case, the following might be possible: IF RUNSTEP = NULL { DECLARE RUNSTEP SET RUNSTEP TO 0 } IF RUNSTEP = 0 { //initialization stuff here RUNSTEP = RUNSTEP + 1; } ELSE { //program stuff here RUNSTEP = RUNSTEP + 1; } Although I guess that is almost functionally identical to IFNDEF.

Right, I forgot that ++ isn't in Kerboscript. Regardless, is there a way to get around the problem presented with creating your own flag value? Also, Camacha, it seems to me that the ++ notation is advantageous because it clearly distinguishes that the variable to be incremented is actually supposed to be incremented, and not that the programmer mistakenly omitted the second operand. Also, if you do not include a specific operand, wouldn't the compiler simply try to interpret the next thing after the operator as the second operand? Example: ... program.DoStuff() Foo++ Bar++ program.DoMoreStuff() ... Here, the character following the operator is the second plus sign, which has been assigned the value one in this context. The compiler sees this plus sign as the second operand, and acts accordingly. But consider the following example: ... program.DoStuff() Foo+ Bar+ program.DoMoreStuff() ... Most languages would interpret this in the same way as this: ...program.DoStuff()Foo+Bar+program.DoMoreStuff()... Thus, the program would attempt to sum the values of Foo, Bar, and whatever number program.DoMoreStuff() returned, if it returned anything at all, which is obviously not the intended behavior.

Forgive me if I am incorrect, but wouldn't trying to create my own flag value end up something like this? DECLARE RUNSTEP SET RUNSTEP TO 0 IF RUNSTEP = 0 { //initialization stuff here RUNSTEP++ } ELSE { //program stuff here RUNSTEP++ } Which would cause the program to declare the variable, set it to zero, enter the "true" part of the if loop, do initialization stuff, increment RUNSTEP, then go back to the top and set RUNSTEP back to 0 again, and repeat ad infinitum. Or maybe I'm just not thinking it through enough. It has to be possible on some level at least I suppose, or else the first() function I mentioned wouldn't exist.

So, just a small idea that I think might make some more complex codes (specifically ones that require many setup values) a little more efficient. Obviously, if you have a code that requires values to be used later to be specified ahead of time, you declare them at the beginning of your program. Like this: A = SomeValue1 B = SomeString1 C = SomeBool1 PROGRAM.DOSTUFF(A,B,C) (Forgive the non-kOS syntax, but it gets the point across.) The only issue is that the code is going to waste time redeclaring A, B, and C every time it loops. For the example program above, it isn't too much of an issue, but for more complex programs it can inefficient. Back when I played Garry's mod, there was (still is) a mod called WireMod, which adds a part called an E2 chip, which is similar to the kOS computer in that it is capable of executing computer code. One of the functions available to the E2 was a function called first(). It returned true if the current execution was the first execution of the program since the last time it was terminated, false otherwise. Typically, a code with a lot of setup would look like this: if(first()) { A = SomeValue1 B = SomeString1 C = SomeBool1 } else { program.DoStuff(A,B,C) } With the above code, it will initialize A, B, and C on the first execution, then loop back to the beginning, check if first() is true (which it won't be) and proceed to the else part of the statement, containing the rest of the program. Then, it only needs to make a single comparative operation every execution as opposed to repeatedly declaring many values every iteration of the program.

Quick question, is there a way to get kOS to simulate a keystroke in a program? I'm working with Action Groups Extended, and if I could get kOS to simulate certain keystrokes bound to action groups in AGX then that would open up a lot of opportunities to control actions without having them bound to staging, which I frequently forget to set up correctly.

Okay, so I'm trying to program the guidance for my Mercury-Redstone type rocket using the method I was describing before. Initially I had a program that worked, but was very inconsistent in trajectory that it produced. It simply waited until the vertical speed of the rocket reached a certain point, pitched it over a set amount, waited a predetermined time, and then locked steering to SHIP:VELOCITY:SURFACE: DIRECTION. The idea behind the new program is that it waits until it reaches a certain vertical speed, locks guidance to an initial pitchover angle, and then continually checks the rocket's current angle against the specified initial angle. Once it reaches an optimal angle (within 0.1 degrees of the specified pitchover angle) it switches guidance to SHIP:VELOCITY:SURFACE: DIRECTION for the rest of the gravity turn. It seems to work until I compare the actual difference in angle to the difference in angle allowed by the program. When I try to do that I get an "Argument is out of range. Parameter name: index" error. Here's the code: COPY mrbooster TO ARCHIVE. DECLARE pitchAngleInitial. DECLARE turnStartSpeed. DECLARE correctRoll. DECLARE initialPitchAng. DECLARE intitalPitchVec. DECLARE angDiff. DECLARE closeNuff. SET pitchAngleInitial TO 88. SET turnStartSpeed TO 50. SET correctRoll to R(0,0,-90). //Roll correction to keep the craft oriented correctly. SET initialPitchAng TO HEADING(90,pitchAngleInitial). SET initialPitchVec TO initialPitchAng:VECTOR. //Used for calculating when we are close enough to the initial pitchover to begin actual gravity turn. SET closeNuff to 0.1. //Ship direction must be no more than this many degrees from the correct pitchover angle to begin gravity turn. LOCK THROTTLE TO 1. //Throttle up. STAGE. //Ignite engine. WAIT 2. //Wait for thrust to build up. LOCK STEERING TO UP + correctRoll. STAGE. //Launch. WAIT UNTIL VERTICALSPEED > turnStartSpeed. //Vertical ascent. LOCK STEERING TO initialPitchAng. print "Debug1". LOCK angDiff TO ABS(VANG(SHIP:VELOCITY:SURFACE:DIRECTION,initialPitchVec)). //Checking angle between current and desired directions. print "Debug2". WAIT UNTIL angDiff < closeNuff. //Wait until we are close enough to the proper heading. print "Debug3". LOCK STEERING TO SHIP:VELOCITY:SURFACE:DIRECTION. //Gravity turn time! Keeping the rocket pointed along the prograde vector. WAIT UNTIL SHIP:LIQUIDFUEL < 150. //Burning, burning, burning. We're turning and we're burning... STAGE. //Escape tower jettison. WAIT UNTIL SHIP:LIQUIDFUEL = 0. //Booster cutoff. WAIT 5. //Chill for a bit. STAGE. //Booster seperation/posipack firing. COPY mrpostboost FROM ARCHIVE. //Load up next program. RUN mrpostboost. //Run it. It only gets as far as the "Debug2" print command, and locks up on the line of code after that. I have also tried executing it in a while loop like the one below without succes. stuff WHILE 0 { SET angDiff TO ABS(VANG(SHIP:VELOCITY:SURFACE:DIRECTION,initialPitchVec)). IF angDiff < closeNuff { BREAK. }. }. more_stuff Can anyone help me stop it from doing this? EDIT: Also, Steven, as a user and not a programmer, it seems like breaking backwards compatibility in that way wouldn't be too bad of a thing. It's not a huge inconvenience to go and wrap a couple of file names in quotes to comply with the new syntax, especially considering the kind of possibilities it could open up. Just my 2¢.

The mathematical relationship between the time since launch and eta to apoapsis is far beyond the abilities of kOS to solve. It gets ugly very quickly due to the constantly changing mass of the ship throwing a wrench into what would be a relatively simple integration of the net force on the vessel.

^^ Interesting, I hadn't thought of doing that. Ill have to try it when I get home. Thanks for the input! Also, an far as not being able to correct for perturbations by locking to ship:velocity:surface, I understand that. I actually wanted that as it would require a lot of precision, and perhaps even require me to delve into raw vehicle control and writing my own control algorithms precise enough to get the initial pitch and roll maneuvers correct. (Lofty goal, I know. But its fun to me!) It would also add the variation in final orbits that you find in real life, normal rockets don't end up within a few hundred meters of their target orbit consistently. Edit: ^That seems to be exactly what I'm looking for. Thanks!

I suppose that could work. What I'm trying to do is create a script to do a gravity turn for a suborbital rocket. (I'm using the 6.4x RSS config from Regex and haven't quite gotten used to everything, so to learn I'm trying to progress in a Mercury-> Gemini->Apollo fashion to get my bearings. If you can't tell, I'm still on Mercury.) The goal was to launch the rocket, wait until 1000m, perform the initial pitchover, and then lock the steering to ship:velocity:surface to produce a real gravity turn that is easily modified using the initial height and pitchover values. I ran into trouble with the vessel rolling to the wrong roll orientation when switching to a vector heading, and I couldn't correct it with an R() tuple because you can't add a vector and an angle tuple. The goal was to convert ship:velocity:surface to an R() tuple to enable roll guidance to keep the rocket oriented correctly. To start I needed to know which basis vectors pointed in which directions to convert from a vector to an euler angle and upon doing so I discovered the issue.

^ DECLARE someVar. SET someVar TO <throttle value>. LOCK THROTTLE TO someVar. PRINT someVar. I tried timewarping and the vectors did not appear to move at all, that was one of my first suspicions that it was due to Kerbin being in a weird orientation compared to the global coordinate system. Neither time of day nor time of year seem to affect affect the orientation of the vectors. I have not had a significant amount of time to test whether or not position on Kerbin affects them though.

Okay, I've got to ask, what is going on with these vectors? These are just supposed to be the default X, Y, and Z axes, (the red, green and blue vectors accordingly.) but only the Y axis is pointing in a direction that makes sense; hence its label, and the labels on the other two.

Well, I was too impatient to wait for stock tanks to be converted to the new 1L system, so I made some quick calculations. From what I can tell, the FL-T400 fuel tank is 1.25m x 1.875m (1.25m is a given of course, 1.875m is an estimation.) yielding a volume of about 2.3 cubic meters. 2.3m^3=2300L. Truthfully the capacity should be slightly less than that because not 100% of the tanks volume will go to storing fuel, but it's good enough. 2300/400=2.875, so 1 stock unit of fuel is about 2.875 liters. I went ahead and updated all of the volumes in Squad_modularFuelTanks.cfg to create a hotfix for anyone too impatient to wait. Here is a pastebin with the code. Just open up Squad_modularFuelTanks.cfg in notepad, delete the contents, paste that in it's place, save, and you're good to go!. EDIT: As I play with this, I notice that for some reason the .cfg update only works on new tanks, so any tanks on crafts you've already built still have the old volumes. Including saved crafts in the VAB. So yeah, this breaks crafts too, I guess.

My time to shine! I actually made a video about doing this in KSP.

Do you plan to add any way to read the vessel's current orientation? I've tried using direction, but that seems to only work when trying to assign it, as opposed to checking it.

Awesome mod! Do you have any plans to include hypergolic fuel and oxidizer? Engines using hypergolic fuels would be lighter because they lack the need for complicated injectors and turbomachinery, but would have somewhat nerfed Isp like in real life.