Cheat engine issues and "locking interval"

[hrydgard]

Got this in a PM on the forum. Let's see if we can break this down into actual fixes.

"
We need code locking interval option for the codes part.

This option is A MUST HAVE for the Cheats menu.
It will allow us to change code locking interval "cheat hz" so games can not change values by themselves once a code is activated.

Currently PPSSPP Cheat's engine doesn't freeze the codes the way it should be and the game changes values itself even if a code is activated thus leading to crashes/not working codes.

Please ADD this function.
Add the ability for users to set cheat hx in Micro Seconds (Code Locking Interval)

Second:

JIT causes freezes when going to cheats menu. For example just when JIT is on Going to Cheats menu and going back to game causes a freeze with or without enabling/disabling any of the codes.

Third:

Soul Calibur Broken Destiny has broken texture colors for the projectiles. The projectiles color for most of the attacks is WHITE which isn't what it should be. You can see a video from psp and see one on PPSSPP to ensure what I am telling.

But my main problems are the first two.
I need a code locking interval option for the cheats. This will be a great service and huge upgrade to the emu. Thank you. Many people ask for this and I personally want this as I am a game mods dev too.

Thank you in advance.
"

[sum2012]

Hmm,need add option: enable once,enable forever

[LunaMoo]

@sum2012 - if you create an asm cheat, that's exactly how it would work already:3. Instead of changing value, you can check which code writes it and modify it to not change value at all, or to set it to whatever you want.
I don't think you can make such option for typical value freezing cheats, even if, it would likely kill performance for everyone, just to help a few that doesn't know how to use ppsspp disassembly to make better cheats.

To reply on that message ~ never got a freeze caused by JIT without activating any cheats myself. I think Melkor from the forums had an issue like that, but he described the issue in very confusing way. I think he just changed some game code by accident maybe even by cheat engine, which had no effect making him think it was nothing, but leaving cheat menu refreshed jit triggering a crash.

I would say I don't have anything against an option to change frequency, the only reason to change frequency would be to not let it show when it refreshes, but the cheat when done correctly would still work even if the refresh would be visible. Common problem with that is caused by confusion. Usually when the same value is written by game somewhere at very high frequency, it's just a display value not used for any calculations anyway, thinking that refreshing it faster than the game will create a cheat is like a most basic mistake people do when starting making cheats and are unable to find other address, but it would not help them making working cheats.

I don't really know how game changing some value faster than cheats do, would be cause of a crash if it would not just be an incorrect address, since they differ alot in some games and that's the primary issue we can observe people have with "not working cheats" and "crashes" caused by cheats.

To deal with address difference, from the early days of CW cheat for ppsspp someone added offsets for few games:
https://github.com/hrydgard/ppsspp/blob/master/Core/CwCheat.cpp#L227
I'm against such solutions through, they're confusing, and since executable is most of the time loaded same way even if it later allocates memory differently, such offsets while fixing some of the cheats, break also all asm cheats. Currently existing offset isn't even doing anything except breaking the addresses as they changed at least a few times by various fixes. Maintaining such list takes as much effort as porting cheats from psp to ppsspp anyway, which those of us who can and have the game do for others already.

[AizerMortenort]

There is no difference in the addresses here especially the one tested by Melkor.
I have personally tested all the codes on real PSP with Code Locking Interval increased to 45000 micro seconds to see the same bad results the PPSSPP Cheats engine does, while setting code locking interval to lower will fix this issue. Do you guys want me to make a video demonstration on real PSP how the locking interval can brake a game or make codes work?!
I think it's pointless here to dispute. Take an example of NitePr , Free Cheat ... they all have the Cheat HZ or Code Locking Interval function as an option. It's an important one and it should be added to the emulator.

[sum2012]

@LunaMoo Yes, @unknownbrackets have already prepared to remove offsets hack
unknownbrackets@14e8114

[LunaMoo]

@AizerMortenort Noone was against that particular option. I saw some Melkor codes and he's pretty famous as he belives, but as for me, I would say he's famous for overcomplicating his cheats which ultimately are not doing anything complex, so really no need for proof that his cheats doesn't work with our refresh rate, I can imagine that:].

I just hope default setting will stay as it is now, since there might be an actual problem with assembly cheats refreshing too fast when JIT is activated. Currently the issue happens only to very long asm cheats like hp display hack for MH and it's pretty easily avoided by modifying the cheat, which I always do myself, but not everyone might even know about it.

@sum2012 yeah I saw that, but even without that module branch the offset is already wrong, I have only EU version of GEB myself which is not affected by offset, but saw recently this ~ http://forums.ppsspp.org/showthread.php?tid=3590&pid=101411#pid101411 which shows how usefull those offsets are right now:].

[AizerMortenort]

Whatever the case "Code Locking" interval will be a good option. People can choose to use it or let it run on default "current" one. After all it won't do anything bad but will be a plus to the program won't you agree with that. :)

[LunaMoo]

I don't have to agree;p, but for the third time, I'm not against it. There's still lots of space in the cheat menu for extra stuff so feel free to implement it.

Edit: @AizerMortenort ~ you can test the feature now if you want, seems to work on a test cheat, althrough I only compared 1ms vs 1000ms, wouldn't really notice a difference between something like 1 and default 77.

Wonder if I should also remove that GEB offset now:P, it's incorrect anyway.

[LunaMoo]

A bit of more info about that JIT issue when closing cheat menu which Melkor has, I did not understood him at all as he was saying no cheat was activated, while it was as he show the problem in https://www.youtube.com/watch?v=NsCPvvR400Q
edit: pasted wrong yt link sorry / corrected now
He also sent me his ini file to check and basically he was changing some lui opcodes like for example: lui v0,0x3F80 by cheats which write just 16 bit value ~ 3F80.

The problem seems to be that with JIT opcodes are replaced and, if the cheat sets just a part of an opcode this leads to invalid opcode and usually results in hang or other errors.
For example a cheat like:
_L 0x10022880 0x00003F80
will likely crash the game, however we can easily fix it, by just writing whole opcode:
_L 0x20022880 0x3C023F80
I don't know if this can be fixed on the ppsspp side, however as shown above very simple solution is to write all opcodes fully when making cheats like that. Imo it's also good practice how cheats which changes any opcodes should be made, unfortunately not everyone does it that way, especially when someone doesn't have full idea of what he's changing.

[AizerMortenort]

The real problem comes after the Cheat Menu is opened and the closed. As I see the code does work before - it has already been active and working before opening the menu, the it suddenly crashes the game after closing it.

[hrydgard]

@LunaMoo , if that's the case we have a bug in our cheat engine, as it should definitely work to change parts of opcodes. Or actually, now that I think about it, if the JIT overwrote the opcode with its own dispatch opcode, then yeah, it won't work :( We could avoid this however by having the cheat engine ask the JIT whether it has modified the location first...

[AizerMortenort]

@hrydgard it should, but from what I see after a dump made before the crash , the engine changes the first 2 digits of the op code value - 3C02 is what they should be always as changing them causes crash so code should be 3C02XXXX but it gets something like 3C0BXXXX or like. What I don't understand is as I said the code itself works and doesn't crash the game, but opening closing the menu causes it to be changed? and game to freeze.

The solution as these codes are used as KEYs to activate/deactivate is actually to use empty 0000000 space in the memory of the game. Usually that memory is with bigger addresses like 01600000 - 01800000 where most of the memory should be empty with 00000000 values which can be used for mips etc.

But as said there is some issue with the Cheat Engine here and opening closing the menu shouldn't actually causes changes in OP codes values.

[LunaMoo]

@AizerMortenort no, cheat menu has nothing to do with it. It might look like that because closing it clears JIT to activate the assembly cheats. I fixed the cheat which was causing problems for Melkor by editing it to write full opcodes without using any joker codes. I also saw exactly how it breaks the game, so it's pretty much as I described this issue without any doubts. If you don't belive words, you should belive in a picture:P

[AizerMortenort]

@LunaMoo I didn't said you don't tell the truth i didn't expect that OP codes cause trouble with JIT when written 16 bit. My question is why the game freezes once the cheat menu is closed and why it doesn't freeze with the code on before entering menu.

Maybe we should change the rules here so OP codes should always be 32 bit written to avoid crashes.
Anyway for the emu to bypass or correct things like that itself?

[hrydgard]

No, we should fix the cheat engine so it tells the JIT when it overwrites stuff, then there wouldn't be an issue.

[AizerMortenort]

@hrydgard So any progress? Can this be fixed?

[unknownbrackets]

That was fixed in 2f6216d, right? There's already a cycle count that resets the values in the same way as apparently is done in the PSP plugin's cwcheat.

Is there anything else this needs to be kept open for?

-[Unknown]