Bizz Keryear

The antenna part in kOS is kept very simply. And it should stay that way, but it might be very simple to include a RT detection or a trigger which mods can flip and use their own antenna thing. Actually really good news: Kevin has started to work again on kOS and fixed a few bugs already, even though he hasn't released a new version yet. I would build my own ... if I know how.

I really like to look at the code of other people, because they can come up with solution I might never thought of and I can adapt those to my own projects.

Are you still working on this? I mean updates used to come in a short time but now it is silence for a while now. And its somehow stuck in mid between 0.5 and 0.6 (which seem to have really cool new features I really do like that) I don't wanna push you, just know.

Bow ties are cool.

It seems to like Kevin currently stopped working on kOS and is instead killing innocent victims (Victim Nr. 1 Nr. 2 Nr. 3 ... btw. did someone else noticed that the uid in youtube videos got longer lately?) I can understand that it seems like only a couple of hours (depends on definition) until 0.22 comes out.

Its a problem of RT, cause its redirect the keyboard inputs through itself (to making the delay possible, or deny control and such). But as far as I know RT development is suspended until 0.22 comes out officially.

Link is in the wiki on the issues page

ship 1 switch to 0. // eventually use a loop here set a to "set ralt to "+ALT:RADAR. delete rmh from 0. log a to rmh. //potential loop endship 2 set x to 0. switch to 0. util x=1 { run rmh. //it reads in the variable ralt which can now accessed. //e.g: if ralt = 120000 { //do something .. launch script or whatever }. //rest of script here // //example 2 print "Craft 2 altitude: "+ralt. //more script }. Eventually you need a mod named "never unload" which keeps craft in ram and let ksp execute them like ones close by.

That mod is* so good it actually give me chills. But it will be tons of work to integrate that in 0.22 which will be out really soon. If not within one week then within two (imho /based on what news I have seen on reddit). I really hope you keep the work on this up even in 0.22, and I hope that it is possible to integrate in the new KSP version without any bigger balancing problems. ------------- *=Can't say if it really is cause I haven't tried it. So I only can actually only say it looks so good.

I think you might misunderstood it a little. We are not developing kOS but a System for kOS that will be used in-game and is based only on stock parts and kOS. Its to see if there is a problem in the latest kOS version and generate Bug reports. We want to help the developer to find bugs faster and that he is able to fix them faster. I can't speak about the others but I don't speak C. (Well, I roughly understand what is going on while looking at the source code, but I am not able to find bugs or fix them). Or maybe I misunderstood you. Anyway If you still want help (here with developing the kerboscript testprogrammmm or at github [to help the mod author ... its in C, though]) you are welcome to work with us.

Really great. Sorry, that I am doing not much right now. I just thought, since programs may be stopped by errors at any moment. it would be better to break them up in parts. which are launched from a master program. Like: //I am the MCP! Everything has to obey my command(s). clearscreen. print "testing basics". run basics. //all functions we need for logging/printing for the tests to come. If that breaks it probably makes no sense to continue. print "testing print". run print. //all print functions including special cases like print "something" + eta:apoapsis. print "testing log". run log //same for log. //rest here

You mean: There was probably some problem at some point with something somewhere. A bug description, that fits everywhere.

Yes, me. And that was reported a while back on github, too. Not sure if that is the use how it was intended. I think it should be set x to 0. lock throttle to x. set x to x + 0.5. But I might also be one of maaaany bugs in 0.84 if you not really need 0.8 feature try 0.71 instead (link below). No, that is something that broke after 0.8, but honestly I am too lazy to find out in which version exactly. Its also already reported on github. I never had trouble with using steering in 0.84 or 0.82 (was broken in 0.83, though). But like the eta error (see below) it might only happen in "special" cases. // the infamious eta error print "some text". //working print "more text" + some_variable_internal_or_not. //also working print "even more text" + eta:apoapsis + "text after". //no problem print "lorem ipsum" + (eta:apoapsis) + "hey don't blame me I am out of ideas". //is fine print "dolor sit amet," + (eta:apoapsis). //also fine print "consetetur sadipscing elitr," + eta:apoapsis. //throws a "unkown term eta" error!!! OK, Changes on your local drive are changes to ship that are made after launch. It should affect the ship like docking a vessel, as long as you are not revert to a point before that has happend (loading a quicksave made before or revert to launch). In that way the changes (at least they should be) are persistent. Switching vessels, going to KSC or leaving the game and come back later shouldn't affect your programs. (All I mentioned here only applies to cases when you are don't get a "can't save here" warning from KSP). You have to save them from the internal editor with F5, though. But I am pretty sure you have them run at least once. (If you can run an edited program it means you have saved it, cause otherwise it would be gone at the moment you have left the editor.) And if that is not the case for you and the programs are still gone try to use kOS 0.71 (link in the wiki -> issues page -> Old Versions) And so far I can't confirm any trouble with saving in 0.84. (But I kinda lost track what I did test in which version...) Uh, that is a drastic change of parts in the vessel ... Please report that on github, too

So then does lock work in loops now? P.S.: I Know What You (Kevin) Did Last Summer ... erm the last days. =>

But I can confirm that print "some text" + eta:apoapsis. was what has broken space computers orbit script totally ... I mean right now you can't achieve orbit with it but with adding the brackets it is executed till the end. While before it always ended with "unknown term eta". Maybe it only shows how wired that bug is.

Ah sorry, and again I am a bit wiser. Ok whats really broken is: print "some text" + eta:apoapsis. That does not applies to until variable + eta:apoapsis also not to when. only to print and that throws an "unknown term eta" error. Print "" at (x,y) is broken in so far that is only prints to lines where the normal print already was. Means if there are eight lines on the screen then print "my text" at (0,10) will stay invisible. --- My guess is that will at least three more 0.8x versions before it is as stable as 0.71 --- If someone still has old kOS versions which aren't on my drive please PM me.

Double post cause its important I have found it! Its an issue with print! So print "ETA:Apoapsis " + eta:apoapsis at (0,9). // does not work and throw an error (without reason) print "ETA:Apoapsis " + (eta:apoapsis) at (0,9). // does work. Since this workaround is around I dunno when it will get fixed since there are more pressuring bugs. But something in 0.84 still prevents it from working correctly.

Didn't test 0.8 throughly but 0.82: lock throttle broken, but lock steering worked (at least for me, dunno if there where some special cases), print eta:apoapsis broken, print "" at (x,y) working. 0.83: lock throttle working, but lock steering broken, print eta:apoapsis broken, print "" at (x,y) working. 0.84: lock throttle working, but lock steering working, print eta:apoapsis still broken (we just found out that that was it which caused the "unreconised term eta:", print "" at (x,y) broken. error messages broken. The list isn't complete and I kinda lost track. But you see where its getting.

Grr. 0.8x is still a pain. Somehow it seems for each bug Kevin fixes he breaks something else. I know its a little unfair and he is doing his best, but I am still upset (and frustrated to run in bugs everywhere). While I am thinking about it I think he must feeling really frustrated right now. At least I would. OK, while I am still not like 0.84. I should say: GO, KEVIN, GO, GO! KEEP UP THE GOOD and not so good WORK UP, WE ALL KNOW YOU CAN DO IT! GO, KEVIN, GO! *clears sore throat* Hope that will cheer him up. Sorry for this most useless post. But I felt like telling the world

Yeah that is looking like I guessed it looks. If commands are executed within a program (you could also type them in in the command line) they will be reset once the programs ends. And this one ends after executing the print. What you have to do is to keep the program running. you can do it by executing a: "wait time_in_seconds_here.". Or you can use a wait until compare_condition. ("wait until 0." or "wait until 0=1." will never come true and going to hold the program forever) you can also use a "until compare_condition" loop. (everything after // is a comment and will be ignored from kOS.) e.g. until altitude > 9999 { // beginning a loop and excuting it //until the altitude of the vessel becomes bigger than 9999m set calt to round(altitude). // set up a variable named calt (for current altitude) // and put in the rounded value of altitude print "current altitude: " + calt at (0,0). // print a string plus variable at a //specific location on the screen. (start_character,line) //currently in 0.84 broken for other values than (0,0). //do some more stuff }. //end of the loop.

Or "forge" a save game. Actually we could define a position (and other states) of a craft without playing the game. And when we working / running the test script on a copy we would have perfect lab conditions. Great idea to take this in consideration. I would not add this in early, though.

This way we are getting nowhere. I can only make wild guesses if you don't post the code.

U sure u have no typo? I just checked it (twice) and it was working on my computer.

I complete misunderstood.

I think that might be way to complex ... but also might needed for nodes. Maybe we should have a rover rocket ... a bit like checks missile but bigger. First starting off with simple commands, like switch to, run, print, print at and so on. Then driving around to a latlan. Stopping there and pause for a while. (quicksave time) Launching the rocket part testing various ifs when ons and so on also until loops... for full blown node testing we need to achive orbit and more (soi change). The part which is left behind can also be used to test target functions. The test has also be pretty complex to find errors like it appears in space computer right now. I have written a test program in which check eta:apoapsis and it works, while I don't like to work in space computer. Payload pointed out that calculations in his whens might be the cause. ... And we also have to things like <resource> in it cause in one version that was broken. Right now stage:resource in compare operations is also broken.