PDA

View Full Version : Dissimilar Modules



Nickademus
November 12th, 2013, 23:02
I'm curious how FG handles different versions of a (library) module between the host and the players.

Hypothetical:
* GM creates module XYZ and gives it to the players.
* Players download and place the modules in their modules directory for FG.
* GM changes the contents of the module but keeps the same name XYZ, categoryname, author and ruleset in the xml files.
* GM hosts a session.
* Players log in.

Now, which version of XYZ is the GM going to see and which version are the players going to see? Or does FG notice the file size is different and treat them as separate library modules?

Trenloe
November 12th, 2013, 23:35
If the module is set as "client" (client.xml in the module itself) then the player needs it installed locally and will use the local copy.

If the module is shared (common.xml) it will download the data for latest version from the GM.

Nickademus
November 12th, 2013, 23:47
And if it is both? Will it download the common.xml data as an encrypted campaign file and leave the client.xml alone for the player?

Moon Wizard
November 12th, 2013, 23:49
If have to look at the code to be sure, but that will be changing for v3.

In v3, the checksum of each file in the module in the player side will be checked, and the each file will be downloaded if it doesn't match.

Regards,
JPG

Trenloe
November 12th, 2013, 23:53
I do not believe so. It will see that the player has a client.xml file and will use that - it won't even try to use the shared common.xml model.

Try it out - connect a local player instance of FG to a GM instance and see if the player cache directory creates a .dat file with the name of the module, which is what it will do if it is downloading data as part of the "shared" functionality. I'm pretty sure it won't...

Nickademus
November 12th, 2013, 23:59
It's hard for me to test modules since I only have the one computer and thus both the GM and Player clients pull from the same list of modules.

Hmmm. I'll have to see how v3.0 handles the legals.

Nickademus
November 16th, 2013, 23:15
I am unable to access my module as a player now.

I'm wondering what value FG uses to compare the host and player's files. I changed the name and the category name of the file in an attempt to make the library module a different file in FG. Now I'm in a game and my versions are not listed for activation, but the originals are shown from the GM. I could have sworn that I was able to request permission to open my modules in a game where the GM didn't have them before. So I can only think there is a conflict between the old and new version of the module (which should be considered two different modules in theory).

Sorry if this makes no sense. Typing while gaming...

Moon Wizard
November 17th, 2013, 04:59
Only modules available on the host and permission granted by GM can be accessed by players. Local installation does not grant access.

For v2.9.4, the module needs to be either common or client to share, and must be installed on both if client.

For v3 beta, any module can be shared by GM. Local installation only determines whether files downloaded or not.

Regards,
JPG

damned
November 17th, 2013, 06:37
For v3 beta, any module can be shared by GM. Local installation only determines whether files downloaded or not.

I was curious about this wrt to C&C. with v3 (once we resolved my client side module issues) the players could access C&C PHB even if they didnt have a license.
I was wondering if it was a licensing change or an oversight. Now I know - its deliberate - but only temporary.

Im working on my players... most are using demo licenses... Im even considering bribing them - if they buy a lite or better i'll buy them C&C...

Nickademus
November 17th, 2013, 09:21
Only modules available on the host and permission granted by GM can be accessed by players. Local installation does not grant access.

Seems odd me asking the developer this, but are you sure? I've gotten access to my local modules in a game where the GM had never heard of the module. In a discussion about this with Trenloe, I was able to reproduce this for him to experience. Going to work now and don't have time to dig into the details though.

Valarian
November 17th, 2013, 09:42
Seems odd me asking the developer this, but are you sure? I've gotten access to my local modules in a game where the GM had never heard of the module. In a discussion about this with Trenloe, I was able to reproduce this for him to experience. Going to work now and don't have time to dig into the details though.
I think this is only if you, as a player, also have a Full or Ultimate license. That seems to override the module selection from the host.

damned
November 17th, 2013, 10:55
hmmm - if you have modules that the GM is not aware of im not sure they can block you?

Moon Wizard
November 17th, 2013, 16:47
Not completely positive, since I haven't looked at in a while and I am out of town without access to computer this weekend.

Local modules might load up. However, GM controls permissions of any modules they have installed for sure.

Seems like the way it should be if it's not. GM controls which books get used in a campaign.

JPG

Nickademus
November 17th, 2013, 17:43
Upon thinking on this, I believe it is/was a case of the xml type. I remember seeing the local module grayed out with a closed book. I had to open the book and get the GM to accept it, so it was still within the GM's control. What I think the difference was is that I changed the base file from client.xml to common.xml.

It could be that only local client.xml files show up as a player since I think common.xml is more for a GM to share. That's my theory thus far. I'll duplicate the common.xml with a client.xml and see if I encounter this problem next week.

Griogre
November 18th, 2013, 10:05
I believe Nickademus is correct, a client can request the GM allow any client module be opened if the module is marked as compatible with the current ruleset. It sends a message to chat saying something about a player is requesting permission to open such and such a module. The GM goes into the module activation window and then checks the module if he wants to allow it. If he doesn't want to allow the module you just do nothing and the module doesn't open on the client.