Mecánica de pistón

Quien soy
Valery Aloyants
@valeryaloyants
Autor y referencias

Hay 3 bloques importantes en la mecánica de los pistones. La base del pistón, la cabeza del pistón y el bloque 36

Contenido

  • 1 base de pistón
    • 1.1 Tras la actualización del bloque:
    • 1.2 Al recibir el evento Block:
    • 1.3 Bloques en movimiento:
  • Cabeza de 2 pistones
  • 3 Bloque 36 / Entidad de mosaico de pistón
  • 4 pistones sin cabeza
    • 4.1 Conseguir un pistón sin cabeza:
  • 5:
  • 6 Versión anterior de esta página:

Base de pistón

Tras la actualización del bloque:

Pistón en un estado defectuoso



Cuando la base de un pistón se actualiza, mientras está retraída y alimentada, o extendida, sin energía y capaz de empujar los bloques frente a ella, programará un evento de bloque. El evento de bloque tiene un ID de evento de bloque, que puede ser 1 o 0. Los eventos de bloque con un ID de 0 se denominarán a partir de ahora "Eventos de bloque de extensión". Los eventos de bloque con un id de 1 ahora se llamarán "Eventos de bloque de retracción". Si el pistón se actualizó mientras se retraía y se alimentaba, programará un evento de bloque de extensión. Si el pistón se actualizó mientras se extendía y no se alimentaba, programará un evento de bloqueo de retracción.

En 1.8, si el pistón estaba retraído y apagado, también se convertirá en un estado de falla. No se convertirá al estado de falla en 1.9.


Algunas personas consideran que, dado que 1.9 pistones ya no se convierten en estado de falla, es un error.


El pistón ahora esperará hasta que se procesen los blockEvents.

Debido al orden de actualización, los blockEvents se procesarán en el mismo o en el siguiente tick. Si el pistón se descarga antes de que se procesen los blockEvents, olvidará su actualización (esto es un error). Si el pistón estaba en un estado de falla, permanecerá en un estado de falla.

Al recibir el evento Block:

Una vez que se procesan los eventos de bloque, el pistón hará lo siguiente en los siguientes casos:

El pistón recibe un evento de bloque de extensión y no tiene alimentación:

Nada pasará.

El pistón recibe un evento de bloque de extensión y se alimenta:

El pistón volverá a probar si puede mover los bloques delante de él. Si puede, eliminará todos los bloques movidos y colocará un bloque 36 con blockId y blockData de los bloques movidos en la posición que obtiene al cambiar la posición del bloque movido en 1 en la dirección en la que mira el pistón (por más información, vaya a la sección "Mover bloques a continuación"). Además, la base del pistón retraída se convertirá en una base del pistón extendida.

El pistón recibe un evento de bloqueo de retracción y no tiene alimentación:

Si hay un bloque 36 directamente en frente del pistón (donde normalmente está la cabeza del pistón), entonces este bloque 36 caerá.


El pistón se reemplazará por sí mismo con un bloque 36 de un pistón retraído con la misma adherencia y dirección que el pistón inicial.

Si el pistón es normal, también eliminará el bloque frente a él.

Si el pistón está pegajoso, hará las siguientes 2 cosas:


Si el bloque 2 bloques frente a él se puede mover, creará un bloque 36 de ese bloque con la posición que obtiene al cambiar el bloque 1 en la dirección opuesta a la que mira el pistón pegajoso.

Si hay un bloque 36 dos bloques delante del pistón pegajoso, el bloque 36 mira en la misma dirección que el pistón pegajoso, y el bloque 36 resultó de una extensión, no de una retracción, entonces el bloque 36 será reemplazado por un bloque del blockID y el blockData del bloque 36.

El pistón recibe un evento de bloqueo de retracción y se alimenta:

Si el pistón estaba en un estado de pistón gltichy, volverá a su estado extendido normal. (Este comportamiento todavía está en el juego en 1.9, aunque en 1.9 no debería afectar ninguna situación que los desarrolladores hayan tenido la intención de que ocurra)

.

Imágenes potencialmente útiles, que no logré incluir por alguna razón:

(Tenga en cuenta que estas imágenes son precisas para 1.8, pero no completamente precisas para 1.9)

Extensión: http://imgur.com/4f40k5R

Retracción: http://imgur.com/SHsNVtt

Caída de bloques: http://imgur.com/7iuY727

Bloques en movimiento:

(TODO)


Cabeza de pistón

Si una cabeza de pistón se actualiza y no hay base de pistón en la posición de la que sale la cabeza de pistón, entonces la cabeza de pistón se reemplazará por aire.

Bloque 36 / Entidad de mosaico de pistón

El bloque 36 es el bloque creado cuando un pistón empuja un bloque. No es sólido, invisible y, extrañamente, no se alinea con la cuadrícula. Los bloques que son empujados por pistones no ocupan un bloque u otro, están en el medio. Por lo tanto, deben almacenarse como entidades de mosaico.


El bloque 36 en sí mismo normalmente no hace mucho. Por lo tanto, esta sección trata principalmente sobre la entidad Piston Tile.

La etiqueta de progreso aumentará en 0.5 cada vez que se procese el bloque 36 (lo que ocurre en la fase de entidad de mosaico de un tick). Si el progreso llega a 1, el bloque 36 se reemplazará a sí mismo con un bloque en el que el id será la etiqueta blockId del bloque 36 y los datos serán la etiqueta blockData del bloque 36. Esto sucede, después de que el bloque 36 se haya procesado dos veces. veces, o en otras palabras, después de dos tics de juego.

Pistones sin cabeza

Por lo general, hay una cabeza de pistón directamente en frente de cada base de pistón extendida. Sin embargo, existen métodos para

Pistón sin cabeza impulsado por un bloque de piedra roja.

obtenga una base de pistón extendida sin una cabeza de pistón directamente en frente de ella. Estas bases de pistón extendidas se denominan "pistones sin cabeza". Dado que los pistones sin cabeza son solo bases de pistón extendidas, se comportan exactamente como bases de pistón extendidas, pero debido a que no tienen cabeza, pueden usarse para crear situaciones que los desarrolladores nunca tuvieron la intención de que ocurrieran, y es posible explotar errores menores en el código de la base del pistón que generalmente son completamente imperceptibles.

Conseguir un pistón sin cabeza:

Si un pistón se extiende y el bloque 36 de la cabeza del pistón que se extiende se destruye antes de que termine la extensión, entonces la base del pistón permanecerá y no tendrá cabeza. Hay varios métodos para destruir el bloque 36 de la cabeza del pistón que se extiende, como explosiones, cruzamientos y cristales de ender (al final).

Propiedades especiales de los pistones sin cabeza normales:

Como ya se indicó en la sección de la base del pistón, si un pistón normal se retrae, eliminará el bloque directamente frente a él. Para pistones con cabeza, esto simplemente elimina la cabeza del pistón, pero el pistón normal sin cabeza puede usar este comportamiento para eliminar cualquier bloque, lo que puede ser útil.

Propiedades especiales de los pistones pegajosos sin cabeza:

Como ya se indicó en la sección de la base del pistón, si un pistón se retrae y si hay un bloque 36 directamente en frente del pistón, entonces ese bloque 36 caerá. Por lo general, esto solo deja caer el bloque 36 de cabezas de pistón extensibles, pero para pistones pegajosos sin cabeza, esto puede usarse para terminar instantáneamente el movimiento de cualquier bloque 36 delante del pistón.

Además, cuando un pistón pegajoso tira de un bloque, reemplazará el bloque directamente enfrente de él con el bloque 36 del bloque tirado. Por lo general, esto solo elimina la cabeza del pistón, pero se puede usar para deshacerse de cualquier bloque directamente en frente del pistón pegajoso.

:

Si un pistón recibe energía de algo que sucede después de que se procesaron los eventos de bloque, el pistón espera hasta el siguiente tic del juego antes de hacer algo. Este es el caso, si el pistón es activado por una entidad o una entidad de mosaico. Dado que el bloque 36 se procesa en la fase de entidad de mosaico, el pistón esperará 1 gtick antes de reaccionar a un bloque 36 que se convirtió a sí mismo.

Dado que la fase Tile Entity viene al final de cada tick, y el bloque 36 se convierte en la fase Tile Entity, es una aproximación útil decir que un bloque 36 necesita 3 gticks para extenderse en lugar de 2. El hecho de que un el bloque 36 necesita 2 gticks para extenderse es casi indetectable, porque todos los demás componentes, que necesitan una fase de procesamiento, ya han sido procesados ​​en el tick y no detectarán nada hasta el siguiente tick.

Versión anterior de esta página:

Solo mantendré el aspecto de la página antes de editarla, aquí.

-Explicación- Tiempos de pistón precisos

En breve, Sharir y Myren lo llenarán de (más) amplios conocimientos. Por ahora, aquí hay algo para mantenerte ocupado:

-Explicación- Mecánica de pistón (corrección + adición)

Los pistones se actualizan mediante blockEvents, lo que significa que en el instante en que reciben energía, programarán un evento para la próxima vez que se procesen blockEvents. Es importante tener en cuenta que los eventos de bloque no se guardan con el mundo, por lo que si apaga el servidor, los eventos de bloque se perderán. También vale la pena señalar que blockEvents no tiene retardo intrínseco y siempre se procesará la próxima vez que se procesen blockEvents. Estos no tienen un límite como tileTicks (con un límite de 1000 por tic). Finalmente, blockEvents siempre se procesan exactamente en el orden en que fueron creados / agregados (ocurre en la misma llamada). Lo siguiente es que cualquier bloque36 que no tenga un tileEntity (creado anteriormente en este tick o en la parte de procesamiento de tileEntity del tick anterior), crea un tileEntity para sí mismo. Luego, se procesan los eventos de bloque. Tenga en cuenta que blockEvents son las llamadas que reproducen los sonidos de extensión y retracción. Finalmente, en la parte de procesamiento de tileEntity del tick, se marcan todas las tileEntities de block36 existentes (no sucede nada más después de esto en el tick).

Echemos un vistazo a por qué, por ejemplo, funciona la tecnología 0 tick. El pistón se actualiza dos veces en el mismo tick y programa 2 eventos de bloque para la próxima vez que se procesen. El primero se procesa, crea un bloque de extensión del pistón en el frente, reproduce el sonido de extensión, etc. El segundo se procesa, ahora el pistón ve que no hay nada que lo impulse, y si es un pistón pegajoso, intenta tirar del bloque frente a él, pero ve un bloque 36 y no hace nada. En su lugar, elimina inmediatamente las tileEntities de block36 que se crearon mientras tanto, coloca el bloque al frente en lo que debería ser finalmente y establece la base del pistón de nuevo a la normalidad. Un comportamiento similar ocurre con pulsos de 1 y 2 tics, sobre 1 o 2 tics.

Echemos otro vistazo a por qué los pistones que se extienden / retraen completamente normalmente (dejan que su bloque36 tileEntity termine el proceso) hacen que otros pistones esperen 1 gtick antes de hacer algo. Digamos que un pistón se está extendiendo y está a punto de terminar. Este tick, no tiene blockEvents, pero su tileEntity ha alcanzado el progreso completo y decide terminar. Esto ocurrirá en la parte tileEntities del tick, programando un blockEvent para cualquier otro pistón impulsado / desactivado por la extensión de este. Sin embargo, blockEvents ya no se procesan con este tick, y los pistones solo comenzarán a procesarse en el siguiente tick, después de lo cual les tomará sus 2 gticks normales para completar la acción (asumiendo que la energía no se corta en el medio).



Añade un comentario de Mecánica de pistón
¡Comentario enviado con éxito! Lo revisaremos en las próximas horas.