Open mrhappyasthma opened 3 years ago
This is a known problem with the SWSH bridge that needs a redesign of the bridge itself on both Checkpoint and PKSM's sides. The essential issue is that save sizes change between updates, which our current bridge system was never designed for. Thank you for the report, but yeah, already known
Is it as simple as adding some kind of header data on the TCP connection specifying the incoming file size? Or is there significant amounts of work that needs to be done in addition to the size change?
(If it's not anything too unreasonable, I could take a stab at it. But I haven't touched these projects before so I'm coming in blind.)
That would be the general idea, yeah; I'd also want the port to change in order to prevent improper format misreading, and probably a bit of versioning info. If you'd like to take a shot, be my guest; I hate networking code with a burning passion so it would be very appreciated
Just updating the save file size 'works'. Although all of the sprites for the SWSH pokemon show as an egg. (Assuming this worked before, perhaps its some issue with data offsets?)
But yeah, I can try to take a stab at rewriting/improving some of the networking logic for this.
So, updating the save file size "works", yes, but a major problem with that is that there are several valid SWSH save file sizes, based off of the order/amount of updates taken. As for sprites, that's normal; we don't have properly sized G8 sprites so I haven't built a sheet that includes any yet.
Ah okay. Well if sprites are an external issue, looks like we just need to update the t3x
file.
Adding support for versioning and sending/receiving files (with dynamic size) is definitely something I can look into it.
Yeah, sprites are just mostly a "I don't do graphic design well, so trying to shrink the sprites and not have them look like ass is a bad thing to assign to me" thing. Same main thing a PKSM Switch version is stuck on, really.
I can't help much with the assets, but i can take a look at the current TCP communication and try to whip up a reasonable protocol to make it a bit more robust to change and compliant with dynamic file sizes
Yep, and thank you for that; was just explaining why it wasn't quite as simple as just updating the spritesheets
So I was thinking something like this. Let me know if anyone has suggestions or concerns.
I tried to keep it fairly basic, while still allowing for some flexibility to add more error codes or upgrading protocol versions in the future.
One other thing that I wasn't sure of: the protocol is fairly self-contained. Did we want to consider sharing this code somewhere that makes it easy to import? Then other projects that use this protocol (e.g. Checkpoint or even folks who wants to write custom tooling) could just include this directly without needing to re-defining all the structs and enums. I wasn't sure if there was any preference of file location for this to make it easier to share. (If we really wanted to go extreme, this could be in its own lightweight dependency. But even within the structure of PKSM, I wasn't entirely sure where to put it. I could just keep it in utils
but then it felt kind of undiscoverable.)
Let me know what folks think.
Discussed offline.
Summary:
_s
suffixBridgeErrorEnum
into the global namespaceconst constexpr
redundancypksmBridgeError_s
for v1 of protocol. Having a string field means we have to worry about translations. It's also not necessary with a single error case, so let's simplify.
Using the sword/shield bridge from the Switch Checkpoint transfers the data correctly. But trying to go to 'storage' after receiving the save is crashing.
Based on the change log, it looks like support up to v1.2 was added. Some work might need to be done after the latest updates.
Attached the Luma3DS crash log, in case it's helpful crash_dump.txt crash_dump_00000000.zip