Você pode seguir a nossa conta no Twitter onde são publicadas notícias sobre Minecraft e links rápidos para a Wiki 

Servidor brasileiro no Discord

Você pode seguir a nossa conta no Facebook onde são publicadas notícias sobre Minecraft e links rápidos para a Wiki 

Minecraft Wiki:Guia de estilo/Redstone

De Minecraft Wiki
Ir para: navegação, pesquisa

Este 'guia de estilo' existe para estabelecer uma única convenção para write-ups de circuitos e mecanismos redstone.

descrição[editar código-fonte]

Cada estrutura redstone deve ser descrita por uma combinação de texto, esquemática (s), e de tela (s).

Structure Name
Structure names should be descriptive and unique, but it is not necessary to create unique names for structures which are topologically similar (they perform the same action with the same components but vary in the exact position of the blocks).
Screenshots and Schematics
Use thumbs for all screenshots and old-style (.PNG) schematics.
Arrangement
Em geral, a descrição de "primário" deve ir para a esquerda ou para cima. (Para Inglês; em idiomas que são lidos da direita para a esquerda, que "direita ou de cima" fazer.)
* Miniaturas (screenshots e esquemas de idade) deve ou ir para a direita em uma coluna, ou abaixo em uma galeria.
* Se um esquema é pequeno e tem um monte de texto associado a ele, ele também pode ir para a direita.
* Para grandes esquemas e grupos de esquemas relacionados, um trecho de texto longo pode ir à esquerda, se há espaço (caso contrário, forçá-lo a seguir o esquema), mas se é apenas uma breve descrição, que aqueles fluxo para a direita ou forçá-los a a seguir o esquema.
* Você pode usar o {{-}} modelo de forçar tudo que se lhe segue a ser abaixo tudo antes dele. Certifique-se de usar isso no final de uma seção / antes de um cabeçalho.

Text[editar código-fonte]

Descreva todas as características importantes da estrutura. Alguns tópicos a abordar podem incluir:

Usage
Descrever a finalidade da estrutura. Explique por que ele é usado ou a função que ela serve como parte de uma estrutura maior.
Ao escrever-se um número de estruturas que todos fornecem a mesma função, considere escrever seção uso apenas uma vez para cobrir todos eles. Por exemplo, se você estiver escrevendo um número de E Gates, você poderia usar uma seção de uso único para discutir o propósito de E Gates e, em seguida, passar para descrever as diferentes formas de construir um portão e sem ter que duplicar uma discussão do seu uso com a descrição de cada estrutura.
O uso é a única parte da descrição do que deve ser considerado 'necessário' para cada estrutura redstone (ou para um conjunto de estruturas que proporcionam a mesma função).
Features
Listar as características significativas da estrutura. Recursos possíveis incluem: 1-wide, 1-alta, plana e nivelada, silencioso, etc. Outras características importantes incluem o tamanho tileable uma estrutura (as dimensões mínimas em que pode estar lado a lado), o atraso que incorre como um sub-circuito, etc.
Ao descrever o tamanho de uma estrutura, listá-la como H1 & vezes; H2 & vezes; V (isto é, as duas dimensões horizontais, em seguida, a dimensão vertical), com a menor dimensão horizontal primeiros (por exemplo, um & vezes; 5 & épocas; 3 para um bloco de estrutura 1 de largura, 5 quadras de comprimento e três blocos de altura). Sempre inclua todos os blocos necessários nas dimensões da estrutura, 'incluindo blocos necessários para apoiar componentes redstone' . (Ou seja, "in-a-vazio" dimensões). Note que a maioria dos circuitos "planas" será contado como dois blocos de alta, exceto para os muito poucos que não necessitam de blocos de apoio. Use & amp; vezes; </ code> para criar o símbolo de multiplicação, & vezes; </ code>, ou apenas usar uma letra x. Em uma tabela, você pode negrito qualquer um de nos tamanhos, para destacar um à escala e sem apoio circuitos.
Terminology
Explique qualquer nova terminologia usada ao nomear ou discutir uma estrutura. Se explicando a terminologia seria complicado o suficiente para submergir a discussão da estrutura em si, considere ligando para uma explicação da terminologia fornecida em outro lugar.
Como o uso, esta parte da descrição pode ser necessária apenas uma vez para um conjunto de estruturas que proporcionam a mesma função.
Exemplos:
Circuitos #Edge Detector são nomeados para o comprimento do impulso que geram e para se detectar a borda subindo ou caindo de um pulso (ou ambos). Por exemplo, um "1-tick Nascente Detector Edge" iria gerar uma saída de pulso 1-tick sempre que a sua entrada muda de OFF para ON. Para diferenciar ainda mais detectores de bordos do mesmo tipo, adicionar termos mais descritivos para o início do nome - por exemplo, "Repeater-Piston 1-tick Nascente Detector Edge".
# A T flip-flop é um circuito biestável (sua saída não muda até que receba nova entrada).
Se nenhuma nova terminologia é utilizada, omita esse tópico.
Construction
Explique quaisquer detalhes de construção não óbvias de screenshots ou esquemas.
Também explicar se existem problemas que podem surgir devido à ordem em que você construir uma estrutura. Algumas estruturas não funcionará corretamente a menos que determinados blocos são colocados na ordem correta, os outros pode (indesejavelmente) começar a funcionar como um relógio, se alguns blocos são colocados diante dos outros, etc.
Se não há problemas importantes com a construção da estrutura, omita esse tópico.
Behavior
Algumas estruturas podem beneficiar de uma explicação de como eles funcionam. Por exemplo:
* Estruturas que dependem do recurso quasiconnectivity.
* Estruturas que dependem do tempo de seus elementos trabalhando juntos.
Se o comportamento é óbvio, omitir esse tópico.
Considerations
Discutir quaisquer questões importantes com a estrutura. Considerações possíveis incluem:
* As comparações com outras estruturas que proporcionam a mesma função.
** Custo do material.
** Compactness.
* Comportamento como uma sub-estrutura.
** Atraso do sinal.
** Modificação comprimento de pulso.
* A dependência de, ou devido a compromissos, erros ou falhas que possam ser corrigidas mais tarde.
* O ruído de: botões, alavancas, placas de pressão, ganchos tripwire, pistões, portas, alçapões, portões da cerca, distribuidores, etc.
* Possíveis interferências com outras estruturas.
Se não há considerações importantes, omita esse tópico.
Variations
Discutir variações topológicas 'significativas' (usando os mesmos componentes e mecânica, mas um pouco organizados de forma diferente). Pequenas variações não precisa ser discutido se eles não oferecem algum benefício sobre o projeto original. Use esquemas adicionais para ilustrar variações, se necessário.
Se não houver variações significativas, omita esse tópico.
Earliest Known Publication
List the date that the structure was first published. Cite original publication as reference.
If the earliest publication date is unknown, omit this topic.

Topics don't necessarily need to be titled in the structure's description -- a single paragraph might address multiple topics with a sentence each, or each topic might consist of multiple paragraphs for a complicated structure.

Schematics[editar código-fonte]

example schematic (in this case, an AND gate)

The preferred method for creating schematics on the wiki is the schematic template.

It is permissible to upload screenshots of schematics from redstone simulator programs, but expect them to get converted by someone else later (or you can do it when you get the chance). Don't use animated GIFs to show multi-layer schematics -- the speed of animated GIFs cannot be modified by the viewer, and not everyone can read schematics as quickly as they appear and disappear.

Large or numerous schematics can overburden the server when trying to render the page:

  • Pages with templates will take longer to respond when saving or previewing, and if that takes too long, the process will fail with either a blank white screen, or a "Server at Capacity" error.
  • If the page load does fail, the browsers "Page Back" button will work better than a refresh to get back to your edit buffer.
  • The load time increases with the total number of sprites in all schematics on the page. Stacked sprites cost proportionately more server time than unstacked ones: if N sprites are stacked in a tile, the cost is about (2×N)-1. Thus dual-layer diagrams are much more "expensive" against the page limits.

There are two methods for handling too many schematics, both involving "offloading" schematics to subpages that can be loaded into the main page at the user's request:

  • Preferred: {{LoadBox}} creates a box into which a subpage can be loaded. It is intended for a small amount of content (a single schematic or a group of schematics). LoadBox takes two named parameters: page, the subpage path, (as wiki link text, e.g. Namespace:Article/subpage), and title, the box title. Thus you might use a call such as: {{LoadBox|page=Frammistat/Widget 2|title=Widget Design #2}} .
  • {{LoadPage}} creates an article section into which a subpage can be loaded. It is intended for large amounts of content which would normally be an entire section in an article, but which is offloaded because of the performance issues described above. LoadPage takes three unnamed parameters, in order: the filename, the title that will show before loading, and the header level you want for that title. Example: if your current page is "Frammistat", and you are inserting a section on Duloxic Frammistats, you can insert the call: {{LoadPage|Frammistat/Duloxic|Duloxic Frammistats|h3}}, and transfer the relevant diagrams and descriptions to the page "Frammistat/Duloxic".

Use LoadBox rather than LoadPage when possible, because it keeps the majority of the article's content within the article, making it easier to read through the article and ensuring that search results lead to the article and not to a subpage with no obvious means of getting to the main article.

Captions[editar código-fonte]

Add {{Schematic help}} to the caption of the first schematic in an article, and to additional schematics if that would be helpful. This will create a standard help link to Help:Schematic.

Content[editar código-fonte]

Use the standard identifiers for different roles instead of your personal block preferences. These generate schematics that match the conventions used for screenshots. For redstone circuits, the important distinctions among blocks are solidity, and opacity vs. transparency.

  • Use input and output to indicate where a circuit begins and ends. Currently, these default to showing lime and pink wool respectively: and . If you have more than one kind of input or output (say, clock or control lines as well as data), mark them with overlaid letters (e.g., A), and identify their role in the text.
  • Use SB (mnemonic: "Stationary Block") to indicate a solid opaque block required for redstone purposes (supporting redstone components, transmitting power, etc.). Currently, this appears as .
  • Use MB (mnemonic: "Moving Block") to indicate a solid opaque block that will be moved by pistons. Currently, this appears as . Don't use this if it matters what sort of block is being moved, as with sand or a block of redstone; then you should use the specific block type instead.
  • Use ts and ts-$ (mnemonic: "top slab") to indicate a transparent block that can support redstone dust (e.g., glowstone, upside-down slabs, etc.). Currently, these appear as , and (top and side views). That is, when you have a choice between glowstone, upside-down stairs, and a top slab, use the top slab. If you could also use glass (the block does not need to carry redstone) then you can show it as ts or as glass.
  • Use AB (mnemonic: "Any Block") to indicate a solid block that is needed for structural purposes, but not for redstone purposes (containing water or lava, blocking mobs, placing ladders, fending stray updates off of a BUD, etc.). Use this if the block could be any building block, such as dirt, obsidian, or glass. Currently, this appears as .

Temporary blocks (meant to be placed, then removed while building) can be shown as any easily-removed block that's not otherwise used in the diagram, and would not behave oddly. Some options are dirt or leaves. It's not necessary to show blocks that would only be used for placing other blocks (such as putting a block in midair).

Anywhere a particular block is needed, use that block. Examples include dirt or farmland for farming, obsidian for durability, and so on. If you have options, use the least expensive or least exotic block that would do (e.g. Jack-o-lanterns rather than glowstone).

Any use of darkening should be explained in caption or text. For MCRS diagrams, darkening meant "solid block above"; since that has been replaced by the transparent sprites (see below), a darkened block is now ambiguous. However, it can still be used to indicate occasional stacking, or other situations that would otherwise require a separate level diagram.

Lightening is used to indicate a significant block that would not normally be shown on this level, and is not covered or underlaid by this level. Usually, that means the input and/or output blocks, but you can use it sparingly to avoid an extra level diagram that would just be one or two items.

Repeating sections of an expandable circuit can be indicated with ellipsis sprites.

Layout[editar código-fonte]

Multi-layer schematics can be done two ways. Use whichever seems more understandable, but don't mix them for a single structure.

Multiple single-level schematics
Single-level schematics, each showing all blocks, dust, and components at the same Y coordinate, with no stacking. Each level of the structure gets its own schematic. A variation of this is the sideview schematic for 1-wide structures. This is recommended for non-redstone schematics, as it is less burdensome on the server and few blocks have transparent versions.
One or more dual-level schematics
Dual-level schematics show two levels at a time: blocks, components, or empty space, but all in a two-block layer. For three- or more-layer circuits, do a separate schematic for each pair of adjacent levels: 1/2, 2/3, and so on. These might make circuits clearer, but be aware that stacked sprites count extra against the page limits.
Use the transparent sprites (SB-u, MB-u, ts-u, and BR-u) for blocks that are "covering" another block. One solid block atop another can be shown by darkening the block. If you are stacking blocks of different colors (say, a mobile block atop a stationary one), note it in caption or text, as this will otherwise be unclear.
If there are only one or two items on a third level, you might be able to use darkening or lightening to avoid an extra layer diagram, but make sure the result is understandable (then note it in caption or text anyway). Otherwise, don't try to cram in a third level.
Not every circuit is suited for dual layers, and especially mechanisms don't do well; if it looks confusing or you are having trouble showing what's going on, switch back to single-layer diagrams.

Screenshots[editar código-fonte]

Example screenshot (in this case, an AND Gate)

Along with redstone schematics and written explanations, screenshots illustrate the correct way to construct redstone structures. When creating screenshots, structures should be built and shot in a consistent way so that users can quickly learn to identify which blocks in an image are part of the structure and what they do, and which blocks are there to help explain it, etc.

A screenshot can contain multiple structures if that would help to illustrate differences between different structures, or to illustrate variations of the same structure.

Building the structure[editar código-fonte]

Choices

Everyone has their own opinions on which blocks should be used in screenshots. So why these blocks?

The Block of Gold was chosen as the primary opaque block because it most closely matches the solid yellow symbol used for blocks in most redstone simulation software. Its edging also makes it easy to count and differentiate.

The Block of Diamond was chosen for moving blocks because its texture is similar to the block of gold, but its different coloring makes it easy to pick out the moving parts of a redstone structure.

The upside-down Stone Slab was chosen because glowstone is a little too similar in coloring to the block of gold, slabs are less complicated than stairs, and the stone slab is easily recognizable as a slab.

Lime Wool and Pink Wool were chosen for inputs and outputs because "green starts the circuit, red stops the circuit" is an easy metaphor to remember (but the lighter versions -- lime and pink -- are used because redstone wire shows up better against them).

Background
Structures should be built and shot in front of a plain, non-distracting background.
The preferred background is a sandstone superflat world (like the Redstone Ready superflat preset), with no other blocks or mobs in the picture. Other possible backgrounds might include: the void, the sky (for under-shots, with clouds turned off), or other superflat worlds made from grass block, iron blocks, glass, etc.
Positioning
Build structures off the ground (free-floating in the air) so that they can be shot from any direction and so that it's clear exactly which blocks are part of the structure.
Blocks
Use the following blocks to build the structure and then remove all unnecessary blocks:
  • Redstone components: Use redstone torches, wire, and repeaters, as needed.
  • Opaque blocks: Use a gold block for all opaque blocks that are necessary to the structure (to support redstone torches, wire, and repeaters or to provide power to another element of the structure, etc.). For complicated redstone structures, consider using different colors of wool (instead of gold blocks) to distinguish different functional parts of the structure.
  • Moving blocks: Use a diamond block for all blocks intended to be moved by a sticky piston. This helps to illustrate the moving parts of a piston-based structure in a static screenshot.
  • Upside-down slabs: Use a stone slab for upside-down slabs required by the structure.
    • Only use upside-down slabs when they are necessary to the structure (because they can act as diodes, to avoid cutting redstone below, to avoid powering a block in that location, etc.).
    • Where an upside-down slab, upside-down stair or glowstone can be used interchangeably in a structure, use a stone slab.
  • Structural blocks: Use a stone bricks block for all blocks required for structural purposes, but not for redstone purposes (retaining water or lava, confining mobs, etc.). Use glass instead when that would help clarify internal structure.
  • Other blocks: Use any additional blocks required by the structure (such as pistons) or necessary to illustrate the purpose of the structure (for example, a structure intended to control a door should include the door in the screenshot).
Input/Output Lines
When it would be helpful to understand the structure, include additional blocks outside of the structure to illustrate how signals enter and exit the structure.
  • Inputs should use lime wool as a background. For structures controlled by buttons, levers, etc., use lime wool to support the power component. For structures which receive input from another sub-structure, use lime wool as the supporting block for redstone wire, redstone repeaters, etc.
  • Outputs should use pink wool as a background.
  • Duplex I/O (where the same point can be both an input and an output), can be indicated with light blue wool.
  • Buses (wire lines between structures) should be laid on white wool. Other colors may be used for multiple buses if that would improve clarity.

Taking a screenshot[editar código-fonte]

Preparation
Before taking a screenshot, take the following steps:
  • Remove or deactivate mods that would affect the screenshot (unless they're specifically about a mod, all Minecraft Wiki screenshots should represent Minecraft "out-of-the-box"). Mods that wouldn't affect the screenshot, or would get cropped out later, are fine.
  • Set Texture Pack to Default (see above).
  • Set Graphics to Fancy.
  • Set FOV to Normal (the lowest setting, to minimize perspective distortions).
  • Set Particles to Minimal (to remove particles from redstone torches which might obscure or be mistaken for redstone wire).
  • Set Smooth Lighting to ON (to subdue distracting block shadows).
  • Set Clouds to OFF (only if you're intending to use the sky as a backdrop).
  • Set view to first-person (you shouldn't be in the shot). Use F5 to switch to first-person.
  • Turn off the HUD by pressing F1.
Taking the Shot
  • Angle: Make sure the entire structure is in the picture, including input/output lines and other illustrative blocks if present. Make sure there is additional space around the structure in your framing so that it has a nice border and you have room to do some cropping later. Try to find an angle that illustrates all important elements of the structure, but some structures may require multiple angles/shots to illustrate everything.
  • Stand on a block rather than flying over the structure. Flying expands your "field-of-view" (FOV) which increases perspective distortion, so standing is better for taking pictures. The block can be in any position that gives you a good shot, and if you need to take the picture again the block will make it easier to get back in position. If you have access to them, standing on a barrier block is best as they are invisible.
  • Make sure no mobs have wandered into frame, and that there are no other stray entities (such as dropped items) that would clutter the shot.
  • Lighting: Take screenshots in the daytime, unless necessary to illustrate a feature of the structure (if you have command privileges, use /time set 6000 to set the time to noon right before the shot).
  • Press F2 to take the screenshot (or use your own screen capture software).

Finishing up[editar código-fonte]

Editing
Screenshots may need clean-up to improve clarity, but this may require some knowledge of image editing software. If you don't know how to do this, or can't, go ahead and upload your image -- hopefully someone will fix your image later (yay, wikis!).
  • Cropping: Crop the image so that the structure takes up most of the picture, but leave some border so the structure isn't crowding the edge.
  • Color Adjustment: Some screenshots may need their color adjusted to improve clarity (especially screenshots of oscilloscopes while the game is paused and dimmed).
  • File Type: All uploaded screenshots should be of type .png (Portable Network Graphic). F2 screenshots are PNGs by default, but if you use other screen capture software you may need to convert the image to a PNG with image editing software.
Upload the image to the Minecraft Wiki.
  • Start at the Upload File page.
  • Use the Browse button to find the image on your computer.
  • Add a description!
  • Set the Licensing menu to "This file is a screenshot of/uses textures from Minecraft".
  • Check everything and then hit the Upload File button.
Add the screenshot to an article.
Images that aren't used by articles may get deleted after a while.
To add a default thumb like the example screenshot above, use [[File:FILENAME|thumb|CAPTION]].
  • FILENAME is the name of the file (e.g., My_Image.png).
  • CAPTION is the text to appear under the image.