DOIds are still 100% needed for instances.
ReusableIds will be ideal for staticService and many other locations
where you know the object is only temporary to that session.
This allows the command system to recognise that they have the ability
in their abilities list.
Also removed setPvpBitmask which is redundant and unused; has no effect
on anything.
Hate is not the same as damage.
AI is meant to choose their target based on who's most hated, not who's
dealt the most damage.
Hate is affected by the hate fields in combat commands, not necessarily
the damage of those commands.
An example is the Guardian Strike ability which deals zero damage but
increases hate greatly.
There is still a purpose for HighestDamageDealer in locations such as
DeathState where the person who gets the loot is the highest damage
dealer. Damage dealt is also used in XP calculation.
Fixed an issue where attributes weren't being removed when unequipping
items.
EquipmentList and ApperaranceList are currently broken and will cause
crashes when modified, thus when equipping an item in any way will cause
a crash. Expect a fix for that from Treeku shortly.
Fixes:
Traceback (most recent call last):
File "scripts/commands/removebuff.py", line 8, in run
buffObj = actor.getBuffByCRC(int(commandString))
AttributeError: 'resources.objects.creature.CreatureObject' object has no attribute 'getBuffByCRC'
Fixes:
java.lang.NullPointerException
at resources.objects.tangible.TangibleObject.getDefendersList(TangibleObject.java:328)
at services.gcw.FactionService.calculatePvpStatus(FactionService.java:318)
at resources.objects.creature.CreatureObject.sendBaselines(CreatureObject.java:1475)
at engine.resources.objects.SWGObject.makeAware(SWGObject.java:532)
at services.SimulationService.add(SimulationService.java:251)
at services.SimulationService.handleZoneIn(SimulationService.java:1187)
at services.object.ObjectService$7.handlePacket(ObjectService.java:1169)
at engine.resources.service.NetworkDispatch$1.run(NetworkDispatch.java:216)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
We've had a completely incorrect buff structure in baselines for the last year due to some small misinterpretations of its structure. It worked because there was the right amount of bytes, but otherwise the structure wasn't right and variables have been in the wrong place. Specifically, we interpreted the stack variable (which comes last) to be the beginning of all buffs except the first, assumed there was an abnormal starting buff, and treated the final stack variable as an unknown variable that comes after the buff list. This is most likely also why it didn't work without this "default buff". The structure has been correct in Buff.getBytes() and buff deltas for a while but has been incorrect for baselines.