IT’S LIVE!!!
Attachment 46144
I am at work right now, but when I get home I’ll be pouring over it to see if my tutorial videos are still applicable. If they are you’ll see them soon!
Printable View
IT’S LIVE!!!
Attachment 46144
I am at work right now, but when I get home I’ll be pouring over it to see if my tutorial videos are still applicable. If they are you’ll see them soon!
As long as the changes are well-localized, we're open to additional @JimSocks input.
Regards,
JPG
Superteddy57, MoonWizard, et al: You guys are rockstars.
I have tested the implementation and found that cross-template referencing is broken, but I have also dug into the code to try and figure out what changed to break it, and I found it!
Between the code I delivered and what ended up in FG there are only very slight differences I noticed, (besides the removal of my avalanche of comments as expected- sorry for over-commenting guys!) but one of the small changes is what breaks the cross-template goodness.
In the original code, I found and used a global table FG was already using elsewhere in order to store the cross template table results. The one I used was DataCommon, and though I know it's not best practice to do that, after examining what DataCommon was being used for in FG I determined my piggybacking off of it would cause zero issues, so I did it- worked like a charm :)
In the current iteration, DataCommon has been swapped for CommonStore. The name change alone would normally be inconsequential, but CommonStore isn't global like DataCommon is, it's local to Story_Template_Generate.lua, and thus is overwritten clean in between different story templates instead of being accessible by them all.
To test this, I took the current code in FG and swapped all CommonStore references back out for DataCommon, and removed the local definition on line 24 of Story_Template_Generate.lua. It worked flawlessly again!
As I mentioned, I know using globals is typically a no-no, BUUUUUT (hear me out here), DataCommon is already being used that way as far as Story_Template_Generate.lua is concerned anyway, and the way I use it doesn't have a chance at affecting current DataCommon usage within FG, AND the things written there are wiped clean every /reload. I suppose the more feelgood way to get this working again would be to create a new global just for this purpose and not double-task DataCommon, which hopefully is an easy kill to get it back 100% functional again?
**First, make sure you read my post above- it's about how the code needs to be repaired**
I have also made a NEW tutorial video, removing all references to the extension (no references of "PRO" and "Stock" anymore- it's ALL stock now!) and just showcasing it as a complete tutorial for Story Template command and usage functionality within FG. The new video also contains all the cool new functions within a single video now instead of having them scattered (which had to happen as I developed new commands/functions after the initial video went live before)
The second tutorial video "Story Templates: Practical Usage examples within Fantasy Grounds" will be a "Where the rubber meets the road" video actually showing these commands/functions in action. I am making that video from scratch right now, but when it's ready it will be a great companion video to this one.
Here is the new video's link:
Story Templates: Commands and usage tutorial for Fantasy Grounds
Congrats on having this incorporated into FG ;)
Note, you might want to update the first post so that folks know they will not longer need to download and install this as an extension.
You are SO right! I am on it!
And THANKS! I am still pouring work into the new content generator that will make use of all these cool new tricks, so it makes me super stoked that the whole community can benefit from the same magic.
I believe it was you who suggested the date functionality (but I could be mistaken, that was a long time ago!). If it was you- that was a great idea. Really helps me keep track of my generated stories when I put the date right in the story's title!