KSP computer dev team

[dharak1]

If you need an editor camtasia is great, it costs 200 bucks though so pretty pricey but worth it imo.

[3_bit]

Didn't even notice you guys posted until now. Action groups CAN toggle lights, but you can't do pseudo-logic to the extent I can with my system.

[Fel]

I see

You're creating a... Newtonian... Action - Reaction system in which the system resembles logical gates.

[CaptinKornflake]

This sounds so cool, I know some basic logic gates and I am currently constructing a tesla coil with some friends so I may be of assistance.

[Scoundrel]

Well, I edit my let's play videos with it, and it is not bad for SIMPLE editing. As soon as I go a little bit deep on video editing, I switch to Sony Vegas Pro 11. I've heard only good things about Premiere, although I've never tested it (but I really want to).

I'm an old VFS grad and I can say that premiere is meh. Final cut pro is better if you can get your mits on it. Way less annoying to use. Grass Valley's Edius is probably my second fave to work with if you're PC minded, and is pretty intuitive. Makes wicked youtube videos. If you guys need editing help, let me know, I'd be happy to give you guys a hand.

That said, I love the idea of what you guys are doing. I can't wait to see it in action.

[3_bit]

I'm used to Premiere, however, and I know it's features. All that aside, I hope Squad makes more... advanced action group systems. The second they do I'll make a more elaborate system. Until then, I have drafted a basic computer-like system, accounting for game limitations. This is .19, so by the day 1.0 comes out I can almost guarantee a more lifelike system will exist.

[3_bit]

Update on the machine:

Regarding how it works, a certain Manley has expressed interest in showcasing my latest design.

I'm working on making a more fluid UI so that people that aren't as retro computer-saavy can use the system (OK, I'm really just duplicating the interface of most Binary in/out minicomputers and labelling it better) Here's a bit on that:

I think I can have my 4-program machine, Processor and all, ready to go before July 5th *cough* *cough*

It will be a great improvement, provided you have a gaming rig. If there's enough interest I might even make a version of my 1-bit adder (full version above) for the demo version (I've explored the options and it can be done, it would just be a bit tedious to make)

[3_bit]

I've been getting a lot more free time on my hands lately so I might even make a full Youtube channel over the summer. More info on that later, if interest is expressed.

[3_bit]

I just finished working in the "processor" part of the device. Well, it actually will take in modules so that the end user can customize them, whether it be an adder or a storage system, I do not know It will be modular and should be easy to develop for as it has a lot of space for logic gates. So far I have designs that have been tested for XOR, AND, NAND, and NOT gates, with some limitations. I do have some longer-term plans to make write-protectable memory, my current units are just essentially switches, and with action groups at a premium there will be a demand. The biggest problem I foresee (memory is only being planned now) is the physics engine ruining everything. My latest version relies on the unit to hit a blockade and go straight back where it came from, and with an impatient user things could end badly for the whole memory array.

Edited May 29, 2013 by 3_bit

[Brabbit1987]

So this seems interesting as I used to mess around with minecraft's red stone system. However, I do have to ask, what is your goal and the point of doing this in KSP? Will it actually have any conventional use? I am legitimately asking, cause I am curious and I don't know.

[AlexL]

However, I do have to ask, what is your goal and the point of doing this in KSP? Will it actually have any conventional use?

For the everyday rocket launcher this is really of no use, but its still really neat (to those so inclined).

3_bit, consider my interest in this project expressed. If I can help out, I will.

[AlexL]

Exams finished today, so I've put a bit of time into trying something for this.

I'm trying to use the helicopter rotor technique developed a while back in order to make a system that doesn't rely on parts falling into ports (had some docking issues with the current design).

https://dl.dropboxusercontent.com/u/55708440/KSP%20computer/v1/Mechanical%20relay.craft

My current prototype can connect it's docking ports, but the fuel doesn't like flowing through the new self-connection, or something, not too sure.

It also goes funny if you quicksave/load when docked.

If you have any tips, or have already tried this route and found it a dead end, do let me know.

[3_bit]

I haven't tried that. Kudos for a new idea, my design doesn't rely on it "Falling" in. I use mine in space: I can take advantage of the (in this case, literally) free movement given to vessels when they undock. This propels it into the other port. I use this tactic to emulate a switch, and embedding a switch inside another gives you an AND gate, if you set it up right. If you add me on Steam I may be of assistance-- my name is obvious. It's great to see others (finally) working on their own machines. Feel free to download my .craft for my latest iteration of the 1-bit adder. It's a bit complex to explain, but as I said, Mr. Manley expressed interest in featuring it a few days ago. Actually, I'll just copy my PM about operation into the OP.

[AlexL]

Hmm, why did it not occur to me that a binary adder, built in a space game, with rocket engines on the bottom, was intended for use in space? Your design makes much more sense to me now.

[Tangent]

I dont know if it will help, but this is pretty interesting.

http://www.neuroproductions.be/logic-lab/index.php?id=52

[Piggius_Max]

Egh... There really isn't any need for this; I mean fine do it if you really want but if you want to make programs go and learn/write code. Minecraft has redstone for the purpose of contraptions, we have toggleable action groups for more intricate control of ships. The computer side of this really doesn't make any sense to me, perhaps the 3D responses you get to inputs are more satisfying but I don't think this is a good idea

[3_bit]

Exams finished today, so I've put a bit of time into trying something for this.

I'm trying to use the helicopter rotor technique developed a while back in order to make a system that doesn't rely on parts falling into ports (had some docking issues with the current design).

My current prototype can connect it's docking ports, but the fuel doesn't like flowing through the new self-connection, or something, not too sure.

It also goes funny if you quicksave/load when docked.

If you have any tips, or have already tried this route and found it a dead end, do let me know.

Now that I think about it, while I think this design is impractical, do continue, but while I disprove of the fuel-requiring turn system, do attach tanks radially to the rotor. When/if you undock the rotor the fuel lines would be lost. I suggest using the small 1.25 meter tank in the center, fuel lines running to each docking port, as the new girders/plates have no fuel crossfeed, which is a good thing for making control logic without using tons of decouplers. I did at one time test using ANT engines to propel the system, but these require active toggling, as well as making any complex 2-way gates impossible. They do have other uses, however, such as locking bits: properly aligned engines could keep a tank from having it's state toggled as the exhaust from and ANT could push it back where it came from regardless of it's original location. The limitation of this is that undocking anything results in throttle on both parts being cut, thus it wouldn't function unless the end-user maintained full throttle at all times, but this would only complicate matters in operation as well as the other moving parts.

[Brabbit1987]

Egh... There really isn't any need for this; I mean fine do it if you really want but if you want to make programs go and learn/write code. Minecraft has redstone for the purpose of contraptions, we have toggleable action groups for more intricate control of ships. The computer side of this really doesn't make any sense to me, perhaps the 3D responses you get to inputs are more satisfying but I don't think this is a good idea

Well while I do agree that I don't see a point in doing all this, I am going to say let them do what they want. If they find it fun, who are we to say other wise. My guess is it will not last long, since it's kinda like using a spatula to hammer in a nail. AKA using a tool for something it was not meant to be used as.

[3_bit]

But the thing is it's an original application of action groups. It can be expanded massively, and if only Squad were to add toggling of fuel crossfeed in action groups, I could make machines that didn't abuse physics and were far faster, smaller, and more reliable. The current generation has physics and timing problems I have to deal with.

[Mekan1k]

Just... Wow.

[3_bit]

Many thanks to Scott Manley for featuring this!

[DiEvAl]

I was trying to find a way to make a logic gate that has inputs in the same format as outputs (and not just inputs as action groups, outputs as fuel lines).

I have an idea that might work, but I don't have time to try it myself. You can try to build it yourself it if you want.

Here is a quick sketch: http://i.imgur.com/t0be6KN.png

Black lines don't crossfeed fuel, green ones do. Red is an upwards pointing engine. Blue are docking ports. The circle is a roughly spherical object that can be propelled with engine exhaust (e.g. a kerbal). The piston in the middle can move freely up and down and dovk to the docking ports. It operates in low gravity such as on Minmus. It has 5 places to connect fuel lines: A1, A2, B1, B2 and C.

When piston is docked to the top docking ports, A1 and A2 are connected, and when it's docked to bottom ports, B1 and B2 are connected.

When not in use, piston is docked to either of docking port pairs. You press an action group that undocks all docking ports and activates the engine.

Now there are 4 cases.

a) Piston is on the top, C is off. Engine doesn't fire. Piston just falls down and docks to the bottom docking ports.

Piston is on the bottom, C is off. Engine doesn't fire. Pistons jumps up a bit, out of docking port reach, and docks back.

c) Piston is on the top, C is on. Kerbal flies up, hits the falling piston and makes it go back up.

d) Piston is on the bottom, C is on. Kerbal flies up, pushes the piston up, and makes it dock with top docking ports.

After this piston is on the top if and only if C was on when we pressed the action group. So basically we have a D-flip-flop in which input, output and inverted output are a fuel lines, and clock is an action group.

Note: If you have two of these set to the same action group, you can't directly connect on of the outputs of one of them to input of the other.

Now imagine you have an unlimited source of fuel and 2 infinite (in both directions) sequences of these D-flip-flops. You have action groups set up like this:

1 = undock all docking ports in first sequence and fire all engines in first sequence.

2 = turn off all engines in first sequence

3 = undock all docking ports in first sequence and fire all engines in second sequence.

4 = turn off all engines in second sequence

Conjecture: For every turing machine you can connect them and set their initial states in such a way that:

1) You can remove a finite number of fuel lines and add a finite number of fuel lines to make fuel lines periodic.

2) You can switch initial states of finite number of D-flip-flops to make states periodic.

3) If you activate action groups in order 123412341234... it'll emulate that turing machine.

I believe it's true, but haven't proved it yet.

EDIT: it might be possible to use whack-a-kerbal balls instead of kerbals.

Edited June 6, 2013 by DiEvAl

[3_bit]

I must commend you for the amazing detail in your post, but I see 3 problems: the Kerbal, the docking ports, and the engine.

The Kerbal: they're prone to falling over and really aren't needed here.

The engine: my current adder which Scott Manley showcased a few days ago didn't need any to control the logic, only outputs. This is because undocking anything propels the object being undocked ever so slightly. Also, undocking your piston (or anything else for that matter) would result in throttle automatically being set to 0 by the game itself.

The docking ports: my system uses a narrow rod with 4 docking ports on all gates except for the fuel in the center gate, which has one on each end. They have one on the outer top and bottom, and one on the inner top and bottom. This allows for simple universal drag-and-dropping of gates, provided the gate you're dropping it into can hold it. While your gate would work in theory, I think it would be too unreliable, as KSP's engine isn't too keen on docking multiple ports at once. I can't find a video right now, but I have seen a few problems with multiple ports docking at the same time that are linked structurally, something my designs are immune to. This may not be a problem with a controlled environment, but I personally wouldn't use it unless I can test it a lot first.

The bottom line: I'll definitely test a version of this without the engine/ Kerbal that would rely on undocking propulsion, but I did find that my 1-bit adder is more than functional on Gilly, but I could not say such would apply to my larger designs that I'm working on, which have the logic tubes (official name not decided yet) parallel to the ground if you had the output pointed up. I will definitely test this and get back to you, but I'm leaving for vacation tomorrow and won't be back until next week Sunday. I can't guarantee any Internet access, but if I do I'll let you know. This system could greatly simplify many of my designs if it works as you say it might.

[DiEvAl]

The point of the engine was to allow you to disable it with something other than action groups: by cutting fuel flow. I don't think you can do that with just docking ports.

[3_bit]

You'd still have to deal with the problem of throttling up the engine quickly after undocking, something I wouldn't want to make the end consumer do. In all honesty though, I am quite inspired by the concept as it could bring down ship size massively, at the cost of a few extra parts.