Validate Attribute maps behavior

[collinsmith]

D2S.StatData isn't ever modified or used properly in conjunction with item stats. This data should be read into the Player entity's stat enum map. Once it's in a map, then items can append to it.

Some things I'm unsure about:

• do all non-static entities need a stat map (Player, Monster, etc), i.e., does the Monster stat map function the same, or do special considerations need to be made.
• stat map should track modifications, i.e., if a stat is modified it should appear blue
• when an item is (un)equipped will the entire map need to be recalculated?

The concern for bullet 3: For things like modded strength/dexterity or stats in the save file it's not a big issue, however this becomes an issue when two items contain the same overwriteable stat and one is removed, which would remove the stat -- I can possibly just not care about this and deal with it later or put these sort of stats in a trailing array list. This would be a problem for say 2 items with a 30% chance to do some event. Technically this should be treated as 2x30% (60%) chance.

[SomeFire]

Technically this should be treated as 2x30% (60%) chance.

No, it is 2 different checks for the same event with 30% chance each. So, it is possible to have event twice with 9% chance (0.3*0.3=0.09) and higher chances for single event. When you work with these checks separately, you avoid issues when events are the same, but differs in numbers (e.g. 30% for critical damage x2 and 30% for critical damage x3).

[collinsmith]

The game already takes care of that. Different skill levels will change the properties hash, so it won't aggregate with properties even if they are the same skill/% chance/etc.

The problem is to work backwards from that, since the player entity will contain an accumulation of all stats and properties from all items/charms/etc they are carrying, I'm afraid some items will have their properties overwritten by other items (not just added). So when that item is removed, even though the player still might have another item with that property, it won't get added back correctly.

I'm going to investigate this further, it might not even be a problem, it's just a concern that it could be a problem.

[collinsmith]

I created Attributes which is a PropertyList that tracks modifications and maintains a reference to "base" stats. The idea is that Attributes will act as the base stats for an item or player that supports apply(PropertyList) which will generate a copy of the base stats and then add the specified PropertyList or perform the given operations on the base stats.

E.g., An armor has armorclass=10, +10 armorclass and +100 item_armor_percent. The base attributes are only 10, but then the properties are applied, first +10 is added, and then that entire value has +100% added for armorclass=40. This is still a WIP, but so far with the armors I've tested it's working. I just need to nail down which property lists are where and make copies where needed. The reason why Attributes only modifies the copy is because the base stats need to be retrievable, e.g., when the item is saved each property list and base stats should be discrete.

Some considerations I'm trying to make are that the original stats are accessible, and this should reasonably support removing stats on-the-fly, e.g., removing set bonuses if a set item is removed. Additionally, some items might not have any use for stats (e.g., attributes or fortitude runeword gives enhanced damage on an armor) -- in these cases the properties should get pushed up to the next level.

[collinsmith]

I made some changes to Attributes to make the different property lists more clear. I also added the ability to add property lists, which are multiplicative right now, and remainder property list which contains stats which the parent needs to handle (+damage on fortitude armor, or +skill for example -- neither of these do anything on the item itself and are meant for character)

[collinsmith]

I'm having an issue with the mutability of some stats when applying (some are unintentionally changing). For now I'm making probably more copies of the stats that necessary to avoid this, so I may want to explore some alternative options.

[collinsmith]

I had to make a small fix. op for energy and vitality are unique in that they should also modify the stat itself in addition to the opstat. vitality is unique in that it should only modify on opstat=maxhp to avoid a double increment.

[collinsmith]

This issue can probably be closed, but do all non-static entities need a stat map (Player, Monster, etc), i.e., does the Monster stat map function the same, or do special considerations need to be made. needs to be looked into.

[collinsmith]

I think not. I'm moving forward with simple adding an Attributes component to monster entities. This means that damage calculation will all use the same code.