Lucky Block Documentation


3.1 Complex Values

Quotes & Backslashes

When specifying a text value, quotes will usually not be needed. Conventionally, quotes should not be used for IDs and other one-word properties, but should be used for text containing multiple words. However, there will be certain situations where quotes are necessary. When the value of the text can be interpreted as any other data type, such as a number, quotes need to be used (e.g. "5"). Also, quotes must be used if the text contains any of the following symbols: , ; ( ) [ ] { }. However, it is best to quote text containing any symbol (with the exception of : and _ for IDs). Alternatively, any character will be canceled (neutralized) and treated as part of the text if preceded with a backslash \ (e.g. Hello\, How are you?). Generally, this isn't recommended due to its obscurity, though there may be situations where it is unavoidable or convenient.


When text contains a quote part of the text, the inner quote must be canceled with a backslash. This may occur if the quotes are simply desired to be a part of the text, such as in the message below.

type=message,ID="To quote Sam, \"The Lucky Block mod is fun!\""

In this case, regardless of the number of quotes, each quote must only be canceled with a single backslash. However, there may also be more technical cases where a pair of inner quotes is actually required to neutralize text within it. The most probable situation for this is when using the hash variable #randList(), or when setting the tile entity of a Lucky Block (See 6.3 Block Data). An example of a drop that sets a Lucky Block that will give the message "Hello, how are you?" when harvested is below. This example uses NBT Tags, which have a similar text concept.

type=block,ID=lucky:lucky_block,NBTTag=(Drops=["type=message,ID=\"Hello, how are you?\""])

Alternatively, the comma in the Lucky Block's message could be canceled with a backslash. If there ever is a situation which involves quotes within quotes within quotes, two backslashes will be required for the inner-most quotes. If even more quote layers are desired, each layer will require an extra backslash.


Complex Example

Below is an example of message containing a complex random list (See 3.2 Hash Variables).

type=message,ID="Here, a complex message: #randList(\"Color, #randList(red,green,blue)\",\"Symbol, #randList(\(,\,,\))\", \"Symbol Text, #randList(\\"(Brackets)\\",\\", Comma ,\\")\")"

This example includes a message with a complex random list. The outer random list contains three inner messages with random lists. These inner messages and random lists, in pseudo-syntax, are as follows: "Color, (red,green,blue)", "Symbol, (open bracket,comma,close bracket)", "Symbol Text, ( "(Brackets)" , ", Comma ," )". The first inner random list doesn't use quotes for its values, as the values do not contain symbols. The second list also doesn't use quotes, but instead cancels every symbol with a single backslash. The last list uses quotes, resulting in the need for double back-slashing. Below is an alternate version of this example that only uses one pair of quotes and cancels all symbols with backslashes. This version is possibly easier to read and understand.

type=message,ID="Here, a complex message: #randList(Color\, #randList(red,green,blue),Symbol\, #randList(\(,\,,\)), Symbol Text\, #randList(\(Brackets\),\, Comma \,))"


Lucky Block Tile Entity

IMPORTANT: As of the 1.8 Lucky Block Combat Update, hash variables do not need to be cancelled ('#'), as this is done automatically. To prevent automatic cancelling use [#].


When setting the tile entity of a Lucky Block (See 6.3 Block Data) and using hash variables within the tile entity, problems may also arise. Consider the example below.


This example will spawn a Lucky Block at the world coordinates 100, 64, 100. When the newly spawned Lucky Block is harvested, it should spawn a pig 10 blocks above it. However, it instead spawns a pig 10 blocks above the original Lucky Block, not the new one at 100, 64, 100. This is because when the first Lucky Block was harvested, its tile entity was processed and the hash variables were replaced, giving the position value of the original Lucky Block. To fix the issue, the hash variable must remain until processed by the second Lucky Block. This can be done by canceling the hash symbol with single quotes, as explained in 3.2 Hash Variables.


When the tile entity is first processed, the quoted hash symbol ('#'bPosY+10) will be replaced with a normal hash symbol (#bPosY+10), but the hash value will not be processed. It will be added to the tile entity of the new Lucky Block in unprocessed form. When the new Lucky Block is harvested, the unprocessed hash value (#bPosY+10) will be processed and replaced with a real value (74), and the example will work as expected. This problem may arise whenever Lucky Block tile entities are used, and is common in .luckystruct structure files (See 2.5 Structures). Note that one exception to this problem is when using structure specific hash variables such as #sPos. These are meant to be processed when the original structure is created, and should not be canceled.



Lucky Block numerical property values support basic addition, subtraction, division and multiplication, and will be evaluated when processed. However, only one symbol is allowed in each value. Below are two examples demonstrating this.


The first example spawns a pig 10 blocks above the harvested position. The second example spawns an item and sets the ID to the result of a numerical equation, evaluating to 273, the ID of a stone shovel. It is also possible to evaluate expressions in JavaScript syntax using the hash variable #eval(...) (See 3.2 Hash Variables). This should generally not need to be used, and is not recommended due to its potential impact on performance. However, it can provide a wide range of functionality, such as support for more complex equations and JavaScript statements. Below is an example which also drops a stone shovel, though in a more complex way.


As well as this, one-line JavaScript statements, such as ternary statements, can be used. The below example will display either the message "Day Time" or "Night Time" depending on the Minecraft world time.

type=message,ID=#eval(#time < 12000 ? "Day Time" : "Night Time")

Finally note complex expressions are rarely used, the most common use being equations for setting positions (such as the first equation example).

Back Forward

Copyright Minecraft Ascending 2015