Any reason when designing xml to pick one over the orders

[Varsuuk]

(EDIT: gah, typo: "pick one over the other")

When one needs to add a HD type entry, with what we have learned so far, is it better to do (memory, performance, usability, etc) enter as something like:



<hd>
<die type="string">d6</die>
<num type="number">1</number>
<mod type="number">1<mod>
</hd>


or



<hd type="string">1d6+1</hd>


The former using more xml lines. Requiring 3 DB lookups.
The latter using one XML line, one DB lookup but requiring a regular expression application to pull out the components then convert them to numbers.

My gut says use #1 because data is separate and in proper format (have to look at type="dice" don't recall how that is used in case is better for this)

#2 has advantage of extensibility, in that we can change the format to add a second die type for example, "1d6+2 + 1d8-1" and could just change the RE. But like, in this case, not seeing a need past #d#+/-# type thing.

No clue which performs better in Fantasy Grounds. Not looking to prematurely optimize, both seem viable and don't want to pick something that is "bad" for performance.

[Moon Wizard]

It really depends.

Performance and Ease of Implementation
If you are reading via APIs all the time and the data does not tie directly to UI elements; then the latter version would be faster (less marshalling data between main application and Lua engine).
If you are using mainly to display all the parts in the UI, the former will be easier to implement, since you can map controls to data fields directly without any script parsing, listeners, etc.

Re-use
Another consideration is how often the fields are duplicated. For HD, I assume that it's one instance per creature. In that case, it's doesn't matter that much. If you had a set of fields for something like every spell out of 50, then reducing number of controls and data fields can help improve performance when copying records or opening windows.

Regards,
JPG

[Varsuuk]

Ahhh - OK - that is good food for thought and a way to think about it. Using that rule of thumb, I will stick to single entry even though it is as you say a limited one per creature thing. I choose based on the UI does NOT need the independent parts - just internal methods calculating background use it for arguments.

I just am barely familiar with RegEx and their implementations and wondered if that was a balancing factor further in other direction. But even if it was, I had forgotten the "nodes" part of the issue and how that can get out of hand too. I've read in passing about that. When I return to my bigger project I will keep that in mind also.

[Moon Wizard]

Just thought of one more consideration.

Mimicking Game Books
When designing fields on non-PC records (i.e. NPCs, traps, items, etc.); we tend to have the fields mirror the stat blocks as they are written in the books. This makes it easier for people to enter data into the FG interface from the game books.

Regards,
JPG