FG v3.3 data structures

[Callum]

Is it possible to have examples of the new xml data structures that were introduced for 3.5E/PFRPG in FG v3.3, please?

[Trenloe]

Detailed here: https://www.fantasygrounds.com/wiki/index.php/Data_Structure_Overview_and_Best_Practices

[Callum]

Thanks, Trenloe. However, I'd found that page when searching around, and it doesn't have what I'm looking for. What I really want is the full XML structure for referenceclassability, and all the others.

[Trenloe]

I don't know if they're specifically available. I you want to get in-depth details on DB structures, your best bet is to add a few entries for the classes you're interested in to an empty campaign and look at the resulting FG XML in the campaign database, as suggested by swbuza here: https://www.fantasygrounds.com/forums/showthread.php?19279-Character-Class-Module&p=350430&viewfull=1#post350430

This is the quickest and easiest way to get example data for the classes you're interested in.

[Talyn]

For purely the referenceclassability class, you're looking at:

(I used pfsrd to copy the textual description)


<reference static="true">
<class>
<barbarian>
<text type="formattedtext">
<p>Blahblahblah. This text appears on the [Main] tab of the Class window.</p>
</text>
<classfeatures>
<fastmovement>
<level type="number">1</level>
<name type="string">Fast Movement (Ex)</name>
<text type="formattedtext">
<p>A barbarian's land speed is faster than the norm for his race by +10 feet. This benefit applies only when he is wearing no armor, light armor, or medium armor and not carrying a heavy load. Apply this bonus before modifying the barbarian's speed because of any load carried or armor worn. This bonus stacks with any other bonuses to the barbarian's land speed.</p>
</text>
</fastmovement>
</classfeatures>
</barbarian>
</class>
</reference>

The <level> line is used for the drag-n-drop so FG knows which level to auto-drop the ability onto the character sheet. That what you were looking for?

[Callum]

I don't know if they're specifically available. I you want to get in-depth details on DB structures, your best bet is to add a few entries for the classes you're interested in to an empty campaign and look at the resulting FG XML in the campaign database, as suggested by swbuza here: https://www.fantasygrounds.com/forums/showthread.php?19279-Character-Class-Module&p=350430&viewfull=1#post350430

This is the quickest and easiest way to get example data for the classes you're interested in.
Yes, I saw swbuza's suggestion in that other thread, which he posted after I started this thread. It's a good suggestion, which I will follow, but I still feel that the information should be generally available without having to go through that process.

[Callum]

That what you were looking for?

Thanks, Talyn, that's just it! Now I can keep using Nickademus's PFRPG Classes module.

[Andraax]

Yes, I saw swbuza's suggestion in that other thread, which he posted after I started this thread. It's a good suggestion, which I will follow, but I still feel that the information should be generally available without having to go through that process.

We look forward to seeing the documentation that you come up with. You *are* volunteering to do this, right? :-)

[Ken L]

We look forward to seeing the documentation that you come up with. You *are* volunteering to do this, right? :-)

He's asking for documentation for the ruleset he purchased with FG. Sure he can open up the raw code and poke around but a reference would aid in him modding what he wants to add.

I don't see anything wrong with his request. I myself had to fish around with grep more than I needed to, to find obscure references between lua and XML for the pfrpg, and core ruleset for my extensions.

[Andraax]

First, it was a joke, hence the smiley.

Second, SmiteWorks is only 3 people, IIRC, so they don't have time to document all rulesets.

[Trenloe]

Be realistic guys - you're never going to get development documentation that details in-depth nuances of individual rulesets. FG community developers are probably less than 1% of FG users (I imaging that's being quite generous). In-depth technical documentation takes a lot (and I mean a lot) of time. There would be a massive outcry from the normal users if updates, bug-fixes, new products, etc. were delayed a few months a year because of FG core developers having to write in-depth documentation. Additionally, a key thing to note here: it has never been advertised that you get "[development] documentation for the ruleset [you purchase] with FG..."

Sorry, I know it's not not ideal... But I really don't think your expectations have been set any differently.

In this example (getting documentation for the FG database structure for a few abilities) it is fairly straightforward to get the information from the database of a FG campaign. As Callum was wanting to know FG DB structures for some specific entities, we can assume that he's familiar with the basics of FG databases. So, based off that assumption, we can assume that it is fairly straightforward for him to look at the FG DB structure in a sample campaign after creating a few example records through the FG interface.

This is actually the most reliable way to get this structure. It's up-to-date, allows you to play around with various what if's (what if this field is empty, is it required? etc.) and see the exact structure with the data that you're interested in.

If the FG core developers spent lots of time creating in-depth documentation, then they would also have to spend lots of time in the future updating that documentation. Remember that out of date information can be worse than no information! As you can waste a lot of time trying to make things work with out-of-date information...

I understand where people are coming from. But SmiteWorks do not have the resources to document (and update) to the level that is being requested in this thread - unless you all want functionality development to slow down to a crawl. It has always been "look at the ruleset code and the campaign database for examples. Then ask on the forums if you need more information." The majority of what you need is available to you - open access to the campaign database and the ruleset code.

It was great that Talyn provided the info that was asked for in post #5. But, to do this, Talyn basically did what was suggested - put the info in a campaign and extracted that data. That's why it was suggested by a couple of community members in the first place - it's quick, gives you the exact structure for the data you want to enter, and you can play around with seeing how different data is stored.

@Callum - the above is no way me singling out out. As this thread has started to discuss levels of documentation, I am simply using this specific example to illustrate my point. You came to the forums asking for more info, you were given the means to find that info. OK, it wasn't detailed development documentation, but judging by your response to Talyn's post, you got the info you needed. Which is great! :)

[Nylanfs]

It took the PCGen project more than 8 years to build our documentation. And it's still not up to date.

[Ken L]

PCGen is volunteer driven compared to a purchased product.

Either way, it wouldn't kill to have a comment for each function for the future. I'm sure there's some internal documentation which is stripped prior to release, else it would be hell to on-board new developers whom are expected to develop their own complete understanding. Whenever I'm dropped into a project like that, I'm left grepping around and using a note-pad to denote areas of interest and jot down connections as I see them. Thankfully those have been rare.

[Bidmaron]

We will respectfully disagree. I am with Trenloe on this (now). WE need them focusing on new capabilities. There was about 8 years ago a detailed ruleset documentation but it was impractical to update. It languished and became increasingly irrelevant. It eventually got taken down. Useful documentation is as hard as the code itself

[Andraax]

PCGen is volunteer driven compared to a purchased product.

Either way, it wouldn't kill to have a comment for each function for the future. I'm sure there's some internal documentation which is stripped prior to release, else it would be hell to on-board new developers whom are expected to develop their own complete understanding. Whenever I'm dropped into a project like that, I'm left grepping around and using a note-pad to denote areas of interest and jot down connections as I see them. Thankfully those have been rare.

SmiteWorks has 2 developers on payroll. One that works on the existing code and one that is developing the Unity version. Everyone else is a volunteer.

[Ken L]

I'm not really suggesting for detailed documentation. a sentence of handful of words above each function/xml windowclass for the future would be sufficient. Self documenting code suffices as well but much isn't. It will also help when smite works gets another developer, and helps more people get into the modding arena as opposed to a handful who wish to navigate it.

Also Andraax, the others are commissioned, they aren't developing these supported rule-sets purely for free here. I don't own any of them as the PF and core rule-set are sufficient for my needs and I don't really know if their internals are as exposed as the base rule-sets are.

[Andraax]

Also Andraax, the others are commissioned, they aren't developing these supported rule-sets purely for free here.

I'm currently the developer for the C&C ruleset; trust me, it's a volunteer position. :-) No one is making a living on the commissions...

[Talyn]

You are? Jeez, good thing I didn't go spamming JPG with email then... =) Hey, PM me if you get a chance. :)

[Ken L]

C&C is listed for sale? I guess most of that goes to the game maker then and FG. Sure commissions are paltry things but I'm allergic to 'crowd-sourcing' things that eventually drive another's profit so it's more a matter of principle unless it's pure FOSS.

[Talyn]

Yep, C&C is one of the retail rulesets, just like Savage Worlds, Call of Cthulhu, etc. Out of all the DLC Developer type, the ruleset devs earn the least for their time involved, so it's difficult to get anyone to step up in the first place, much less stick around.

[dulux-oz]

The Commissioned Devs do it for the love of the game (whichever game that is) - as the Dev for the 13th Age I can tell you the amount of commission is surprisingly small. Most (half?) of the price of a given item goes to to the original game licensee, then SmiteWorks gets their cut for both their Intellectual Property (the FG engine, etc) and for the FG Store expenses, etc. What's left is... a fair price but certainly not a price someone could live on (the hourly rate sux big-time :) ).

Its a hobby, not a career, and I would hazard a guess that most of the Community/Commissioned Devs feel the same way.

Coming from both a FOSS and a Proprietary Software and ICT background, yes, I'd like to see more / better / more extensive documentation, but as all things in a hobby (and even in the FOSS world) "put up or shut up" - if we want something badly enough we do it ourselves (or pay someone to do it for us)... or we can bitch and complain repeatedly in the hope that this will goad people to action - and that never works (and I'm speaking as someone who both gets bitched and complained at and who also has run FOSS & Proprietary Projects) because all it does is make the people who might be inclined to do it annoyed. Oh sure, raise the issue, but then don't harp on and on about it.

In the particular case of SmiteWorks and FG - the number of people who would benefit from the type of doco being discussed is only a small, small percentage of the user-base - and while I might miss some good doco I would wager that the majority of that small small percentage has the skills necessary to "work it out for themselves" anyway. Those who can't will end up asking questions which the Community will answer. So from a cost-benefit and SWOT analysis its not worth the time and effort for SW to do it, especially when that means taking dev-hours away from other, more "bang for your buck" activities.

Just my $0.02 worth :)

Note: Rereading what I just wrote it occurs to me that some people might take what I said personally. That is not my intention; I am speaking generally and not at any one individual or group of individuals - so please, nobody get their nose out of joint over it - let's keep it civil at all times, shall we?

[Ken L]

? FOSS developers tend to be pretty gainly employed. It's more when a paid for product takes freely contributed items then attempts to market it that itches many the wrong way.

In regards to documentation 'put up or shut up' as you call it. I always comment my code even minimally with snarky remarks both in work, and FOSS. It's fosters more collaboration and many eyes make for short work in terms of finding bugs and bringing in improvements. Coming into to FG, I don't really see myself developing documentation given how the 'core' rulesets are maintained by the developers themselves so it makes sense for the 'maintainers' to keep that up to date. Sure one can 'put up' but they're not the maintainer, so if the maintainer decides some things are being depreciated it's a game of catch up which is alleviated by the maintainer putting a comment in the new code.

This is just standard 101 for any major FOSS, especially if you're devel on any distribution or a package maintainer. You maintain and document your own package, and or contributions so others can understand what you wrote. In the corporate world lack of documentation is seen as 'job secruity' but we've let people go who've failed code reviews, relying purely on obfuscation which when untangled at additional effort revealed nothing special. Not to say FG is intentionally confusing, but for anyone who wishes to start modding it's confusing as heck.

[dulux-oz]

As I said in my previous post, looking at things from a cost-benefit anaysis I can see why things are the way they are - do I particularly like it this way? Not really, but I'd rather have the Devs spending their limited resources on new features, etc, because IMNSHO the dev-doco, while incredibly useful to me, is only going to benefit a very small percentage of the user-base - and I haven't been that disadvantaged without it (DOEs as a practical example).

Anyway, that's enough said from me - I've made my point and said my piece. I've leave this thread to continue on its merry way - its a better cost-benefit for me to work on actually coding for the Community :)

Cheers

[Talyn]

I agree with Ken and with Dulux-Oz. There is a woeful lack of documentation for much of anything, and the majority of documentation that exists is written for people who are already knowledgeable programmers. There's also not enough free time for the couple developers at SmiteWorks to write up extensive Wiki articles, and the usual batch of Wiki authors around here are not programmers or markup ... "markers" (we really need a cool-sounding word for that, since it isn't "programming") so don't know what to do with it. For newcomers who want to dig in and help, it's a daunting task with almost nothing but uphill obstacles.

Reference Manuals are a good example. There was zero documentation for them from the developers, then added to that, The Community™ was very misguided about that and ganged up to prevent any of that code getting out because it was "proprietary 5E code" or so they thought, until we proved them wrong. I was an incredible pain in the *** via emails, etc. until I was provided with example code then later Moon Wizard wrote up the wiki page for reference manuals. (In my defense, I was new last year and unfamiliar with just how small SmiteWorks actually is, which makes me even more appreciative now that Moon Wizard took the time to write that documentation.)

I suppose it would partially fall to the DLC Developers ourselves to write up the documentation, though I don't know how many besides me and one or two others who spend more time in the XML than anywhere else (except for the Ruleset Devs and Lua scripters). But once again, that runs up against their free time. I sure don't have much...

[Callum]

Just to be clear - my initial post was simply a polite request, not a demand. It wasn't aimed directly at Smiteworks staff, either - I simply hoped that someone who was already familiar with the new structures would be able to provide the info. For many of us, work and family commitments leave precious little time to sit in front of our PC at home delving around inside FG, and so it's really helpful if useful information about the software is readily available. Nonetheless, the fantastic FG community rose to the challenge, as always, and gave me the info I needed - thanks! I hope I've done my part in helping others out over the years.

Was it frustrating that it took me so long to update a module that I'd been happily using for some time but had been rendered inoperative by changes to the core FG code? Yes, slightly. Does this mean that I feel any resentment towards the Smiteworks team or the Fantasy Grounds software? No, not one bit - I think they are a great group of people who do a fantastic job producing an amazing piece of software that I will continue to use and recommend to others into the foreseeable future.


We look forward to seeing the documentation that you come up with. You *are* volunteering to do this, right? :-)

If I manage to find the time to sit down in front of my PC at home and do it, sure. ;-) It would also be nice if I had editing rights to the wiki so I could put it somewhere appropriate.

[dulux-oz]

It would also be nice if I had editing rights to the wiki so I could put it somewhere appropriate.

If you write it up and send me a copy (in Wiki format) I'll post it up for you

[Nickademus]

Was it frustrating that it took me so long to update a module that I'd been happily using for some time but had been rendered inoperative by changes to the core FG code? Yes, slightly. Does this mean that I feel any resentment towards the Smiteworks team or the Fantasy Grounds software? No, not one bit - I think they are a great group of people who do a fantastic job producing an amazing piece of software that I will continue to use and recommend to others into the foreseeable future.

What should be noted here was that it was the unique situation of the content you were using suddenly getting covered by a license and a pay product being offered that did what you wanted. Not something that happens regularly and a situation where legally the product you use could have been disallowed. Yeah, it's frustrating when things change, but it wasn't just changes to the FG code that caused this; it was a entire shift to producing licensed products for PF. I'm not surprised that thing changed in the wake of that (in fact, I believe I state it would be needed in the announcement thread for the PF license).

[Talyn]

Even simpler: this boils down to the SRD modules not being updated (yet?) with the 3.3 features. At this point, using the SRD modules ends up with your characters being incomplete, and you're stuck with the old way of doing things, which would be no big deal, we did it for years — except the 3.3 UI makes it appear that things are broken.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=20138&stc=1&d=1502728993

[Callum]

Yeah, it's frustrating when things change, but it wasn't just changes to the FG code that caused this; it was a entire shift to producing licensed products for PF.

Yes, I fully appreciate that. I realise that the changes were necessary to enable the licensed Pathfinder products and increased automation in the Pathfinder rulesets - all of which I think is great! I'm favour of development in general, and these changes in particular.