The Kerbal KAL Logic & Computing Laboratory [WIP]

[HB Stratos]

Looks awesome! I definitely need this tool now, to figure out what the heck might be broken in a craft file I am dealing with. Is it somehow possible to make it draw a craft tree where it displays which part is attached to what and with what means it is attached?

[Nazalassa]

Going to be more difficult, but... maybe I can manage it... if I find time. I'm currently learning xcb (X C Bindings) so I probably won't be into Python "in a relatively close future". But I'll see what I can do before next vacation; I may find some time to work on it.

I think I can do *some* 3d rendering, but just lines between the centers of attached parts. Probably not more.

[Nazalassa]

Idea fir instruction set: every instruction is a 'MOV'. There are as many registers as we want connected to the bus. Since there is only 1 instruction, we can drop the opcode, and encode instructions as 16-bit (65536) numbers - two opcode registers will be needed. Some registers do stuff with what's in them - so for example registers 0x10 and 0x11 are the adder inputs, and 0x12 is its output, 0x13 and 0x14 are the carry in/out resp., maybe 0x15 and 0x16 are for ror, 0x17 and 0x18 for rol, 0x19 and 0x20 for inc, etc. and the rest can be used as memory.

I'll try to make a bus that takes two numbers and transfers from the first to the second.

 

(that's an highly orthogonal RISC architecture lol)

[Nazalassa]

Log 23.9

I have some good news and a less-good new.

1. I have successfully made a bus which can MOV from one register to another, both specified by two special KALs. That means we can do MOVs. So we can have as many as 256 registers.
2. Each MOV instruction takes 4 phys-ticks, so if we made a computer out of that, it will likely be 6.25ips. It may be possible to pipeline MOVs at 3 phys-ticks (8.3333ips) as MOVs consist of two parts, [write to the bus] and [read from the bus]. Each takes 3 phys-ticks, but the latter is delayed by 1 phys-tick, for technical reasons.
3. Even if I use 3 KALs per storage register, I think I can as well use 2, since purely storage registers don't need an always-active KAL.
4. I have some ideas for memory, and 256 machine words may take like 4 or 5 KALs.
5. HOWEVER, less-good new: I have made some calculations ; assumig we have three buffer fields per register (two in the register itself + one in the bus), that makes around 1,700 lines per register in the craft file, so for example, if we have 48 registers, that makes around 81,600 lines. With an average of 42 characters per line (I think this is more or less a correct approximation), that makes 3,427,200 characters, so the craft file will be around 3.27 MiB (or 3.43 MB). I'm not sure how KSP handles craft files that large, but I suspect some replica crafts are even larger, so if anyone has data to give...
   Besides, I'm not sure how KSP will handle the KALs. There will "only" be a hundred or so, but most of them will have buffers in them (512 points) which may be bad for performance, although I have not tried.
   Anyways, that's only for 48 registers. 96 would be better - more storage! - but that would also be 6.5 MiB.
   It would definitely be better if we could just define the buffer in one place and then just refer to it in the other KALs. I don't know if it's possible, nor do I know how to do it.

Download: https://kerbalx.com/Nazalassa/bus-mov-test

Edited July 14, 2023 by Nazalassa
Download added!

[Nazalassa]

On 3/6/2023 at 2:37 AM, HB Stratos said:

A word of caution though, when playing with complex KAL mechanics on my 1k part concorde I have run into the issue of larger time skips causing issues with the averaging skipping around more. If we end up running into lag we may need to clock down the CPU beyond what the physics tick rate dropping would already do to ensure reliable function. Also, we cannot use axis groups as input, at least not without major filtering. Even when set to playing axis grouped KAL appear to be updating on a different clock cycle, therefore making the averaged output of that KAL and another one flutter between a real average and the value of the non-axis KAL.

Just asking, but (if you still have the craft file) what is the size of the craft file?

[HB Stratos]

4 hours ago, Nazalassa said:

Just asking, but (if you still have the craft file) what is the size of the craft file?

about 5000kb, so 5mb? The biggest craft on KerbalX is currently ~15mb (https://kerbalx.com/HolidayTheLeek/Aqua-sama) so I think we should be good. It will just take ages to load. 

I think KALs also run on update(), not on fixedUpdate(), which is to say they run with every frame you see on screen, not every physics frame. This can actually cause issues with using axis groups as input as they update with fixedUpdate(). See this bug report I wrote for KSPCF: https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/129

Other than that, cool to see you still working on this. I haven't really checked in here much as I am working on finishing my concorde when I play ksp, and on university when I don't. 
 

[Nazalassa]

13 hours ago, HB Stratos said:

about 5000kb, so 5mb? The biggest craft on KerbalX is currently ~15mb (https://kerbalx.com/HolidayTheLeek/Aqua-sama) so I think we should be good. It will just take ages to load. 

I think the part count shouldn't be a problem, as there are like 2.2 KALs per register (rough estimate), but... Maybe loading time will be awful. Editing the file will be awful, too. Would be waaaay too hard to find the right KAL and then edit it. I really should work on something that purely edits KALs before we try it on a larger scale.

Maybe we should begin with 48 registers? 32 storage, and 16 special ones (like if you write to them and then read from them, you get what you wrote but a NOT has been applied to it, also a register for the IP, one for the address to look in the memory that, when read, gives what's at the address, etc.)

13 hours ago, HB Stratos said:

See this bug report I wrote for KSPCF: https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/129

But can't we just proxy the KAL linked the the AG in the case you describe (t)here? Like the other one.

[Nazalassa]

In other news, I am working on a second version of cfp, and I managed to make a function that finds stuff:

 find(config, name, value)

  -> returns the list of structures in config so that they have name=value
     example (cuz I'm bad at explaining): find(config, 'VESSEL/PART/MODULE/target', 'val') will find all MODULEs which are inside
                                          a PART which is itself inside a VESSEL, and which have target = val.

Do you think it should rather return the VESSEL (if called with VESSEL/.../name)?

 

** UPDATE **

I added a "just name" and a "absolute only" functionality to the find function.
If the path (or "name" as I called it) starts with a '/' then it will look for VESSELs (assuming you start with '/VESSEL/...') only in the config root, and not in all substructures of the config.
If value is not specified, then it returns whatever has that name (doesn't check for values), so searching for 'PART/MODULE/CONTROLLEDAXES/AXIS' will give all KAL fields ('AXIS{...}') in the config. Searching for '/PART/MODULE/name' with value='ModuleRoboticController' will return all KAL controller modules, provided that they're in a PART that is in the root of the config (it is the case in .craft files). Then performing another search, on each of them (by changing the 'config' parameter) for '/CONTROLLEDAXES/AXIS/timeValueCurve' will give you, for each KAL, all of its timeValueCurves.

Note: if what I wrote is un-understandable, just tell me.

Edited July 15, 2023 by Nazalassa
UPDATE

[Nazalassa]

Small update: KAL application suite is getting closer! I got back to the project this afternoon - after like two months away - and I got the main script working.

[Nazalassa]

Another small update: KAL module main script (left) is finished! It features a "search" function to find KALs by name. Now I'll work on the KAL track editor (right).

               

Edited September 15, 2023 by Nazalassa

[HB Stratos]

This is very awesome! Sorry, I've gotten kinda swamped up in other projects, but this is still awesome to see, even if I don't play too much KSP at the moment. There's a lot of potential here.

[Nazalassa]

9 hours ago, HB Stratos said:

This is very awesome! Sorry, I've gotten kinda swamped up in other projects, but this is still awesome to see, even if I don't play too much KSP at the moment. There's a lot of potential here.

I think I'll rework half of the core. There's a lot of stuff missing in what I've done, namely:

• Getting the parent of a node
• Better search function
• A way to lock part, or all, of a config file
• Something better than a list to hold the config (class Megalist is coming)
• And more caveats and issues

Edited November 2, 2023 by Nazalassa

[Nazalassa]

Update on cfp: that's the second time I rewrite this program!  I got a working Node() class which is a fancy dict, with functions to get all values corresponding to a name, etc. Plus a class for the scripts manager. And reworked functions to load/save stuff from/to file. Once that is done I will rework the main script.

I made a custom Treeview with integrated scrollbar and search area, too. That will be more than useful.

I know this is becoming the cfp thread, but I prefer having a program that sets KAL curves automatically, rather than copy-pasting the same thing over and over again.

-- Upd. --

Revised main script! Now capable of having multiple files, and switching between them! And also running scripts, on the selected file. (the font change is due to fontconfig including bitmap fonts on my computer now)

-- Upd. 2 --

Main script and KAL-utils KAL list are done. I might have to rewrite the file opening part of the main script, though.
Next, utlity functions, and KAL editor interface.

Edited March 3 by Nazalassa
Half-done

[Nazalassa]

Made some progress the last few days, the most important being the ability to copy data from KAL curves to files, and vice-versa! The next thing to do (hopefully that won't take long) is to add track creation/removal functions. Hopefully that won't be hard, and won't take too long (the behind-the-scenes function is already made, all that's left is to make an interface to it).

I know it's a bit silly to have to start a main script that only proposes another script, but who knows, it may be useful. Still, you can directly launch /kal-utils-main as the start script, but it doesn't support file saving/opening... etc etc etc.

(oh, and it works with actions as well as axes!)

-- Upd. --

The 'delete' buttons now work, and the track's target is now shown under the track preview. Only thing left is the 'create new track' thing. I guess I'll put it in the bottom-right empty space.

Edited January 17 by Nazalassa
Update

[Nazalassa]

Log 24.1

 

Well well well, I have some good news! I just finished the track adding part and fixed a lot of quirks and bugs. cfp 0.3 is now usable!

This version of cfp can be found in the git repository here.
It (no longer) includes a test craft (kaltest) which you can (no longer) use as a sandbox. If you want to edit some text, look in the 'msg' dictionnary at the beginning of each file.

To launch: open a terminal in the 'cfp_0.3' folder from the tgz and run './cfp_0.3 -i <path-to-craft-file>' (without the quotes). There can be as many '-i' options as you want, and of course there also is a '--help' option, which will tell you of all other options.

Some documentation will come soon.

---

We can soon start doing stuff again! Just give me some time to get some documentation and some prebuilt curves.
I have a 256 register array in progress, which will have a file size of (quick estimation) 20 Mb. It is currently at 6.3 Mb, with 512 KAL controllers, 256 of which have a track with 512 points, and 16 structural panels. It takes 10 seconds to load. Of course, I'll do it for 256 registers, then make the first 16 or so "special" ones (adder and stuff), add a bus, and if you need less just remove some.
Thanks to Emacs kbd macros, I got unique names for each register (R00 to RFF and R00r to RFFr).

I also made a modified version of the KAL editor, to blend the KAL list and the KAL editor; so much more practical.

 

Edited March 3 by Nazalassa
Moved link to Codeberg

[Nazalassa]

Log 24.2

Wiring complete! The 256 register bank now has 768 buffers in it, in 513 KALs. Next: implement the MOV instruction. That will take some more time. File size: 15 Mb.

Spoiler

On 7/14/2023 at 9:56 PM, HB Stratos said:

The biggest craft on KerbalX is currently ~15mb (https://kerbalx.com/HolidayTheLeek/Aqua-sama) so I think we should be good. It will just take ages to load.

That one will not remain the biggest for long

Loading time: approx. 30 seconds in KSP, less than 1 in cfp. cfp is python so it's supposed to run like 10x slower than KSP. However it actually runs 30x faster, which means KSP does stuff 300x slower than cfp. Isn't there, like, an optimisation problem?
Also, removing or placing a part takes like 20 seconds. lol.

-- Upd. --
There is now a KAL controller with 1030 tracks. I think it's a new world record.

Edited January 21 by Nazalassa

[Nazalassa]

-- Upd. 2 --
The forums won't let me edit the previous post, for some unknown reason. Therefore I am forced to create a new post.
I am trying to launch it. If it doesn't crash, I will try to operate MOVs between registers 00, 01 and 02, for which MOV has been implemented.

Time between 'launch' button press and loading on the runway: 1m 36. Seems to launch without problems otherwise.

Problem: I have a very bad function to allocate persistent IDs. I just discovered read KALs from registers 00 - 3F modify write KALs from registers 40 - 7F instead of 00 - 3F. Only these KALs seem to be wrong. Will investigate.

-- Upd. 3 --
Corruption fixed for registers 00, 01 and 02; let's see if it works.

-- Upd. 4 --
OH YEEEEEEEES DANG KRAKEN IT WORKS!!!!1!!111!!!1!11

*ahem*
And each MOV takes about 4 phys-ticks.

Only need to fix a problem, which is that reading from register 00 doesn't disable it.

Spoiler

Here's the beast:

-- Upd. 5 --
MOV KAL toggling is done, thanks to a little scripts that made the times from a KAL's name. Now I have (in theory) a bus with 256 registers connected to it, and a MOV operation. Needs testing though.

Edited January 22 by Nazalassa
corruption

[Nazalassa]

I didn't even realize I forgot to put the register bank on kerbalx. Sorry for that.
Kerbalx link: https://kerbalx.com/crafts/80789

[Nazalassa]

For convenience, I have created a git repository on Codeberg to put all the things I have done since the beginning of this thread.
Link: https://codeberg.org/Nazalassa/KALlogic

[HB Stratos]

Wow, been a while since I had the time to pass by here. All I can say is this looks extremely impressive. Very cool to see so much working already. Due to the compression of multiple states into a single KAL (and my long break) it has gotten quite hard to follow what the thing is actually doing and how, but it sure as hell does look impressive. Glad to see you're still working on it. I really do hope to join in again when my workload loosens up. University has sadly not been kind. 

[FleshJeb]

Really pleased to see that you’ve taken this as far as you have. 

As noted, one of the major issues that keeps KAL computing from being really useful is the lack of sensors (other than KAL destruction).

Well, I had an exceptionally stupid notion: The Making History Mission Editor has triggers for various flight events and parameters. It can also activate action groups and staging… That gets you 11 responses to “sensor” data. Now, if I understand the power of what you’ve got here, you could treat those action groups as a bit field, and activate 2^10 ish possible other KALs. (x sensor condition activates bits 2 and 5, bits 2 AND 5 activate KAL34)

There’s some decent potential for fully automated, fully stock mission execution (with a boatload of hard work, caveats and exceptions).

I checked the manual, just to see if I’d remembered the features correctly:

https://wiki.kerbalspaceprogram.com/wiki/Mission_Builder_Manual