Good to see a promising open-source emulator as well (that has GamePad emulation as well...). I can tell it's developed actively, as its bugs are discussed (and solved) on IRC daily.
I'm sure this will quickly catch up with cemu as for commercial games and the extra bonus of open source and clean code make it definitely worth the wait. Until that time, all I can do is expressing my gratitude to the devs. +1'ed the OP.
I spent the last few days figuring out how to build decaf-emu, and this is what I did to be able to build it:
1) Get windows 10.
2) Get Visual Studio (enable Windows 10 SDK!)
3) Clone the github repo. (git clone https://github.com/decaf-emu/decaf-emu)
4) Init and update submodule (git submodule init && git submodule update)
5) Open Visual Studio and load decaf.sln
6) Click "Build" (Build>Build Solution)
7) Once the build has successfully finished, open a command propt and cd to C:/Users/username/Documents/GitHub/decaf-emu/obj/Debug
8) Type "decaf.exe play <path to extracted game directory>" (without quotes)
9) Wait and see how it crashes
10) Report the error to the developers, fix it yourself or wait until the developers have fixed it
Well, Cafiine is for simple file replacements, whereas Loadiine is for loading an entire game. I'm assuming it only takes .wud files, and it would be much harder to recompress after every edit, than to place it in the right folder for Cafiine to find it.
On topic: Really nice editor Roadrunner! I don't own SMM, so I won't be able to use it, but if I did, I would. You did a great job figuring out most of these values.
Version 1.0 by Grop
This is a program that was developed in a few days to edit HIOSubjectData_CAFE.bin, which can be found in NSMBU and NSLU. This file controls all challenges. With this editor, you can edit the difficulty of the challenge (in stars), the timer, its ID and the ID of its prequel, the cutoff points for the medals, the type of the challenge, the start powerup and everything else that is documented at this wiki page. Currently, there are 10 unknown values. Feel free to add them to the wiki when you've found their purpose. The numbering of the unknowns is a little weird, because some values are missing; those values were found by me while working on the editor.
Python 3.4 or up
Kinnay, for figuring out what this file does;
RoadrunnerWMC, for finding a few unknown values and moral support;
Me, for making this thing.
If you have any suggestions or questions, please let me know. Download
Q: How can I run py files?
A: Please install Python and PyQt. Then try running the program again.
Q: How do I save my edits to a challenge?
A: First click the "Save this challenge" button, and then go to File > Save File (As).
Q: Where can I find HIOSubjectData_CAFE.exbin?
A: In "vol/content/CAFE/subject/".
Well, he basically stole the Reggie version with NSMBU support, and then released it as his own work. Then, he also started to act superior to Roadrunner, who has figured out the entire format of the levels in NSMBU. Being one of the people who had worked on the editor for a few months when he released "his" editor, I'm not trusting him anytime soon.
I heard the following story:
Sony hired in multiple (2?) detectives to track Hykem down for his work in PS4 hacking. Said detectives recently came to his house, forced Hykem to wipe his harddisk, and they took his PC. Nintendo probably has nothing to do with this.
Go to function linkActorsToSprites. This function assigns actors to the sprite ids.
If you scroll down, there are some stw instructions. These store the actor ID at r10+sprite_id*4. Search for the instruction that stores a register in your spriteid*4
Scroll up to see what is loaded into that register. That's your actor ID.
Doubleclick the offset that holds the actor ID
Step 2: Find the creator (ctor)
Press X to find the Xrefs to this offset
Find the entry in that list that that loads this actor ID into r5
Check what is put in r4 before the registerProfile is called
This should be a function. Doubleclick it.
If it's a very short function that immediately branches to another function, the function function it branches to is the creator. Otherwise, the function you're already in is the creator.
Step 3: Find the vtable
Scroll down a bit, until something is stored at r3 + 0x4C
Then scroll up to see what is stored into that register
This should be an offset. Doubleclick it to reach the vtable.
Inside the vtable are a bunch of references to functions related to this actor (sprite). Convert these bytes to longs by pressing "d" 3 times while the byte is selected.
The size of an entry is in brackets.
Information about LinkList and ListNode can be found here.
0x00: Heap (pointer) (4)
0x04: Id (4)
0x08: Actor type information (pointer) (4)
0x0C: wasNotDefered (1)
0x0D: isSprite (1)
0x0E: created (1)
0x0F: deleted (1)
0x10: Nybbles 05-12 (4)
0x14: Nybbles 13-20 (4)
0x18: Nybbles 21-22 (1)
0x19: Nybbles 23-24 (1)
0x1A: initStateFlag (1)
0x1C: Child list [LinkList] (0x10)
0x2C: Child node [ListNode] (8)
0x34: Parent (pointer) (4)
0x40: Visible actors list node [ListNode] (8)
(Nearly) all actors that appear in a level have this struct. Sizes of entries are in brackets.
The rotation field contains three values: x, y and z). Those values are not stored as a float, but as something similar to a fixed point value. A few example values are probably the best way to illustrate this: 00000000 = 0 degrees, 40000000 = 90 degrees, 80000000 = 180 degrees, C0000000 = 270 degrees.
If the "is active" flag is disabled, the actor doesn't move or update anymore. This flag and the flag that indicates wheter the actor is visible or not can be changed for Mario as well. Unlike the field that deletes actors, the effects of these changes can easily be reversed by flipping the byte again.
The total length of this struct is 0x27C (Bytes).
0x000: Actor struct (0x50)
0x050: Direction (0=Right, 1=Left) (4)
0x054: Player ID (1)
0x056: Layer (1)
0x06C: Position, X (float) (4)
0x070: Position, Y (float) (4)
0x074: Position, Z (float) (4)
0x078: Speed, X (float) (4)
0x07C: Speed, Y (float) (4)
0x080: Speed, Z (float) (4)
0x090: Scale, X (float) (4)
0x094: Scale, Y (float) (4)
0x098: Scale, Z (float) (4)
0x09C: Rotation, X [explained above] (4)
0x0A0: Rotation, Y [explained above] (4)
0x0A4: Rotation, Z [explained above] (4)
0x0BC: Collider (0x128)
0x20C: Zone (1)
0x20E: isActive (1)
0x20F: isVisible (1)
The vtable holds the offsets to virtual functions. For every actor inheriting (a class that inherits) the Actor class, the start of the vtable contains offsets to the following functions. Note: each offset is a long (4 bytes), and between after every offset come 4 null bytes.
The StageActor base class expands on this:
Classes of actors (can) inherit other classes. A few of these classes are listed here. Unless overwritten, everything in the super class is copied to the actor class.
Annoying instructions in PPC
The rlwinm instruction is particularly hard to quickly understand. To help you with understanding this instruction (and simplified instuctions, like clrwi and extrwi), IDA 6.6 has a nice feaure; just press F10 when you encounter such an instruction, and it is converted to C syntax. For IDA 6.1, there is this plugin (more info can be found here), that does the same.
... to be expanded
All credits for this go to Kinnay, I merely put this here to make it more readable than an IRC log. Also thanks to MrRean for some more info. And whoever wrote the wiki article about memory addresses.
You should also post a tutorial on how to dump files with DDD, as we don't know the NUS key of every game/dlc (i.e. the MK8 DLC). That method is also a lot less illegal (no need for all those illegal keys).
Disc. The dump this rpx came from was the first NSMBU dump. And I doubt there are differences between the disc and eshop versions of the game. Making changes to a released game only costs Nintendo extra money.