Incomplete analysis of MCBE redstone system operation (4) Piston
//Some part of the docs are poorly translated or even not translated, this will take time to edit and fix.
The piston is an extremely important original in the Redstone circuit system of Minecraft. Its basic function is to push a block (or entity) in a specific direction when activated by a Redstone signal. This column provides a simple summary of the piston features of the Bedrock Edition by gt testing, decompiling code, viewing memory data through special means, and communicating with experienced Redstone players (line).
In this column, you can see answers to the following questions:
-
What is the extend and retract time of the BE piston?
-
Why BE's piston is slower?
-
Does CD even exist? (what is CD?)
-
...
Please read the second one before reading this following one
- Incomplete analysis of MCBE redstone system operation (1)
- Incomplete analysis of MCBE redstone system operation (2)
- Incomplete analysis of MCBE redstone system operation (3)
and be sure to know a few things like
- Although all the content in this article is based on the two official versions 1.14.6 and 1.16.4, it has been established since the last time (a few years ago) the piston characteristics were changed, so it is also applicable to the new version.
- The time unit of timing analysis is gt instead of rt.
In the eyes of the player, the three stages of the piston are not extended, half extended, and fully extended are as follows:
In the game, the piston has only four states: retracted, partially extended, extended, and partially retracted. In the following, the four numbers 0, 1, 2, and 3 are used to represent these four states. As shown below:
Before talking about this issue, the first thing to be clear is that the internal part of the piston involved in the update has two parts: the consumer (Piston consumer) and the block entity (Piston block actor). The former is responsible for the update of the Redstone signal inside the piston, and the latter is responsible for the movement state of the piston (that is, the interaction with the world), which only occurs within the simulated distance.
And in the same 1gt, the block entity is always updated before the consumer. The following cpp pseudocode describes this update sequence:
bool isRedstoneTick = false;
void BlockActorTick(){} //Update Block Entity (Tile)
void RedstoneTick(){} //Information about consumer block
void LevelTick(){ //Game Update / World Schedule Update
isRedstoneTick = !isRedstoneTick;
BlockActorTick();
if(isRedstoneTick){
RedstoneTick();
}
}
int main() {
while(true){ //Main loop
LevelTick();
}
}Piston consumers are a type of consumer, and its update is explained in detail in the second part, so I won't repeat it here. The following focuses on the update of the piston block entity.
After omitting irrelevant parts (such as interacting with entities) and making appropriate simplifications, the update process is divided into the following two parts in turn:
-
Calculate the new state based on the current state and the strength of the Redstone signal
-
Update the interaction state with the world (and the block) according to the new state
The following is divided into two subsections to talk about these two steps separately:
The status update is mainly based on the following four rules (C represents the current state, N represents the new state, S represents the redstone signal strength, && represents AND):
Note: Some simplifications are made here for the convenience of understanding. The code judged in this part of mojang is too messy and there are no regulations. The following figure describes this state cycle very well.
However, please note that this is only the calculation of the new state and setting, no external behavior will be generated, so these changes will not be shown in the game for the time being.
This behavior will occur if and only if the current game is carved into redstone and the old and new states are different. The purpose of this step is to process the blocks attached to the piston according to the current different states. The behavior is shown in the following table:
Please see section 5 for details on how to convert between MB and square.
Having said so much theoretical analysis, let's do some timing analysis on the piston's pushing out and retracting.
The picture below shows the piston's launch process. Now let's make a simple explanation:
-
Suppose that the piston receives an activation signal on Redstone Carving 1.
-
At the time of Redstone Engraving 2, the piston detects that it has received a redstone signal, and the current installed state is 0, and the new state is calculated as 1, and the state of the update is general, and the attached block becomes MB
-
On the next non-redstone engraving, the piston will not do any checks and actions, the status is still 1, and the MB is still MB, but at this time the client has rendered the piston to a full 1 push state
-
On Redstone Carving 3, the piston checked again and found that it had received a redstone signal and its status was 1, so it calculated the new status as 2 and changed the MB back to a block.
This is a complete piston push process. Please note that this picture does not shift to the left or right by 1gt, because the actual state change must occur in the Redstone Carving. At this point, how would you define the launch time of the Pistons?
- How long does it take to go from state 0 to state 2?
- How long does state 1 last?
- How long does MB survive?
Everything makes sense. Therefore, the extending time of the piston will not be defined here. The same is true for cd, as long as your definition can describe this fact, you can define it anyway or take your time to Timings docs
The process of retracting is completely opposite to that of pushing out. The schematic diagram is shown below, so I won’t repeat it here.
The answer is not there. Because the piston in state 1 or state 3 will ignore the Redstone signal and become state 2 and 0 in the next Redstone engraving. If it is not designed like this, the piston of BE will appear instantaneous push and instantaneous animation (but the state change is still continuous), it is not easy to manage the conversion between Moving Block (MB) and Block.
The state of a block that has not been restored after being pushed is also a block. In the Java Edition, the id of the block is 36 but in the BE version, the block id is 250 and its name is Moving Block, and the following and above are abbreviated as MB.
Mojang specially reserved the position with id 36 when adding the block in the early version, but this position was not allocated to the MB in the end but was occupied by the element block 0 in the educational version.
There is nothing important about the conversion between the block and the MB, here is a brief mention.
-
This behavior is triggered when the piston turns from state 0 to state 1 and from state 2 to state 3. Check all the blocks attached to it that cannot be pushed (if wheat, etc.), first generate drops with a range of 1, which will not produce any fortune effects, and then remove the block;
-
For a block that can be pushed, first generate an MB in a new location, and then remove the block. The original block information will be stored inside the MB
There are some special treatments for flowing water, big boxes and other special blocks, so I won’t repeat them here.
This behavior is triggered when the piston turns from state 1 to state 2 and from state 3 to state 0. Generate a block at the new location, replacing the original MB
If the movement order of the blocks to which the piston is attached is not implemented, various pulls and data loss will occur. The piston maintains a list of blocks that need to be moved and sorts the blocks according to specific rules. The sorting needs to be based on a strict binary comparison rule, which is as follows:
For the attached squares A and B, first, calculate the position vector AB from A to B and then include the pushing direction P of the given piston. If the dot product (quantity product) of AB and P is greater than 0, that is, the two-phase vectors If the included angle is acute, then B will move before A, otherwise A will move first. Here is a simple schematic diagram: (This need to be retranslated due to google translate being dumb at translating logic)
BE's pistons are simple, clear and clear in every respect. In a word, every redstone carving updates its own state according to the redstone signal and processes the interaction with the world. Its own finite state machine is also surprisingly simple and easy to understand. The so-called launch time and withdrawal time have different results under different definitions. In the non-redstone carvings, the BE piston will not be updated or changed, except for animation, which is why the player feels that the BE piston extends and retracts very slowly.
In addition, under the blessing of random block update order and random block entity update order, there is no obvious priority among BE pistons. Under random conditions, all beings are equal.
slightly
- origin0110
- _hhhxiao
- Other players in the group
Source: MCBE红石系统运行不完全分析(4)——活塞