Test Release v3.2.0

My 4th edition ruleset spits out "out of memory" when I try to open a module that was created using the 4e parser. This module works fine in 3.1.7, this only occurs on 3.2.0.

How many items in it? The 4e library contains almost a hundred thousand entries from memory....

I think around 7000 items all up for the PHB pre-selection. :/

Can't find it, but I thought Moon mentioned earlier that 3.2.0 uses more memory than 3.1.7. Not sure if that's just going to be the way it is, or if he was working on it.

Quote:

---

Originally Posted by LordEntrails

Can't find it, but I thought Moon mentioned earlier that 3.2.0 uses more memory than 3.1.7. Not sure if that's just going to be the way it is, or if he was working on it.

---

Yea I think that was in relation to my last report on having x number of modules loaded and getting memory full issues. Can't remember what page but they are aware of it. Just posting every different occasion it's come up (since this was just one module, albeit large)

Quote:

---

Originally Posted by LordEntrails

Can't find it, but I thought Moon mentioned earlier that 3.2.0 uses more memory than 3.1.7. Not sure if that's just going to be the way it is, or if he was working on it.

---

I believe it was here > https://www.fantasygrounds.com/forum...l=1#post280027

So, a small issue with the manual roll window, this is present on both the 5th edition and 4th edition (all I've tested so far). When using the newly added button to roll instead of input, the result does not apply if it is an attack or a saving throw.
For example, here is the attack rolled with manual rolling OFF (top roll) and then again with manual rolling ON and using the dice button to auto-roll. https://puu.sh/qHVC9/9d4980b586.jpg
Damage does seem to apply correctly, however. It only affects attacks and saving throws.

Quote:

---

Originally Posted by Moon Wizard

I'm going to look into it, but the current FG client has always had troubles dealing with very large lists of any sort, and even with having lots of modules open at once. I just don't know if the architecture can handle all those modules open at once, at this point.

I'm guessing that you would have seen some slowness in the primary Story list and NPC list even with v3.1.7 with that many modules open.
With v3.2.0, we're talking ~2500 NPCs and ~4800 items with just the 5E modules I have on my machine, and trying to display those in a single list.

There are two things I think might be going on:
* The drawing code is having trouble handling thousands of individual list record windows (and possibly some numerical boundary considerations).
* The memory limit is getting reached, since having all those data modules open plus all the memory used by the windows.

I'm close to 1.7GB with my module set and that's about the boundary for 32-bit applications (2GB including stack) unless the OS supports the extra memory option (which bumps it to 3GB including stack). If it hits this boundary, it will cause a crash. This is what I guess is happening.

---

For 5E specifically, I'll add something else to that list:

Most of the non-adventure 5E products use Reference Manuals, which are awesome. However, they are split into two sections: the actual Page Content that we read, and Index Content which are the links we click on the left column but more importantly it contains search keywords. Since everyone is using PAR5E except me, what I'm noticing is that PAR5E takes the entirety of the Page Content, strips out the punctuation then puts all that into the <keywords> tags. So effectively you have two versions of every Reference Manual loaded at once, doubling the memory required for that part of a module.

Additionally, PAR5E misses a few items like the Bold Paragraph, which is strips out both sides of the parser markup but leaves the "b" attached, ie. if the first word in your bold sentence is Strength, the keyword PAR5E spits out will be bStrength which isn't a word anyone would search for so now that's just taking up a few bytes of memory. Hyphenated strings get merged into a single word so "all-clear" will become "allclear" which again, no one would search for. All these are small issues but when you consider the entire manual is being duplicated into keywords, they add up quickly.

What I've been doing is going back into the XML, copying the <keywords> section into https://tools.perceptus.ca/text-wiz.php?ops=4 then putting the results back into the keywords to save memory and filesize. I'm debating if I want to remove common words like "a" "an" "the" and so on or not, too.

But anyway, for 5E PAR5E products, the Index is definitely part of the problem with memory usage.

3.2.0 just went live?

Nah - Im an idiot - please ignore me.

Damn you damned. You got me!