How to keep the holder value when exporting characters

[Alynn]

Currently in my project the middleware software, in order to pull the player name from the database, needs to touch the db.xml file directly and compare the character IDs to pull the correct one for every character. Everything else can be done directly on the exported character sheets. While this does work, I would rather not touch the db.xml file with the middleware if I can help it.

The problem no matter how many different ways I've tried when using DB.export the Holder/owner node is never exported with the rest of the character. I've tried doing a separate export pulling charsheet.*.holder, but it looks like we don't like wildcards for export.


So I am looking at getOwner and wondering if I can use File.writeTextFile to make my own xml file with holder information in it. However, getOwner or getHolder requires a direct db node, and since the nodes can be id-xxxx where xxxx is some set of numbers under charsheet; looping through all 9999 of them would be a terrible idea.

So is there any other way that I can export the character data with holder/owner information intact, OR be able to export holder/owner information to its own file.

This is more of a better to have feature. The middleware works as presently coded, but if I can keep it from touching the db.xml then there is no chance of the middleware affecting the db.xml file and causing corruption.

Thanks in advance,
Alynn

[Moon Wizard]

DB.getChildList("charsheet") (or DB.getChildren("charsheet") would return the list of all character nodes.

Regards,
JPG

[Alynn]

There we go, that was the hump I wasn't seeing. I now have an owners XML that has the holder data I need.

As a suggestion, if possible adding a new boolean value for DB.export so that we can choose to keep or discard the holder information.

Thanks again, now everything is fully working on the FG side, now it's time to do some tweeks in the middleware to mach the new stuff.

[Moon Wizard]

Holder information is not relevant for export in almost every situation. Export is for creating data packs for to share information, so holder information would actually cause issues.

Regards,
JPG

[Alynn]

Ah gotcha. So would it be easier to add a <playername type="string">playername</playername>

I mean in all reality if I'm the only use case that could use that information I can totally understand not implementing anything like this at all. But thank you again for the help. All the testing is complete on this end of it, and now I can adjust the middleware to work with the new files.

[damned]

If you are also creating an extension you can create new hidden fields that hold this info. The two fields you mention holder and ID are pretty much the only fields that dont get exported. (ofc you will prolly find another one now that I said that). Sync the non exporting data to these new hidden fields and then you have access to the data.

As to editing DB from the external tool - you cant if the DB is in use. The db.xml is not the live data - that is stored in RAM and written periodically to the db.xml file.

[Alynn]

Yeah I got it now. The whole issue is that initially I just had what I'm calling the middleware. I was initially using prostream, but it didn't do everything I needed, so I wrote my own parser to do what I needed; this is what I am now calling the middleware. I decided because I'm a glutton for punishment to make a Twitch extension to show this data. So I basically created the twitch extension portion. I just now finished creating the FG extension portion. So now i need to go back to the origional application, and make some adjustments to 1) make it configurable from a single file to point to the locations of the output files. Start up a webserver and have it be able to send the correct JWT for the files it is serving back to twitch.

So basically I had a working thing, then decided to make it the middle agent for a whole Twitch Extension. And because I figure other people would want to use this, I had to make it as dummy proof as possible. So instead of making one thing at a time from one end to the other, I made the middle, made the two ends, and now going back and making the middle work with the ends. It's backwards but hey what are you gonna do?

Interesting about the db.xml. In my mind it was a bad idea to mess with anything that FG was using. So maybe I didn't need to make this custom XML outpu

[damned]

If you are just reading the db.xml file all the data is in there - except for those two fields you have already identified.
The big issue in terms of streaming is that file only updates every 5mins.
On a long running campaign getting it to save more often might impact the game as it can take longer and longer to write as the file gets bigger

So in the instance where you want to update that output more often then doing your own export is probably good - just export the characters and/or ct and not have to export all the story - might work for you.

[Alynn]

Yeah before when I was just exporting "charsheet" and "combattracker.list" did everything I needed except the holder. This export happens every time a turn changes. The middleware just watches the charsheet export for changes and then does it's stuff once the file is updated. So I thought about making my own export just grabbing the information I want in a single file, but I feel no need to reinvent the wheel. I've also considered, and may even implement the middle ware just touching the DB.xml on startup because the holder isn't going to be changing. But again that is all on the middleware part.

Thanks again, you all have been very helpful.

[damned]

Are you creating an extension as well? If so add a hidden field that gets its value from that non exporting field. It will export.