[Batch Editor] .EncryptionConstant=$rand generates wrong EC values for Maushold and Dudunsparce rare forms

[yor-so]

Describe the bug Maushold and Dudunsparce rare forms, depend on the formula EncryptionConstant mod 100 = 0. Reference: https://bulbapedia.bulbagarden.net/wiki/Personality_value#Maushold.27s_form The EC reroll button works fine and it generates valid values for those forms. But in the batch editor, there's no validations for the instruction .EncryptionConstant=$rand, so the values generated break legality.

To Reproduce In the batch editor, run the instruction .EncryptionConstant=$rand for Maushold and Dudunsparce rare forms. EC generated values are missing the validation, so it generates wrong ec values, breaking legality.

Expected behavior EC values should match the calculation formula for those forms and generate valid ec values.

Screenshots

Additional context NOTE: I have a fix for this issue, I'm reporting the bug so the fix can be associated to this report. Wait for me to send the pull request with the fix.

[sora10pls]

.EncryptionConstant=$rand0

[yor-so]

I think there's a case to fix this. My reasons:

• There's not documentation about $rand0 or $randN instructions, how they work, how many there are, when to use one or another.
• This will require only a batch instruction for all files. If I want to generate the right EC value for those rare forms, but keep random EC values for all other mons in a sav, I'll have to write a more complex batch. This is easier for users.
• This will avoid other people reporting the same issue.

[sora10pls]

Honestly, I am of the opinion that the batch editor should remain "not smart". The point is to modify a given property to be assigned a certain value en masse. Do note that in the future, more Three-Segment Dudunsparce encounters will not abide by EC mod100 logic (e.g. GO transfers, future games where Three-Segment may be obtainable on its own).

As you were advised earlier regarding Trainer ID randomization, you can use the random range syntax. If we do go ahead and add in logic to account for what could result in an illegal Pokémon, there are many other instances we should look at:

• Random PID assignment on PKMs with PIDIV correlation should always yield valid PIDs
• Random range syntax on held items should skip illegal or invalid held items in the given context
• Randomizing to yield a Shiny PID specifically for Max Lair raid encounters should yield xor = 1, without using .PID=$shiny1

I do not believe accounting for all of these should be necessary. If we start adding safety measures for this, we should add safety measures for everything else, too. Not to mention that these proposed changes should also apply to Silcoon, Cascoon, Beautifly, and Dustox, since they work in a similar manner.

[Lusamine]

If the issue is lack of documentation, we should poke PPORG to update the guide: https://projectpokemon.org/home/forums/topic/45398-using-pkhex-how-to-use-the-batch-editor-in-pkhex/

[yor-so]

Makes sense. @sora10pls You can ignore my pull request. The issue with the lack of documentation still stands. @Lusamine, improving that documentation would be great, but I think it'll be a good idea having the documentation in the repo, either in a readme.md file or maybe in a wiki. What do you think?

[Lusamine]

No, it should stay on Project Pokemon where the other support is. That's where the "wiki" is.