Payload

BTW Kevin, I was reading your blog and saw. I think that is a terrible idea. Imagine the compatibility issues. How will one person who uses ; share code with someone who uses . or ^ or $ or.......? The fullstop is fine. On a side note. <resource> Still doesn't work in expression. Although, stage:resource works perfectly now.

Why would you need to put more in the loop? All it does is hover? You really should keep your loops as simple as possible. If they are too big and nasty, consider breaking the operations up into smaller loops. You don't want your computer trying to do everything all the time. NEVER, I repeat NEVER, print anything in a time critical loop. Print takes ages. I did a little testing of orbital eccentricity calcs. set Rneg to ((apoapsis + 600000)-(periapsis + 600000)). //Where 600000 is the mean radius of Kerbin. set Rpos to ((apoapsis + 600000)+(periapsis + 600000)). set Eccentricity to (Rneg/Rpos). print Eccentricity. That is only for Kerbin. I haven't figured out how to make use of the Body command since it returns a string and not an integer. Facepalm. That could probably be shortened to one print command. I haven't bothered yet. There is also hundred different ways to do that math. YMMV. It gives the correct answer. That is all I'm worried about.

No. SAS removes all (Steering) control from kOS. Leave it off until your program is done. Derp, not all control just steering. Someone asked about staging. This is how I have been staging. set Count to 3. //Where 3 is the number of asparagus stages. set StartFuel to <liquidfuel>. //Where startFuel is the total amount of Liquid fuel your rocket has. until orbit = 1. // Loop with conditional close. { set StageSolid to stage:solidfuel. Set StageLiquid to stage:liquidfuel. //Loop tracked variables. set Lfuel to <liquidfuel>. if Lfuel < StartFuel - 1081 AND Count > 0 { stage. set StartFuel to Lfuel. set Count to Count - 1. }. //Stages parallel liquid and asparagus. Where 1080 is the amount of fuel in one stage of asparagus. if StageSolid > 0 AND StageSolid < 1 //Stages Solid paralleled on Liquid. { stage. }. if StageLiquid = 0 AND StageSolid = 0 //Stages Solid and Liquid and Decouplers in serial. If the rocket has 0 liquid fuel, it wont stage. { if Lfuel > 0 { stage. }. }. }. The only special case I can think of where the above script will fail to stage is Solid fuel paralleled on solid fuel. If you want that, you can do something very similar to the liquid asparagus/parallel section.

I'm betting it's just too slow. Full time 3.6Ghz intel quad here. Ati 6970 2gb video card. In a desktop that cares nothing about how much power it's chooching from the wall. Your laptop isn't what I would consider slow, but the way this game treats CPU's.... I tried with ships from around 1.0 TWR to way over 2.0. The problems for me started below about 1.5TWR. Hover height started to vary around 4m. Too much for a nice dainty landing. Still, we can't reduce HZ speed with thrust until we get the values exposed. You could just use a drogue to cancel your HZ velocity and cut it when you are within a range you are comfortable with. Until then all of this landing talk is speculatory at best. Just to update. I've added an exit option to the main menu but until we get an EXIT AND RUN command the menu doesn't work with the actual program modules. Even if the menu is done it doesn't actually end until the program you called with run is over. That keeps the modules from actually controlling your craft.

My script is for circularizing a know condition. It's quite flexible as I have used that script to launch to 300km and to 80km and the largest eccentricity I got was .002. I'd say that was circular for all intents and purposes. I'm not sure how it will handle all conditions because it is hard coded to reduce engine power considerably when the periapsis is 80% of the apoapsis. I'm starting to think that either 20% might be too much or .05 thrust might be too little. However, it proves to be fine for my test rocket. Any proper circularization script has to take into account burn time. For that, you need to calculate twr and required dV. Once you have have burn time you can use eta:apoapsis to set the burn to half and half.

PID controllers are nice and they give us more flexibility for unknown conditions. However. I have found that a simple loop holds altitude within one meter. At least with ships of 1.5+ TWR. I can't foresee why you would be be bothered to write such a controller unless it is essentially required. I tested this hover script with a few different craft and it seems to behave as expected. until count = 100. { if veritcalspeed < 0 { lock throttle to 1. }. if verticalspeed > 0 { lock throttle to 0. }. set count to count + 1. }. Of course you could use any method the break out of the loop you wish. I setup a simple counter. I haven't timed it's relation with system time or observed any side effects of condition. It was just something to use as a loop break. YMMV. It also works equally well as a vertical speed hold. Just change the 0 to whatever. The speed of your computer might play some part in whether or not this works well. It shouldn't, as far as I can tell, but it might.

There has to be a way to set each kOS part you attach to a ship a certain folder. It could give you a dialog box in the VAB to pick a folder from the list. You could use more than one folder instead of just one called archive, and just maintain a list of folders that is the archive for that particular piece. I imagine the flow going something like this. I grab a kOS part and attach it to a ship in the VAB. A menu/dialog box pops up asking me to set a folder that will be that parts archive folder. I select a folder from the list. They are folders that the user has put in the archive folder. You could even have a way for a user to make a new folder then. Such as a text entry field. If it finds the folder you have named, it uses it. If it doesn't find it, it asks you if you would like to make one. A lot of work that Bac9 has done in B9 aerospace might be helpful. Items such as the info drive. It might be really helpful to know how that works.

I am building a flight computer comprised of modules made by others and my self. If I have a EXIT AND RUN command it is supremely easy to add and remove modules and it makes it to where they are self contained things that are easy to debug. I have tried what you suggested and had my orbit program run the splash and the menu. It did work. The only issue I have with that is I now have to cram every module into the main. It's going to get big and slow. My orbit program is already too slow. Mostly my fault, but you can imagine the nightmare with module integration. Nice de-bugg-able and replaceable chunks. That is what we are going after. This is a scripting language after all. It should be as easy as possible. The autoexec would be nice. It's not as important as break and run though. For now, that is what is really required. Then module writers only need to add EXIT AND RUN main. or whatever you wish to call it. My main menu then only has to do the same on selection. Right now I have everything set to run from main menu. The problem is then when it runs the orbit program that the program orbit no longer has control of the ship. It stages but it doesn't throttle or steer. The menu literally doing nothing. It is set to wait for end condition. Yet some how it is not allowing the orbit program full control of the craft. I suspect it is because the menu program has control of those things. I even tried moving the main loop out to the main menu and had it do the loop and the orbit program just set when flags but that still doesn't work. Break and run solves all my problems. Autoexec is nice but not nearly as important.

Just set the plugin to load a txt file called autoexec from the archive. It shall be called autoexec so that your plugin knows what to load. The files them selves are not removed and I can call those from any unit. Why not have the autoexec work the same way? Just called automatically by the terminal. If it's empty or it doesn't exist, it does nothing. If it has commands, it executes them. Like a call to MAIN with a BREAK and RUN. Even my old 286 had an autoexec.

That rocket actually flies off the top of the screen!!! Not just pretty pictures. Moving pretty pictures like a bauss.

Just a few commands so we can switch to the right volume and start the main program whatever it might be named. That way we don't have to console hump to get going. Just power up. I'm sure other more creative people can think up other ways to use it. But that is what I would use it for. Would be nice to just be able to toggle the power when I want to test a revision.

Menu system progress. I need sleep.

I have a strange question. How do I get one program to end before the next one starts? The linking works fine until I run my main menu script which is similar to the menus I have put in my programs. Well when I call run from the menu it does run the script but the craft is not controlled anymore and it doesn't throttle up. It just stages. Well I wrote a splash screen that shares none of those variables and it can launch and run the orbit script. When I made it to orbit I noticed it ended both programs. I know it seems like a non-issue for most people right now, but I'm there already. I need someway to make sure one program has ended before it runs the next one linked. And I could really use some sort of autoexec. On a side note. I think I might have to edit that font to fix the jacked up backslash so my rocket art looks sexy. Also gotta love that ugly menu. I think the bottom is a little far to the right.. HAHAHA

Retrograde just means west in this computer. I hate to tell you. If it were that easy we would be showing it off already. Now if there is some new development I haven't heard about. By all means enlighten us. I'm sure the landing guys would love to have it for Test vehicle 2.0 time. Test vehicle 1.0 is slated to land capsule only like apollo. Test vehicle 2 is where we attempt to make the software compatible with a much wider range of rockets. I was hoping to get an Apollo style code out because I know there are a lot of people who would love to be able to recreate that as accurately as possible. The Apollo guys had to manually cancel horizontal velocity. At least Neal Armstrong did anyway. I can say that I have made a boat load of headway. My launch to orbit code now stages "all the things" perfectly without jacking your chutes or anything else. Even asparagus! I have some work to do on my menus and I'm not entirely sure how I will handle that now. I was thinking of using a separate program for setting of initial values then when done executing the launch to orbit program. I think that will work as far as variable retention. For real this time. Staging all the things launch to orbit code. For asparagus, all I need to know is the amount of fuel in the two sections you intend to drop off when empty and how many asparagus stages you have. It's rough and it's full of unneeded variables and resource tracking that isn't required anymore. When I wrote the majority of this the direct values didn't work in expression. I will start working on getting it cleaned up and getting the main menu system at least started. clearscreen. set rpAlt to 100. set rProgram to 90. set r to 180. set p to 0. set y to 0. set orbit to 0. set tOrbit to 100000. set hAtmo to 69500. set tAngle to up + R(y,p,r). set tThr to 1. set turn1 to 9999. set turn2 to 14999. set turn3 to 19999. set turn4 to 24999. set turn5 to 49000. set selection to 0. set flagup to 0. set flagdown to 0. set confirm to 0. set Count to 2. print "Select your orbit altitude.". print "--------------------------------". print " ". print " ". print "Use action group 9 to add 10Km to orbit alt.". print " ". print "Use action group 8 to remove 10Km from orbit alt.". print " ". print "Use action group 7 to confirm orbit alt.". until selection = 1 { on ag9 set flagup to 1. on ag8 set flagdown to 1. on ag7 set confirm to 1. if flagup = 1 { clearscreen. print "Select your orbit altitude.". print "--------------------------------". print " ". print "Default orbit alt is set to " + tOrbit + "m". print " ". print "Use action group 9 to add 10Km to orbit alt.". print " ". print "Use action group 8 to remove 10Km from orbit alt.". print " ". print "Use action group 7 to confirm orbit alt.". print " ". set tOrbit to tOrbit + 10000. print "You have selected " + tOrbit. toggle ag9. set flagup to 0. }. if flagdown = 1 { clearscreen. print "Select your orbit altitude.". print "--------------------------------". print " ". print "Default orbit alt is set to " + tOrbit + "m". print " ". print "Use action group 9 to add 10Km to orbit alt.". print " ". print "Use action group 8 to remove 10Km from orbit alt.". print " ". print "Use action group 7 to confirm orbit alt.". print " ". set tOrbit to tOrbit - 10000. if tOrbit < 80000 { set tOrbit to 80000. }. print "You have selected " + tOrbit + "m". toggle ag8. set flagdown to 0. }. if confirm = 1 { clearscreen. print " ". print "You have confirmed " + tOrbit + "m". print " ". print "Lift Off in 5s.". toggle ag7. set confirm to 0. wait 2. set selection to 1. }. }. set cAlt to tOrbit - (tOrbit*.2). set xAlt to tOrbit - 1000. set hAlt to tOrbit - 5. clearscreen. print "Orbit altitude set to " + tOrbit. print "3". wait 1. print "2". wait 1. print "1". Wait 1. Print "Lift Off!". stage. set StartFuel to <liquidfuel>. lock steering to tAngle. lock throttle to tThr. when altitude > rpAlt then { set r to rProgram. print "Roll Program". }. when altitude > turn1 then set p to -35. when altitude > turn2 then set p to -45. when altitude > turn3 then set p to -60. when altitude > turn4 then set p to -75. when apoapsis > turn5 then set p to -90. when apoapsis > tOrbit then { { set tThr to 0. }. until altitude > hAtmo { if apoapsis < hAlt { set tThr to .05. }. if apoapsis > tOrbit { set tThr to 0. }. }. when Eapoapsis < 1 then set tThr to 1. }. when periapsis > cAlt then set tThr to .05. when periapsis > xAlt then { set tThr to 0. sas on. print "You Are Now In Orbit". wait 1. set orbit to 1. }. until orbit = 1 { set Lfuel to <liquidfuel>. set Sfuel to <solidfuel>. set StageLiquid to stage:liquidfuel. set StageSolid to stage:solidfuel. set Eapoapsis to eta:apoapsis. set tAngle to up + R(y,p,r). set throttle to tThr. if Lfuel < StartFuel - 215 AND Count > 0 { stage. set StartFuel to Lfuel. set Count to Count - 1. }. if StageSolid > 0 And StageSolid < 1 { stage. }. if StageLiquid = 0 AND StageSolid = 0 { if LFuel > 0 { stage. }. }. }.

I"m not totally against it. Any idea of how we will make it work? I was thinking something like acceleration checking. but it will have to be tightly windowed so it doesn't stage anything it isn't supposed too.

Did you try it? Because all I did was change the dll. I took the computer unit off the craft and it went over 6000 like nothing was wrong. I put it back and crazy things happen after 6km every time. I will try to delete the entire craft file and make a new one. Maybe something in the file got bugged somehow? We shall see. I have tried everything. There is something wrong with what you have done with the part ID thing. I am actually staging things and trying to go to orbit. Give it a shot and tell me what happens. Go over 6k. I'll go dig up the info on what causes this as it has happened to a lot of mod devs. I know a few have given minor explanations of the problem that might help.

Simple serial staging. OHH THAT IS BAD CODE> If anyone tried that autostage script I'm sorry it was only the top part of it apparently, and that part was broken too. It checks for total fuel so it won't stage your parachutes unless they are on the same stage and it handles upper stage solids and decouplers. Those four variables are updated in the loop. I haven't tried removing them and using the direct terms. That wasn't working last time I checked. It won't stage asparagus. Am I right in thinking the test vehicle will be serial staged?

Look at all that math. Why calculate it again? It is already calculated. We just need the variable exposed. You must really hate free cpu cycles. I think we are just going to have to take it slow for a while. Every time we get a new update something else critical breaks. Now the rockets are having stretchy syndrome like some of the older mods and wigging out KSP. .4.5. try it. My rockets wig out KSP above 6000m now. OR AND operators work though.

You should mention that capitalization of AND/OR is required in wiki. I am in favor of more Case tense separation as long as you put it in the wiki. But yea now my launch to orbit script is finally working again. TY. EDIT: HAHA now the scripts work. Do I need to update the part and not just the .dll? Because now when the rocket gets up to somewhere around 6000m, A part of it stays there and the rest goes up and the rocket zooms off the top of my screen. I think it has something to do with your part handling. I checked and the parts are the same. Sooo. .dll related? Don't worry. You aren't the first to have the stretchy rocket problem. I know several mods have had it in the past. The last I remember was the procedural fuel tanks.

What I don't get is, the info we need to cancel Horizontal speed is right there on the navball. I wonder just how hard hooking that is. I haven't tried writing any plugins for this game. That would be one more IDE package on my machine that required constant maintenance. Some call it tired. I'm going with lazy... Might as well tell the truth about it. I bet Kevin already has it working in his little lab over there. Just laughing at us.

Sweet. Time to change them all to tObit. for now. As long as you guys don't make fun of me.

Great article here that will help with understanding of PID controllers. Caution! This will hurt your head. http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/

We can't do that right now at all. We have no way of correcting horizontal speed other than manually. Landing from orbit is going to require an atmosphere and a horizontal speed reduction device. AKA parachute. What you are talking about is a job for mech jeb. I think you're misunderstand the capability of the virtual machine we have access to. I think if we wanted mech jeb we would just use that. I don't know. Am I out of touch with what people expect this thing will be able to do? I have high hopes for sure but I don't see this ever getting near mech jeb functionality nor does it need to. We need a simple Apollo style test vehicle to start with. Test Vehicle 1.0. The current project goals are to make Test Vehicle 1.0 go up, move around, come back. Maybe late in development. We can go for mun free return etc. EDIT: I mis-read I thought you were talking about closed loop control. I think maybe you will be able to setup a loop that pulses the steering lock off and the sas on at the same time and then back on lock and sas off. That might give us enough control to cancel our horizontal speed manually.

Done. The Space Computer.

We'll the kOS release thread is starting to get clustered with code example questions and such. I thought it would be a great idea to start a new thread so that those things can be discussed without making a mess. My idea was that we build a basic flight computer out of txt modules that can be accessed from a main menu. I have a few ideas kicking around about how to do that. I could do the whole thing but then I wouldn't really learn anything and you guys wouldn't either. It needs parts. Or modules. 1. Lift off to orbit. 2. Change orbit. 2a. change apoapsis/periapsis/circularize. 3. Execute node. 4. Landing from orbit. 4a. with deorbit burn and without. That is about all I think we can do for now. As time goes on and kOS becomes more robust I think many features could be added. Notice!. Requires kOS v0.71 Update 10-15-2013. Found the time to update the Orbital calculation place holders. Circularization and Transfers are now handed with Vis-a-Vis. Added some checks to the menu system. Now you cant accidentally run the orbit script when you are already flying. May need tweaking. Added Cancel options to the Transfer and Landing scripts. You now have the option to go back to the menu when you get the burn dialog. Other various changes. 10-11-2013. Bro, do you even land? SC does! Most of the time. http://www.youtube.com/watch?v=lXvvJpWK--4 Changelog..................................................................................................................................FAR+DRE Video by Kalista Massive round of bug fixes related to Recursive ON statements. Menu now functions. Primitive landing function. Scripts hosted on pastebin. Other things I probably forgot already. 9-16-2013. Added comments to the launch script 9-15-2013. Added roll control to the launch script. Update 9-14-2013. O.K. Guys. New updates. Heading is now set via yaw with the Variable tHeading. Inclination launches are now as easy as setting a heading. The further you stray from equatorial the more Your inclination will vary from heading. Worst is polar at around 84deg inclination. 45 deg heading was 44.6 inclination. YMMV. Rockets launched into inclination should now circularize much better. Pitch is set just like it used to be only with a better term and the numbers now correspond to the Nav Ball. Throttle limiting is in. You can currently limit your TWR directly via the variable tTWR. You can turn throttle limits off with the variable throttleLimit. Auto warp is in. If you have focus on the kOS window then the auto warp will default to Physical Warp for some reason. So make sure you don't. Hohmann transfer updated with warp script. Scripts below have been updated. Scripts updated 10-15-2013. Menu system. Spash Screen. http://pastebin.com/J0YRUueD Menu. http://pastebin.com/epwUK7aN Launch to orbit. Note the eccentricity. That is correct. MechJeb said .000 http://pastebin.com/zZwek06Z Hohmann transfer. http://pastebin.com/RxN9a4n3 Landing Program. No Image Yet. See video.. http://pastebin.com/eteJFMUg I would enjoy any questions and feed back on these items as they are. Special thanks to Cpt. Kipard and Ralathon for dropping the orbital calc knowledge. Also thanks to Kalista for making great videos for us. Known issues. G-turn is not dynamic. That is getting worked on soon. As always, still need to setup a config file to run that will replace constants. The Mun is getting closer to our grasp. Once some bugs in the newest version of kOS get sorted, there is nothing stopping us. Still requires kOS version 0.71 for now. Need MORE Modules! Again, we need people to get in and write some modules. We are still missing the standard orbital ops functions. I have written the transfer to give you an example of how those things can be accomplished since it must do all of them. Grand programming experience is not required. Examples and advice are available. Everyone has to learn this language from scratch anyway. Get started now! Available test crafts can be found here. kOS Test Craft v1.0.. http://www./download/hp5epoz6u3daq96/kOS_Test_Craft.zip By Cpt. Kipard. This baby has enough dV to go to duna at least. It is also a very KSP style rocket. It's a little wobbly but it gets there. The Jebpollo... http://pastebin.com/2zp4N9MU. Serial staged Apollo like craft that I have been using for testing. Has all the things to get Jeb to the mun in style.