Jump to content

kOS Test lab - a collab project


Bizz Keryear

Do you think that is a good idea/Will you participate?  

  1. 1. Do you think that is a good idea/Will you participate?

    • Yes, I will work on the vessel. (please comment)
      5
    • Yes, I will work on the script. (please comment)
      2
    • Yes, I will help test it in older kOS versions.
      2
    • Yes, but I am not able to help (no time/ no skills/no whatever)
      3
    • No, leave me alone.
      2


Recommended Posts

I use this forum cause I think its better than the wikia to communicate.

Ok, that will be a collab project in the kos wikia.

Umm is here anyone who can come up with a vessel and a Kerboscript that is capable of testing every command?

Something we can use after each update so we can run a quick test on what is broken?

We are in need of a vessel and a kerboscript.

The vessel should be able to keep up with the script but should kept as simple as possible.

The script also should kept as simple possible but it should not only contain all commands but as much alternations as possible.

It also should give a reliable feedback. hopefully print, log, and switch to will not break.

Update: I created a Wikipage.

Edited by Bizz Keryear
Link to comment
Share on other sites

I use this forum cause I think its better than the wikia to communicate.

Ok, that will be a collab project in the kos wikia.

We are in need of a vessel and a kerboscript.

The vessel should be able to keep up with the script but should kept as simple as possible.

The script also should kept as simple possible but it should not only contain all commands but as much alternations as possible.

It also should give a reliable feedback. hopefully print, log, and switch to will not break.

I could try to make a vessel, though not exactly sure what all it should have. Maybe a plane that uses rover wheels and maybe some small detachable fuel tanks to test staging?

Link to comment
Share on other sites

I could try to make a vessel, though not exactly sure what all it should have. Maybe a plane that uses rover wheels and maybe some small detachable fuel tanks to test staging?

If I would have ideas about that I wouldn't need help.

edit: That sounded way more snooty than I wanted to be ... actually ... I only wanted to say that I right now have no clue what and how to do.

Actually my rockets are working, but not that good. And my programming skills ... well ... they usually work (after removing all typos ... lots of typos) but they are far from genius.

Edited by Bizz Keryear
Link to comment
Share on other sites

From my PM to Bizz Keryear:

Sounds like a good idea to me. Would require at least 2 spacecraft though to test the target vessel function. That could be skipped though for simplicity.

I think a script that lands a simple rover on the mun is probably the way to go, since we now have the ability to create follow maneuver nodes, and we need a way to see if changing our SOI body registers.

Thoughts?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

If LOG is used to print values to a file on archive, then a quick diff can use used on the file to compare it to what it said last time. This doesn't cover all the things that need to be tested but it can cover quite a few. For example, if there had been a test script that contained a simple bit that runs an until loop 3 times and prints "1" then "2" then "3" to a log, then the fact that curly braces got broken would have caused that output to be different than it was before (it would fail to print the 1, 2, and 3). If you have a simple diff check on the output from the expected output it would have flagged a problem that would have made it clear that the new version had broken something. Similarly you could have a bit of script that just prints the results of every math function, prints the meaning of every special variable and so on.

What may make sense is to not only have a fixed known test script to run, but also have a fixed known save game to run it in, on a fixed known vessel at a fixed known location and a fixed known time. (So the test would involve loading that vessel and running the test script on it as soon as it loads. There would be some minor variance in the output LOGs because it would be impossible to run it at precisely the same instant of time to get the exact same velocity, prograde directions and so on, but as long as the values were checked within a degree of allowed error it could still detect if something really odd was different.)

Actually now that universal time is going to be supported and not just mission time, it may be possible to make the test script wait for a known instant of time to run in (some instant a minute or so after the point when the saved game is), to help ensure less variation on variables like velocity vector and prograde directions and altitudes and so on.

Link to comment
Share on other sites

If LOG is used to print values to a file on archive, then a quick diff can use used on the file to compare it to what it said last time. This doesn't cover all the things that need to be tested but it can cover quite a few. For example, if there had been a test script that contained a simple bit that runs an until loop 3 times and prints "1" then "2" then "3" to a log, then the fact that curly braces got broken would have caused that output to be different than it was before (it would fail to print the 1, 2, and 3). If you have a simple diff check on the output from the expected output it would have flagged a problem that would have made it clear that the new version had broken something. Similarly you could have a bit of script that just prints the results of every math function, prints the meaning of every special variable and so on.

What may make sense is to not only have a fixed known test script to run, but also have a fixed known save game to run it in, on a fixed known vessel at a fixed known location and a fixed known time. (So the test would involve loading that vessel and running the test script on it as soon as it loads. There would be some minor variance in the output LOGs because it would be impossible to run it at precisely the same instant of time to get the exact same velocity, prograde directions and so on, but as long as the values were checked within a degree of allowed error it could still detect if something really odd was different.)

Actually now that universal time is going to be supported and not just mission time, it may be possible to make the test script wait for a known instant of time to run in (some instant a minute or so after the point when the saved game is), to help ensure less variation on variables like velocity vector and prograde directions and altitudes and so on.

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.

Link to comment
Share on other sites

Actually now that universal time is going to be supported and not just mission time, it may be possible to make the test script wait for a known instant of time to run in (some instant a minute or so after the point when the saved game is), to help ensure less variation on variables like velocity vector and prograde directions and altitudes and so on.

Yeah, I was thinking the same thing as I was reading your post.

If I get some time today I may try working on a rover rocket. Or...would it work to have 3 separate vessels? A rocket, a rover and a plane? I mean, I guess it would be possible to build a plane with rockets on it and rover wheels, though while trying to keep it simple I dunno if it could get to orbit easily, unless we edit the save file to put it into orbit I guess. I tried doing a space plane with landing gear and rover wheels, but couldn't get it up to speed in order to get into orbit. Though that was before kOS, haven't tried spaceplanes yet with kOS.

Link to comment
Share on other sites

What about breaking the test program into different parts that can called using the action groups? Like you have one part that works as a ground test that will test simple things like math expressions, IF, WHEN and UNTIL loops, etc. Then another part that can test things in atmospheric flight, like steering, latlng expressions, vessel info, etc, something that can be tested in orbit, like maneuver nodes, orbit info, another test that can look at rover functions and a final test that can run the whole test program together. Breaking it into steps will help to isolate problems easier and make troubleshooting faster.

Link to comment
Share on other sites

What about breaking the test program into different parts that can called using the action groups? Like you have one part that works as a ground test that will test simple things like math expressions, IF, WHEN and UNTIL loops, etc. Then another part that can test things in atmospheric flight, like steering, latlng expressions, vessel info, etc, something that can be tested in orbit, like maneuver nodes, orbit info, another test that can look at rover functions and a final test that can run the whole test program together. Breaking it into steps will help to isolate problems easier and make troubleshooting faster.

I guess that could work, though it's my personal opinion, I don't like using action groups for things like that because it takes away from their function on the vehicle. Granted, this would be a test vehicle so it's not likely it would need action groups (except maybe for opening/closing air intakes for planes/space planes, and toggling their engines).

Link to comment
Share on other sites

I'm no computer programmer, but I am quite profficient in TI-Basic. I've seen the code and I might be able to contribute. I've done not much more than simple GUIs and virtual processors of my own design, though.

Link to comment
Share on other sites

Alright, well I'm going to tackle this. Going to use the wiki as a reference: http://kos.wikia.com/wiki/List_of_all_Commands

I'm going to write a script that tests all the commands under Self explaining commands, Math Functions and Other.

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

Link to comment
Share on other sites

I'm no computer programmer, but I am quite profficient in TI-Basic. I've seen the code and I might be able to contribute. I've done not much more than simple GUIs and virtual processors of my own design, though.

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.

Link to comment
Share on other sites

  • 1 month later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...