MantisBT - Cheat Engine
View Issue Details
0000240Cheat Enginepublic2013-04-20 19:512013-04-21 20:42
Reportermgr_inz_Player 
Assigned ToDark Byte 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000240: Lua file. "This is not a valid cheat table (buffer error)"
DescriptionIf we add checked.bmp and save table, we can not load this ct/cetrainer file later.

CE gives this error message:
"This is not a valid cheat table (buffer error)"

It happens with:
- original CE6.2
- CE from Nov2012, Jan2013 and from newest revision (r.1762)
TagsNo tags attached.
Attached Files? checked.bmp (1,078) 2013-04-20 19:51
http://cheatengine.org/mantis/file_download.php?file_id=78&type=bug
bmp

patch luafile.pas.patch (634) 2013-04-21 03:52
http://cheatengine.org/mantis/file_download.php?file_id=79&type=bug
patch fixLuaFile_V2.patch (3,252) 2013-04-21 16:27
http://cheatengine.org/mantis/file_download.php?file_id=80&type=bug
? luafile.pas (4,654) 2013-04-21 16:27
http://cheatengine.org/mantis/file_download.php?file_id=81&type=bug

Notes
(0000513)
mgr_inz_Player   
2013-04-20 20:00   
(Last edited: 2013-04-20 20:03)
Looks like Tcompressionstream or Tdecompressionstream problem.

Not related with Ascii85, because it happens when using original CE6.2 too.

(0000514)
mgr_inz_Player   
2013-04-21 03:53   
OK, I've made dirty patch. See at attached files...
(0000515)
mgr_inz_Player   
2013-04-21 16:27   
I attached patch version 2.

It patches:
- OpenSave.pas
I used existing variable, "version", and I pass it to createFromXML function. TLuafile.createFromXML(filenode, version);

- luafile.pas

saveToXML function now adds uncompressed stream size (WriteDWord):
m:=tmemorystream.create;
c:=Tcompressionstream.create(clmax, m, true);
c.WriteDWord(filedata.size);
c.write(filedata.Memory^, filedata.size);
c.free;

createFromXML function has two parameters now: filenode and version

if version >= 15 it reads compressed stream like this
size:=dc.ReadDWord();
freemem(b); getmem(b, size);
read:=dc.read(b^, size);
filedata.WriteBuffer(b^, read);

otherwise, it will use old method:

read:=dc.read(b^, maxsize); //reuse the b buffer
filedata.WriteBuffer(b^, read);


But if "buffer error" exception occurs, it retry again with 1 byte buffer
read:=dc.read(b^, 1);
filedata.WriteBuffer(b^, read);

and ignores "buffer error" exception. From my short research, filedata will contain right data anyway.

I will attach luafile.pas as well (for better readability).
(0000516)
Dark Byte   
2013-04-21 20:42   
Fixed in the svn. It's now part of the base85 update which has a complete overhaul anyhow.
Also, no real need to add support for previous versions. The "compatible" solution to load old tables that are broken because of this is to bug out the same way

Issue History
2013-04-20 19:51mgr_inz_PlayerNew Issue
2013-04-20 19:51mgr_inz_PlayerFile Added: checked.bmp
2013-04-20 20:00mgr_inz_PlayerNote Added: 0000513
2013-04-20 20:03mgr_inz_PlayerNote Edited: 0000513
2013-04-20 20:03mgr_inz_PlayerNote Edited: 0000513
2013-04-21 03:52mgr_inz_PlayerFile Added: luafile.pas.patch
2013-04-21 03:53mgr_inz_PlayerNote Added: 0000514
2013-04-21 16:27mgr_inz_PlayerNote Added: 0000515
2013-04-21 16:27mgr_inz_PlayerFile Added: fixLuaFile_V2.patch
2013-04-21 16:27mgr_inz_PlayerFile Added: luafile.pas
2013-04-21 20:42Dark ByteNote Added: 0000516
2013-04-21 20:42Dark ByteStatusnew => resolved
2013-04-21 20:42Dark ByteResolutionopen => fixed
2013-04-21 20:42Dark ByteAssigned To => Dark Byte