Ruleset Token Bag? And another thing...

[wmsmitty]

So, as a GM, great to have a variety of Tokens to represent your NPC's. But I'm finding that as a player, it makes no sense to buy or even create my own token, because I can't use it when playing on another GM's server. And, for some reason, if a GM has bought a character token pack, he/she can't share it with the players. So what is the point in creating player tokens or buying them if nobody can use them?! Let me take that back a bit; yes, I know a GM can at least share created tokens; just can't share commercially bought token sets.

I'm finding that buying 3rd party commercial products has SERIOUS limitations in use. Can't copy a map from a map pack over to a new module, can't share token packs with the players. I think I'm done buying 3rd party products. I buy it, I own it. I should be able to use it as I please with FG.

Another question, why do I see an empty Ruleset token bag? I get this token bag every time; even when creating a new module. What is its purpose?

Loving the software, but this token stuff and 3rd party limited usage is getting to be a bit annoying! I'm hoping that I'm overlooking something basic here.

Thanks

[damned]

Hi wmsmitty

The token and portrait architecture was an early design decision that makes less sense today but is not trivial to unwind all its dependencies.
I believe that this is likely to change in the new engine rewrite but not before.

In regards to images in modules - the majority of new products are released as secured/encrypted products with the agreement of the authors / ip-owners - they prefer to have their products protected.
Not all content producers choose to protect their products but it seems that most choose this option if it is available.

[Zacchaeus]

It isn't a good idea to share tokens since they take up too much memory. The DM can allocate any token they own to a player. If the DM wants to give the player a choice of token then the best idea is to open the token bag as large as possible, display all the tokens and send a screenshot to the players.

You should be able to open a map pack in any campaign and use the map in that campaign.

[Trenloe]

The empty ruleset token bag is not actually empty. There are two completely transparent tokens in there, which you can’t see or select as they’re transparent. These are used by some rulesets and extensions as anchors for graphics placement on images.

And, as far as player tokens are concerned - if you’re talking about PC portraits, which can be used as PC tokens, then the player does have access to their own portraits on their computer when they are in a GMs game. Or are you talking about just generic tokens to add to the map?

[wmsmitty]

Hi wmsmitty

The token and portrait architecture was an early design decision that makes less sense today but is not trivial to unwind all its dependencies.
I believe that this is likely to change in the new engine rewrite but not before.

Ok, perfectly understand that.

In regards to images in modules - the majority of new products are released as secured/encrypted products with the agreement of the authors / ip-owners - they prefer to have their products protected.
Not all content producers choose to protect their products but it seems that most choose this option if it is available.

Well, with such an option these retailers have lost me as a buyer -- obviously that's just me. Just don't believe in the model. It's like I don't really own the product. Thanks for the response.

[wmsmitty]

It isn't a good idea to share tokens since they take up too much memory.

That's developer talk; tokens don't have to take up so much memory as to slow things down, do they? But, ok...so the decision is not to share these resources. Then an alternative would be to allow the client to pick his token and have it placed/uploaded to the GM's campaign token directory when connected. Would that not work?

The DM can allocate any token they own to a player.

Interesting! Is this as simple as dragging the token onto the character sheet? I'll try it next time.

You should be able to open a map pack in any campaign and use the map in that campaign.

Yes, you can do that. Obviously. What I want to do is use a certain map to use in my own developed module. I like working with clean modules. I don't like having them polluted with a bunch of files I"m not using.Makes running the game it bit more difficult having to filter through a bunch of unwanted files and information. I tend to close out out modules when creating a module -- clean slate.

For the map packs; I'm ending up taking screen shots to port them over into a clean module as a work around.

[wmsmitty]

The empty ruleset token bag is not actually empty. There are two completely transparent tokens in there, which you can’t see or select as they’re transparent. These are used by some rulesets and extensions as anchors for graphics placement on images.

This makes me feel better. At least to know that there is a purpose for this. Just the same, why bother exposing this to the end user? If this content is meant to act as a place holder or anchor, you should be able to do that without having to publicly expose the bag. Doing so begs the question that I originally asked. Can't you treat these things as hidden fields until a time in which they need to be exposed?

[Zacchaeus]

The way FG works is that the DM hosts and the clients get everything from the DMs machine. So everything has to be downloaded from the DM to the client in order for the player to gain access. Tokens are .png files which, although they are relatively small, can and do take up more memory that .jpg files. And especially if you share a ton of tokens you will have long download times and it will eat memory client side. All graphics on the client side are loaded into memory in an uncompressed format. So, for example, the PHB might only use a couple of hundred Mb DM side but for the players that's going to run up about 1.2Gb of memory. Since FG can only utilise about 3Gb of memory on a 64bit machine that's a lot. So, it is not developer talk it is the reality of the current architecture.

And yes, the DM can simply drag any token into the token slot on the character sheet.

[wmsmitty]

The way FG works is that the DM hosts and the clients get everything from the DMs machine. So everything has to be downloaded from the DM to the client in order for the player to gain access. Tokens are .png files which, although they are relatively small, can and do take up more memory that .jpg files. And especially if you share a ton of tokens you will have long download times and it will eat memory client side. All graphics on the client side are loaded into memory in an uncompressed format. So, for example, the PHB might only use a couple of hundred Mb DM side but for the players that's going to run up about 1.2Gb of memory. Since FG can only utilise about 3Gb of memory on a 64bit machine that's a lot. So, it is not developer talk it is the reality of the current architecture.

Thanks for the explanation. For the record, wasn't trying to be sarcastic. I just think there is a better way to implement the token feature than what the current architecture uses. So if this is the current case, so be it. Perhaps the design will be revisited in the new FG design. That is my developer's mind speaking.

[LordEntrails]

Thanks for the explanation. For the record, wasn't trying to be sarcastic. I just think there is a better way to implement the token feature than what the current architecture uses. So if this is the current case, so be it. Perhaps the design will be revisited in the new FG design. That is my developer's mind speaking.

Yep, everyone knows their is a better way to architect tokens and portraits. It's a common discussion when someone new with a software background gets involved in diving into the details But it's what we have today and why Damned said;

...
The token and portrait architecture was an early design decision that makes less sense today but is not trivial to unwind all its dependencies.
I believe that this is likely to change in the new engine rewrite but not before.....