Concerns about New Wiimmfi Feature

      Concerns about New Wiimmfi Feature

      I shared information about the new Wiimmfi feature regarding automatic bans for receiving items before the countdown in the CT Jam Discord server, and I've collected questions from people here to try to get answers:
      1. It mentions a LEX file is needed for tracks that have item boxes before the starting line. Will this require LE-CODE for it to be fixed, or will this function be built directly into Wiimmfi?
      2. Will it be possible to disable it for certain regions or friend rooms? For example, any region that uses the Online Time Trial mode will essentially be broken by this.
      If I see anymore questions, I will update this post. Thanks!
      What exact feature are you talking about? There is no feature on Wiimmfi itself that would issue automatic bans for using items during countdown.

      When a moderator is running mkw-ana, that can detect some cheats automatically, and when configured correctly, will automatically issue a ban on Wiimmfi. In that case it's up to the moderator to make sure not to run this in rooms / regions where using items during the countdown is expected.

      However, if we add something like this in the future, then yes, region owners will be able to disable that for their region, and friend rooms will not have something like that at all; in friend rooms it's up to the host to decide if cheating is allowed.

      DevkitPro Archiv (alte Versionen / old versions): wii.leseratte10.de/devkitPro/
      Want to donate for Wiimmfi and Wii-Homebrew.com? Patreon / PayPal

      Dieser Beitrag wurde bereits 0 mal editiert, zuletzt von Leseratte ()

      I announced this new feature on the wiki today. There are no precise plans yet. But we want to recognize item cheats, among other things, if they are used too early. mkw-ana has included this feature for a long time.

      At the moment, my aim is to mark new tracks accordingly from now on. Before this feature is activated, there should also be several settings for the regions. Details are not yet clear.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.
      Ah, didn't know you already announced that.

      Yeah, right now it's just vague plans so that for example auto-bans issued by mkw-ana (for item usage before the race starts) can be ignored if they happen on a track where that's expected. That'd be independant from any LE-CODE update, it would just be Wiimm's CT database seeing that LEX flag (as soon as a track has been added to the database) and will then tell Wiimmfi to ignore mkw-ana autobans for that track.

      Every other usage of that feature is still unclear yet, but if we ever add any kind of auto-bans on Wiimmfi itself, however that will work, then of course that will be configurable by region.

      In fact, there's already a flag in the region config on Wiimmfi that can be set depending on the glitches / cheats / hacks allowed or forbidden in that particular region.

      DevkitPro Archiv (alte Versionen / old versions): wii.leseratte10.de/devkitPro/
      Want to donate for Wiimmfi and Wii-Homebrew.com? Patreon / PayPal

      Dieser Beitrag wurde bereits 0 mal editiert, zuletzt von Leseratte ()

      Tock schrieb:

      Why not make a hash database on Wiimmfi for this? You can automatically log it and check it instead of hoping people will add LEX files.
      I thought a long time about this and analyzing the tracks. But analyzing a track for item boxes hits before start is very difficult. Think on moving and falling item boxes, item boxes behind objects, or items you get, because an objects hits some other object so that an item was released.

      And a hash database is more manual work than automated. At the moment I use the results from wszst analyse and store them into the database of ct.wiimm.de. And here I have an export to Wiimmfi with known SHA1 and attributes. All I have to do is: make scan-all. And once declared, updates usually inherit this declaration from their successors.

      I thing, there are very less tracks (1/500-1/1000) where you can get a item before start. In MKW-Fun an old version of Punch City had this issue. And with the new feature I'll give the authors a chance to declare this unusual situation. And I think, the very good Wiki team (mods and many more other people) will update a track with this issue, like they do with second ktpt or extended item pos.

      WIT: Wiimms ISO Tools
      Verwaltet Plain ISO, WDF, WIA, CISO, WBFS, FST: kann Extrahieren, Erstellen, Patchen, Mischen und Überprüfen

      SZS: Wiimms SZS Tools
      Verwaltet SZS-, BRRES-, U8-, BMG-, BREFT-Dateien uvm.



      PN ohne persönlichen Charakter werden ignoriert. Support-Anfragen gehören ins Forum.
      My idea was that when the automatic system flags someone for getting an item before the countdown it first checks the tracks hash against the whitelist for tracks that allow it, then against the blacklist that does not allow it, and if it isnt in there it logs which track it was and the player. Then a mod checks the track and decides whether it is possible or not.

      That way you slowly build up the database without hoping someone randomly knows a track or tests all >4000 tracks.

      Else you likely will get false positives and ban people just because someone did not add a Wiimmfi file to the track and / or nobody catched it before.

      It took people 2 years to find out that GCN Yoshi Circuit had broken Checkpoint linking.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Tock ()

      Another issues with the current model: Sometimes you miss adding released tracks onto your archive. If an update is released that adds this LEX file and you miss it, people still could be falsely banned for this issue. Similarly, should people have to update every single version of each track affected? Sometimes people prefer to have older versions of tracks in their distributions, and people also like to play older distributions. In addition, texture hacks and track edits of custom tracks are usually missed by you unless specifically requested on the Wiiki page for requests, so if they're put into a distribution, this could also cause problems. If you were to continue pursuing the Archive + LEX file method, there would need to be a way for other people (such as me, Kanto, or Tock) to add more tracks to the list to avoid any more problems.