Only time in packet is wrong, some macros use this value for counter. Remove buff packet works well and removes the icon at the right time.
But maybe the scripts execute slower on the new framewrok - and the code calculates the difference in time from creating the bufinfo to sending the packet - or the time function itself is more accurate?
It is probably a mix of all those things. It may require a re-tweaking of whatever calculations are done or what mechanisms add the timer times. Each object that creates a timer sends the duration of that timer to the buff bar if it has it on creation.
It seems counterproductive at first that "upgrading" would make things worse, but it is just because the way things are handled under the hood at the operating system level have now changed. There are new better ways to do things that need to be explored, and old legacy ways of doing things that need to be upgraded. The end product is almost always better than the project it was built off of. We are just going to have some growing pains in the meantime.
In the meantime, if anyone has Visual Studio or some other IDE installed and wants to explore tweaking the buff icons and packets to increase accuracy and comes up with something viable, please let me know.
There is another PR about to get pushed to TrueUO, that is currently live on Heritage, that completely changes how timers specifically work. Instead of threading timers and using priority they are all just stored in a timer wheel.
https://github.com/TrueUO/TrueUO/pull/1275
Provides support for managing a large number of timers represented by TimerItem instances. The timer wheel is optimized so that add/remove operations for timer items is constant time (O(1)).
learn.microsoft.com
However, I don't think these changes have anything to do with it. It is almost exclusively the framework upgrade. The same upgrade that increased world save times. That is another system that needs lots of little tweaks to modernize and work in harmony with modern operating systems.
