Desrtfox

Are you using the same save game though?

Just an FYI regarding this issue. I'm having something very similar happen, though I'm not sure it's identical. I've lost my map for the Mun, but my map for Kerbin and Minmus is fine. Specifically, it looks like Kethane is confused and actually tries to draw the Mun map centered on my active vessel. Furthermore, when I zoom in or out, the map zooms extremely fast as though Kethane can't figure out what scale it should be drawing at. During play last night, the Mun map temporarily fixed itself, but then went wonky again later. I do not use a mod manager, but I do run a lot of mods, and I've seen some other strange behavior not tied directly to Kethane, so I'm not sure if the Kethane issue might be some kind of memory issue. Regardless, I'd really like to have my Mun map back

Thanks for this Payload. I'm going to test out setting up actual burn times for my circularization burn scripts now, considering mine was more of the loop until correct method, and while working, was rather slow.

So, I did find the time. Here's the find and replace expression for use with Textpad (my script editor of choice): Find: \.\([^0-9]\)\|\.\($\) Replace: ;\1 Other editors should have similar syntax.

I agree. I don't have time to actually build the regex at the moment, but the logic is pretty simple: Period followed by not a number, switch to semicolon. Period followed by EOL replaced with a semicolon. I think that'd do it.

With respect. The . being end-of-command is a problem in and of itself. No you can't simply do a find=replace - precisely due to the . being overloaded. This is why it's already a problem. Having said that, a pretty simple regex will get you where you need. the logic would be: period followed by not a number, switch to semicolon. Period followed by EOL replaced with a semicolon. I think that'd do it. Also, most scripts will have timings and triggers that depend significantly on the vessel or situation, so yes, you're going to have to comb through the code in most cases anyway. Assuming, of course, the code is in anyway nontrivial, you're going to have to look it over and understand it, so converting the terminators won't be much of an extra burden on that process. I'm in the ; as default camp, but I know that Kevin wants the language to be as englishlike as possible, but if there's a possibility for a more "standard" terminator to be used, I'm all for it. For me at least, having the option for the semicolon would make writing my own code much more pleasurable, which, I'm guessing that I'm going to be doing much more of that than downloading code from elsewhere. So, this option sounds like a quality of life type improvement.

While I understand the concern about sharing compatibility, I for one, would really like to see the option at least to terminate with semicolons. There's a reason this is almost universally used in programming languages. It doesn't conflict with most expressions, and is second nature to those of us who program. Secondly, the idea that one should be able to simply cut and paste someone else's kOS code into their program is a little unlikely anyway. Usually, there will be some modification necessary, and to me, switching a terminator would hardly be the most difficult part of the translation. I vote for the optional terminator of semicolon at least.

OK, that seems reasonable. I have to confess here, that I was just posting generally useful scripts, not focusing so much on the scenario laid out in the OP. Sorry about that, I came in from the kOS thread and just assumed that this thread was a script exchange kinda thing. I'll take a look at the actual mission now! I don't see the perfect circ script though. I see one from Payload that appears to be similar to what I've done. I'll try his out and see what I get.

Just for the record, I'm pretty sure this is untrue. Prograde does mean in the direction you are orbiting, and it does take into consideration your speed relative to the center of the gravity well you are at, but not velocity relative to the surface. For instance, in a polar orbit, prograde is going to mean what you think it should mean - in the direction you're going. Driving on the surface with a rover, or any suitably slow craft, you need to consider that the body you are sitting on is spinning, and thus, imparting velocity to your craft even though it may be sitting still on the surface. So, in this case, prograde may not mean what you expect due to the high westward velocity imparted by the rotation of the planet. Now, if we could compute this velocity imparted by the planetary rotation, and subtract it out of the prograde vector, we would be left with the surface velocity vector. I don't know how to do this off the top of my head though.

Just an FYI to anyone using this. A good rule of thumb seems to be to set the switch intake air value to about 1/10 of the original value of your intakes. I've done this with two SSTO spaceplanes of vastly different masses (though both SABRE jets with TWRs in the 2 to 3 range) and it seems to work well. Here's the second SSTO: http://steamcommunity.com/sharedfiles/filedetails/?id=173554539 Apparently, the circ burn portion of the code still needs some work though. Occasionally, it pushes part periapsis causing the burn to stop.

Here's my code for a sabre based SSTO spaceplane. In my case, the TTW is about 2. Also, this gets a little toasty towards the end of the run, so you may need to adjust targetVert and possibly the intake air switch point for the sabres. I can post the craft as well if you'd like: print "initializing". lock air to <IntakeAir>. set targetPitch to -55. set targetVert to 82. set tAlt to 100000. brakes on. lock throttle to 0.3. stage. wait 12. brakes off. lock throttle to 1. lock steering to up + R(0,targetPitch,-90). until altitude > 150 { if verticalspeed < targetVert {set targetPitch to targetPitch + 0.5.}. if verticalspeed > targetVert {set targetPitch to targetPitch - 0.5.}. if targetPitch < -85 {set targetPitch to -85.}. if targetPitch > -40 {set targetPitch to -40.}. lock steering to up + R(0,targetPitch,-90). set air to <IntakeAir>. }. gear off. until air < 0.26 { set vertDist to verticalspeed-targetVert. set targetPitch to targetPitch - vertDist/40. if targetPitch < -85 {set targetPitch to -85.}. if targetPitch > -40 {set targetPitch to -40.}. lock steering to up + R(0,targetPitch,-90). set air to <IntakeAir>. if vertDist*vertDist < 300 {wait 1.}. }. toggle ag1. lock throttle to 0.75. rcs on. lock steering to up + R(0,-55,-90). wait until apoapsis > tAlt. rcs off. lock throttle to 0. lock steering to prograde. until eta:apoapsis < 5 { if apoapsis < tAlt {lock throttle to 1.}. if apoapsis > tAlt {lock throttle to 0.}. }. set t to 0.5. lock throttle to t. until periapsis > (tAlt* 0.99) { if eta:apoapsis > 5 { set t to t - 1/10.}. if eta:apoapsis < 5 { set t to t + 1/10.}. if t < 0 {set t to 0.}. if t > 1 {set t to 1.}. lock throttle to t. }. Here's a screenshot of the craft in orbit, so you can get an idea of the launch vehicle: http://steamcommunity.com/sharedfiles/filedetails/?id=175440122

There's no sqrt() function, but you can do x^y, including x^0.5 so yeah, we can compute square roots.

If anyone's interested, here's my script for boosting to orbit using a sabre engine system (From B9). This rocket has a TWR of about 3.3, but I'm hoping the code works for rockets of varying TWRs. Also, action group 1 is used to switch engine mode. set air to <IntakeAir>. set tAlt to 100000. set maxAccel to 40. lock throttle to 1. lock steering to up. stage. wait 4. stage. lock throttle to maxAccel * mass/maxthrust. wait 1. until air < 1/6 { set x to x - verticalspeed/135. if x < -85 { set x to -85.}. lock steering to up + R(0,X,-90). lock throttle to maxAccel * mass/maxthrust. wait 1. set air to <IntakeAir>. }. toggle ag1. rcs on. lock steering to up + R(0,-55,-90). until apoapsis > tAlt { lock throttle to maxAccel * mass/maxthrust. }. rcs off. lock throttle to 0. lock steering to prograde. until eta:apoapsis < 5 { if apoapsis < tAlt {lock throttle to maxAccel * mass/maxthrust.}. if apoapsis > tAlt {lock throttle to 0.}. }. set t to 0.5. lock throttle to t. until periapsis > (tAlt* 0.99) { if eta:apoapsis > 5 { set t to t - 1/10.}. if eta:apoapsis < 5 { set t to t + 1/10.}. if t < 0 {set t to 0.}. if t > 40 * mass/maxthrust {set t to maxAccel * mass/maxthrust.}. lock throttle to t. }.

I can confirm this lockup as well. Also, it seems that copying to 0 isn't always working. So far, it seems like copying to 0 won't actually save your changes if you are copying anytime after program execution. Anyone else seeing this?

At the risk of being woefully wrong again, I'm going to jump in here. I have been messing with the vectors quite a bit to try to get a handle on them, and I think it's more complicated than this in the background. First, regarding UP. I believe this is a vector that runs from the center of the current gravity well to the active ship. This vector will change in direction based on where above the surface of the planet, the ship is. I believe that this is why we need to add the UP in to our steering commands. Imagine that you're circumnavigating Kerbin. The UP vector is the vector that connects the center of the planet to your ship so as you circumnavigate, that UP vector is rotating around to match your ship location. Now, imagine you want to set your ship to a +30 degree incline from the horizon. If you just set your steering to a static direction vector, you would slowly pull up out of the atmosphere as the surface of the planet pulled away from your static vector. Now, if instead, you used UP + some rotation, your angle is always relative to the UP vector, which changes direction based on your ship location. In this way, you can maintain a fixed angle relative to the surface. This is all speculation on my part, so take it with a grain of salt.

Great news. Also, it turns out I was wrong about the need for the declare as well. Set does the declare for you. So, the only part I was right about was the vector bit. Woohoo, go me!

I'd be surprised if this is working at all. All the lines like this: set vThr to vThr + 0.05. with a floating point number are going to be interpreted as: set vThr to vThr + 0. Unless I'm mistaken. Also, I don't see any DECLARE statements for your intenal variables. Last time I tried this, I got an error until I added the declare statement. The reason that you're getting three numbers for velocity is that the system is returning velocity not speed, i.e a vector not a scalar.

Sorry to spam up your thread, but I clearly am not understanding the resources thing. Here's my entire code: print "initializing". print <LiquidFuel>. wait 1. stage. lock throttle to 1. lock steering to up. wait 1. stage. until altitude > 10000 { lock steering to R(0,60,180).}. until altitude > 100000 { lock steering to R(0,0,180).}. I get the error "unrecognized term ''" on line 1. That is the line with the print <LiquidFuel>. This appears to me to be exactly what's in the readme page, but clearly I'm doing it wrong.

I just realized that this same issue may be why my resources read isn't working. My code looks like this: wait until <IntakeAir> < 0.02. Clearly this isn't going to work because of the . even if the <IntakeAir> flag works. I'm going to try: wait until <IntakeAir> < 1/50. and see if that works. Thanks for letting me see this razark.

If you look in the PluginData\kOS folder, there's a file called arc. This looks to me to be a mostly text file. It has some sort of binary header, but it has all of the programs typed out in that file as plain text. With a little luck and effort, you could probably edit that file directly. I haven't tried this, but I'd like to know if you get it to work.

Yes, but you can't explicitly use the . (dot) in a line of code due to the . (dot) being considered the End Of Line character. Personally, I'd rather see the ; used for this purpose which would then, potentially, allow for the typing of floats.

I also tried <ElectricCharge> to no avail. The readme says anything that appears on the resourced drop down. Is there a list somewhere of resources that are supported?

I'm running in to another issue. Maybe I'm just not doing it right, but I can't seem to use the resource tags. I'm trying: print <IntakeAir>. This yields the syntax error again - unrecognized term ''. If anyone knows what is wrong, I'd appreciate any direction.

I'd like to say thanks for making this mod. It's already awesome, and will likely be one of the most essential mods for KSP. Bravo. I'd also like to request that it be possible to use variables inside the vector triplets. If this is already possible, then please let me know how, because everytime I try something like R(0,X,0) I get what essentially amounts to a syntax error. Thanks much for the mod!

This mod has to be installed the old pre .20 way. i had this same issue when I made a folder in GameData and put the files there. the files need to be put in the plugins and parts folder directly stemming from the KSP folder, not the GameData folder.