Adding missing PKM.ConvertTo methods

[Chnapy]

Hi,

For my own project, I had to create quite all missing "ConvertTo" methods, for instance PK7.ConvertToPK8, so that I can convert any PKM to any other target type.
Since I made this work I guess it would be good to move all this logic in PKHeX, so PKMEditor.LoadFieldsFromPKM would be more complete.

My implementations need changes to be compliant with PKHeX structure, and have propably multiple blind spots, but I think it can be a good basis.

An example with PK7->PK8: https://github.com/Chnapy/PKVault/blob/main/PKVault.Backend/storage/services/PkmConvertService/PK7Converter.cs

Before going further I want feedbacks so I'm not missing something here.

[kwsch]

Already exists:

PKHeX/PKHeX.Core/PKM/Util/Conversion/EntityConverter.cs

Lines 73 to 80 in 906cae2

	/// <summary>
	/// Converts a PKM from one Generation format to another. If it matches the destination format, the conversion will automatically return.
	/// </summary>
	/// <param name="pk">PKM to convert</param>
	/// <param name="destType">Format/Type to convert to</param>
	/// <param name="result">Comments regarding the transfer's success/failure</param>
	/// <returns>Converted PKM</returns>
	public static PKM? ConvertToType(PKM pk, Type destType, out EntityConverterResult result)

PK7=>PK8 is accomplished via the PK7=>PKH=>PK8 path.
PK8/PB7=>PK7 are not legitimate transfer paths, therefore are not implemented, and require the user to opt-in to property-copy reversing methods. Once enabled, the logic will fallback property copy.

The PKHeX.WinForms GUI automatically converts any .pk* file that is loaded (or indicates that conversion isn't possible) before loading it to the editing fields/slots.

[Chnapy]

Ok, I didn't see EntityConverter.TryConvertFromHOME in this logic.

So there is no need to handle these not legitimated transfer paths ?
Another example would be PK2->PK3, since this is done with fallback property copy when enabled, properties like IVs are not converted correctly. This kind of issue appears with multiple cases.

I understand that opening a PK2 in my SAV3 is not expected for legality concerns, and that conversion cannot always be perfect.
But I thought that maybe opening any pk file in any save (if valid species) would be nice, breaking as possible walls between some generations, following a "best effort" principle going further than the fallback property copy.

[kwsch]

properties like IVs are not converted correctly

There is not a PK2->PK3 conversion routine made by GameFreak/any official developer, thus anything that you dream up is a fabrication. IVs in Gen3+ are 0-31, and IVs in Gen1/2 are 0-15. They do not map 1:1. Shininess is derived from the PID/TrainerID in Gen3+, and is derived via IVs in Gen1/2.

Any attempt at backwards conversion would need to exhaustively find encounters using the EncounterGenerator (to get a possible met location and level), and have a convoluted set of settings to allow for retaining of all moves (even if illegal) or brute-force dropping of specific moves/mutations. Gen2->Gen3 does not have 1:1 encounters available, so you'd need settings to conditionally choose events/ignore shiny/hidden power, potential de-volving for future-gen evolutions, and many more considerations.

Since it is not official, and there would be a mountain of considerations/configurations needed to resolve all end-user complaints, it is easier to just not support rich backwards conversion. AutoLegalityMod is a nest of complicated spaghetti that tries to reverse a battle template into a PKM, and this would be a similar situation. Realistically, the best you can do is use AutoLegalityMod to convert an exported set back into a PKM in your destionation type; that would try to respect most of the core properties, and arrive at a legal state (or indicated failure).

[Chnapy]

They do not map 1:1

Maybe there’s been a slight misunderstanding. I wasn’t suggesting aiming for a perfect conversion. My thought was simply that in those cases, we can try a partial conversion, not perfect but still an improvement over a direct property copy, ignoring most complex parts.
Since not all users necessarily require a perfect result, it seems reasonable to consider this as an option, especially given that property copy can already be enabled.

But ok, I understand this is not something expected here, and that it'd add a significant amount of code to maintain.

Thank you for your time and the explanations !