Upgrade your account to a Community Supporter account and remove most of the site ads.
Rocket your D&D 5E and Level Up: Advanced 5E games into space! Alpha Star Magazine Is Launching... Right Now!

Reply to thread

Message: <blockquote data-quote="andargor" data-source="post: 1249475" data-attributes="member: 7231">Yeah, I took a look at the Basilisk project (within which is the treasure generator), and I have to admit that I don't feel as comfortable updating it. Mainly because I would have to learn how the thing works, and the data files are proprietary.I would be willing to parse the PCGen files for you and output the files in your format, since the relevant info is there (and my parse-fu is strong <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /> ). But to ensure it works properly, etc., I would leave that up to you (sorry).I have to disagree with using the PCGen data files when they are in XML.With all due (and well deserved) respect to the PCGen people, I have looked into this as well, but have concluded that they would be of limited use. Having worked extensively with PCGen data files, and helping them update to 3.5, I have consistently been frustrated with one fact: PCGen blurs the line between data and code.Basically, if there is a "tag" change, the Java and LST code has to be modified. That is why there is a new version every two weeks and is hard to follow, and old data files need to be recoded, and why 3.5 is such a pain to redo (yes, redo from scratch). Heck, in 3-6 months, the NPC generator will have to be updated again to reflect LST changes for export purposes.So in essence, LST is code that people other than Code Monkeys can change. It's a custom scripting language that changes often.And the XML format they are working on does not change this, since they are just embedding LST "code" into tags.But I am working with others on a generic way to represent the data sets that is independent of the tool or engine used. The concept is to transform this immuable, never changing data (except for, say, errata) to fit the needs of tools using such things as XSLT, XPath and XQuery. An XML Database, really. (See the "Suite Interoperability" thread here, and the d20-XML group for those discussions, there is even a nice diagram that I made to illustrate this)This would be what is required to ensure that another recode of the tools is not necessary for a good long time.Keep talking! <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f609.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=";)" title="Wink    ;)"  data-smilie="2"data-shortname=";)" />Andargor</blockquote>

Verification