Bizz Keryear

Yeah, 2+ meter cockroaches...

umm, what else except the throttle is broken? as I said I have just in the moment 0.82 running and it displays me very well the eta:apoapsis.

Somehow with k-OS I lately feel like I am here: http://www.batoto.net/comic/_/terra-formars-r4747 So many huge bugs.... And since 0.5 it only gets worse...

Well I have some k-OS versions on my g.drive https://drive.google.com/#folders/0B8G15uDawhyDQWhVSjFCTmU2WVE I tested eta:apoapsis and eta:periapsis. Both work. maybe your menu editing broke the script? Did also happened to me.

Seems broken, as well as wheelthrottle. I already opened an issue on github

I was just (super) saiyajin ... erm ... saying So that you know it. Btw I still want include that into the wiki. Not just link like now, but full blown. With file download (file will be hosted on the wiki) and everything. edit: I should read my notifications.

@Kevin is it ok if I publish the old binaries of k-OS?

Its an Issue of RT. I overrides the keyboard inputs. And in a way that Kevin can't do anything about that. The only way is to fix that in RT. And I assume they might never do that.

Really nice, and totally useless. I like it. Could You add that to the wiki? Edit: You know that Foor() round() and so on were addded in 0.8x? Edit2: Sweet 0.82 is out: Now with less bugs (than Joe's Apartment). did someone else has noticed that the k-OS part has a slight amount of air ? (taken from 0.8)

We both have used the ON ... command wrong. That way it causes a memory leak, causes the event handler are keeping pilling up. See: http://kos.wikia.com/wiki/How_not_to_use_the_ON_command. , http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-7?p=677306&viewfull=1#post677306 and https://github.com/Nivekk/KOS/issues/111.

Pitch of what? Your current?

As far as I know KSP usually don't use multiple lines in their serialized variables... so I thought having multiple lines in there might be troublesome. Never looked ... wait a moment harddisk { capacity = 10000 volumeName = file { filename = stage8 line = clearscreen. line = set totalfuel to <liquidfuel>. line = print "total fuel: " + totalfuel. line = stage. line = wait 1. line = set booster to stage:liquidfuel. line = print "booster fuel: " + booster. line = wait 1. line = set stagefuel to totalfuel - booster. line = print "stage when fuel: " + stagefuel. line = wait 1. line = lock throttle to 1. line = lock steering to up + R(0,0,180). line = stage. line = when altitude > 200 then { lock steering to heading 90 by 90. }. line = set lq to <liquidfuel>. line = when lq <= stagefuel then { stage. } line = until lq <= stagefuel OR altitude > 10000 { set lq to <liquidfuel>. print <liquidfuel> at (0,5). print stage:liquidfuel at (0,5).}. line = until altitude > 10000 { print <liquidfuel> at (0,5). }. line = lock steering to heading 90 by 45. line = set l to 0. line = until l = 1 { set lq to <liquidfuel>. print <liquidfuel> at (0,5). if lq = 2880 {set l to 1.}. if stage:liquidfuel = 0 {stage.}. }. } } is what it actually look like in a ksp save ... very crude program I know, I only set it up for a staging test ... and it was short so it was first choice for the 0.8 fix test. ah crap. all whitespace are actually masked as & #32; but I cant get this board to write that....

ah thats it... at first I thought it where the multiple compare I had there... umm that means there is a workaround ... just don't use newlines.

Like you said. Totally broken. But he isn't here this weekend said the video. any until something { }. I tried ended in a lineXX: mismatching delimiter. error edit where variables in subprograms always been global?

Guys! Wait until you try 0.8 ... lots of cool new features, but UNTIL is broken! *tears* Edit: Who else thinks that the next update should not contain any new feature, but making all given so far working ... And as intended!

I've just tested it out ... and couldn't get my error. All seemed fine ... until I figured out yes the main engines also use fuel... So all calculations are for naught if you don't apply fuel lines from your liquid booster to mains. You might not want this but its the only reliable way to know when your boosters are out of fuel. Another way is to stage the booster manually. Maybe someone else figures a way out to calculate how much fuel the mains consume. And also while using lock steering to up + R(0,0,180). wait until altitude > 200. lock steering to up. I experienced a unstable flight. While using lock steering to up + R(0,0,180). wait until altitude > 200. lock steering to heading 90 by 90. I had no problem. Edit: Did someone else recognized that print at now works with variables?

Sorry if I butt in, and I only will test it out yet, but I am pretty sure that wont solve your staging problem. Even if the main engines are fired later, as soon as you add them the fuel for them will be added to the stage fuel. That way your booster will only drop if the mains also out of fuel. you might more something like that: //pseudocode. set total_fuel to <liquidfuel>. set stage_fuel to total_fuel - // now add here the total liquid fuel that your booster have. you get that by multiplying the total amount of boosters and fuel in each one (and each fuel from VAB). and don't forget the dot. when <liquidfuel> <= stage_fuel then {stage.}.

Ah this is a known bug with RT. It causes that keys are passed through to KSP even when in the K-OS window. Unfortunately there is no fix (yet). You have to ask RT for that.

This Candy made it finally into the Wiki. I have made the experience that troubles with k-OS are linked to crafts. If a script works or not fairly depends on the craft. The cruise missile script didn't worked for my plane even though it were flying pretty stable (sas off and hand off controls and it flew a strait line, and it was also well controllable without sas) but with the script all it does were loopings. While the original missile missed the target about 6km (too far away, but it flew over it) but flew well. So it would be a good idea to prived the craft file as well. As someone said: It depends not on the separation. To do it correctly you have to know how much fuel in all boosters are. And then separate the stage if that is missing from the initial amount of fuel. See in Space Computer how they done it in the asparagus staging. It is similar. Try the Wiki, its far more complete than the github pages. Yes. It is running in a part of the craft.

Sorry to say, but http://file2web.com/838PartTools%20020.zip is a dead link

Thanks a bunch I wanted to have that so badly, no time today but I might mentioned it a article in the wiki, soon. ------------------- @KevinLaity It might be cool to have "on" statement at file operations. Like e.g. copy a_file from archive on 2. // AND/OR run autolaunch on 0. // AND/OR log "my_data" to log_file on archive. // AND/OR delete old_data on 2. and so on. This would get rid of a quite few of "switch to"s. ------------ Btw has someone else this wired bug: After I have created a new vessel (from SPH/VAB or loading a craft file) the first command I enter causes the k-OS computer to freeze permanently, until I reboot it with a power un-&reconnect. It might be only appear after a few resets to launch, not so sure about that.

I'd like you to to put that on the wiki. Space Computer has a (imho) good asparagus solution

OK, now I get it, but wont you agree that other things are more important right now? Maybe it should be in for version 1.0 or so.

To both I can only say: Add more computers to you Vessel. You will get more disc space. It might be including a switch to <drive_name_or_number> command at the executing computer. So it means: Yes one computer can execute the files on another one (as long as they are on the "same" vessel... docked ships also count as same vessel) A how to make all probe cores into k-OS computers can be found here. Dunno what that is supposed to mean, but how about to bring a probe back home then? Read the wiki! You can use DECLARE PARAMETER <variable>[,<variable>[,...]] within a program then you can call that program with program(<variable>[,<variable>[,...]]) (Sorry for the empty quote I used it only to link the conversation ...) NO what I really meant, if you doing it inside of the game, you depend on the game that mean all those long loading times, also if you test run your script it will affect the vessel attached to it, which usually end in lots of explosions if the script fails caused by typos. I mean the real test if the ship behaves like you thought it will is another story, but if the script just simply stops cause you have forget a dot, a bracket or a quote-mark ... unneeded loading times I am not a ten finger writer and not typing blind, but I use both hands and not searching keys. Sometimes ... well its a not so rare case.... one finger is too fast and I end up with owrds (e.g.). Having those and the previous mentioned ones is really a pain in the (lower) south end if you facing north.

He said that the comment stripping and validation checks should be done in game. While better error codes would be good, a check outside would be better and faster. your game would not be running away while fixing typos. Serious editing is often done outside already, why not check and compile it there, too. Instead of waiting the long loading times of ksp. Remember your Rocket might have a horrible accident if your program fails. Which would cause another loading screen.