API changes to allow for more mounting styles

NODE NAMES:

The base name of a node can be whatever you want.  The basic wall sign
will keep the node name you give, while its hanging, on-pole, and yard
variants will, where applicable, use the same name, with "_onpole",
"_hanging", or "_yard" appended.

One exception:

If your node has "_wall" in its name, that bit will be stripped-out when
generating the above node variations.  For example:

"default:sign_wall_wood"

...will become...

"default:sign_wood_onpole"
"default:sign_wood_hanging"
"default:sign_wood_yard"

MODELS:

The base sign model and entity files must now be named:

sign:   mymod_foosign_wall.obj
        mymod_foosign_facedir_wall.obj

entity: mymod_foosign_entity_wall.obj

their other variants, where applicable, must be:

mymod_foosign_onpole.obj
mymod_foosign_hanging.obj
mymod_foosign_yard.obj

mymod_foosign_entity_onpole.obj
mymod_foosign_entity_hanging.obj
mymod_foosign_entity_yard.obj

For `facedir` signs, the "_facedir" in the base sign model filename is
automatically stripped from the name when generating the entity model
filename, as entities don't have a concept of wallmounted/facedir/etc.
For example:

"mymod_foosign_facedir_wall.obj"

...will become...

"mymod_foosign_entity_wall.obj"

* allow passing custom onpole, hanging, and yard sign models, for
situations where the filename(s) thereof can't be derived from the base
sign model filename.

* allow passing a custom pole mount, hanging, and yard sign stick
textures as the third, fourth, and fifth tiles{} entries, respectively
(independent of the above model file option)

* fine-tuned the pole mount on the standard sign models to eliminate
overlapping faces (so it looks better with basic_signs' glass sign.

* Move basic_signs wooden yard sign back to signs_lib.

MODELS.md

@@ -2,9 +2,11 @@
 
 In the model files:
 
-* The base sign model should be designed to look like a flat board placed on one side of the node space.  The first material entry in the model file must be assigned to the front and back faces of the sign, the second material must be the sign's edges.  The filename should be something along the lines of `mymod_my_cool_sign.obj`.
+* The base sign model should be designed to look like a flat board placed on one side of the node space.  The first material entry in the model file must be assigned to the front and back faces of the sign, the second material must be the sign's edges.  The filename should be something along the lines of `mymod_my_cool_sign_wall.obj`.
 
-* For most signs that are allowed to sit on a vertical pole/post such as a fencepost, the pole-mounted model is just a copy of the base model, shifted back a bit, with a pole mount added to the back.  In these models, the third material in the model file must be assigned to the pole mount.  Name the model file the same as the base sign, but end the name with `_onpole`.  For example, `mymod_my_cool_sign_onpole.obj`.
+  In each of the variants below, generally-speaking, the third material in the model must be assigned to whatever it is that that model uses for the sign's mounting method, and the mounting style will be the last word in the model filename.
+
+* For most signs that are allowed to sit on a vertical pole/post such as a fencepost, the pole-mounted model is just a copy of the base model, shifted back a bit, with a pole mount added to the back.  In these models, the third material in the model file must be assigned to the pole mount.  Name the model file the same as the base sign, but end the name with `_onpole` instead of `_wall`.  For example, `mymod_my_cool_sign_onpole.obj`.
 
   For signs that allow mounting onto a horizontal pole (such as a Streets mod horizontal "bigpole"), the third material is still the vertical pole mount as above, but there must also be another the pole mount included, designed to wrap around such a pole/post, to which fourth material must be assigned.  In most cases, this alternate mount will just be a copy of the vertical pole mount, but rotated by 90°, and explicitly centered vertically in the node space.
 
@@ -12,20 +14,28 @@ In the model files:
 
 * For hanging sign models, the third material must be assigned to whatever it is that makes the sign look like it's hanging from the ceiling (default signs have a simple, flat rectangle, meant to show an image of a simple pair of chains).  The model file for these must be named the same as the base model, but ending with `_hanging`.  For example, `mymod_my_cool_sign_hanging.obj`.
 
-* For most signs, the sign entity will be a simple rectangle, sized just slightly smaller than the width and height of the sign, and centered relative to the sign face.  Its UV map should cover the entire image area, so that the image is shrunk down to fit within the sign's intended text area.  The rectangle must be positioned slightly in front of the sign (by 10 millimeters or so, due to engine position precision limitations).
+* For yard sign models, the third material must be assigned to to the "stick" on the back of the sign that hold it up.  The model for this type must be named the same as the base model, but ending with `_yard`.  For example, `mymod_my_cool_sign_yard.obj`.
+
+* For most signs, the sign entity (if applicable) will be a simple rectangle, sized just slightly smaller than the width and height of the sign, and centered relative to the sign face.  Its UV map should cover the entire image area, so that the image is shrunk down to fit within the sign's intended text area.  The rectangle must be positioned slightly in front of the sign (by 10 millimeters or so, due to engine position precision limitations).
+
+  The entity should be named the same as the corresponding wall, on-pole, hanging, and/or yard models, but with "_entity" added just before the mounting style.  For example:  a sign using `mymod_my_cool_sign_wall.obj` for the base model file should have an entity model file named `mymod_my_cool_sign_entity_wall.obj`.
 
 In your code:
 
-* For most sign types, `signs_lib` expects the first `tiles{}` entry in the sign definition to be the front-back texture (how the two textures are arranged within the image file is up to you, provided you match your sign model's UV map to the image layout).  The texture for the edges is the second entry.
+* The first `tiles{}` entry in the sign definition needs to be the front-back texture (how things are arranged within the image file is up to you, provided you match your sign model's UV map to the layout of your image).  The second entry will be the texture for the sign's edges.
 
-* For pole/post-mounted sign models, if applicable, the mod will ignore any further tile entries, and will directly set the third and fourth entries so that one of them is blank, while the other is set to the standard pole mount texture.  Which one it sets to the pole mount texture is what controls whether the vertical or horizontal mount is visible.
+* For signs that can be mounted on a pole/post, the third `tiles{}` specifies the pole mount image to use.  When `signs_lib` goes to register the on-pole version of the base sign, it will rewrite the third and fourth `tiles{}` entries internally.  one will be set to the texture you supplied, the other will be set to the standard empty image.  Which one it sets to the pole mount texture is what controls whether the vertical or horizontal mount is visible.  If you don't specify a pole mount image in the third `tiles{}` entry, `signs_lib` will use its standard pole mount texture.
 
-* For sign models that hang from a ceiling, the third `tiles{}` entry must be set to a suitable image that fits whatever the parts are that suspend the sign from above.
+* For signs that can hang from a ceiling, the fourth `tiles{}` entry specifies the image to apply to the part of the model that makes it look like it's hanging.  If this entry is not set, `signs_lib` will use its standard hanging chains image.
+
+* For signs that can stand up in the yard, the fifth `tiles{}` entry specifies the image to be wrapped around the "stick" that the sign's mounted on.  If not set, it will default to "default_wood.png".
 
 * Some signs may allow for more complex entity shapes, images, and UV mapping.  For example, [street_signs](https://forum.minetest.net/viewtopic.php?t=20866) has a standard city street intersection sign, the entity mesh for which consists of four simple rectangles.  Two of them are identically UV-mapped to the top portion of the texture image, and placed on either side of the upper half of the sign portion of the model.  The other two rectangles are also identically UV-mapped, but point to a lower section of the texture, and are rotated by 90° and shifted down in the model, to place them on either side of the lower half of the sign.  This causes the first line of text to appear on both sides of the upper half of the sign, with the second line of text appearing on both sides of the lower half.
 
   Signs which don't use the simple models described above may not be compatible with the wall, ceiling, floor, or pole/post placement paradigm, but these things can be overridden/disabled in the node definition, if needed (as with the above intersection sign).
 
+* `signs_lib` automatically blanks-out all redundant `tiles{}` entries for each node.
+
 ## Blender users
 
 Start a new project, open the "Sidebar" (usually by pressing `N`), and scroll down to the Display section.  Set the Grid floor to 5 lines, Scale to 0.5, and Subdivisions to 8.