evandixon

If you have a way of running homebrew on your 3DS (not with your R4), and if you have a copy of either PokéTransporter or Pokémon Dream Radar, then you should be able to use TWLSaveTool. http://smealum.github.io/3ds/

Try using TWLSaveTool with your 3DS, if you can. https://gbatemp.net/threads/release-twlsavetool-v1-0.412887/

If you can't use homebrew, Gateway, or CFW, a Sky 3DS won't help you. Getting access to homebrew (and by extension, Hans) shouldn't be too difficult. Look here for the possible ways of getting homebrew: http://smealum.github.io/3ds/

Simple hosting should be enough. A CDN would be much more expensive, so I'd only recommend it if your website makes enough money, and if you have enough traffic to justify paying for the use of multiple servers.

Looks about right.

Did you trim the first 0xFF0 bytes from the romfs? If so, don't. The latest version of hans doesn't require this, and doing so might break things.

I'm going to leave this here for any aspiring save researchers. Further discussion should occur in the Save R&D forum or via PM. I was able to decompress each save file using .Net's System.IO.Compression.DeflateStream. The trick is to only give the deflate stream the data after the two byte header, because the header is part of the zlib spec and not part of the deflate algorithm.

What save manager are you using?

Don't forget to delete the secure value when importing your save.

Are you deleting the first 0xFF0 bytes from the romfs? If so, make sure you have the latest version of hans (available in the homebrew starter kit on Smealum's site), and don't delete anything in the romfs. The latest version of hans doesn't require that, and I don't know if doing so will make it not work.

It won't work on a 3DS, because in DS mode, once a cartridge is removed, the system won't recognize anything any other inserted cart. If you get it working on a DS Lite, then it might work.

If you mean with TWLSaveTool, then it won't work because EoS isn't supported.

Try this: http://filetrip.net/nds-downloads/utilities/download-uniquegeeks-offline-save-file-type-converter-2-6-alpha-f26025.html Convert from a Raw save to a Raw save, setting the size to 128KB.

Test Line 1 Test Line 2 If this appears properly, then I used Android's Google Chrome. What browser are you using?

I wouldn't trust TWLSaveTool with EoS saves just yet. I just tried it on my copy of Eos, and it did the same thing, except worse, since it only gave me half of the save (64K, not 128K).

Both saves have an extra byte at the beginning for some reason. If you open your saves in HxD and remove it (and say yes to changing the file size), POKEDUN SORA.0.SAV works for me in DeSmuMe. Ideally, there will be 4 bytes before "POKE_DUN_SORA". I tried the same with POKEDUN SORA.1.SAV, but it didn't work, because the first hundred or so bytes are all 0. I suggest trying to redump that one, just in case the failure was a fluke. [Edit] I managed to fix the second one. I forgot that there's a backup save about 50K in. http://filetrip.net/dl?BCrlfH0Zyj

I'm experiencing this too, and I know a few others who experience it as well. I'm almost certain it's a server config issue, not dependent on any browser. Hopefully @Alpha can fix this soon. I didn't know this. Thanks for pointing it out.

When you download the .zip, use Right-Click -> Properties -> General -> Security -> Unblock before extracting it. In DeSmuMe, did you use File -> Import/Export Backup Memory? Usually when directly editing the .dsv file doesn't work, this does.

Have you tried pheonragon's solution (linked to in the post above yours)?

Mine doesn't count since right now I have to break and use Visual Studio's quick watch to actually see the contents

I've researched the same thing. I believe the original filename is hashed somehow, then the game uses that hash to find the appropriate file. In image_2d.bin, the game takes even takes it a step further. It takes a filename (like "BACKGROUND_SUB_GOLD01"), looks in image_2d_database.bin to find a corresponding filename (usually just lowercase, but can be anything), then hashes that to look for the file. I managed to redirect an image lookup that way. I tried comparing the hashing algorithm to that of SARC (scroll down to GetHashFromName()), but I don't think it's the same one. Maybe it's similar and being calculated slightly differently. I've identified some corresponding filenames and hashes (well, positively identified the first two and made reasonable guesses about the others): num - hash - filename 130 - 21691D3B - wallpaper_main_top01 689 - CA5EA838 - wallpaper_main_top02 141 - 259CCD06 - wallpaper_main_top03 680 - C740D87F - wallpaper_main_top04 147 - 2882BD41 - wallpaper_main_top05 It's interesting how different the hashes can be when there's only a 1 bit difference. For now, I've given up. I've started trying to map image filenames to their corresponding hash, but I don't think we'll ever have a complete list, even if we do figure out the hash. A lot of entries in image_2d_database point to "unused" (like BACKGROUND_SUB_GIFT01), so any file in the FARC that's not in the database we'll probably never know how to match. I would be interested to see your analysis of the message.bin FARC hashes to the actual filenames. This is something I considered doing myself. Knowing this would be especially useful, since it would allow me to make a string editor to complement my WIP script editor. Right now, there's more we don't know that what we do, so you probably can't go wrong with anything. However, here are some things that we'd like to know: -The placement data for scripts -The script flow data -Where starter moves/abilities are defined when changing the player or partner Pokemon in scripts. If changing the player/partner to a non-starter Pokemon, it will have the moves and ability of some other starter Pokemon. @psy_commando could tell you more about that. -Cafe rewards -Item data -Pretty much everything else

Based on MeroMero's research, that should unban all Pokemon. Side note: I got your PM, I just need time to write a good response.

In most cases, the Sky 3DS behaves exactly like a retail cartridge, so it should work.

I looked at the save file, and it has a zlib header, but using .Net's DeflateStream and DotNetZip, I was unable to inflate the save. Something about the block size not being right. It could be that there's some slight differences in PSMD's library, and the ones I used. Looking in the code.bin strings provided by psy_commando, it seems PSMD uses "Quazal ZLib Compression Plugin". Unfortunately, according to Bing and Google, that means nothing.