Complete OSRIC mod preview for feedback

[First Edition Society]

Edit - please see this thread with the up-to-date attachments, and discussion/comment for the First Edition Society OSRIC mod.



Hi all,

Works been ongoing for a while on an OSRIC mod designed to work with the official AD&D 2E Fantasy Grounds rulebook and Celestian's 1E extension. The mission of this mod is to automate many of the processes in the OSRIC book, and provide all the widgets necessary to create content and run campaigns using Fantasy Grounds. This is intended to be the platform for additional work by the First Edition Society on Fantasy Grounds for more OSRIC content.

It's a big mod. Work in FGC started in March, and the mod is butting up against FGC's 32-bit limits. The mod itself is complete and I've verified the processes all work, but the ref manual can't be finished. I'll need to break it up probably in order to make it more modular so DMs can only load the portions they'd use in running a live game and not the portions they'd need when creating content for the game to be played.

If you have a moment, I'd appreciate comment/feedback: any table glitches, points of division for separating into multiple mods, etc. This is meant to go up on the forge and will be free. Try out the generators - NPC parties, caravans, pilgrims - all the stuff that is the tip of a gigantic process tree iceberg mostly underwater. Hit the "roll" button and go get yourself a frosty beverage. It might be done by the time you get back

Suggest running it in FGU, as it's scraping the ceiling of FGC.

I'll be AFC for a few days, but will respond to any and all feedback as I can. I appreciate the communities pointers for how to optimize this for Forge distribution!

[Moon Wizard]

If it's hitting FGC limits on a single mod; then you probably need to look at shrinking the graphics to more manageable sizes anyway for both load times and transfer speeds.

Regards,
JPG

[celestian]

If it's hitting FGC limits on a single mod; then you probably need to look at shrinking the graphics to more manageable sizes anyway for both load times and transfer speeds.

Regards,
JPG

The OSRIC book is effectively the PHB/DMG/MM all in one.

I think he plans to split out some of that but right now the OSRIC Full is everything and at 9.2 meg. Which, these days, is a microscopic download in the scheme of things.

[EOTB]

If it's hitting FGC limits on a single mod; then you probably need to look at shrinking the graphics to more manageable sizes anyway for both load times and transfer speeds.

Regards,
JPG

There's hardly any graphics in it. It's just the number of game items. The graphics that are in it were put through photoshop to get them down to a few kb. I'm trying to think of separations between what people would need when playing, vs what people would need to prep and export content those tables create vs being loaded at the same time as an RPG session is ongoing and never used in the game session itself.

[Trenloe]

What isn't microscopic is the db.xml file in the main module - 81MB uncompressed, and over 2 million lines of XML (2,353,694 lines to be precise). This is the largest data module I've seen by a long shot - and no surprise that FGC struggles with it and runs out of memory.

@First Edition Society - FGU takes longer to process data than FGC did. Just opening the full module took around 2 minutes on my computer - which is a pretty high end i9 based Windows computer. The memory use went from 340MB to 7,500MB.

Monumental task putting this together! But it's a little too monumental!!! The main areas that have a lot of records are Table (over 3,700 of them) and NPCs (over 2,000).

So, definitely needs some trimming down and segmentation into individual modules to allow control over what gets loaded.

[EOTB]

Yeah, I think I’ll have to give the final form a break up.

There was no degradation in performance until I put the thin mint of the ref manual on top. Then it puked everywhere

[JohnD]

This is a huge bit of work... I also suggest breaking it up into smaller parts.

Love the ability to generate complete adventuring parties.

[EOTB]

Thanks John!

While AFC, I’ve been thinking about ways to split it between use-to-play and use-to-create.

Play - always load: the players reference (already split) as mod 1 and the monsters chapter as mod 2. For people who mainly play pre-packaged scenarios, this is all they’ll need to load for most adventures on a “dungeon” map such as G1, U1, B2, etc.

Play - sometimes load: dungeon random encounter tables (mod 3); wilderness random encounter tables (mod 4); urban random encounter tables (mod 5). Either mod 3 or mod 4 would likely be loaded with mod 1 and 2. But that three-mod load should be the most you’d need at one time in-game with players, and I think would be a similar computer tax as the 2E computer tax. Mod 5 would be expanded with the handful of monsters on the urban encounter table so the DM wouldn’t have to use mod 2 at all, with its hundreds of not-applicable monsters to urban adventuring. But you’d need to load one of the content creation mods below (mod 6 - NPC class templates). The urban tables pull a surprisingly high number of PC classes of various races and levels into that encounter table. So there’s no benefit to surgical redundancy as with the monsters. That results in urban adventures also having a 3-mod load

Content creation: NPC class templates (mod 6, often but not always used with mod 7); treasure tables including monster lair treasure generation (mod 7); NPC adventuring party generation tables (mod 8, loaded with mod 6 and 7 when used in prep); and random dungeon generation tables (mod 9).

Module 1 nearly always must be loaded in prep as well, of course.

NPC adventuring party tables represent a huge load (400+ tables and other widgets) that would only be drag when not generating NPC parties.

I’m wondering if the NPC templates wouldn’t be better as read-only so that anyone new to FG using the OSRIC mod(s) doesn’t use the template to make a specific NPC, overwriting it in the process.

It seems to me that I can load exported adventures (e.g., N1) with treasure parcels and the magic items embedded in the adventure don’t require the 2E DMG to be loaded to work. Am I remembering correctly? If so, the treasure tables can largely be shunted to prep tables instead of play tables, presuming most GMs make their parcels outside of play.

All of these seem to me to be tables I would use before logging in with five buddies to run a game. And if I am doing campaign-style overland travel where players have a random encounter designated “in-lair”, where they’ve stumbled onto an unplanned monster having some sort of treasure hoard, the GM can load the treasure module after the fight, generate that single treasure with one click while the players take a quick break and high-five each other, and unload the treasure module afterwards.

Does that look like a usable segmentation? Or is that now *too* segmented?

It would take a little while for me to rebuild to that plan, as I think I’d need drag-export the applicable items in batches into their new mods, open up a new campaign folder for each mod, open the exported mod into its new home campaign folder and then drag copy each item so I have a clean folder for fixes and re-exports into updated mods as-needed.

Plus I’d have to “re-drop” all the shields as I go so that where mods do interlink (e.g., monster treasure buttons in a monster description), it’s telling the DM to load the new segmented mod and not “full OSRIC” to use that button.

But that process will still be much faster than it was to make the various items from scratch; it’s doable.

[EOTB]

Also wondering: should I make the DM’s half of reference manual it’s own mod so they can always have the full ref manual at their fingertips even if not loading some mods.

I don’t think (?) a reference manual by itself takes up much space/resources if cosmetic JPGs are left out.. It seems more convenient than having many mini reference manuals loading with segmented content mods.

Feedback here would be appreciated also.

[Trenloe]

Other ruleset modules do full reference manuals in one module. The Pathfinder Second Edition Core Rules module, for example, has full reference manual of the base 640 page rulebook/PDF, and this includes a lot of images too (200 in total). The reference manual in itself is not an issue - it's the shear number of records and amount of data that becomes an issue.

As I mentioned earlier, the full OSRIC module linked in post #1 contains 2.35 million lines of XML. The PF2 core rules I've just mentioned, which is a large module by comparison to most, weighs in at "just" 75,000 lines of XML (30 times smaller than the full OSRIC module). Now, just counting lines in an XML file doesn't give a complete picture, as some lines may have a lot of data (especially those with text) whereas others may just have a simple number, but it gives a good idea of the shear huge size of the module.

You can also open up the db.xml file in an XML capable editor such as Notepad++ and look at where the biggest type of data is being used. Note - this will take a long time for such a big file, and Notepad++ will go "not responding" a few times - just leave it to complete what it's doing.

Here's the db.xml file from the full module, with the first level of records collapsed - noted the line numbers to the left of the main FG record types:



Looking at the big records:

1. NPCs - 1,750 thousand lines
2. Tables - 331 thousand lines
3. Items - 150 thousand lines
4. Reference - 55 thousand lines (this primarily includes the Reference Manual).
5. Classes - 30 thousand lines
6. Spells - 25 thousand lines

So, this ties in with what I mentioned earlier - NPCs and tables are the main areas, with NPCs being massive compared to the rest - taking up 75% of the whole module!

If I just remove the NPC data from the module, in game module load time drops to around 20 seconds and memory use is at about 1.7 GB (compared with over two minutes and 8 GB for the full module).

So, I'd recommend that you split this into at least three modules - maybe more.
1) A player based module - classes, items related to players, spells, just the relevant tables, etc.. This will still be a big module, but can be loaded by the GM and players and won't overload the player side. Player relevant reference manual.
2) A GM based module (not including NPCs) - GM related tables, magic items, treasure parcels, etc.. GM relevant reference manual.
3) At least one NPC module - I've recommend splitting these further along the lines of the categories/groups you have - allowing the GM to open the relevant NPC module/s as needed, and close them down after. The following screenshot shows where the most data is in each NPC group/category, this will give you an idea of where to split your NPC modules up (for example, Demi-Humans has 570 thousand lines):