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

[Goblin-King]

There have been some questions posted related to distributing modules or getting module data to show on the clients. I'm writing this to clarify the various types of data that modules can contain.

There are three types of data, detailed below. Each module can contain all three data types, although it is most likely that they have just one, or sometimes two, types present. The type is defined using the checkboxes in the module export view (H for host data, S for common shared data and C for client data).

Some users might be interested in building modules directly from XML files. In this case, the type of data is determined by the naming of the XML file with the module data content. The names of the files are db.xml for host data, common.xml for shared data and client.xml for client data.

The types of data available (with examples of possible usage) are:

Host data: Host data in modules is only viewable by a user running in Gamemaster mode. The module file must be installed on the user's computer. A user running as a player who has a module with host data won't be able to see the host data content even if the module is locally installed.
Monster/magic item compendiums
Adventure module GM notes
Client data: Client data is viewable by any user, player or GM. The file must be locally installed. The GM does not need to have a module for a player to be able to use one (nor does the GM automatically see it in such a case), although the GM must allow/disallow the use of client side modules.
Spell compendiums
Rules reference/House rules
Supplements containing information usable by players such as feats or classes
Common data: Data that is passed to each player whenever the GM activates the module. Players can't activate the data. The players do not need to have the module file installed, although if they do and the data matches, the data does not need to be transferred over the network. Note that data such as house rules and player campaign information could technically be presented as either client or common data. The downside of common data is the requirement to transfer the data over the network, as well as the lack of player control.
House rules
Adventure module player information
Campaign information for players Unless a module contains common data, it must be distributed to each player you wish to have access to the (client) data in that module.

[Griogre]

Thank you for the info Goblin-King. I noticed that the common data must be set to Force Load to actually make it transfer.

[Kalan]

Thank you for the info Goblin-King. I noticed that the common data must be set to Force Load to actually make it transfer.

I'll have to double check this then...

Are we correct to presume that common data will only be available when the players connect to the GM's machine?

[ldyparadox99]

Well, I just wanted to report my latest findings.

It seems by changing the client.xml for my eqd20spells.mod file to common.xml seems to finally upload to the player (with any update I make on my side).

The file does need to be forced otherwise it won't work at all.

This makes me feel a lot better than having to send them the .mod file since the spells in this system aren't under the OGL.

[Valarian]

Is it possible to include both a common.xml file and a client.xml file in the same module? I can see possibilities for having a module available for sale where, if only the GM buys it, it works like a common module and is only available while the player is connected. However, you want the ability for a player to buy the module for access off-line. Can this be a single .mod file, or would it have to be split in to a GM version and a Player version?

[Kalan]

Is it possible to include both a common.xml file and a client.xml file in the same module? I can see possibilities for having a module available for sale where, if only the GM buys it, it works like a common module and is only available while the player is connected. However, you want the ability for a player to buy the module for access off-line. Can this be a single .mod file, or would it have to be split in to a GM version and a Player version?

I know using the /export command will yield different module types within the .mod file.

Probably the best way to tackle it is look at the information involved, then split it into logical parts to build modules from. I've done this for a few diff projects now and it works well. But I can't see why the way you propose couldn't work, it'd be worth checking into.

[Valarian]

I was thinking modules for basic rules, rather than the campaign modules created by the /export command. The same information is useful to the GM and the player (for creating characters). So the player may want to purchase the Basic Rules module so that he can reference the material when creating local characters. Otherwise, if only the common module type is used, the player can only view the information when connected.

[Kalan]

I was thinking modules for basic rules, rather than the campaign modules created by the /export command. The same information is useful to the GM and the player (for creating characters). So the player may want to purchase the Basic Rules module so that he can reference the material when creating local characters. Otherwise, if only the common module type is used, the player can only view the information when connected.

The best way I think to accomplish this would be using the client module for the "game info" that both sides require, db module for "GM only stuff", and common for commonly accessed tables by both sides which resides on the GM side only so that the player only has access during sessions. I can't see any reason why the player would only have the client.xml in their .mod file, while the gm could have all three in a single .mod file.

The only issue here would be IP information - which generally lends itself, at least for personal use sets, to the common.xml file. But if you have licence rights, then client would be a better way to go.

This is the basic layout I use for my modules that I've been working on.

[Lorddamax]

Ok I am trying to get a spellbook exported and it's driving me nuts.

The file is common.xml

When I use /export I get nothing useful.

Hmm. My cllient PC just suddenly popped up the module - but its not showing an icon. And it took a LONG time for it to appear. The file is about 200k - however I'm testing this on 2 PCs on the same lan.

I shut down the client, restarted it, and now the module is not appearing again.

I'll try and post some screenshots lateron. Driving me batty. I cant have my players download and install a module every time we play.

[Griogre]

Hmm on a spellbook like module I would have expected you to make it by hand not by using the /export command.

[Ram Tyr]

I cant have my players download and install a module every time we play.
It does not sound like you want to use 'common data'. Client data instead seems to be what you are shooting for.

Of course, that does not help with the fact that you have not been able to make your 'common data' file work.

Later.

[Tropico]

Hmm.. I know I have in the past managed in doing what you're trying to by placing the file as 'common.xml' data and then force-loading the 'book' before the players connect.

Note that it has to be set up and forced before the players connect, once they connect, the changes you make to the permissions will not work, is what I've found.

But I would definitely say common.xml + force-load is what you're looking for, you must be missing a step somewhere along the way.

As far as the 'export' thing, I think that's only done when you want a 'campaign' or 'adventure' type of module. I don't think you need to do it in this case either.

I think some screenshots would definitely help out.

Edit -> Here is the thread (https://www.fantasygrounds.com/forums/showthread.php?t=6631) where I had (what seems to be) the same problem as you. It includes a step-by-step of everything I did. Maybe it'll help.

[Lorddamax]

It does not sound like you want to use 'common data'. Client data instead seems to be what you are shooting for.

Of course, that does not help with the fact that you have not been able to make your 'common data' file work.

Later.

Client data MUST be downloaded manually. Absolutely NOT what I want.

[Lorddamax]

Hmm.. I know I have in the past managed in doing what you're trying to by placing the file as 'common.xml' data and then force-loading the 'book' before the players connect.

Note that it has to be set up and forced before the players connect, once they connect, the changes you make to the permissions will not work, is what I've found.

But I would definitely say common.xml + force-load is what you're looking for, you must be missing a step somewhere along the way.

As far as the 'export' thing, I think that's only done when you want a 'campaign' or 'adventure' type of module. I don't think you need to do it in this case either.

I think some screenshots would definitely help out.

Edit -> Here is the thread (https://www.fantasygrounds.com/forums/showthread.php?t=6631) where I had (what seems to be) the same problem as you. It includes a step-by-step of everything I did. Maybe it'll help.

Well like I said - its working now. Kinda. About 8-10 mins after a client connects he can view the module. I havent tried it over the internet, but on a LAN where I can move a 1 meg file in under 1 second, a 150k file is taking 8-10 minutes to update. Thats nuts.

Running another test now, this time at home on a wireless network instead of wired at work. Either way it's still faster than an internet connection.

Ok at home over a wireless connection it took 4 minutes for the book to appear. Next time I play online I'll see how long it takes over the net for 5 players connected.

[Ram Tyr]

Client data MUST be downloaded manually. Absolutely NOT what I want.
Right, but only the first time. The common data has to sent over the network each time according to Tero, which I thought was a concern of yours from the portion of your post I quoted. Either way, glad you are making progress.

Later.

[Lorddamax]

Right, but only the first time.

Unless I am constantly updating the file. Every game session.

[Tokuriku]

Even then, only the files that got changed will be uploaded, the rest will not be touched.
What will take time is if you put new images in your ruleset everytime.

[Toadwart]

Would there be any problems with testing the behaviour of modules using 2 sessions of FG (one as host and one as client) on the same pc? or would it be better to tst with two pcs on the same network?

What if I fired up 2 or more client sessions? Would each client have a separate cached copy of the module data?

[Griogre]

I have done a fair amount of module testing by running several copies of FG2 on one machine. The only thing I can see is that it appears to transfer data much faster than normal (I think, effectively, everything is pre-loaded).

[Toadwart]

Hmm, I think I ran into a problem with user settings (hotkeys maybe) when I had 2 or more client sessions going at the same time. However, was many weeks ago and was working on a partially complete custom ruleset at the time so might have been a ruleset problem or I just confused myself :o

[arnon]

Some questions:

If I'd set my modified modules with the common.xml file type (so that it'll update if I make any corrections/additions), will it need to load up everytime a players connects to me?

Will it be better if i send them the modules (each time i change them) and tell them to place them in the modules folder? and will that cause a long loading time like the first time a player connects?

[Griogre]

Some questions:

If I'd set my modified modules with the common.xml file type (so that it'll update if I make any corrections/additions), will it need to load up everytime a players connects to me?
Yes, it will have to be loaded each time the player connects.

Will it be better if i send them the modules (each time i change them) and tell them to place them in the modules folder? and will that cause a long loading time like the first time a player connects?
Client modules would not be need to be transfered. Which is better really is determined by the stage of your module. If you are in the constantly making changes stage then a common module is better. Once things are stable though client modules are better to avoid the transfer on connection of common modules.

Of course, you may want to use a common module to limit distribution of your data - if that is important to you.

[arnon]

So if I send my players the modules, in the Module Activation window all i'll need to do is allow them to see it, not Force Load... right?

Thanks for the answers :)

[Griogre]

That is correct. To allow players to open a local client module all you need to do is allow it. If the host forgets, the players can ask by attempting to open the module which sends a small message to the host that someone is trying to open the module. The host can then allow or disallow the load.

[Astinus]

Does opening a module consume memory? Or is memory only taxed when a specific image/entry in the module is opened? I'm wondering if there's any value in limiting the number of open modules in FGII, or if we can have as many open as we like without affecting system performance.

[Griogre]

I can only guess at an answer, but I would presume opening a module consumes some memory (however small modules may not actually cause the program to use any more RAM depending on how it allocates memory initially). This is based on "lag" when large modules are opened.

Most modules are text only and as long as this is true - really wouldn't take much memory on any computer able to run Windows and DirectX 9.0c. When I run I typically have open all the default d20 modules, some of the CSRD modules, a cheat sheet module, and usually an adventure module or two. That would be between 9 and 12 modules. I doubt you would see much preformace impact unless you have a computer running less than the required amount of RAM for you operating system and was running a ton of large modules.

[Callum]

Hmm on a spellbook like module I would have expected you to make it by hand not by using the /export command.
This is probably a really dumb question, but what do you mean by "make it by hand"?

[Tenian]

I assume he means open the XML file and enter the data manually, in some sort of XML/text editor (i.e. outside FGII).

[Griogre]

Yes, that's what I meant. The /export command is usually used for making adventure modules (or parts of them). Spellbook and other "library book" type modules are usually built with some sort of XML editor to avoid having listings in the varies Story, Map, Item, and Personality books. Also you can do things you wouldn't be able to do it you exported the module.

[mattcolville]

I think I've run into this problem.

What's the function of having both different types of data, but also an interface for "GM Only," "Players have access," and "force push to players?"

Because it seems based on my primitive understanding, that you kinda need to work both sides of that for it to function properly.

I feel like the FGII interface, Deny/Allow/Force covers the data types. Is there a reason it works that way?

Usually when I find something like this, where it seems like a dependent redundancy, I later discover it's that way for a reason. :D Figure that's about to happen here.

[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. :D

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. :D

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 (https://nsis.sourceforge.net/Main_Page), 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 (https://www.fantasygrounds.com/forums/showthread.php?t=9166&highlight=NSIS) 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 (https://nsis.sourceforge.net/Main_Page), 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 (https://www.fantasygrounds.com/forums/showthread.php?t=9166&highlight=NSIS) 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.

[Moon Wizard]

The catalog is just a list of links to the data in the other modules.

Cheers,
JPG

[Zeus]

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.

If your group is comprised of Windows XP, Vista, 7, OSX/Wine/Crossover clients as is mine the NSIS .exe installer will run on all platforms just fine. As for how to safley distribute you might also want to look at creating a simple private group page on Google or Yahoo groups, they normally allow you to upload files and create a free secure space for your groups to interact and share resources. Many other users here also use online RPG portals like Obsidian to help manage their campaigns as well as provide ongoing campaign information. For small of amount of time and about (3-5 bucks a month) you can even run a small secure hosted WordPress or Web site to act as online Campaign Portal for your group(s), with tools like WP its a snap to build forum or blog elements along with support for rich media content like maps, campaign handouts, video streams of memorable past games etc etc.



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.

Hmm, doesn't sound right to me. I'm sure the xml inside the catalog module contains all of the power data, not sure why the source modules would still be required to be opened. Sort of defeats the purpose of a catalog as it operates more like an Index if this is the case. I'll check with Tenian.

[Zeus]

The catalog is just a list of links to the data in the other modules.

Cheers,
JPG

Tis strange, I cracked open my 4E Catalog.mod (22MB) and the power content is definitely included the module? Why would the data be included but the reference links linked to the external original source? I've dropped a note to Tenian and posed the same question.

[mattmalmquist]

ok hope this is the place to ask this...i am in the middle of creating one of the old dnd adventure mods in fantasy grounds II and was putting all the monsters under combat to make it easier for my dm. this way i was able to quickly make 12 monsters of the same type and change up thier hp as required...unfortunatly when i exported it the combats were gone and all my links to the combat from my story entries come up blank. Is there a way to export these and if so can u explain how...It just seems so much easier to put them in combat and leave the personalities area for the unique creatures

[Moon Wizard]

The ruleset needs to enable encounters to be exported. Currently, the 4E and d20_JPG rulesets are the only rulesets I know of that have campaign encounters, and the ability to use the /export command to create modules containing them.

What ruleset are you using?

Cheers,
JPG

[mattmalmquist]

im using 3.5e

[Moon Wizard]

The 3.5E ruleset does not currently support exporting of encounters. I'm working on a 3.5E overhaul right now, but it will not be ready for a bit.

Most people recommend the d20_JPG ruleset for playing 3.5E right now. There will be an update path from d20_JPG to the new 3.5E ruleset when it is ready. In fact, the upcoming 3.5E ruleset is essentially the next iteration of the d20_JPG ruleset.

Cheers,
JPG

[Jharii]

Tis strange, I cracked open my 4E Catalog.mod (22MB) and the power content is definitely included the module? Why would the data be included but the reference links linked to the external original source? I've dropped a note to Tenian and posed the same question.Is there any update to this at all? The same issue is currently happening to me. My catalog is 1.6mb and contains links to other modules. The power content is not within the module.

Sorry if the answer is elsewhere. I did do a search and could not seem to locate it.

Thanks.

[Zeus]

I did speak to Tenian (author of the 4EParser) about this some time ago but forgot to update the thread.

It turns out that the 4E Catalog contains only reference links for powers and that source modules are still required to be opened. The catalog does contain some source data about each power however it is not complete and is exclusively used by EugeneZ's DDI Character Builder importing tool.

So in summary, the 4E Catalog acts more like an Index in that it provides a single reference for all 4E Powers but to open or link to the powers requires the source module for the power to be open.

Hope that clears up any confusion.

[Jharii]

I did speak to Tenian (author of the 4EParser) about this some time ago but forgot to update the thread.

It turns out that the 4E Catalog contains only reference links for powers and that source modules are still required to be opened. The catalog does contain some source data about each power however it is not complete and is exclusively used by EugeneZ's DDI Character Builder importing tool.

So in summary, the 4E Catalog acts more like an Index in that it provides a single reference for all 4E Powers but to open or link to the powers requires the source module for the power to be open.

Hope that clears up any confusion.
Thanks. That certainly does. However, I do have a problem. I created all the mods (PHBI, II, III, etc.) and share the modules in conjunction with the catalog. I then force the download to the players/clients, yet they are not distributed and are not available in the modules. They only have the catalog available. They cannot even create characters with the source material as a result.

Is this normal behavior?

[Griogre]

It depends on how you build your modules. If they are client modules, then yes they should work that way. Client modules have to be on the local machine to be opened. Only if the server and clients have identical versions of the client modules can they be force loaded.

[Jharii]

It depends on how you build your modules. If they are client modules, then yes they should work that way. Client modules have to be on the local machine to be opened. Only if the server and clients have identical versions of the client modules can they be force loaded.Ah. I believe mine were all built with the default db.xml. I never realized the impact this had. So common.xml it is (and a lot of rebuilding/renaming). Thanks.

[Griogre]

The db.xml modules are server only modules. The common modules are also only server only and can be force loaded onto the clients. Typically you should keep common modules as small as possible since they have to be loaded and transfered every time a client connects.

[Moon Wizard]

One caveat on making them a non-host module type is that it will increase the download time at the beginning of each session. While the module data should cache, it's one more file to check, and if there are any changes, another large download.

Regards,
JPG