Space Computer. Brought to you by kOS and hopefully many nerds.

[Motokid600]

Ty Payload that gives me something to try. But im afraid the program doesn't even get to that point. The program does not shut down, but stops functioning after the first surfacespeed line. ( with the exeption of the "lock steering to prograde" line which works ) The reason I use this is because that is was the navball indicates until about 40km where it changes to orbital velocity. Would you recommend a better value? Ive tried just velocity, but nothing.

Like I said everything just stops functioning. The engines just burn to the tank is out of fuel. Where its supposed to stage once under 5 units of fuel. If it even would get to that part... I need the gravity turn to function first. I don't just hold at 45 degrees until the target apoapsis I pitch over as the speed increases. THEN shutdown engines at target apo. But as you have informed me ive been loosing apo height due to drag this whole time now. I just never realized it doing it manually.

Edit:

OHH I think I know what your problem is. You still have power when you go to wait for apoapsis? I think you might be running out. Does the kOS screen go blank?

No its powered. Code doesn't even get to that point though.

Edited September 17, 2013 by Motokid600

[Payload]

kOS v0.61 is out. I have tested some new code and added comments so it is easier to follow. V0.61 compatible launch script is now up on the front page. Go update your kOS to .61 then you can have commented code!

Edited September 17, 2013 by Payload

[Motokid600]

Hm. Now I cant run the program at all. Syntax error. Is this mod now placed in the gamedata folder? Wheres the Archive folder now?

[Camacha]

I guess I am of the breed that likes to do everything on its own, so I will not look at the code in this topic and instead try to figure it out myself. I might be fun to see afterwards which differences there are in the code and what works better, though.

Although I think that last bit will not be hard to answer, hah. Nevertheless, developing something myself seems fun.

Edited September 17, 2013 by Camacha

[Kalista]

http://www.youtube.com/watch?v=2Td1yOtpmtw]

2 things of note . First yes i was lazy and didn't adjust the roll program hench why my winglet smacked the launch clamp so sue me . 2nd I'm about to kill DRE took two takes to get this first one rocket blew due to G forces after the launch burn ended 2nd take as you can hear at the end it attempted to again think for now on ill apply the fix that removes G damage since its been buggy as of late. Other than 2 problems that aren't the fault of the mod nor space computer current version flys as straight as the previous one. Even tho its not designed to be used with FAR long as you tweek the gravity turn ( I haven't in my test only thing i touched was the TWR setting) the program will fly any decently designed rocket FAR or not so payload if anyone gives you crap that there rocket with far went derp mode feel free to link either of my videos as proof it flys em just fine .

[Payload]

The thing is, I have been trying all day to build a rocket this thing can't fly. Unless I go really extreme on the bad moves, I can't do it. When I finally did build one that it couldn't fly, there was no way I could do it manually. I think there are some epic button mashers out there that have no idea how bad the rocket design is because of their epic button mashing. I applaud those epic button mashing skills. I don't have them. That is why I got Mechjeb and then kOS when it was available. I really am wanting to just throw Mechjeb away now, but I need it for it's information. It is really helping me debug and understand suitable behavior modes.

I expect we will have far less failures now that people can read the comments. I also bet there are a few things I didn't think about. As far as testing goes. This thing should stage Asparagus, Parallel, and Serial as well. Someone needs to give that a work out. I have tried all of those and it works. I bet there is some configuration I haven't thought about yet though. That is what we need to do. Weed out the failure modes. There is no way I am going to attempt any landing code until I know this is working as well as it can be.

One thing I need to explain.

The prints in the loop are bad form.

I know that.

I have left them there for the time being for debugging.

I really wish prints weren't that slow, but they are slow on every platform I have ever coded for. Nature of the beast.

You can increase the loop speed by quite a large amount if you remove them.

I never thought I would have to write code for something that is slower than my Amtel based Ardiuno clones.

I thought wrong. This is an interesting learning experience.

On a final note, WE NEED MODULES.

Who is writing the landing script?

We also need orbital correction modules. I can help. I think I might be able to muster the strength to do the calculations properly this time.

We also need the standard orbital vector selects like mechjeb's SASS.

We could use a standardized program that checks the current body. Now that examples of how to do that are available. We need it to set some variables. If you have some questions ask me and I'll get the info we need. It's not like it can't be amended.

EDIT: Kalista, if you set tOrbit to 200k in the beginning that will set it's default value to 200k. Then all you have to do is hit 7. Have you tested the Jebpollo craft I posted? Or the official test craft? I think both of those are on the limit of this launch system.

Edited September 17, 2013 by Payload

[Kalista]

When i restart mission controller tomorrow and hit the apollo missions on it ill see if SC flunks out on it. My apollo style rockets tend to fly like a trailerhouse caught in a tornado so as far as my rockets go that will be the real test my little VZ rocket I've been using is my low/medium orbit workhorse for satellites so it always flys like an arrow. And yeah mechjeb is pretty much the same thing for me information only since engineers windows just aren't easy on my eyes. Far as coding goes I'm not that good at it but I'm willing to test them and test to see how far compatible they are. If I were to code anything on here I'd make the North Korean missile program look like a first rate program.

edit: Yeah I know setting the tOrbit to whatever I want saves time I use the action groups in my videos to give me time to go over a mental checklist that everythings running. Just tried the jebpollo in FAR+DRE its not pretty thing comes apart pretty quickly on me tho I may have botched the program setup will try the other craft here in a minute and if it doesn't turn to confetti I'll post a video. Test craft did better tho still broke apart before orbit. Problem with both in FAR is even turning off gimballing the control authority on them has them wobbling like crazy then sheering apart after. I'll try them both again later when my epilepsy fit subsides and I can think more clearly.

Edited September 17, 2013 by Kalista

[Payload]

Just doing some testing on the efficiency of limiting TWR below 10k with the stock game.

Results:

Orbital test.

Parameters: 100k orbit alt. 0deg inclination.

6255m/s total

1927m/s left after orbital test 1. limit TWR to 2 until 10k.

1919m/s left after orbital test 2. limit TWR to 2 until 15k.

1801m/s left after orbital test 3. limit TWR to 1.5 until 10k.

1923m/s left after orbital test 4. no TWR limit.

1923m/s left after orbital test 5. limit TWR to 2.5 until 10k.

So 2 is better than 2.5 and 2.5 was the same as not limiting it at all. That is with the stock gravity turn settings.

Conclusion, if you are way over 2.0 TWR on launch you want to use the limit. If your rocket starts about 1.8 or 1.9 and gets no higher than 3. The limit might only help a little.

2.0 seems like the ideal setting for stock KSP.

That might not be true if one changes the G-turn settings to rotate more slowly. More experimenting will have to be done. I think that is about optimal launch dV for the stock game. Someone might be able to get lower.

Edited September 17, 2013 by Payload

[Kalista]

http://www.youtube.com/watch?v=_wawUoIsaQM]

Jebpollo test craft aiming for 100km launch 0° inclination FAR+ Fixed DRE
Suggestions for others who attempt this with the above mods, Lock TWR to 1.25, Keep Throttle lock till turn 4 having it unlock at turn 1 will make you lose a ton of turn authority.
With everything plus the kitchen sink thrown at this if I would have kept TWR lock on longer it would have had a better orbit than it did. One of the better stock craft of its type I've tried with FAR just needs alittle more babying to get it completely ontrack.

[rkman]

I'm having a bit of trouble getting this to work. I got it so far that the "adjust orbit altitude" menu comes up, but then the actiongroups (key 7, 8 , 9) don't appear to do anything, it just stays in the menu.

I figure the problem might be in the names i gave the script files. I've got 3 scripts in KSP/plugins/plugindata/archive:

menu.txt

sc1.txt

orbit1.txt

I named the latter two after scripts that menu.txt appears to call.

[Payload]

I'm having a bit of trouble getting this to work. I got it so far that the "adjust orbit altitude" menu comes up, but then the actiongroups (key 7, 8 , 9) don't appear to do anything, it just stays in the menu.

I figure the problem might be in the names i gave the script files. I've got 3 scripts in KSP/plugins/plugindata/archive:

menu.txt

sc1.txt

orbit1.txt

I named the latter two after scripts that menu.txt appears to call.

You can't be focused on the kOS window or the action group triggers don't work. Click outside the terminal and they should work. Also the names don't really matter anyway. The menu system won't actually work until we get the command EXIT AND RUN.

KSP wont close one old program that calls another even when that program has ended. It keeps any other programs from having steering control and throttle control.

You just have to use run for now. I also haven't posted half of the things that are rolled into the menu because at this point they wont work. I keep forgetting to include the splash screen. Because it doesn't actually do anything but look pretty.

HAHA Kalista, I can't believe you got that thing into space with FAR. Also I think you lost part of the launch escape system on stage one sep there. That's OK Jeb is too much of a man to use it anyway.

Edited September 18, 2013 by Payload

[Kalista]

Payload are you saying that having one program run off another wont work ? Because I've been running a release program that starts off the end of space computer that deorbits my boaster and parachutes it into a soft landing thats been working perfect for me. If not disreguard this been a hectic day and may have misread it.

[Payload]

Payload are you saying that having one program run off another wont work ? Because I've been running a release program that starts off the end of space computer that deorbits my boaster and parachutes it into a soft landing thats been working perfect for me. If not disreguard this been a hectic day and may have misread it.

I'm saying if you try to run the launch to orbit program form the menu like you would expect, the program fails to control Steering and throttle. You can try it for yourself but I am not the only person who has reported it. You can see there where I even put the menu on hold, I've tried exiting the main loop right after the run call... Everything.

The first program running is the only one that can control steering and throttle. Until we get EXIT AND RUN or some kind of equivalent, or this steering and throttle control issue is solved, I am afraid the menu system is DOA.

Edited September 18, 2013 by Payload

[Kalista]

I just had a completely different reaction from using the menu.txt for me it just instantly cut from menu without me touching a thing skipped to my launch program and just staged every second. Its odd if I run my launch to orbit program at the end of it it will start up my release and return program with 0 issues just seems odd to me it works and the menu program has a heart attack. I should clarify to soon as menu loaded didn't get the GUI at all just skipped to my launch failed to set throttle and perma staged control.

[Payload]

I bet you called your program in the area that calls the Splash screen. That is the problem that code was written a long time ago and I haven't bothered to go over it and comment it because It wont work for now anyway.

Set the splash to 0. Then the program wont try to run it.

if index = 0 AND selection = 1
 {
 [b]run a1.[/b]
 wait until ready = 1.
 }.

Those sections are where you setup your program calls. The splash is specifically for running the splash screen.

[Kalista]

Exactly as you said changed what you told me to got the GUI picked launch to orbit no throttle no pid endless staging. What stumps me ( and its due to me being programming illiterate ) is menu > lkosat bugs out yet lkosat > plrelease runs flawlessly ill post both of my codes so you might make sense of it ( lkosat is just a stripped down SC with the gui taken out since its not needed for what its programmed to do plrelease is my sat release + deorbit )

lkosat

clearscreen.
sas off. // Ensures SAS is OFF.

//**User Set variables.

set tOrbit to 200000.          // Sets Default Target Orbit.
set tHeading to 90.            // Sets your launch heading. Usage:0-360. 0=North. 
set rpAlt to 1000.             // Sets the altitude at which to preform an initial roll.
set rProgram to -90.           // Sets the roll target. Engages at rpAlt. Usage:0-360. 180=VAB default.

set throttleLimit to 1.        // Engages throttle limits below turn1.
set tTWR to 1.25.                 // Sets the max TWR while throttle limited.

set Count to 0.                // Sets the number of asparagus stages. 
set aspFuel to 0.              // Sets the amount of fuel in one aparagus stage.


//**Internal variables.

set yaw to 90 + tHeading.                            // Internal var to match heading to NavBall
set pitch to 90.                                     // Sets your inital pitch via heading. Usage:0-360 90=Up.
set roll to 180.                                     // Sets your inital roll. Usage:0-360. 180=VAB Default.
set x to 0.                                          // Internal var for angle calculation.
set y to 0.                                          // Internal var for angle calculation.
set z to 0.                                          // Internal var for angle calculation.
set tThr to 1.                                       // Sets throttle at lift off.
lock steering to up + R(0,0,roll) + V(x,y,z).        // Locks steering to calculated vector plus roll.
lock throttle to tThr.                               // Locks throttle to var tThr.
set orbit to 0.                                      // Sets the main loop close condition.
set hAtmo to 69500.                                  // Sets the altitude of atmosohere of Kerbin. Unit:Meters.
set turn1 to 9999.                                   // Sets the altitude of the first down range turn. Unit:Meters
set turn2 to 14999.                                  // " " Unit:Meters
set turn3 to 19999.                                  // " " Unit:Meters
set turn4 to 24999.                                  // " " Unit:Meters
set turn5 to 49999.                                  // " " Unit:Meters

//**Values based on UI.

set xAlt to tOrbit - 100.                 // Primary M.E.C.O. Condition. Usage:xAlt=tOrbit-Meters.
set xOrbit to tOrbit + 5000.              // Secondary M.E.C.O. Condition. Usage:xOrbit=tOrbit+Meters. 
set cAlt to tOrbit - (tOrbit*.05).        // Internal var for near MECO throttle limit. Usage:cAlt=tOrbit-5%.
set hAlt to tOrbit - 5.                   // Internal var for apoaps hold. Usage:hAlt=tOrbit-Meters.


//**Begin Countdown.

clearscreen.
print "Orbit altitude set to " + tOrbit + "m".
print "3". wait 1.
print "2". wait 1.
print "1". toggle ag1. wait 1.
clearscreen.
print "Lift Off! Target Heading set to " + tHeading + "Deg". stage.

set StartFuel to <liquidfuel>. // Internal var for initial Total Liquid Fuel. 


//**G-turn Section.

when altitude > rpAlt then set roll to rProgram.
when altitude > turn1 then set pitch to 65.
when altitude > turn2 then set pitch to 50.
when altitude > turn3 then set pitch to 30.
when altitude > turn4 then set pitch to 15.
when apoapsis > turn5 then set pitch to 0.


//**Orbit Injection control. Alter at your own risk.

when apoapsis > tOrbit then
 {
 set tThr to 0.
 set Gk to 3.5316000*10^12.
 set Radius to 600000 + apoapsis.
 set iRadius to 600000 + ((apoapsis+periapsis)/2).
 set tVel to (Gk/Radius)^0.5.
 set iVel to (Gk/iRadius)^0.5.
 set reqdV to (iVel-tVel).
 set acceleration to (maxthrust/mass).
 set burnTime to (reqdV/acceleration).
 set tTime to (burnTime/2).

 until altitude > hAtmo
 {
 if apoapsis < hAlt { set tThr to .1. }.
 if apoapsis > tOrbit { set tThr to 0. }.
 }.
 when altitude > 70000 then stage.
 when altitude > 70200 then set warp to 3.
 when eta:apoapsis < 120 + tTime then set warp to 2.
 when eta:apoapsis < 60 + tTime then
 {
 set warp to 0. wait 1. lock steering to prograde.
 }.
 when eta:apoapsis < tTime then set tThr to 1.
 }.

when periapsis > cAlt then set tThr to .1.
when periapsis > xAlt OR apoapsis > xOrbit then
 {
 set tThr to 0.
 sas on.
 clearscreen.
 print "You Are Now In Orbit".
 set orbit to 1.
 }.


//**Main Control loop. Alter at your own risk.

until orbit = 1
 {
 set x to cos(yaw) * cos(pitch).
 set y to sin(yaw) * cos(pitch).
 set z to sin(pitch).
 set StageSolid to stage:solidfuel.
 set StageLiquid to stage:liquidfuel.
 set Lfuel to <liquidfuel>.
 set TWR to maxthrust / (mass*9.81).
 set cTWR to TWR * tThr.
 set dTWR to cTWR - tTWR.
 print "Heading  " + heading at (0,3).
 print "Max Surface TWR " + TWR at (0,5).
 print "Current TWR " + cTWR at (0,7).
 print "ETA:Apoapsis  " + eta:apoapsis at (0,9).

 if throttleLimit = 1
 {
 if cTWR > tTWR { set tThr to tThr - (dTWR*.1). }.
 if cTWR < (tTWR - (tTWR*.1)) { set tThr to tThr + .05. }.
 if tThr > 1 { set tThr to 1. }.
 if tThr < 0 { set tThr to 0. }.
 when altitude > turn2 then
 { set throttleLimit to 0. set tThr to 1. }.
 }.

 if Lfuel < StartFuel - aspFuel AND Count > 0
 { stage. set StartFuel to Lfuel. set Count to Count - 1. }.

 if StageSolid > 0 AND StageSolid < 5
 { stage. }.

 if StageLiquid = 0 AND StageSolid = 0
 { if Lfuel > 0 { stage. wait 1. }. }.
 }.


//**End program orbital condition print out. Extend solar pannels on AG1.

lock throttle to 0.
wait 1.
print " ".
print "Apoapsis is " + apoapsis + "m".
print " ".
print "Periapsis is " + periapsis + "m".
print " ".
print "Orbital Eccentricity is " +
 (((apoapsis + 600000)-(periapsis + 600000))/((apoapsis + 600000)+(periapsis + 600000))).
print " ".

wait until orbit = 1.
wait 5.
run plrelease.

plrelease

clearscreen.
lock steering to heading to 0 by 0.
print "preparing to launch payload".
wait 15.
TOGGLE AG4.

wait 5.
clearscreen.
print " Deorbiting Boaster".
lock steering to retrograde.
wait 10.

Lock throttle to .75.
wait until periapsis < 0.
lock throttle to 0.
wait 2.
set warp to 4.

wait until altitude < 70000.
set warp to 0.

wait until altitude < 32000.
lock throttle to .75.
wait 20.
lock throttle to 0.
unlock steering.
set warp to 4.

wait until altitude < 8000.
set warp to 0.

wait until altitude < 7000.
set warp to 0.
TOGGLE ag6.

set warp to 4.
wait until altitude < 1000.
set warp to 0.

One flows seemlessly into the other and again I'm as beginner as it gets with coding so bear with me. And yes I just now removed the sas on from lkosat forgot to remove it till now.

[Payload]

Exactly as you said changed what you told me to got the GUI picked launch to orbit no throttle no pid endless staging. What stumps me ( and its due to me being programming illiterate ) is menu > lkosat bugs out yet lkosat > plrelease runs flawlessly ill post both of my codes so you might make sense of it ( lkosat is just a stripped down SC with the gui taken out since its not needed for what its programmed to do plrelease is my sat release + deorbit )

One flows seemlessly into the other and again I'm as beginner as it gets with coding so bear with me. And yes I just now removed the sas on from lkosat forgot to remove it till now.

Couldn't tell ya what is wrong honestly. If I knew, we wouldn't have this problem. Also you don't need the "wait until orbit = 1." That section cannot run until orbit = 1. That is handled by the injection control. It already waits until then by default. You just simply run anything you want at the end.

[Kalista]

Just out of curiosity what is the highest orbit you have tested SC to ? I'm about to see if i can get my VZ rocket with some extra boasters to hit the 3 mil meter mark. I'll report back how well it does after.

edit: Well without tweeking it doesn't like going that high soon as ap hits 3,000km and the pe is 55km it triggers the end of the program will play around with it more tomorrow to get it running at high orbits.

Edited September 18, 2013 by Kalista

[Payload]

Just out of curiosity what is the highest orbit you have tested SC to ? I'm about to see if i can get my VZ rocket with some extra boasters to hit the 3 mil meter mark. I'll report back how well it does after.

edit: Well without tweeking it doesn't like going that high soon as ap hits 3,000km and the pe is 55km it triggers the end of the program will play around with it more tomorrow to get it running at high orbits.

It's hitting the fail safe secondary MECO condition. Remove that and it will at least attempt to circularize.

One of the issues is the calculation I am doing to set the injection burn is close but no cigar. It is an approximate value of how long it will take for you to make the burn. The more elliptical your orbit is, the more error it will incur. It isn't to hard to actually do the right equation. The variables are all there and correct. I am just short cutting the calc because the Law of Conservation of Angular Momentum ensures that as long as the orbits are not ostensibly oblique, the timing will be accurate to an extent that satisfies the purpose.

Removing the fail safe MECO condition will get you a whole lot more circular though. You may have to adjust your primary MECO condition.

Edited September 18, 2013 by Payload

[Kalista]

One last question for you while your here since you have been a massive help. As the mod stands right now is it possible for one part to send orders to another? Example I have a single rocket with a control terminal on it thats in a 4 hour orbit ( 2868.75x1227 km ) with 3 probes on its nose each with a terminal and small motor. Can i have a launch program take it up to that orbit then send a program to each core when its turn in the rotation comes up to release from the main rocket and circularize thus allowing a single rocket with the primary program sending a signal to the other probes onboard when its turns up to decouple free and go. I got a strong feeling the ability to do that yet hasn't been implimented into the main mod and you seem to be almost as knowlegible about the mod as kevin is.

[Payload]

I don't believe what you are talking about is possible right now. I'm pretty sure that that is where we are headed. For now you need to have plenty of antenna on your ship and switch to it and copy code from the archive. Then you can run it locally. I would not be surprised to see what you are asking for eventually. The new remote link additions seem to be heading in that direction.

[rkman]

You can't be focused on the kOS window or the action group triggers don't work. Click outside the terminal and they should work. Also the names don't really matter anyway. The menu system won't actually work until we get the command EXIT AND RUN.

Thanks, it works now.

A bit of feedback:

I have had exactly one instance where SRB's were staged by the script. In all other dozen or so attempts i had to stage the SRB's manually.

Rockets that fly stable with mechjeb wobble severely with the KOS launch/ascent script.

Also the script seems to reduce control authority of the first stage, compared to mechjeb. Though that might be a side effect of the wobble.

Maybe useful: i put some quick-and-dirty pitch-over/gravity turn code in the main control loop, that seems to work rather well:

when altitude > turn1 then set pitch to 90 - ((altitude - turn1) * (90 / (turnend - turn1))).

turn1 = 6500

turnend = 45000

all 'when altitude > turnx then set pitch to y.' code commented out

[Dunbaratu]

One last question for you while your here since you have been a massive help. As the mod stands right now is it possible for one part to send orders to another

It looks like on GitHub someone is working on a way to log text data to the hard drive of the KOS part. Perhaps when that exists one could write to a known filename on the archive drive (assuming you have antenna range to do it) containing Kosscript commands, and another KOS part elsewhere in the solar system (assuming it has antenna range to archive as well, and is close enough to be loaded and running and not "on rails") could continually run that file from the archive as code over and over until it sees an expected change to a variable. Thus modules could write snippets of code in the "log" files for other modules to run.

Whether or not this works will depend on whether they let us make log files that have *.txt extensions so they look like the program files.

[Kalista]

It looks like on GitHub someone is working on a way to log text data to the hard drive of the KOS part. Perhaps when that exists one could write to a known filename on the archive drive (assuming you have antenna range to do it) containing Kosscript commands, and another KOS part elsewhere in the solar system (assuming it has antenna range to archive as well, and is close enough to be loaded and running and not "on rails") could continually run that file from the archive as code over and over until it sees an expected change to a variable. Thus modules could write snippets of code in the "log" files for other modules to run.

Whether or not this works will depend on whether they let us make log files that have *.txt extensions so they look like the program files.

That plus RCS translations ( so I can send my automated cargo ships to resupply my space stations) and possibly a relay network style ability to send new programs to objects far away without them looking like a porcupine with a soup bowl on its back ( a la remote tech type relay ability) are the 3 things I'm hoping we get fairly soon mostly 2 and 3 so my rovers on duna can get new orders to go after its arrival ( Also even tho kevin said time lag is out I'm really hoping he adds it to a config file with a simple true/false condition so those of us that want it get it and those that dont have it off by default).

[Dunbaratu]

That plus RCS translations ( so I can send my automated cargo ships to resupply my space stations) and possibly a relay network style ability to send new programs to objects far away without them looking like a porcupine with a soup bowl on its back ( a la remote tech type relay ability) are the 3 things I'm hoping we get fairly soon mostly 2 and 3 so my rovers on duna can get new orders to go after its arrival ( Also even tho kevin said time lag is out I'm really hoping he adds it to a config file with a simple true/false condition so those of us that want it get it and those that dont have it off by default).

The antenna range calculations changed in 0.65 so it's not QUITE as bad as it was before, but it's still going to require a few. What would be great would be if it was directional. If the dish antenna is aimed at kerbin you get better range than if it isn't. But before that can be a possibility we have to have the ability to get data on objects more than 2.4 Km away, and on objects that don't have their own SCS on them.

Right now the way the data gathering about your target's stats works is that the target must be a vessel and must be loaded into the full simulation system (not on rails). This makes getting data on planets impossible unless that system is handled differently.

Heck if we could just query the universe time (as opposed to just the mission time), we could devise our own equations to work out where planets and moons have to be using our own homebrewed "on rails" calculations.

Edited September 24, 2013 by Steven Mading