Nope, SFA2 doesn't boot at all with Joe & Mac's stock footer. I'll try every stock footer later. And yes, earlier I meant that it didn't even boot, sorry. I'm pretty sure we've never gotten SFA2 to boot at all with any of the patches, by the way. Only unpatched and with the SMK footer (glitched, of course).
Interesting. So the basis of that test was flawed from the get-go.
I'd appreciate testing the stock footers with SFA2. At least footers from 4-6 games of varying differences. We know SMK's boots, and J&M's doesn't. Starfox/Stunt Race FX (either. basically the same footer), yoshis, SMW, BoF(? maybe, since its a capcom game...). The SuperFX games, maybe do an additional try with a modified footer to remove the special chip. Like:
Code:
47 02 00 00 3E 12 74 06 70 02 55 02 00 00 3C 05 10 00 00 00 43 61 6E 31
Thats because I'm beginning to suspect the special chip byte will only support SuperFX, and will interfer with any other game and cause it to not boot.
I played around with the modified Super Tennis versions for a while but I really couldn't see any difference at all and I tried all the values you told me to. Maybe that really is for online latency like you suspected?
The netplay guesses are purely guesses. Netplay is a new feature over the previous VCs and SNESC, so it makes sense to store data for it along side other data if needed.
But yea. I wouldn't really expect much of a difference I guess. It was probably set to 07 just because of a communication error among devs. "Set it to 6 or over", some time later "did he say over 6? or 6 or over? ill just set it to 7 to play it safe...".
Maybe there's something in each game's sig file related to this? Remember that each game has a unique sig file and that we're just adding any randomly any of the stock files because the bypass method we're using still requires something to be there even if it doesn't read them. Maybe there's more to these sig files and they also authenticate the footer in some way and that's why we haven't been very successful modifying footers? Maybe if the sig files were better understood we could find a different way to bypass security that still read them. Or maybe this doesn't make any sense at all to someone who knows better than me xD
Well, at the very least they tried to make it a lot harder to hack than the NES Online app, that was just a mapper of throwing in a rom and covers with the correct names, editing the lclassics file and it would work well as long as it didn't have a mapper that wasn't used in one of the official games (which ironically means that the SNES Online app has a better compatibility since pretty much every NES game and their uncle used a mapper). Even the Famicom Disk System games worked on the Western version.
I haven't messed with the sig file at all. I'm not an encryption guy, and I assume that's encrypted data. It may very well be that sig files validate certain preset ids/footers, even if a footer is used on more that one game. Kind of a dumb loophole, but certainly possible.
I've suspected the titledb interfers with things too, or at least may need more looking into. I think the volume and playcount entrys in the titlesdb either override the corosponding values from the footer, or just rendered them obsolete during development and they forgot/didnt bother to remove those footer params.
Further, I think that maybe the SDA graphics data might need a entry in the titlesdb. On the original Wii it was it's own file. JDCE.sda. Id be takign wild guesses at the JSON entry for supplying a path to that though, so I hope thats not the case.
...
We've tried a lot, with confusing results. I don't have many ideas to test atm. So I've been going back over previous posts and tests to kind of organize things so that a new test I didn't cover stands out. But I suppose the J&M footer not booting SFA2 at all kind of explains some of it. But really, if the SMK footer will boot it, just not if I supply SDA data, param 44 and header3, I doubt any other footer will either with modification.
Looking at my notes, its interesting that we did try the SMK footer with SDA data, but no modification to the footer. It didn't boot simply by adding adding the SDA data to the file... we never got to a test of modifying the footer to add in param 44. I'll focus my thought on that for now. Try to figure out how adding the SDA data in any form renders the sfrom unbootable... Like, what could it be expecting other than a titlesdb entry for the .sda? Hmm...
EDIT:
Test#9
Test#10
I tossed some rational around for either working, but in the end... this should just be tested. It's the SMK footer with param 44 added. #9 is footer in the mid, like it would be on WiiU/SNESC. #10 is footer at the end.
Theory for one of these working while the Tests 4 and 5 did not is, those did not include param 44, and with SDA data provided the emu has a hard time calculating the size of the game ROM. When param 44 is provided, it used its location to help calculate the rom size. Well, that at least applies to #10. #9 is a "meh. might as well have this tested too".