dnbattley

It's not necessary to use such ways to modify the force as you can create continuous, variable force by an antagonistic arrangement of two docking port drives, each using an airlock, with an offset to their extension creating an imbalance of force (which is mapped to the throttle). I have a craft in KerbalX which demonstrates this: https://kerbalx.com/dnbattley/Space-Arrow-CVK-Jet-Mk-1

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.

<edit> I misread your initial suggestion. I agree with this and would suggest the following scoring: 1. an initial reading (screenshot) be submitted at the chosen point of descent (i.e. when pE is ~0m) using the stock dV calculator showing TWR and burn time 2. a screenshot be required immediately prior to and after jettisoning each stage, demonstrating i) full use of prior stage fuel and max TWR of the prior stage and ii) max burn time of the following stage 3. scoring is defined as: SUM ((1-maxTWRstage) x net burn timestage) i.e. a 3 stage lander which operates at (0.5x rising to 0.7x) TWR for 100s, (0.6x rising to 0.9x) for 30s, then (1.0x rising to 1.3x at landing) for 95s would score 0.3x100 + 0.1*30 -0.3x95 = 30+3-28.5 = +4.5

I may have to review my official Jool 5 submission lander for this challenge, as (for mission design reasons) I recall it had an abysmal TWR that started at 0.9x, and only struggled up to something like a respectable 1.5x by the time it landed...

It was on an old version, given this video is 3 years old, but: https://youtu.be/QXst9xp9GJY

"Well what about the KAL negative thrust/drain valve infinite fuel exploit? Huh?! Another loophole Dr. Kerbal!!!"

While I largely agree, the memory leak issue (as a specific example) has varied over time, but by my estimation at least is worse in 1.11.x when working in the VAB/SPH for significant time than I remember it at any point since at least 1.4...

On a lighter note, I will be very disappointed if this update isn't called 1.12: All your base (are belong to us)...

While true, there are some frustratingly persistent bugs around KAL's that I would personally like to see acknowledged, let alone addressed: KSP has the ability to be Turing complete if they did...

Nah mate, it's just the TCP button.

I'm surprised I've never come across this bug. Are the robotic parts attached radially or to nodes? The latter is obviously always stronger. Regarding this there is already a stock "solution" involving a Kraken drive applying constant downward force. This can also help with walking robots, responding to an earlier post - or even used for more extreme effects: