World name is Skaz'Dhuk. My guess is the apostrophe is messing with it somehow. The folder path in the settings is correct. I assumed in the error message it was just truncated, but maybe not.

The module should be using the path in which the world is stored.

When a world is created, a World Title is entered and a Data Path is entered.

The default image location should be set to the "Data Path" with "/realmworksimport" appended to it.

e.g. my test world with a title of "Test RW Import 0.8" is stored in the path "Data/worlds/rw-import-0.8". The module's "Location of Extracted Assets" was automatically set to "worlds/rw-import-0.8/realmworksimport"

Do you have "Skaz'Dhuk" in the Data Path as well as in the World Title?

Update: I tested by creating a realm with both title and data path set to "Skaz'Dhuk" (without the double quotes), and the realmworksimport directory was created correctly. The title and path had the simple single quote mark in it, not a back or forward tick which you can sometimes get in document programs like word.

New version 0.3.15 has a small improvement to place Actors into a sub-folder named after the containing topic. (But with the proviso that if the topic has only one actor AND the name of the actor is the same as the name of the topic, then no sub-folder is created.)

Version 0.3.16 tries to store the statblock somewhere in the Actor sheet for ALL game systems.

For PF1, many of the other fields in the Actor sheet are extracted (this has been available for a long while).

For all other game systems, the HTML of the statblock will simply be copied into an appropriate Notes or Biography section of the Actor sheet.

First, thank you so much for doing this! Being able to actually get my nicely sorted Realm Works material into a quality VTT so I can actually reveal it to my players and integrate it into our sessions is going to be awesome.

Second, I have a question on best practice. So I'm kind of wandering what people are doing as far as updating materials. Earlier in the thread there was some mention about re-exporting newly updated topics from Realm Works to Foundry, but what if it happens the other way? Let's say that during session we end up making notes on a scene/topic/Foundry-thing. Now, when we update, I'm assuming we lose that if we over-write it. And there is of course no way to have it automatically transfer from Foundry back to Realm Works.

But this does give me an idea. Would there be any way to have the tool tell us when it is going to update data that has been changed in Foundry since the last time the tool updated it? I suppose that would only address part of the issue (there's still needing to know which info you've updated in Foundry but not in Realm Works, so you can update it in Realm Works also--but that would require some sort of database changelog in Foundry), but it would be something.

Anyway, just wanted to get the thoughts out there in case they weren't already, and thanks for the cool tool!

Transferring information back from FVTT to RW wouldn't be possible because the UUID identifier required on each individual snippet of information isn't stored within FVTT (and several snippets are merged together to form the journal entry text, so it isn't easy to rebuild snippets from FVTT).

I don't think FVTT keeps a record of when something was last updated, so it would be difficult for my module to know if something is original or modified. It could be a future (difficult) extension for my module to take two import files, try and determine the differences, and then apply only those differences to Foundry VTT - but it would be a very complicated task to do this.

I'd already created an issue in github to suggest this function, but the more I think about it, the more complex it appears. The issue is https://github.com/farling42/fvtt-im...orks/issues/19

Thought I'd take a peek at the forum after a long period of not bothering and was very excited to see this. Thank you Farling for taking this on and sharing it with the community.

I host my instance of Foundry on The Forge, and my Realm in RW is large. So, it'll be interesting to see how it handles the import.

I'm assuming that there is no roll back and that it would be prudent to create a new World in Foundry to test. Are the scenes, journal entries, etc. foldered in such a way to indicate that they are from RW? Could I just delete a top-level folder if I want to remove all the imported content?

Yes. They end up in a folder named Realm Works, so can just pull out want you want and then delete the folder.

At least this was true a few versions ago, when I imported my realm and I don't know why Farling should change that.

I host my instance on my own server, but if the importer module is available for Forge installs, I don't see a reason why it shouldn't work just fine.

Version 0.3.17 tries to calculate HP for PF1 actors better.
It also supports linking to items from "Pathfinder 1e Content" module during actor creation (if they aren't in the basic PF1 system compendiums).

You are correct, there is no roll back. So definitely create a copy of your world before trying the import.

Yes, you specify the name of the top-level folder into which all entries are imported. For journal entries, each is then put into another sub-folder based on the category of the RW topic.

All the conversion is done within your browser rather than the server. So that is where you would need processing power ;-)

I might also suggest that if you are still using RW for your world management, then you could try importing only a partial RW output rather than the entire realm?

I don't know anything about Forge, other than they have made changes in some way that mean it isn't a standard Foundry VTT installation. My module is available directly from within normal Foundry VTT from the module listing, I just don't know of Forge uses that function.

My Knowledge of Forge is spotty as best as I haven't used it myself, but from what I gather, they only allow a subset of modules on their servers. So my guess would be: if a user can select a module while on a forge instance, the module will work fine.

But maybe that's a question better asked on https://www.foundryvtt-hub.com/

A question for users of this module...

Which game systems are you using for which you'd like your statblocks imported to your Actors?

At this stage I'm not proposing full decoding, simply the ability to have Actors created and the statblock from RW imported into a notes/bio/description field on the corresponding Actor sheet.

I've got this working for a lot of game systems, but I can easily add additional game systems - I just need to know which of the 50+ available game systems I should actually do this work for.

I just got a chance to try it out, and have some thoughts.

First thought is it's really cool. I was surprised how nice it came out looking.

Additional thoughts are suggestions for tweaks.
-Is there anyway to make an option for un-revealed snippets to be hidden/secret by default? I know that's being used for GM secret notes, but really, unrevealed snippets are essentially secret and it probably wouldn't hurt anything to use that functionality for them both. Or an option at least would be great for me, since I extensively use the revealed/unrevealed Realm Works feature to let me know what information the party knows.
-I can't seem to find links from the scene note associated journal entries (that was a cool thing to do, by the way!) back to the scene. It would be great to be able to see a link to the scene from the journal, so they are connected in both directions.
-This probably isn't under your control, but in case I'm wrong, I noticed that the alphabetical sorting doesn't work right for numbers--it's going by the first digit so 100 is before 2 in long lists of journal entries.

Those are the things that I ran into pretty quickly as features that would improve the experience for me.

I just got a chance to try it out, and have some thoughts.

First thought is it's really cool. I was surprised how nice it came out looking.

Additional thoughts are suggestions for tweaks.
-Is there any way to make an option for un-revealed snippets to be hidden/secret by default? I know that's being used for GM secret notes, but really, unrevealed snippets are essentially secret and it probably wouldn't hurt anything to use that functionality for them both. Or an option at least would be great for me, since I extensively use the revealed/unrevealed Realm Works feature to let me know what information the party knows.
-I can't seem to find links from the scene note associated journal entries (that was a cool thing to do, by the way!) back to the scene. It would be great to be able to see a link to the scene from the journal, so they are connected in both directions.
-This probably isn't under your control, but in case I'm wrong, I noticed that the alphabetical sorting doesn't work right for numbers--it's going by the first digit so 100 is before 2 in long lists of journal entries.

Those are the things that stood out to me as options/features that would improve the experience for me.

Not looking at the code but I would guess this is happening because its not really seeing those as numbers but as text so it makes sense. Probably won't be anything that can be done.

The only way I've ever found to work around this is to add placeholder zeros (e.g. "2" is numbered "002"). Don't know if that would work here or not.

That would probably work I know I've used that in other places that i've had numbers stored as text.

The RWoutput file doesn't include information about which snippets are revealed or hidden. The only way to get this information from RW would be to have RW produce a filtered output rather than a full output.

I've added an issue to remind me about putting links from the Journal Entry to the Scene (since the other way already exists). I think that the scene is always given the same name as the journal entry.

The alphabetical sorting is definitely an issue with Foundry VTT - for my own worlds I've switched off automatic sorting and rearranged them manually. I think this could be an option, possibly, to put topics in the same order as they appear in the RWoutput file. I will see if disabling the auto-sort puts them in the RWoutput order.

Thanks!

One other thing that might be useful is if the import included information on which topics contain and are contained by others. My realm is extensively organized in that manner for physical geography, and I while I know Foundry doesn't (and probably never will) support that style of organization, having the info there makes it a lot easier to adapt.

Each journal entry created from a topic will have a "Governed Content" section near the end, this contains the list of child topics from Realm Works.

Unfortunately, at the moment there is no link from a child topic back to its governing topic.

Ah yes, and so it does. I must have forgotten that it's there in one direction, just not the other.

I have an issue identified (https://github.com/farling42/fvtt-im...orks/issues/32) for going in the other direction, but it isn't so simple because of the way that the file is loaded. Topics are read one-at-a-time from the file, in order to support very large files.

0.3.19 now creates a link to the parent, and puts it at the top of the Journal Entry. You can set the prefix for the link in the module settings.

Also...
Add module configuration setting to set the preferred Actor type when generating Actors from statblocks.

When decoding PF1 Actors, check for presence of "challengerating" element to choose 'npc' Actor type instead of 'character'.

Better fix for HP calculation of PF1 Actors for Actors with multiple types of hit dice.

Create link at start of each Journal Entry to the parent topic. The label for this link is a configurable parameter.

0.3.20 adds some more linking...

The "Governed Content" will now contain the full hierarchy of descendents rather than only the direct children.

Provide link from Scene Notes journal entry back to the Scene - although clicking on the link will not do anything, since the default behaviour for a @Scene link in Foundry VTT seems to be to open the scene notes associated with that scene (and not switching you to that scene).

Cool thanks!

(There's a mod that lets the scenes links in the journal take you back to them, so that part is covered.)

Full hierarchy might not be ideal for all worlds. For instance, one of my top level topics is "The Multiverse" which includes all geographical areas nested underneath it, so if I'm understanding the feature correctly, it will have thousands of governed content links. Maybe it could be a toggleable option?

I was considering how to get the content hierarchy to be collapsible, but it appears that raw HTML doesn't allow it and you have to mess around with CSS and possibly JS as well.

The way that the module creates the hierarchy of governed content does lend itself to allowing a maximum depth to be specified - this would allow a top-level journal entry to perhaps be limited to showing 3 levels of descendents rather than the full tree (and setting it to 1 would disable showing anything other than direct children).

0.3.21 adds a configuration parameter in the module settings panel so that you can specify the maximum depth of the governed content added to journal entries.

Yeah, that's a better a way of doing it than my idea.

0.3.22 allows you to specify that image/asset files can be located in your S3 storage (if you've configured it for your foundry server).

0.4.0 adds the decoding of D&D 5E portfolio files.

It also removes support for 0.7.9 of Foundry VTT.

0.4.1 fixes a bug introduced in 0.4.0 which meant that the module would fail to initialise if you did not have the D&D 5E game system installed on your Foundry installation.

0.5.0 will now set the disposition of the default token of NPC actors to match the allegiance found in the HL portfolio file.

It also adds support for Savage Worlds HL portfolio files. It will import into the FVTT Savage Worlds game system, and will use the compendiums in the "Savage Worlds Core Ruleset" premium module if installed.

It has not been tested with the HL "Adventure Edition" premium content since I don't own the "Savage Worlds Upgrade to Adventure Edition".

Is RealmWorks necessary? Or can exports be done from Hero Lab?

I've held off buying RealmWorks because when Hero Lab announced they were doing layoffs, they indicated they were no longer supporting RealmWorks.

This seems like a big time saver....but does it require buying a no longer supported piece of software, just to get an export to work?

Hi Aril. I don't know the answer to your question, but wanted to point out that while support has been scant it's not non-existent. A few months ago they fixed an import-export bug, and a bug that kept RW from integrating the 64 bit version of HeroLab.

What they actually said was specifically that they ARE still supporting RW, but that it is no longer in development.

Gotcha. How much does it have in the way of features? I hate the idea of paying monthly for software, but when they made that announcement re: RealmWorks, I changed from planning to buy that, to subscribing to WorldAnvil instead, and though WorldAnvil is neat, it's a progressive model where all kinds of features are kept back from you unless you pay even more.

I think the only feature that was initially intended that didn't get implemented is the calendar.

I use it all the time - it is by far the best, most flexible world building/campaign management tool I've seen (and I've been playing a LONG time :)).

You buy the software once and can install it on as many machines as you wish and don't HAVE to pay any monthly fees just to use the program.

BUT, to sync your realms between machines (and to allow your players to sync to their machines if they've chosen to buy RW themselves) you do have to pay a small monthly server maintenance fee (well worth it, in my mind).

Hi Aril, the module will load a .por file directly and create an Actor for each sheet in the .por portfolio file. If it is PF1, D&D 5E or Savage Worlds then it will also try to populate as much of the Actor fields as possible; otherwise it will simply store the statblock in the Description/Biography field of the Actor(s).

0.5.1 fixes a bug.

Snippets are now placed immediately after the section header when the section has sub-sections. (Previously they were put AFTER all sub-sections, and so appeared to be part of the last sub-section.)