aluigi, posted Mon Mar 13, 2017 4:55 pm (21446)

---

Mah, honestly I don't know what to suggest you except that you should ever use just "comtype oodle".
I doubt that Horizon uses an oodle version higher than 2.4.1 but you can check it very easily in the oodle shared library of the game (if you can access it).
Anyway it's external code so there is nothing I can do.

AnonBaiter, posted Sat Mar 18, 2017 1:28 am (21587)

---

Excuse me, how are "lzo1x" and "lzo2a" highlighed as bold blue on notepad (by using quickbms language that was imported from the program) while "xmemdecompress" are highlighted as just plain blue?

Or maybe it's just me being an idiot.

aluigi, posted Sat Mar 18, 2017 9:26 am (21595)

---

Fixed.
It was an old version of the file dated 31 May 2015 that additionally didn't contain these important lzo*

AnonBaiter, posted Sat Mar 18, 2017 1:18 pm (21602)

---

Thanks for the fix.

Anyway, I know this thread is not about "games" but since this is also about compression issues I feel no other thread fits than this one.

So, I had to modify your assassins_creed2.bms script just to see if it works with the extracted files of Assassin's Creed. One file in particular from the Xbox 360 version of the game refuses to work.

Code:

  offset   filesize   filename
--------------------------------------
  00000000 714        Map_Menu_0

-------------------
*EXCEPTION HANDLER*
-------------------
An error or crash occurred:

*EH* ExceptionCode      80000001 guard page violation
*EH* ExceptionFlags     00000000
*EH* ExceptionAddress   00829c87
                        00400000   00429c87 quickbms.exe
*EH* NumberParameters   00000002
*EH*                    00000000
*EH*                    0b195001

Last script line before the error or that produced the error:
  63  clog MEMORY_FILE OFFSET ZSIZE SIZE

I had attached the file and the modified script in question.

assassins_creed2.rar

aluigi, posted Sat Mar 18, 2017 3:15 pm (21603)

---

I don't know.
The first file (0x00000019: 0x00000229 -> 0x000002ca) was correctly decompressed, no idea why there are problems with the chunks of the second one (0x0000047b: 0x00002d8a -> 0x00008000), everything is correct as far as I can see except for the data of the second file that (at a first look) doesn't seem xmem.

AnonBaiter, posted Sat Mar 18, 2017 4:07 pm (21606)

---

Yeah I thought so too.
However, in the decrypted binary executable of the Xbox 360 version of the game, I found three strings that indicate these compression algorithms:

Code:

LZX
LZO2A
LZO1X_999
LZO1X_1

One of them isn`t even supported on quickbms(lzo1x_999), while my guess is that lzo1x_1 might be the same as lzo1x.
These are just clues I`ve gotten anyway. Perhaps you might have better luck than me in figuring out the compression algorithm used on that file.

aluigi, posted Sat Mar 18, 2017 4:24 pm (21607)

---

LZX: it's xmemdecompress (Microsoft LZX)
LZO2A: lzo2a
LZO1X_999: it's the recompression algorithm of lzo1x, it's the same used by quickbms with comtype lzo1x_compress
LZO1X_1: lzo1x

AnonBaiter, posted Sat Mar 18, 2017 5:33 pm (21608)

---

Huh.

AnonBaiter, posted Sat Mar 18, 2017 9:09 pm (21612)

---

Here are more versions from the Xbox 360 version of Assassin`s Creed. Because I think that just one isn`t enough.

Savage, posted Tue Mar 28, 2017 7:29 pm (21812)

---

Today i got a message in Linux that xmemcompress is only supported in windows, is possible to fix it?

aluigi, posted Wed Mar 29, 2017 2:29 pm (21827)

---

Unfortunately I can't help with that because it's an API of the XboxSDK for Win32 that can't be used on Linux.
As far as I know there are no open source versions of xmemdecompress, in the past I already checked some "supposedly working" codes and they failed in misery, so you can save your time instead of searching

Savage, posted Wed Mar 29, 2017 9:19 pm (21840)

---

Oh..well thanks anyway , wine works great with the quickbms

chrrox, posted Thu Mar 30, 2017 9:04 am (21844)

---

I think umodel does not use it.
https://github.com/gildor2/UModel/blob/ ... ession.cpp

aluigi, posted Thu Mar 30, 2017 11:23 am (21846)

---

lzxd is already available in quickbms in the compression/unmspack.c but it uses the hardcoded window_bits 21 (lzxcab) and 16 (lzxchm), while apparently it needs 17 for xmem.
Added in my TODO the possibilty to specify arbitrary arguments to pass to the decompressor.

Nameless, posted Wed Apr 05, 2017 7:29 am (21978)

---

Thank you for implementing labels, but looks like I found bug. If labels used in the function then it causes script to loop endlessly. Here is example:

Code:

debug
callfunction INSIDE

startfunction INSIDE
set CHECK byte 0
print "000"
test:
if CHECK = 4
   continue end
endif
print "AAA"
continue test2
print "BBB"
label test2
print "CCC"
math CHECK   1
continue test
end:
endfunction

aluigi, posted Wed Apr 05, 2017 3:36 pm (21992)

---

I can only suggest you to replace continue with break and check if something changes but in any case everything worked correctly in my tests (that involved also functions) and there will be no updates for this (so called) feature in future.

Nameless, posted Wed Apr 05, 2017 5:55 pm (21997)

---

Break has the same effect.

AnonBaiter, posted Thu Apr 06, 2017 1:38 pm (22026)

---

aluigi wrote:

lzxd is already available in quickbms in the compression/unmspack.c but it uses the hardcoded window_bits 21 (lzxcab) and 16 (lzxchm), while apparently it needs 17 for xmem.
Added in my TODO the possibilty to specify arbitrary arguments to pass to the decompressor.

Does that mean the issue I`m having with the Xbox 360 version of Assassin`s Creed(by using my scimitar_compressed.bms script, no less) will be eventually "fixed"?

SkullKid2000, posted Fri Apr 07, 2017 11:45 am (22047)

---

I get a "rnc_packed_crc_error" when trying to use the robotwarsed.bms script with QuickBMS 0.8.0. 0.7.7 works just fine, though, so I'll stick with that until Luigi fixes this

aluigi, posted Sat Apr 08, 2017 7:42 am (22068)

---

Thanks for the report, I "touched" the rnc code just in 0.8.0 and apparently I forgot to disable the rnc check... oh well it happens

GenEric, posted Sat Apr 29, 2017 5:16 pm (22725)

---

Hey, just got a memory allocation error from the Zero Escape: The Nonary Games script. Let me know if you need any further details. Just looking to get the whole thing unpacked.

http://i.imgur.com/vAxdDvO.png

The assets unpacked so far have been hugely helpful, so thanks for this.

aluigi, posted Sat Apr 29, 2017 6:05 pm (22727)

---

Good catch, it seems just a bug in the new "tcc" feature (the runtime C compiler) of quickbms.
The game has tons of files and there is a certain amount of memory consumed and not freed at each cycle so you get the memory allocation error when the process has already allocated some Gb of memory.
I was ready to suggest to use -9 (that limits these types of memory leaks) but quickbms even crashes with it so it looks like a lame bug that I have to solve for the next version.

Unfortunately there are no temporary work-arounds to complete the extraction.

GenEric, posted Sat Apr 29, 2017 6:10 pm (22729)

---

No sweat, I don't mind waiting for next version. Thanks for your time on this issue. It's been a huge help!

Acewell, posted Tue May 09, 2017 6:51 am (23039)

---

i think i found a bug with the findloc command, my last entry is ignored
i will attach a sample and the script
*solved and removed*
i didn't see anything in quickbms.txt about there being a limit to how many
times you can use it or where you can/can't use it.

aluigi, posted Tue May 09, 2017 7:03 am (23041)

---

It's a conflict between the searched string and the name of the first variable.
Fix: replace the name of the first variable (RYHP) with NEXT_RYHP

Yeah I know it's boring but one of the rules of quickbms is that name of variables and constant strings (even the binary ones) are handled in the same way.
Even I forgot that and it required some tests before fixing it