Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix aspd buffing v2 #19

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

nmaligec
Copy link

@nmaligec nmaligec commented Aug 2, 2021

Just like the previous version (v1) this fix addresses 2 points that still prevent aspd buffs from selecting the correct character. The changes to the fairy, enchanted and awakened code sections remain mostly the same between v1 and this version. The main difference is that for characters who are eligible for an aspd buff, a variable is set in the character's respective init section in Player:init(). The buffing sections can use this variable instead of a more lengthy table search. These variables correspond to the same list added in v1, and are set to true if the character is not on that list.

A similar approach as above for avoiding table searches was used to optimize the cooldown bar update code in arena.lua. The non_cooldown_characters list was removed since it's no longer needed.

The intention is not just avoiding table searches, but also to achieve easier code maintenance. The centralized lists in main have to be updated when new characters are added or existing characters have their attacks modified. By instead placing that information inside the init code on a per character basis, it will be in the same place where their attacks are modified or where new characters are added. This makes it more convenient to update and less likely to forget.

Additional goals that were not achieved:

  1. Use the same approach to handle the class table searches by just placing variables in the character init sections like: is_mage, or is_enchanter, etc... I'm not yet familiar with all the sections of code that use the classes tables, so I leave it as a suggestion for someone who knows the code better to implement safely.
  2. Use the same approach to handle non_attacking_characters table searches in buy_screen.lua. Unfortunately the buy screen uses the list before initializing characters. A major change to the buy screen would be needed and I don't know if it would be worth it. At any rate I don't yet understand the code well enough to do it myself, so I just leave the suggestion here for possible discussion by people who know the code better.

This uses the same approach as the v1 fix, but checks a variable set directly on the unit itself instead of checking a global table.

Manually set the can_use_aspd variable to true in each unit section in Player:init, where the unit has a timed action with tag 'shoot' or 'attack'.
Similar to the aspd buff changes, the draw code now checks a variable set directly on the unit, instead of going through a table.

Manually added the has_cooldown variable to each appropriate unit section in Player:init. Also removed the non_cooldown_characters table from main.lua, as the only place that uses it has been modified in a way that no longer needs it.

Note: Even though the pyromancer and cryomancer do damage on a timer, it is handled by the DotArea code and so the variables needed to fill their charge bar never get set. These are the only two characters that exclussively attack through dot damage routines. For both, the cooldown flags were left false by default. Originally they were left out from the list of non_cooldown_characters.
@nmaligec
Copy link
Author

nmaligec commented Aug 3, 2021

Issues are turned off and since I touch on the relevant section of code here, I'll note it here.

Some characters are unintentionally more rare than others

In the code for the buy screen, it checks if the 3 character buy options are all contained in a special list of non_attacking_characters. It keeps reselecting until at least one character is not on the list. This roughly reduces the chance of getting, say a squire, by the chance that the other two are not on the restricted list.

The current list of restricted characters is: cleric, stormweaver, squire, chronomancer, sage, psykeeper, bane, carver, fairy, priest, flagellant, merchant, miner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants