User talk:Wiimm

LE-CODE Track Updates

Although I've been clearly aware that changing version numbers isn't an ideal thing on the Custom Mario Kart Wiiki, I feel like the track updates that only function properly with LE-CODE should be changed. It seems misleading (at least to me) that they're not alternative updates, since, like I said, they only do their purpose when using LE-CODE. What are your thoughts on the matter? --KantoEpic (talk) 01:44, 12 February 2020 (UTC)

I think we talk mainly about Lavaflow Volcano. "alt" means alternative. And with this suffix I think, that something in the gameplay changed like other objects, other walls other other models. Then we have the suffix "le". This is a special case of "alt", that is designed for LE-CODE only (not really usable with standard code). But the Lavaflow Volcano update fixes a bug (only if using LE-CODE). And for such fix updated incrementing the the version number or adding ".fix", ".hotfix" if ".hf" is usual. Jasperr hasn't updated the track for 10 months and the bug is still there. So increasing the version is in my opinion the best. Declaring is as alternative version is wrong here. So ".fix" is a good middle way. -- Wiimm (talk) 06:18, 12 February 2020 (UTC)

Another point: Changing the version number immediately after publishing isn't problematic. The problem is to change it after months or years, if the there a copies in the world (distributions, other downloading portals). Then we have different version numbers for for the same track. -- Wiimm (talk) 06:21, 12 February 2020 (UTC)

Even though, yes, the disappearing item bug was fixed thanks to the LEX file, you will still experience the bug outside of an LE-CODE-based distribution. If I'm going to be honest, a page like MP9 Toad Road handles its recent LE-CODE-only track update just fine. Its download link is in the Misc-Info box like an alternative update, and it doesn't replace the previous version. Unless a track update that includes LE-CODE-only fixes comes with other fixes and/or improvements, I don't see the reason for incrementing a current version number. --KantoEpic (talk) 07:06, 12 February 2020 (UTC)

LEX:HIPT

Hi, just wondering if you knew when having a HIPT section in a LEX file, the sound effect for changing positions still happens when the position icon isn't showing. Trainiax/SwampyGator (talk) 03:42, 16 February 2020 (UTC)

Yes, I know. Its more complicated to suppress the sound effects. -- Wiimm (talk) 07:45, 16 February 2020 (UTC)

Oh, that's interesting. Didn't even think about testing this, I always play without sound. I'll look into that for the next release. -- Leseratte (talk) 08:04, 16 February 2020 (UTC)

I was also thinking about the same thing, but for the versus rating (VR). Not only having it hidden online entirely but also disabling the vr gain/lose sound as well. Huili (talk) 03:48, 18 February 2020 (UTC)

Aquatropolis fail?

Just curious, what about the Aquatropolis update had you mark it as a fail? Trainiax/SwampyGator (talk) 20:38, 17 February 2020 (UTC)

No chance to cross the first abyss -- Wiimm (talk) 08:52, 18 February 2020 (UTC)

LE-CODE Cup BMG IDs

So I never took the time until now to look around for it, and I can't find where cup names are defined (To be clear, I have found where the first 8 cup's names are defined, as well as the 2 battle cups, but I can't find anything for the custom cups). I would appreciate being enlightened as to where this is at within the BMG files (I assume Common.bmg), or if it is even a thing at all! Thanks in advance. JoshuaMK (talk) 05:33, 21 February 2020 (UTC)

Cups in LE-CODE have no name. The name (blue) and number (red) you see on the cup icons in Wiimms MKW Fun is just the cup icon. The cup name is empty for all cups, and that cannot be changed with BMG entries. -- Leseratte (talk) 13:36, 21 February 2020 (UTC)

Thank you for the info. Yes I already understood that those were cup icons, so I guess no cup names then! It's nothing big of a problem that LE-CODE doesn't support cup name entries. JoshuaMK (talk) 18:07, 21 February 2020 (UTC)

LE-CODE Crash While Scrolling Cups

We are having an unknown crash while scrolling through cups in LE-CODE, which can be seen here: https://gyazo.com/d95e39e768dfd2d4c6e7bf68b0fd0134 I have the icons encoded as CMPR, and it is a 128 by 128*n tpl file, with n being the number of cups. Please help where you can, all info is appreciated! :) JoshuaMK (talk) 07:24, 25 February 2020 (UTC)

The crash is outside LE-CODE. So analysis is a job for Leseratte. Anyway, please send me MenuSingle.szs. -- Wiimm (talk) 17:16, 25 February 2020 (UTC)

The crash happens within the method __THPHuffDecodeDCTCompY, so I'd assume the game doesn't like the THP files you are using. -- Leseratte (talk) 17:19, 25 February 2020 (UTC)

In this case, I don't need MenuSingle.szs. -- Wiimm (talk) 17:55, 25 February 2020 (UTC)

Cup Videos

If I may also ask, how do we get rid of the THP video that plays behind the Track Selection? So it appears like in MKW Fun and CTGP? JoshuaMK (talk) 07:28, 25 February 2020 (UTC)

I use a special empty video (1MB) and link it to all video files of files/thp/course. You can get it from MKW-Fun or Intermezzo. -- Wiimm (talk) 17:16, 25 February 2020 (UTC)

Added info + download to tutorial. -- Wiimm (talk) 17:55, 25 February 2020 (UTC)

WSTRT Fails When Patching

Sorry about the persistent questions, but I feel this is quite serious. For some reason as of today WSTRT always fails to patch an input main.dol/StaticR.rel file. I don't know why this is. I've tried uninstalling and then reinstalling it, I've restarted my laptop, and I've tried lots of variations and such. It just keeps failing anyway.

Here is an error message I get when I run it:

wstrt patch main.dol --clean-dol --add-lecode --wiimmfi --region 20037 --gct-move=ON --add-section RMCE93.gct --DEST ./patched/main.dol
PATCH main.dol
>>>> GCT DATA/GROW, 14a0 bytes
    2 [main] wstrt 1922 cygwin_exception::open_stackdumpfile: Dumping stack trace to wstrt.exe.stackdump

And here is the stackdump file resulting from the error above:

Exception: STATUS_ACCESS_VIOLATION at eip=61161F88
eax=8008C4E8 ebx=C3633338 ecx=30D87D08 edx=00000000 esi=800A0000 edi=800A0000
ebp=00B75F18 esp=00B75F0C program=C:\Program Files (x86)\Wiimm\SZS\wstrt.exe, pid 1922, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
00B75F18  61161F88 (8008C0E8, 8008C0E8, C3633338, 00000000)

Thanks for all the help :P JoshuaMK (talk) 01:44, 26 February 2020 (UTC)

EDIT: It seems to only happen when patching the input main.dol file with a GCT, as long as I exclude the GCT patch, it works. But this still doesn't help me, although the specific information will probably be very helpful to you :P JoshuaMK (talk) 01:57, 26 February 2020 (UTC)

I need the files main.dol and RMCE93.gct of your example to analyse the error. -- Wiimm (talk) 12:01, 26 February 2020 (UTC)

I looked at the GCT last night and as it turns out somehow Huili managed to fill up almost half of the GCT with garbage data. I'm sure this would throw WSTRT off since my own GCT (which ofc is proper since I wrote the structure by hand to make sure it was valid) works perfectly with WSTRT, having no errors. Sorry for the inconvenience! :P JoshuaMK (talk) 17:00, 26 February 2020 (UTC)

EDIT: I was looking at Star's Speedometer code, not garbage data :P This code doesn't work with WSTRT. I am wondering what other codes potentially don't work too :/ JoshuaMK (talk) 17:30, 26 February 2020 (UTC)

EDIT2: Forgot the link to the files, here you go: https://drive.google.com/open?id=1eHXE01IN9fKaVFjdKxeacx4ejpMcpfJm JoshuaMK (talk) 17:53, 26 February 2020 (UTC)

Theoretical all chat codes should work. So I don't know why it does not work. maybe an issue with size and/or --gct-move? And a first test with your files using Linux doesn't crash. -- Wiimm (talk) 21:46, 26 February 2020 (UTC)

Yes, it is very likely Windows only. When I run the simplest command: wstrt patch main.dol --add-section RMCE01.gct

It still doesn't work. I suggest an update to the Windows version of WSTRT if possible. JoshuaMK (talk) 21:50, 26 February 2020 (UTC)

I found the bug. It is a combination of conditions.

First, an ASM cheat with invalid length must exists. The tools analyse the data for different reasons (especially old reasons to allow cheat code split prior --gct-move was implemented).
The length must be > cheat data size.
Running Cygwin, because it crashes for memmove() when source and dest are identical, and size is negative. Linux does simple nothing.

I fixed it. I will also try to update Cygwin. But the last time, there were many alignment errors while loading Cygwin libs. And then I go back to the old system.

-- Wiimm (talk) 14:52, 28 February 2020 (UTC)

Where can I find Star's Speedometer code -- Wiimm (talk) 18:11, 28 February 2020 (UTC)

Star's Speedometer found and it works with new tool. -- Wiimm (talk) 18:53, 28 February 2020 (UTC)

Nice to hear it is fixed! Glad I reported the bug before other people had any issues :) JoshuaMK (talk) 04:54, 29 February 2020 (UTC)

About the current state of the wiki and LE-CODE

Hi, in the first few months I was a huge fan of the le-code project you and Leseratte are working on. It seemed like a great way to have a public code base where we can add features to without having to worry about the limitations of Mario kart Wii, while keeping an uniform standard. However, now we are one year further, I'm not that enthousiastic anymore. Sure, it's still a great way for distribution makers to make distributions, but it's not more than that. Nobody has any say in what is getting added or not, nobody has any say in how things are loaded and nobody has any say in how native Mario Kart Wii formats are altered to support this closed source project.

The wiki starts becoming one big shameless advertisement for your code loader, and that saddens me. You can't just make CT creators, distribution creators and even software developers change how they have to create their content just because you decided that's how it's going to work. All the struggle Joshua is facing above just confirms it, it should not be next to impossible to add own alterations to MKW if LE-CODE is running as well.

I still appreciate all the hard work, I really do, and I still see a lot of potential in this project.There is just one thing I'm asking for: make it open source. Allow distribution creators to choose how they are going to implement it, don't just claim a huge block in memory as your own and say that that is forbidden territory if you still want Wiimmfi, but keep things open. Either that, or do not advertise it as a de facto standard that it isn't.

--kHacker35000vr (talk) 11:56, 5 March 2020 (UTC)

I don't see it like you. In general, all LE-CODE extension are designed as additional features for the track authors. If not running LE-CODE, the track will function. So LE-CODE changes only the default behavior, that can be overridden by cheat codes (same as Original MKW). Example extended presence flags: An object can be enabled/disabled by a new condition. When I defined it, I made sure that you can determine for each object whether it works in the standard code. So a track creator can decide by its own, to use the features of LE-CODE, or only some of them. Incidentally, most of the properties eliminate errors that have arisen due to the creativity of the creators. Examples are scaled Gomba and the enlargement of the item positions online.

You are right on one point: I use the wiki intensively to draw attention to LE-CODE. I've always done that: In the beginning it was the videos from CT until others created the videos. Technical innovations such as quadrilaterals for checkpoints I also advertised in similar way. The wiki is full of my promotions, of which I have no personal advantage. People should just be made aware of what is still possible.

One kind of advertising are the logos. I added them to make visually clean, that this is an extension not supported by standard code.

Open source is a different topic and is actually independent of the other things. Bean and Leseratte work closely together here. And to my knowledge, they are the only ones who know the internals of MKW at the high level. They also implemented the Wiimmfi patcher that protects the Wii for destructive attacks while playing online. I myself have no idea of the interior details and always ask for support. It doesn't help that I have access (can read and write) to the sources. I concentrate more on the algorithmic work. Ultimately, it is a decision by the bookworm (and possibly Bean, who contributed the code). People can always ask for features.

-- Wiimm (talk) 14:39, 5 March 2020 (UTC)

A few comments about that:

- All file format changes we did were documented in the wiki during development, and we talked to multiple track creators and to MrBean to ask for comments or improvements prior to finalizing the formats. Also, it's a wiki. If you have concerns or want to add comments, write on the talk pages - that's one of the reasons why we are adding this kind of information to the Wiki. For example, we started working on the presence flag definition on January 1st - and announced that in the wiiki news on January 10th, and nobody bothered to read it and leave comments on things to improve.

- Yeah, the Wiki is becoming "advertisement" for the code loader. Same as it is advertisement for all the CT tracks, custom distributions, and tools that are provided here. What's the difference?

- I am not excluding anyone from adding these features to another distribution. Everyone can use the released LE-CODE binaries, I talked to MrBean and I'm willing to give him the full source code if he wants to integrate the features into CTGP (so far he didn't, probably because he was busy with his 24p mod), I did provide parts of the code to people who asked me about how I implemented a particular code. And if anyone has a question how a particular feature is implemented, I'll gladly share that part. I just do not want to release the full source code of the project that I wrote, and that is my right.

- I am by far not the only person who does closed-source stuff. Lots and lots of the tools on the wiki - excluding Wiimms ISO and SZS tools - are closed-source, some track creators even use private tools they don't publish. CTGP is closed-source as well - and that can't even be integrated into other distributions, so it's even more closed.

- There are certain parts of code in the LE-CODE and in the Wiimmfi update (more so in the Wiimmfi update, but still some in LE-CODE, too) that are security related, which we just don't want to get public.

- The issue joshua was facing is that Wiimms SZS tools had a bug that caused it to crash when it occurs certain, rarely used GCT cheat code forms. That has absolutely nothing to do with LE-CODE. LE-CODE and its loader don't prevent you from loading additional mods at all. You can add your own cheat codes just fine, next to the LE-CODE loader in the 80001800 range, or at the end of MEM1, like it was always done in the past. LE-CODE doesn't change anything about that.

- We are not forcing CT creators to do anything. But for CT creators who do want to use certain new features in LE-CODE distributions, we now give them the ability to do so. You are free to ignore LE-CODE and continue creating tracks like you used to. We are also not forcing distribution creators to do anything different. You are free to build a ct-code distribution. We also aren't forcing tool authors to change anything - we are encouraging them to adhere to the Nintendo file format, which (incidentally) they didn't in the past. Old versions of Wiimms SZS tools, from before we even had the idea of LE-CODE, work fine with LE-CODE - because they fully adhere to the standard. We are merely adding onto the standard, in a compatible way. That's why LE-CODE tracks still work in the vanilla game, and why old tools of Wiimm still work with these tracks. Other tools just don't work properly because they are buggy, and that's what we asked the creators to fix.

- Also, the ct-code has now been open-source for about 6 years. How many code changes have been done to that in the meantime, from people other than Bean, Chadderz, Wiimm or me? One small bugfix in 2015, that was it. It's not like there would be huge amounts of developers contibuting a bunch of content to LE-CODE if it were open-source.

- We are not claiming a bunch of code as our territory if you want Wiimmfi. You are perfectly able to build CT distributions for Wiimmfi without LE-CODE. But when you want to load LE-CODE, it's going to need space in memory, same as with any other mod. That has nothing to do with claiming "forbidden territory".

--

Leseratte (talk) 16:33, 5 March 2020 (UTC)

@Wiimm: I think you're underestimating how much talent there is in this community, there are plenty of people with decent assembly/coding skills and there absolutely are more people who know a lot about the fundamentals of the game, or at least have the skill to learn about it. The reason I have started this thread is because of that; LE-CODE is advertised as a code loader. I really thought it would allow many more programmers to make mods with it. However, the exact opposite is happening now: it has become harder to make mods.

Furthermore, I will try to explain myself the best I can, forgive any ambiguities. There are very clear differences between adding your custom track or mod to a list and making a page for it and basically taking over the complete technical side of the wiki. More and more technical pages are altered for LE-CODE exclusive features, which basically means the information about the file format is not entirely correct anymore. It really is not the same as an isolated page for a ct or just adding a tool to a tutorial.

About the source, I do not expect you to make everything open source, there will always be things that are completely irrelevant for other coders that want to pick certain features. However, like I said above, there are many talented coders in this community who might want to take x and y from LE-CODE, but without having to do z, or want to implement z in a different way. And they can't, it's all or nothing and without the necessary time and reverse engineering skills they won't be able to do anything about it. You're forcing people to use the whole pack, with everything that comes with it exactly like you have intended it to be.

In my eyes there is one major difference between the old ct-code and your adaptation, being just the way it works. ct-code added track slots, did a terrible job at it and some minor changes like lapcount. LE-CODE meanwhile comes with an amazing amount of features, of which many require custom track creators to take action in order to make use of it. It has much more potential for many branches of the community. And yes, maybe it won't see many contributions, but you'll still allow everyone who wants to work with it to take it and change it to what they want.

You're basically creating a monopoly with the way things are going right now, intended or not. And that's actually perfectly fine in my eyes, in my opinion one uniform course of the community will bring much more progress than closing things altogether like CTGP, but this is just not the way to do it. All that is communicated right now is 'LE-CODE uses memory at 0x808dd400, and somewhere after it Wiimmfi needs room, so don't use it if you want Wiimmfi'. Other than that it's very strange that Wiimmfi needs that space to function (I know the reasoning behind it, and there is something to say in favour of it) it is not communicated at all. How much room is used? How much room is there for own code? Right now the advice is to just use space used by the stack. Which is not a very nice solution in my opinion.

The tools that are not working with the new formats are not breaking that new format because they are coded in a wrong manner. They have all the right to ignore proven padding, since they are not created with changes to those fixed formats in mind. Even my recent code does nothing with that padding. So basically you are forcing them to adapt. Again; nothing wrong with that if there is one agreed upon format by the community, but a very different story if it happens behind closed doors. And I'm aware of that proposal by Wiimm for the presence flags, I even gave my own opinion about it and I will say that was a great course of action.

To finish it off; I will stay consistent, I strongly disagree with anyone who keeps tools they used private for no reason at all. I think that's nothing more than rudeness towards everyone else. All distribution creators must according to the wiki rules make sure the tracks inside them are available as well, and all tracks are basically outlawed to be modified in the worst way possible. Meanwhile it must be completely fine to alter all technical pages on the wiki to promote your own code loader without any funcitonality of it being available to the public. I just can't understand that. I do not agree with the fact that some very handy CTGP features are kept locked either. Features that really make your content stand out can be kept private, it would be very weird to ask for that to be any different, but you could really help many others by opening up what's not as important. Everything that is built comes out of a 10-year old progress of research, development and most importantly sharing. Without this wiki many things would not have happened, and this wiki too is built upon the idea that people want to share. The development branch of this community lacks any of that, very few functions are made public, almost everyone has to start from square zero and the wheel had to be reinvented many times. I have my own ideas to tackle this, have actually set some things in motion already, but I can't do it alone. It would really be a very great gift to the community if things are made more open, starting off with what probably is the largest step this community can make: one standarised base that supports custom functionality for the game.

kHacker35000vr (talk) 18:48, 5 March 2020 (UTC)

- First of all, I am not understanding your point that LE-CODE makes creating mods harder. As far as I know, the space at 808dd400 and upwards has never been used in the past by any other mod - all mods known to me either use the cheat code range (80001800) or are loaded at the end of the heap. I deliberately chose this space for both the LE-CODE and the Wiimmfi update, in order to stay compatible with as many other mods as possible. Is there any other existing mod that was using this same space that LE-CODE breaks?

- The information about file formats is still correct - every page that contains LE-CODE specific file format details is clearly marked with the LE-CODE icon and explains which parts are for the original game and which are for the LE-CODE, so we are not making the information incorrect, we merely add information.

- LE-CODE already has a couple parameters that can be set by the end user, to enable or disable some featurs (engine class mod, performance monitor, time trial, ...), and I am definitely planning to extend that so you can enable / disable more parts as you like. And as I said, if someone wants to know how a certain part works - tell me and I'll give you that part of the code (unless its about the anti-cheat or security parts for MKW-Fun).

- During the last years, since the game's release, every game mod (including CTGP!) has been using the 80001800 range, or the space at the end of MEM1 (after the stack). Nobody at all was interested in the 808dd400 range. And now that we use it for the Wiimmfi update and the LE-CODE, we are creating a monopoly? You can still use all the space you used before.

- Both the LE-CODE and the Wiimmfi update are designed for a fixed RAM address, because that makes the development *way* easier. The LE-CODE loads at the beginning of the usable space and grows towards larger adresses, and the Wiimmfi update code loads at the end of the usable space and grows towards smaller addresses. That means, if you add a bunch of code behind the LE-CODE, the wiimmfi update might overwrite it when it grows (gets more code) in the future. It simply has no fixed loading address, because it grows "backwards" when we update it. That is why I recommended people not to add data to the LE-CODE binary file, because if you add too much, the Wiimmfi update will overwrite it. And the reason for that is, in case you didn't know - both LE-CODE and the Wiimmfi update need a reasonable amount of space, and we wanted to keep supporting both cheat codes and mods to the MEM1 space, so we had to find other space.

- What is wrong with Wiimmfi & LE-CODE using that space, which nobody else bothered to use since the game's release, and now suddenly that we are using it, people complain that we use that space? Why?

- About the file formats - tools that are developed properly are supposed to load the file into a structure as-is, and store it as-is. When you load any file into an editor (not even related to MKWii), that editor is not supposed to delete data it doesn't understand. Doing so is bad design, even if you think that that data is just padding. If I have a binary file, open it in an editor, then save it without changing anything, the file should be identical. If it isn't, then that's a buggy tool. Even if people assumed certain parts were unused. And - as you mentioned yourself - the process didn't happen behind closed doors. It was open for discussion for over a month. Nobody complained about that format, so we implemented it. It probably would have been possible to work around tool issues and retain compatibility with nonconforming tools, but that would have complicated the format even more. And given that the needed change is like one line of code, we decided on not doing so. And nobody complained about that while the drafts (we did have multiple drafts for the KMP extension) were open. Would it have been better to keep the file format extensions a secret, only implement them in Wiimms tools, just to not "alter wiki pages for LE-CODE"? No, probably not.

- I understand that it might be a good thing for the community if things like the LE-CODE would become completely open-source and expandable. It isn't open-source right now. I haven't yet decided whether it'll be open-sourced in the future. I will think about that again, and about which parts can be made public and which ones I'd like to keep closed.

--

Leseratte (talk) 19:26, 5 March 2020 (UTC)