ROM Hack Super Mario 64 ds code not working

  • Thread starter Thread starter dahacker2019
  • Start date Start date
  • Views Views 4,291
  • Replies Replies 14

dahacker2019

Well-Known Member
Newcomer
Joined
Dec 21, 2018
Messages
67
Reaction score
10
Trophies
0
Age
25
Website
www.youtube.com
XP
219
Country
United States
There is a Boolean value that states if your character is under lava. Setting it to 1 results in random lava burns. The code won't work on the Twilightmenu++ with a modified usrcheat.dat file but other codes in the usrcheat.dat file work. I've tested the code on desmume and some emulators on Android that accept AR codes. Drastic DS didn't work. The code is:
[RNG Burning]
0216E940 00000001<outside castle adr
0217FD20 00000001<inside castle adr
D2000000 00000000

I don't know why it doesn't work but all feedback is appreciated!
 
Tested the code in DeSmuMe with the US version of the game and it did nothing. Are you sure this code works?
It's version! 1.0 USA 0056

P.S. Using same ROM as desmume

--------------------- MERGED ---------------------------

Here's an image of the ROM
 

Attachments

  • Screenshot_20190405-135803~2.png
    Screenshot_20190405-135803~2.png
    55.8 KB · Views: 247
Last edited by dahacker2019,
Yes, most flashcard cheat engines implement (to whatever extent, but I imagine nearly 100% compatible) the ARDS codes

The code you posted looks wrong, codes starting with 0 (or 1/2) are simple memory writes, but the D2 one ends all conditions and resets pointer shifts... but the only 2 previous codes didn't set up any of that...
 
Yes, most flashcard cheat engines implement (to whatever extent, but I imagine nearly 100% compatible) the ARDS codes

The code you posted looks wrong, codes starting with 0 (or 1/2) are simple memory writes, but the D2 one ends all conditions and resets pointer shifts... but the only 2 previous codes didn't set up any of that...

It worked on desmume and some ar handling Android DS emulators. But the code won't work on certain ones or on the 3ds r4 emulating usrcheat.dat

--------------------- MERGED ---------------------------

It worked on desmume and some ar handling Android DS emulators. But the code won't work on certain ones or on the 3ds r4 emulating usrcheat.dat
If the code is wrong tell me how to fix it I would love to have that help with this.
 
Yes, most flashcard cheat engines implement (to whatever extent, but I imagine nearly 100% compatible) the ARDS codes

The code you posted looks wrong, codes starting with 0 (or 1/2) are simple memory writes, but the D2 one ends all conditions and resets pointer shifts... but the only 2 previous codes didn't set up any of that...

The code is totally fine writing D2 as the last line is never wrong. It just resets the codehandler to its initial state.
The value that gets written seems to me some condition value that gets set by a function if some test is true and later gets used to do the lava burning thing. And if the value gets written after the test but before the game checks if it should do the lava burning it will do the lava burning. So the more often you write the value in a second the higher the chances are that you will get lava burned. So maybe Twilightmenu++ doesn't do it often enough so chances of lava burning are very rare. But this is just a wild guess and maybe this problem lies somewhere else.
 
The code is totally fine writing D2 as the last line is never wrong. It just resets the codehandler to its initial state.
The value that gets written seems to me some condition value that gets set by a function if some test is true and later gets used to do the lava burning thing. And if the value gets written after the test but before the game checks if it should do the lava burning it will do the lava burning. So the more often you write the value in a second the higher the chances are that you will get lava burned. So maybe Twilightmenu++ doesn't do it often enough so chances of lava burning are very rare. But this is just a wild guess and maybe this problem lies somewhere else.
I've tested other codes for example: moon jump. There is no code lag. So that's not the issue. Maybe it's applying too fast? If that's the case how do I slow it down?

Update: tested a button activator no bueno. ON desmume it worked so the address might be wrong. The address might be different. Do desmume addresses apply to actual hardware RAM addresses?
 
Last edited by dahacker2019,

Site & Scene News

Popular threads in this forum