| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Things done:
- Removed the equips table and added another column which keeps track about
whether the item is equipped or not
- Added a message to notify the client about failing equips instead of
hardcoding to chat notification
- Removed the move possibillity. It was a quite long function and our future
idea of the inventory does not need any moves
- Removed the inInventory and inEquipment parameters from chr_inv_count,
but added a equipped key to the table that chr_get_inventory returns
This change makes equipped items still being in the inventory. This means
in-inventory triggers are still active! However it makes no sense to disable
this triggers during equipping since it will appear as still in the inventory
to the client.
|
|
This was the final step to remove the hierachy with Entity on the top.
|
|
I did not really care too much about staying consistent with the use of
static_casts to Actors since they are only temporary anyway until Actor
is a component too.
|
|
A CharacterData was created as a proxy class in order to allow using the
old serialization method.
|
|
This allows the server to compile with c++0x (and enables it).
This also includes some coding style / readabillity fixes.
|
|
Also added checks for invalid item and zero amount
Reviewed-by: bjorn.
|
|
Same thing, but shorter.
|
|
Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
Reviewed-by: Erik Schilling
|
|
Due to a misplaced semicolon, it always returned false after the first
instance. This function is only used by the script function
chr_unequip_item.
Reviewed-by: Yohann Ferreira
|
|
the function can now count in the inventory
and/or the player's equipment.
I also fixed the script function and added a use case
in the example map.
+ Fixes after Ablu's review.
+ 2nd fix after Ablu's review: Fix the inventory remove behaviour.
Resolves: Mana-Mantis #288
Reviewed-by: Ablu
|
|
You can unequip using the slot or an item id.
+ Fixes from Ablu's review.
Resolves: Mana-Mantis #350.
Reviewed-by: Ablu.
|
|
One per inventory slot, one per item id or name.
+ Fixes from 2 Ablu's reviews.
Reviewed-by: Ablu.
1st part of Mana-Mantis #339, 350.
|
|
Reviewed-by: o11c.
|
|
Reviewed-by: Thorbjorn Lindeijer.
|
|
We can't arbitrarily remove inventory items on initialization, and
shouldn't have to, because what's in the DB was correct when it was
stored.
Also, there should be no need to check the inventory after inserting
items, since the insert method should already make sure not to insert
items when there is no space.
Reviewed-by: Yohann Ferreira
|
|
an arbitrary number of layers. (up to 255).
|
|
Made the server handle only one slot type requirement since
it's irrelevant to have more anyway.
Plus, it simplifies the code for both equipping/unequipping.
I also added a dagger to show how equipping/unequipping
is working.
|
|
It will make the client capable to tell which item
is to be unequipped when there are several item equipped
within a slot type, for instance.
The client has now yet to be upgraded to follow the new protocol.
|
|
|
|
I made the system handle the fact that equipment item
are completely unlinked to the inventory items.
Equip items now have a unique itemInstance number permitting
to equip the same item type multiple time when the slot capacity
is wide enough to do so.
I also prepared the functions to welcome in the near tests against
scripted equipment.
The equip process is known to be working server-side but the unequip
process has yet to be reviewed, even if implemented.
|
|
Previously it was a list of pair ofunsigned int,
used to get the equipment slot requirements.
It didn't make sense as the ItemEquipsInfo was already a list of it.
So you had to manage with a list of list and that ended up being
irrelevant to the need.
I had to disable the equip function to permit compilation.
This will be fixed in my next commit.
|
|
to something more meaningful.
|
|
|
|
|
|
Moving and splitting items in the inventory window should be
much more responsive now.
|
|
The unecessary equipment check was already removed, but the now
useless force parameter is now also removed.
|
|
|
|
in oversized inventories.
|
|
The inventory part is done. The equipment one will only handle
equipment triggers for now.
|
|
This is in preparation of fixes for issues: #373, and 379.
Equip and inventory related packets are the only ones changed.
|
|
now, the equipment slots are independant from the inventory slots
according to the inventory and equipment data.
This will permit to avoid checking the equipment each time
one touches the inventory and vice versa, and make the former
delayed mode useless.
Also, note that equipped items will be removed from inventory
and readded once unequipped.
The design will permit the following, even if not implemented yet:
- To make equipment items stackable again, if wanted.
- Have more than one item with the same id equipped on different
slots using the itemInstance field.
Note: I didn't add the database structure updates yet, to see
whether other changes may later go along with those.
|
|
I said I wouldn't do it, but I change my mind. Here is why:
The delay mode is used in the trading code, and in the inventory
code for lua only.
In the lua part, the delay mode is useless as it is used only
when the script is requesting removal of more items than owned.
This is something that can't be handled well anyway,
as for the script part, even when the character was still
keeping its items.
Plus, it's not actually an error, IMHO.
In the trading code, it made sense. But the next commit
will bring design changes making the inventory items
and the equipment items not linked anymore. Hence, making
it impossible to trade equipped items, for instance,
which is a good thing IMHO. It will also remove the need
of a delayed inventory mode in that case.
The two cases where it is used will disappear, making it
useless.
Last but no least, the part watching for equipment changes
in the commit() function is not something easy to debug
without first having a proper and working base.
(checking of two multimaps changes, for instance).
We can add it back once the code has been fully debugged
for the most skilled among us.
And yes, I am sure of what I'm currently doing.
For now the whole inventory and trading code is in need of review
but it already was, anyway.
|
|
This doesn't change anything yet.
|
|
* The 'itp' parameter is no longer simply ignored (seems to be a small
optimization in Inventory::remove)
* Avoid incrementing an invalid iterator, fixing a crash (problem found
by Stefan Dombrowski)
* Use the right inventory index in the call to changeEquipment, which
previously was using "it", which would be equal to "it_end" there.
Reviewed-by: Stefan Dombrowski
|
|
Listed: http://bugs.manasource.org/view.php?id=324
Reviewed-by: Yohann Ferreira
Reviewed-by: Jared Adams
|
|
Reviewed-by: Bertram
|
|
Also added an header to the autoattack.{h,cpp} files.
Big but trivial fix.
|
|
Mainly for consistency with the client, and the general consensus was
that these numbered versions were clearer.
|
|
Don't try to notify the client when automatically removing unknown
items, since at this point the client hasn't connected yet.
Reviewed-by: Freeyorp
|
|
Whether it's a good idea to automatically remove unknown items from the
inventory in the first place is something to be considered.
Reviewed-by: Freeyorp
|
|
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.
|
|
|
|
Also updated the headers to refer to the GPL by URL instead of
suggesting to contact the FSF by snail mail, as per the latest
GPL usage instructions.
|
|
defines.h, and removing some overheading along the way.
|
|
|
|
the items.xml. Cleaned out some nonsensical weapon types.
|
|
only receive attribute change messages when the attribute actually changed. Left the HP mechanics as they are for now (although I consider them flawed).
|
|
|
|
them.
|
