dnbattley

Without wishing to flex too hard on this thread, I have managed to find a number of good uses for KALs, particularly since the final update when they fixed some irksome bugs that prevented it reaching its true potential: Given the number of videos, I've spoilered them to keep this post in check, and sub-divided into categories 1. Robots! 2. Logic Gates 3. The Piece of Resistance: Meta KSP

My confession is that, since the time I discovered how to use docking port/landing wheel/KAL overclocking Kraken drives, 99% of my missions now take place in and around the KSC.

This is an interesting challenge, but removing the ability to use electricity undoubtedly and exponentially ramps up the difficulty level...

Some people may have already seen this on Reddit: a meta game of KSP I recently created entirely within KSP using KALs, as the logical next step from creating a working binary calculator... Here is a new video showcasing this creation in more detail, together with a blow-by-blow overview of the KAL logic which amounts to a very detailed KAL tutorial... Enjoy!

Being very slow on the uptake, I have only just read this dev diary, but my immediate thought was "why not just simplify/elongate the hit box?": I mean, if an object is travelling at warp 1, the hit box is effectively just a really long cylinder with (if you want to be really flash) the cross sectional area of the object from the perspective of its vector of travel, which you can then over-extend for huge distances in front of and behind the vessel. Only as you slow down or get within a reasonable physics range would this hit box cylinder need to be refined by being compressed and (depending on the speed) interpolated back into the actual 3D shape of the object. Taking this approach you would then approximate any vessel as an exaggeratedly long cylinder, only looking at the intersection with other craft periodically (this periodicity would in part determine the extent to which you exaggerate this hitbox size and so could be tailored to the machine speed). On the detection of a cylinder collision you could then choose to either refine the calculation (i.e. based on local coordinates and using a more refined collision shape is it still a collision for the vessel?) and/or simply teleport the colliding vessel(s) to the point of intersect as determined by the detected overlap and proceed with the explosion calculations from there.

So just to add to (and in doing so resurrect) this somewhat old thread, and point out that I have finally managed to demonstrate Turing-like behaviour in the original KSP (as part of a recent forum challenge) through which it is possible to generate both logic gates and even a binary adding device. While these creations can controlled via action groups and/or KAL priorities in the context menu, there is no way (to my knowledge at least) to create a link between a kerbal's "physical" space which they can interact with back to this "virtual" environment in which calculation can occur, underlining the (to my mind) importance of having some sort of "interactive" part which act as a switch, and then allow us to take the next step up in functionality...

@TriggerAu: this one's for you ☝️!

I've had a busy, but productive weekend, and proudly present:

My logic board craft file is now posted here: https://kerbalx.com/dnbattley/Logic-test-3

Well... I think it's fair to say that I had a good evening:

Oh my! I've been thinking about this for a while now and have some ideas using the KAL approach, and this is all the motivation I need to dust off that prior work and contribute to this. What are the outcomes we need to achieve to fully realise this: if we can generate and link AND, OR and NOT gates is that enough?

Inspired by a conversation on the Reddit, I thought it would be helpful to share my comment here to open up the debate to community members of this forum. The thread was started by Tom Vinita and was about part modules. Here was my comment from there: A discussion of part modules should, for me, include discussion about permitting interaction. Specifically I would like to see: * All scientific parts having a "monitor" function to allow a KAL logic tests of their particular function to be "armed": e.g. if temperature > value then...; if pressure > value then... etc. This would allow interesting functionality beyond simple parachute deployment on re-entry. * Lights or solar panels having a secondary function of "report value" of light shining in them, which could result in e.g. doors which open when a torch is shone on them; solar panel mounts (not just the panels themselves) which can be made to orient toward (or away from) the sun. * Wheels or landing legs which can be used to "weigh" objects. What do community members here think? Is there a wider debate to be had on space engineer / Minecraft like functionality regarding part interaction? Or is that an unnecessary distraction for a team already under the kosh trying to build a project under too much time pressure...

A month or so later, thanks to the time it takes to ship around the world: Woohoo! Thanks KSP Team!

Created for the challenge forum Asteroid Day Challenge, I'm quite proud of this little movie: https://youtu.be/xc1OwkGgW8Y

My humble submission, created for this challenge. Edited to add: the explanation behind this mission is a blink-and-you'll-miss-it moment in the video, but the description in YouTube is more informative. The principle seeks to find a "resonant" magnetic frequency for the loosely bound ferrous core of an asteroid whereby flipping the field rapidly can create localised distortions that in turn will generate internal pressures that will cause the asteroid to crack along fault lines. In my head canon, this is enough to break the asteroid apart on its own, but a secondary objective may be to open up a fissure down which explosive charges could be placed.