[PLUGIN, WIP, 0.23] kRISC - kOS with a RISC heart

[erendrake]

I used module manager to add a kOS module to all of the stock command units just for aesthetics reasons. This project is a heavily modified version of kOS, but we are now in the process of merging it with the main version of kOS to have the best of both worlds

Cool! It makes a lot of sense to include it in the pods.

[Camacha]

Cool! It makes a lot of sense to include it in the pods.

Do you imagine that replaces seperate kOS units, or that those exist next to autonomous kOS units? Adding them to probe bodies does make sense, as even V2's had some kind of guidance. Though I am very slightly uncomfortable with adding them for free - especially in manned pods.

[Tallinu]

To think that a crewed capsule would NOT have the same computing resources as a probe, if not better resources, seems silly to me... Why force someone to attach a probe body on top of every crew capsule just to get access to that feature?

[erendrake]

Do you imagine that replaces seperate kOS units, or that those exist next to autonomous kOS units? Adding them to probe bodies does make sense, as even V2's had some kind of guidance. Though I am very slightly uncomfortable with adding them for free - especially in manned pods.

I would agree with you on pods like the Command Pod Mk1 where they are designed to be replicas of a part that never had a serious computer (mercury capsule). Once you make it to the Mk2 Lander Can Or the Mk 1-2 Command Pod I think they clearly have some kind of computer in them so i wouldnt mind giving them a KOS module. I do think that For very primitive pods I would like to see limits such as smaller memory, read-only memory and limited available sensors added. All of that is just a wish so far

[Camacha]

Edit: just thinking aloud here, feel free to poke holes in my post.

Not a line of thinking I disagree with per se. I does get me thinking about modularity - is it in those terms desirable that (almost) every pod automatically has stuff like this included? Or should users be able to tailor the hardware they send on a mission to their every need? I tend to side with the last idea, as that is the meat and bones of KSP. I think embedding them would also pose problems, as hardware with a certain speed is in that case intrinsically linked to that one pod. Using a single man pod for a mission would automatically mean using slow hardware. And although I do agree that most modern pods have computers on board, if some brave Kerbal decides to test his mental arithmetic, who are we to judge?

On a related subject: if the kOS units are integrated in the pods, do players pay the price in terms of weight and especially power requirements? Or would that not be fair, as there is no choice?

I do appreciate the ease of adding kOS to pods, but can't help but feel that it goes a bit against the grain of the game.

Sorry for the rambling, too little sleep and too much coffee.

[Dappa]

I was just thinking about modularity too, and I think Camacha has a good point. Modularity is what makes KSP so great. Having one part capable of doing everything would spoil that in my opinion, it's just too easy if you ask me. If you want to make a craft that can do everything, but it'll cost a lot of mass (and money).

In fact, I think Squad already takes this too far, by putting loads of torque on the capsules.

To think that a crewed capsule would NOT have the same computing resources as a probe, if not better resources, seems silly to me... Why force someone to attach a probe body on top of every crew capsule just to get access to that feature?

Well, then how much should a probe core (or crew capsule) be able to do? Real world robotic spacecraft execute a sequence of commands uploaded from the ground. They usually do very little decision-making, they don't calculate their own burns or required attitudes. The kOS computer lets us do much more than that, which brings us back to modularity.

I would agree with you on pods like the Command Pod Mk1 where they are designed to be replicas of a part that never had a serious computer (mercury capsule). Once you make it to the Mk2 Lander Can Or the Mk 1-2 Command Pod I think they clearly have some kind of computer in them so i wouldnt mind giving them a KOS module. I do think that For very primitive pods I would like to see limits such as smaller memory, read-only memory and limited available sensors added. All of that is just a wish so far

Just thinking aloud here, you could go as far to make certain computer types capable of executing commands, but not able to run programs, or disable certain logic? I'm sure you'll find the right balance.

[marianoapp]

All the features of v0.11.1 were successfully merged! Now both projects should have the same features, including the RemoteTech integration.

There are a few differences in this version regarding the RemoteTech integration:

- The integration is controlled by a config flag which is disabled by default (use "set config:rt2 to true" to enable it and then reload/change the vessel so the config takes effect).

- The progress bar is only shown when the delay is bigger than 0.5s to avoid the flashing on the screen.

- When the connection is lost the queued commands remain until the connection is re-established (the deployment of commands can be cancelled with ctrl+c/break).

- When the connection is lost running programs keep running but they can't move the ship since RT2 is blocking all input (but they can print stuff on the screen).

I also added a new config key "Start on Archive volume" that sets the Archive as the default volume when you reload a ship (no more "switch to archive" every single time ). To enable it use "set config:arch to true"

(To view the state of the current config you can list all the values with "list config")

[latest bin download]

[Dunbaratu]

All the features of v0.11.1 were successfully merged! Now both projects should have the same features, including the RemoteTech integration.

Is there a good reason for them to continue being two separate projects? It sounds like if they stay separate then you just have to keep re-doing the merge effort again and again on a regular basis.

[erendrake]

Is there a good reason for them to continue being two separate projects? It sounds like if they stay separate then you just have to keep re-doing the merge effort again and again on a regular basis.

I am not interested in parallel projects when we can combine our efforts on one great mod. marianoapp and i need to have a meeting of the minds on which one (kOS or kRISC) will continue active development. I would be happy to continue as maintainer and i setup a Github Organization if we wanted to share admin on the project.

@marianoapp would you like to have a skype/hangout discussion on this?

[Camacha]

Oh, I kind of assumed the regular kOS would continue feature wise, with the works of kRISC under the skin. I understand there is a large performance boost to be expected by the kRISC approach, so I do not really see what added value of the 'old' kOS inner workings would be. But of course, I am hardly informed when it comes to technical matters, so I might be totally missing something crucial

Speaking of performance, I am really eager to get my hands on the kRISC version to do some optimization tests. I just came up with a couple of ideas for software that could really benefit from all this.

I love all the optimism and energy, I feel this development is really something great.

Edited March 6, 2014 by Camacha

[erendrake]

Oh, I kind of assumed the regular kOS would continue feature wise, with the works of kRISC under the skin.

There is no argument about which codebase we will use, all of the performance gains of the new parser with all of the features of v0.11.1 is a no brainer

It just comes down to who will be charged as "maintainer" and which name the project will use. I would release these bits as kOS v0.12 today and deal with whatever bugs we find but i would like to talk to marianoapp first to be sure that is ok. there is a ton of good work in here and i want to be respectful.

[Camacha]

O yeah, just out of curiosity - is the plan to increase the speed of kOS, or are you reserving the performance increases that are not direct (like a better behaving KSP when running multiple units) for something like faster and higher tech kOS units down the line? Or something completely else of course.

I am not sure what I want when it comes to processing speed A fast script enables you to do some really interesting and high tech things, but it also provokes more sloppy writing and less creative solutions. Slow processing really forces you to make the most of what you get.

[Horus]

@erendrake: you are totally right - you need to join your forces on this AWESOME automation mod. Automated drones creation is a pure enjoy for me.

Thanks for your efforts, guys!

[erendrake]

O yeah, just out of curiosity - is the plan to increase the speed of kOS, or are you reserving the performance increases that are not direct (like a better behaving KSP when running multiple units) for something like faster and higher tech kOS units down the line? Or something completely else of course.

I am not sure what I want when it comes to processing speed A fast script enables you to do some really interesting and high tech things, but it also provokes more sloppy writing and less creative solutions. Slow processing really forces you to make the most of what you get.

Lets get this code out for a spin and see if speed is still an issue we need to worry about.

[Camacha]

Lets get this code out for a spin and see if speed is still an issue we need to worry about.

Sure, first things first I think the speed of development is amazing enough. I was mostly referring to artificially limiting speed though.

[marianoapp]

(...) I was mostly referring to artificially limiting speed though.

Right now there is a config option that limit how many instructions per update the CPU can execute, and you can change it to whatever you want (the default is 40 but I think it should be higher).

That means that if the game is running at 30fps you can execute a maximum of 40*30=1200 instructions per second. You have to be aware that these instructions are actually CPU instructions, so for example a command like "set a to 1 + 2" ends up as 5 instructions after being compiled.

If you change the config from 40 instructions per update to only 1 (still running at 30fps) you'll be barely able to execute a few commands per second, and it would be impossible to run, for example, a hovering script.

In fact I think that the extra speed has to be taken into account when writing a script, because it can happen that a simple control loop is executed more than once in a single update, and that can mess with PI controllers for example that store the accumulated error.

[erendrake]

Right now there is a config option that limit how many instructions per update the CPU can execute, and you can change it to whatever you want (the default is 40 but I think it should be higher).

That means that if the game is running at 30fps you can execute a maximum of 40*30=1200 instructions per second. You have to be aware that these instructions are actually CPU instructions, so for example a command like "set a to 1 + 2" ends up as 5 instructions after being compiled.

If you change the config from 40 instructions per update to only 1 (still running at 30fps) you'll be barely able to execute a few commands per second, and it would be impossible to run, for example, a hovering script.

In fact I think that the extra speed has to be taken into account when writing a script, because it can happen that a simple control loop is executed more than once in a single update, and that can mess with PI controllers for example that store the accumulated error.

We could easily hook something like this up as a tweakable. so we could give each mission its own clock speed.

[Camacha]

In fact I think that the extra speed has to be taken into account when writing a script, because it can happen that a simple control loop is executed more than once in a single update, and that can mess with PI controllers for example that store the accumulated error.

That should not inherently be a problem, as long as kOS users have some insight into what happens. If results vary from time to time without some indication of a cause it will become very frustrating very quickly

[marianoapp]

We could easily hook something like this up as a tweakable. so we could give each mission its own clock speed.

Yes, that would be interesting, right now all the configurations are plugin-wide and apply to all the savegames.

[Camacha]

We could easily hook something like this up as a tweakable. so we could give each mission its own clock speed.

That sounds like a pretty neat thing. I can imagine there being some kind of incentive to keep the speed down, such as power consumption or something else you would need to balance against speed. If you want to take it even further it might even be adjustable from within the script, so you can implement things like the CPU governers found on real life phones. Turn it up when needed, slow it down when idle or sleeping. Scriptable adjustments might be taking it too far though.

Maybe another slider for the memory in relation to the weight could be made

[marianoapp]

If you want to take it even further it might even be adjustable from within the script, so you can implement things like the CPU governers found on real life phones. Turn it up when needed, slow it down when idle or sleeping. Scriptable adjustments might be taking it too far though.

Already works like that

The whole config is a structure that you can modify from a script, so writing a command like "set config:ipu to ##" changes the execution speed, although there's no real need to slow down right now.

[Dunbaratu]

I am very very happy to find that both project maintainers are willing to merge the two projects into one. To me that is far more important than any new features and I'm willing to wait quite a long time on feature updates if that's what it takes to get the two to become one. I'm willing to be a testing guinea pig for the merged version when a release candidate appears.

[Camacha]

Already works like that

Nice one! I guess the rest comes down to whether you want an incentive for slowing the speed down. I would not mind that, as balancing those kinds of things out is a part of engineering, as long as we can find a way to do it that feels natural, of course.

I am very very happy to find that both project maintainers are willing to merge the two projects into one.

Same here. Hear, hear

Edited March 9, 2014 by Camacha

[Dunbaratu]

You might want to deliberately slow down the speed if the computer you run KSP on isn't super fast, to ensure the kOS code doesn't end up choking the simulation to the point where it stutters. We've already seen that it's possible for kOS to starve the main KSP thread of time so that KSP stutter-pauses its simulation. Granted, that was because of a bug that clogged the execution queue with more and more pointless no-op work as a loop iterated. Still the fact that kOS (or any mod) that takes a long time to finish responding to an update call can starve KSP of time like that could mean that someone may want to throttle back their code if their animation starts stuttering. If they've got kOS and a bunch of other mods too it might hit a point where it's too much to finish all the updates all the mods are doing in one physics tick.

[drtedastro]

user options.... build it for max possible and then let user decide how much or how little.

based on user desire, percent efficiency can set up wait-state loop / branch / no-op or such.