Kaphotics Posted November 18, 2018 Posted November 18, 2018 PKHeX is programmed in c#; the games are not. There are certain calculations that are done using floating point which end up with different results (between the two programming languages): Until a workaround is found, there may be some inaccuracy in the calculations (+/- 1 or ~0.0001) 1
Reisyukaku Posted November 19, 2018 Posted November 19, 2018 Interesting. I've experienced a thing before where a calculation relied on integer underflow/overflow, but theres a feature in C# to disable protection from it... As far as this goes, it looks like its truncating your float or rounding to the nearest tenth, which is weird.
Sabresite Posted November 21, 2018 Posted November 21, 2018 Generally using a double or decimal fixes it. I haven't had time to test it but I assume Kaphotics had already tried various options.
Iz. Posted June 1, 2020 Posted June 1, 2020 (edited) Hello I wanted to know what measurements PkHex is using for SwSh? I assumed PkHex automatically added the weight/height when you are genning a Pokemon, but I can see now that is not the case. I opened up a legitimate shiny Rilllaboom, which I obtained by breeding. PkHex says it's height is 114, and weighs 86. I'm thinking the weighting measures might go by kilos, as Serebii has Rilaboom as 90 kilos. Not sure what the height measures may be. I just noticed something very important. I am viewing all the eggs I have bred of the same specie. They are all different in height and weight. Is this due to the fact that the Rillaboom parents I used, when gen with incorrect height and weight? Or is this an error on PkHex? Edited June 1, 2020 by Iz.
Dark_Ansem Posted June 20, 2020 Posted June 20, 2020 Aren't height-weight values actually working differently, in the sense that they range between pre-set sizes?
Hide Posted June 20, 2020 Posted June 20, 2020 On 11/18/2018 at 4:23 PM, Kaphotics said: PKHeX is programmed in c#; the games are not. There are certain calculations that are done using floating point which end up with different results (between the two programming languages): Until a workaround is found, there may be some inaccuracy in the calculations (+/- 1 or ~0.0001) Maybe you could create a table with the right (expected) values and then have PKHEX look for the right value using the approximate result from C#. Something like a dictionary for heights and weights.
Kaphotics Posted February 9, 2022 Author Posted February 9, 2022 Turns out this was a combination of using the same float value constants & operation order. I've reverse engineered the calculation and PKHeX now emulates the entire call chain correctly, as implemented in this commit: https://github.com/kwsch/PKHeX/commit/9c5955c10404caa9170b7423e39a773212765e8a This issue is now resolved; un-sticky'ing. Have fun with all the h/w calc precision 1
Recommended Posts