Assistant GM Extension (Fantasy Grounds Unity 5E Ruleset)

[webdove]

Yes I understood that granting assistant would replace a CT entry. I imagined that it would only affect the CT memory of the PC that was granted Assistant status.

What I had not realized is that just having the Assistant module loaded without changing any granting of assistant GM or modifying any Assistant GM settings wipes all Party Vision for all characters.

Thus even your suggestion "If you have an Assistant GM to run NPCs for you grant them access and leave it alone forever." will still result in wiped party vision the next time the game is loaded. That was in fact the experiment that I performed.

I am not being critical, I am just observing that Party Vision and Assistant GM are incompatible.

[SilentRuin]

Yes I understood that granting assistant would replace a CT entry. I imagined that it would only affect the CT memory of the PC that was granted Assistant status.

What I had not realized is that just having the Assistant module loaded without changing any granting of assistant GM or modifying any Assistant GM settings wipes all Party Vision for all characters.

Thus even your suggestion "If you have an Assistant GM to run NPCs for you grant them access and leave it alone forever." will still result in wiped party vision the next time the game is loaded. That was in fact the experiment that I performed.

I am not being critical, I am just observing that Party Vision and Assistant GM are incompatible.

Its how FGU works. If LOS data is tied to the CT entry - any removal of it will result in its loss. Not anything I'm going to manage as LOS data is notoriously tricky even for them. Its not party vision. Its the CT entry's individual recording of its LOS data.

I'm going to ask an expert to make sure my world view on the way FGU works with history data is correct - remove CT entry or change its map and the LOS history data is lost. If I can get that theory validated - I will come back and double down on this not being anything to do with party vision or anything else but what I've said it is. If not - I'll tell you what I found out.

[SilentRuin]

Ok this is according to Moon Wizard:

Token history is tied to a “tokeninstance”; which at the API level is part of an image value. FoW is tied to a tokeninstance. Therefore, since FoW is only relevant to the image value that the tokeninstance is part of; then there is no mechanism to track a historical FoW since the FoW data is only relevant to the current image. Plus, it would get huge data wise.
This is completely independent of the CT; which only saves a “link” to a tokeninstance using a image data path and token ID.
When a token is added/deleted; the CoreRPG code checks this “token link” to see if it is “linked” to a CT entry for actions, decorations, etc.

FoW data is huge; since it’s actually a geometric Boolean of all visible regions.
Plus, there is no where to store this information right now; and it could be a problem that additional database checks would need to be added for every image database node to know when images deleted in order to remove the token data to prevent crashes later.

So every time CT entry gets updated by AssistantGM and the tokeninstance gets copied to the new entry the FoW data is lost.

Nothing to do with party vision. Nothing to do with anything except the replacement of the CT window list and the data within it - which is mostly copied.

I asked to make sure there was no way to get this data when replacing a tokeninstance (which I do in several of my extensions not just this one - so do others I'm sure) and got this answer from Moon...

No; there is no way to retrieve this data; and even if we did; it would be a lot of data to pass through an API. Hundreds of points defined in floating point variables.

So, doubling down on my answer. This is how FGU works. If you want to use Assistant GM - or some of the other extensions that replace or update a tokeninstance? You will lose the FoW data. Like I said - its fragile data useful while in one map for one run. Though if you stay on that one map that history will still be there as long as nothing changes to that tokeninstance. And if your using Assistant GM for that player - it will.

And just went to the trouble of trying to not copy the tokeninstance and got a nasty reminder of why I had to copy it in the first place. Its the only way to inherit the new ownership from the CT entry. Hence, it is what it is and that's the way it has to be to work. If you want to preserve your FoW - do not grant access to Assistant GM - though that will only interfere with it after you start a new session or switch it back your FoW will be there for the time in between - do not change the tokeninstance in normal FGU by switching maps, removing the CT entry (which removes the tokeninstance) and probably a bunch of other ways in FGU and with other extensions.

[webdove]

So to gain control of a tokeninstance which contains its own FoW data you must construct a new one which has no FoW data.
Odd that it seems to be erasing all FoW data even though I have not activated Assistant on anything. Perhaps the client preemptively recreates all the tokeninstances when the client opens the CT?

Moon says: "the FoW data is only relevant to the current image" I parse that as: "the record of current (white) and memorized (gray) map appearance only pertains to the tokeninstance's current containing image (picture of the map)".
That is perfectly sensible.

He avoids maintaining a FoW history, but there is no need for historical FoW data here only current data not being lost.

The only way this could work is if you could create a new tokeninstance for so you inherit ownership (as you currently do) and then copy the linkage from the old tokeninstance to its FoW and transplant that copy into the new tokeninstance so it now has proper FoW to match the old tokeninstance then delete the old tokeninstance. You would now have a properly owned tokeninstance with the correct current FoW image data attached.

That does sound tricky though. It would require you to find the FoW structure attached to the old tokeninstance and I have been searching corerpg, 5E and refdoc and can find no reference to {LOS Sight Line-of-sight} anywhere. Perhaps Moon knows where it is hidden.

Thanks very much for helping me learn. I am working to convert Celestian's 2E DMGX code to 5E with an extension (having last written lisp code decades ago) and learning all of this is a real challenge without an overall explanatory document for all the classes, attributes, methods and their relationships.

[SilentRuin]

Honestly I've explained as best I can. If you have Assistant GM active for the player it will wipe out the FoW due to the fact it has to update the CT to be different from the default and apply ownerships. All your doing is describing the exact same thing I've described already. This will happen when you open the CT when active for first time - or when its up and you grant access on or off. If active. Its for the reasons I stated. I'm not sure what you mean by "preemptive" - if its active it HAS to update the CT which involves updating all the relevant entries and thus all the tokeninstances. As I've stated - again.

And yes I tested that the FoW is still there after the session restarts if the Assistant GM for that user is not active. It was still there.

[webdove]

You were right that some other extensions may be updating token instances and erasing FoW data. I saw it happen if my PV PC had a set of map FoW in Party Vision and I used the GM to flip PV out of and back into Party Vision. That wiped the Party Vision memory.

The workaround that I have found is if I never login a client in control of the PV character that I include in Party Vision. With that restriction I can keep all my extensions loaded (several are yours) and the PV token never loses its Party Vision memory of the map. I had been logging in as the PV client using my localhost connection when I was talking with you before.

Again, thanks for your help.

[vaughnlannister]

Hi, a small thing that annoys me somewhat as DM is that my players aren't able to drag their player token from the Combat Tracker onto the map, is that something that they would be able to do with assistant GM ? Thanks!

[SilentRuin]

Hi, a small thing that annoys me somewhat as DM is that my players aren't able to drag their player token from the Combat Tracker onto the map, is that something that they would be able to do with assistant GM ? Thanks!

No that is FGU behavior which I happen to agree with. Last thing one needs is a bunch of players screwing with the map by simply moving locked tokens to where ever they like simply by dragging into a new position. I'm not going to provide that and I hope they never allow it also!

[vaughnlannister]

Ok, yes that would be really bad , though you could use masking :P, and only reveal the area their allowed to drag them, though then you would have to remove the mask again XD, so ummh more clicks lol, if you use the green icon at the bottom of the Combat Tracker, its just on click-drag anyway . I'm always looking for little tweaks that give me less clicks during a sessions , for instance, would a feature that allows to auto-share a map with the players, after you've dragged them onto the map something you would be interested in?

[SilentRuin]

Ok, yes that would be really bad , though you could use masking :P, and only reveal the area their allowed to drag them, though then you would have to remove the mask again XD, so ummh more clicks lol, if you use the green icon at the bottom of the Combat Tracker, its just on click-drag anyway . I'm always looking for little tweaks that give me less clicks during a sessions , for instance, would a feature that allows to auto-share a map with the players, after you've dragged them onto the map something you would be interested in?

To many variables. People will not be ready to "share" a map right away without doing some prep work first in some cases right before they hand it out. I would not want to automate that - especially when lighting comes around.