There are four big changes in this release:
- When a DoT debuff lands on a target, it turns out that the plugin was already storing some critical information I hadn’t decoded yet. The lowest 8 bits of the average DoT tick, along with the lowest 8 bits of the player’s current critical hit rate, were in the combat data stream already. This is both extremely useful and frustrating at the same time, because it is not the entire DoT amount – if the DoT ticks for more than 260 damage, then this number will be 0x05, not 0x105. However, I have modified the plugin to use this information while also simulating the DoT tick, and this allows the plugin to calculate the 2nd byte of the DoT amount. The result: the average real in-game DoT amounts are used by the plugin now.
- The DoT tick critical hit percent is sent in units of 1/10 of a percent, so the lowest 8-bits allows for up to 25.5% crit. When buffed, bards and monks exceed this, so the plugin does a similar trick to estimate the next byte of the DoT tick crit percent. Note that the ACT FFXIV plugin’s DoT simulation will still add a fixed amount to each tick corresponding to the crit %. This can be adjusted to show the individual crit hits by selecting the “Simulate Individual DoT Crits” setting. This setting is not enabled by default because parses will be more accurate and repeatable if no additional randomness is introduced.
- Along with the DoT data comes two interesting extra values I decoded from the existing log data – Damage Aspect Type and Elemental Affinity Type. Damage Aspect Type refers to blunt, slashing, etc. Elemental Affinity Type refers to the elemental type of the hit. Note that both magic and physical damage types can have an elemental affinity. This new data is displayed within ACT DamageType column.
What this means is that the remaining inaccuracies in DoT amounts should be due to too many / too few DoT ticks on the target. This is a very complex issue to solve due to the various latency issues involved between client / server as well as on the server itself. - Modified the network processing code to handle TCP retransmits. This appears to be the cause of all the 'network errors' that people have had reported since the 2.4 launch - extra lag / lost packets cause packets to be resent, and the plugin was not handling that correctly.
In addition to the above, there are a number of other fixes included in this version:
- Fixed Galvanize & Stoneskin damage shields so they work again.
- Changed how the plugin determines the local ip addresses in order to access FFXIV game traffic.
- When a target now has more than 30 buffs, the plugin will now record them and simulate any DoT ticks that were previously being lost. This should now allow fates, CT, and ST runs to show accurate DoT ticks. Previously, any buffs / DoTs exceeding the 30-buff client display limit were being lost.
- Minor adjustments to make the plugin 64-bit compatible. This will still require changes when FFXIV is upgraded to run in a 64-bit process, though.
- Fixed two glaring bugs with current critical hit rate calculation.
- Changed the filename for log files to start with date/time, and removed player name from the filename. This was causing problems for HistoryDB searches, even though it was helpful for me when receiving log files.
- Added some multithread locking to the buffs processing. I don’t know where the multiple threads are coming from, but there are two bug reports that suggest it is necessary.
- Recoded how Contagion works, it will no longer miss DoT effects cast <1.5 seconds before Contagion is used.
- changed OverhealPct column data type to varchar so it properly exports to ODBC
- Renamed the “Original DoT calculation” to “Simulate Individual DoT Crits”, to more clearly indicate what the option does: instead of adding a fixed amount to each dot tick, it randomly determines whether the tick should crit or not based off the dot debuff’s critical hit rate.