mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-25 06:06:03 +03:00
[GH-ISSUE #3988] Gods Eater Burst Broken Savegames #1623
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#1623
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Daykod on GitHub (Sep 29, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/3988
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.
@thedax commented on GitHub (Sep 29, 2013):
IIRC PPSSPP has never loaded saves for this game created by a real PSP. As for why, my money's on missing sceJPEG stuff, but I could be wrong.
@unknownbrackets commented on GitHub (Sep 29, 2013):
Hmm, it says "hash broken". It might've hashed the save with your PSP's nickname or the PSID.
Does the save in question work on any PSP, e.g. not just yours?
-[Unknown]
@thedax commented on GitHub (Sep 29, 2013):
@Suleks Could you upload the save to a site like mediafire? I'd like to test something.
@Daykod commented on GitHub (Sep 29, 2013):
I don't have another PSP on hand to test. It might be worth noting that the DLC didn't load when I copied it to the PPSSPP's memstick either. Something about a character mismatch. I dunno why it loads the saves made in ppsspp though. It's still writing a JPEG for the avatar because the avatar loads on the real PSP.
Here's a link to the saves if you'd wanna check them out.
https://dl.dropboxusercontent.com/u/38823080/SAVEDATA.zip
EDIT 1
Here's the last part of the log when loading a save game made in PPSSPP sort of successfully with the dlc
@unknownbrackets commented on GitHub (Sep 29, 2013):
You may have to copy the files from PSP/LICENSE (or whereever, I forget) to the PPSSPP memstick/ directory as well for the DLC.
-[Unknown]
@Daykod commented on GitHub (Sep 29, 2013):
Copying PSP/LICENSE didn't seem to do much.
@unknownbrackets commented on GitHub (Sep 29, 2013):
Dunno then, see #1916. Maybe there's DLC files you also need to copy.
-[Unknown]
@Daykod commented on GitHub (Sep 29, 2013):
I figured it might be related if there's some kind of DRM thing going on. Anyway I just double checked the savegames and the one created on PPSSPP actually doesn't have an avatar loading on my real PSP. So it might be the JPEG breaking it like @thedax mentioned.
@thedax commented on GitHub (Sep 29, 2013):
Does the save created by PPSSPP actually load and go in-game on your PSP? Also, if you then save the game on your PSP and re-load it in PPSSPP, does it kick you back to the main menu?
@Daykod commented on GitHub (Sep 29, 2013):
Yeah, the PPSSPP game save loads on the real PSP. Saving after loading it onto the PSP did seem to break it. Now it behaves like the real PSP savegames. The same error message about hash broken appears in the log
@thedax commented on GitHub (Sep 29, 2013):
I just did a test and yes, savedata are indeed transferable between real PSPs. Is it safe to say then that the game may be hashing the avatar image created by scejpeg?
@mr-chya commented on GitHub (Sep 29, 2013):
I just tested the save games available on gamefaqs which I assume were made with a real psp and they worked correctly so I am not sure that is it. However with that said one file I noticed that was present inside the gamefaqs saves and not present in any other is a file named C00.bin.
@Daykod commented on GitHub (Sep 30, 2013):
Well I can't explain this. They did actually load in ppsspp and they have avatars. What's even in these save files?
@Daykod commented on GitHub (Sep 30, 2013):
Still dunno what's up with this save file. I'm checking out the one with just C00.bin and it seems to be edited. Has stupid amount of money with top end gear without having any missions clear. Removing C00.bin causes the game on ppsspp to read it as corrupted but it "recovers" it and works fine afterwards. It doesn't rewrite C00.bin to the memstick. I tried it with my real PSP and ppsspp. I didn't see the bin get touched in the log though. As for the dlc, it seems it's generating a key and using it to find a file in PSP/LICENSE. It generated a couple and none of them matched the one I have for it. Wonder if the CFW i'm using on my real PSP is doing something with that.
@Daykod commented on GitHub (Oct 2, 2013):
Just to make sure nothing weird was going on, I loaded up the disc for GEB without CFW and didn't change any of the save files I already head. Created a new one to test it too. Still dunno whats up with those extra bin files.
@Daykod commented on GitHub (Oct 3, 2013):
What's up with sceJpegGetOutputInfo()? Using the debug bit of code to try and dump the jpeg always breaks at line 196, on fclose(wfp). Buffer overflow exception. Are the checks at the start of the function missing something? I'm trying to figure out what's going on in this save menu. Here's the call stack when you open the continue singleplayer menu.
Also I tried setting up JpcspTrace up with my real psp to see what's going on in this menu but the log doesn't catch anything from sceJpeg. Here's a link to the log : https://dl.dropboxusercontent.com/u/38823080/log.txt
@unknownbrackets commented on GitHub (Oct 3, 2013):
The God Eater games use some complex linking, it's not impossible JpcspTrace is missing it, unfortunately... or maybe it's some module that's already loaded doing the sceJpeg calls. Hmm.
For the debug code, it looks like you need to create a "Jpeg" directory (possibly inside Windows/) or it'll probably crash. Might check wfp != NULL.
-[Unknown]
@Daykod commented on GitHub (Oct 3, 2013):
Cool. Got it working and it looks like the jpeg isn't too far off of what it should be. Instead of putting it in a specific directory, I just changed sprint off to format "Jpeg%x.jpg" instead.
Here's a link to the image
https://dl.dropboxusercontent.com/u/38823080/Jpeg7369E829.jpg
@unknownbrackets commented on GitHub (Oct 3, 2013):
Oh, that's interesting. Is it meant to have a background? It almost seems like there's transparency that's being ignored, but that would be JPEG-2000 or something right? (I do not know much about that stuff at all.)
-[Unknown]
@Daykod commented on GitHub (Oct 3, 2013):
https://dl.dropboxusercontent.com/u/38823080/pspscreenshot.png
Here's what it should look like so there's some kind of transparency somewhere. PPSSPP just draws a black silhouette.
@CPkmn commented on GitHub (Oct 3, 2013):
@unknownbrackets
Transparency isn't ignored - nothing is actually being decoded because the functions it uses aren't really implemented fully and (I guess) there's a silhouette, and the decoded avatar is drawn over that (but since nothing is decoded, nothing is drawn over it I think).
In order to actually decode the avatar, the following functions have to be correctly implemented :
sceJpegDecodeMJpegYCbCr()
sceJpegMJpegCsc()
@Daykod commented on GitHub (Oct 3, 2013):
The silhouette would changed based on the save game though from what I could tell, and I think PPSSPP gets that part right. I'l have to check it again later.
@thedax commented on GitHub (Oct 5, 2013):
Another thought just occurred to me: @Suleks: What firmware was your PSP on when you created the save, if you can remember? If it doesn't match the firmware the game wanted(say 5.00 or 5.50 for example, and the game wanted 6.xx) that tends to create "corrupted" saves, which might be throwing off PPSSPP. Or was it if you upgraded to a newer firmware after creating the save on the "wrong" one? Hm..either way I seem to remember improper firmware versions causing trouble.
@Daykod commented on GitHub (Oct 5, 2013):
I use the PSP 3000 model so I was probably using CFW 6.60 when I made it. I created a test save without CFW with the disc though and it had the same issues IIRC. That one was created with the latest firmware.
@Daykod commented on GitHub (Oct 5, 2013):
https://dl.dropboxusercontent.com/u/38823080/SAVEDATA2.7z here's the zip I posted in the other thread. The second file is the one I'm sure I created on a real PSP since it has avatar data at all and it loads ingame after the MJPEG implementation commit.
https://dl.dropboxusercontent.com/u/38823080/SAVEDATA%20-%20TEST.7z is a new set of save files I just tested with that commit. Both real PSP save games still give the hash broken message. Gave them appropriate names this time round so they're easy to identify.
@thedax commented on GitHub (Oct 6, 2013):
I tested savedata-2.7z and the second save slot with 10 hours goes in-game without the mjpeg commit, so I don't think it's working because of that. The third save slot with 5 hours doesn't go in-game with or without the commit(broken hash).
I got the same results as you with SAVEDATA-TEST.7z.
@Daykod commented on GitHub (Nov 16, 2013):
Thought I'd add that God Eater 2 still has this issue. It can't load real PSP save games. There aren't any MJPEGs used in the loading screen. Same error code though.
@Daykod commented on GitHub (Nov 26, 2013):
So I had a dumb realization about that real PSP save game that loaded in PPSSPP. It was run through SED because I was manipulation the version of the save so that it could be imported in JP GEB. So despite being able to be transferred to different PSPs, PPSSPP can't decrypt it? I'm not too familiar with the DRM that PSPs use I just tested this with my GE2 save that I used SED on.
@kurasa25 commented on GitHub (Dec 2, 2013):
same problem here... except my save works perfectly on my psp. only on ppsspp the avatar is kinda buggy and it sends me back to the title screen as soon as i try to load the save.
@Daykod commented on GitHub (Dec 2, 2013):
I still have no idea what's the problem. I'm guessing namco bandai implemented their own encryption somehow. That or PPSSPP doesn't decrypt saves like I think it does. If a missing key is the issue, I can pull out GEB and GE2's key using SED. I should have them laying around. Otherwise I have no idea what that broken hash means. It can't be JPEG because GE2 doesn't even use any JPEGs in it's loading menu.
@erratic187 commented on GitHub (Dec 16, 2013):
Hi...im also experiencing this issue however, it's on just 1 save file. I have 2 PSP save files w/c i then transfer to PPSSPP, when i load one, it just goes back to the previous menu, when i load the other, it gives me the 'special char unlock key' message but then loads up the save just fine. if anyone wants to check the files just msg me...
@unknownbrackets commented on GitHub (Feb 15, 2014):
There have been some improvements to savedata loading and etc. Has this improved at all?
-[Unknown]
@Daykod commented on GitHub (Feb 15, 2014):
Haven't messed with it in a while. I'l try it after my internet is fixed from these storms.
@thedax commented on GitHub (Feb 15, 2014):
I tested again with Sulek's broken save(s) and it still kicks you back to the main menu, so no.
@super-ninja-tom commented on GitHub (Apr 7, 2014):
Same issue here
@unknownbrackets commented on GitHub (Jul 7, 2014):
Are there any tools to hack this savedata? For example, could we compare the raw data from a psp and from ppsspp and see what's different, if anything?
-[Unknown]
@unknownbrackets commented on GitHub (Jul 7, 2014):
For now, 08888F54 is where it seems to decide whether the savedata is good or not in Gods Eater Burst.
08888F54 1043028B beq v1, v0, pos_08889984
As a workaround, you can force it to load savedata using:
08888F54 1063028B beq v1, v0, pos_08889984
This could theoretically be done as a cheat and work on the PSP as well to allow PPSSPP savedata to load. It seems like 088494C0 is the function that makes the decision but I'm not sure yet.
-[Unknown]
@super-ninja-tom commented on GitHub (Jul 7, 2014):
Hi @unknownbrackets, can you elaborate on the workaround? Can you show me a diff that I can put on my master please?
@unknownbrackets commented on GitHub (Jul 7, 2014):
The workaround is a modification to the game, not to ppsspp.
-[Unknown]
@super-ninja-tom commented on GitHub (Jul 7, 2014):
Ah, thanks for that. I will have to see what I can find on the internet about modding PSP isos. On my PSP though its on OFW so I guess the reciprocal would not be possible for me but its the PC I want to play it on so worth me having a look.
@hrydgard commented on GitHub (Jul 7, 2014):
Well, @unknownbrackets gave enough info there to easily create a CwCheat code. Leaving it as an exercise to the reader...
@super-ninja-tom commented on GitHub (Jul 7, 2014):
Ah, OK that helps. Will have a go at that then :)
@unknownbrackets commented on GitHub (Jul 7, 2014):
The hash is just barely off. Makes me think we are wrong just by a byte or something, but I'm not sure where...
It's a simple sum of the bytes from the savedata (after psp decrypt + rolling xor + byte lookup table translation) afaict. With my savedata, the checksum is 0x200 higher than it ought to be.
-[Unknown]
@super-ninja-tom commented on GitHub (Jul 7, 2014):
:( the cheat doesn't seem to work for me on ULES01519
I tried:
{quote}
_C1 Enable PSP Gods Eater save
_L 0x08888F54 0x1063028B beq v1, v0, pos_08889984
{quote}
I was using http://forums.ppsspp.org/showthread.php?tid=3590 so it may be out of date. It does appear in the UI and appears selected so it may be different for different region versions?
@unknownbrackets commented on GitHub (Jul 7, 2014):
It's probably in a different place for the European one, I only have the US one.
-[Unknown]
@super-ninja-tom commented on GitHub (Jul 7, 2014):
Sure, to find the locations do I have to step through it in the debugger with a good save and bad save? Is there a variable location that shows where the interpretter is and a couple of good breakpoint locations in the source? Thanks!
@unknownbrackets commented on GitHub (Jul 7, 2014):
What I did was first look at where the savedata is loaded to (via the savedata struct.) Then I set a breakpoint on this memory address and found where it read it in. This is that xor/lut part. There it writes it out somewhere else, so that's the new breakpoint address to look at.
Ultimately, in that func it determines if the sum (t0) matches a hash (t7.) I have not yet figured out where it gets the reference hash (which may be what's wrong) or the lookup table (which maybe could also be wrong.)
Anyway, based on this it returns 1/0 iirc. The v1, v0 check is verifying this result. So you just want to nix it and make it always allow the savedata.
-[Unknown]
@unknownbrackets commented on GitHub (Jul 7, 2014):
There is floating point involved in the lut calculation. It's some kind of rolling lut.
The reference hash is at data + 0x10 (which it wipes to zero before calculating the hash.)
This implies something may be wrong with the lut, so maybe the savedata is actually invalid (somewhere.) It has my name, various text, etc. in it though and does not look wrong.... interp and jit both don't work.
Altering the savedata on load slightly (even one byte, even the last one since it's a rolling method) after psp decrypt totally corrupts it. So it seems like the savedata itself is decrypted right at least to the point of getting to the game.
It would actually help if anyone can check if their save is also 0x200 off (from their PSP.) I see some 0xFF 0xFF 0x01 0x01 in the savedata which would account perfectly if something was supposed to be zeroing them out.
-[Unknown]
@super-ninja-tom commented on GitHub (Jul 7, 2014):
Thanks, I will have a go at writing a CwCheat for the EU version then...
@unknownbrackets commented on GitHub (Aug 19, 2014):
So, I had initially made a mistake when checking this, and thought I'd eliminated the float lut stuff. I was wrong. The lut definitely seems to come up with incorrect data. So this could very well be floating point related.
In both saves I am testing, it's three bytes that are wrong. Probably coincidence, though.
The source data (as read from the file and decrypted by psp savedata) is correct, so at least that part is fine.
So this confirms that the cheat to make the savedata load could result in gameplay problems later.
-[Unknown]
@unknownbrackets commented on GitHub (Aug 19, 2014):
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 commented on GitHub (Aug 21, 2014):
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:
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 commented on GitHub (Aug 21, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
@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 commented on GitHub (Aug 22, 2014):
@ninjatjj forget the cheat for that purpose, it will soon no longer be needed.
@super-ninja-tom commented on GitHub (Aug 22, 2014):
it will be great news when that happens!
@LunaMoo commented on GitHub (Aug 22, 2014):
@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 commented on GitHub (Aug 22, 2014):
@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 commented on GitHub (Aug 22, 2014):
@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 commented on GitHub (Aug 22, 2014):
@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 commented on GitHub (Aug 22, 2014):
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 commented on GitHub (Aug 22, 2014):
@LunaMoo thanks for the context - much appreciated!
@unknownbrackets commented on GitHub (Aug 23, 2014):
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 commented on GitHub (Aug 23, 2014):
Awesome - really great work - thanks for fixing this one!
@fauxhind commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
@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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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 commented on GitHub (Aug 31, 2014):
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.
@WolfVantage commented on GitHub (Dec 20, 2014):
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 commented on GitHub (Dec 26, 2014):
if anyone can summarize how to make the save data can be continued?
@unknownbrackets commented on GitHub (Dec 26, 2014):
http://forums.ppsspp.org/showthread.php?tid=13848&pid=97431#pid97431
-[Unknown]