Reply to thread

Message: <blockquote data-quote="andargor" data-source="post: 1231333" data-attributes="member: 7231">I have no problem with custom info from different tools being stored in the export, and that is safely ignored by other tools. Maybe I didn't understand your example correctly, but if changes are made in another tool, then a common way of indicating that those changes have been made to other tools would have to be implemented. I still maintain that "recorded" user choices is probably the most tool independent way to do this.Ah. The unique ID issue. There are two ways of doing it:- Having a central repository to ensure there are no GUID collisions. It would need to be relatively real-time in order to not slow down anyone's development (i.e. it can't be a periodically published list). Also, it needs to be OS independent (I know Windows has a facility for generating "random and unique" GUIDs, but it won't apply to Macs or Linux)- Using game system elements to establish uniqueness. I submit that a name, a type, a version, and a source reference (perhaps with the game system name) would be sufficient. For example, I have not seen duplicate D&D feats named X from the same source, except errata (and the version tag fixes that).Just maybe to "synchronize the clocks" about what the idea is, I'l attempt to illustrate what happens in the graphic file format world. The example is Windows-centric, but hopefully the idea for a common generic format not tied to any tool, which would use transforms, will be illustrated. - Tool One uses GIF files- Tool Two uses JPG files- Tool Three uses BMP filesTo avoid having the makers code something specific to import and export pictures in the format of the other tool makers (which number grows with each new tool released from new makers), a common format is established: DIB.DIB is a very simple format, with no special encoding. It just says which pixel has what color. Each maker has only to code support to and from DIB, with their own encoding. If they have a new version of their format, they just update their import/export routines.The common XML format is just that (the DIB <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=":)" /> ). If my XSL-fu was as good as my code-fu, I'd probably draft up something fairly quickly for DMGenie, RPM and  Campaign Suite, and the common format is really irrelevant. Whether it's based on CSX or not is not that important. I just found it to be a good starting point.That's basically the idea. If I'm way off base here, please do not hesitate to slap me <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=":)" />Andargor</blockquote>

Verification