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

Allow PP Ups to be edited #2222

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

Conversation

dot-Comfey
Copy link

Client-side change. I'm not a web designer so a lot of the HTML/CSS may be messy. However, it seems like the general interface works; PP ups can be edited, and they are able to properly import/export as well as pack/unpack. Pokemon sent into battle have the PP up changes applied.

Screenshot 2024-02-10 165516

Client-side change. I'm not a web developer so a lot of the HTML/CSS may be messy. However, it seems like the general interface works; PP ups can be edited, and they are able to properly import/export as well as pack/unpack.
@dot-Comfey
Copy link
Author

Screenshot 2024-02-11 201438

@Karthik99999
Copy link
Contributor

Screenshot 2024-02-11 201438

Just a suggestion, can we show the actual pp values in the dropdown instead of the amount of pp ups? I think it would be a lot more clear for non 5 pp moves. Not sure what others think about this though.

@pyuk-bot
Copy link
Contributor

It doesn’t look like this will be a problem judging by the code, but those screenshots have me worried. Can you assure that both newly created teams and old teams from before this change will have their pp ups default to the max?

@dot-Comfey
Copy link
Author

They do default to max, and teams transferred to the new client should be able to unpack properly because moves without a defined PP up value get set to 3.

@dot-Comfey
Copy link
Author

Screenshot 2024-02-15 234209

In the current implementation, PP ups will update every time an update to a move is made; PP ups are associated with a move slot and not a move, so if a move is changed, changes to PP ups will carry over, but if a move is removed from a set by trying to add a move twice, any changes to PP ups will continue to be associated with the original move.

@DaWoblefet
Copy link
Member

I'm not sure this should be editable in the UI at all, as opposed to being something that is just changeable via importing. We're taking up a lot of real estate in the teambuilder for a feature that will go unused the vast majority of the time.

@dot-Comfey
Copy link
Author

Despite how much work I put in trying to create a UI, I honestly have to agree; having it be easily accessible to newbies is likely to confuse them, but those who know will know.

Only editable in the import/export interface now, which can be done by adding ';2', ';1', or ';0' after a move.
@kwsch
Copy link

kwsch commented Feb 17, 2024

Based on my experience with editable entities, my thoughts:

  1. Hide the PP selections by default.
  2. Put a button-label on the far right above where it currently is (text=PP); italicize/color it if PP Ups deviate from the default max index. Dunno if screen readers/accessibility needs to be considered, so tagging it with a reader description might be needed too.
  3. When the button is pressed, it will contract the move text boxes and show the PP Up overrides. Pressing it again will hide them and the moves will re-extend.
  4. Italicize/color any selections that deviate from default (max).
  5. When visible, show the effective PP value as discussed (not the PP Up count).

For paste formatting, Moves are currently formatted as - {move}; possible inclusions for PP Ups:

  1. Treat the - as the PP Up specifier; acknowledge 012- as the first character to be interpreted as 0123 PP Ups.
  2. Append an override after the move (PP Ups: 1)
  3. Include a separate line if any PP is overridden before/after all moves (like PP Ups: 3|1|3|3)

Pros/Cons:

  1. Breaks parsers, slightly obtuse, but it's the least visually disruptive and quickest for humans to grok.
  2. Breaks parsers, easiest for human reading.
  3. Outdated parsers will likely ignore the line, but easy for humans to miss if it's before moves.

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

Successfully merging this pull request may close these issues.

None yet

6 participants