HPAndroid, posted Sun Apr 14, 2019 3:38 am (46905)

---

Sorry, but this is not my specialty.
Can you elaborate on this issue?
Thanks!

Code:

   if format = 99
      ofmt = 6
   endif
   if format = 100
      ofmt = 2
   endif

aluigi, posted Sun Apr 14, 2019 9:02 am (46910)

---

Code:

   if format = 99
      math ofmt = 6
   endif
   if format = 100
      math ofmt = 2
   endif

Scott Rash, posted Mon Apr 22, 2019 9:35 pm (47207)

---

So I am trying to unpack the pak file for Friday the 13th: The Game to see in umodel. But when trying to unpack the file, I get this:

Code:

- open input file C:\Users\Ben\Desktop\F13\SummerCamp-WindowsNoEditor.pak
- open script unreal_tournament_4.bms
- set output folder .

  offset           filesize   filename
--------------------------------------

- error in src\extra\xalloc.c line 703: xdbg_realloc()

Error: memory allocation problem
       Access is denied.

Shadow Walker, posted Wed Apr 24, 2019 6:30 am (47236)

---

Can someone explain what this error means?
Thanks


- GUI mode activated, remember that the tool works also from command-line
where are available various options like folder scanning, filters and so on

- select the BMS script to use
- select the input archives/files to extract, type * or "" for whole folder and subfolders
- select the output folder where extracting the files
- open input file C:\Users\user\Desktop\files\GEARASSETS_NOO_ScriptAssets.xxx
- open script C:\Users\user\Desktop\Injustice2_model\ue3_oodle.bms
- set output folder C:\Users\user\Desktop\files\end

offset filesize filename
--------------------------------------
00000000 104 GEARASSETS_NOO_ScriptAssets.unp
00001868 4294967207 GEARASSETS_NOO_ScriptAssets.unp

Error: impossible to write 0xffffffa7 bytes (total 0xffffffa7)
Check your disk space

Last script line before the error or that produced the error:
18 log name offset headsize

Press ENTER or close the window to quit

chrrox, posted Wed Apr 24, 2019 5:51 pm (47255)

---

Is your hard drive full?

Scott Rash, posted Wed Apr 24, 2019 9:13 pm (47260)

---

chrrox wrote:

Is your hard drive full?

No, it isn't. There is still a good amount of GB left in my C: Drive and D: Drive. Is there a certain amount of GB required to unpack the file?

z22901206, posted Thu Apr 25, 2019 3:27 pm (47291)

---

Code:

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

*EH* ExceptionCode      80000001 guard page violation
*EH* ExceptionFlags     00000000
*EH* ExceptionAddress   01078452
                        01050000   00028452 quickbms.exe
*EH* NumberParameters   00000002
*EH*                    00000000
*EH*                    106B1270

Last script line before the error or that produced the error:
  229 clog NAME OFFSET ZSIZE SIZE

SLZ.bms

483.PACK.zip

aluigi, posted Fri Apr 26, 2019 5:11 am (47305)

---

@Scott Rash
off-topic, there is the UE4 topic viewtopic.php?f=9&t=1005

@Shadow Walker
off-topic, since it's a game/script thing.
that error means that the size field is invalid 0xffffffa7, the script must be updated

@z22901206
probably off-topic but I will check

aluigi, posted Fri Apr 26, 2019 11:34 am (47314)

---

@z22901206
I'm still not sure if it's a bug of the algorithm or it's related to the invalid decompressed size field specified in the archive.
Anyway, I have added a check on the end of the input data in the algorithm and now it works, it will be available in quickbms 0.10.0

aluigi, posted Sun Apr 28, 2019 6:26 am (47378)

---

QuickBMS 0.10.0 is out

Shokoniraya, posted Sun Apr 28, 2019 10:19 am (47382)

---

reimport mode full support for multiple reversed math operators

operators are maximum?

and whats different between quickbms.exe and quickbms_4gb_files.exe? except bigger than 4 gigabyte or 64-bit files? can use quickbms_4gb_files.exe always? so whay there is two exe always? quickbms_4gb_files.exe wants more CPU or more memory ram? is this the reason? or anything else?

aluigi, posted Sun Apr 28, 2019 10:52 am (47385)

---

8 maximum operators.

The differences between the two executables are mainly:
- 4gb_files is suggested to be used on files bigger than 4gb
- 4gb_files is suggested to be used on files containing files bigger than 2Gb
- 4gb_files can read 64bit fields while quickbms.exe only 32bit fields (64bits are truncated, 0x1122334455667788 is read as 0x55667788)
- 4gb_files may not work correctly in some rare situations

My suggestion is to use ever quickbms.exe, while 4gb_files must be used only when requested by the script or by the author of the script

Shokoniraya, posted Sun Apr 28, 2019 3:35 pm (47400)

---

i always using 4g exe, i mean, is there any problem with that? (My suggestion is to use ever quickbms.exe: but why? i always usin that)
i just want to ask: im getting problem if i just using 4g exe always?

chrrox, posted Sun Apr 28, 2019 3:52 pm (47401)

---

I can't get the comtype ALZSS to work.
sample file

aluigi, posted Sun Apr 28, 2019 3:53 pm (47402)

---

If you have ever used quickbms_4gb_files it means it works very well

The problems happen only in some rare cases like the following script:

Code:

get VAR long # for example 0x88888888
if VAR     ...

For quickbms.exe VAR is That's why exist also signed_long which is valid with both.

I guess it may also have some problems with some dll with calldll but it's really very rare (I'm not even sure).

aluigi, posted Sun Apr 28, 2019 3:59 pm (47403)

---

@chrrox
Honestly I guess I didn't test the code, not even sure if I had samples.
The code is correctly called and this is the script but the output is 0 which means that it doesn't work as expected:

Code:

comtype alzss
idstring "ALLZ"
get FLAGS long
get SIZE long
get ZSIZE asize
clog "dump.dat" 0 ZSIZE SIZE

I didn't edit the original source code so it works exactly as expected

chrrox, posted Sun Apr 28, 2019 4:05 pm (47404)

---

It does work in his exe posted here.
https://github.com/Brolijah/Aqualead_LZSS/releases

Brolijah, posted Sun Apr 28, 2019 4:29 pm (47406)

---

chrrox wrote:

It does work in his exe

This is half right... The file decompresses right, from what I see in the memory viewer. However, the destination pointer goes past the expected EOF... I'm looking into why that is now. In the code I shared, I checked on return if the DST equaled the EOF, and if it's wrong then I assume that to be the result of an error.
Truth be told, the game I reversed the decompression routine from didn't have any return checks validating it decompressed properly. In that game, it just exited when finished. (So my "error checking" is potentially flawed because I had to wing it.)

EDIT: I'm tired and jumping the gun. I just saw chrrox shared a different file than what I was given a short bit ago. The 33 file shared in this thread does decompress correctly in my tool. The one I was given (38) is the one with the weird dst error I just described.

EDIT2:

aluigi wrote:

Honestly I guess I didn't test the code, not even sure if I had samples.

I gave like 15 sample files with the ALLZ code...

aluigi, posted Sun Apr 28, 2019 5:18 pm (47408)

---

Brolijah wrote:

aluigi wrote:

Honestly I guess I didn't test the code, not even sure if I had samples.

I gave like 15 sample files with the ALLZ code...

Ah ok, so I tested it for sure.

Sorry, it's just that I didn't remember it, which is positive since it means it was very simple to implement and I had no bad memories about it

aluigi, posted Sun Apr 28, 2019 5:27 pm (47409)

---

This is how the code is called from quickbms:

Code:

size = ALLZ_Decode(&out /*don't worry, doesn't get modified*/, in, zsize);

- out is the pre-allocated output buffer
- in is the input (from byte 0)
- zsize is the total size of file 33

It's all correct here.

aluigi, posted Sun Apr 28, 2019 5:33 pm (47410)

---

The current code on github has been updated since the one I implemented in quickbms and that may be the reason:

Code:

138c170
<                             *dst   = *encoded_src  ;
---
>                             *dst = *encoded_src;
271,272c303,306
<
<     return ((dst == decoded_eof) || (dst == (decoded_eof 1))) ? fullSize : 0;
---
>     // Eh, seems safe.
>     return ( ((encoded_src == encoded_eof) || ((encoded_src 1) == encoded_eof)) &&
>              ((        dst == decoded_eof) || ((        dst 1) == decoded_eof))
>            ) ? fullSize : 0;

Brolijah, posted Tue Apr 30, 2019 9:24 pm (47473)

---

Ahah... Apologizes for that. And apologizes in advanced again because I still need to fix one more thing with the decompression. I mentioned above a strange scenario where the dst jumps past the EOF, although the decompression was already completed. I'm waiting on a contact to finish testing the changes with a game which uses several ALLZ compressed files and inform me if it is 100% successful. I'm certain the solution will be one of two minor changes to the function.

Personally I'm a tad confused how I managed to finish the decompression "ahead" of the original assembly routines, but I won't complain if it works.

aluigi, posted Wed May 01, 2019 1:48 pm (47496)

---

Ok, keep us update when the new version is out

Brolijah, posted Wed May 01, 2019 7:24 pm (47516)

---

https://github.com/Brolijah/Aqualead_LZSS

Results are in, and I believe I've perfected it. The real fix turned out to be changing this:

Code:

while((dst   disp_length) <= decoded_eof)

... to this:

Code:

while((dst   disp_length) < decoded_eof)

I also have a few minor comments since I looked at how you implemented the functions. You don't need most the includes that I had for my tool. You don't even need "aqualead_types.h" since ALLZ_Decode doesn't contain the magic check. (In the games and my tool, that check is done outside the function before calling it.) The only includes that are actually needed for ALLZ_Decode are and for these lines right here:

Code:

if(!(*ptr_dst)) // stupid-proofing in case the caller didn't malloc a buffer
{
    *ptr_dst = malloc(fullSize);
    memset(*ptr_dst, 0, fullSize);
}

Other than that, and this one's just a tiny nitpick, I'd maybe suggest referring to the compression as ALLZSS for consistency with Aqualead's naming convention and so that others don't think its related with the LBALZSS formats that are also in quickbms. (Aqualead's names are always prefixed with AL, from their magic values to even their class names.)

aluigi, posted Wed May 01, 2019 8:03 pm (47517)

---

There is also that "if(encoded_src <= encoded_eof)" that should be fixed (not mandatory but better to do it).

Maybe at the end of the function you can just use:

Code:

return dst - ptr_dst;

That would make the function more "dynamic".