Two weeks ago, a couple MKW code modders including CLF78 have created and posted an Open Letter on Discord, mentioning a couple things they don't like about the current MKW Development community, especially with regards to Wiimmfi and the LE-CODE.

We (Wiimm, me and MrBean35000vr) do agree with some of the points, and we disagree with others; and we decided the best course of action would be to go through that letter completely and then writing responses to each and every section / statement that's in there.


If you haven't read that letter linked above I'd recommend you read it first (or "in parallel" with this response), as I'm not always repeating the statement / question I'm answering to.



We do know that currently a lot of requests (MKW regions, new game definitions, etc.) takes a long time, because usually only Wiimm performs these things and he has a ton of other things to do. That is why the described functionality (only allowing approved Texture Hacks in worldwide races to prevent cheating by using modified tracks) is still in development / being prepared since over a year. We know it would be stupid to have requests like that lay around for eternity, that's why there's multiple people other than Wiimm and me (mainly Atlas, KantoEpic, Krummers and Trainiax) who are currently involved in all the track testing.

A couple notes about that:

If so many people in the community were against that kind of verification, why did none of these people ever mention that concern to me and/or Wiimm (at least not in the main PM / Conversation I just read through again)? I don't know if I am missing some other communication that took place between Wiimm and any of these people.

Back in April 2020 Wiimm and me informed the whole Wiimmfi team about the fact that we want to do something about modified tracks that people are using for their advantage. Around that time, there were multiple bans for people using modified tracks clearly intended to cheat (removed oil spots, added more item boxes, made offroad weaker, and so on). At that point we just asked the Wiimmfi mods what their opinion on that was (and suggested white-/blacklisting for tracks, and they agreed. NONE of them mentioned any concern like "that would prevent people from using new Texture Hacks". Neither did any of the ~5 people that are currently testing all the Texture Hacks.

Still, we were aware of the fact that many people like to use Texture Hacks in worldwide races, that's why Wiimm gathered that group of people who volunteered to verify all existing Texture Hacks in the Wiiki and classify them into the different groups. Yeah, that's been taking a while because there's so many, but once that's done, I see no reason to believe there should be any large delays - after all, Wiimm is always testing *all* newly-uploaded CTs in the Tockdom-Wiki, categorizing them and adding them to his archive, and I believe his plan was to include Texture Hacks in that process as well, once all the currently available ones have been handled. So just like CTs get added to Wiimms archive once a week or so, the same should happen for Texture Hacks. So no, signing up on Wiimmfi will not be required, you just need to somehow get the Texture Hack either into the Tockdom Wiki (where nearly all tracks are anyways), or to Wiimm, or to one of the other Texture Hack testers. If we decide to go with a whitelist and only allow approved Texture Hacks, and not with a blacklist only blocking known bad tracks. The issue with a blacklist is that it's trivially to circumvent, just add one random byte to the track somewhere and its hash is going to be different.

There isn't really any other alternative to prevent cheating. Deal with the fact that people cheat online with modded tracks and there's no way to detect and prevent that? With item cheats and stuff at least you have a chance to detect these - but who's going to notice if someone adds another couple itemboxes, makes offroad a bit faster, removes oil spots, or other small changes to cheat? These have all happened in the past, and only got caught because the cheating mod got published, or someone made a video of themselves cheating ...



Yes, the payload "uses" security-through-obscurity. There's tons of additional verification we're doing in order to be able to get rid of the 7-day wait (remember back when that didn't exist, how many cheaters got around our bans?), there's stuff related to 1.1 (the track stuff) and if the payload was open-source it'd be *very* trivial to just patch out any checks for stuff like described in 1.1 or any of the other anti-cheat stuff.



Modding interference sometimes is a problem with the payload, I agree with that. That was one of the reasons (not the only one) why CTGP got the unique exception to bundle the patches directly into CTGP without downloading them from Wiimmfi. Remember, we've introduced this payload in 2018. That's already four years ago. Back then, the ONLY MKWii game mods were CTGP or old CT-code distributions. Any other distribution was a plain, 32-track distribution with maybe a couple cheat codes, but no significant code changes.

In the last couple years lots of new Mario Kart Wii game mods emerged, like my LE-CODE, or the described Online TT or Hide and Seek mod. If we were to completely redesign the payload system from scratch in 2022, we might have used a different approach (a custom REL, or whatever) that would be more compatible with custom game mods, but that's how it is. Back in 2018, neither Wiimm nor me nor MrBean would have imagined the number of MKWii code modifications created in the coming years.



As for the specific modifications that were described there: I was not aware of the fact that running frameskip offline would break ghost data saving. Neither did MrBean tell me/us about that when we implemented the Frameskip code, nor did anyone else - like the creator of Online TTs - tell us about that once they figured out about the bug. When we implemented Frameskip (which was *intended* for online races with a lot of lag), we didn't notice any harm in offline races and decided to leave that in. Now that we've been told (through that open letter, as far as I know nobody told us about that earlier), we can try to get that fixed. Right now, frameskip IS disabled while in TT mode, and it's always been since it was introduced. That means that the claim from the document - quoting "it's literally impossible for any mod using Wiimmfi to support ghost saving since frameskip is forced upon them" is plain false, since frameskip is automatically disabled in time trial mode. If that's broken in Online TTs, then that means the mod is not correctly telling the game to play a Time Trial.

Yes, you could say it's Wiimmfi's fault that it wrongly applies frameskip in online TTs, but you could also say it's "Online TTs"' fault for not correctly setting the TT flag ...
Now that we know about that bug - again, nobody told us about that - we can try to get that fixed by either detecting online TTs and then not run frameskip, or by fixing whatever causes the ghosts to desync.

As for the Hide and Seek timer bug, that seems very interesting. CTGP's CountDown mode, which also has a timer running backwards, and normal Battle races, which also have a timer running backwards, that timer lag fix is working as intended; so there must be something weird about how Hide and Seek implements its timer. Now that we know about that (previously I've only been told "H&S doesn't work, do something"; that's not a helpful bug report); we can either try working around that, or, ideally, H&S would be implemented like all other already existing game mods with a backwards-running timer, if possible. I'm not sure if this is the same bug that CLF78 has already fixed with this commit or if this is a different one.

As for the LE-CODE message bug, that's something that's definitely Wiimmfi's fault / my fault, and was caused by some leftover debugging code (using that particular BMG message) that we accidentally left in payload 91. This bug has since been fixed with payload version 92 (which sadly took me a while to deploy due to issues with my development server / system).

Yes, it is annoying if Wiimmfi updates - whether it's server updates or client payload updates - break the game or any existing game mods. But please remember: Wiimmfi is created and updated by just two people, Wiimm and me, for more than 8 years already. It's been very very very stable in the past regarding the stability / functionality of the core servers themselves - but still, when we're implementing large new features like reconnecting to the server after a connection loss in the middle of a race, like we did with payload 91, then yes, stuff can break. We do not have the capacity to run every code change through millions of test cases, and because Wiimm's distributions did not use the affected BMG messages, all our tests were still successful.

Unless we start testing each payload update with EVERY existing CT pack or mod distribution out there, there is going to be bugs, whether they are our fault, the mod creator's fault, or just nobody's fault because it's a general incompatibility.

If you have a Wiimmfi account, you can visit the Wiimmfi portal and easily roll back any payload update we do, to test if a bug that's been reported to you (in your own CT pack or distribution) has been caused by the most recent Wiimmfi update.

The Wiimmfi portal also has a way to mark certain payloads as beta or alpha versions, which so far has only really been used by Wiimm & me during development. The beta branch is open to everyone, so if you're a mod creator you can use the beta branch to receive updates earlier than the public for testing. In the past we haven't really used (or advertised) that, but that's something we will change for most future updates, and definitely for large updates like frameskip or the server reconnect code.

In response to this open letter, I have asked Chadderz to add a couple new channels to the "MKWii Mod Programmers" Discord server which most MKW code modders should already have access to, where MrBean and I plan to discuss future payload updates (instead of doing so through private Discord DMs) so other modders can see what we're up to before it gets released to everyone - that was a suggestion that came up during discussions on Discord. We will also be using these channels to announce and describe new Beta payloads.

EDIT: The Discord Channels mentioned here now exist. The "announcement" channel where we announce new payloads is readable for everyone, the "discussion" channel is read- and writable for everyone, and the hidden "development" channel is only visible for people with the Mod developers role.



As for CTGPs exemption, that's already been explained above - CTGP already existed when we made the payload, as the most complicated MKW mod at that time, with a proper auto-update system. It was just easier to handle code updates in CTGP that way, rather than making sure none of the payload patches conflict with any CTGP patches. Yes, I completely agree, now that there are more and more mod packs out there, that system should be changed. But I don't think open-sourcing the patches (1st suggestion) is the solution. First, for reasons described above regarding the "security-through-obscurity" complain. Second, because that would mean we'd need to wait for each and every mod to be updated and then have all their users redownload the mod. That means we're going to have to wait months until we can finally phase out an old payload version, which is very annoying.

As for the 2nd suggestion, letting mods choose which features to apply, this is something we can definitely look into. Now I don't know how complicated that is going to be to implement properly so please do not take this sentence to mean "we are absolutely going to implement this this month", but right now I see no reason that would prevent us from doing that, so if that is something that mod creators want (which apparently is the case according to that open letter), then I can add that to our to-do list. HOWEVER, I also have to say, that both Wiimm and me have a normal, day-to-day, job. We have less available time for Wiimmfi then we've had back in 2014 when we started the project, and we have more and more and more stuff added to our to-do lists all the time, so I cannot promise when we will get to that. But that same statement would apply to ALL ways / methods, no matter which one we were to choose.

As for the 3rd suggestion, listing patches & addresses & reasons is something we can do, and I've been planning to do that (at least listing the patches themselves) for a while. A week ago I've published a list of all game patches including a short description, though it will probably take a while until I can produce a full list of all the in-game RAM addresses we're patching (and a reason for each RAM patch).

As for the Wiimmfi patch not being provided in GCT form - yes, that probably wasn't the wisest decision back then, there wasn't really a reason to keep that a secret. Though, back then, *all* MKW code mods (at least those I knew of) were distributed either as an ISO patcher (rare), or, more common, a Riivolution XML pack. A very very simple solution for modders back then would have been, take the original game, patch it with Wiimms Tools then have WIT dump the difference between unpatched and patched DOL and put that into an XML. What's why, in that linked Discord chat, I've said "I don't think there was a particular reason to keep that secret" instead of "Yeah we kept that code a secret just to annoy you or do whatever".



Yep, I agree, the situation with the RCE code is stupid. The whole code for the RCE patch has been written by MrBean for CTGP and has then been adapted for the Wiimmfi Payload. Due to a GCC compiler change / update / whatever the compiler started to no longer generate the correct ASM code but instead caused the console to crash upon encountering the RCE. The reason this is only the case for the Wiimmfi Payload and not for CTGP is apparently different compiler versions or settings that we can't just easily change.

When this has been reported to me in 2021, I have told MrBean about the fact that the RCE protection patch is broken. MrBean did agree that he needed to rewrite the whole RCE patch "soon" in order to be more resiliant and more clean, which would also fix that bug. I've bugged him about that a couple times, but he didn't do so until yesterday. And because it's not A) a security issue and B) normal users are unlikely to encounter this issue, I didn't really regularly ask him for updates.

Yes, the fix (that's been suggested) in the assembler code itself is simple and easy, I agree with that. But the patch is written in C, not in assembly, and it's not so simple or clean to convince the compiler to output particular ASM; and while just "injecting" the ASM bugfix would have worked, it'd have had a high chance of breaking in even worse ways after an update.

MrBean has provided me with a new version of that code with that issue fixed after being poked again yesterday, and I have rolled that out as a beta payload version 93, meaning, it's available for everyone who opted into receiving beta payloads, as mentioned above.


The issue with the payload download apparently being insecure has been crossed-out from the document already - this was never the case for any of the official patchers, just for (the first version of) the self-made gecko code.

As for telemetry data being unused, there's a simple reason for that: Implementing moderator interfaces or APIs for stuff like that takes time. Lots of time, which neither Wiimm nor me have. It's on Wiimm's to-do list to have Wiimmfi immediately act on that telemetry information itself (by kicking and banning cheating players, in regions where that feature is enabled), that way there's no need for moderators to access that raw telemetry data.

After all, as I've already mentioned before, we're only two people with a limited amount of time for Wiimmfi, so yeah, sometimes part 1 of a feature is already implemented (collecting data) but part 2 (doing something useful with it) needs to wait for some reason when other stuff is more important.

And no, I didn't "hurl insults at the person who found the flaw". I hurled a single insult ("idiot") at the person who decided to ABUSE that flaw to break other's player's rooms.

The so important thing we were working on at that time was the security update / updated patchers for all other games other than MKWii due to a dangerous bug. ( wiimmfi.de/update ). This was a fuckton of work to make sure that works with all games without breaking more stuff - but it was a risky security issue that could have caused lots of bricked consoles, so YES, stuff like that IS definitely more important than fixing friend room kicking (which we had to disable because cheaters found a way to trigger that even when they're not the room host). We've spend multiple months doing NOTHING Wiimmfi-related at all except fixing these security issues so hackers can't just brick your console.

And back then, when the vulnerability was still present, I couldn't exactly say "Sorry, we're fixing a vuln in ALL Wii games that cheaters can use to brick your Wii, kicking has to wait", could I?



- Character and Vehicle modifications are possible, and there is no server-side auto banning for invalid characters or vehicles. All that happens (server side) when using such a character with an invalid ID is that the driver / vehicle display on the Wiimmfi page stays empty. One of the Wiimmfi moderators (Atlas) has a tool to monitor the Wiimmfi status page for players using illegal vehicle/drivers in worldwide races so that HE (or another Wiimmfi moderator) can manually ban these players.

- I agree about the fact that the current RCE fix is broken and stupid. As mentioned above in 1.2.2 that was something that MrBean was supposed to fix a long time ago, and has only just now (after this Open Letter blew up) finally fixed the bug. This issue is now fixed with the new beta payload (including support for larger or smaller buffers) and will be rolled out to everyone if there's no bug reports with the beta.

- Yes, the Wiimmfi payload is developed and compiled in a way that it always has to be loaded at the same RAM address. Back when we developed the update, nobody was using that space, it was dead RAM that nobody ever used, so we used that piece. Please remember that back in 2018 when we made that update, we were under immense time pressure. We knew a bricking code existed, we knew malicious people had access to that, it was only a matter of time until someone used it and bricked a ton of Wiis. That isn't exactly the time to make updates even more complicated by introducing a build system / dynamic linking that can handle being moved to another RAM address. Yes, it would be cool to deliver both the Wiimmfi Payload and the LE-CODE as a dynamically-linked REL file, and yes, I agree, it would be helpful for other custom mods, but it's not that easy, unfortunately.



First, let me describe what my initial intention was when I developed the LE-CODE, and why I chose certain design decisions:

Before we had LE-CODE, Wiimms MKW Fun was a mess based on multiple different patches. Some patches were in the old ct-code form, some patches were Gecko cheat codes, and some patches were in a custom ASM patch code format that Wiimm developed. That made adding features complicated, since you had three different kinds of codes in three different locations that were all compiled and loaded and used differently. *That* was the main reason I initially started working on the LE-CODE - not as a feature pack for other distributions, but to make MKW-Fun code development easier for Wiimm and me.

As soon as we had the first test versions available and/or started talking about that to others, many other people expressed interest in using the LE-CODE for their own CT packs, and we thought, why not, the binary's there, Wiimms Tools support it, here you go.

Then, LE-CODE "blew up", got immensely popular, and almost immediately, nobody made ct-code based CT packs anymore (or old-style, 32-track, CT packs). LE-CODE had gotten to the de-facto standard for new CT packs, when I hadn't even intended for that to happen.

I definitely agree with the last statement, that 2014 was a different time and the MKW development scene has changed immensely since then.
But still, it's a game mod that Wiimm and me developed, and released as binary form for MKW-Fun and other CT packs to use. That is our decision, and that's how it is. However, as described under "2.2 The Issues", we will try to make the LE-CODE more compatible to be combined with other game mods in the future, by giving the user more detailed control over which features from the LE-CODE to enable or disable.



According to the open letter, I am "Known for [my] tendencies to avoid answering questions about programming". That is not true, not at all. If I receive questions from people that I can answer, I'm doing that. But I get so many messages on Discord and on other platforms that I simply can't answer everything. Yes, I've been ignoring some of these messages and that's probably not the best cause of action. In the future I'm going to clearly respond with "I don't know" or similar. I've checked all the examples you've linked, though. I can't find any where I've ignored a person completely.

Just because I made LE-CODE doesn't mean I can answer any question about why a crash happens. Especially when (as it often is the case) the crash happens in Nintendo code and not in my code. I also have nearly 0 clue on how to actually MAKE a LE-CODE distribution as, believe it or not, I've done that maybe twice in 2019 when I began developing LE-CODE, and since then I'm just using pre-made scripts to make a test distribution or I just inject a new LE-CODE build into MKW-Fun or Wiimms Intermezzo to test - no need for me to know how to actually make a new distribution, Wiimm does that, so I have no clue how that works. Especially for questions regarding Wiimms tools - ask Wiimm.

Yes, sometimes I miss messages because I accidentally mark them as read in Discord. Happens, then I answer when getting another message. Sometimes I'm on holiday or don't have much time for Wiimmfi, then stuff might not get answered for 2, 3, 4, weeks.

Sometimes, I just DONT KNOW the answer to a question. The reason why I tend to "ignore technical questions", as mentioned in the letter, because with technical questions there's a way larger chance that I don't know the answer than with general Wiimmfi questions.

I am a private person. A volunteer. Wiimm and me are providing the LE-CODE binaries for fun, because we can. Because it's our hobby. Until any of you start paying us for exclusive premium support, none of you can *demand* I answer to any messages or support requests, *especially* coding ones or crash debugging that usually require more time and thought to answer. Sometimes I just don't answer. Maybe I don't feel like it, maybe I'm on a month-long holiday, maybe I'm sick, maybe I can't answer your question, whatever.

Just like yours, my day only has 24 hours, and I have a day job, and other hobbies, too. I don't have lots and lots of time available for Wiimmfi, LE-CODE, payload, Wii stuff, server maintenance, forum moderation & administration, responding to Discord messages, and so on. That's why stuff doesn't get done and/or only gets partially implemented.

Having said all that, let's look into how the situation can be improved:

As for the LE-CODE documentation: Most of that has been written by Wiimm. Neither Wiimm nor me are native english speakers, so documentations (or texts in general) written by either of us can sometimes be confusing or sound like crap. I can't deny that, but I also can't change that. We aren't going to have native english speakers review everything we post on the internet. But that's why all the LE-CODE documentation is in a publicly-editable Wiki. If something is written in a confusing way, you can rewrite it. If you had to figure something out manually because we forgot to document it, you can add it to the Wiki for future users to use.

As for security stuff: No, the LE-CODE doesn't contain any security bugfixes that would leave non-LE-CODE users vulnerable to anything. All security patches are included either in the Wiimmfi payload or directly in the Wiimmfi patchers.

As for the binary blob and wasted memory: Yeah, that's true - LE-CODE's binary is compiled similarly to how the Wiimmfi payload's being compiled (see above), so the same restrictions for that apply. I've tried converting the LE-CODE into a REL before so it could be relocated, but it's difficult and I didn't get it to work (at least not with the current build system and without using stolen Nintendo compilers or tools from whatever Nintendo leak). Instead of spending a year doing stuff like that, that no ordinary user will ever see or care about, I'd rather do other stuff.

As for features: Yes, I know there is features in the LE-CODE that cannot be disabled, not all of them are included in the config file. We've been planning to change that, and I believe almost every new feature we implement does get an appropriate feature toggle (track repick limits, performance monitor, TTs on custom tracks, extended presence flags, speedometer, thunder cloud time, special chat messages, "Wiimm" cup with random tracks; can all be controlled using a parameter file by the distribution creator). Yes, it's on my to-do list to do that for the other, older stuff, too.

The only ones I could think of that people would want to disable, though, are the Wiimmfi patch (to run LE-CODE on an AltWFC server) or the edited offline VS race point matrix. Other than these two, I can't really imagine many features that would need to be disabled / configured by a mod creator?

Goomba size changes, extended item range, custom ObjFlow files, position tracker mods, modified woodbox drop height, is all stuff that's fully controlled by the track(s) that are added to the distribution. It doesn't really make sense to have LE-CODE feature toggles for stuff like custom ObjFlow files or position tracker mods - if you don't want those, just don't put any modded ObjFlow files or any LEX files into your distribution and the features are not going to be used.

Other than the Wiimmfi patch and the offline VS points, is there any other particular features that I'm missing that people would want to have a feature toggle for? If there is, we can probably add feature toggles for that too, if there's a good reason.



- We will try to add more feature toggles to the LE-CODE for stuff people have requested in the past, including settings to disable the built-in Wiimmfi patch
- Providing a list of places where the game is patched, and why, is something I can do (just like with the Wiimmfi payload mentioned above) for all addresses used by the LE-CODE, to make it easier to combine the LE-CODE with other mods. A list of all addresses patched by the LE-CODE will be published soon-ish, but a full explaination of what each patch does can take a while.



- The linked messages about documentation are with regards to messages either sent by Chadderz, or related to Chadderz (his Wiki), so I (Leseratte) can't really comment much about these. I believe Chadderz has already commented on that issue in the related Discord discussion on the "MKWii Mod Programmers" Discord, but the summary is, Chadderz thinks that in his jurisdiction, sharing most of this information is illegal, and unless any of you happens to be a UK-based lawyer who can tell Chadderz for certain that publishing all that information is completely legal, and will take legal responsibility if that's not the case, I can't blame him for not doing something he thinks is illegal. It doesn't matter if we all (including Chadderz) think the law is stupid, or if the law doesn't exist in my or your jurisdiction.

But I'd like to mention that Wiimm (and me) are adding tons and tons of stuff to the Wiki. Early documentations of MKWii file formats, analysis of the MKWii network protocol, long and extensive explainations about LE-CODE, how to generate a distribution, and how all the custom features work (LEX file, extended presence flags, LE-CODE settings), *ALL* have large and extensive Wiki pages mostly written by Wiimm, and partially me. We aren't keeping any documentation away because we feel like it - if we didn't document some stuff, it's because documenting takes time, lots of time, and as already mentioned above, we don't have that. But still, the closed-source LE-CODE has a way better documentation than some of the existing (older or newer) open-source mods - I believe it's easier for someone to make a CT pack based on LE-CODE than it is to make one based on ct-code, MKW-SP, Hide&Seek, Online TTs or other mods, even with the source code of the latter being available. At least for people who aren't developers.

I do have my own, incomplete, symbol list for Mario Kart Wii which I've collected over the years from multiple sources. If MrBean agrees with that (as he provided some of them), I can publish that list somewhere as well, but looking at how complete the symbol lists in these ghidra files or in the mkw decompilation repo already are, I doubt they'd be useful to anyone.



The Epropeller Speed cheat code was added by Wiimm to that tockdom page, yeah. Wiimm didn't miscredit anything, he didn't say it was his code, the very first revision of that code simply started he doesn't know who made it. At that time, Wiimm wasn't really that much involved with other code modders, and he still doesn't use Discord much where most of these discussions take place. I'd assume "KE-CODE", while being obvious to Kevin and people who know him, didn't really tell Wiimm much, so he left that out (but explicitly added a question mark to indicate he doesn't know who made that code). Three minutes later, after the initial revision, he found out the original name ("KE-CODE"), and another ~15 minutes later, apparently after he talked to Tock, credit for the creator (KHacker35000vr) got added.

NEVER did the page state that Wiimm (or I) made the code. It just stated that he doesn't know who made it.

No, "the LE-CODE author" didn't take its place. If you read the page correctly, it says "??? made the PAL version and Leseratte ported it to the other regions", which, I believe, was true at that point. I got the PAL version from someone, probably from Kevin? I don't remember; and then I ported it and gave it to Wiimm to test. Never did Wiimm (or anyone else) claim that I have created that code.

*That* is something you feel the need to mention in an open letter like this? That credit for something got added a whopping ~15 minutes after it was first posted?



So, to summarize:

• Wiimm and me are only humans doing this in our free time and we only have so much time. If we don't implement a feature you'd like, it's not because we hate you, it's usually because it either doesn't work or because we don't have time. If game requests or region requests take a while to be approved, so be it. Wiimmfi's a free service and we don't provide 24/7 support. If I don't respond to your Discord message, it's either because I don't have time, or I don't have an answer to your question.
  
• I agree with some of the points, but claiming that I would never answer to any programming-related questions is clearly a lie. Just because I made LE-CODE doesn't mean I have answers to all LE-CODE questions.
  
• Wiimm never claimed that I wrote the Epropeller code, that's also a lie.
  
• Short-term, we will provide lists of all RAM addresses used/patched by both the Wiimmfi Patcher and the LE-CODE
  
• Long-term, we will add explainations to these lists explaining what each patch is used for
  
• Long-term, we will try to provide a way for distributions to disable certain non-mandatory parts of the Wiimmfi payload (and disable/enable LE-CODE parts in LE-CODE-based packs), but I can't promise when that'll be and how exactly that'll work for the payload.
  
• The MKW payload and the LE-CODE will stay closed-source, but the development process itself (what we're working on, what things we think about adding, when there's new Beta versions, and which new hooks we're introducing that could break other mods) of the Wiimmfi payload will be made more open and will happen in a dedicated Discord channel instead of just through private chats to make it easier for mod creators.
  

I hope this response makes it clear why some things are the way they are, and also makes it clear that we can try to improve some of the points mentioned in the letter.

Thanks for your response. Let me respond to each of your comments:

Right now what's happening with Texture Hacks is going through all of them, categorizing them into known allowed hacks (that just change textures) and known forbidden ones (that do model / KCL / KMP changes), and ones clearly designed to cheat. With the first step to forbid tracks clearly designed to cheat.

As I mentioned above, how and when and if we're going to block all other Texture Hacks is still open for discussion and hasn't been implemented and/or confirmed yet.

EDIT: And, as @Trainiax mentioned in the post before this one, Discussion about that has been going on on the Tockdom Wiki. Nobody tried to "hide" anything.

We're hashing the entire file to know which track is being played, so it can be displayed on the status page and so we can have statistics on which tracks are how popular. Wiimm's track archive has always been designed with the SHA1 checksum of the uncompresses SZS as the track identifier, so that's what we used here.

Later we've added hashing KCL, KMP and Minimap and stuff like that so when someone is playing an unknown track (a track where Wiimmfi and Wiimm's CT archive do not know the SHA1 checksum), Wiimmfi can take a guess and display something like "this has the same KMP and minimap as this other track X, it's probably an edit of that track", instead of just displaying "Unknown track XYZ".


No need to make it even more trivial, then. Maybe patching out the current code is trivial, but manipulating it to send fake data isn't "trivial". Yes, you (and other modders) are able to do that with your skills by hard-patching the binary, but most cheaters most likely aren't.


For online races specifically?

I mean, I get it, it's annoying if you want to develop a feature for your mod (in this case, Online TTs) and the Wiimmfi payload has a bug that prevents that from working. I've had that happen once or twice with the LE-CODE as well, and obviously it's easier for me to work around that than it is for others. That's what, as I mentioned, we can try to change by providing a detailed list of all patches including all the addresses we're patching (both for Wiimmfi and for the LE-CODE) so there's no or at least less address conflicts.

But in this exact situation, was there something we could have done better to prevent that? As far as I know, and if I'm reading the open letter correctly, ghost saving in Online TTs was never implemented / released and was just something Melg and others tried to add to the mod. (Quote: "Wiimmfi prevented the author from implementing ghost saving").

We're going to be releasing more payloads on the beta branch (and announce new releases) in the future so mod creators can make sure to test their mods against new payload versions and tell us if it breaks something.

But in this particular case of frameskip, do you have a suggestion for what we could have done better? We couldn't have known that people were trying to implement ghost data saving in online races, and even if we did, without having a distribution that already uses this, how could have we tested and prevented that issue?

We cannot really write the payload with every hypothetical potential feature that anyone could ever want to implement in the future in mind, can we?



Yeah, that's really a point we can and should change for future updates, especially ones so large as the reconnect code & frameskip.


I'm a bit confused about that. You want us to keep a new feature hidden, not implemented for anyone, just because it's not 100% implemented yet, and the 50% implementation doesn't do any harm?

At least with the current implementation Wiimm and me can see that data, though Wiimmfi mods can't (yet).

I mean, if that's what you / the community as a whole wants, I can keep partially-finished features out of the payload in the future. But that is going to cause fewer and larger payload updates with massive changes whenever a new feature is finally completely finished. I'm genuinely curious as to how that would be better for both users and mod developers?

Currently, when we have new feature(s) that we want to implement that contains both a client part and a server part, we both chuck that onto our to-do lists, I'll get to the client part whenever I have time (and verify that it sends the correct stuff to Wiimmfi), and Wiimm gets to the server part whenever he has time (and verifies that he receives the correct data from the client).

We could change that and have the code stay commented out / not included in the payload until the server side is fully implemented, too, but I fail to see the advantage in that? Or am I missing something?



I *did* mention multiple times in that time that Wiimm and me are busy doing important security work. That should have been enough information to understand that, yeah, important security work takes precedence over bugfixing small features. Yes, I could have said more, and given more details about what exactly we were patching - but to me, Wiimm and MrBean, that was just an unnecessary risk.

An RCE that occurs in nearly all games (including Mario Kart Wii!) is a huge deal, and we already had to rush with the new updated patchers (that's why there were so many small 0.7.0, 0.7.1, 0.7.2 ... updates within the first week or so after its release - we would have liked to test more ...) because someone figured out the exact exploit shortly before we had the new patchers ready.

Publishing details like "Hey guys, there's an RCE vulnerability in a lot of Wii games" would have increased the risk of someone abusing that thing earlier.

That's what happens with nearly all software, though. The developer finds a security vulnerability (or someone responsibly discloses a security vulnerability to them), the developer makes a patch, the developer releases a bugfix, and *then* there's an announcement "Hey, there's a critical RCE with CVE-12345678, please install update X so you'll be safe".

For a regular user who is just curious why the kicking functionality isn't working, does it really matter?
It was chat messages on Discord, damnit. People asked me why Kicking isn't fixed yet, I'm telling them that it's because we're busy working on an important security issue.

I'm not going to ponder for hours over every message I write, thinking about how I best phrase the message I want to get across...



The only automated bans that Wiimmfi issues is for completely invalid VR/BR (0 or > 9999), and for using a region you're not allowed to use. These bans have been implemented for a looong time, even long before the payload, because these were the only things we could really detect on the server back then.

Other bans are handled by the Wiimmfi moderators. Some mods like Atlas are running tools monitoring certain aspects (like the usage of Texture Hacks clearly designed for cheating), but that's not done by the server yet. Which is one of the reasons for the stuff mentioned under 1.1 - we want to handle that on the server with automatic server bans eventually, instead of moderators doing that manually.

The server itself is fairly tolerant with regards to client mods. Yeah, messing with tracks, vehicles, drivers, finish time (in custom modes) and so on may make the /stats/mkw and /stats/mkwx pages look weird, but the only thing that that causes is an entry in the logs, no auto-ban or other blocking behaviour by the server.

That might change in the future, but even then, only for worldwide and for regions where the region owner has enabled that setting in the region settings, so even then a mod that adds more drivers / vehicles would be fine, as long as they're only used in friend rooms or in its own region.


I know, that's why I mentioned I should change that and clearly respond with something like "I don't know" in the future. I was treating Discord Chats more like a Discord Server or a Forum. If I didn't know an answer, I didn't write a useless "no idea". I realize that that wasn't the best course of action for 1:1 chats.


I did not say that the LE-CODE contains additional security bugfixes. I said some parts of LE-CODE are security-related. Maybe that phrasing is crap (I'm not a native speaker).

The LE-CODE used to contain (and probably still contains?) a couple bugfixes that are *also* included in the Wiimmfi payload, so that you aren't as vulnerable if you try to run a LE-CODE distribution in LAN mode or on an AltWFC server. The LE-CODE never contained any security-related bugfixes *that aren't also included in the Wiimmfi payload anyways*.



No, I think you missed the point. The Wiiki is full of documentation written by Wiimm or me. We documented MKW's network protocol, we've documented the LE-CODE and all the additional features it includes and how to build your own distribution, Wiimm documented lots of stuff about track objects, and so on. Lots of MKW-related stuff we do gets documented. All the modding tools (wszst, wkmpt, wbmgt, wimgt, wkclt, wmdlt, wpatt, wstrt, wctct, wlect) Wiimm developed also have lots of documentation.

We are not sitting on a big pile of documentation. Yes, I do have an incomplete symbol map of Mario Kart Wii which has grown over the years. I'd say 80% of that symbol map is related to Gamespy stuff from when we made Wiimmfi, and the whole Gamespy SDK stuff is already open-sourced anyways.
And for the other 20%, most of that is from the old CT-CODE from Chadderz, from various bits and pieces we've picked up here and there, or stuff I was told on Discord (by Bean or by other people).

I don't have a large symbol map about the internals of Mario Kart Wii. MrBean and Chadderz have, sure, but the fact that they're not publishing theirs has legal reasons (as mentioned above) and I can't change that. Wiimm and me don't actually have that many symbols related to actual MKW game code that could be useful to anyone. That's true today, but it was also true three or four years ago when there were no other public sources like the Ghidra project or Riidefi's mkw decompilation.

Wiimm and me aren't really doing any decompilation work of Mario Kart Wii. It's very very rare that Wiimm or me ever "hunt" through the game, searching for new game functionality.

Most of the mods we're doing both in the Wiimmfi Payload and in the LE-CODE is just more and more custom code appending to a small set of game hooks. Lots of track mods (LEX files, slot shenanigans) that happens during track load, for example.

Wiimm and me aren't doing low-level, in-game code or menu hooks like Online TTs, Hide and Seek, or stuff like that. I have absolutely no idea how I'd ever mod a game mode to play TTs online, or how I'd implement most of the stuff in these mods. It's not what I'm experienced in. Take a look at the feature list of the LE-CODE.
We're good at writing general C code for logic stuff (extended presence flags, track variants, debug screen), stuff that takes very little game hooks and has very little "connection" to the actual game code.

We do not and have never had a secret, large collection of symbol maps or other decompiled information about the game. Other people do. Even today I don't think I'd have the capability and the knowledge required to even start building actual game mods on the level of CTGP's Countdown, your Hide & Seek, or Melg's TT Online. I simply don't.


I seem to have missed that part, sorry.

In 2016 - when I started working on all the competition stuff and we started collecting competitions, figuring out how the system works, and re-implementing all the server infrastructure on how to distribute competitions, the plan / goal was to have it working like Nintendo. Have a competition for a while, then have a different one, and not have people be able to practice and practice a competition over and over again to get better times than players who don't mod their game with competition files manually.

That didn't really work out since a while after that, Custom competitions started to appear and we've built a competition interface, where people could have uploaded and played competitions all the time.

I've been planning to make something more useful with all the competitions than just taking them as-is, dumping them into a ZIP file and telling people "here you go, a bunch of RKC files", but it wasn't really high on my to-do list, more like a "I should eventually do this when I have time".

I think the "tournament museum" is a cool thing.
It makes the competitions accessible to users in a user-friendly way (unlike just having people download a ZIP with all the RKC files) and without potentially messing up Wiimmfi or the competition rankings when hundreds of people upload the same RKCs to Wiimmfi just to have Wiimmfi deliver them to their Wii because there's no easier method to do so.

When I was approached by Zach about getting the RKC files for that mod, I believe Wiimm gave them an internal Wiimmfi right to download all the competitions from Wiimmfi including their proper descriptions and texts to use for the project.

Yes, I should have just thrown a ZIP file with all the RKCs up on some webserver for modders to download, and I didn't.

I'm not sure what you were expecting.

Yes, some of the stuff I / we did in the past wasn't the best solution. We should have published a (detailed) patch list earlier, I shouldn't ignore messages, and so on. But what were you expecting as a response to that letter?

Me and Wiimm going "Hey, that's great arguments, here's the source code for Wiimmfi, the LE-CODE and the Wiimmfi payload"? No, we both know that that wasn't going to be the response to that letter.

In response to that letter we've published the patch list, I will soon update it with more details / offsets for each patch; Bean has provided a new update that fixes the RCE bugfix, what else could we have done within two weeks? I already mentioned a bunch of stuff we're going to look into (making parts of LE-CODE and the Wiimmfi payload optional so distributions can turn them on/off), and I also mentioned that future discussions regarding payload development will happen in the open on a Discord channel rather than in private.

And the response took "so long" because we're three people. I didn't want to write this whole response on my own (then it would just have been my opinion and not something Wiimm and/or MrBean would have agreed with), so I first needed to write a draft, then have Wiimm check it, then find some time for Wiimm and me to talk about it, mention concerns, adapt it, and so on. And then I deliberately held it back another two days until I had payload version 93 available, another thing that was requested in the letter, as a sign like "Hey, we're starting to do some of the stuff you've asked in the letter, not just talk about it".

Wiimmfi development has slowed down in the last couple years, compared to how fast it's been in 2014. In 2014, when we started working on Wiimmfi, Wiimm and me talked to eachother once a day, or every two days, trying to get everything working. In the last year or so, we're talking to eachother twice a week when we're playing MKW-Fun, and then *maybe* once again on the weekend. We simply do not have as much time for Wiimmfi as we've had years ago. Under these circumstances, I don't think a response of one and a half weeks is "so long".

I know about that, that's why I mentioned it's probably partially Wiimmfi's fault and partially the mod's fault. I think it's just one of the situations that can be prevented with us publishing new patched addresses and new beta payloads earlier. I know it's most likely not that easy to just set the Time Trial flag in general as that's going to trigger a ton of extra behaviour in the game that's not compatible with the rest of the game mode.

@ardaonline: Sorry, I do not speak Turkish, and DeepL doesn't seem to be able to translate your text into readable / understandable English or German, if you want to contribute to this discussion please post in English. If your response has nothing to do with this open letter (which I'm guessing due to the few readable word snippets) please post it in another thread again, this thread is specifically for the discussion about the mentioned open letter and our response(s) to it.

Can't say much about that as I don't know why other mods would have said that. Or did Wiimm or me actually say that somewhere?

"The Wiimmfi Team" isn't a single person. It's absolutely possible that some mods forgot about the discussion that took place.
Here's the message that we've sent to the whole Wiimmfi team in 2020:
If you got conflicting / wrong information from someone, that most likely was a mistake and not something done to deliberately mislead people




Genuinely curious, can you link me the page / revision where it said that?

I checked every single revision of the Epropeller Cheat code wiki page and neither of them mentioned that I (or Wiimm) made the code.
Quoting the very first revision of this page, this is what I see on that page - because Wiimm did not know who made the code:

Epropeller Speed is a Cheat Code for all 4 regions of Mario Kart Wii. ? made the PAL version and Leseratte ported it to the other 3 regions.

That is true, and that's something we might consider for the LE-CODE, but after talking about that with Wiimm again, that's not something we plan on doing for Wiimmfi.



CLF78 and a couple other people wrote an open letter about the state of the community with regards to Wiimmfi, the LE-CODE, Wiimm & me in general, and so on, with a bunch of concerns. The letter is linked in the first post if you want to read it.

This thread's first post is our response to that letter, what we think about it, and what parts we'll try to improve, followed by discussion about our answers.

It's mainly useful for developers, modders, programmers, ...; I don't think many of the points in the letter are relevant for the average Wiimmfi user.

Okay, I didn't check that. That was indeed written a bit misleading, I agree with that.


As far as I know, based on 2015-level knowledge (I didn't really keep up with AltWFC much), that server was working okay-ish with like 5 people, but as soon as you actually got a large amount of people connected it slowed to a crawl and people disconnected (probably because either Python or the SQlite database was too slow). Has that been fixed since then? Might well be the case, I haven't used (or looked at) AltWFC in a long time.

Though, I'd say that writing your own servers based on AltWFC or on OpenSpy (if you don't want to use Wiimmfi) for Mario Kart Wii isn't really an efficient usage of time - I think if that is going to happen, then probably with mods like MKW-SP completely rewriting the netcode and using custom servers no longer relying on the ancient Gamespy structures. We basically "reimplemented" the WFC and the Nintend servers so that Wiimmfi would be compatible with all (or, at least, many) games.

If we would have developed servers just for Mario Kart Wii, and would have had that level of ASM / in-game knowledge in 2014 which we have today, maybe we would have gone the route of writing a new netcode and custom servers for MKW as well instead of rebuilding Gamespy.


If I understand it correctly, then that's (among a lot of other things) what's planned for MKW-SP. A new game mod / game structure that will be able to work on self-made servers with a bunch of extra functionality, too.

That's the issue I meant, yeah, but as I said, haven't really kept up with AltWFC since then so it's entirely possible that the issue is already gone (despite only having been closed by a bot for being stale, not because someone confirmed it was fixed).

What kind of copyrighted material do you think the LE-CODE contains?
Maybe they could take down CTGP, I don't know if they bundle any Nintendo stuff. But the LE-CODE doesn't contain any code or assets that are copyrighted by Nintendo; and neither does Wiimmfi. Don't know about the laws in other countries, but German law (which is where both Wiimm and me live) explicitly allows you to develop custom servers if the original ones are gone.