zengei

Is there a way to bring up the UI manually? I had to edit a .version file so I could see the UI and make sure it was working.

Alternatively use Research Them All to automatically unlock them. The mechanics of this might change in 0.24 with funds now though.

Excellent, will have to check this out on my next restart.

Are you using RPM 0.17? I don't think this is yet compatible with it.

I really like this idea. In fact, I came here to post this after watching Scott Manley's Interstellar Quest Episode 10, where he basically .It would encourage reusing existing designs and testing new designs before using them "for real".

Works fine for me with RPM 0.16. Do you have the KSI MFD?

Yeah, I think I've noticed that too, good to know I'm not going crazy. Besides that, another couple of minor issues I've noticed while practicing with this: The heading as reported by the navball and the heading reported by the HSI can differ by up to 1º. I'm assuming this is due to rounding differences. If the HSI window is open and you reload from a save, the HSI window will no longer be open but the UI button will report "Close". Clicking the Close button and then Open brings the window back. But still, excellent work. One thing I've learned is that I've been greatly misjudging my approaches, when I think I'm lined up I'm not actually. At one point I thought the HSI was wrong, but I learned that it was not. Have to learn to trust my instruments.

Need to practice some more but just made by first reasonably well executed landing, excellent work! It says so in the dependencies list:

Nevermind, found it on your GitHub. C# nice, I'll probably fork and play around with it.

Cool, a standardized package format wouldn't be too difficult. Basically a zip file with folders rooted at the KSP directory (i.e. how most mods are distributed anyway) plus a metadata file. I'm a big fan of the simplicity and power of Arch Linux's package format expressed in PKGBUILD files. Being able to express (hard and soft) dependency and conflict relationships between packages would be a big boon for user friendliness. Also being able to express more complex relationships like provides or replaces would help forks and continuations. When I looked into this a while ago there was even an effort to use pacman directly. Unfortunately that level of robustness is a lot of effort (Linux package managers have years and years of development from multiple contributors), but it's relatively straight forward to add over time. A KSP package manager would also have the advantage that the packager would also likely be the creator, which reduces the need to e.g. be able to build from source and support exotic installation procedures. What language is that example written in? I'm assuming Python like the rest of Kerbal Stuff?

Very nice! I look forward to trying this.

Yes, indeed.

If you really want to know... The tetris code can be found here. First you need to assemble it into machine code using a DCPU-16 assembler, like Organic. Then you need to place the outputted bin file in Kerbal Space Program/saves/<profile>/Ketchup/FloppyDisks. Tetris is a relatively large program, so it doesn't fit in the first sector of the floppy disk that the default firmware reads from disk on boot. So you'll have to get an alternate firmware that can read more data from disk. I've provided such a firmware under the Contrib folder of the relase download, in the source assembly file named firmware_127sectors_v1.dasm. You can assemble that into machine code using Organic, or other assembler as well. Place that outputted bin file in Kerbal Space Program/saves/<profile>/Ketchup/Firmware. From in-game, right click on the computer part, and toggle the firmware window open. Flash it with the alternate firmware. Then toggle the interfaces for the computer, keyboard, LEM-1802 (monitor), and M35FD (floppy drive). Use the get disk option from the floppy drive window, to select the tetris image, then insert it into the drive. Power on the computer, after the few seconds it takes to read the floppy disk, the tetris flash screen should appear, and then you can click the attach button on the keyboard window to start playing. For your and anyone else's convenience, here are some links to pre-assembled versions of the firmware and tetris game, removing the need to use organic or another assembler: firmware_127sectors_v1.bin tetris.bin

Version 0.6.0 released: https://github.com/dbent/Ketchup/releases/tag/v0.6.0 Now has an implementation of the SPED-3 device, so now all stock devices have been implemented except for sleep chamber device, which doesn't really have any utility. Next release will probably be some bug fixes and code cleanup.

Thanks, looks like there isn't an elegant way to do what I want, will probably try a different approach.

Thanks, checkout my earlier post, with some links to already proposed specs (that I still have yet to get to). I've also listed some possible external devices in this issue. If you want to get a discussion going on a specific device, feel free to start a new issue in the KSP_DCPU16_Standards repository, so we can brainstorm ideas. Eventually, I'd like to see specifications like those on http://dcpu16.com/ but also including psuedo-code on how to interact with the device.

How can I force KSPEvent buttons to always be available when right-clicking on a part? It seems they're automatically hidden if a part has no ElectricCharge available.

Version 0.5.0 released: https://github.com/dbent/Ketchup/releases/tag/v0.5.0 Checkout the release notes for more information. And the updated README.

Ha, thanks. Probably the biggest thing to do right now is to arrive at a community consensus on Kerbal-specific devices that allow the DCPU-16 to interact with the ship. There are some proposed specifications, that I've been negligent in reviewing myself, since I've been focusing on getting the core stuff "feature complete". There are also some open issues on GitHub if you want to contribute to the main work. One other thing is that the upcoming release will implement the M35FD floppy drive spec and get rid of the ability to "flash" the main memory. Instead, I'm implementing this proposal, which will automatically load the first sector (512 words) from the first floppy drive it finds into main memory and execute it. This would allow you to treat memory images as floppy disks so long as they are <=512 words, otherwise we'll need some sort of bootable floppy disk standard, and tools to generate floppy disk images from the memory images spat out by the assemblers.

Released 0.4.1, which includes a workaround for a bug in saving and restoring values in the game's save files. I'll release 0.5.0 this weekend, which will include implementations of the M35FD floppy drive and a community proposed firmware/BIOS.

Yep, done.

Ahh, that seems rather obvious in retrospect, thanks. I guess I'll 'escape', forward slashes with another character then, thanks.

Has anyone noticed that if a ConfigNode value is written with two forward-slashes in a row, then the value that is read back is truncated? For example if you write the following value: hello//world, then when you read it back it's read as hello. As far as I can tell this only occurs with two forward slashes in a row, any number of single forward slashes is fine, i.e. h/e/l/l/o/w/o/r/l/d is read back correctly. Is this a known bug? Possibly some sort of expected behavior? I only noticed this because I was saving Base64 encoded values, in which // can occur readily.

Missed a release last week but 0.4.0 is available which brings state saving/loading and interfaces for external devices.

Seems likely. Most physics data appears to be single-precision floats in KSP.