PDA

View Full Version : Players unable to open module...



Doswelk
May 16th, 2007, 09:59
When the player tries to open a "book" it closes again, this includes the ones I have stated to be forced to players.

What I did do last night was manually copy the .mod files to the client pc and then they could "open" the books.

Is this how it is supposed to work?

lucyanor
May 23rd, 2007, 11:23
I am having the exact same problem. What is the solution? Where did you copy the file?
I thought that the moment the clients connect, the .mod is transferred automatically.
However, even if the file is selected as auto load and open in the DM server, it does appear in the client mod books but just wont open. You pull it open and it closes back on its own!

Tokuriku
May 23rd, 2007, 11:40
The clients have to download the mod manually.

ldyparadox99
May 23rd, 2007, 12:34
We've been discussing this also in the Workshop since I thought I had done something while making a custom ruleset.

I went ahead and put the custom module in one of my player's module folders and the book can be opened however this is going to be a major pita since the module is a work in progress..ie..I'm putting a little bit of info in it at a time as the players level and gain new spell levels.

I don't really want to have to send out the file over and over and over again as it changes and info is added.

Griogre
May 23rd, 2007, 17:14
This is a module type you can force the players to load from the Host. I'm not sure how to do make one off hand though. That's why there is a "force" load module setting. It only works on the right files though.

Kalan
May 24th, 2007, 11:42
I have been able to replicate this issue - and it concerns me, as there are a number of projects in the works that will require this "auto download", and subsequent "dumping" of module data on client machines. Giving players copies of the .mod files isn't how it was supposed to work (or at least that was my impression).

ldyparadox99
May 28th, 2007, 21:23
Still waiting for a reply on this.

As I predicted, having to send the module to my players ensues in complete chaos. While it should be better the next time, I know that one of them will end up deleting the new module and using an out of date one since my spells.mod book is a work in progress.

Goblin-King
May 29th, 2007, 07:54
Since this has come up in a couple of places, I made a sticky explaining the module types:

https://www.fantasygrounds.com/forums/showthread.php?t=6446

For in-progress work, I would suggest either working on it as a common data module and distributing it as client data when it's done, or naming it with version numbers to make sure everyone has the current one.

The book not staying open situation is probably the result of a module that does not contain client data appearing on the player module list, and should not occur. If you are seeing this, could you please post steps on how to replicate this, as well as the types of data contained in the module in question and whether the players seeing it in their list have the module file locally installed or not.

ldyparadox99
May 29th, 2007, 12:49
I just need some clarification for the client.xml (which would be for a converted d20spells.mod file, not from any module being made within the FG program itself).

You state that it needs to be installed locally. Does this mean there's a download when the player connects to the host and it's then installed locally or is the GM responsible for distributing the file and the player putting it in the module folder?

Because if it's the former, the players can see the spell book in the module activation screen but can not open it unless they physically put a copy I sent them on their PC.

Kalan
May 29th, 2007, 13:46
Just a quick clarification then I think for me as well :)

Common data does not need to be distributed to the individual players (it is instead transmitted when a player connects)? While client or db data must reside locally on the player and GM's system?

I have used common.xml, however, even after several minutes, the data does not appear on the player side (the "cobweb" phenomenon"). Is this an indication of a transmission error? How does one resolve this?

Griogre
May 29th, 2007, 17:56
As I mention under Goblin-Kings post. To make the common data actually "move" you need to set the module to "Force Transfer" on the module list.

Kalan
May 29th, 2007, 19:26
Just seen your post there, then this one :) As I said there - I need to try it out :)

Goblin-King
May 30th, 2007, 07:30
Common data does not need to be distributed to the individual players (it is instead transmitted when a player connects)? While client or db data must reside locally on the player and GM's system?
It is transmitted when the GM activates the module, and to connecting users after that.


I have used common.xml, however, even after several minutes, the data does not appear on the player side (the "cobweb" phenomenon"). Is this an indication of a transmission error? How does one resolve this?
Did you check the "I" checkbox for index generation when you exported the module? If you didn't, the data would get transferred but there would be no library entries to access it by. If you created the module by hand, did you create the <library> tag in common.xml?

Kalan
May 30th, 2007, 09:54
It is transmitted when the GM activates the module, and to connecting users after that.


Did you check the "I" checkbox for index generation when you exported the module? If you didn't, the data would get transferred but there would be no library entries to access it by. If you created the module by hand, did you create the <library> tag in common.xml?
I just double checked - and there is the <library> tag in the module. The player receives the module on their end, and all tags under <library> - however none of the data residing within those tags show up.

A snippet of the code is as follows:



<library>
<wowrpgbasicrules static = 'true'>
<name type='string'>WoW RPG Basic Rules</name>
<categoryname type='string'>WoW RPG Essentials</categoryname>
<entries>
<allianceraces>
<librarylink type='windowreference'>
<class>referenceindex</class>
<recordname>..</recordname>
</librarylink>
<name type='string'>Races of the Alliance</name>
<index>
<dwarf_ironforge>
<listlink type='windowreference'>
<class>referencetextwide</class>
<recordname>..</recordname>
</listlink>
<name type='string'>Dwarf, Ironforge</name>
<text type='formattedtext'>
<p><b>Description:</b>The dwarves of Ironforge are a proud, stern and determined people with streaks of kindness hidden under the gruff exteriors of their sturdy frames. Their love for battle, invention and exploration impels them ever forward to discover and unearth the mysteries of their heritage, educating them further about those who first created the dwarven race.</p>
.
.
.
</text>
</dwarf_ironforge>
</index>
</allianceraces>
</entries>
</wowrpgbasicrules>
</library>

It works fine on my GM machine, and the library information shows up on the player machine (ie: the Player does see the "Races of the Alliance" if they click on the book...however when they click on the Races of the Alliance link - no data shows up. After about 10mins of being connected, there was still the cobweb on the Players "version" of the book.

I hope this makes some sense :S

Kalan
June 1st, 2007, 09:23
Just seeing if anyone else is still observing the "cobweb" loading issue with regards to common.xml files...

IE: Bumpage...

SniperDM
June 3rd, 2007, 02:04
I have this problem Kalan, and it seems entirely related to the fact that players cannot access common data unless is has a library index. While this seems to make sense at first, it's giving me some trouble. I don't want players to be able to peruse this shared data, I only want them to view it when I choose to share it with them.

Basically, my campaign is very large, and for organization, I've broken it apart into several smaller modules. This works fine for me, but whenever I try to share an image, like say, a map, that is a part of any module, it freezes up both of my players, even though my modules were exported with the 'common/shared' data boxes all ticked. It seems that unless I also tick the 'create library index' option, the players just get stuck trying to load data that isn't there for them. I've also tried, for lack of ideas, to export the same modules as 'Host' or 'Client' to no avail.

The only solution I found was for the players to have the modules on their own hard drives. This allowed me to share the maps without having a library index, but it is an imperfect solution for most DMs that cannot trust their players as I do mine. Is there any way we can truly share module-contained maps and images or even story pages/items, etc, without creating a library index for them?

On a side note, when I gave the players my module so they could view shared module maps without a library index, the module appeared in their module list, though they can't 'open the book' for it. It just keeps flipping closed. I just force load it for them anyway, but it's worth noting.

Griogre
June 3rd, 2007, 06:33
On a side note, when I gave the players my module so they could view shared module maps without a library index, the module appeared in their module list, though they can't 'open the book' for it. It just keeps flipping closed. I just force load it for them anyway, but it's worth noting.
The snapping closed just means it is not a client module openable module. If it isn't a client module, players will not normally be able to get it to stay open.

ldyparadox99
June 3rd, 2007, 13:57
It's worth noting that I went ahead and changed the client.xml to common.xml for my eqd20spells.mod file and it's finally showing up in the player's library as long as I force it to load.

I'm not sure what changed between the time Griogre mentioned to try naming the client.xml to the other types and now, but it works and I won't have to send the .mod files to my players.

The headache of making sure the players have all the updated contents has lessened considerably. Now if I can convince a monkey to do the data entry from the PHB and into the spells mod life would be good. :D

Kalan
June 3rd, 2007, 14:23
It's worth noting that I went ahead and changed the client.xml to common.xml for my eqd20spells.mod file and it's finally showing up in the player's library as long as I force it to load.

I'm not sure what changed between the time Griogre mentioned to try naming the client.xml to the other types and now, but it works and I won't have to send the .mod files to my players.

The headache of making sure the players have all the updated contents has lessened considerably. Now if I can convince a monkey to do the data entry from the PHB and into the spells mod life would be good. :D

It shows up - but are they actually able to access anything in the file? My files show up fine in the library - but the players are unable to access anything "inside" the library itself...

Kalan
June 3rd, 2007, 14:29
Ok...disregard me :S I don't know what happened since yesterday when I checked...but now it all works fine :S So long as the book is "open" on the GM's side, things are cool.

One thing I noticed tho - the players are not able to "open" the books in themodule activation - but that doesn't seem to affect the operation of the data transfer - ie: Its workin just hunky dory now :)

Great work guys - and thanks for puttin up with a whiny guy ;)

peace :D

V

SniperDM
June 4th, 2007, 03:33
I'd still like to know if it's possible to use modules WITHOUT a library index but with 'shared' data to be able to share image files in an adventure without the PCs having the module.

Griogre
June 4th, 2007, 04:00
I don't really understand your question, Sniper. I can make a module, export it with out indexing and share the images in the module. Is that what you are asking? In fact that is how I usually make adventure modules.

Because you would normally do this for an adventure module it seems like you are asking a trick question.

SniperDM
June 4th, 2007, 05:54
Then I must be doing something wrong. Like I said above, I tried doing this with a single module as all three export options. In all cases, when I share an image contained in this module, it causes both my players to freeze so that they have to CTRL+ALT+DEL out of fantasygrounds. The only solution was to give the players the module file.

I guess I'll have to keep trying, but again, I've exported the same module as 'common' 'client' and 'host.' No luck.

Griogre
June 4th, 2007, 07:45
Hmm. Ok to export a adventure I load the campaign I'm going to make a module from. I then type /export in the chat to pop the export window. I type in the name of the module, the filename and put my initials in the author name. I tab through the next two entries leaving them with the default text and give the thumbnail path. Next I just check Story, Images & Maps, Personalites, and Items. Only the Host data will be checked and I leave that alone. I right click and select export. You should get a success message.

I load up the campaign I'm going to use the module in. Select the module and make sure the book is open. I then open maps and images click on an image and then right click and either preload it first on the players machines or just share it. The image should pop on the players machines.

SniperDM
June 4th, 2007, 10:26
Hrm, you may have just solved my problem Griogre but I won't know until I can get a player to test it for me.

The key is...

I tab through the next two entries leaving them with the default text
See, I think I've actually been putting text in there, and one of them has to do with library indexing, I just realized. I don't check the circles for library indexing in the middle section, but perhaps by naming the index anyway, this is creating a conundrum on my players' clients as they load the module or image, causing the freeze. I've just exported a new version with those lines empty as a 'host' module like you suggested, and will give it a test when my guinea. . .I mean PLAYERS. . .are available.

Thank you for the tips.

SniperDM
June 4th, 2007, 23:19
Just an update. I tested this and it's still causing my players to freeze, if they don't have the module installed on their own machines. I'm looking at the file and all the data is under a 'db.xml' meaning it should be of the host type. I'm sort of short on ideas. I'd post a copy of the module here but it's full of licensed content and that would be bad. So I guess I'll just have to stick with giving my players the module.

Griogre
June 5th, 2007, 09:28
You might try having your guys delete the module they have and then try. I believe FG2 will read off of their machine first which may be a corrupted module. If you still have problems I would suggest you send the campaign to customer support so they can take a look at it.

Kalan
June 5th, 2007, 09:37
I have looked over the code for SniperDM - and I _think_ it has something to do with how he originally exported the module.

At first I thought he was coding things from scratch, but after looking it over it became clear he did the data entry in FGII. Basically its a "standard" adventure type module.

The best solution is to simply delete all instances of the module, then - presuming you used a seperate campaign to key this data in - just rexport the module selecting "S" on all items you wish to share with your players. (I tested by selecting S on each item - Story, Images, NPCs, etc). Since the players do not need the actual text within the module, and only the images, this should work - as I have tested this export function on this end.

Hopefully that makes some sense...if not, I'll be around pretty much all day until about 10pm GMT+1 (so for about another 12hrs or so).

SniperDM
June 6th, 2007, 17:48
Just a heads up that the problem is solved. I can't say for certain what it was. There were escape characters in the text of the campaign database that I deleted, also when I exported this time I used a different file name than the one I had been using and deleted the old file. Since Kalan suggested deleting all instances of the old module I suspect this might have been the solution. Technology is such a fickle goddess. :) I used 'host' to export though, and it seems to work fine.

Your help has been indispensable on this Kalan. Thanks again for your assistance.