combattracker automatically created entries question

[Tarostar]

I'm rewriting the combattracker for my own system and to automate a lot of the work for my NPC handling. In the process I've changed it to store data in the database rather than the registry. However, I have the problem that it crashes when I close the combattracker if I delete any entries.

I've discovered what might be the cause and is certainly a problem. The default entry that is created does not create a database node (obviously the fields are not remembered if I close and reopen)! When I add a second entry that is created correctly and remembered, BUT with an ID as if the second item in the list.

Questions:

1) Where is this entry being created from? I can't find it to stop it being created. Adding <skipempty /> under <windowlist name="list"> does not make a difference.

2) Looking in combattracker.lua I see that it always calls
getWindows()[1].close(); and sure enough if I remove it I get two default entries. Is this a workaround for a bug or something? I've tried adding getWindows()[2].close(); but although that deletes the initial entry it does not stop the crashes...

Thanks

[Tarostar]

Finally resolved this, although more by trial and error than any deep understanding.

I left the combattracker as a windowreferencecontrol under gmshortcuts but added the recordname element.



<windowreferencecontrol>
<bounds>5,27,47,27</bounds>
<icon>
<normal>button_tracker</normal>
<pressed>button_tracker_down</pressed>
</icon>
<class>combattracker</class>
<recordname>combattracker</recordname>
<tooltip>
<text>Combat tracker</text>
</tooltip>
<nodrag />
<closetoggle />
</windowreferencecontrol>


In utility_combattracker.xml I changed the combattracker windowclass as follows:


<windowclass name="combattracker">
<datasource>combattracker</datasource>


Which is the same as writing:


<windowclass name="combattracker" source="combattracker">


So far so good. Where I made my mistake was in <windowlist name="list">. I specified it as <datasource>.</datasource> which meant that the list was being created at the same level as elements in the combattracker windowclass, which in turn caused two empy list entries to be created and caused crashes when deleting entries. I'm not sure why it would create two empty entries and fail to save those, but as soon as I changed it to the code below all my problems went away and it is now working properly.


<windowlist name="list">
<datasource>.list</datasource>

[Bidmaron]

Might I ask what it was you were getting it to do for you?

[PneumaPilot]

Gosh, I am just barely beginning to understand this combat tracker thing, and now you make me think I'm way behind where I thought I was.

Out of curiosity - and hopefully future benefit - what is the significance of the dot (.) in that last code fragment?

[joshuha]

The dot in a datasource means to make it a child node of whatever the parent is in the db.xml file.

[PneumaPilot]

So if you start with just a dot, it assumes...what?...the last item mentioned, or is there some database object associated with the control in general? In other words, if you start a reference with a dot, what is it a child of?

[Foen]

A control bound to the database is typically a child of its containing window (or more specifically, a child of the database node associated with that window).

For example, the 'name' string in the d20 character sheet front page is bound to a database node which is the child of the character sheet node. The name of a skill is the child of the skill node, which is the child of the containing skill list, which in turn is the child of the containing character sheet node.

Clear as mud:)

Foen

[Tarostar]

Might I ask what it was you were getting it to do for you?

Sorry, I had a bit of a fever yesterday so I wasn't checking the forum. I wanted to store the combattracker data in the database rather than in the registry. This allows me to get data from various fields for various calculations, such as subtracting impairment and other penalties from attack rolls and so on. It also means that you can share data from the combattracker with the players if you wish.

You would also want to get rid of storeToRegistry and restoreFromRegistry in combattracker.lua and the associated code.

[Tarostar]

Clear as mud:)

Indeed. So for what I was doing in the combattracker the database would look like this with one entry (note that the idcounter holds the ID of the next entry to be added):



<combattracker>
<list idcounter="2">
<id-00001>
-- the elements go here such as <name></name>, etc.
</id-00001>
</list>
</combattracker>