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 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.

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