Minecraft Flying Machine CA

[NoAyeBeardo]

I can't think of any easy way to make directional pistons, other than have four different states.
Some things to add to udirmcslime:
Honey (sticks to anything except slime)
Obsidian (unmovable)
Observers (directional)

Can cells have two colors to show direction on them, e.g.:

[Schiaparelliorbust]

Honey blocks sound good. So do observers and obsidian. But we need to figure out what directions to make it in. Adding another direction will add many other states, but it still seems to be way under the the 256 states that is the maximum for Golly. I think we should make a sort of additive counting system for the block push limit (the current system is buggy): basically a counter state leaves the piston and branches off when there is a branch, all the while counting up by 1 each time it passes a block, and when it's at a dead end it changes direction and when it reaches a branch the two or more numbers merge. If it ever goes above 12, it will come back to the piston telling it to not move. I don't know how the piston should know when to fire though (i.e. how will the piston wait for the presence or absence of a "don't move signal"?).

[HelicopterCat3]

Ah, so the idea is to have 4 directional "piston" states, a movable object state, and immovable object state, a sticky 1 state (slime blocks), a sticky 2 state (honey blocks), and a power source state to trigger the piston states to extend and push the movable states and pull movable states with the sticky states. Oh and BUD update stuff to to make most of these slimeblock machines work.


Definitely easier said than done...

I suppose we could utilize how some JvN29 states work for the piston states, but other than that, we definitely can't use the permute symmetry in the rule table
Edit: There are some great examples of this rule already on here, but I think it can be optimized, somehow

[Schiaparelliorbust]

Ah, so the idea is to have 4 directional "piston" states, a movable object state, and immovable object state, a sticky 1 state (slime blocks), a sticky 2 state (honey blocks), and a power source state to trigger the piston states to extend and push the movable states and pull movable states with the sticky states. Oh and BUD update stuff to to make most of these slimeblock machines work.


Definitely easier said than done...

I suppose we could utilize how some JvN29 states work for the piston states, but other than that, we definitely can't use the permute symmetry in the rule table
Edit: There are some great examples of this rule already on here, but I think it can be optimized, somehow

What do you think of my above idea?

[HelicopterCat3]

Ah, so the idea is to have 4 directional "piston" states, a movable object state, and immovable object state, a sticky 1 state (slime blocks), a sticky 2 state (honey blocks), and a power source state to trigger the piston states to extend and push the movable states and pull movable states with the sticky states. Oh and BUD update stuff to to make most of these slimeblock machines work.


Definitely easier said than done...

I suppose we could utilize how some JvN29 states work for the piston states, but other than that, we definitely can't use the permute symmetry in the rule table
Edit: There are some great examples of this rule already on here, but I think it can be optimized, somehow

What do you think of my above idea?

Hmm, so a state is created from a piston (non-directional) to check the amount of total movable objects by increasing a variable each time it passes a block and then if that variable goes past twelve the piston doesn't fire? Seems like it could interfere with the movement of other states, but it sounds like it could work. It seems iffy to me cause it seems like the piston state would have to read more data to function, while yes directional pistons would require more states, it would be more optimal

[Schiaparelliorbust]

Hmm, so a state is created from a piston (non-directional) to check the amount of total movable objects by increasing a variable each time it passes a block and then if that variable goes past twelve the piston doesn't fire? Seems like it could interfere with the movement of other states, but it sounds like it could work. It seems iffy to me cause it seems like the piston state would have to read more data to function, while yes directional pistons would require more states, it would be more optimal

The hardest part is what would happen if two counters interact? I wonder if the Minecraft wiki has anything to offer on this.

[HelicopterCat3]

Hmm, so a state is created from a piston (non-directional) to check the amount of total movable objects by increasing a variable each time it passes a block and then if that variable goes past twelve the piston doesn't fire? Seems like it could interfere with the movement of other states, but it sounds like it could work. It seems iffy to me cause it seems like the piston state would have to read more data to function, while yes directional pistons would require more states, it would be more optimal

The hardest part is what would happen if two counters interact? I wonder if the Minecraft wiki has anything to offer on this.

This CA is definitely more complicated than it seems. Another thing with these counter states would be not only colliding with other cell or each other, but them running along the correct direction and not along all adjacent slimeblocks. I peer into Minecraft's code sometimes for funsies and this stuff happening on a 2d plane is actually more complicated than it occurring in 3d. It's hard to explain, but pistons in Minecraft just know what they're pushing. These counting states could absolutely work, but the ramifications would just continue to pile up...

[Schiaparelliorbust]

This CA is definitely more complicated than it seems. Another thing with these counter states would be not only colliding with other cell or each other, but them running along the correct direction and not along all adjacent slimeblocks. I peer into Minecraft's code sometimes for funsies and this stuff happening on a 2d plane is actually more complicated than it occurring in 3d. It's hard to explain, but pistons in Minecraft just know what they're pushing. These counting states could absolutely work, but the ramifications would just continue to pile up...

More complex in 2d than 3d? Wow. Perhaps we can make a test version with only 1 piston/cluster of blocks moved. We can try out the counter states like that? How does the Minecraft code do it? Is it too complex to explain here?

[HelicopterCat3]

This CA is definitely more complicated than it seems. Another thing with these counter states would be not only colliding with other cell or each other, but them running along the correct direction and not along all adjacent slimeblocks. I peer into Minecraft's code sometimes for funsies and this stuff happening on a 2d plane is actually more complicated than it occurring in 3d. It's hard to explain, but pistons in Minecraft just know what they're pushing. These counting states could absolutely work, but the ramifications would just continue to pile up...

More complex in 2d than 3d? Wow. Perhaps we can make a test version with only 1 piston/cluster of blocks moved. We can try out the counter states like that? How does the Minecraft code do it? Is it too complex to explain here?

Well, yes and no, to understand, one would first have to know that there categories of physical objects and events in Minecraft, there are entities, blocks, block-entities, sounds, and particles. Block-entities are just blocks that store data like chests or dispensers. What the game does is when blocks are near a piston, it first determines their properties like movability, and then temporarily turns them into block entities that detect each other and then "send" that data to the piston to determine if it actually pushes it. This is why it takes a couple frames for pistons to push since they can't push block-entities. This is the short version of it, and pistons are actually less complicated than this in the code, because of basic JavaScript functions that simplify it.

[Schiaparelliorbust]

Well, yes and no, to understand, one would first have to know that there categories of physical objects and events in Minecraft, there are entities, blocks, block-entities, sounds, and particles. Block-entities are just blocks that store data like chests or dispensers. What the game does is when blocks are near a piston, it first determines their properties like movability, and then temporarily turns them into block entities that detect each other and then "send" that data to the piston to determine if it actually pushes it. This is why it takes a couple frames for pistons to push since they can't push block-entities. This is the short version of it, and pistons are actually less complicated than this in the code, because of basic JavaScript functions that simplify it.

Well do counter states have any problems other than interacting with each other? You said they might go in the wring directions and stuff. How does Minecraft implement the push limit?

[HelicopterCat3]

Well, yes and no, to understand, one would first have to know that there categories of physical objects and events in Minecraft, there are entities, blocks, block-entities, sounds, and particles. Block-entities are just blocks that store data like chests or dispensers. What the game does is when blocks are near a piston, it first determines their properties like movability, and then temporarily turns them into block entities that detect each other and then "send" that data to the piston to determine if it actually pushes it. This is why it takes a couple frames for pistons to push since they can't push block-entities. This is the short version of it, and pistons are actually less complicated than this in the code, because of basic JavaScript functions that simplify it.

Well do counter states have any problems other than interacting with each other? You said they might go in the wring directions and stuff. How does Minecraft implement the push limit?

I forgot the exact way the push limit works, but I can't look at it right now because my phone is committing terminal stupid along with my laptop, and assuming your counter states works the way I think it does, when a piston is touched by a redstone block, it fires and sends the counter state along all adjacent slimeblocks since it doesn't know the specific direction to send them in excepts for where the redstone block is. I'm assuming that's what would happen, but there might be an easy fix I'm not realizing because of my ADHD...

[Schiaparelliorbust]

I forgot the exact way the push limit works, but I can't look at it right now because my phone is committing terminal stupid along with my laptop, and assuming your counter states works the way I think it does, when a piston is touched by a redstone block, it fires and sends the counter state along all adjacent slimeblocks since it doesn't know the specific direction to send them in excepts for where the redstone block is. I'm assuming that's what would happen, but there might be an easy fix I'm not realizing because of my ADHD...

Well the counter state branches off, but it might have trouble when there is a square of blocks. It might miscount. If we do have a counting state, we need to make sure it works with any possible starting configuration.

[HelicopterCat3]

I forgot the exact way the push limit works, but I can't look at it right now because my phone is committing terminal stupid along with my laptop, and assuming your counter states works the way I think it does, when a piston is touched by a redstone block, it fires and sends the counter state along all adjacent slimeblocks since it doesn't know the specific direction to send them in excepts for where the redstone block is. I'm assuming that's what would happen, but there might be an easy fix I'm not realizing because of my ADHD...

Well the counter state branches off, but it might have trouble when there is a square of blocks. It might miscount. If we do have a counting state, we need to make sure it works with any possible starting configuration.

I agree. Also, it might be best to do what the other proposed rules for this have done and make a piston head state so that the counter state is sent from where it pushes so that it doesn't act like said circuitry. We just need to work out the counter state and find out how to make the piston head state come into existence once more, in the right direction. Every problem has a solution, but then the solution becomes a problem.

Edit: The only solution I can think of is having 4 different directional piston states and each one transmits this piston head in the direction specified. So in total, here are all of the states:
4 Piston States
Piston Head
Slimeblock
Honey Block
Glazed Terracota
Movable Object (wood I guess)
Immovable Object (Obsidian)
Redstone Block
Observer
Counter

[Schiaparelliorbust]

I agree. Also, it might be best to do what the other proposed rules for this have done and make a piston head state so that the counter state is sent from where it pushes so that it doesn't act like said circuitry. We just need to work out the counter state and find out how to make the piston head state come into existence once more, in the right direction. Every problem has a solution, but then the solution becomes a problem.

Edit: The only solution I can think of is having 4 different directional piston states and each one transmits this piston head in the direction specified. So in total, here are all of the states:
4 Piston States
Piston Head
Slimeblock
Honey Block
Glazed Terracota
Movable Object (wood I guess)
Immovable Object (Obsidian)
Redstone Block
Observer
Counter

Counters won't be a block of their own. Thy will be in a block and can move through them glazed terracotta should be easy, it can only be pushed and and not pulled either directly or from slime/honey blocks. Counters should come out of the piston "body" when it's retracted.

[Moosey]

I agree. Also, it might be best to do what the other proposed rules for this have done and make a piston head state so that the counter state is sent from where it pushes so that it doesn't act like said circuitry. We just need to work out the counter state and find out how to make the piston head state come into existence once more, in the right direction. Every problem has a solution, but then the solution becomes a problem.

Edit: The only solution I can think of is having 4 different directional piston states and each one transmits this piston head in the direction specified. So in total, here are all of the states:
4 Piston States
Piston Head
Slimeblock
Honey Block
Glazed Terracota
Movable Object (wood I guess)
Immovable Object (Obsidian)
Redstone Block
Observer
Counter

Counters won't be a block of their own. Thy will be in a block and can move through them glazed terracotta should be easy, it can only be pushed and and not pulled either directly or from slime/honey blocks. Counters should come out of the piston "body" when it's retracted.

Warning: the following paragraph has a lot of wolfram alpha links.




spoiler alert: this won't work (as far as Golly cares) in the *best* case. By a lot. (that's eleven unique states, times 16 for timing movement-- range of 15 for pushes = fifteen timing states, plus a still state, times four for each direction). Even if you miraculously drop a whole lot of states, like several states (probably around seven base states) that would be necessary for observers, as I did, (and I also ignored the existence of obsidian entirely, which would require the addition of one state but obsidian would also completely break physics unless you want to add FAR more states so I'm just going to ignore it). If you are okay with cutting down the amount of timing states and drastically cutting range, I have bad news: you'll only be able to fit four timing states per base state & direction; only two if you want to be realistic about how expensive observers will be, statewise. You might want to consider trying some kind of generalized-to-arbitrary-two-dimensional-shapes version of the firing squad problem, because that might be able to give you a usable amount of space to put slime blocks and stuff to make spaceships. Particularly if you drop observers. And terracotta or wood. (I mean, this is all only if you want to have this rule work in Golly, which I'm assuming you do)

[Sarah]

This is probably the smallest flying machine I can think of

Code: Select all

x = 4, y = 4, rule = uDirMCSlime
.T$pQH.C$ApH.A$4A!

[the lifestroyer]

Can Someone tell Me Which State Is Which like which is the piston Etc

[Schiaparelliorbust]

Warning: the following paragraph has a lot of wolfram alpha links.




spoiler alert: this won't work (as far as Golly cares) in the *best* case. By a lot. (that's eleven unique states, times 16 for timing movement-- range of 15 for pushes = fifteen timing states, plus a still state, times four for each direction). Even if you miraculously drop a whole lot of states, like several states (probably around seven base states) that would be necessary for observers, as I did, (and I also ignored the existence of obsidian entirely, which would require the addition of one state but obsidian would also completely break physics unless you want to add FAR more states so I'm just going to ignore it). If you are okay with cutting down the amount of timing states and drastically cutting range, I have bad news: you'll only be able to fit four timing states per base state & direction; only two if you want to be realistic about how expensive observers will be, statewise. You might want to consider trying some kind of generalized-to-arbitrary-two-dimensional-shapes version of the firing squad problem, because that might be able to give you a usable amount of space to put slime blocks and stuff to make spaceships. Particularly if you drop observers. And terracotta or wood. (I mean, this is all only if you want to have this rule work in Golly, which I'm assuming you do)

Then we can drop observers, obsidian and terracotta. Maybe honey blocks too. I still want to be able to have the push limit. Do you think we can have regular pushable blocks? And most of your links lead to simple calculations. Why is that?

[Hunting]

And most of your links lead to simple calculations. Why is that?

...the simple calculations are "the number of states needed with this proposal".

[Schiaparelliorbust]

...the simple calculations are "the number of states needed with this proposal".

Thanks for clarifying. Do you have any ideas? Especially for resolving problems with the counter states. Also, please look at the language thread.