| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This should allow to finally call functions to lua without having to care
about working around situations where a lua call causes a c++ call which
needs to call to lua again.
Tested against the source of tales repository data.
|
|
This introduces two callbacks:
- on_update_derived_attribute -> Called to recalculate other derived
attributes.
- on_recalculate_base_attribute -> Called to recalculate a base attribute
(only called for characters. However the
function passed as callback can be useful
for recalculating the derived attributes
as well)
Monsters no longer block recalculation of attributes except HP and Speed.
I saw no sense to keep this.
Fixed constant value in libmana-constants.lua
Dropped bool type of the recalculation functions. It would be difficult to
keep it while pushing all to the script engine and it was unused anyway.
All in all this adds a LOT more flexibillity to projects since they can now
adapt all attributes in the way they want.
|
|
|
|
|
|
This replaces the rather hard to understand event dispatcher with a
probably even harder to understand templated library, but fortunately
we can rely on the available documentation.
Hopefully it will also help with the readability of our code and with
adding additional signals to other classes.
Added libsigc++ to README and Travis CI configuration.
Reviewed-by: Erik Schilling
|
|
Same thing, but shorter.
|
|
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
|
|
|
|
Reviewed-by: bjorn
acked-by: Ablu
|
|
The timeout remembers a reference point of time against which it can check
how much time is remaining.
Reviewed-by: Erik Schilling
Reviewed-by: Yohann Ferreira
|
|
In preparation for using an entity/component system for the entities
in the game world, this name will be more recognizable and easier to
talk about.
Reviewed-by: Yohann Ferreira
|
|
The main change here is to remove the separate calling of 'perform' on all
beings, and rather rely on the beings to do whatever they were doing in
that function when the virtual 'update' function is called.
Reviewed-by: Yohann Ferreira
|
|
These were unused parameters and one return type with an ignored 'const'
qualifier.
Reviewed-by: Yohann Ferreira
|
|
It's not nice to use ++ on an iterator that may be std::map::end(),
in my case this caused it to hang indefinitely.
Reviewed-by: Yohann Ferreira
|
|
Reviewed-by: bjorn.
|
|
This can now be done in attributes.xml through the
minimum and maximum attribute parameters.
I also changed the AttributeInfo struct as requested by bjorn.
Reviewed-by: Erik Schilling, Thorbjørn Lindeijer
|
|
Reviewed-by: o11c, bjorn, Bertram.
|
|
Being::findPath doesn't change the position of a being, and so should
not be syncing mOld to the current position. When invoked on the wrong
moment, this could cause MapComposite::update to fail to realize that a
being has moved into another zone.
Also removed some other usages of mOld that were not necessary, to make
its purpose clearer and make a potential cleanup easier.
Reviewed-by: Yohann Ferreira
|
|
The server is now using the autoattacks system to perform damage
based on the attack's timer.
I also added a default bare knuckle attack when the character
is unequipped.
As a result, maggots can be killed again with bare hands now.
Known issues left:
This isn't tested against equipment changes for now, and the client
isn't in sync with the attacks speed.
Reviewed-by: Crush.
|
|
Reviewed-by: Jaxad0127.
|
|
The setAttribute() already takes care of updating them.
Reviewed-by: Jaxad0127.
|
|
The bug made the monsters unable to move.
Reviewed-by: Jaxad0127.
|
|
The crash happened when it was trying to move an NPC from its old zone
to its new zone. The old zone was based on the old position, which was
(0,0). That crashed since its zone didn't match its old position, but
its new one.
This fix makes sure to update the old position to be in sync with the
zone, by resetting it after being inserted into the MapComposite.
Reviewed-by: Yohann Ferreira
|
|
SCOPE_TYPES -> ScopeType (plural was confusing)
ATTR_BEING -> BeingScope
ATTR_CHAR -> CharacterScope
ATTR_MOD -> MonsterScope
ATTR_MAX -> MaxScope
AttributeScopes -> AttributeScope
(A single scope seems to include multiple lists of attributes. Seems
wrong to me to name this type in plural form.)
getAttributeInfoForType -> getAttributeScope
(just naming it after what it is actually returning)
Reviewed-by: Freeyorp
|
|
Just seems a bit more organized to me.
|
|
There was a version taking an attack range, but the range was always the
same as the one specified in the Damage class.
|
|
This reverts commit b2209cbe93aa12dcd4e4e3b9a7cd8b13ed5713e9.
Money should be handled through attributes, not magic numbers.
|
|
- At character's attributes recalculation when necessary.
- In the lua scripting functions.
|
|
This saves a bit of cpu and make use of pixel points where
tile points where used before and could lead to discrepancies.
Reviewed-by: Thorbjorn.
|
|
As the protocol version isn't something the maintainers should
set, I removed the net_clientVersion irrelevant option, replaced
by the corresponding define PROTOCOL_VERSION
in the manaserv_protocol.h file.
A corresponding change in the client will be made.
N.B.: Now, the Enet version is also reported in the log.
Reviewed-by: Jaxad.
|
|
The server was actually using the bitmask enum while the the client
still sent another one, creating discrepancies.
A second problem is that the being direction was not properly
initialized and not updated while it was moving.
Reviewed-by: Jaxad.
|
|
It was too close from the Position class and it leads to
making the server handle one or another type through the
code. Still bugged me many times while making changes.
Reviewed-by: Jaxad.
|
|
Reviewed-by: CodyMartin.
|
|
Trivial.
|
|
Trivial fix.
|
|
Trivial fix.
|
|
Reviewed-by: Bertram
|
|
Also added an header to the autoattack.{h,cpp} files.
Big but trivial fix.
|
|
Also split updateDerivedAttributes and remove the calc check workaround.
Reviewed-by: Bertram.
|
|
The speed conversion needs a standard tile length anyway
and can be improved later once the movement code
will start to handle beings size.
Reviewed-by: Crush.
|
|
setAttribute should be used for this, which also calls updateDerivedAttributes
as needed.
Reviewed-by: Bertram
|
|
Reviewed-by: Thorbjorn.
|
|
Conflicts:
src/account-server/storage.cpp
src/game-server/being.cpp
src/game-server/being.hpp
src/game-server/character.cpp
src/game-server/character.hpp
src/game-server/gamehandler.cpp
src/game-server/inventory.cpp
src/scripting/lua.cpp
src/sql/mysql/createTables.sql
src/sql/sqlite/createTables.sql
|
|
This describes the purpose of the method better.
|
|
Attribute system:
Structure is no longer completely hardcoded. Attributes and structure is
defined by new xml file (defaulting to stats.xml)
Structure defines non-base modifications to an attribute, to be used by
modifiers from items, effects, etc.
Calculating the base value for core attributes is still done in C++ (and for
such fundamental elements the only reason I can think of to do it any other
way is perhaps being able to quickly change scripts without a compile could be
useful for testing, but such things are a low priority anyway)
Item structure:
Modifiers are now through triggers rather than single events. This also
removes hardcoded types - an item could be both able to be equipped and be
able to be activated.
Item activation no longer consumes by default, this must be specified by the
property <consumes /> inside the trigger.
Currently only attribute modifications, autoattacks, and consumes are defined
as effects, but stubs for others do exist. Autoattacks are currently
non-functional, and this should be rectified with some urgency.
Auto Attacks:
AutoAttacks are now separate entities, though not fully complete, nor fully
integrated with all beings yet. Integration with the Character class is
urgent, integration with other Being children less so.
When fully integrated this will allow for multiple autoattacks, through
equipping multiple items with this as an equip effect or even through other
means if needed.
Equipment structure:
As ItemClass types are no longer hardcoded, so too are equip types. An item
have multiple ways to be equipped across multiple equipment slots with any
number in each slot. Character maximums are global but configurable.
Miscellaneous:
Speed, money, and weight are now attributes.
Some managers have been changed into classes such that their associated
classes can have them as friends, to avoid (ab)use of public accessors.
The serialise procedure should also be set as a friend of Character (both in
the account- and game- server) as well; having public accessors returning
iterators is simply ridiculous.
Some start for such cleanups have been made, but this is not the primary focus
here. Significant work will need to be done before this is resolved
completely, but the start is there.
BuySell::registerPlayerItems() has been completely disabled temporarily. The
previous function iterated through equipment, yet in the context I think it is
intended to fill items? I have been unable to update this function to fit the
modifications made to the Inventory/Equipment/Possessions, as I am unsure what
exactly what it should be doing.
ItemClass::mSpriteId was previously unused, so had been removed, but I
notice that it was used when transmitting equipment to nearby clients.
Experimentation showed that this value was never set to anything other than
0, and so has been left out of the ItemManager rewrite.
I am not entirely sure what is happening here, but it should be worth looking
into at a later time, as I am not sure how equipment appearences would be sent
otherwise.
|
|
Reviewed-by: Bertram
|
|
Reviewed-by: Jaxad0127
|
|
|
|
Reviewed-by: Jared Adams <jaxad0127@gmail.com>
|
|
|
