PDA

View Full Version : More modules bugs since recent updates



Astinus
December 9th, 2008, 18:49
There's quite a bit wrong with the way modules work in FGII since the recent updates, some have been mentioned here, some haven't.

The following bugs assume GM's are distributing modules with "client" data prior to games.

1. The problem I haven't seen mentioned: When you share an image in a module there's no way to change the client's view of the image.

If the GM zooms or changes the view and selects "Share Sheet" it does nothing on the client side. It doesn't zoom or anything.

Before the recent round of updates, there was a workaround: by selecting "Preload Image" the host could change the client's view and zoom in etc.

Now even the workaround is broken! There's no way to change the client's view of an image. This renders modules useless as a means of sharing large images like maps.

2. The problem that has been mentioned: When sharing module images, "Share Sheet" doesn't preload the mask, if it's applied. The map pops up, and then a few seconds later the mask is applied.

Before the updates, "Preload Image" was also an acceptable work around. If the GM hit "Preload Image", waited a second, then hit "Share Sheet", the module image would load on the client side with the mask applied.

No longer. Another workaround bites the dust. Whatever the recent updates have done, they've changed the functioning of "Preload Image" in regard to modules. It's a painful loss.

A great strength of FGII was that GMs could use modules to pre-distribute images, and therefore run high quality games with tons of great material, on low bandwidth setups.

It would be great to have this back.

EugeneZ
December 10th, 2008, 01:09
This post details issues I've had with FG2 but I was just careless to not relaize they are tied to the update. I assumed I was doing something wrong. I fully agree with this user that I've experienced both of these issues and would also love to see them fixed. Preferrably for no need for workarounds at all, but even the preload functionality from before would be better than nothing.

Thanks for the report, Astinus.

Bumamgar
December 11th, 2008, 01:21
This bug is causing some real grief for my campaign. I'd love for it to get fixed so I could pre-distribute hi-res maps to my players before each session.

Astinus
December 11th, 2008, 01:42
I assume one of the devs has read this.

Is there any chance at least of getting the "Preload Image" feature to work as it used to, i.e. as a workaround?

For people who utilize modules like this - and it seems there are a few - this is a significant "broken" feature.

Goblin-King
December 11th, 2008, 09:12
This issue is not as simple as it first seems. There are two kinds of problems. First, there are issues with things that FG allows the user to do, even though they really shouldn't, and that results in some bugs and/or bug-like behaviour. Second, there's a functionality required by some users that is not properly supported by FG. We're working on both issues.

Let me elaborate a bit. Client modules were never intended to be used for distributing images that would be used masked. The very point of a client side module is that the player does not need to contact the host in order to operate it. Basically, you can compare the client needing to say "hey host, I want to show this image, do you happen to have a mask on it" to "hey host, this player wants to access the information on the fighter class, can I show this information or do you have something to add". Basically, one bug here is the fact that you can use masks on images from client modules, which should be unmodifiable. Modifying includes creating masks. Another is the fact that you can actually share it. You shouldn't, since not all players necessarily even have that module installed.

Pre-distributing images is a great tool especially with large maps or slow connections and FG doesn't really have that now. Client modules just aren't the way to do it, technically. We want to make this available, and have ideas, but we're going through the plan right now to make sure it works.

Zooms, client view rectangles and such are mostly weird behaviour caused by the behaviour that you can do even though you shouldn't :) . We're working on a fix for all of this, but we want to avoid breaking anything further...

Goblin-King
December 11th, 2008, 09:43
Well, I rolled up my sleeves to start work on this and I found it was already done! Try doing what you've been doing, but switch to host mode modules instead. The clients will not be able to open these on their own, but they'll be able to access the images inside, just as they would with tokens.

We didn't do much testing on this yet, so I'll keep my eyes open about feedback regarding the issue.

Ged
December 11th, 2008, 12:32
As I had to clarify this issue to myself, I thought I'd share my thoughts with you as well. Goblin-King already said this, but maybe for some of you this is more readily digestible.

To use modules to deliver images before a session in order to save time and bandwidth during sessions:

Put the images in a module in host mode.
Deliver this module to the players by some means other than FG (email it, for instance). It follows that:

The players cannot open the images in Fantasy Grounds by themselves in client mode.
When the GM shares the image, the information is read from the module on the player's computer (if the player does not have the module, everything works as normal, the host sends the image to the player).
Mask works as it is supposed to.

Callum
December 11th, 2008, 12:44
To use modules to deliver images before a session in order to save time and bandwidth during sessions:

Put the images in a module in host mode.
Deliver this module to the players by some means other than FG (email it, for instance).
Do you really need to e-mail the module to the players? I've always used host mode in all my modules, and distributing module images from within FG seems to work fine for me. I use the pre-load image command, and my players haven't reported any problems with slow loading or missing masks...

Tenian
December 11th, 2008, 13:13
Callum:

Some people use large maps and/or play over very slow connections (Mobile broadband/dial up). In such situations, a file distributed by FTP/email outside of FGII provides much better performance.

Goblin-King/Ged:
Is there any possibility that some form of encryption could be added to modules? I think this feature would be a lot more useful if players couldn't just unzip the module and open the maps.

Ged
December 11th, 2008, 13:14
Do you really need to e-mail the module to the players? I've always used host mode in all my modules, and distributing module images from within FG seems to work fine for me. I use the pre-load image command, and my players haven't reported any problems with slow loading or missing masks...
No you don't have to e-mail it. The purpose of my post was to advice how to pre-distribute images in a low-bandwidth situation, as required by the OP:


A great strength of FGII was that GMs could use modules to pre-distribute images, and therefore run high quality games with tons of great material, on low bandwidth setups.

Edit: too slow :)

EugeneZ
December 11th, 2008, 14:37
I'll definitely have to try this next session. Thanks for looking into this!

Astinus
December 11th, 2008, 14:56
This issue is not as simple as it first seems. There are two kinds of problems. First, there are issues with things that FG allows the user to do, even though they really shouldn't, and that results in some bugs and/or bug-like behaviour. Second, there's a functionality required by some users that is not properly supported by FG. We're working on both issues.

Let me elaborate a bit. Client modules were never intended to be used for distributing images that would be used masked. The very point of a client side module is that the player does not need to contact the host in order to operate it. Basically, you can compare the client needing to say "hey host, I want to show this image, do you happen to have a mask on it" to "hey host, this player wants to access the information on the fighter class, can I show this information or do you have something to add". Basically, one bug here is the fact that you can use masks on images from client modules, which should be unmodifiable. Modifying includes creating masks. Another is the fact that you can actually share it. You shouldn't, since not all players necessarily even have that module installed.

Pre-distributing images is a great tool especially with large maps or slow connections and FG doesn't really have that now. Client modules just aren't the way to do it, technically. We want to make this available, and have ideas, but we're going through the plan right now to make sure it works.

Zooms, client view rectangles and such are mostly weird behaviour caused by the behaviour that you can do even though you shouldn't :) . We're working on a fix for all of this, but we want to avoid breaking anything further...

Thank you very much for the detailed explanation. It all makes sense now.

Astinus
December 11th, 2008, 15:03
Well, I rolled up my sleeves to start work on this and I found it was already done! Try doing what you've been doing, but switch to host mode modules instead. The clients will not be able to open these on their own, but they'll be able to access the images inside, just as they would with tokens.

We didn't do much testing on this yet, so I'll keep my eyes open about feedback regarding the issue.

It works great! Just tested in localhost mode, and over a dial up connection with a separate installation, and it all works as it should. Masks apply from the instant the image is loaded, the GM can change the client view and zoom etc.

So after thinking everything had gotten worse, everything has actually gotten better! Thank you, that's some fast service. ;)

Astinus
December 11th, 2008, 16:21
Try doing what you've been doing, but switch to host mode modules instead. The clients will not be able to open these on their own, but they'll be able to access the images inside, just as they would with tokens.
After tinkering with this some more, I noticed tokens still don't load locally. Even if saved in the module, the tokens are still being transferred from the Host.

Not sure if it was your intention for them to load locally, but I just thought I'd mention it. It would be nice if they did load locally, but I'm not complaining. It's sweet as it is :)