Importing Character XML Like Images

[ericidyll]

Hi all,

Does anyone know of a good reference to all of the events available for FGII scripting? In particular, I need to know about the imageupdatefolder, and everything around it. I have been told elsewhere that it would be difficult to have character import while playing, but I have strategy that might work.

My idea is to have a folder that monitors for new files or file changes. XML files added to it can be made available in FGII, and when double clicked, Lua could validate that data and load it into the DOM where characters are stored in the ruleset I am using (Spyke's GURPS 4e).

Alternately, I could make it so that dragging that XML to either personalities or the PC character window would produce either an NPC or a server PC, respectively.

It seems I can only get started on this if I find out the events associated with the imageupdatefolder (onImageUpdate?), and if I can find out whether the image filtering in the imageupdatefolder "image" is happening in a scriptable way, or whether it is coded in the FGII core application. I already tried putting an XML file into the images directory, but it would not be presented to me in FGII. I hope this filtering isn't hard coded, and is Lua accessible.

Any pointers or advice? Has someone perhaps done this for some ruleset already?

Cheers,
~Eric

[Griogre]

Smiteworks deliberately turned off the file access parts of LUA for security reasons. You might try the referance here for the other: https://www.fantasygrounds.com/refdoc/

[ericidyll]

So for this to work ddavidson would have to hard code a character import folder that would allow loading of files contained therein into FGII. With a sandboxes directory like that, it would be pretty much the same level of risk as running ruleset XML files with Lua functions in them already, right?

So how do I get Doug interested in this feature? By getting other people interested in it? Through a poll maybe?

[drahkar]

Its more involved than that. Because Lua file access code will not be enabled, they would have to hardcode all of the functionality for the directory, the monitoring for file changes and opening and using the data. None of it would be able to be done through Lua.

The most common way of implementing character imports currently is by making a separate script/program that takes the db.xml and the imported data and inserts the import data into the db.xml for use. But without significant development within the FGII engine itself, I don't see how this would be done within the platform.

[ddavison]

I have been thinking about this for a while actually. I ultimately want to allow people to print characters from XML to HTML by selecting the name of an XSL file in a specific folder under the ruleset. I would also like to allow importing of XML and maybe HTML and Text using the same basic method. We will need to build in XML validation to ensure it matches a DTD which would need to be included with each ruleset that supported those features.

This entire process would be not just for printing, saving and transferring characters between campaigns but it would also open up compatibility and interface options with other helper programs like character builders. For 3.5 games, for instance, it would be nice if you could dump a stat block into a screen and have it generate either an NPC or a PC character for you depending on which XSL import file you selected.

[Zeus]

Yes. Yes. Yes.

I'm glad this is being considered, given your experience with XSLT Doug I thought this might be high on your list for possible inclusion into the main FGII app.

Its ironic though as only this week someone asked in a post on how to export Tables and other campaign objects from one campaign file to another and I considered updating the external .NET tool I pulled together last year to include other objects aside from PC character sheets.

Now I know this is being considered, I'll shelve the update.

Z.

[Foen]

Eric has an interesting idea though: the engine monitors certain directories and brings their content into FG. The directories are ruleset-configurable, and PneumaPilot has previously demonstrated that you can have multiple such directories for a ruleset (one for images, one for maps etc). Aside from his nWoD ruleset, I'm not aware of any others that make use of this facility.

If the engine raises an event (onChildUpdate perhaps or onChildAdded) when the newly-added item is inserted into the database structure, then this approach could be used to capture added resources. Although I haven't tested it, I think the snag would be that the object added to such a directory would be treated as though it were an image file (even if it was an xml file instead) and there is no way of accessing the content/text of the added object if it is treated as an image.

Good thinking though, and very interesting. I think something similar was contemplated a year or so back to trigger music playing, although I can't find the thread.

Foen

[drahkar]

Doug, that would be a fantastic implementation. I've been working on a small conversion application for doing just that, if we could have it all supportable through the interface using DTD conversions, that would be fantastic.

[ericidyll]

@drahkar: Ah, right, right, the loading of files would be hard coded. So something like the image folder. When a file is added, FGII sees this, and grabs the filename to present in the listing. When the small object behind the filename is dragged anywhere, it would load the file into a DOM object for the file, and trigger an event. This event would presumably contain the object that the filename object was dropped on as well as the DOM object, and the ruleset could make use of those two pieces of information to do whatever it needs to. This wouldn't require any file loading properties in Lua, and since it would be using a specified directory, there shouldn't be privacy concerns. The other type of security risk I can think of is if malicious code exists in the file loaded, but this wouldn't be any worse than loading a character client side, right?

@ddavidson and @drahkar: Validating against a DTD could be nice, but would require additional overhead when developing a ruleset. Although you could know you are getting a valid file, loading characters during character sheet development would lead to a requirement that you update your DTD with every structural change in the character sheet. With differing formats for NPCs and PCs, as at least some rulesets have, this issue gets doubled, and introduces a second "hard-named" DTD for any hard-coded valdiation routine to check. Though this might not seem like a big deal, this suggests that it might be nicer to leave DTD validation up to the ruleset. DTD fetching could clearly be done by FGII hard code, with a DTD included in the ruleset as Doug describes. But the calling of the validation routine would be better to leave in Lua's hands. After all, it's up to the ruleset to determine what valid data looks like, so it should probably be up to the ruleset to determine when to check data. Do you agree?

@everyone: Spyke made an importer for his GURPS ruleset, and this is great for loading characters up prior to playing. Personally, I could put together a character based on a template or unfinished character file quite quickly in GCS, and being able to load it while FGII is running would be great.

Perhaps more important is that if this facility existed, any given ruleset would have import functionality without someone having to build it. Any ruleset would be able to bring characters into campaigns and perhaps into libraries swiftly. The ruleset wouldn't have to do much either; depending on whether the character is dropped onto the Personalities icon/window, the Character Selection icon/window, or a Library icon, it would conditionally load the existing DOM object, already parsed from the file, into the appropriate portion of the DOM holding Personalities, Characters, or Library entities. I'm not sure if these DOMs are accessible to Lua, but I'll go out on a limb and assume they are.

(gee I'm long winded)

I'm glad there's some interest in this from at least you four. I feel this sort of facility would be handy for any ruleset. Excited!