PDA

View Full Version : FG2 Crash on Load od Campaign



Zeus
June 21st, 2009, 18:23
Hey all,

I'm experiencing a weird issue under 2.3.6 which results in FG2 crashing upon restart/reload of a campaign which contains a specific open module. I am hoping someone can point me in the right direction or confirm if this is a known issue.

Firstly I am running FG2 on a 64bit Vista system with the latest 4E_JPG 1.51 ruleset. I am using a H1 KoTS module I created by compiling the story elements (through the FG2 interface) and using monsters, items etc. from parsed rulebook modules (using Tenians 4EParser) and then /exporting the whole lot.

Now in general everything is fine, ruleset/modules (including KoTS) work and my players are able connect to me and enjoy some fine virtual RPGing. I have run serveral sessions without any in-game incident.

The problem comes after I have shut down the server and restart FG2 and reload the campaign (usually the day after a game session to update notes etc). As soon as I start FG2, select the campaign and Start, FG2 crashes after about 3 secs. Attempts to reload FG2 and the campaign result in the same crash, FG2 is not responding blah blah.

Inspecting the campaign folder and specifically the modulesdb subfolder I find in all of the 1KB files a single file (4e H1 KoTS.xml) which reads at over 2548Kb! Opening the suspicious XML file reveals many recordname entries have double chained entries.

e.g.


<class>encounter</class>
<recordname>encounter.id-00016@4e H1 KoTS@4e H1 KoTS</recordname>

Some records even have triple or quadruple repetitions so am pretty sure something is wrong.

Manually replacing every duplicate/triplicate or quartet reference to @4e H1 KoTS with a single entry and resaving the file fixes the issue and FG2 loadd up the campaign without error.

Now at first I thought it was a one off but this is happening now after every sustained game session. Has anyone else encountered anything similar?

I admit to only using the 4E_JPG ruleset so cannot confirm if this occurs in other rulesets. However given the module in question was created using /export and given modulesdb is not specific to a ruleset I'm inclined to suspect the issue maybe with FG2 and how its maintaining modulesdb. Having siad that I am no expert so what do I know, it could be anything.

Any help would be much appreciated as the resolution whilst pretty quick is a pain in the a*@ to do after every session.

Thanks Z.

Zeus
June 21st, 2009, 18:42
I should add that even though I have edited the XML file and removed all duplicate chained references. As soon as I have closed FG2 after a game, all the duplicates, triplicates etc. are back?

The affected recordname entries all relate to <shortcut> elements. Am I right in understanding these relate to Shortcut Pin data for maps?

If so I recall hearing of a problem with having more than one pin on a map that links to a single encounter, however I thought this had been fixed. The module does indeed contain maps with multiple pins (some of which will point to the same encounter/story element). Could this be the cause of the problem?

Griogre
June 22nd, 2009, 08:28
You module just may be corupt. If it is always one module that gives you problems, ie H1, just load that module campaign up and re-export it.

Zeus
June 22nd, 2009, 09:32
OK. Will re /export and see if that makes any difference.

Tenian
June 24th, 2009, 22:38
I'm getting the same thing on one of my modules. It crashes if I close it and re-open it. Fortunately I have a backup of the campaign and restoring the module DB folder fixes the issue. Until the next time I save.

Tenian
June 24th, 2009, 22:45
It only seems to be the <shortcut> elements of images that are multiplying.

In the original module none of the shortcut elements have @ designators. Is this the problem?

Griogre
June 24th, 2009, 23:08
Possibly, however the @ designators in 2.3.6 and below didn't work. I don't know if they work now but if they fixed that in 2.4.x then something might have problems.

Dupre
June 25th, 2009, 11:08
Thank you for the feedback everyone. Upcoming 2.4.2 includes a fix for this.