Feature/762 pp up #763
Feature/762 pp up #763
Conversation
…ey are not needed (e.g. when no move present or when boost cannot be applied)
…ug with this - if anything becomes disabled, suddenly none of the other buttons work. Why not?
|
Closes #762 |
…buttons from being pressed (due to early return).
| table.insert(self.move_buttons.pp_minus, {node="pp_minus_move_btn" .. i, text=txt}) | ||
|
|
||
| -- Set nodes disabled until we confirm there's actually a move there, which we will do in the below loop | ||
| gui.set_enabled(del, false) |
There was a problem hiding this comment.
@Jerakin There is a major bug here that I cannot understand. If I set any of these to enabled=false here, or down on line 296, then none of these buttons works anymore. For example, if I delete a move, then I can't click the move again to set it. As another example, if I boost the PP to max, I can no longer reduce the PP.
If I don't do any of this set_enabled stuff, everything works fine. If I leave the screen and come back in, it works fine. For some reason it seems that setting any of these nodes to be enabled=false poisons the others.
Do you have any ideas what's going on?
There was a problem hiding this comment.
This is resolved! The issue was that when the button became disabled, for some reason gooey would always say we are over the button. I'm not sure if this had to do with removing and re-adding the buttons or what. Fixed by checking a.enabled and a.over to early return, rather than just a.over.
No description provided.