Loading problems and Confusion

[Verkhaz]

So I am preparing a DnD campaign and therefore decided to give FG a go.
Created a oneshot adventure as a first "get together" and had to abort due to massive loading times causing me to lag so hard I lost teamspeak connection.
So I have been trying different things with a friend of mine and we cant make stuff work since the game for some reason doesnt tell anything what it is actually trasnferring on data we are utterly confused.
I have subscribed to Ultimate license and own some of the official modules. My testing friend has standard subscription and owns pretty much the same official modules.

The oneshot is basically 6 PCs I created beforehand, some images for handouts and 2 maps, one of those a combat encounter. The total package is ~122 MB.
I tried creating a complete cache by joining myself as a player, I created a module out of that oneshot and I have the whole campaign folder. I uploaded all of those three things and my friend put those in his respective folders.

The only thing we could find that made him load all the files instantly without any loading was a fresh campaign where I checked the players to load my own created module, no Player characters involved.
As soon as he joins the original oneshot and rolls something with a PC FG starts to load for ages and we have no clue what it even loads. He has the oneshot module, he has the official modules that I granted player acess to he has everything but the few PCs.

So the following questions arise:

1. What the hell is this software loading after even the module is shared ?
2. How do I transfer larger campaigns to my players so they get all files beforehand and we avoid this horrendous loading time. Apparently creating a Module file is not enough ? how Do I avoid them getting whatever information files they need from my acess granted to players official modules, I cant have 5 people loading all that stuff.
3. Any way I can give the premade Pcs to my players for them to put them into FG folders, since that somehow seems to create loading ?

Thanks in advance,

a quite fed up new user.

[seycyrus]

@Verkhaz. I'm sure someone more competent than I am will be along momentarily to help you out, but let e state that your problem seems to be very unusual. What version of DnD are we talking about? 5.0 is the main feedbucket of FG, and tons of users share and load material like you have described without any of those problems.

What's your internet speed?

I wonder if sharing your one-shot would help others figure things out.

[Trenloe]

Welcome to the FG forums Verkhaz. Sorry you're getting frustrated.

The first time a player connects to a campaign is when the most data is transferred from the GM to that player - this includes shared campaign data and also modules that the player can access. The player can see the data being stored in the <FG app data>\cache\<campaign name> directory in the form of a number of files with the .dat extension - as they are being downloaded the size of these files will be increasing (you may need to refresh the file explorer window to see the file size change). Depending on the size of the modules the player can access, this can take a while - and during this time the GM instance of FG will be less reactive than normal.

The good news is, that once the static data is downloaded (i.e. modules that don't change, unless the base module is updated by SmiteWorks) then this download will not happen again (unless the player uses a different computer or clears their local cache).

There are some things you can do to help this:
1) Only allow the players to access the modules they need, and don't share GM only modules. I know it's tempting to share everything, but try not to...
2) Keep any images/maps you create to 2048x2048 pixels and less than 1MB in file size - use JPG format.
3) Leave your GM instance up a couple of days before your session and ask the players to connect when they can, open the modules they need, etc.. This will cache that data locally for each player that does this. If this isn't possible, allow for 30 minutes at the beginning of a session for players to join and get their data.
4) If your GM computer is on a WiFi connection, try putting that computer on a wired connection - this might improve the FG upload efficiency from the GM to the players.

If you have lots of PCs for the players to choose from, then export them to a XML file (using the chat command /exportchar) and send that file to the players. They can then import the whole file into their own PC management campaign or in manage characters (import the XML file from the character management window or using the importchar chat command).

[Trenloe]

The oneshot is basically 6 PCs I created beforehand, some images for handouts and 2 maps, one of those a combat encounter. The total package is ~122 MB.

See the bullet #2 in my post above - keep image sizes to 2048x2048 pixels and under 1MB in file size.

I'd recommend not putting images like these in a module you share with a player. Either have them in a GM only module (that the GM only opens) or have them in the campaign itself - then share these one at a time (via the right-click menu) as and when needed. And still keep the image sizes to within the recommendations.

[LordEntrails]

Welcome to the forums, sorry your having problems.

FG is loading everything, including every image you shared (and it is opening every image in the background). Do NOT share the DMG or MM, do not share maps larger than 1MB in file size and 2048x2048 pixels, do not share dozens or hundreds of images initially, do not have more than a few dozen tokens in a shared folder.

"Module" files do not help players, anything you specify in the campaign "modules" window gets copied to and loaded into the players campaign cache, even if they already have a module of that content (because FG doesn't know if the two modules are identical or not). You can do the creating a local cache trick, or at least you could years ago, but you have to make sure your cache is named identical to the players cache, and you don't turn it into a module, you then send that to the player as a cache and they place it correctly into their cache folder (but why bother? There are easier methods)


You can export the PCs and email the xml file that is created, but don't bother, they are not impacting your load times unless they are corrupted somehow. Just let them select the PC's from the PC selection window.

Finally, check out the FG or FGCollege discord channels, lots of friendly people there who can help walk you through getting started.
The transfer or creation of the player cache only happens once. What I do before starting a campaign is a day / hours before game time I startup my campaign and have the players connect one at a time and allow FG the ~10 minutes or so to download and build their player cache. Remember, your Upload speed is typically 1/10 or less of your download speed, and it's your upload speed that usually is the restricting factor.

[notrealdan]

Hi and welcome!

Keep in mind that while you may (or may not) have a very fast internet connection, your players may not. Even if everyone has a "fast" connection, most fast home internet connections have a fast download speed, but the upload speed is typically a small fraction of that. It is the upload speed at the DM's end that matters in this case, as that will typically be the bottleneck. And FG has to use that upload bandwidth to send ALL of that data to ALL of the players, so at least on the first session, it can simply take a while. What does an internet speed test (such as speedtest.net) report your upload speed as?

[Verkhaz]

Hello, thank you all for your help. I will try to answer the points.

I cant share the oneshot I guess due to it containg some images I bought (Heroicmaps for background).
My internet connection is 16.000kbit/s down, 1024 kbit/s upload. (I highly doubt any of my players being below that, its pretty standard here)

to Trenloe

1. I shared as few player modules aas I thought to get away with, bit hard if you dont really get information of what data is in. From the top of my head Players handbook, Swordcoast players module, xanathars players module.
2. I dont want to sound disrespectful but 1 MB image size is nothing, it isnt 1995 anymore. I am a DM who uses a lot of images and quite detailed "battlemaps". I have been doing that in Maptools for years (and that comes free of charge) since I can just create a folder with the cache files for my players to get beforehand. That is practically what I was trying to do in FG, so far unsucessful.

I am not on wifi. As stated I created 6 lvl 2 PCs.

What I still dont get is if I create a own module with my images, or cache or whatever is the saving grace and upload that to googledrives, let my players download that and put it in the modules folder, why is there still loading ocurring even with my buddy having all official modules and stuff ?
I tried giving him the created cache from using localhost in a 2nd instance, the created module and the whole campaign folder. The module seemed to have gotten rid of the loading at least until PCs were involved.

[Trenloe]

2. I dont want to sound disrespectful but 1 MB image size is nothing, it isnt 1995 anymore.

Nope, it's not - but the application is based on a 2005 architecture. Recommendations are there for a reason. There are various inefficient libraries/processes in the 32-bit FG Classic application - hence one of the big reasons for SmiteWorks to develop FG Unity (64-bit, more recent and efficient libraries for networking, images, etc).

What I still dont get is if I create a own module with my images, or cache or whatever is the saving grace and upload that to googledrives, let my players download that and put it in the modules folder, why is there still loading ocurring even with my buddy having all official modules and stuff ?

As I mentioned - you can see which files are being downloaded and cached on the player side. I'd recommend seeing which files are actually being downloaded and when.

Also, as mentioned, it *will* take time for files to download - even if you have a great upload speed. See the recommendations given above for ways to try to help this initial, usually one-off, large download of data to the players.

[LordEntrails]

Not disrespectful at all, imo. But as Trenloe states, it is what we have to work with currently (FGU is slated for release in December). And I don't mean this to sound... snide, but you can work with the system,or you can fight it because you want to do something else.

Note that the image size recommendations (1mb, 2kx2k) are not limits, but suggestions. The file size will impact transfer time, the pixel size will impact how much memory/RAM FG uses to have the image open. Current FG architecture on the player side opens all images into RAM, so you don't want to overshare or you will hit the ~3GB process size limit of 32-bit operating systems.

[damned]

Hi Verkhaz

You have your module of 122MB plus the PHB plus SCAG plus Xanathars. Lets say its 200MB. You have 5 players. That is roughly 1GB of data you are uploading to your players at campaign initialization.
You have a 1Mbps internet link. The players speeds are going to be irrelevant. Physics says that a 1Mbps internet link will take about 10seconds to transfer 1MB of data.
Teamspeak is going to be competing with this upload for bandwidth and because its bursty its going to get squeezed out.

What are your options?
1. Unshare SCAG and Xanathars (at least for now)
2. Resize your handouts - unless the handout has lots of writing on it - they probably dont need to be bigger than 1000x800px
3. Resize your maps - try to keep your battlemaps under 2048x2048 and 2MB
4. Put your table up early - and have the players connect - on the first session - an hour before the game - to let everything sync across (this might have been reduced now to 50B x 5 players or 250MB or about 40mins)
5. Play session 1
6. Before session 2 put your table up early and share SCAG and Xanathers and have the players connect and let the content sync

Hang in there - you will have to work thru the teething bumps and it will be worth it.