How do players see my modules? Module data types and distribution

[mattcolville]

Ok, I bet I can guess.

The common/client/db.xml definitions are for companies making modules for purchase? So they can define a product as "GM only?" Those distinctions are in no way meant for normal users, are they?

[Phystus]

Actually, they are meant for everyone.

I'll give you examples:
I have a module of information about the campaign world for my players. It includes some maps and such, and it's a fairly large file. It also doesn't change very often. So, I made it as a client.xml and emailed it to my players. This means FG doesn't have to send the players those maps during a game session, so we don't slow the game down.

I have another module of custom spells that the players have researched. That file is quite small, being only text. It also changes from time to time as new spells are learned. I made that as a common.xml, so I don't have to remember to email updates. Since it's a small file, the transfer time during the game is not a problem.

I force load both of these, so they're always available to the players.

Adventures are made as db.xml of course. And set to GM only on the module activation.

Hope that helps.

~P

[mattcolville]

Actually, they are meant for everyone.

I'll give you examples:
I have a module of information about the campaign world for my players. It includes some maps and such, and it's a fairly large file. It also doesn't change very often. So, I made it as a client.xml and emailed it to my players. This means FG doesn't have to send the players those maps during a game session, so we don't slow the game down.

I have another module of custom spells that the players have researched. That file is quite small, being only text. It also changes from time to time as new spells are learned. I made that as a common.xml, so I don't have to remember to email updates. Since it's a small file, the transfer time during the game is not a problem.

I force load both of these, so they're always available to the players.

Adventures are made as db.xml of course. And set to GM only on the module activation.

Hope that helps.

~P

Ok, that helps. My understanding grows. Thanks for the clear explanation.

If my players and I all have all the same Modules, theirs stored client-side, mine server side, what's the difference between Allow and Force Load? Why would I use one over the other? Seems like everyone's saying "Just use Force Load."

You have two models, one with big data files manually synched via email, one with a tiny file which FG2 pushes out to the client. But you have them both on Force Load, is that just so you're certain that everyone has both of them loaded? So if you open, for instance, a map from your campaign, you know everyone can see it because you literally FORCED them all to have it pre-loaded? Whereas with Allow, they won't see it? Or will only see it if THEY have the module loaded too?

Everyone's help is appreciated, I really want to make this thing work.I have a lot of players depending on me.

My problem is that this program's learning curve is pretty extreme. It might not be obvious to a power-user, but I've been working on this thing since Sunday and I'm still not ready yet to run a game. Given the, ah, price, I was hoping something more intuitive. Not your fault!

For instance, at least some of my players are very much NOT computer power-users. If I tell them they have to download files, navigate to a specific directory and drop the files in there, there's a good chance they'll get confused. Imagine asking your mom to run this program and get into a game, that's what we're talking about.

They can play WoW, they can play SC2 or Tide of Iron, because Steam handles all that. But once you get to file structures and stuff they start to freak out. So I was hoping I could do all the heavy lifting over here and make it as easy as possible for them.

Not giving up though!

[mattcolville]

Actually I have a module here that appears to collate all the relevant Player Data for making dudes for my chosen system, it may be enough to just push that to them and not worry about the other books.

If I make that common, force load, they'll be able to log in, make dudes, without me emailing them anything or asking them to put anything in the right place, correct?

[Griogre]

Correct.

The difference between approve and force load for client modules is that approve means the player has the *option* of opening the module or not. Force load means if the client has the same module - it *is* automatically loaded.

Some people make very large 4E library modules. Win7 has a hard limit of 4 Gigs for one app. If you play with all 4E books and allow them the player can just open the books he needs. If you force load all 4E books then you will cause all core and splats and magic books to load on the players computer. If they are on an old computer or a laptop/notebook you might very well run them out of RAM and put them on virtual memory as there are now 3 PHs, 8ish Splats, 2 Campaigns, and 2 AVs.

[mattcolville]

The problem I'm running into now is;

A: the module I have that collects all the PC powers and Racial Abilities (but, annoyingly, not feats) doesn't appear to actually contain the power info, only links to the power info. So using that module means the player still needs the module from the original product.

This is disappointing to me because I'd hoped that specific module could save the headache of loading and managing all the others, but in fact using it just increases the number of modules I need to load by one.

B: It appears that the Force Load thing transfers the module every time the player logs in, which I was hoping would be a one-time resource sink. Subsequent logins would just check "does this player already have this module? Load it." Doing it every time is, I fear prohibitive.

So if I understand the way FG2 treats its data, and admittedly it seems likely to me I do not understand it, in order to make this as easy as possible I need to make sure all my players have all the data locally, at which point I can then...actually at this point my understanding breaks down. Force load it? Allow it? Unknown. I want them to be able to make a dude without A: having to wait many minutes for modules to load B: know which modules their data is in and C: worry about local data vs server data. I suspect this is not possible.

I wanted to give my players the ability to log in and easily make their character, but this appears to be a feature this software doesn't support. Part of my frustration is the astonishing fact that there appears to be no indication that you are loading or transferring a library module. How do you know if it's working? Wait and hope. How do you know how long it will take? IMPOSSIBLE TO SAY!

I should say "make it easy to log in and make their character *again*" because they already built the character once in the Character Builder.

[Moon Wizard]

There is a tool floating around the forums that converts Character Builder files into XML that can be inserted into your campaign.

For modules, you could build an uber module containing all data (not just links), but I don't think that the parser supports it. It would be a manual endeavor of copy and paste. Try asking Tenian, who built the tool. For 4E modules, you want the monster books to be host data. Also, you want the 4E player modules to be client data, and have the modules installed locally on their machines to minimize data transfers on game startup.

To understand modules:

• There are 3 types of module data. Usually, each module contains a single type of data, but can contain all three.
• Host = Only available on the host, will not load on client
• Client = Available on host or client, but must be installed locally. Host controls access.
• Common = Available on host or client. Host controls access and distributes file via network at beginning of every game session.

• There are 3 types of module access controls for host. By default, access is denied, but a request is sent to the host chat window.
• Allow Access = If module is client/common type and is available on client, then client has the option to open.
• Force Load = If module is client/common type and is available on client, then client automatically opens the module.
• Deny Access = Regardless of module type or availability, the module can not be loaded by the client.

Improvements to the transfer rate and visibility into the transfer of files is definitely something that is on the wish list. Believe me, I want all these things as well. We're limited by what we can build in the time we have, and we have to prioritize for the whole community.

Hope that helps a bit.

Regards,
JPG

[mattcolville]

Yeah, I guessed that was the solution. In fact, I was trying to avoid a situation where my players had to all have the same data modules locally, as not all of them are computer savvy.

I was hoping a one-time force-load would be enough to get the data to them, behind the scenes as it were, so they wouldn't have to worry about downloading, navigating to their AppData folder (which, in Windows7, is a hidden folder) and then dropping the files in. I am not looking forward to calling my players on the phone and walking them through the process of Showing Hidden Folders just so we can play D&D online.

So it sounds like...there is no solution that meets my criteria for allowing players to easily recreate their characters inside FG2. And the only thing for it is manually walking all my players through the process of getting the data modules onto their computer and in the right folder. I've got about 15 players across the country right now waiting on this and while some of them are plenty savvy, some are not. And none are going to think this is reasonable.

I'm at the point of concluding this is not a piece of commercial software. Some kind of status bar for transferring files seems to me basic functionality. The absence of normal Windows UI standards like...the fact that hitting escape does not close a context menu, just to pick a random example, means I'm going to have some really, really confused players. Stuff will happen, they won't know why, and they won't know how to undo it.

I mean, believe me, I have some idea how hard it must have been getting the software to the state it's at, but I feel like I just paid $150 to beta test Fantasy Grounds.

The worst-case scenario right now is; my player logs into my server to make a character. He has all the data modules locally. He's gone to the trouble of flagging each piece of data in his character sheet with the sourcebook its from (something he didn't have to do when he made the character in the first place, the process of selecting feats and powers in the Builder is sourcebook-agnostic). He discovers he has a piece of data from some product I have no module for, likely a Dragon Magazine, likely a recent Dragon Magazine. He now has the choice of either entering the data from scratch (something he may conclude is impossible, if it is a Feat, since you cannot create Feat descriptions in the character sheet) or sitting there and waiting for me to go launch the Parser and scrub the Compendium, and import the data module myself.

I predict this will not be an easy process for most of my players.

[Zeus]

mattcolville - I understand your plight, however there are things you can do to make your life as a DM easier as well as ease the setup learning curve for your players.

I build all my player modules as per usual (using the Parser tool) and I make a mental note to regularly scrape the latest Dragon Magazine every month (usually less than a 10 min job for the functional data). I then use NSIS, an open source installer that builds install packages from scripts, to produce a single .exe which when executed installs 4E extensions, modules and portraits to the appropriate FGII app folder subfolder (modules, extensions etc. etc.). In other words pretty much everything your players need to game.

My players find this invaluable as its a simple case of downloading the latest .exe from the group web portal, executing and then starting FGII. Nice, easy and less faffing about for your players. Of course this isn't needed for every game session but only when you add/change your module/extension/portrait content.

Here's a thread which discusses NSIS (amongst a few other things) and attached is a ZIP containing an example of a NSIS script. All you need to do is update the paths and filenames, copy it to a folder that contains your modules and execute with the NSIS tool (see link above). It will then produce a .exe file you can then distribute.

As for the Catalog feature of the Parser, it does produce a self contained master Powers module. Linking to its contents should NOT require the original modules to be opened within FGII. Not sure why your seeing different behaviour.

[mattcolville]

mattcolville - I understand your plight, however there are things you can do to make your life as a DM easier as well as ease the setup learning curve for your players.

I build all my player modules as per usual (using the Parser tool) and I make a mental note to regularly scrape the latest Dragon Magazine every month (usually less than a 10 min job for the functional data). I then use NSIS, an open source installer that builds install packages from scripts, to produce a single .exe which when executed installs 4E extensions, modules and portraits to the appropriate FGII app folder subfolder (modules, extensions etc. etc.). In other words pretty much everything your players need to game.

My players find this invaluable as its a simple case of downloading the latest .exe from the group web portal, executing and then starting FGII. Nice, easy and less faffing about for your players. Of course this isn't needed for every game session but only when you add/change your module/extension/portrait content.

Here's a thread which discusses NSIS (amongst a few other things) and attached is a ZIP containing an example of a NSIS script. All you need to do is update the paths and filenames, copy it to a folder that contains your modules and execute with the NSIS tool (see link above). It will then produce a .exe file you can then distribute.

As for the Catalog feature of the Parser, it does produce a self contained master Powers module. Linking to its contents should NOT require the original modules to be opened within FGII. Not sure why your seeing different behaviour.

I will check out the NSIS, thanks for the tip. I was thinking about using a self-extracting zip file, but the problem is I have players on three different versions of Windows and Macs, so probably there's no one solution other than DropBox and letting them navigate to the proper folder.

When my player had grabbed a power from the 4E Catalog and then tried clicking on it to read it, he got an error telling him the sourcebook it came from was not present/loaded. That seemed pretty cut and dry to me, but maybe I was doing something wrong on my end.