@all
table updated! if you're having random crash still, re-download and test~
///************************************************************************************///
Turk wrote: ↑Sun Feb 04, 2018 9:45 pm
[...]
ioshilee wrote: ↑Tue Feb 06, 2018 3:13 pm
[...]
just updated the table, all the crashes should be fixed, please test~
///************************************************************************************///
cosminuk2011 wrote: ↑Sun Feb 04, 2018 9:43 pm
First of all I want to say, Thank You Cielos for your free great work.
Second, please add back "Reset Outfit Quantities" if it is possible. I'm stuck with 100 "Bathhouse Towel Outfit" and I really want to reset them to 1. I don't want to lose the game save that I already have done 80%.
It is safe to use the table with uplay online. It is any risk to get a ban? However, it is a single player game.
1. as of patch 1.20, you can sell back the outfit to the Weaver.
2. I'm playing the STEAM version with almost all the scripts on (except for the inf. item script). as you said so yourself, it's a single player game, as long as you don't touch the micro-transaction part, I think you're ok~
///************************************************************************************///
SunBeam wrote: ↑Tue Feb 06, 2018 6:29 am
[...]
hi, it's been a while~
ok....
as you've just mentioned in the PS, at the beginning the crash were caused by insufficient bytes allocated for the CE's injection code template.
rather than 5 bytes it SOMETIMES used 14 bytes.
that time I rewrote my scripts to treat all the injection jmp as 14 bytes to deal with this type of crashes.
than it's the "null scenarios".
after these implementation, I thought all the crashes has been fixed. but the bug reports says otherwise.
as I always activate all the scripts I used at the start of the game, I just state that as the precaution of crashes until I fixed it.
then I found out, for my scripts, that it's an by-product of using readmem and reassamble.
e.g.
Code: Select all
ACOrigins.AK::WriteBytesMem::Bytes+7F7B99 - 74 0C - je ACOrigins.AK::WriteBytesMem::Bytes+7F7BA7
ACOrigins.AK::WriteBytesMem::Bytes+7F7B9B - E8 5003FBFF - call ACOrigins.AK::WriteBytesMem::Bytes+7A7EF0
ACOrigins.AK::WriteBytesMem::Bytes+7F7BA0 - C6 87 72010000 00 - mov byte ptr [rdi+00000172],00 { 0 }
ACOrigins.AK::WriteBytesMem::Bytes+7F7BA7 - F6 87 70010000 01 - test byte ptr [rdi+00000170],01 { 1 }
I used readmem on "ACOrigins.AK::WriteBytesMem::Bytes+7F7B99"
and then used reassamble on "ACOrigins.AK::WriteBytesMem::Bytes+7F7B9B"
when CE's are using 14 bytes to jump to my code cave, reassmble(ACOrigins.AK::WriteBytesMem::Bytes+7F7B9B) would be most likely be 14 bytes as well. thus using readmem on "ACOrigins.AK::WriteBytesMem::Bytes+7F7B99" would result in a crash.
but as I always activate all my script as soon as the game is booted up, I never encounter this problem until I have time to tested run the scripts by enabling them in-game.
anyway, this crash had since been fixed.
then I got busy and stopped cheating for awhile, and I got back to update scripts for the latest update just recently.
and there were still reported crash occasionally.
and the most recent report is for the int. item script.
as I follow the reported steps and failed to re-create the crash, together with the recent cracked game, I haven't go deep yet.
until today, I found out the crash was caused by a similar reason.
I simply used reassamble on conditional jmp.
while it would works properly when it's a short jmp, but CE would failed to compile it properly if it's too long a jmp.
e.g.
jne 141BE2C4E
would becomes
jne 241BE2C4E (e.g. 0F85 9A2BA97F)
because the destination's address is larger than signed 4 bytes.
so, using reassemble may crash the game when these "long jumps" occurred.
and, I've rewrote these reassemble part of my scripts just now and about to upload for testing when I saw your message..
now to avoid these long jumps, I can either used STN's approach (by searching the nearest codecave manually, or using your approach.
I thought STN's approach would leave some self-made codes in the memory when you de-activate the scripts mid-game.
yours is a better approach as you'd clear the code cave when it's de-activated. still I don't like the feeling that there's a solid limit bytes I can implement my codes in...
anyway, in the end I think it's just different approaches.
and if you think my approach (as describe above) is "if CE stopped working for some reason at some point, you'd give up instead of figuring out how to make it work again", I won't say I don't care (or else I won't bother typing the above crap), I would feel bad, but I think I can live with that...
finally, you back for real this time? anything you plan to release on FRF again?