Gods Eater Burst Broken Savegames

[Daykod]

Getting a weird error when loading my saves created on my actual PSP and it won't actually load them. It just goes back to the main menu whenever I try to load a save that wasn't created in ppsspp. They definitely work on my PSP though. Took a screenshot of the log right as it went back into the main menu. It's a bit noisy because of the atrac spam.

[unknownbrackets]

By the way, if anyone wants to see the monster func and doesn't own the game, you can get the demo NPJH90167 (God Eater Burst demo - NOT the God Eater demo) and look at 08808BB4. It appears to be the same.

Should be this one: http://www.pspdemocenter.com/page.php?id=3419

The most dangerous things it does are probably mul.s and cvt.s.w.

-[Unknown]

[unknownbrackets]

Well, I logged every single mul.s, sub.s, cvt.s.w, and trunc.w.s instruction's operands, and ran the same 2 million instructions on a psp. I either screwed up bad (although I triple checked...) or all of them produced exactly the same results, to the bit, in ppsspp.

Pretty sure this is right, but I'm kinda not believing (IEEE or not) that all the multiplies were bit for bit identical:

void __attribute__((noinline)) test_muls(u32 v1, u32 v2) {
    u32 res = -1;
    asm volatile(
        "mtc1 %1, $f0\n"
        "mtc1 %2, $f1\n"
        "mul.s $f0, $f0, $f1\n"
        "mfc1 %0, $f0\n"
        : "=r"(res) : "r"(v1), "r"(v2) : "$f0", "$f1"
    );
    printf("mul.s %08x - %08x = %08x\n", v1, v2, res);
}

The only other "exotic" instruction is ins. But they are all this:

ins v0, zero, 23, 9

It doesn't work in interpreter either, so it's not some kind of flushing issue. I can only assume I did something wrong in testing those float operations...

Unless it's c.le/bc1tl (in interp also.) Maybe bc1tl is being decoded wrong or something?

-[Unknown]

[hrydgard]

All I can think of apart from that is some cpu flag that modifies the rounding mode (rounding of the last bit in a floating point operation can often be controlled) of the float calculations...

[unknownbrackets]

Hmm, now that I think about it, I think this was one of the few games that set a rounding mode to something. I guess it's possible this is the cause of both this issue and the Peace Walker one.

If yes, I think the solution would be to assert the rounding mode set by the thread before the first compiled fpu instruction, and reset it on exit if it was set. This should avoid any impact to C++ code / HLE thread switching, and minimize perf hit.

Interpreter might be more tricky...

Still need to test to see if this is even the cause.

Another thing I've been worrying about here - we may have to add an option (or do something) to allow people to load their old savedata. Could try to detect the hash fail and do something smart, but not sure it's worth it.

-[Unknown]

[unknownbrackets]

Okay, that works great, and that was indeed the problem (for mul.s.) Need to delete some debugging code, add an option, and handle in armjit still, but shouldn't be a big deal.

One way or another will get complaints about savedata not loading from Gods Eater Burst.

-[Unknown]

[hrydgard]

Cool! Glad to hear my intuition was right :)

Yeah, the savedata issue will be a problem. I presume this code only exists once in the game and is used for both saving and loading? In that case it will be hard to make any kind of hack like "old rounding mode when savegame old" as it will then also save out in the old "format". I guess we could add some crazy switch and zap the jit so the user can load, flip the switch, then save, but automating it will be tricky.

[unknownbrackets]

Well, if we detected it it would just be to show an osm, I think. It's possible to detect the hash failure using a replacement hook. Automating would be crazy, yeah.

-[Unknown]

[LunaMoo]

Wouldn't the cheat from above be enough to work around this backward compatibility issue?

If so, I can confirm it works in EU version(same address) and I made a similar cheat for GE2 a while ago. Just a bit of work for the users. :3

BTW nice work solving this ancient issue:).

[unknownbrackets]

Well, the cheat allows loading the corrupt broken savedata, but it doesn't make the savedata not corrupt (although saving after loading with the cheat will set the corruption in stone.) You may experience weird glitches anywhere in the game because of this corruption.

-[Unknown]

[LunaMoo]

Oh so it's actually broken, I thought it would simply not load because of incorrect hash.:3

Anyway great news, MGS was also affected, wonder how many other games were having problems because of this.:)

[super-ninja-tom]

@LunaMoo how are you managing to get that cheat to work on the EU version, please help!

I am using ULES01519 and have: 1.Fresh install: ppsspp-v0.9.9.1-65-gf8a4236-windows-x86 (tried with ppsspp-v0.9.9.1-65-gf8a4236-windows-amd64 too) 2.Contents of memstick\PSP\Cheats\ULES01519.ini: _C1 Enable PSP Gods Eater save _L 0x08888F54 0x1063028B beq v1, v0, pos_08889984

3. "Enable Cheats" in main PPSSPP settings
4. Open game, made sure that "Enable PSP Gods Eater save" is checked in the Cheats settings menu
5. Tried to load a save game from my PPSSPP and it drops back to the previous menu, a save created through PPSSPP still works.

Any tips would be greatly appreciated as you mention having got the EU version to work but I am still stuck :(

[hrydgard]

@ninjatjj forget the cheat for that purpose, it will soon no longer be needed.

[super-ninja-tom]

it will be great news when that happens!

[LunaMoo]

@ninjatjj basically 0x8800000 is 0 for the address in cw cheat and first number in the address is actually a code type not part of the address, you can google for cw cheat code types. So basically the first part of the cheat ~ after the title ~ should look like "_L 0x20088F54"(~ "2" in there is basically a code type meaning "32 bit write") and also don't put disassembly after the second code in the line it was more of a comment nothing required.

And yeah saves from psp will work without any cheats, tried already with both GEB/GE2, don't bother using the cheat, just wait a bit, I replied only to point your problems with making cheats.

[super-ninja-tom]

@LunaMoo many thanks! that works great for me - much appreciated. I took a quick look online to try to understand the "32 bit write" but I found the source of CwCheat.cpp helped me most: It looks like: https://github.com/hrydgard/ppsspp/blob/master/Core/CwCheat.cpp#L294 https://github.com/hrydgard/ppsspp/blob/master/Core/CwCheat.cpp#L284 https://github.com/hrydgard/ppsspp/blob/master/Core/CwCheat.cpp#L221 Explain why: 0x08888F54 works on the US version and we need 0x20088F54 on the UK version.

As suggested above, I will wait for the official version but at least I can see why its different now - thanks again!

[LunaMoo]

@ninjatjj it's same for both EU and US, it's just that CW Cheat address starts from 0x8800000 which is user memory. When you look at the address in disassembly or memory viewer it'll be 0x8888F54, but as cw cheat the address would be 0x0088F54(0x8888F54-0x8800000). Writing 32 bit value simply means that the value you write can be from 0x0 to 0xFFFFFFFF, It's like the most common and usefull code type in cw cheats althrough it has many others, including some which take more than 1 line of code.

[super-ninja-tom]

@LunaMoo Ah, that explains it then thanks!

I still don't really understand why the US version needs the following: https://github.com/hrydgard/ppsspp/blob/master/Core/CwCheat.cpp#L221 And the EU version works even though it isn't having that applied?

[LunaMoo]

Oh that, this is a pretty awful workaround added only because those games were loading differently on psp and ppsspp, so some cheats weren't working and people cried:]. I'm quite sure this workaround actually broke cheats which worked, because the issue wasn't really affecting whole memory while that "fix" does shift all addresses by same offset.:|

I think the initial issue should have been completely fixed by v0.9.9.1-38-g2de6b47, so that workaround probably should be removed as well, currently I assume all it does is breaking cheats for versions of the game it affects.

[super-ninja-tom]

@LunaMoo thanks for the context - much appreciated!

[unknownbrackets]

I've removed the hack in my modules branch, which makes memory allocation much closer. I can almost exactly match it by making sceNetInit() allocate some stuff, but there's still a couple things off by slight amounts within its self-managed allocation pools - possibly different timing.

-[Unknown]

[super-ninja-tom]

Awesome - really great work - thanks for fixing this one!

[fauxhind]

So the cheat is obsolete? I still can't get it to load up despite using the cheat code. Also installed the latest build which was stated that it fixed the save file error but it didn't do anything at all.

[unknownbrackets]

Using default settings and not using the cheat loads savedata for me.

If you're using the cheat (which kills the hash check), and your savedata still won't load, you've got a different problem. Maybe relating to DLC or something.

-[Unknown]

[fauxhind]

I have the DLC installed but the problem still persists. Blurry avatar and automatically puts me back to the main menu screen.

EDIT: May I ask as well, what build are you using?

[unknownbrackets]

v0.9.9.1-168-ge1d2e72 which I just sent a pull request for, but it doesn't change anything above v0.9.9.1-164-gcdbcc12 for Gods Eater Burst's savedata issue.

-[Unknown]

[tomjenkinson]

@fauxhind, which version of GEB are you using? I can confirm the EU version works without cheat and stock 0.9.9.1-92-gd4ec7d8 (I do have the EU DLC installed).

[fauxhind]

US version @tomjenkinson I have the files I need (that being the DLC) and I have the latest stable build but despite having what I need, it still sends me back to the main menu screen. Help would be appreciate because noone wants a 500hour save file going down the drain.

[unknownbrackets]

If you have a save file that you loaded with the cheat code enabled, and then saved, or a save file from created/saved/updated from an old ppsspp version, you'll need to go into System settings and turn off the GEB fix to load the old save. Once you've loaded it, turn it back on, and save.

However note that the cheat leads to savedata corruption. I think it will have been saved in your savedata now.

-[Unknown]

[fauxhind]

Oh I'm glad then because what happened is that my savefile was deleted instead of corrupted when using the cheats which I find weird. I would fire up GEB with the cheats, send me back to main menu, close the game and reopen it, it would say no save file was found. Luckily I have my savefile backed up. Regardless, I was able to fix the savefile issue by downloading the latest build from the automated builds.

[LunaMoo]

If you talk about the cheat from here, for US version it would actually need an offset for the address to counter that one added by a hack in our cw cheat implementation as discussed above;3. Basically the hack -0x7EF00, so all the cheats created on ppsspp have to include +0x7EF00 to an address, kind of stupid, so yeah it's better to just use ppsspp option to deal with it.

[MaxiM-PL]

Hey guys, Downloading v0.9.9.1-1245-g4b053ef helped me with not being able to load the game at all, but one issue still persist. I'm using the original PSN files to play between my PC and my Vita. So far so good, but I'm getting "Could not recognize the Special Character unlock key." error while loading the game: http://i.imgur.com/scUfTaq.jpg It does load however and after uploading the save game back to Vita the error is gone and I can continue (so far at least). Any ideas?

[Nailurridlo]

if anyone can summarize how to make the save data can be continued?

[unknownbrackets]

http://forums.ppsspp.org/showthread.php?tid=13848&pid=97431#pid97431

-[Unknown]