A puzzlescript file is divided into the following sections.
Have you ever felt the need to create a family of similar objects, and found it takes a lot of cutting and pasting in the editor? That's what the Tags section is about. Start with a single object, then use tags and sprite transforms to create a whole family of objects and the rules to go with them and for next to no effort. Nice!
Here is a sample Tags section.
Puzzlescript NextTAGS
====
Int = I0 I1 I2 I3 I4 I5 I6 I7 I8 I9
Bool = True False Maybe
Primary = Red Yellow Blue
Secondary = Purple Orange Green
Color = Primary Secondary Trash
AX = A1 A2 A3 A4 A5
// these are pre-defined, so you don't need to:
//directions = up right down left
//horizontal = right left
//vertical = up down
Couple of things to note. The tag name is before the equals sign, and the values follow. If a value is already defined as a tag name, then all its values are included, and so on. The Color tag therefore has 7 values.
When the tag name is used in defining an object, it is expanded into its values like this.
OBJECTS
=======
redborder:directions
red
00000000
.000000.
........
........
........
........
........
........
rot:up:>
blueborder:directions
blue
copy:redborder:directions
greenthing:directions
green
copy:redborder:directions flip:^ translate:>:3 shift:v:2
temp:Int:Color:AX
transparent
The first definition creates four red border objects called redborder:up, redborder:right, redborder:down, redborder:left. Each object is rotated by 90 degrees, to make up the four sides of a square. Then the second definition creates another four matching blue border objects.
You can do something similar with flip, shift and translate, replaced the absolute direction by relative, for a rather strange green thing as per the third example.
How it works is that the object name is divided into 'parts' separated by colons. Each part, if it is a tag name, is expanded into all its values. So how many temporary objects does the final definition create? The answer is 350! That's 10 Ints, 7 colors and 5 AX's. Not sure why you'd need so many, but that's what it does.
Now where are you going to use all these objects? In rules, of course!
[ greenthing:directions | crate ] -> [ | crate ]
[ greenthing:directions | crate ] -> [ | greenthing:directions ]
[ greenthing:directions | crate ] -> [ greenthing:directions | greenthing:directions ]
directions [ greenthing:directions | crate ] -> [ greenthing:directions | greenthing:directions ]
[ player | temp:Int:Color:AX ] -> [ temp:Int:Color:AX | player ]
The first rule obviously finds any greenthings (eight different kinds) next to crates and destroys them. But it does so in quite a clever way. The original object you defined is replaced by the tag expansion, and then the original object is redefined as a property object. The result is that the first rule only expands to 4 basic rules, one for each direction. (As well, each of the objects created by tags can be redefined without triggering an error. Sometimes that turns out to be quite useful.)
The second rule replaces crates by greenthings. In this case the rule has to be expanded, so this one rule turns into 16. At least you didn't have to type them yourself.
The third rules shows the use of a tag as a rule prefix. Again, the expansion is to 16 basic rules.
As you can imagine, if you use objects with a lot of tag values (like temp:Int:Color:AX), the expansion can be enormous (1400 rules in the case of the fourth rule).
Object names with Tag parts also work in the these sections, and there is a special feature.
COLLISIONLAYERS
redborder:directions, blueborder:directions
Int Color AX -> temp:Int:Color:AX
The first line puts the 8 border objects into the same layer, which makes perfect sense because they could never interfere with each other. The second line puts the 350 temporary objects each into its own layer, one for each tag value and combination on the left of the arrow!