User talk:Wiimm

Archive

Old talk is archived at User talk:Wiimm/Archive.
If you want to talk about Wiimmfi, then use User talk:Wiimm/Wiimmfi.

Please continue talk here.

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 Leseratte (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)

@kHacker35000vr:

• You wrote: "More and more technical pages are altered for LE-CODE exclusive features". That is not true! True is, that there are some pages that describes the technical aspects of LE-CODE and related tutorials. And true is, that some articles contains hints about LE-CODE solutions and these hints are marked by a logo to make it clear, that it is a LE-CODE solution. I don't see any disadvantage to give much info as possible about LE-CODE. Btw, there are more pages describing the network protocol. And they additional info is added since 6 years until now. I think it is better an author gives a complete info instead that others must analyse it step by step.

• About source: When will you release the source of your KMP tool? You demand things that you don't want to fulfill yourself.

• About broken KMP tools: From the beginning my tools accept all params, read them and stores them. They did it, even if the meaning is unknown. Smart functions, that override params automatically can be enabled or disabled. So padding's and also unknown values of the files headers keeps unchanged, if an editor does not change them explicitly. This is an absolutely common procedure when editing binary data. If a tool overwrites some data for no reason, it will not work correctly. Nevertheless, I did not attack any KMP tool author, I simply asked to correct this error. The implementation would simply be nice and sensible.

• About cheats: When we developed LE-CODE and the SZS tools, 1 important goal was always, that standard cheat codes can be used together with LE-CODE. In the years implemented different things, to allow easy cheat import. The whole concept is, to allow cheat code to modify the game as usual, and all contlled by simple options:
  • Cheats can be integrated into main.dol by my tools. Option --add-section do it for you.
  • Large cheat blocks are moved to the end of the memory (internal pointers are edited for this). It is done automatically, if the cheat block is to large. Option --move-gct force it.
  • My tools add the classic cheat code interpreter automatically if needed.
  • I wrote an internal cheat code interpreter for some standard (internal) cheat codes to allow free and independent usage of the classic cheat code interpreter.
  • Using cheat codes provided by USB-Loader and other game loaders are possible.

• About memory usage: LE-CODE must reside at any memory place. So we (mainly Leseratte) searched for possible places and we found a block, the is not used after loading staticr.rel. This memory place is optimal, because it has a fixed memory address and is until today never used and never claimed by any other custom project. So we claimed to avoid potential conflicts.

• You wrote: "You're basically creating a monopoly with the way things are going right now, intended or not." That's true, but only because no other tries to implement a code extender. And is it really a monopoly? We have LE-CODE, CT-CODE (open source since >6 years) and CTGP. So there are 3 code extenders.

• Some final notes: Since the beginning of this Wiiki, I defined file formats and described it in this wiki. And I think it is good. We spent many time in the development and testing of LE-CODE and my SZS Tools as supporter. If you don't like LE-CODE, don't use it. Feel free to create an own code extender and extend your KMP tool as supporter. Then I am really amazed that now that everything has been implemented and documented, it is criticized. And strictly speaking, I am amazed that the documentation is criticized at all. Because I think it's good if all aspects of Mario Kart Wii are documented in this wiki, and this includes LE-CODE. We accept critics and feature request. So if you tell me, you need a cheat code, that doesn't work with LE-CODE, we would check it. We had some requests and implemented it (e.g. support of mushroom kart).

-- Wiimm (talk) 09:36, 6 March 2020 (UTC)

Ok, I understand the memory part. It wasn't really that huge a problem to me, it's more the lack of documentation because it is the easiest way to append cheats to the bin.

And yes, I am quite late with this critism, but that is because I assumed since the very beginning that LE-CODE was going to be an open code loader (not open source per se, just a way to add functionality to the game). And that's exactly what I am asking for right now, nothing else. Ct-code and CTGP only have a minimal presence on this wiki, so I don't think it's fair to compare them with LE-CODE.

Personally I think that editors belong in a different category with regards to open source, but I see where you are coming from. The source code for the KMP Mod would have been made public years ago - the moment I dropped the project - if the code was actually decent, but right now even I can't make sense of what's going on. And personally I think open source code should at least be understandable for everyone. I think you would understand my decision to not make it public if you see the code, it's also the reason that I have not made a new release to support LE-CODE features. Which I actually intended to add.

And yes, making an own LE-CODE is a possibility, but what is there to gain? It would result in the exact opposite of what I think is best for the community. I still think LE-CODE would be a great general standard for everyone, and for that reason alone I do not mind the wiki edits at all. I have said it above; the modding branch of the community is a mess, and an open standard could really help it get on its feet. For me personally there is nothing to gain, I could work around any possible limitation if I have to, but many others aren't as skilled to do so, they could really benefit from it. The mushroom kart assembly was provided by me, so I know all about it, but I probably won't be tempted to make such request again. I have another code nearing completion for a specific track, but my plan right now is to release it together with the track so everyone can implement it if they wanted to. It's just not the most ideal solution.

--kHacker35000vr (talk) 11:53, 6 March 2020 (UTC)

I understand your position, even if I not agree most of them. But this is life and ok for me. So it's a good time to close this discussion and remember it in the next decisions.

You can always ask for support, even after this discussion. I'm not resentful.

Another point: If you give me the sources of KMP Modifier, then I can try to change it. It's clear that I keep the source private. A rejection is ok for me.

-- Wiimm (talk) 16:35, 6 March 2020 (UTC)

Just to give a good example; the code. And just to give an impression of the difficulties a closed source LE-Code may bring to distribution creators: if they want to add their own code, including complicated features with multiple hooks throughout the game and maybe data access that LE-Code uses or has completely replaced, they will have to be very careful to not break anything LE-Code does, and because there is no open source repository nor decent documentation about what it does, this can be a true challenge for something that is otherwise very straightforward in vanilla Mario Kart Wii. I have checked all documentation carefully, and could not find a single way to turn off certain features. It's either all or nothing. I'd love to see a thriving coding community where all noses are pointing in the same direction, and these huge limitations of LE-Code really prevent anyone from making great mods without having to lose the most important features it has to offer. All distribution authors are forced to release all the tracks, then why is it no problem to keep this de facto standard completely private? I found that even the loader is obfuscated assembly code. What's wrong with helping other modders to work with it, rather than against it?

--kHacker35000vr (talk) 13:10, 5 April 2020 (UTC)

Just a few things to add to this:

• "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." CT-Code did a lot less than LE-Code, it had a more focused set of features so people had little reason to want to change it. LE-Code, on the other hand, aims to provide many ways for ct creators to enhance there tracks, so I'd argue it's much more likely for people to want to help create these kinds of features. Also, Nameless is currently working on a battle expansion mod built off of CT-Code, so there are still people who are modifying it, and I'm sure they would rather have based it off of LE-Code's more sophisticated game patching system if it was possible for them.
• "I talked to MrBean and I'm willing to give him the full source code if he wants to integrate the features into CTGP" The fact that Bean would need the source code to integrate it is showing Kevin's point exactly, if we want to use our own code loading systems then it becomes harder to integrate LE-Code. Multiple C/C++ code patching systems exist or are in development for the game (CTGP-R's, Pokey, Dossun, Kuribo), so why is only one of them (and a private one, at that) allowed the help to implement LE-Code?
• "I am by far not the only person who does closed-source stuff" Keeping everything private is far too common in the coding side of the community, and it really harms it. Symbol maps are generally kept private, structure information is rarely shared; everyone keeping this mindset will never improve things, why not be one of the people to help finally change this?

-- Seeky (talk) 14:10, 14 April 2020 (UTC)

3 Inquiries

Hi Wiimm, I have three questions I would like to ask you about.

For one, is there a public command in WSZST to get the recommended slot for tracks like you use in your CT Database?

Secondly, is there another public command in WSZST or WIMGT to parse the ordered bmgs to create cup icons like you use for your Intermezzos and MKFun?

Finally, I have a suggestion for a possible LE-CODE feature. As I'm sure you know, inside the Common.szs there are BSP files for each kart that change the position of the tires, but it affects all karts. My idea is for not only it to read

ma-kart.bsp

but also

ma-kart_mr.bsp

In that case, the BSP file would only affect Mario's Classic Dragster, and not all of them. It would really make people like me who have a lot of custom karts installed's lives a lot easier and make things overall look better.

Thanks, Trainiax/SwampyGator (talk) 17:33, 16 March 2020 (UTC)

»wszst slot *.szs« lists a slot analysis for each tracks. »wszst check ...« prints hints about slots.

»wszst copy ...« knows option --patch to concat images together.

I put the idea with ma-kart_mr.bsp in out bug tacker.

-- Wiimm (talk) 05:27, 20 March 2020 (UTC)

Good to hear about the latter two but I think you misunderstood my first point. When a track goes through your database, you assign a recommended slot outside of the troublesome ones, for example Atlas's RMX Mario Circuit 1 got assigned T81 (SNES Mario Circuit 3). Do you do this manually or is there a command for that? Trainiax/SwampyGator (talk) 14:21, 20 March 2020 (UTC)

That is done manually. Wiimm does play every track that he adds to his archive, and then decides on a slot to use for this track (or he takes the recommended slot if the author chose one). There is no automatic system to pick a slot, other than a couple checks to see if it's a special track that requires one of the few specific slots. -- Leseratte (talk) 15:24, 20 March 2020 (UTC)

The download filename of RMX Mario Circuit 1 is old_mario_sfc. So I see it as recommendation for slot 8.1. And rarely I override it. -- Wiimm (talk) 16:12, 20 March 2020 (UTC)

Something odd with vX MKW Hack Pack's CT page

So as you know, KantoEpic and I have been working together to get all MKW Hack Pack versions on your CT database, as well as all the changed track versions updated. So, I went through now that vX is out and was going to begin putting those tracks into the database (through Talk:Intermezzo), and I had him check the versions like I usually do. However, he said that the first four tracks are identical to versions of the track already on the database. I don't know if it's something wrong with the way "wszst distrib ." normalized the tracks, but he says that they are identical in content. I'll attach the four tracks that seem to be having this issue.

• Abandoned Boardwalk (identical to v1.01)
• Abe Abbott Raceway (identical to RC4)
• Alpha Desert Valley (identical to v1.3)
• Alphina (identical to RC2.1)

Speaking of which, I also had an idea about the distrib function. Would it be possible to check if there is a lecode-XXX.bin file in the folder and then try to populate the slot IDs based on the LE-CODE file and the track file names?

Sorry for constantly clogging up your talk page, Trainiax/SwampyGator (talk) 16:46, 31 March 2020 (UTC)

I'll verify it in the next days. -- Wiimm (talk) 18:46, 31 March 2020 (UTC)

It's a bug in processing SHA1 aliases. It depends on the order of scanning files. Not fixed yet. -- Wiimm (talk) 10:27, 4 April 2020 (UTC)

No Bug!

To eliminate duplicates I normalize the files. And I store the original SHA1 as alias of the normalized SHA1. So you can search and link differing duplicates by SHA1. For this step (to store the relation) I have to scan the original file. And now after scanning the bug is gone [1]. Now I'll download vX and scan all files. For this step no track names are needed.

-- Wiimm (talk) 14:15, 4 April 2020 (UTC)

Ain't that convenient. --KantoEpic (talk) 23:52, 4 April 2020 (UTC)

I scanned all 512 tracks of vX and many files are known now. For the unsolved tracks there are many updates in the wiki, that I hadn't noticed before. This needs more time than usual. I'll go through the list in the next days. At the moment 41 tracks are waiting. -- Wiimm (talk) 11:54, 5 April 2020 (UTC)

Award Ceremony Crash

Everything is working except for an unknown crash in the award ceremony. I replaced all the files in the Award.szs menu like I should for LE-CODE. Was hoping you could give me some pointers :P Also, I have another code for the 200cc on my talk page for you, and some other info. JoshuaMK (talk) 19:17, 3 April 2020 (UTC)

Have you used build 16 where we fixed this or a similar bug? -- Wiimm (talk) 11:55, 5 April 2020 (UTC)

Yes, each time LE-CODE has had its updates, I've properly updated the files for my script. It is currently using build 16 of LE-CODE. Here is the decompiled menu being used for the script: https://drive.google.com/open?id=1dwnbZ57vjYc81WTlUVyn9g6vz7zhFvjH JoshuaMK (talk) 18:31, 5 April 2020 (UTC)

I played a grand prix in 150cc with Intermezzo and saw the ceremony without any issues. Do you talk about this case? -- Wiimm (talk) 20:16, 5 April 2020 (UTC)

Yes, I am talking about that. Was this with my menu I sent you? I will have to check it again JoshuaMK (talk) 00:55, 6 April 2020 (UTC)

I used your Award.szs in a PAL version of Intermezzo. Have you renamed winningrun_demo.szs to 037.szs? -- Wiimm (talk) 05:51, 6 April 2020 (UTC)

I think that is the issue. I am updating my script to handle it and the other special SZS files. I will update with results. JoshuaMK (talk) 07:30, 9 April 2020 (UTC)

I won't know for sure, due to Hack Pack not having anymore updates for the next few months, but I consider this as resolved as it was an issue in the script that is now fixed. Thank you for your time! JoshuaMK (talk) 03:43, 13 April 2020 (UTC)

Possible LE-CODE Error

Hello again Wiimm, in my latest version of Trainiax's Test Distributions I used the slot feature to allow for reusing the same slot for multiple appearances of the same track in order to reduce filesize. It worked perfectly in the builder, except that the header tracks don't act as a header, it instead just loaded the header. I have attached the LE-CODE definition file here, if you could take a look whenever you get a chance. Trainiax/SwampyGator (talk) 14:41, 6 April 2020 (UTC)

This is the issue: "S 0x45! 0x59! 0x5a! 0x5b! 0x59! 0x5a! 0x5b!" Header+Random files must be in order without holes. So you can't have both: head+random and distributing tracks in multi slots (with some exceptions). Anyway, the concept of ALIAS is planned therefor. My Tools can manage it (hidden feature), but LE-CODE not yet. -- Wiimm (talk) 17:15, 6 April 2020 (UTC)

I see. Thank you. Trainiax/SwampyGator (talk) 18:42, 6 April 2020 (UTC)

btw, I use hard links to save space. -- Wiimm (talk) 19:25, 6 April 2020 (UTC)

An Inquiry Regarding BSP Files

Hi Wiimm, I noticed that you were interested in implementing Trainiax's idea of character specific BSP files and as a custom character and kart creator who has made many different kart mods with BSP files, I am overjoyed about these news. I have an inquiry about that: since BSP files cannot be edited in CTGP, is there way for those files to be called from another folder or source that is not within the Common.szs file? Or would that be too hard-coded for that to be possible?

Thank you, --TravixMan (talk) 04:27, 7 April 2020 (UTC)

That would probably be possible (same as LE-CODE already does it for the Objflow.bin), but that wouldn't help with CTGP unless they implement this feature, too. -- Leseratte (talk) 05:04, 7 April 2020 (UTC)

Is it possible to change the spawning position of the EnvKarehaUp object?

Hi Wiimm, while experimenting with the EnvKarehaUp object, I noticed that where the leaf effect appears is not reliant on the position, or other settings off the AREA that is linked to it within the KMP, as no matter what, the object will be at its original co-ordinates from Maple Treeway. Is this spawn point for EnvKarehaUp able to be modified at all within the file for the course? Or is it a behavior that has been set somewhere else in the code, or maybe even something else? --Unsigned comment by TAS Rhys (talk).

I don't know it. I never analyzed the details of PEnvKarehaUp. -- Wiimm (talk) 06:48, 24 April 2020 (UTC)

Wiimmfi Support

Hey Wiimm! Da ich brerits wisse, dass du deutsch bist, schreib ich dies auch einfach mal in deutsch. Ich habe vor ein paar Tagen meine erste CT distribution erstellt. Leider habe ich weder vom CT- noch vom LE-Code Ahnung, weshalb sie nur 32 Strecken beinhaltet. Wie genau bekomme ich mehr Cups hinzu? Ich bin ein Neuling in der MKWii Modding Scene (zumindest vom eigene Mods erstellen), weshalb ich nicht weiß, an wen ich mich sonst wenden könnte. Außerdem wollte ich noch fragen, wie das mit dem Wiimmfi Support funktioniert. --SitBar (talk) 11:52, 30 April 2020 (UTC)

Für den LE-CODE gibt es hier im Wiki eine Anleitung, wie man das in eine eigene Distribution einbaut: LE-CODE/Distribution_Tutorial. Ähnliche Anleitungen für den CT-CODE finde ich allerdings gerade nicht. Im LE-CODE ist Wiimmfi eingebaut, funktioniert also automatisch. Wenn du dann eine eigene Region für deine Distribution haben möchtest, kannst du hier - https://wiimmfi.de/reg-apply - eine Region beantragen, dann wird dir eine zugeteilt die du dann in deiner Distribution benutzen kannst. Wenn du stattdessen eine Distribution mit Wiimmfi-, aber ohne LE-CODE bauen willst, kannst du einfach den Parameter "--wiimmfi" von WSZST nutzen, um main.dol und StaticR.rel für Wiimmfi zu patchen. Wenn du den LE-CODE nutzt, dann ist Wiimmfi da schon mit drin. -- Leseratte (talk) 12:12, 30 April 2020 (UTC)

StaticR.rel issues when adding more game modes

Hi, I have heard that CuberHax is having an issue with the StaticR.rel tool when trying to add more game modes to Cuberluigi CT Pack with Countdown Mode.

"It's about trying to add Countdown 2.0. The first time I tried to patch it into the main.dol a while ago, it didn't work, and then I tried again, and it worked. I then tried to patch it into the main.dol for other gamemodes with Countdown, and that didn't work. I tried again, But no avail. If adding a specific section only works once in a while, it might be a bug in Wiimms StaticR Tool that should be looked into" CuberHax said. -- Octanevinny (talk) 5:40am, 5 May 2020 (UTC)

I need the base (source) files and the used command for analysis. -- Wiimm (talk) 09:20, 5 May 2020 (UTC)

CT_Code can't read in other regions.

Hello, I'm trying to make my CT pack work with other regions (my region is PAL) but when I tested it with someone who has a NTSC copy this happens as shown from image. It's the splash screen you make during CT_Code that occurs when something's wrong.

media:CT Code malfunction.png

Kind Regards, MiniGeek2000

You have to patch main.dol and staticr.rel for each region separately. Anyway, I recommend LE-CODE instead of CT-CODE. -- Wiimm (talk) 17:01, 6 May 2020 (UTC)

Use command »wstrt ana main.dol staticR.rel« to analyze the modified files. -- Wiimm (talk) 17:05, 6 May 2020 (UTC)

How do I patch main.dol and staticr.rel for each region? --MiniGeek2000 (talk) 08:50, 22 May 2020 (UTC)

wstrt patch --region 12345 main.dol staticr.rel

-- Wiimm (talk) 16:25, 23 May 2020 (UTC)

Is it normal if it looks something like this after patching it to NTSC?

media:Main.dol patching.png

--MiniGeek2000 (talk) 07:45, 24 May 2020 (UTC)

Yes, But you have not patched the region (missing: Value of 'sdkver' changed from '001000' to 'xxx'.) -- Wiimm (talk) 12:11, 24 May 2020 (UTC)

Track Missing WBZ Id

Hello, I'm just letting you know that my custom track, Twilight Town, has not gotten a wbz id yet despite being released on th 26th of June. Due to the track being made for the Custom Track Jam, it was not released publicly until the 29th, however, the news template states that it was released on the 26th. When looking through the "recent changes" tab, I noticed you added wbz ids for the tracks released on the 29th, however, Twilight Town has not gotten one yet. I was just letting you know in case you missed it. --DryBowser; "Blue Loop is the Fisher Price: My First Loop Track of Loop Tracks." (talk) 20:56, 1 July 2020 (UTC)

Most of the time I only find new tracks via the latest news. And the first version of your track was added late (too late). So this hint is useful. Then I was absent for 5 days, so your route will be inserted today. -- Wiimm (talk) 08:47, 7 July 2020 (UTC)

Automated height correction with wkmpt

Does wkmpt have the functionality to automatically calculate the Y-value for all points in a KMP. If it does would you be able to put an example here please. I'm asking because MagicY only runs on python 2.7 and because I program in python my PC's running the latest version of python meaning I have to run KMP cloud and MagicY in a virtual machine with python 2.7 installed which is really inconvenient so I'd much rather use your tools. Also HackerCop's Track Pack needs updating on your CT archive as the latest version is v2.1 but on your CT archive it's v1.0. Thanks --HackerCop ❯❯❯ Talk 10:09, 18 July 2020 (UTC)

You can enable it for each section and for single points. If you create a text version of the KMP, the feature is explained in the section header, example:

	@KCL-FALL-WIDTH     =   0        # set to a value >0 (e.g. 200) to enable KCL falling
	@KCL-FALL-PRE-ADD   =   0        # add this height or vector before falling
	@KCL-FALL-POST-ADD  =   0        # add this height or vector after success
	@KCL-FALL-TYPES     = KCL$DRIVE  # bit field of recognized KCL types
		# Best values are:
		#  - KCL$BORDER: All KCL types except effects.
		#  - KCL$DRIVE:  All driveable types like road, boost, ramp, water, ...

	...

	# Column 'flag' is optional and usually only used internally.
	# Syntax:   FLAGS_STRING   or   '(' EXPRESSION ')'
	#   F (F$FALL): Point can be used for FALL-DOWN functionality.
	#   S (F$SNAP): Point can be used for SNAP functionality (ignored by ITPT).
	#   J (F$JGPT): Point can be used for automatic JGPT creation.
	# Remove the letter or replace it by '-' to disable a feature.
	# If the column is missed, all options are enabled by default.

More details: https://szs.wiimm.de/doc/kmp/fall

-- Wiimm (talk) 12:08, 19 July 2020 (UTC)

Thanks for your help. I was able to get height correction working by changing the values of @KCL-FALL-WIDTH and @KCL-FALL-PRE-ADD. No more slow MagicY then! --HackerCop ❯❯❯ Talk 18:11, 20 July 2020 (UTC)

Wrong number of laps in v1.2 and v1.3 versions of Sunset Cliffs in wiimms CT archive.

Please look at: talk:Sunset Cliffs -- Octanevinny (talk) 5:21, 22 July 2020 (UTC)