I’ve had this problem off and on in the course of developing modules, and it’s a puzzler.
I have set my pieces up with various Layers, functions, submenus, etc., and one in particular is causing issues.
It’s located in a Layer called “Flip” which shows the second layer (the “back side” of the counter). The suffix I have edited in is -d (shorthand for a disrupted state).
I’ve checked the Prototype over and over and made sure that the “is suffix” radio button is selected so that what should display in the buffer is “Piece Name -d moves from 1214 to 1314”. “-d” is the actual suffix.
When I save changes to the module, drag a new piece onto the map, and move it, it works nicely: “Piece name moves from 1214 to 1314”. Then I use the Flip feature, and when I move it, the message is, “-d moves from 1314 to 1214”.
Why is the Piece Name portion of the message not displaying?
I have a similar setup for Commander piecess, where the suffix -repl (for replacement) is set up to display. It works fine and the settings are identical, as far as I can tell.
I have also checked the map properties to make sure $PieceName$ is set up to display in all instances.
Could be a simple typo …like an extra space at the end of a command or one letter out of place. I’ve done that a few times and it’s driven crazy for hours.
I’ve also noticed that you’re using a Prototype. I’ve had problems in the past using a prototype for Layers and Dynamic Properties as prototypes are inherently designed to apply to all pieces that carry that prototype whereas Layers and Dynamic Properties tend to be piece specific and they probably should be used as a piece trait rather than a prototype trait.
In fact, I’ll only use a layer or DP in a prototype if I intentionally plan to have all pieces using that prototype to carry the same value or display the same layer.
Hmmm, that seems an odd “restriction”. Especially since other layers are in play (including identical flip layers) on other prototypes and they work with no problems. Still, it could be a design thing, one of those odd unexplainable artifacts (like layers in the list in the Editor showing up on the pieces in the REVERSE order)
I’ve been considering just chalking it up to some odd corruption in the piece prototype and just deleting it and starting over… but having to RE-create all the Layers submenus and attributes seems to be begging for the introduction of more error. Maybe, I’ll start with killing that one layer in that one prototype and see if that won’t solve the issue (although I’m sure I’ve already tried that, since it’s the easiest solution).
Something else just occurred to me: I wonder if the problem might be that during the creation of all these layers and features (spread out over months’ time) I might have duplicated some keyboard shortcuts in the commands and it’s creating some “collisions” in the code? Not sure why that would manifest itself by a $PieceName$ disappearing out of ONE particular layer, but, just thinking out loud.
My biggest confusion is in not being able to see any kind of alphanumeric editable input relative to the piece name in the Layer editing screen itself. The only thing visible and editable are the “is prefix” and “is suffix” buttons.
Being an heavy Prototype and DP user (with a touch of layers), I’m pretty sure Prototypes do not mess DP and are handled correctly (ie as abstract classes instanciated for each object inheriting them). And indeed, I am a strong believer that Prototypes do reduce the risk of errors by poor copy/paste.
You may, however have an issue with Prototype order since they are loaded in order and can only affect previously loaded Prototypes.
Concerning overloading command names, you are now allowed (since quite some time) to give each command a real name and not just the keyboard shortcut. I suggest to make heavy use of this feature and give your commands (especially the internal ones not seen by the end users) a long and explicit name to limit risks. And make your own list in a side text file if you’re afraid of forgetting them…
Make your naming conventions for commands and stick with it (eg ‘DoSomething’, ‘do_something’ or ‘do.something’, do not mix conventions in a single module). And if you have many aspects in your game, use a naming convention that allows separate namespaces (usually, prefixes that tell what the command is related to). For example, Foo.do_something and Bar.do_something could have a similar effect but on different aspects of the game.
And I often create ‘debug’ commands when needed. That’s commands that basically log all the internal values of a piece (eg "pos: $position$ - HP: $hp$ - " and so on). Sometimes, it is necessarily to use them within trigger (ie, in your case you can make a trigger command debug/flip/debug to see what happen with which DP/CP).