Not sure why this is happening, but I’m working on a module that uses strength point markers under units to denote current strength.
I have all the game markers in the module set up in a prototype as having Delete, Clone and Rotate features only; this SP item also has over a dozen “Layers” so that players can go through the different strength levels. None of the levels have any “names” or prefix/suffixes on them.
Now, when these markers are placed, and when they are moved (with their parent unit), they generate text buffer reports (e.g., Strength Point moves from hex ## to hex #). But I don’t want them to; is there a way to preclude their appearance? In other words, can you set buffer reports on a piece-by-piece basis, or is this only limited to MAPS?
I have similar markers in other modules and I don’t recall them causing text buffer reports (but I may be wrong).
A piece (so a marker, a unit, whatever) only generates a text report when something in one of it’s prototypes executes a “Report” trait. And modules DO often get built so that, say, Units will receive some sort of trigger (e.g. “MovedOnMap” or “MovedMap” or something like that) from the map when they are moved on it. Their response to this trigger may be directly captured with a “Report” trait, or sometimes a “Trigger” trait will first check things and then fire a new key command to activate a Report trait.
Ideally of course, this would only be true of one level of a “unit”, not individually true of a whole bunch of “parts of the unit”. But it sounds like in the module you’ve got, a bunch of the sub-parts of a unit may all be attached to a “prototype” that does reporting - so they’re ALL handling the same MovedMap trigger and then ALL generating their own individual reports. By digging your way around the Global Prototypes you may be able to figure out which level is doing this – it may be that things like the Strength Points are inheriting a Prototype (so have a Prototype trait in their definition) that they really don’t need. Or one of their prototypes is responding to a moved-on-map trigger when it shouldn’t be. Not saying this will be “easy” to find or correct, but it’s definitely correctable.
What you say is mostly correct except I think for this. Maps can generate reports for pieces that move across or onto the map. You can see this in the Map setup page. These reports, which I don’t think can be selectively disabled, are unrelated to report traits. I suspect it’s map reports the OP is talking about.
If it were my module and based on my limited understanding, I would try to merge both pieces into one. This would solve the report problem and avoid other problems like the pieces becoming separated.