Support for RPA-4.0

[xtremeqg]

Ran into this particular archive version today. Header looks as follows:

RPA-4.0 0000000027d75111 00000042 Made with Ren'Py.MY_HEADER

Followed by 36 bytes which appear to be 9 32-bit integers with low values (1,45,417,2,462,417,0,0,0).

Looks like key = parts[1] and offset = parts[2] but offset is wrong (compressed data starts at offset 96, after those 9 integers).

Making it parse the header was easy enough but there seems to be some pickle-related issues.

First pickle.loads() complained about being unable to find module renpy. So I added sys.path.append(".") and all was good.

Then pickle.loads() complained about being unable to load module cPickle. Okay... I tried adding a blank module manually to sys.modules[] but no dice.

My python isn't that great... if someone could add support for this new version I would appreciate it.

[omegalink12]

Looks like a new custom RPA format. Can you provide the name of the game?

[omegalink12]

Also @Lattyware , maybe a custom issue template might be useful?

[Lattyware]

Looks like a new custom RPA format. Can you provide the name of the game?

Yeah, having an archive to work with makes it infinitely easier to add support. If you could give us an example archive of this version, that'd be great.

Also @Lattyware , maybe a custom issue template might be useful?

Agreed, #23 look good to you?

[madeddy]

RPA-4.0 is basically standard RPA-3.0. (short v3) Only change besides the id in the first 8 bytes is the shortened key from 42424242 to 00000042 and is no issue for the used v3 code.

UnRPA can simply use a alias and link to v3 if this identifier is encountered. Like its already done for RPA-3.2 if i remember correctly.

Btw. There are way more of this bogus Renpy archive variants out there. Mostly minor little changes like this one or added bytes like v3.2, file ext changed or v2 / v3 identifiers switched. If possible at all, one would need some functionality which automatic unravels such formats. I would not want to see the code for this...

Greets

[omegalink12]

We already have force detection switches which should handle the situations you're describing but they are not user friendly at all. The problem with assuming that the variants are all minor changes is that eventually someone encounters a situation like #15 .

But anyways, since you know about the new archive variant, can you provide some details on where it is used?

[madeddy]

I encountered the v4 in this one: NSFW! Patreon/Magic_fingers Not sure if thats the same as for the issue opener.

ps: If you're on it, please check the "current" implementation of RPA-3.2 you initial provided for UnRPA. I have no archive to test this, but i think it would fail. Dont want to open a issue and be wrong about it. (The code is now overly complicated imo.)

[omegalink12]

First, I'll give a NSFW warning for the link, But yeah, this is simply 3.0 with a tweaked header. Can be unpacked with unrpa -f RPA-3.0 archive.rpa -l

[madeddy]

Wanted to add a warning and forgot. Thanks. And yes, force v3 works also. (Tested)

[Lattyware]

Resolved as of #25.