Hunting down a bug

[peterb]

This bug is most probably the result of my modifications to a ruleset - which is why I post my question here instread of the support forum.

I'm using version 2.6.4

I've made some modifications to the CoC ruleset. I restructured the main-tab, added armour fields, fatigue and a major wounds field. I also added some automations to handle random Armour Point-rolls.

I've also edited the default skilllist in eramanager.lua.

On the skills-tab of my modified ruleset a empty skill always appears when you toggle the skills-tab. I have made no modifications to the skilltab code or the skilllistitem code. This empty skill does not appear in db.xml. If you manually create a new skill - that skill does appear in db.xml. If you delete the empty skill - FG crashes!

The skill behaves as all other skills. You can add a base, a name, you can double click it and a d100 is rolled etc. But it's never saved to the db.xml and if you remove it then FG crashes.

I'm lost. I've tried removing all skills onInit code and inserting a print statement instead. A empty skill still appears. Something seems to create a skill outside the onInit routine of charsheet_skilllist.lua.

I've searched the code for what in earth it could be, but I can't find a thing. My first thought was that some code somehow referenced the skill frame and sent create item requests. But I can't find any such code.

How do I best proceed with debugging this? For example, is there a way one could trace what code does what in what frames (e.g. get a print statement on the console)?

[Moon Wizard]

You may want to check that that the skipempty tag is set for the windowlist in question. Still, that shouldn't make FG crash when you delete it.

https://fantasygrounds.com/refdoc/windowlist.xcp

My advice is to start with the original code, and make very small changes until you see it break. Debugging ruleset modifications in FG is a binary debugging kind of affair. Also, make sure you use /reload to reload the ruleset on the fly to make things a little quicker while iterating (only can use about 5 times before memory issues occur).

Cheers,
JPG

[peterb]

Thanks for the tip. It was easy to do too. Just make a fresh copy of the CoC ruleset and copy the changes one by one. Took me about one hour to find the error. It was something I added almost 10 months ago that I had forgotten about. An invisible linkednumber field at the top of charsheet_skills.xml. I use it to enable an automatic adding of a fatigue mod to all skill rolls. When I removed that field the ghost skill entries disappeared. And those that existed since before (in already existing PC sheets) could safely be removed.

I still don't understand why these ghost skill entries are created and why FG crashes when you delete them, but at least I got rid if them and the ugly bug they created. Now I just need to figure out another way of referencing a value on the main tab from inside a windowlist item on another tab, a windowlist that is not defined in the skill sheet, but in charsheet_listclasses.xml. But I create a new thread about that...

[peterb]

I might add, that adding any kind of numberfield or number control to the a windowclass that has charsheet_skilllistitem entries creates this problem. I made a test and added five more linkednumber fields and got five more ghost entries, all of which crashed FG when you removed them (and then closed the charactersheet from the skilltab). Odd, really odd.

[Moon Wizard]

I would guess that you are running into an issue where your numberfield is sharing the same namespace as a windowlist object. I've seen this happen repeatedly with the combat tracker, since the top level object is also the list object. I ended up creating a separate combattracker_props database node to track high-level information from the combat tracker. (such as round number).

If you like, you could private message me an example of your code with and without the statement, but that is my guess.

Cheers,
JPG

[Foen]

I think moon_wizard has nailed it. If you create a bound control (numberfield or stringfield) which sits below the list node in the database hierarchy, it is treated as a window for the purposes of displaying a windowlist. Basically, a windowlist creates a window for each databasenode that is an immediate child of the windowlist node.

That behaviour would make a phantom window appear in the list, and deleting it would cause potential problems because the FG engine tries to close a window when, in fact, there is no window node in the database. Furthermore, if you were using linkednumber, any change to the target nodes would cause the FG engine to try to recalculate the linkednumber value: with the node deleted, a null reference exception can arise and the FG sesson may crash.

Stuart

[peterb]

Thanks for the help, and the explanation. I managed to work around the problem and now I have 99% of what I need for running a BRP fantasy game up and running. Not that my version is as good as Foens BRP ruleset, but it will keep us running until a more versatile (and good looking) BRP ruleset arrives on the market.