https://www.reddit.com/r/emulation/comm … g_ds_wifi/

seems like desmume got famous

oh and if you wonder where the actual sabotaging was:

https://sourceforge.net/p/desmume/code/ … /winpcap.h
https://sourceforge.net/p/desmume/code/ … /winpcap.h

r3602 renamed one of the pcap imports to something that doesn't exist (pcap_sendpacket -> pcap_send), which wasn't mentioned at all in the commit message.

r3636 was me thinking that there were pcap versions that actually had pcap_send.

r3639 was zeromus confirming that pcap_send doesn't exist and that he was just silently trying to sabotage code.

heh.

does it still map the ARM9 BIOS to 0x0F000000 instead of 0xFFFF0000?

looks like you've been doing some good job, I thought desmume was more or less dead these times, guess I'm proven wrong

re: wifi

I understand your point, but the solution chosen is radical-- when you release an emulator, you'll always have to deal with hordes of noobs, and applying the same solution to the general problem would basically mean suppressing the emulator from the internet

sure, that'd get rid of the problem, but it's a bit of an easy solution

I'm not blaming you there though, I damn well know who's responsible for that

but that's not the whole reason why I lost motivation. It's mostly that from an emulation point of view, desmume reached a mostly-mature status, and therefore there isn't as much exciting work to do anymore imo

as for wifi, I kept trying but could never get local multiplayer working, it seems to require insane accuracy

and yeah, I'm doing well, I'm mostly into ROM hacking and emulation these days (you can check out my website for a little preview of what I'm into)

Maybe your driver can't support the format being requested.

That format may seem nonstandard, but actually it's the format used by the DS's microphone, and we're too lazy to implement resampling

UPDATE

WFC now works (albeit unstably) since r3533.

From #desmume:
[13:02] <Manivo> Holy crap.
[13:06] <Manivo> So seeing as we're slowly progressing towards flooding big N's servers with pirate connections
[13:08] <Manivo> Here's an idea I had the other day. How about limiting wifi access for savefiles on which cheatcodes have been used?
[13:08] <Luigi__> that may be done
[13:08] <Manivo> Big N's fury might be sooner summoned if they had a flood of cheaters on their servers, rather than a flood of illegitimate players.
[13:08] <Luigi__> http://forums.desmume.org/viewtopic.php?id=2543 <- that has been discussed here
[13:08] <Luigi__> it is already possible to cheat on WFC using an ARDS
[13:09] <Luigi__> the real problem may be LUA
[13:09] <Manivo> I know, the difference however is that on an actual DS one needs to actually buy something, which limits the numbers of people who actually do that.
[13:09] <Luigi__> but seeing as it is enabled by a preproc definition, blocking wifi communications on LUA enabled builds shouldn't be hard
[13:09] <Manivo> Seeing as both desmume and AR codes are free..

What do you think?

Also, MKDS seems to be suffering from a timing problem as the WFC race starts. The bottom screen map becomes unstable and the 3D framerate drops to 25. I thought zeromus, our professional in timing problems, could perhaps look into that...

I see. You mean if they use LUA scripts, or ARDS/whatever cheat codes while WFC-playing. Interesting point.
My answer: we should detect when the game tries to connect to the WFC servers (by looking for particular data in the packets being sent, I guess) and, when it's doing, block LUA/ARDS cheats.

And for what's hacking the WFC servers, I can't really find a purpose to it. Because I meant 'real' hacking, aka trying to get the servers down or to retrieve sensitive data from them (I don't think there's any in WFC though).
If it's hacking for cheating, well, interesting... depending on how much the user is cheating, it may or may not be noticeable by Nintendo. If it is, it is really bad for us. We should just block any cheats when WFC'ing. But this point may need more thinking and discussion.

But it is already possible to use an ARDS when WFC'ing, I think. And it hasn't been reported as crashing the WFC servers or whatever. So ARDS should be okay. The real problem is LUA.

The best way to know that is to record the packets being sent and look for the MAC address in them. There we have our answer.

Also, if you set DeSmuME to load a firmware dump, you'll be using the MAC address stored in your dump. But I agree, we should make DeSmuME generate different MAC addresses for each computer. Probably a MAC address like 00:09:BF:xx:xx:xx (where xx:xx:xx are the last three numbers of your computer's MAC address) would do it.

And about ClIRC. ATM, it works, but the connection is wonky. I'm looking for what could cause that. Maybe just your router having trouble acknowledging the presence of the DeSmuME "device". Mine had trouble too. But the connection is still wonky. I could connect to EFNet and talk on #dolphin-emu, but the connection timed out after a while.
The problem may be that SoftAP's current receiver can only read one packet every millisecond. There's high chance that packets are being missed.
I'm going to rewrite the receiving code so it can handle more packets per millisecond and also make it operate in nonblocking mode.

ACTION PLANNED:

We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.

Hoping everyone agrees with it.

So we suddently changed the save file format to proprietary?
I'm okay with this change ONLY if the conditions below are met:

1. If DeSmuME can load raw save files and convert them to its own format, just like NO$GBA
2. If the folder for save files is changeable, because otherwise it'll be a pain to manage the save files
because, when you run a game on another emu with a savefile created by desmume, the game will
most likely erase your save file.
3. If users can convert desmume saves to raw saves.