Bug(?) in the CoreRPG Ruleset

[Minty23185Fresh]

I'm hoping this is the place to post this. I don't see a specific sub-forum for bugs, like there is for 5E.

This is rather esoteric, but a bug none-the-less, I believe.
The issue is, that the true name of an NPC shows up in a shared encounter, on the client's copy, even though the NPC is marked as "unidentified". (The provided screenshots will help make that more intelligible.)

The first screenshot is of the host's (GM's) instance.
(Note that there are no extensions loaded (bottom of the chat window).
Untitled1.png
In the left portion of the screenshot, NPC information has been provided. I will be using "My 1st NPC", note that it is shared (with the client) and is marked as "unidentified". Also note both the real name and the non-id'ed name.

In the right portion of the screenshot I have provided an encounter. Note that it too is shared with the client. I'm not sure why one might do this, but I can, so it should behave properly. The NPC in the encounter is still marked as unidentified and the real name appears in the encounter window. Having the real name show up for the GM is an expected behavior.

Now for the client's screenshot, shown below. Just as with the host, the left portion of the screenshot shows the NPC data and the right shows the encounter data. For the NPC data, note that only the unidentified information is available to the player (client). But, the shared encounter reveals the real, true name of the NPC in the encounter's details (circled in red and blue). By the way if you click on the NPC link in the encounter (circled in blue) the same NPC details are brought up as shown in the left portion of the screenshot.
Untitled2.png

So why is this important? If I, as the GM, have gone through the trouble of providing a non-ID'ed name for my NPC, e.g. "Big Red Lizard", I don't want a shared encounter revealing to my players that it is an "Inferno Breathing Iguana".

[Andraax]

Why are you sharing encounters?

[Minty23185Fresh]

Why are you sharing encounters?

I tried to "pre-address" this question in my discussion above (alas, without success).
"I'm not sure why one might do this, but I can, so it should behave properly."

[Trenloe]

Yeah, what Andraax says. Whereas it’s possible to share encounters, they aren’t designed to be shared - there’s little players can do with it and, as you report, there is no indentification control over the NPC name displayed in the encounter window.

[Minty23185Fresh]

I noticed another thing. Which presents a paradox. If I uncheck the ID flag in the encounter, the NPC remains unidentified in the NPC records library. Which might be okay, or might not. Seems as though, if the DM IDs the creature in the encounter, possibly the NPC should be ID'ed globally. And then there's this whole shared NPC/encounter thing....

[Minty23185Fresh]

....it’s possible to share encounters, they aren’t designed to be shared....

Okay, fair enough... I can live with this. If a DM is crazy enough to do this then it is at his/her own peril....

[Trenloe]

I noticed another thing. Which presents a paradox. If I uncheck the ID flag in the encounter, the NPC remains unidentified in the NPC records library. Which might be okay, or might not. Seems as though, if the DM IDs the creature in the encounter, possibly the NPC should be ID'ed globally.

You wouldn’t want to ID a NPC globally from a single encounter that the NPC record is linked to.

Encounters are designed to pre-stage NPCs that will be added to the combat tracker. They do not change the original NPC data. The ID button purely means the ID state that the NPC will be in after being added to the combat tracker (and map) when the encounter is deployed.

[Minty23185Fresh]

You wouldn’t want to ID a NPC globally from a single encounter that the NPC record is linked to.

Encounters are designed to pre-stage NPCs that will be added to the combat tracker. They do not change the original NPC data. The ID button purely means the ID state that the NPC will be in after being added to the combat tracker (and map) when the encounter is deployed.

Excellent. Thank you. I'm adding support for the ID fields in the Field Filters for All Libraries Extension and got a little bit of tunnel vision there. I am trying to decide what data to populate the filters with, based on the ID field value. I noticed encounters could be shared (which surprised me) and noticed the inconsistency so I reported it.

I still have a bit of a quandary. If encounters are shared by a DM, for whatever reason, because they can be, I need to prepopulate the drop down filter values so as not to reveal data to the player that the DM is attempting to keep to herself/himself (via the ID field).

[Andraax]

I don't think you should worry about it too much. A GM sharing an encounter would be like the "table top" version of the GM handing his notes on the current adventure to the players. If the GM isn't worried about the players seeing it, then it's not a big deal.

[Minty23185Fresh]

I don't think you should worry about it too much. A GM sharing an encounter would be like the "table top" version of the GM handing his notes on the current adventure to the players. If the GM isn't worried about the players seeing it, then it's not a big deal.

Excellent example thanks. My example on the other hand is poor. Items would provide a better example. A shared item that is wonderous but unidentified and has a huge value that shows up in the drop down or allows searching of the description field would be poor form on my part.

But all-in-all, thanks guys for getting me back on track.