`Moveset` struct stores 4 moves, and exposes methods to interact with a moveset.
`IndividualValueSet` stores a 6 IV template (signed).
Performance impact:
* Less allocating on the heap: Moves - (8 bytes member ptr, 20 bytes heap->8 bytes member)
* Less allocating on the heap: IVs - (8 bytes member ptr, 28 bytes heap->8 bytes member)
* No heap pointers, no need to jump to grab data.
* Easy to inline logic for checking if moves are present (no linq usage with temporary collections).
End result is faster ctor times, less memory used, faster program.
XD compares the player TSV against the non-shadow members, which is unnecessary but does result in them being able to cause shiny skips.
Update the VerifyNPC method to remove tsv check, as it's just repeating the logic we've done in the lock generator.
Added a test method that can be stepped through; compare the team results manually since they aren't exposed for interaction.
Closes#2751 , big thanks to @ijuintekka for being so detailed in their investigation/report!
Co-Authored-By: ijuintekka <ijuintekka@users.noreply.github.com>
Now accounts for the shiny locks & associated restrictions, abusing the
recursion by setting & unsetting the required CPU Trainer's shiny value.
Repoint all test methods to use the new obj methods
Now gets count=2 tests working
yield return new SeedFrame { FrameID = ctr + (l.Seen ? 5 : 7), PID = pid
};
used to be ctr + 6, needs to alternate even-odd
all 2 lock cases pass, but didn't make lock3's pass. Something else is
still amiss :)
break out some classes for the solidified lock objects
commented out test calls = not working
will have to debug in more detail later; the first lock is always
working at least.
data sourced from
https://github.com/ijuintekka/Eligor/blob/master/Eligor/Spread.cs , not
sure if it's perfect.
can't cleanly condense deviating team appearances as double-shadow leads
can't be selectively encountered. didn't feel like modding lockfinder's
recursive algo to be smarter.
tested for 2 locks, later commits with legality check implementation
will feature more lengthy lock checks (test case automation).
https://pastebin.com/VdbjWaqL
(species doesn't matter since most are 50/50 ratio)
force colo starters to be male only
use some c# lang features for EncounterType flags
add edge case PIDIV detection for starter gender/shiny lock scenario
adds a little documentation for those unfamiliar with the NPC PKM
generation quirks.
Colosseum Starters will now be recognized with a different PIDIV type
which is specific to them & them only.
