search

mm201 / pkmn-classic-framework

Pokémon application logic for Generation IV and V, including servers
http://pkmnclassic.net/
Other
219 stars 43 forks source link

Moderation #70

Open mm201 opened 5 years ago

mm201 commented 5 years ago

Okay so wow. This is getting kind of big. We have lots of players and cheating sucks for them. One-off raw database edits to remove cheats just aren't feasible anymore and raw pkm structures were always hell to work with. It's time for a proper moderation system.

Unfortunately, this requires getting a lot of other things in place first:

InternalLoss commented 5 years ago

I know that the PID used isnt always the PID that Wiimmfi/Alt sees (since it can be the PID used from before Shutdown), but it might be a good idea to share that info with Wiimmfi since if you know the PIDs of cheaters you could give them a ban from Pokémon (I'm sure Wiimm would give you banning permissions on Wiimmfi for Pokémon Gen4+5) if they keep being unruly.

hfc2x commented 5 years ago

Just for keeping this into consideration, as I commented in #69, Pokémon which have been Cute Charm-abused, always with no exception have one of the following PIDs, which can easily be identified and blocked from being deposited into the GTS:

0000000000, 000001, 00000002, 00000003, 00000004, 00000005, 00000006, 00000007, 00000008, 00000009, 0000000A, 0000000B, 0000000C, 0000000D, 0000000E, 0000000F, 00000010, 00000011, 00000012, 00000013, 00000014, 00000015, 00000016, 00000017, 00000018, 00000032, 00000033, 00000034, 00000035, 00000036, 00000037, 00000038, 00000039, 0000003A, 0000003B, 0000003C, 0000003D, 0000003E, 0000003F, 00000040, 00000041, 00000042, 00000043, 00000044, 00000045, 00000046, 00000047, 00000048, 00000049, 0000004A, 0000004B, 0000004C, 0000004D, 0000004E, 0000004F, 00000050, 00000051, 00000052, 00000053, 00000054, 00000055, 00000056, 00000057, 00000058, 00000059, 0000005A, 0000005B, 0000005C, 0000005D, 0000005E, 0000005F, 00000060, 00000061, 00000062, 00000063, 00000096, 00000097, 00000098, 00000099, 0000009A, 0000009B, 0000009C, 0000009D, 0000009E, 0000009F, 000000A0, 000000A1, 000000A2, 000000A3, 000000A4, 000000A5, 000000A6, 000000A7, 000000A8, 000000A9, 000000AA, 000000AB, 000000AC, 000000AD, 000000AE, 000000C8, 000000C9, 000000CA, 000000CB, 000000CC, 000000CD, 000000CE, 000000CF, 000000D0, 000000D1, 000000D2, 000000D3, 000000D4, 000000D5, 000000D6, 000000D7, 000000D8, 000000D9, 000000DA, 000000DB, 000000DC, 000000DD, 000000DE, 000000DF and 000000E0

Gannio commented 4 years ago

A quick solution could be to import PKHex's core files to run a legitimacy program on each Pokemon submitted, then reject them on the spot if they don't check out. I used it in a side project I'm working on for a similar reason, and it seems to run fine there. That would also allow any theoretically acceptable Pokemon rather than limit them based on arbitrary issues such as Cute Charm.

Edit: Actually the side project also has some amount of profile implementation in its setup. I'll try and see if I can learn a bit of the framework here tomorrow.

mm201 commented 4 years ago

@hfc2x Cute charm abuse can be done without any assistive devices so I have no plans on blocking it. And you're in the wrong issue for that anyway. You want #3 .

hfc2x commented 4 years ago

@mm201 Okay, that's fair enough, since I guess it'd be on the same level as RNG abuse. Should the problem of the hacked-to-death teams in the Wi-Fi Battle Tower rooms be reported over that same issue? ( #3 )