| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
By default they are not persistent now (meaning that they wont get
stored in the database).
|
|
Things done:
Wrote a entity:give_experience function (lua side only).
Renamed characterpoints to attributepoints (no db update. Did not want
to do one for a simple rename).
Temponary introduced a ATTR_LEVEL constant. TODO: dehardcode this.
Script binds for settings the correction and attribute points.
|
|
The ai is similar to the old c++ version. Only the target searching is
executed every 10 ticks only now to prevent performance issues with too
many lua calls.
|
|
Each ability can now define a cooldown that prevents the player from
using other abilities for a while. The time of this cooldown can be set
to any attribute. The modified value of the attribute is the value of
the cooldown in game ticks. The cooldown will be automatically started
if the ability has `autoconsume` set to true. Otherwise a script has to
call entity:cooldown_ability(ability).
|
|
During the implementation bjorn and I agreed to limit the number of attacks that
can be used in the same tick to one. This makes a lot of stuff easier and the
client cannot display two frames at the same time
Things done:
- Implemented setting of attacks when equipping/unequipping items
- Single place where the xml attack node is parsed
- Finished attack logic
- Unified the attack handling of monsters and characters
- Added a global cooldown after attack use
(not only for next use of same attack)
- Removed the temponary attributes for the monster attack values
- Priorities for all attacks
- Rewrote the attack core:
- Attacks now have this attributes:
- warmup -> time a attack needs after starting it to actually deal the damage
- cooldown -> time a attack needs after dealing damage before another attack
can be used
- reuse -> time before the same attack can be used again
- If no attack is performed at the moment the following is done:
- make a list with all ready attacks
- check for attack that has the necessarily range and highest priority
- start this attack (inform client about it)
- when warmup is finished -> trigger damage
- when cooldown is finished -> allow to use other (or the same if reusetimer
allows) attacks
TODO:
- sync client with this to allow better timed animations
|
|
It's easier to just talk about world data and to modify it as a whole.
If there is really a need to separate it, a project can still choose to do
that (and in whatever suitable way). There is no need to enforce this
separation or to do it in our example.
Reviewed-by: Erik Schilling
|
