Having Ideal Player Fog-of War

[webdove]

Have you tried if you have party vision option off, you can just add the PV token to Party Vision via right mouse each time you add it to a map. Therefore you only have to deal with one token, not all the others.

I have been trying to achieve ideal group FoW and memory of the map with Party Vision and Movement disabled so players do not see in real-time through each others eyes (like the Borg) and I don't have to keep removing characters from Party Vision when they spontaneously pop into Party Vision.

I have a non-client PC called PV who will hold the shared memory of the map. The GM has to move PV since Party Movement is off. I cannot have PV owned by a client for complicated reasons that I have been talking to SilentRuin about. Some of the extensions that I use must be replacing character tokeninstances which is deleting their associated FoW image data.

I need the FoW data for PV preserved while PV is in Party Vision so the players retain a memory of the map.

It appears that PV's FoW image data when PV is in Party Vision is held in a separate object from the FoW image data for PV when PV is out of Party Vision.

My experiment:
Party Vision and Movement is turned off in settings.

Experiment 1.
I add PV to the Combat Tracker, the map and to Party Vision.
I move PV around the map to collect FoW image memory for PV.
This populates PV's "Party Vision FoW image data" which clients can view even though the clients are not in Party Vision.
If I remove PV from Party Vision, clients lose their view of PV's "Party Vision FoW image data". If I add PV back into Party Vision then the clients regain their view of PV's "Party Vision FoW image data".

The above FGU behavior makes sense and provides a workable means of sharing a map memory without giving clients "Borg Vision".

Experiment 2.
I remove PV from the CT to wipe PV's FoW image data.
I add PV to the Combat Tracker and to the map, but I do not add PV to Party Vision.
I move PV around the map to collect FoW image memory for PV.
This populates PV's "non Party Vision FoW image data" which clients cannot view since nobody is in Party Vision.
If I select PV as the GM, PV can see his own memorized FoW image data.
If I add PV to Party Vision other clients still cannot see the FoW image data that PV just collected.

Apparently PV's collected FoW image data is recorded differently if PV was in Party Vision when the recording occurred that if PV was not.
If PV has FoW image data recorded while in Party Vision, that data is shared with clients when PV is added to Party Vision.
If PV does not have FoW image data recorded while in Party Vision then no data is shared with clients when PV is added to Party Vision.

Experiment 3.
I recorded FoW image data from part of the map while PV was in Party Vision and recorded FoW image data from another part of the map while PV was not in Party Vision.
Only the FoW image data which was recorded while PV was in Party Vision can be viewed by clients when PV is put into Party Vision.

So it appears that there are two separate FoW image data recording structures for PV's tokeninstance. One for Party Vision data and one for non Party Vision data.

This approach that I have developed does almost everything I need except for one thing.
I would like to be able to have PV controlled by players.
A. The players cannot "own" PV since that causes any extension like "Assistant GM" (which recreates token instances) to wipe the FoW image data for PV.
B. I don't want to enable Party Vision and Movement since then I constantly have to remove characters from Party Vision.

Ideally if FGU would provide separate settings for Party Vision and for Party Movement I would achieve FoW perfection :)

[LordEntrails]

Hope you don't mind. I moved this to a thread all it's own as I thought it was valuable enough to have it's own discussion and for future reference (it will no doubt get lost in the fog of How To in the original thread. Note that you can use the link of the quotes text to see where it came from etc.

[webdove]

Thank you. That is most helpful.

Because of my discussions with SilentRuin about the incompatibility between Assistant GM and Party Vision I became curious about what was happening in the software.

Do you know if I am correct that there are two different image memories for each tokeninstance, one for Party Vision sharing and one that is private?

(This next part probably belongs back in "How do I ???", but I will write it here for my convenience and move it later depending on your response.)
As I try to learn the FGU software framework enough to write my DMGX/5E extension I have come to the following conclusions.
The refdoc document describes a base software framework of objects and methods for FGU. The documentation there is maintained.
The CoreRPG ruleset implements many basic d&d objects and methods. It has no documentation besides the code.
The 5E ruleset implements specific 5E objects and methods and wrappers to CoreRPG objects and methods. It has no documentation besides the code.
Extensions implement additional objects and methods on top of CoreRPG and 5E to enhance the user experience or implement additional 5E functions.

In implementing the DMGX/5E extension my best hope of understanding the task is to find an existing extension that adds or changes a modifier to damage (like DMG: 2) so I learn what to do in initialization and the function and precedence of any method wrapping that I need.
I have as yet failed to find that extension.

I do have the 2E code from Celestian, but it does not help me understand what I need to do during initialization (like modifications to the arrays bonuscomps and targetableeffectcomps). Apparently I need to wrap modDamage() to both collect the modifier amount from DMGX: x and to apply that modifier to the roll and also wrap onDamageRoll() to print out the effect in chat.

Am I on the right track?

[SilentRuin]

This seems like a rehash of our whole conversation in the Assistant GM thread where I described what causes FoW to be lost and why that is. I think its relevant you include the Moon Wizard quotes I gave you in there also in here for context.


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.


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 as we discussed - FoW (Fog of War history of what was previously seen) is fragile by its very nature in FGU. Short of a complete redesign your not going to see this occur as your asking in being able to control FoW outside of the Engine code.

Personally, I think FoW visual history is a cheat for the players. In the old days we made them map the places on pure words alone. While I would not go back to that way of doing things - I am quite OK with FoW being lost occasionally.

Here is my game theory on that:

Player: "Hey my past sight of other places is gone?"

Me: "Game showing that your character forgot that clear precise vision of what you have seen. Now you have just your memory."

As you would. In life.

As far as Part Vision and what its doing? No clue. But the above is for full context in that previous conversation.

[webdove]

I still believe there is an evolving FoW image data structure that exists at both the client and the GM for presenting the appearance of FoW for each tokeninstance.
I believe there is a link from each tokeninstance to this structure.
To link that existing FoW image data structure to a new tokeninstance should not require the passing of any floating point FoW data through the API since the FoW image data structure is not being modified or transferred anywhere.

[SilentRuin]

I still believe there is an evolving FoW image data structure that exists at both the client and the GM for presenting the appearance of FoW for each tokeninstance.
I believe there is a link from each tokeninstance to this structure.
To link that existing FoW image data structure to a new tokeninstance should not require the passing of any floating point FoW data through the API since the FoW image data structure is not being modified or transferred anywhere.

According to Moon Wizard the tokeninstance is the only thing with a link to that map data structure.

And while it would be nice to be able to pass a tokeninstance FoW to a new copy of it - that is not something they provide. As Moon stated in my quotes from him - because the data structure is much to big to be transferred anywhere. While I agree you'd think it was just a pointer that could be passed into the new tokeninstance - its something I will never see as its all in the ENGINE level of the code - which we only will ever have access through API's they share with us.

The thing about coding in FGU is that you will find lots of things you can't do - that you have to be inventive in your coding to accomplish. At least as close as you can anyway. But some things - like what we discussed on FoW is out of our control completely. It gets confused more when you state Party Vision as having anything to do with anything at all.

It's tokeninstance. And due to restrictions on how ownership of these is given access to use through the API it can only have the ownership of the CT reassigned by recreating the tokeninstance itself. At least as far as I've found. And anything - my extensions - other FGU operations as you've pointed out - or user actions - can change that tokeninstance and lose that FoW history.

It would take a redesign on SW's part to change this. And I get the impression FoW history can be blown away by lots of things - i.e. fragile. But trying to tie it to Party Vision as if that is a "thing" is wrong. Its tokeninstance and anything that might change it that can lose the FoW. That of course, is a lot of things.

So if you really want some action on this you'll have to reform the request your making. I think what you want is a way to have the FoW preserved when a tokeninstance is changed but remains on the same map. I mean that is the ONLY way anything your asking for here would work. If its being deleted, moved to another map, then its gone no matter what.

[Caveat: as I understand things - which of course could be wrong.]

[SilentRuin]

Also when talking and describing your steps and what you want you should always have every extension disabled. That way its RAW FGU your showing it happen with.

[kevininrussia]

Personally, I think FoW visual history is a cheat for the players. In the old days we made them map the places on pure words alone. While I would not go back to that way of doing things - I am quite OK with FoW being lost occasionally.

.

I'm hoping the designers give an option to turn off Fog of War history.

[EllivasKram]

I'm confused why PC's being able to view through each others token is a problem.

It's part of the game to be able to see the map and all tokens as a Human Player in top down God view..

Or if using 'Theatre of the Mind' then the action is open to all to visualise.

I find LOS history being lost is a pain for my players.. Which your PV token can resolve.. But the thought in DoTMM of having 20+ PV tokens (One for each Map) is painful.. to retain LOS History.

But I tend to use LOS on the current MAP and MASK mode on previous maps - If they didn't explore fully the level..

It would be good if there was a 'LOS MASK' to in effect turn off LOS for explored area's.. while retaining LOS on unexplored parts of Maps maybe..

[MrDDT]

I'm hoping the designers give an option to turn off Fog of War history.

Can't you right click the token and remove it at any time?

[MrDDT]

I'm with SilentRuin, I think PV token is not needed and FOW is ok enough. The only issue I come across is other EXTs that I like to use (Exampel Portals) and you lose that FOW. But even still I think FOW is not a major issue because again players have their own memories which should be good enough as if they were the character.

[kevininrussia]

Can't you right click the token and remove it at any time?

Fog of War History (the darkened map area of previously seen areas). The point is my players want to map out their travels so they would rather not have the LOS history. I don't think its reasonable for me to continually right click 6 tokens every turn to remove their LOS history.

So, an option to turn it off would be nice.

[MrDDT]

Yeah, I think that would be kinda cool.

[webdove]

I'm confused why PC's being able to view through each others token is a problem.

It's part of the game to be able to see the map and all tokens as a Human Player in top down God view..

Or if using 'Theatre of the Mind' then the action is open to all to visualize.


FoW and map masking are new features to D&D play enabled by the use of computers. They increase player "immersion" (being in the shoes of the characters) in the same way that Syrinscape sounds do. The lack of full understanding of the map leads players to use their characters' imagination to visualize what the characters cannot see rather than players using their "DM imagination" to "unvisualize" things that they should not know (my players are not high on the "self restraint" scale and are high on the "minmax" scale).


I find LOS history being lost is a pain for my players.. Which your PV token can resolve.. But the thought in DoTMM of having 20+ PV tokens (One for each Map) is painful.. to retain LOS History.

But I tend to use LOS on the current MAP and MASK mode on previous maps - If they didn't explore fully the level..

It would be good if there was a 'LOS MASK' to in effect turn off LOS for explored area's.. while retaining LOS on unexplored parts of Maps maybe..

(These are purely my hypotheses from experiments as I have not found any FoW documentation or tokeninstance code)

FoW (map memory) is only retained if the character tokeninstance exists and the two FoW image data structures (one for Party Vision, one for Private Vision) attached to the tokeninstance are retained or relinked to any recreated tokeninstance (in my view relinking FoW is free, copying FoW is unnecessary. However, SilentRuin asserts that either the tokeninstance or the FoW links to it are not accessible at this time to extension writers.).

The tokeninstance is a structure that holds the dynamically evolving state of any token during exploration and combat. I do have separate PV characters for each level included in the Party Vision List to retain shared map memory, but I have learned that if you remove them from the CT then the FoW image data for them is lost (because the tokeninstance is destroyed). So you need to keep all PVbylevel character tokeninstances for the map memory to be preserved. As you observed, if they are also in the CT that would result in an increasing processing burden for CT activities.

However, I suspect that if you use SilentRuin's "Combat Groups" extension, put all the PVbylevel CT entries in a PV Combat Group except for the PVlevel character for the currently active map and then make that PV Combat Group not visible then all the inactive PVbylevel tokeninstances will no longer be linked to the CT and will no longer cause the painful CT processing burden that you speak of.

Ideally, FGU would provide a button that translates all Party Vision FoW into a map mask. Then it would no longer be necessary to preserve PVbylevel character token instances because the information would then exist in the map mask for that map.

Alternatively FGU could provide a setting that would automatically add all map exposure that is revealed by characters that are included in the Party Vision list into the map mask for that map. Then anytime you switch to mask mode you will see all the map areas that were revealed by characters that were in the Party Vision List at the time without having to do anything special. That map mask would automatically be preserved with its map even if all of the characters were removed from the Combat Tracker thereby deleting all the character tokeninstances and that map was closed (I believe that masks are preserved if a map is closed and reopened.

[webdove]

Fog of War History (the darkened map area of previously seen areas). The point is my players want to map out their travels so they would rather not have the LOS history. I don't think its reasonable for me to continually right click 6 tokens every turn to remove their LOS history.

So, an option to turn it off would be nice.

I can understand your players interest in a "no FoW history" setting.

[LordEntrails]

Interesting discussion and I think it helps highlight just some of the challenging decisions the devs have had to make. As you can see, there are lots of different use cases, and lots of different preferences.

I will add my opinion on FoW history in terms of the players needing to remember where they have been or make their own maps. I get it, and have run games (some with FG) doing that. But I also understand the realities of life and that this is a game. It could easily be 2 or 3 months between game sessions, and yet only a few minutes for the characters. Expecting the players to remember what the characters remember is, to me, a poor stance. Part of RPGs is pretending to be someone you are not. Different skills, abilities, history, and yes, different memory skills. Same reason I don't like player puzzles/riddles/challenges in my game, because those are reliant upon the player, and not the character.

But, each to their own :)

[kevininrussia]

I get why people would want to have the Fog of War history. I think most do want it. That's why I was hoping for an option to turn it ON or OFF with default ON.

In the The Laboratory forum there was discussion about the brightness of the Fog of War history. Moon mentioned they would brighten it up some as some thought it was too dark. I would imagine there would be an ability to turn it off too.

About the FOW brightness, I don't envy Moon on this. I started my carrier as a visual effects artist with directors peering over my shoulder saying "a little less, a little less, ok now a little more, no a little less" I learned it was best to give them the mouse and go take a snack break. :-)

[webdove]

Interesting discussion and I think it helps highlight just some of the challenging decisions the devs have had to make. As you can see, there are lots of different use cases, and lots of different preferences.

I will add my opinion on FoW history in terms of the players needing to remember where they have been or make their own maps. I get it, and have run games (some with FG) doing that. But I also understand the realities of life and that this is a game. It could easily be 2 or 3 months between game sessions, and yet only a few minutes for the characters. Expecting the players to remember what the characters remember is, to me, a poor stance. Part of RPGs is pretending to be someone you are not. Different skills, abilities, history, and yes, different memory skills. Same reason I don't like player puzzles/riddles/challenges in my game, because those are reliant upon the player, and not the character.

But, each to their own :)

I concur.