Mario Kart 64 Hacking General Discussion

[queueRAM]

I don't follow where you got the 0x884C6C4C address from. If you're using shygoo's PJ64 debugger, you can just open the memory viewer and go to one of the addresses you are interested in (e.g. 801A7A90 for GP human table). There you should find the 100 values (starting with thirty 0x01s). You can tweak the values there for a running game. PJ64d is also scriptable with javascript if you want to programatically do it without using something like CheatEngine.

If you wanted to modify these in the ROM itself, I'm not sure exactly where these values are stored. I'm guessing they are generated by code somewhere. Maybe someone who knows more details about this can chime in here. You can always set a write breakpoint on one of the values in the debugger and see where they are written from. If you need help with this, I can take a look some evening this week.

[UndeniablyAlex]

(16-01-2018, 08:50 PM)queueRAM Wrote: I don't follow where you got the 0x884C6C4C address from.  If you're using shygoo's PJ64 debugger, you can just open the memory viewer and go to one of the addresses you are interested in (e.g. 801A7A90 for GP human table). There you should find the 100 values (starting with thirty 0x01s). You can tweak the values there for a running game. PJ64d is also scriptable with javascript if you want to programatically do it without using something like CheatEngine.

If you wanted to modify these in the ROM itself, I'm not sure exactly where these values are stored. I'm guessing they are generated by code somewhere. Maybe someone who knows more details about this can chime in here. You can always set a write breakpoint on one of the values in the debugger and see where they are written from. If you need help with this, I can take a look some evening this week.

​


Thanks again for this queueRAM, I found the table! Guess I'm just still struggling with the shift in addresses at run-time, keep looking in the wrong places. Trying to get to grips with the javascripting in the debugger, trying to get the screen.print function to print out the value of player 1's inventory at run-time, but it either says "false" or "0" permanently. Is shygoo still active? Might be good to get some guidance from the creator I suppose!

[shygoo]

Hey, still active . It sounds like an invalid address is being passed to the mem interface (or its possible my screen.print function is just broken). Could you provide a snippet of the JS code that's causing issues?

[UndeniablyAlex]

(31-01-2018, 05:55 PM)shygoo Wrote: Hey, still active . It sounds like an invalid address is being passed to the mem interface (or its possible my screen.print function is just broken). Could you provide a snippet of the JS code that's causing issues?

​


Hey shygoo! Good to hear from you I'm still toying around with it, apologies again if I'm missing something obvious!

Code:

​mem.bindvar(this, 0x20165F5E ,'itemAtCurrent', u8)

events.ondraw(function()
{
   screen.print(20, 20, 'current item value: ' + itemAtCurrent)
})

What I get from this is "current item value: false", and I'm looking to get the value returned of the item held by the player, i.e. "current item value: 7" when holding a Blue Shell.

EDIT: Also just a little note for yourself shygoo! The screen.print(x, y, text) function example has a little spelling mistake in it:-

Code:

​
events.ondraw(function()
{
    screen.print(20, 20, "power: ' + mem.u8[0x8033B21E])
})

the quotation mark before power should be an inverted comma

[shygoo]

Ah I see, I'm guessing that 0x20165F5E address came from Cheat Engine. Converting a process address to an actual N64 virtual address is a little awkward. It needs to be offset by 0x60000000, and the last nybble of the address needs to be corrected for proper endianness (under the hood PJ64 stores every 4 bytes using little endian ordering for optimization, even though the N64 is natively big endian).

The conversion operation for addresses of 1-byte variables would be:

Code:

​0x60000000 + ((address & 0xFFFFFFFC) + ((address & 3) ^ 3))

And for 2-byte variables:

Code:

​0x60000000 + ((address & 0xFFFFFFFC) + ((address & 3) ^ 2))

I think the currently held item is a u16 at 0x80165F5C, while the u16 at 0x80165F5E represents the status of the item window.

This seems to work

Code:

​mem.bindvar(this, 0x80165F5C, 'itemAtCurrent', u16);

And thanks for pointing out the error in the doc, I should work on my proofreading  

[UndeniablyAlex]

This is wonderful help shygoo! Thank you so much Is there any way I can edit a script through project64d to output results to a text file? I'd be looking to keep track of each item picked up by a racer as the race progresses!

[shygoo]

The script api has a file system interface as of today 

[UndeniablyAlex]

Howdy all! Was struggling to see the forum at all for a few days! Been making some real progress with the dissertation work, but I'm having a bit of trouble with pointers in the memory address? I am trying to lock down exactly where each racer's X, Y & Z co-ordinates during the race, and I know the pointers to their driver structures are located at 0x800DC4DC, but I'm not sure how to get to the structures from there?

Thanks again for adding the scripting system shygoo, it's worked wonders for me!

[UndeniablyAlex]

Hey folks! I'm looking for the memory addresses which hold the current ranking of the CPU Racers (1st, 2nd, 3rd etc.) and where the CPU Racers keep track of how many laps they have done? Many thanks!

[ct187]

I found this thread a few weeks ago and have been playing with shygoo's course viewer since then. I'm surprised that there still haven't been any custom MK64 levels released (other than the one from 2008) when it seems like a lot of the work has already been done and we are really close.

I am determined to make at least a custom battle course. Using shygoo's course viewer, I've gotten to the point where I can manipulate vertexes (although not user-friendly) and come up with edited course layouts. If i was able to get to the point of changing Big Donut around to be a "custom" course within the course viewer, how difficult would it be to map the updated vertex data back to the original memory addresses in the ROM?

Basically I'm looking at the 3d rendering of my edited course in the viewer and I'm going to begin just trying to just reverse what the course viewer does when loading from the ROM. For each of my updated vertices I want to find the addresses of the data where that vertex originally came from, so I can write my changes to the ROM. Is this possible or is the original ROM address of a vertex impossible to determine from just the rendered 3d model? Is there another or better way anyone can think of to do this?