Start-up/Loading times

[DNH]

How long should it take for FG2 to start up and be ready to play with an existing campaign? I ask this because sometimes I have to wait as long as 15 or 20 minutes before I get to the main desktop, and that seems like a very long time to me. I understand it may be due to a lot of XML parsing going on, perhaps having more characters in the campaign slows things down a lot. But is 15-20 minutes excessive?

FWIW, my PC is not the latest and fastest machine around but it's fine for everything I ask of it (which includes the likes of LotRO). Admittedly, the drives probably need defragmenting, which would help, but that's about all I can think of.

Any thoughts?

[Spyke]

I wonder if you've got lots of tokens?

Spyke

[Dupre]

How long does it take to start the Tale of Dinor example campaign on your PC? For reference, a five year old laptop we test with loads it up in 8 seconds.

[Tenian]

Modules seem to dramatically increase load time. Running with as few modules open as possible vastly improves the load speed. The larger the module the worse it seems to perform.

I wonder if cleaning out the moduledb directory for reference modules (i.e. not the adventures you have masks/saved tokens) wouldn't improve performance. I know my reference modules get changed fairly frequently as new parser features are changed/added.

[Griogre]

Even if you are having to use virtual memory it shouldn't normally take more than a minute or so to load FG and that is an eternity for a computer.

Like Tenian has mentioned loading every module does seem to extent the load time of FG. I cleaned out the moduledb folder for most of my ongoing campaigns recently because some of them were getting huge. It was 14 megs of mostly 10 and 12K files. I wondered at the time if those files weren't suppose to overwrite each other.

DNH, you might want to send the campaign file and any module files you have open to FG support so they can take a look at them, it is very strange you have to take that long to load FG. The only reasons I can think of is that ou are having to use virtual memory and your hard drive is just about full so you are thrashing, or you really have gigs of module data which would really trigger having to use virtual memory.

[Tenian]

I think each file in the moduledb is supposed to represent changes that occur with the module. Sort of incremental changes.

The problem is 4E modules tend to change alot as new parser features are changed/added. I think this might be causing the moduledb to bloat. The Dev's can probably give a clearer indication as to what the folder is for.

Most other rulesets don't have the expanding module issue. As they tend to either have unchanging reference modules included at the time of install, have no modules, or the modules are manually built (and usually smaller).

[DNH]

That's an interesting point. Just what can be got rid of? Can I delete everything from the moduledb folder? Will new files get written here? What about 'db.backup.xml' or 'db.restore.xml' - can they go too? And the contents of the temp folder? Or the chatlog?

Is there anything, in short, that I should *not* delete, that will not get rewritten by FG2 if missing?

[Tenian]

I believe the moduledb contains the mask info / any changes you've made to the module.

I would copy my campaign to a new directory, delete the moduledb for the new campaign and then load it. See what's missing.

Exit and load it again I suspect modules will take a long time to load on their first pass.

[DNH]

What about CampaignRegistry.lua? That looks to keep track of the positions of every window ever opened in the campaign. Some of them become irrelevant, but how to clean them out? And is it worth it?

[Griogre]

It doesn't hurt to clear out CampaignRegistry, but it would have little effect. Primarily it holds window positions and combat tracker info. It should be a small file.

Like Tenian I think the moduledb is suppose to be the differance between the actual module file and any changes you have made to the module while it was imported into your main campaign. You would think there would be a max of one file per module but FG appears to continoulsy generate the files each time you load the main campaign, at least with the 4E ruleset. There also appears to be a check sum number in the files.

If you haven't made any changes to the imported module entries then you could safely delete them all. When I was cleaning things out for my 4E campaigns I just sorted by date and got rid of everything prior to my last game.

Purging your campaign of obsolete charaters will greatly decrease the size of your db.xml file for the campaign. One of the biggest components, size wise of the campaign's db.xml file is the character sheets. I got rid of 6-8 old characters out of my oldest campaign and halved the size of the db file.

[DNH]

Thank you to everyone for your help and suggestions. I have done everything suggested here but the only thing that made any noticeable difference was paring down the modules folder to only those I *know* will be used in the session. So I took out all my adventure modules, any reference books I don't really need in-game, and so on. The start-up time was much reduced ... which is what you'd expect when the modules folder dropped from 114MB to just 23MB!

Thanks again.

[DNH]

I wonder if you've got lots of tokens?

Spyke

I do have a fair amount of tokens of a fair size, averaging about 30KB or so each one. My question is this though: do I need to hold these in the FG2 tokens folder if all (and I mean *all*) of my tokens come from modules?

[Spyke]

I do have a fair amount of tokens of a fair size, averaging about 30KB or so each one. My question is this though: do I need to hold these in the FG2 tokens folder if all (and I mean *all*) of my tokens come from modules?I tend to keep my tokens outside the FG2 structure and just copy in the ones I'm likely to need for a game (often just the ones in the module). I'm not sure whether it affects start-up time but it definitely helps during play.

Spyke

[Griogre]

If the tokens are in the shared tokens they may need to be transfered each time. I'm not sure if they are cached. The ones in the host tokens are only transfered when used.

Personally, because of the token crash bug I don't put tokens in modules. However they may have fixed that bug recently. I haven't had a chance to test it because you need a token new to all the clients and at least 5 or 6 clients connected to be sure.