Cheat Engine

[holaboludo]

Grettings!

I've been trying to figure what's the issue with my script, what it does is to enable a simple "free camera mode". When enabled and disabled for the first time it will work normally, but problems arise when is enabled and disabled the third or fourth time. Both the CE and target application freeze and I have to kill both programs via the Task Manager because they become unresponsive.

Here's the code (it was stripped down since I believe the issue is very likely caused by the injection itself):

[ParkourPenguin]

You aren't using the syntaxcheck variable (like most other people... )

Maybe it's the aobscan. Maybe it's whatever you omitted in place of the "do stuff" comment. Maybe there's a deadlock happening from your weird code.

Using the auto assembler recursively is almost always a bad idea (I don't even know if it's designed to be reentrant). That luacall just makes it even worse.

I wouldn't call autoAssemble at all and would instead do everything in Lua. Particularly limit the aobscan to only scan through executable regions.

[holaboludo]

Thanks for the reply ParkourPenguin. The assembly part of CE is very difficult for me to understand and use but I'm gonna try to look up about it later.

I tried removing the luacall(playSound(findTableFile(''))) function and the issue seems to have been fixed now. EDIT: the problem still persists sadly.

Apologies for not sharing the full code before, it's pretty long. I apologize for the messiness of it, hopefully is readable enough.

Basically what it does is to run an AoBscan injection to disable the camera's control. If the AoBscan injection is successful then it will pause the emulator and run multiple simple smaller non-injection AoBscan searches to print the camera's coordinates, disable the HUD graphics, set the camera's control hotkeys and apply a small fix caused by disabling the camera's code then resume the emulation. Many of these addresses require AoBscans since their addresses are not dynamic and change every gameplay.

[ParkourPenguin]

• Again, syntaxcheck
  
• Again, I wouldn't use autoAssemble like that
  
• pause / unpause don't take parameters
  
• What is setGlobalKeyPollInterval doing there?
  
• You sometimes use literal addresses. This is bad. If it's in the main exe, use game.exe+offset. e.g. `writeBytes('game.exe+1234', 5)`
  
• Use local variables
  
• Doing an aobscan for writable data is bad
  
• I've had problems passing nil for certain parameters in memscan.firstScan sometimes
  
• For simple cases like this you should probably be using AOBScan instead of memscans
  
• Checking if the foundlist is nil does nothing. (you call initialize before that, so clearly it isn't nil)
  
• If the foundlist ever was nil, you'd double free the memscan (memscan.destroy called twice). This would be very bad if CE wasn't smart enough to catch this
  
• You access the first result of the foundlist without checking if it found anything first (fl.Count > 0). Also, it's not a bad idea to check if it found more than one and abort if so.
  
• `for i = 1, 1 do...` is a weird way of setting i to 1- especially since you don't even use i
  
• You're creating a bunch of memory records every time you enable the script. Create them once and access them.
  
• memoryrecord.setAddress takes a string. You're lucky CE has a special case that converts numbers to hexadecimal strings in this function
  
• Do you really have to pause / unpause the process?

CE logs some information using OutputDebugString. Maybe use DebugView (windows sysinternals) to get some idea of where CE freezes up

[Dark Byte]

Is the memoryrecord set to run asynchronous? If so, AddressList access is not thread safe

[holaboludo]