Creating and sharing Modules

[VenomousFiligree]

Can someone please clarify the differences between:

H - Host data
S - Common shared data
C - Client data

and how the Modul Activation tags:

Block from players
Allow for players
Force load for players

effects each?

Thanks

MB

[Tenian]

H = Host data = db,xml. These modules can only be opened by the host. The client does not even see an option for them in the module activation window.

S = Common shared data = common.xml. Modules built with this option are stored on the host and transferred to the client when they are needed (similar to the way maps, tokens, rulesets, etc are transferred). In my experience large common modules will choke off the transfer of other items (such as tokens and maps).

C = Client data = client.xml. Modules built with this option are available to the client but are not distributed via FGII. The client must have a copy of the module on their machine. These are normally distributed via FTP/email. The advantage of this type of module is you can transfer it while you are not playing (good if the module is large). The disadvantage is all your players have to keep the modules synced manually...which can be a challenge if you have some players who are not technically inclined.

Module activation:
H:
None of these settings matter

S:
Block from players = Players can not open the module.
Allow for Players = Players can open the module.
Force load for players = When a player connects the module is automatically loaded (and transferred)
Blank = When the player attempts to open it the host is sent a request message.

C:
Block from players = Players can not open the module.
Allow for Players = Players can open the module.
Force load for players = When a player connects the module is automatically loaded if present on the client machine.
Blank = When the player attempts to open it the host is sent a request message.


In short:
H is usually for host only materials (adventures, monster manuals, etc)
S and C hold the same type of content but the mechanism for getting that content to the players is different. S uses FGII to transfer the data, C requires some other means of transfer.

C is sometimes used to transfer map content over low speed connections (since the maps can be sent to the player in advance of the session). However, the module is just a renamed zip file, so players can easily explore it and view maps without any sort of masking. It can be very useful for large world maps, pictures of cities, and other "reference" content.

[VenomousFiligree]

Thank you :)

[Spyke]

Really good overview. Thanks Tenian.

Spyke

[Tenian]

I have a tad bit of experience with modules :)

[Foen]

BTW, a single .MOD file can contain more than one of these data types.

Foen

[Griogre]

Very true what Foen says - though there can be some oddities when the modules chare a common definition file. And you MUST force load common modules to actually get them to transfer unless this has changed recently. Is not enought to just check them.

[DNH]

I am always looking for ways to speed up my sessions and last week we had to wait a minute or so for map transfers a couple of times. What I want to do is the following, but I am unsure if it will work.

I already have my adventure in a module. This includes all the maps, tokens, items, story entries, encounters etc etc. I want to make a separate module containing all of the adventure's maps and send this to the players ahead of the session. FG2 would then "insta-load" the maps when I hit the Share command.
Only ... will that work properly if the two modules are not exactly the same? I mean, I already have a reference module (an atlas, really) that I use in this manner but it's the same module for me and the players. This adventure one wouldn't be.

Thanks.

[Tenian]

To do this, you would have to use the same module that the clients do for maps. I.e. you'd have to have both the Adventure and the atlas module open on the host. As the host you would have to open and share maps from the atlas module if you wanted them to load local. If you load them from the Adventure module, they will be transferred down from the host.

Again, modules are just renamed zipped files so the clients can easily open the modules they have on their machines and view all the images without masks. I personally feel making it that easy to get the maps is just a step too far, but your mileage may vary...especially if you use a system where the maps are not particularly important.

[DNH]

Ah right. Good point, that. I have story entries set up with links to my maps. If I instead had to go looking through another module for them, I would probably be wasting the time I would be saving from having them load locally! Not worth the mileage then, as you say.

FWIW, we play 4e ... so maps are largely unimportant, right?! ;)

[Foen]

I'm not sure the modules need to be the same, the content of modules is merged when the modules are loaded, and FG resolves lookups versus the merged data pool (I believe).

Stuart

[Griogre]

Try preloading the maps as much as you can during breaks and at the start of the session. Even if you get the map preloaded on only part of the players it still speeds it up for the rest of them.