Allow PP Ups to be edited

[dot-Comfey]

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.

[dot-Comfey]

[Karthik99999]

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]

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]

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]

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]

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]

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.

[kwsch]

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.

[KrisXV]

Suggested change

	set.movePPUps = buf.substring(i, j).split(',').map(number => parseInt(number));
	for (var q = 0; q < buf.substring(i, j).split(',').length; q++) {
	var ppUpsUsed = parseInt(buf.substring(i, j).split(',')[q]);
	set.movePPUps[q] = ppUpsUsed;
	}

[larry-the-table-guy]

You might want to pull buf.substring(i,j).split(,) into a variable outside the for loop. Also set.movePPUps needs to be initialized w/ an array before writing to it.

[dot-Comfey]

Initializing the array with the values as strings and converting them to numbers works without crashing or upsetting Linter, so I've done that.