Library Activation - Player side

[ldyparadox99]

Today the BF and I have been going through learning FG2 (I've been working on a new ruleset) and it came time to enter his spells. I have the spell book set so players can open it, however, when he tries to open it the book just snaps shut again. And the cobweb that indicated on the GM version that a image was pre-loaded is also in the lower left hand corner.

Any idea what I'm doing wrong? It of course works perfect on my version.

TIA!

[ldyparadox99]

I think I answered my own question, but I don't think it's right...

Basically I have to make sure my eqd20spells.mod is on every player's computer in order for them to see it vs. it uploading from mine to theirs.

[nezzir]

Yeah, I think that's what I've found too. There was a discussion about it in the healing forums but the answer wasn't 100% clear (to me).

There are 3 types of files, db.xml, client.xml, and common.xml. Most .mods are db.xml and client.xml. My initial understanding was that if the file was named common.xml that is was accessible via remote, but that doesn't seem to be the case.

I'd like to get a clear answer on what each of these files types are and how they affect access.

[Griogre]

Did you see this (https://www.fantasygrounds.com/forums/showpost.php?p=40254&postcount=7) post by Goblin-King? Try exporting with the "S" variant to see what appears in the mod file. I think there may have been an earlier post explaining a little more.

[ldyparadox99]

But that's meant to work for modules that you make within the program using the story book, correct??

I'm purely editing and modifying the existing d20spells.mod file (renamed into my ruleset, of course).

So if I'm understanding this correctly, those of us that make a ruleset with modules outside of the program will have to individually give each module to our players.

[Griogre]

All modules are the same under the hood, using the default export command does echo the entries to the story books. I'm not suggesting you export your EQ stuff that way - I'm just suggestion you quickly export an entry of two with the "S" so you can see what the "S" option database file name in the mod is.

Once you know that you can try renaming your EQ file to match. I believe Goblin-King said there were 3 or 4 file formats. I know of two: db.xml and client.xml. I'm guessing the others have unique names or maybe just tags too.

[ldyparadox99]

Ah ok, I get it.

I'll attempt that and report my findings. I think at this point it's safe to say the client files need to be manually put in by the player.

Update: I went and created every combination of module I could and none of them would load off the player client. They all indicated the streaming of information, but the books still snapped closed.

[sloejack]

I went and created every combination of module I could and none of them would load off the player client. They all indicated the streaming of information, but the books still snapped closed.

Based on my experience this is how it works (each player must have a copy of the module to be able to load it locally if allowed). In the grand scheme of things, I think this is probably for the best in the case of commercial offerings where you would want everyone who uses it to pay for it. Alternately for large projects that have DM and player specific stuff, hopefully they would allow a limited license allowing the DM to distribute the player module content to their players.

[Ram Tyr]

This post might be helpful to the discussion until Ged or Tero the Goblin King elect to provide a response to the discussion of this problem.

Ruleset Caching in FGII (https://forums.fantasygrounds.com/forums/showpost.php?p=38302&postcount=17) (post dated March 30, 2007)


Rulesets will be cached so that they are not playable without a GM who has the ruleset. Therefore they do not spread anymore by just connecting to a host.

Modules will be by default only for the GM and the fact that reference information can be included in modules does not change that. "By default" implies there are other possibilities too: in fact the modules of v2 may include host data, shared data and client data. Host data is only for the GM, the GM can allow the players to receive shared data, and client data is contained in modules clients have and the players may request for the GM to allow enabling them (the GM can naturally access his/her own client data).

The shared data are also cached and do not become available for the players outside the game session.

So, unless I entirely misunderstand the description, it was not intended that only those players that also own the module can access it during the game. The caching was meant to allow temporary access while connected to a GM with the module.

Later.

[Pikup]

Based on my experience this is how it works (each player must have a copy of the module to be able to load it locally if allowed). In the grand scheme of things, I think this is probably for the best in the case of commercial offerings where you would want everyone who uses it to pay for it. Alternately for large projects that have DM and player specific stuff, hopefully they would allow a limited license allowing the DM to distribute the player module content to their players.

Are you saying if I create my own module of herbalist potions etc I cannot allow my players to see/refernce this unless I mail it to them offline and teach them where to place it?

Pikup

[sloejack]

Are you saying if I create my own module of herbalist potions etc I cannot allow my players to see/refernce this unless I mail it to them offline and teach them where to place it?

Pikup

that's correct and the quote from Ged's posting above also states this, I'll requote for clarification:


Host data is only for the GM, the GM can allow the players to receive shared data, and client data is contained in modules clients have and the players may request for the GM to allow enabling them (the GM can naturally access his/her own client data).

This means that both DM and players must have the module, and that even though the players have the module the DM can control if they are able to open it in FG or not. With respect to shared data I believe this is referencing things like tokens, images (maps), and other objects that can be transfered from the DM to the players managed via the share radial option.

[ldyparadox99]

So, unless I entirely misunderstand the description, it was not intended that only those players that also own the module can access it during the game. The caching was meant to allow temporary access while connected to a GM with the module.

Later.

That's what I thought as well, especially for those of us creating rulesets for games that don't have OGL. While I know that none of my players are going to take what I created and share it with others, I still don't want to be passing this thing around.

[Griogre]

Slowjack, I think you missed the important part of Ged's post (bold added by me):

Rulesets will be cached so that they are not playable without a GM who has the ruleset. Therefore they do not spread anymore by just connecting to a host.

Modules will be by default only for the GM and the fact that reference information can be included in modules does not change that. "By default" implies there are other possibilities too: in fact the modules of v2 may include host data, shared data and client data. Host data is only for the GM, the GM can allow the players to receive shared data, and client data is contained in modules clients have and the players may request for the GM to allow enabling them (the GM can naturally access his/her own client data).

The shared data are also cached and do not become available for the players outside the game session.

If it's cached that means its being sent. When I have a second I'm going to rename a client.xml to share.xml and shared.xml. :p

[Griogre]

Thought I would mention that changing the client.xml to shared or share.xml didn't work. Think we need a developer to tell us how to do this.

[sloejack]

Slowjack, I think you missed the important part of Ged's post (bold added by me):

No, I didn't miss the important part. There are two points to the post, the first revolves around protecing IP of content, in this case rulesets, by caching the ruleset data. A module is not a ruleset. It may contain game rules, but it is not a ruleset, it is a module.

With modules there are three types of content that can exist independantly or in combination. db.xml (DM Only), client.xml (Player data, also visible by DM), and common.xml (shared data presumably passed on to players similar to ruleset information in a cached format when the module is activated).

To date, I have not seen this function properly, though to be honest, I'm focused more on conversion and adventure creation at the moment so I don't get to play as much as I would like.

[Griogre]

I'm kinda like you. I'm not really sure the common stuff works or not.

[Kalan]

I'm kinda like you. I'm not really sure the common stuff works or not.

Common doesn't work right now either - thus far, its as though FG sees "client" and "common" files like "db" files - ie: only accessible by the GM.

I really hope we can get this issue resolved soon...a lot of rulesets coming up will need this function working...