The health bar status updates do not require prerequisite checks as they use flags within the packet to determine the proper state of being yellow or green or both.
* This issue is responsible for causing client crashes when logging out, one of the signs is the sound of your backpack closing multiple times.
* Fix prevents multiple calls to subsystems such as the trade window, which had the potential to dupe items when returning them to the trade partner.
* Credit goes to UO:Revealed (www.uorevealed.com) for reporting the circumstances which lead to the fix, which seems to have been an overlooked issue for a very long time.
* Scripts project assembly name changed to "Scripts.CS" and build output targets the "Scripts/Output/" directory to mimic RunUO's ScriptCompiler behaviour.
* Removes the risk of inconsistency [warnings] generated by timers that tick with handlers that modify World.Items and World.Mobiles during I/O.
+ Update description of Core.TickCount.
* HttpListener will serve the status page to a URI in the format of http://<shard-ip>/status/
* Port 80 may need to be white-listed for external requests to be served.
+ Core housekeeping, converted some for-loops to foreach-loops.
+ Reimplementation of Core.TickCount using only native .NET Stopwatch.
* Stopwatch actually wraps the QueryPerformanceCounter method to get its result and can also be used to determine whether HRT is supported.
- Removed SafeNativeMethods DLLImport for QueryPerformanceCounter.
+ Added Core.GlobalUpdateRange to define a constant standard range used in many calculations throughout RunUO.
* The value '18' in a range context is hard-coded in many places, this new property will eventually be used to replace those usages.
* Can be enabled or disabled by setting the static property 'Enabled' to true or false (disabled by default).
* Uses single-list caching for movement operations instead of multiple caches depending on direction.
* Uses deferred Linq queries to process high volumes of items in collision detection only when necessary.
* Reduces movement lag for all Mobiles, including players, even with thousands of on-screen Mobiles and Items.
There is a very rare potential, mostly in custom situations, for the 'BaseRunicTool' 'ApplySkillBonus' method to cause the server to become unresponsive.
The reason for this is that, if you call the method on a 'Spellbook' which already has all 4 of the skills listed by default in 'm_PossibleSpellbookSkills', then 'found' is always true.
This issue has been reproduced on a shard that calls 'ApplySkillBonus' more than once when crafting 'Spellbooks'; the rarity is that the 'ApplyAttributesTo' method may call the 'ApplySkillBonus' more than once; the off-chance of 5 consecutive calls, where each preceding call applies one unique skill of the 'possibleSkills', would result in the 5th call entering the deadlock state.
The fix is quite simple, evaluate the 'count' in the while statement and decrement it for each skill that is checked; removing each skill from the 'possibleSkills' list as they are checked, to prevent them being checked multiple times due to the random indices selection.
