Quote:
Originally Posted by nevak
Hi!
I'm not sure if this has been already explained here, however if it has, just let me know and I will delete this =).
|
don't !! that's very interesting.
during coding of the lapis editor, i saw that the used cost & success rate was defined by the ReqIg value of the lapis.
of course (!?!) the used ReqIg are not 1, 2, 3, 4, ... but they start at 30 and jump (somewhere) to 98+
here are the values i can associate:
Code:
0003E8 1.000 reqIg: 30 (50%)
000FFF 4.095 reqIg: 31 (46%)
002BF2 11.250 reqIg: 32 (40%)
0059B5 22.965 reqIg: 33 (32%)
00A140 41.280 reqIg: 34 (24%)
021AAC 137.900 reqIg: 35 (16%)
0591C8 365.000 reqIg: 36 ( 8%)
075300 480.000 reqIg: 37 ( 2%)
099138 627.000 reqIg: 38 (~1%)
0C6BB0 814.000 reqIg: 39 ( 1%)
0FDE80 1.040.000 reqIg: 40 (<1%)
2625A0 2.500.000 reqIg: ??
3567E0 3.500.000 reqIg: ??
53EC60 5.500.000 reqIg: 98
7270E0 7.500.000 reqIg: 99
958940 9.800.000 reqIg: ??
- did you trace how ECX was settled ? (how data at DS:ECX+4C6490 was defined)
Edit: the point is: how a RegIg value (if it's actually used) is processed to obtain a valid index (among the ones listed here), and finally be sure that the RegIg values used in interface are valid.
- did you also find the success rate array ? (it's not the following bytes or they are widely shake to give the percents).
Edit2:
the full list of allowed ReqIg values is so:
Code:
1.000 reqIg: 30 (50%)
4.095 reqIg: 31 (46%)
11.250 reqIg: 32 (40%)
22.965 reqIg: 33 (32%)
41.280 reqIg: 34 (24%)
137.900 reqIg: 35 (16%)
365.000 reqIg: 36 ( 8%)
480.000 reqIg: 37 ( 2%)
627.000 reqIg: 38 (~1%)
814.000 reqIg: 39 ( 1%)
1.040.000 reqIg: 40 (<1%)
2.500.000 reqIg: 96
3.500.000 reqIg: 97
5.500.000 reqIg: 98
7.500.000 reqIg: 99
9.800.000 reqIg: 100
Credit and thanks go to Nevak.