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.
when the world loads and the player spawns in, or is
teleported to the same node space as a sign, occasionally, the
player's model goes flat and their skin gets changed to the
whatever the sign's text is.
Also, when checking if an entity needs spawned, or when
deleting, try to make absolutely sure that only sign-related
entities will be selected for re-use, or selected for deletion
(we don't want some player's prize cow to be deleted)
I think this will fix it, or at least it'll surely prevent
signs_lib from being able to cause it.
Also, moved another function to the entity-handling section of
the file and made it global (signs_lib namespace) in the
process.
Also, tweaked the object names in the standard sign Blender
project file, renamed it, renamed the small/slim pole mount
project file as well, and added a copy of the standard pole
mount project file.
to the pole and horiz pole check routines, in case they need
their own, custom checking routines, if the usual, simple
checks aren't good enough.
got rid of the allowed-poles table, as it's now obsolete
moved all existing special code into compat.lua, altered to
use this feature.
Treat T-junction as a vertical or horizontal pole (depending
on its orientation), if the sign could be placed flat against
the back or side of the junction.
In this instance, the "front" of the junction is the side with
the middle bit sticking out, and will just get a regular wall
signif targeted, as with any non-pole node.
(both wooden and steel signs)
only streets mod's "bigpole" supported for now.
Model changes:
To make a sign support horizontal mounting, make a single "_onpole"
model, with two copies of the pole mount, one rotated by 90°. Make sure
the second copy appears has its own material entry, and that it is last
in the materials list in the exported .obj (`grep "g " file.obj` to
check).
When registered, signs_lib will set the "_onpole" and "_onpole_horiz"
tiles{} to reveal one mount or the other: entry 3 will expose the
vertical mount, entry 4 is the horizontal copy, with the opposite entry
being set to the "blank" image.
