- 
                Notifications
    
You must be signed in to change notification settings  - Fork 220
 
Add new feature for automatic attribute allocation #1489
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
base: dev
Are you sure you want to change the base?
Add new feature for automatic attribute allocation #1489
Conversation
Adds a new button and a new popup to the TreeTab that allow the configuration of settings for automatic attribute allocation
- If an `autoAttributeConfig` exists and is enabled, any attribute pathing nodes will be allocated according to the configured weightings and options. - Holding a hotkey will still have priority and right-clicking will also remain unchanged. - Attributes that are gained from non-attribute nodes on the path are taken into account *before* deciding the allocation
`autoAttributeConfig` is saved on a per tree/spec basis to the xml, so that different trees can have different configs.
`autoAttributeConfigSaved` wasn't updated when saving a build
- Didn't properly cache all attributes gained from all non-attribute nodes in path - Also changes `maxValue` to use `<=` rather than just `<`
Even with a set config, attributes can be forced via hotkey or swapped via right click
Disable/Enable the other buttons/fields, when automatic attribute allocation checkbox is marked/unmarked
Automatic attribute allocation wasn't working with effects like "From Nothing" or "Controlled Metamorphosis"
Previous fix led to right-click attribute switching taking into account auto attribute ratios, which is not intended
| 
           Thanks for testing. Can confirm, not user error. I think it has something to do with "Strength" acting as a default fallback, if no attribute can be determined (I copied that behavior from the previous attribute logic). In equal weight scenarios it will therefore usually pick Strength first, but it should only happen on the first node and that's definitely not the case here. I'll look into it  | 
    
`maxDiff` was initialized at `0`, which led to problems when the difference in attribute ratio was nominally negative. There is secondary issue that needs to be fixed related to this, but at least this ensures that maximum value always applies as a limit. The other issue is that target ratios should be recalculated if a maximum value is reached because it changes the relative weights of the remaining attributes. Will be done in separate commit
| 
           Fixed the max value for Strength bug, but found another issue with ratios not being properly affected, once max values are reached, so I'm converting to draft again for the moment.  | 
    
The weights and actual attribute values of attributes that had already reached maximum values were still taken into account when calculating current and target ratios, leading to wrong effective weights. Now, if weights are `str: 10 / dex: 2 / int: 1` and strength reaches its limit, it will be treated as `str: 0 / dex: 2 / int: 1`
0526f77    to
    8f490f1      
    Compare
  
    The `Load()` function called `UpdateAutoAttributeConfig()` before `calcsTab.mainOutput` was initialized, which led to an error. I've added an additional `nil` check now
| 
           Actually found another bug while using it myself. It's fixed now, but I marked the PR as draft again and will give it a few more days of testing with real builds.  | 
    
| 
           Tested a bit more with my own characters, as well as some imported poe2.ninja characters, and it seems to work fine.  | 
    




Description of the problem being solved:
I was getting a bit annoyed by having to micro-manage attributes when planning out passive trees, so I added the option for some automation.
Until now assignment of attributes for travel nodes worked like this:
I found that inconvenient because I would have to keep track of how many attributes I have vs. how many I needed. Especially on triple attribute builds, it felt pretty tedious.
Feature Description
Now there is a new menu button called "Auto Attribute Config" (I'm open to better naming suggestions) on the bottom of the tree tab and it looks like this:

Copied explanation from
help.txt:Other Functionality:
ModifyAttributePopuphelp.txtSteps taken to verify a working solution:
Test cases
enabledbox is checkedBASE,INC, andMORE)calcsTab.mainOutputdoesn't exist yet* "Works", but weapon swap passive functionality is still buggy in itself
Limitations:
Link to a build that showcases this PR:
Test Build with some relevant test items