collinsmith / riiablo

Diablo II remade using Java and LibGDX
http://riiablo.com
Apache License 2.0
872 stars 99 forks source link

Improve spell auto add/remove #49

Open collinsmith opened 5 years ago

collinsmith commented 5 years ago

eca930a911cef699a36709b1ffc3fa4820abb689 removed the hacky top/bottom rows in the spell quick panel in favor of defining the default skill set (attack, kick, etc). Two things that need to be mediated are 1) certain default skills are conditionally added (if weapon is throwable, then add throw/left hand throw. I need to check and see the behavior of left hand throw versus throw and also if attack is conditional in some case (e.g., maybe it's not available if the character can't attack for some reason). 2) charged skills such as those given by tome of (identify|town portal) and also scroll variants need to be added dynamically. This means adding support for detecting inventory items in addition to charms. I will need to check for built-in support in the excels for adding these skills.

It's possible that the item types somehow define the skills they add, so I'll look into this as well.

collinsmith commented 5 years ago

scroll/book skills: ibk,isc have pSpell=1 tbk,tsc have pSpell=2 All rows have spellicon=-1, so perhaps this column was abandoned and the spells are hardcoded to pSpell. This column is not present in weapons.txt.

throw seems to appear as long as item type is throwable, and left hand throw only appears on barbarians if a throwable weapon is equipped. NOTE: left hand throw always appears, however it is only enabled (not red) if a second throwable is equipped.

left hand swing doesn't ever display (hence ListRow=-1). I think this indicates it's completely unused and the default behavior with dual wielding seems to be alternating between left and right weapons. It might be interesting to look into modifying this behavior to add support for left/right hand specific skills, e.g., you could dual wield but only use one of the weapons to attack with. I may create a feature request for this in the future.

collinsmith commented 5 years ago

After more investigation I've discovered some interesting behaviors, some of which are likely corner cases that I will ignore as the original game does.

Both scrolls define ListPool which may correspond directly with their pSpell (it could also just be coincidence they are the same). These seem to be the only skills that make use of this column. It appears this indicates that this aggregates all individual scrolls and gives them one icon with quantity similar to books.

Books aggregate multiple books into the same skill icon. This skill isn't marked as a charged skill in the save and shows up differently in-game with something similar to its item description. I'm unsure how the same selects which book to cast the spell from, but it's possible that the game has some custom code to track the number of available quantity. I would like to change the icon to use the charged skill icon with a blue number indicating quantity below. I'd also like to, in the future, look into adding some kind of "low quantity" icon when the user has a book with less than say 5 quantity remaining.

Originally it was assumed that saved skills were a DWORD, but it seems that it's really two WORD (or packed DWORD). The first word corresponds to the skill id, while the second value is unclear. The original game does not support reloading the skill bar using charged skills (they reset to empty skill when the character is loaded, but saves show me the value), and the second WORD appeared to be the item index, but it changes based on slot inconsistently and has nothing to do with the charged skill itself. I'll investigate a bit more, but I think what's going to happen is I'm going to use the second WORD as some kind of identifier to the item that the charges belong to so that the icon can reference the correct charged skill. If the character is saved using a charged skill and reloaded while also having the uncharged skill, then the skill is set to the uncharged skill (so my guess is the second WORD is wiped when loaded).

This is interesting too, items with the same charged skill will override one another with possibly the larger level of the group. I didn't anticipate this because the attributes on the item still maintains each description discretely, but once the charges on the selected charged skill are used, the unused skill is basically hidden from the user (I thought they might show up only when the "primary" one was used). I think this whole deal is a corner case, so I may just ignore it and if someone wants to add support for this later on an enhancement, be my guest, but I'm pretty sure the base game won't generate items that conflict in this manner.

Each charged skill is never combined on the skill quick panel -- this will make it easier to determine which item to subtract charges from. -- I don't know how this will deal with aggregate charges -- I can test, but I might ignore this behavior as a corner case that hopefully never comes up as an issue in production.

collinsmith commented 5 years ago

After a bit more investigation, it appears that the second WORD seems to correspond to some kind of skill id. My best guess is that when a skill is added/removed from the player's list, it's assigned an id which corresponds to this value. I am basing this from checking the skill id then unequipping and requipping the item to "reset" the id and then checking it again. In this case, the same skill is referenced from the same item, only the order in the list is reset.

This doesn't change the item save order, so this might be a run-time only thing, which would also explain why loading the character resets the skill to default if it was a charged skill. This also complicates the stat-skill relationship -- this needs to be worked out how the binding it created.

collinsmith commented 5 years ago

I tested giving a runeword item the same charged skill twice (two entries in magic and runeword prop lists) to test the behavior and once the charges on the runeword were used up, the base item charges weren't touched and the skill was infinitely castable. I won't make any special considerations for this corner case then, just as the game clearly doesn't. It is an interesting behavior though, since visually the game aggregates the properties and adds their charges even up to the skill icon, however casting the skill only effects one of the counters.