Online PokeSav

[evandixon]

Is there a way to create an on-line version of PokeSave? I realised that many people on these forums have Mac or Linux as their OS, and I didn't see any special downloads for those OS's. So, I had an Idea, for an online *.pkm file editor, but I was too lazy to try to figure out the specs for the 136 byte files (surely it needs more space than that.), then I got an idea for an online version of PokeSav/PokeMod. I would offer to help make it (if I had the specs for the save structure), but I do not know PHP, only ASP.Net, and I also figured that since Pokemon is this site's specialty, that it would host the online version.

Is this practical?

[SCV]

Is there a way to create an on-line version of PokeSave? I realised that many people on these forums have Mac or Linux as their OS, and I didn't see any special downloads for those OS's. So, I had an Idea, for an online *.pkm file editor, but I was too lazy to try to figure out the specs for the 136 byte files (surely it needs more space than that.), then I got an idea for an online version of PokeSav/PokeMod. I would offer to help make it (if I had the specs for the save structure), but I do not know PHP, only ASP.Net, and I also figured that since Pokemon is this site's specialty, that it would host the online version.

Is this practical?

We are already working on a cross platform sav editor. An online sav editor would probably use too many resources. There is no Mac or Linux downloads because we had not gotten around to making something that was cross platform and we are not the people who made pokesav. People need to get over pokesav.

[evandixon]

I don't see what resources it would take up, other than people's uploaded save files. Just allow one save file per user.

[coolbho3000]

I don't see what resources it would take up, other than people's uploaded save files. Just allow one save file per user.

I suppose a client side one would not use many resources on our part. A server side save editor would stress the server too much, especially if there's a lot of people using it at once. However, as SCV said, the research team is already working on a cross-platform Pokesav replacement (to come before Pokemod, which seems to become more long term now because of its awesome goals :grog:).

[SCV]

I don't see what resources it would take up, other than people's uploaded save files. Just allow one save file per user.

Everytime a person wants to edit a save file, they have to upload it, if the same number of people that use pokesav use it, that amounts to alot. Then there is the matter of using processing power to handle all those files and editing them.

[evandixon]

Oh. By resources, you meant memory and bandwidth.

[codemonkey85]

I was too lazy to try to figure out the specs for the 136 byte files... I would offer to help make it (if I had the specs for the save structure)...

*COUGH AHEM*

There was, as I recall, someone from GBATemp (MarkusE I think?) who wanted to make a PHP Pokesav replacement. I do not believe it went anywhere, but you could always try to track him down. In any case, if you would really like to help out with a DS save editor, you could always stop by the save structure help thread (linked in my signature) and help data mine.

As for actual programming, I am working on something you will no doubt be interested in, when it's ready to be released to the public at large.

[Guest]

Why not just make an Online Pokésav that only supports ARDS output?

That way, you won't get billions of save files uploaded to the server, and people will be able to use it still.

As for Mystery Gift, when we click Load PCD or Load PGT, we would just upload the PCD and PGT files hosted on the website. Same for .pkm files.

Anyone that can use Pokésav to edit their save files can also use ARDS codes, either by using their flashcart's built-in AR, or by using NO$GBA to input the codes.

[evandixon]

I can consider that if I ever touch my upload bin again.

[Chase-san]

Not very feasible, aside from bandwidth concerns programming something like this in say... php, would near impossible due to the exact bit manipulation that has to be done. Which last I checked PHP had limited support for.

[evandixon]

Ah-ha!

Something ASP.Net has over PHP!!!!

This IS possible in ASP.Net (with help from CodeMonkey85's code library), just impractical like you said about bandwidth, plus speed with X amount of hits at a time.

[Chase-san]

Well php also has weak typing which could cause conflicts as well. (A string can be used as an integer etc, without any kind of cast, making things dangerous).

Looking over the operator list, php does have bitshift and other bitwise operators. However there are bitshift concerns on some systems, because of the loose typing, cannot be left shift to be more then 32 bits (if so behavior is undefined).

As for ASP.Net, GTFO with that stuff. ASP has been superseded by PHP and not many places even support it. If your doing that, why not just use Tomcat or a streamed C++ application, which both are far better suited to this kind of task. >.>

[evandixon]

ASP has been superseded by PHP and not many places even support it.

And yet is more powerful. *resists flaming*

There are actually many places that support it.

Lets not turn this into a flame war.

[ceolceol]

Well php also has weak typing which could cause conflicts as well. (A string can be used as an integer etc, without any kind of cast, making things dangerous).

Looking over the operator list, php does have bitshift and other bitwise operators. However there are bitshift concerns on some systems, because of the loose typing, cannot be left shift to be more then 32 bits (if so behavior is undefined).

I know this thread is hella old, but I found it while searching to see if someone made an online equivalent of Pokesav, so I felt I had to reply to this bit.

PHP definitely has the tools to manipulate binary data (I'm doing it right now), it just doesn't have a convenient syntax for byte arrays. It's got pack, unpack, bitwise operators, etc. Weak typing wouldn't be an issue as long as you cast it as the appropriate type (which PHP supports).

If you limited the app to only handle pkm files, you wouldn't need to worry about shifting more than 32 bits— I'm pretty sure you only need to shift at most 16.