Establish a breakpoint address

[dcx2]

If it started at 120, after one frame it's 119.  After another frame it's 118.  Each frame, it decreases by 1.  This is why the "different by 1" search finds it.

[live2play]

So, the 8-bit, 16-bit and 32-bit searches resulted in addresses, but whenever I activated the only one of each type that had a high enough value (i.e. not the ones with 00000001-00000003), the game hung.  I used the correct code type for each of the writes (e.g. 00, 02 and 04), clicked to the left of the code to enable the asterisks, highlighted the code name at the left and selected Apply Codes.  Any other ideas?

P.S.  My SD card reader decided to stop working tonight.  I was going to try and put the same codes on the card and use Cheat Manager to activate them via a GCT file.  Is it possible that the GCT code functionality in WiiRD has issues or has your experience been that it works without issues?

[dcx2]

I'm not sure I understand what you were trying to do.  Were you trying to write a value to the timer in memory?  Were you trying to patch the assembly so it didn't count down, or counted down faster?

In general, I don't like writing data values to RAM.  I much prefer patching assembly because there's a good chance that the value in RAM will move around.  Pointers are evil like that.

I used the correct code type for each of the writes (e.g. 00, 02 and 04), clicked to the left of the code to enable the asterisks, highlighted the code name at the left and selected Apply Codes

Do you have any C2 code-types active?  The only GCT code issue I have ever seen is applying cheats after a C2 code has been applied.  Here is the special process I use if I'm re-applying cheats after having activated a C2 code.

1) Breakpoint on something (code handler works great!)
2) Apply cheats
3) Go back to breakpoint tab and click step
4) Now you can click run.

I have found that without line 3 ("click step") the game will still lock up.  Don't know why.

[live2play]

I was writing (persisting) a value (e.g. FFFF for 16 bit) to the memory address that was changing.  I will look into patching the assembly instead.  On a related note, what technique would you use to find the blast radius (actual damage) for a bomb/grenade?

[dcx2]

What was your goal in writing 0xFFFF to the timer?  Are you trying to keep grenades from exploding, or make them explode faster, or what?

If the timer was allocated inside dynamic memory, then your pointer code could have corrupted some other important memory.  If you think you have the timer, throw another grenade.  You should be able to watch it count down in Memory Viewer and explode when it reaches zero.  If that works, throw another one, and this time pause the game, and write a bigger value (like, 300 = 0x12C = 10 seconds), and make sure the grenade actually takes 10 seconds to go off.

As far as blast radius...again, blow yourself up.  You probably know where your own health is.  See who writes to your health and you should find the bomb code.

[live2play]

Thanks.  I'll look into this further and see what I can figure out.