[WIP] Jebnix - A kOS Alternative

[John FX]

Please make sure it can maneuver the ship using the gimbals and not the torque. Kos can only manipulate the torque so those of us using realism mods with no torque in parts need the OS to be able to access the engine gimbals and move them to the same degree the keyboard can.

Um... KOS currently does use the gimbals and can fly a ship using no torque. Like so. It can also fly using only fins and it uses RCS in space.

Javascript is disabled. View full album

[woodywood245]

This would really be a major improvement over kOS. It would make programming much easier to be able to enter angles directly (Pitch, Roll, Yaw), instead of rotational vectors from a reference direction, as in UP + R(0,0,180) + R(0,pitch,0). It took me days to figure how kOS (and KSP) handles the internal frame of reference and it remains an unneeded complication to me. Just as KSP keeps that reference for internal purposes only, but shows angles that are consistent with the relative orientation of the craft (IRT the main body), the same approach would be best if used by Jebnix.

I will add this request to the list.

[Zander]

Um... KOS currently does use the gimbals and can fly a ship using no torque. Like so. It can also fly using only fins and it uses RCS in space.

Why doesnt it work on mine?? when i turn on rcs and let kos control it it just fires all of them at the same time and the ship jiggles but doesnt turn the way it should.

[HoneyFox]

That concept is interesting. I see that not much in the way of a "distributed intelligence" to each single part, but about specific actions for each part triggered by different events, all those "scripts" active concurrently within Jebnix CPU.

But to implement that, I hope those actions can be executed independently of the standard 10 action groups + standard switches, or we run out of possible actions pretty fast.

Yes all these scripts (normally will run in its own loop) run concurrently and options can be provided to pause their own scripts.

There's no need to worry about action group limitation because we can code to invoke an action of a part by the action's name, which is totally not related to the action group system.

[HoneyFox]

Why doesnt it work on mine?? when i turn on rcs and let kos control it it just fires all of them at the same time and the ship jiggles but doesnt turn the way it should.

I don't think KSP has provided interface in FlightCtrlState to individually command a reaction whell / an engine to adjust attitude.

The control is a global one and all parts will try to follow that if possible (has reaction wheel / engine has gimbal) and if allowed to (reaction wheel enabled / gimbal is freed)

[diomedea]

There's no need to worry about action group limitation because we can code to invoke an action of a part by the action's name, which is totally not related to the action group system.

Uh, sorry, slow down a bit, I'm not following what you mean... "we can code to invoke an action of a part..." not related to the action group system, to me means you want to invoke a specific part.module and those are coded in the KSP.exe (the native ones) or in plugins built to support those parts. But that means to me, Jebnix should be made aware of all part.module definitions (even for future parts!) and include some way to call the methods in those plugins. That certainly requires coding, but by Jebnix author, not by a user who will just create scripts to be run in Jebnix. So, if I'm wrong or missing something, please clarify your idea.

[John FX]

Why doesnt it work on mine?? when i turn on rcs and let kos control it it just fires all of them at the same time and the ship jiggles but doesnt turn the way it should.

Have you tried an install with just KOS to fault-find and check for mod interactions?

EDIT : Maybe this would be better in the KOS thread? This is the thread for discussing JebNIX after all...

EDIT 2 : Just looked again at the first post which has been uupdated. looking good!

EDIT 3 : for `distance delay` would this be possible to optionally integrate with remotetech? I imagine in an ideal world RT would take care of all the route calculation/loss of signal and be able to let other mods know the delay as a single figure in seconds so JebNIX could either use that figure or it`s own one derived from kerbin distance. This would mean sometimes loss of signal. I would imagine JebNIX would continue to run any programs that were started by this point but not accept input.

That would be cool. To totally rely on your program to execute the mission beyond radio range...

EDIT 4 : Just read about Multitasking. Multiple scripts running, each on its own process, each with its own memory space (no sharing variables).

Interprocess and intercomputer communication. Threads and computers could send and receive messages to each other without using a convoluted hack.

My first thought was multipart ships that break apart in orbit and stay within 250m of each other hurtling down through the atmosphere to the ground and land in formation...

Please let processes continue on units that are on other craft but within 250m.

Edited January 9, 2014 by John FX
read first post again.

[HoneyFox]

Uh, sorry, slow down a bit, I'm not following what you mean... "we can code to invoke an action of a part..." not related to the action group system, to me means you want to invoke a specific part.module and those are coded in the KSP.exe (the native ones) or in plugins built to support those parts. But that means to me, Jebnix should be made aware of all part.module definitions (even for future parts!) and include some way to call the methods in those plugins. That certainly requires coding, but by Jebnix author, not by a user who will just create scripts to be run in Jebnix. So, if I'm wrong or missing something, please clarify your idea.

Ah... for those actions (shown in action group editor) or events (shown in part's context menu), they are stored in a list in part modules(including modules implemented by 3rd-parties plugins, as you stated "future parts"). So the Jebnix plugin can of course scan these lists to acquire all available actions/events.

However, Jebnix plugin will never be able to know what an action mean, to invoke which action/event should be decided by users, so Jebnix needs to provide some kind of debugging tool to list all these actions/events so that users can choose which one to invoke.

To make things more understandable. Here is a simple process:

1. User enter something like: List part(...).module

Jebnix returns names of all part modules in that part, might be something like this if used on an engine: ModuleEngines, ModuleGimbal, ModuleAlternator.

2. User enter something like: List part(...).module(ModuleEngines).action

Jebnix returns names of all actions in that part module, might be something like this if used on an engine module: active, shutdown.

3. User now know what choices are available. And he can write something like this in his script:

Invoke part(...).module(ModuleEngines).action(shutdown).

Hope that i made it clear to you.

[diomedea]

Hope that i made it clear to you.

Certainly that example helped a lot to make it clear, thanks for that. That resembles to me how methods and properties are parsed by the editor in a modern IDE. Hope that is doable also in Jebnix, sure it gives a lot of "programming power" to the user. A lot more powerful than what a simple script would allow.

[John FX]

Certainly that example helped a lot to make it clear, thanks for that. That resembles to me how methods and properties are parsed by the editor in a modern IDE. Hope that is doable also in Jebnix, sure it gives a lot of "programming power" to the user. A lot more powerful than what a simple script would allow.

It does sound very powerful if it can be implemented. It would seem to suggest that `control from here` on a docking port would be an option that this would allow for example. If we can find a way to target docking ports on another craft... you can tell where this is going.

How possible is it to send translation commands (ikjlhn)?

[woodywood245]

It does sound very powerful if it can be implemented. It would seem to suggest that `control from here` on a docking port would be an option that this would allow for example. If we can find a way to target docking ports on another craft... you can tell where this is going.

How possible is it to send translation commands (ikjlhn)?

There are some technical details I need to work out, but I'm hoping to have translation capabilities built in to Jebnix.

[woodywood245]

Ah... for those actions (shown in action group editor) or events (shown in part's context menu), they are stored in a list in part modules(including modules implemented by 3rd-parties plugins, as you stated "future parts"). So the Jebnix plugin can of course scan these lists to acquire all available actions/events.

However, Jebnix plugin will never be able to know what an action mean, to invoke which action/event should be decided by users, so Jebnix needs to provide some kind of debugging tool to list all these actions/events so that users can choose which one to invoke.

To make things more understandable. Here is a simple process:

1. User enter something like: List part(...).module

Jebnix returns names of all part modules in that part, might be something like this if used on an engine: ModuleEngines, ModuleGimbal, ModuleAlternator.

2. User enter something like: List part(...).module(ModuleEngines).action

Jebnix returns names of all actions in that part module, might be something like this if used on an engine module: active, shutdown.

3. User now know what choices are available. And he can write something like this in his script:

Invoke part(...).module(ModuleEngines).action(shutdown).

Hope that i made it clear to you.

This is an interesting idea. I will look into it.

[John FX]

How`s everything coming along? Is there a tentative ETA for beta release?

[FanaticalFighter]

Wow, this will be amazing. Any idea when you'll be able to do the alpha testing?

Also, I have one small recommendation. Using kOS in Real Solar System, I couldn't connect to the archive (I think the location of Kerbin is hardcoded into kOS) Could you code in something that figures out where Kerbin is and does the whole antenna thing accordingly?

[JackGruff]

Whatever you do, please make it part-less. It's display can be toggleble via http://forum.kerbalspaceprogram.com/threads/60863

[Mihara]

/me peeks in.

Just when I wanted to start working on kOS/RPM integration.

I want a place where I can hook a terminal in, partless or not.

[diomedea]

I am in full support of this mod.

What kind of parts are you planning to have? CPU and additive hard drives separately? In-line and radial? If you need my modeling services I'm available for a few parts.

Whatever you do, please make it part-less. It's display can be toggleble via http://forum.kerbalspaceprogram.com/threads/60863

Knowing there will be nothke making those parts, I would not like to not have them. But, many "computational" tools were questioned because of their reliance with parts (MechJeb, Protractor, Kerbal Engineer Redux, kOS itself, to name a few).

I would propose the possibility to have two different setup for the same functionality, and believe it may be as easy as to set a switch or a config value, to let the user decide if Jebnix is made dependent on its parts or not with that user install.

[JackGruff]

Knowing there will be nothke making those parts, I would not like to not have them. But, many "computational" tools were questioned because of their reliance with parts (MechJeb, Protractor, Kerbal Engineer Redux, kOS itself, to name a few).

I would propose the possibility to have two different setup for the same functionality, and believe it may be as easy as to set a switch or a config value, to let the user decide if Jebnix is made dependent on its parts or not with that user install.

I've always thought needing parts to be immersion breaking. It doesn't make sense to me. Every bit of funtionality that kOS would need in RL could concievably be provided in the space of the probe cores and command pods. Or you imply that they cannot fit a CPU or hard drive in there? That's silly.

But to appease both crowds, I would just make it a single line in a config like you said. Part-less mode: works as long as there is a command part of any sort (except chairs, I guess). Part mode: needs the part. Simple.

[diomedea]

I've always thought needing parts to be immersion breaking. It doesn't make sense to me. Every bit of funtionality that kOS would need in RL could concievably be provided in the space of the probe cores and command pods. Or you imply that they cannot fit a CPU or hard drive in there? That's silly.

But to appease both crowds, I would just make it a single line in a config like you said. Part-less mode: works as long as there is a command part of any sort (except chairs, I guess). Part mode: needs the part. Simple.

Be sure I am not implying what you wrote. My point was very different, and making that "silly" appreciation in that way makes my opinion very negative.

Those computational tools (I know about a lot of them) certainly would fit a CPU, that as you suppose can easily be considered already existing within a command pod. But it would be more than adequate to consider parts also as SOFTWARE. And that software must actually be installed within that CPU or you don't have it. So much, I would say it is immersion-breaking to NOT have a part (to each his own! You are entitled to your opinion, others to theirs). When we will have to compute the cost in building a craft, we are going to add also the software parts installed (no pirated software here). What I agree with, instead, is we don't need any hardware parts unless those are very specific with some feature in the mod that has reason to exist in a hardware piece. Take, e.g., the MechJeb Pod.

I hope now you get what I mean. If you don't concur, that's to you. If you dare again to mark anybody else's opinion as silly, I will request a ban on you.

[willow]

Instead of building your own language, or continuing on the "less than stellar" syntax of kOs.

Why not simply implement an existing game scripting library? Like Lua, or Javascript?

The obvious benefits are twofold...

First of all you don't have to worry about language and syntax, only implementation, so you can spend all your time on getting the language to work with KSP well..

Secondly. People don't need to learn a new language which in it's initial stages is likely to be very fickle and buggy. And they get to use existing editing tools like luaedit and learn from existing internet resources.

Your work would then be restricted to handling in and output to and from the script. Meaning you get to add lots of features in little time once the initial plumbing is done.

[Dunbaratu]

I hadn't noticed this thread before. This would be good if it can be accomplished. It's a pretty ambitious set of goals.

What are the plans for release?

1 - Release nothing until all the goals in the bullet-point list are met.

2 - Release when some of them are met, and plan to hit the rest in future updates.

[Dunbaratu]

At the moment, I'm working on my variant-type structure, which will handle operations between different types.

kOS is by definition a loosely-typed programming language, though I'm not entirely sure if it's implemented that way in kOS.

Most operators, such as subtraction, multiplication, and division, cannot be performed on string values. Bitwise operations cannot be performed on strings or floating-points. I prefer to control the implementation of operations myself because I know what the result will be, and so will the user.

I have two choices:

1. Throw an exception in the event an invalid operation is performed. Or...
   
2. Cast the variant to a valid type and then perform the operation. (Strings that cannot be parsed are interpreted as 0 or False depending on the type.)
   

Do you plan to use the addition operator (+) for string concatenation like what kOS does now? Because if so then it would be nice if there was a way for the script writer to pick which meaning of "+" was meant - string concatenation or math addition. Imagine if you implemented automatic casting (which I think is the right way to go to make the language newbie-friendly), then it would be very odd and confusing if the following two statements get treated differently:

set val to "50".

set answer to val + 1. // Result: answer = "501" because '+' is concatenation.

set answer to val - 1. // Result: answer = 49 because '-' is math subtraction and "50" got parsed into a number.

To have the '-' and the '+' operator give such opposite behaviors would be weird, and it would mean if you really DO want addition you'd have to subtract a negative, which would be really messy looking.

One possible solution: Don't overload the meaning of "+" to be concatenate anymore. Concatenate with a different operator. (problem, backward compatibility with kosscript).

Another possible solution: Although automatic casting exists, also provide a means for manual casting, so someone can do something like this:

set answer to val:AS_NUMBER + 1.

(I was thinking what would make a good "cast" operator and thought the : suffix format might work for it and be in keeping with how the rest of kOS looks, as in: :AS_NUMBER or :AS_STRING. )

[Dunbaratu]

Good luck, this looks great. I was hoping someone would continue with the KOS-style update.

Could you add an option for a directional alt-radar? Instead of reading straight down, maybe read distance to ground from the ship's bottom depending on its orientation relative to the ground?

I think it makes sense to invent a Part for this - a small itty bitty thing the same size as the little science instruments like the Gravioli Detector of Seismometer. Then instead of using the orientation of the craft, you base it on the orientation of the part. Whichever way the distance-finder-part is pointed, that's the line it shoots its "ray" in to look for intersecting terrain. Most of the time, you'll want to mount it aimed down to get the behavior you mention, but for other purposes you could mount it in other directions.

[Rosco P. Coltrane]

Besides wishing you good luck, I'd also like to make a petition here: please document your stuff!

As the author of an IDE for kOS looking into supporting Jebnix, lack of documentation is a hell of a problem. And for your potential users too.

Good luck man!

[Dunbaratu]

Because this project looks ambitious and I therefore expect it will be quite a while before there's a release, I'll continue using eerandrake's attempts to make a kOS 10.0 that is compatible with KSP 0.23 in the meantime. But once this thing is working well I'd definitely want to use it.

To that end, is backward compatibility with kOSscript really a necessary goal? If you're going to rebuild everything from the ground up anyway, and it will probably differ enough to require people to re-write scripts anyway (many scripts have weird twiddly behavior to work around bugs that you'd hopefully be trying to get rid of), maybe it's not as important to make it kosscript compatible. I don't know - it's up to you at any rate. I wish you good luck. I want to use this.