Combat Tracker 3.5E Bugs...

[HoloGnome]

1. Do not delete wounds from characters when removing them from the combat tracker - any wounds should always stay with the character sheet and be saved/restored on remove/add to the combat tracker
2. When adding multiple monsters from an encounter item using auto-init, not all monsters have init values (For example, I saw 1 or 2 end up with blank init on an add of 10 monsters - 5 monster types, 2 of each)
3. CTRL+click to target an opponent when the source character is selected seems to have intermittent bugs - sometimes it works and sometimes it doesn't. When running battles, there have been multiple times when FG refused to target and I had to manually drag targets from the Combat Tracker to get them to show up/be valid. On the map, it would appear to show that the opponent was targeted, but there was no updated status text indicating that fact in the combat tracker.

[Moon Wizard]

1) Reproduced.
2) Unable to reproduce. Need more information on which creatures (standard bestiary or other).
3) Is the target not targeted at all? (i.e. arrow missing when hovering over token on map) Or is it just the CT display that is not updating? Do you have a reproduceable scenario?

Thanks,
JPG

[RTFallen]

3) Is the target not targeted at all? (i.e. arrow missing when hovering over token on map) Or is it just the CT display that is not updating? Do you have a reproduceable scenario?

I've had something similar happen while testing modules. Sometimes when using CTRL+click it selects the token you are trying to target instead of targeting it. I usually have this problem when trying to target as GM. When I target as a player I don't seem to have this issue. (Running second FG as player for module testing.)

I'm not sure how to reproduce it. It seems to happen at random times.

Resire

[HoloGnome]

1. Great.
2. I was using modified versions of the 3.5E ruleset zombies. I dragged the Zombie, Human Commoner from the Library, created 5 different types of zombies with different names as NPCs, then added them from the NPC window to an encounter, set the encounter to have 2 of each type (10 total), and dragged the encounter to the Combat Tracker window. The CT populated with 10 zombies, but at least 1 always had blank INIT even though auto-init was set in the prefs. See attached image. As a test, I quit and relaunched the app and the problem still occurs. This bug occurs when nothing else is in the Combat Tracker. See attached image.
3. I definitely saw this issue when I was trying to target as the GM, but I intervened when the player could not target. I tried to make sure that the token was not self-targeted and that it was selected before control-clicking. I just couldn't get it to work properly.

[Moon Wizard]

2) Technically, that zombie has an initiative of zero. There is no concept of "nil" or "null" for numerical fields, but they can be set to hide the data on a specific value (in this case, zero). It only happens in the rare case that a create has a negative initiative value (which I believe zombie is one of the rare cases, since most creatures have zero or higher initiative bonuses). It will all still work as expected; you just won't see the zero.

3) Hmm, I might need some help trying to recreate this one, since it appears to be intermittent.

Regards,
JPG

[HoloGnome]

2. I see. Yeah - didn't think about the -1 INIT. Interesting. Considering this issue and other possibilities for INIT modifiers, I think it would be great if FG supported negative INIT values for full relative ranking of INIT in all scenarios.
3. OK - I will try to see if I see it again and/or can find a reproducible case.

[Trenloe]

Considering this issue and other possibilities for INIT modifiers, I think it would be great if FG supported negative INIT values for full relative ranking of INIT in all scenarios.

FG supports full initiative ranges - both positive and negative. As M_W said above, it is just a value of 0 that is not shown in the Init field - but the 0 is there and being processed correctly. All other non-zero numbers (positive and negative) will be shown and they will be ordered correctly, including 0.

[HoloGnome]

OK - well...I would suggest that FG start showing values of 0 so that users are not confused by blank fields that should have values in them. What is the reason that 0 values are shown as blank? There is a fundamental, programmatic difference between 0 and blank. To me, blank means that initiative has not been rolled and is unset. So, if a GM sees a blank field, how is he/she supposed to know that a player's result is 0 vs. them not rolling initiative? And, the same confusion applies to monsters as I experienced with the -1 INIT mod zombies. This issue would appear to be a bug that needs to be fixed to improve FG usability/clarity.