kOS Autopilot

[Camacha]

But the other thing is that being able to treat docking operations with vectors would open up a lot of useful things like using dot and cross products to help you calculate docking moves.

I kind of figured the same, though I am also not sure whether confronting people with vectors might easily throw them off. When you get the hang of it it is fine, but it might be confusing that adding 1 (, 0, 0) to 1, 1, 1 suddenly means that you have effectively got 1, 0.5, 0.5. My guess would be that an absolute domain is easier to understand than a relative domain. No idea how relevant that difference is though.

Before, you only needed to touch vectors if you wanted to. If this makes it into kOS, they will play a much bigger role - pretty much everyone writing a script will have to deal with it.

Edited February 18, 2014 by Camacha

[erendrake]

Alright people, new pre-release is out

https://github.com/erendrake/KOS/releases/tag/v0.11.1P1

This adds

• Direct Flight control
  
• vessel load distance
  
• random number generator
  
• More engine stats
  

Off to bed.

[Dunbaratu]

Alright people, new pre-release is out

https://github.com/erendrake/KOS/releases/tag/v0.11.1P1

This adds

• Direct Flight control
  
• vessel load distance
  
• random number generator
  
• More engine stats
  

Off to bed.

Adjust load distance? The KSP API lets you do that?? On a per-ship basis???? (i.e. some ships staying loaded farther away than other ships?) Then why haven't more mods made use of it? I'd love to hear more about how that works and how you use it. If it does what it sounds like it does I might want to go back to trying my orbital missile platform again.

[Camacha]

Alright people, new pre-release is out

[...]

That looks lovely

[erendrake]

Adjust load distance? The KSP API lets you do that?? On a per-ship basis???? (i.e. some ships staying loaded farther away than other ships?) Then why haven't more mods made use of it? I'd love to hear more about how that works and how you use it. If it does what it sounds like it does I might want to go back to trying my orbital missile platform again.

It doesnt let you adjust it per ship, Only globally so far I was looking for a way for KOS to allow for a grasshopper style booster return. Saw the load distance and thought "why not!" I actually havent tested it yet but it looks pretty fun

I did find a "Pack" distance that is adjustable per vessel and addeded it, thinking that maybe we could prevent vessels from getting unloaded? Again i havent really tested it yet

[Camacha]

I was looking for a way for KOS to allow for a grasshopper style booster return.

Grasshopper style should be feasible. There are other mods out there that let you adjust loading distance. When you set it to, say, 200 kilometer, you can get all the way to orbit (including lateral movement) without ships unloading. I think the dropped parts should be fine as soon as they have landed, though I never confirmed that. Running a dedicated save would probably be smart though, to prevent massive lag when other parts come within the large loading range.

I have, however, observed strange behaviour when running multiple but seperate kOS units side by side. Sometimes the non focussed kOS unit just goes haywire, gets deleted or somehow influences the focussed unit. I have only seen this behaviour in Kevin's versions though (and played a lot less since), so I have no idea whether this is still the case.

[Dunbaratu]

I was just playing around with typing commands on the terminal and I was trying to use Fore, Starboard, and Top to translate, and the behavior of this seems really weird and off:

sas off.
rcs off.
set f to facing.
lock steering to f.

rcs on. // getting ready for translation.

// At this point it seems right.  It rigidly stays in the current orientation like I'd expect, using kOS instead of SAS to do it, and it's not using RCS fuel because it's settled down into the fixed orientation.

set ship:control:fore to 1.0. // attempting to translate forward.

// Instead of moving in a straight line, it activates the RCS thrust blocks asymmetrically and tries to rotate me.

The problem seems to be triggered by trying to use LOCK STEERING. If I try it by unlocking the steering and instead using SAS to lock my orientation, then it behaves as you'd expect. Something about using LOCK STEERING and using FORE for translation at the same time makes kOS try to rotate the craft even when the current orientation is already the one that the steering is locked to.

(EDIT: Additionally, another problem seems to be the inability to unlock the translation controls and give them back to my manual control. You know how if you don't UNLOCK STEERING, you can't steer manually? Well after I played with "ship:control:fore" and then set it back to zero again, from then on there was no way to make the H and N keys work again to move the RCS translation manually. They were locked out. Even toggling power on the SCS module didn't give me control back.)

Edited February 20, 2014 by Steven Mading

[Camacha]

(EDIT: Additionally, another problem seems to be the inability to unlock the translation controls and give them back to my manual control. You know how if you don't UNLOCK STEERING, you can't steer manually? Well after I played with "ship:control:fore" and then set it back to zero again, from then on there was no way to make the H and N keys work again to move the RCS translation manually. They were locked out. Even toggling power on the SCS module didn't give me control back.)

I have not tried the new release yet, but maybe you locked your controls to 0 instead of releasing them?

[erendrake]

I was just playing around with typing commands on the terminal and I was trying to use Fore, Starboard, and Top to translate, and the behavior of this seems really weird and off:

sas off.
rcs off.
set f to facing.
lock steering to f.

rcs on. // getting ready for translation.

// At this point it seems right.  It rigidly stays in the current orientation like I'd expect, using kOS instead of SAS to do it, and it's not using RCS fuel because it's settled down into the fixed orientation.

set ship:control:fore to 1.0. // attempting to translate forward.

// Instead of moving in a straight line, it activates the RCS thrust blocks asymmetrically and tries to rotate me.

The problem seems to be triggered by trying to use LOCK STEERING. If I try it by unlocking the steering and instead using SAS to lock my orientation, then it behaves as you'd expect. Something about using LOCK STEERING and using FORE for translation at the same time makes kOS try to rotate the craft even when the current orientation is already the one that the steering is locked to.

(EDIT: Additionally, another problem seems to be the inability to unlock the translation controls and give them back to my manual control. You know how if you don't UNLOCK STEERING, you can't steer manually? Well after I played with "ship:control:fore" and then set it back to zero again, from then on there was no way to make the H and N keys work again to move the RCS translation manually. They were locked out. Even toggling power on the SCS module didn't give me control back.)

Crap i forgot to look at LOCK STEERING and this new flight control at the same time. That will have to get fixed!

About letting go of these new controls, I added ship:control:neutralize that should set everything to 0 and then release control. I was trying to figure out how to let go without a "turn me off" command and i couldn't quite figure it out.

[erendrake]

Alright, now that people are starting to find bugs its time for another pre-release. Im thinking that i want to feature lock 0.11.1 with these features, get it tested and out. Then get the rest of the docking milestone finished

https://github.com/erendrake/KOS/releases/tag/v0.11.1P2

This adds

• New Vector math
  
• Disk Space is now defined in the kos part module, new hard cap is 655360 bytes
  

as well as everything from the first pre-release

[Dunbaratu]

I have not tried the new release yet, but maybe you locked your controls to 0 instead of releasing them?

The problem is that the new manuevers used SET rather than LOCK, but despite being called "set" it still locks the controls, and there's no way to unlock them. I haven't tried the new 'neutralize' that erendrake just made to see if that fixes it.

[Camacha]

About letting go of these new controls, I added ship:control:neutralize that should set everything to 0 and then release control. I was trying to figure out how to let go without a "turn me off" command and i couldn't quite figure it out.

Is that not what unlock was for?

[Dunbaratu]

Is that not what unlock was for?

LOCK has two important differences from SET:

1. The fact that it overrides user control.

2. The other effect is that the value can be a re-executable expression that is re-run each time the value is checked, rather than a flat value.

So if you want effect #1 without also having effect #2 there wasn't really a way to do that in the language. What happened with this SET is that it gives you effect #1 without effect #2, but then didn't have a corresponding UNLOCK to release it because it wasn't a LOCK in the first place. (And I did try it with LOCK first. It actually returns an error when you try to use it with LOCK. It only works with SET.)

[Camacha]

Hmm, I see. This could be terribly confusing, apart from that it still does not allow to set a value while still allowing user input.

[erendrake]

The problem is that the new manuevers used SET rather than LOCK, but despite being called "set" it still locks the controls, and there's no way to unlock them. I haven't tried the new 'neutralize' that erendrake just made to see if that fixes it.

It does appear that I have some work to do on these controls. It shouldn't be hard to change the behaviour to set. Steering helper fighting the direct method for control is going to be tougher but still shouldn't take long.

[erendrake]

.

I have, however, observed strange behaviour when running multiple but seperate kOS units side by side. Sometimes the non focussed kOS unit just goes haywire, gets deleted or somehow influences the focussed unit. I have only seen this behaviour in Kevin's versions though (and played a lot less since), so I have no idea whether this is still the case.

Most of the time they should be totally seperate. There are some static classes/members around that might cause commands to bleed over in strange ways. I'll have to audit these to make sure they are safely used

[Camacha]

Most of the time they should be totally seperate. There are some static classes/members around that might cause commands to bleed over in strange ways. I'll have to audit these to make sure they are safely used

The most notable example I can offer from the 0.7 era is one kOS controlled craft hovering rock steady. I switch to another vessel, order it up and attempt a similar hover. Not only does the second unit exhibit a large unexplained oscillation, the stability of the first unit seems to decay alongside the second one (albeit slightly less severe). The really strange thing is that when I switched vehicles on the fly, the first oscillating craft seemed rock steady again. Switching back to the second craft showed the oscillation in the first craft again.

I saw this happen a couple of times, but far from always. I could never quite replicate it reliably. For now it would proably be best to assume this behaviour does not exist, until I can find some prove of it in newer versions and preferably record or replicate it.

[Agathorn]

The most notable example I can offer from the 0.7 era is one kOS controlled craft hovering rock steady. I switch to another vessel, order it up and attempt a similar hover. Not only does the second unit exhibit a large unexplained oscillation, the stability of the first unit seems to decay alongside the second one (albeit slightly less severe). The really strange thing is that when I switched vehicles on the fly, the first oscillating craft seemed rock steady again. Switching back to the second craft showed the oscillation in the first craft again.

I saw this happen a couple of times, but far from always. I could never quite replicate it reliably. For now it would proably be best to assume this behaviour does not exist, until I can find some prove of it in newer versions and preferably record or replicate it.

There is a very good chance that KSP doesn't update the physics as often on the non-active craft.

[Camacha]

Have you seen the RISC version of kOS? It seems that might be a good way of increasing performance - or decreasing load. Do you think this will be useful to this version of kOS, or does that mean too much of a rewrite?

There is a very good chance that KSP doesn't update the physics as often on the non-active craft.

The weird thing is is that it is not very consistent. Stuff will go haywire sometimes and work perfectly fine at other times, with apparently the same starting conditions.

[erendrake]

Have you seen the RISC version of kOS? It seems that might be a good way of increasing performance - or decreasing load. Do you think this will be useful to this version of kOS, or does that mean too much of a rewrite?

I think its a great idea, My main goals have been to add new features to KOS to enable tasks like docking, science, Mod integration. I have also spent a bunch of time trying to make documentation that doesn't suck. I have spent very little time thinking about performance.

It looks like great work and i will see if marianoapp minds if i merge in his improvements

[Camacha]

It looks like great work and i will see if marianoapp minds if i merge in his improvements

Your version of kOS is becoming a black hole for good ideas - in the good sense

Edited February 23, 2014 by Camacha

[erendrake]

Your version of kOS is becoming a black hole for good ideas - in the good sense

My attitude is that none of us as as smart as all of us. Each of us has a focus and marianoapp's is clearly performance, Which we sorely need.

[Dunbaratu]

Idea: Mission Control's Mainframe CPU back home.

There is a a storage volume back home at KSC called "archive", by why do the only CPUs that can run code off that volume exist out on remote vessels? Wouldn't they know how to build a bulky mainframe computer and house it in a room in a building on the ground long before they learn how to put a computer on a spaceship?

What I'm thinking of is this: Add one additional kOS SCS CPU that lives not inside a vessel part, but just lives "in limbo". (Or, it does live in a "part" but that "part" isn't hooked into the rest of the structure for a vessel part. It's just a "part" object that lives inside the kOS Mod's own head and isn't connected to anything.) It's not part of the KSP physics engine. It doesn't get unloaded when a vessel goes out of scope because it's not on a vessel at all. It represents the mainframe back home at KSC. It can run code. It's default Volume is 0, the archive, and it doesn't have a local volume. It just runs natively off the archive. Because it's not on a part it doesn't unload and can continue running no matter where the game is focused. kOS just makes sure that the list of currently active CPUs it needs to execute instructions for when KSP runs its update hook for kOS includes this phantom mainframe CPU as well as the CPUs attached to loaded parts.

What the mainframe CPU could do:

Presumably the mainframe can obtain data about any named vessel in comms range (where the meaning of "in comms range" would vary depending on whether or not remote tech is being used, just like it does currently for seeing if a remote volume is reachable). Perhaps for realism, attempts to obtain telemetry about a vessel would generate a lightspeed delay in the execution of that command. Then the home mainframe could perform calculations without the limitations of lightspeed delay or small hard drives. For example:

// Running on the mainframe:
set ves to vessel("some name").
set vesOrb to ves:orbit. // This command takes lightspeed-delayed minutes to finish.
run calcTransfer( "Duna", vesOrb ). // mainframe makes complex calculations instead of the vessel doing it.
log burnStartTime to sendFile.
log burnAim to sendFile.
log burnDuration to sendFile.
// Now the vessel can "copy sendfile from archive" to get the result.

The mainframe could also be responsible for storing its own database of really complex slingshot planetary transport network calculations that it can use to tell the vessel what to do. Or it could run the over-arching "mission script" like I did in the Duna Challenge Mission 2 entry. That always felt a bit "wrong" because in my head I was imagining that that global script was running at home, telling the craft how to initiate each of its smaller script steps, but I knew that's not really what was happening in the mod because the computer was on the vessel and just accessing the mission script from the archive, rather than the mission script *actually* running back home on the archive.

It could also be responsible for getting the vessel set up on the launchpad. Imagine an init script stored on the mainframe that you run from the mainframe to copy the code and initial settings onto the vessel's computer before launch.

What to do with the mission control mainframe computer is really up to the player of course. I'm just thinking of ways it could be useful.

What it could not do:

Anything involving current vessel velocity or position or orientation. The current SHIP, is essentially, null for the purposes of running mainframe code. This may be the trickiest change as it would mean having to trap that condition and make sure it doesn't bog up the mod when there is no current ship, and instead gives a pleasant error message about it.

[erendrake]

Idea: Mission Control's Mainframe CPU back home.

There is a a storage volume back home at KSC called "archive", by why do the only CPUs that can run code off that volume exist out on remote vessels? Wouldn't they know how to build a bulky mainframe computer and house it in a room in a building on the ground long before they learn how to put a computer on a spaceship?

What I'm thinking of is this: Add one additional kOS SCS CPU that lives not inside a vessel part, but just lives "in limbo". (Or, it does live in a "part" but that "part" isn't hooked into the rest of the structure for a vessel part. It's just a "part" object that lives inside the kOS Mod's own head and isn't connected to anything.) It's not part of the KSP physics engine. It doesn't get unloaded when a vessel goes out of scope because it's not on a vessel at all. It represents the mainframe back home at KSC. It can run code. It's default Volume is 0, the archive, and it doesn't have a local volume. It just runs natively off the archive. Because it's not on a part it doesn't unload and can continue running no matter where the game is focused. kOS just makes sure that the list of currently active CPUs it needs to execute instructions for when KSP runs its update hook for kOS includes this phantom mainframe CPU as well as the CPUs attached to loaded parts.

What the mainframe CPU could do:

Presumably the mainframe can obtain data about any named vessel in comms range (where the meaning of "in comms range" would vary depending on whether or not remote tech is being used, just like it does currently for seeing if a remote volume is reachable). Perhaps for realism, attempts to obtain telemetry about a vessel would generate a lightspeed delay in the execution of that command. Then the home mainframe could perform calculations without the limitations of lightspeed delay or small hard drives. For example:

// Running on the mainframe:
set ves to vessel("some name").
set vesOrb to ves:orbit. // This command takes lightspeed-delayed minutes to finish.
run calcTransfer( "Duna", vesOrb ). // mainframe makes complex calculations instead of the vessel doing it.
log burnStartTime to sendFile.
log burnAim to sendFile.
log burnDuration to sendFile.
// Now the vessel can "copy sendfile from archive" to get the result.

The mainframe could also be responsible for storing its own database of really complex slingshot planetary transport network calculations that it can use to tell the vessel what to do. Or it could run the over-arching "mission script" like I did in the Duna Challenge Mission 2 entry. That always felt a bit "wrong" because in my head I was imagining that that global script was running at home, telling the craft how to initiate each of its smaller script steps, but I knew that's not really what was happening in the mod because the computer was on the vessel and just accessing the mission script from the archive, rather than the mission script *actually* running back home on the archive.

It could also be responsible for getting the vessel set up on the launchpad. Imagine an init script stored on the mainframe that you run from the mainframe to copy the code and initial settings onto the vessel's computer before launch.

What to do with the mission control mainframe computer is really up to the player of course. I'm just thinking of ways it could be useful.

What it could not do:

Anything involving current vessel velocity or position or orientation. The current SHIP, is essentially, null for the purposes of running mainframe code. This may be the trickiest change as it would mean having to trap that condition and make sure it doesn't bog up the mod when there is no current ship, and instead gives a pleasant error message about it.

This sounds like a fun project! I would love to talk to you about how it would be implemented. Lets setup a group hangout and get some comments on it. It also seems like the mainframe would be responsible for switching active vessels? Spawning new ships on the pad?

[Camacha]

Somewhat related: I would - someday - like to see kOS units have the ability to communicate. This might be in the form of networking like capabilities, or a more low level multithreading style mechanism. I think this is something for the far future, but having multiple units operating in concert should allow for some very funky and nifty schemes. I guess a mainframe computer would benefit from this too.

Stuff like building a super computer, neural networks or simulating the MSL landing sequence (with command being switched from the skycrane to the MSL) should all become a lot easier.

Edited February 23, 2014 by Camacha