Gecko dotNET Bugs and Requests

[dcx2]

Yeah, I goofed.  When I made the zip file for 0.66.2 I put the wrong exe in it.  0.66.3 is now up.

[Bully@Wiiplaza]

When I made the zip file for 0.66.2 I put the wrong exe in it.

rofl ;D

[Deathwolf]

When I made the zip file for 0.66.2 I put the wrong exe in it.

win xD

[Bully@Wiiplaza]

- switching from search tab to memory viewer using the context menu takes me to wrong addresses (bad bug :-\)

[dcx2]

Just the search tab?  Does disasm context menu's memview shortcut work?  How about Show Mem during a breakpoint with a load or store?

This is probably a result of some changes that I needed to make so that the selected cell isn't changed when switching tabs.  I'll look into it when I get off work tonight.

EDIT:

Found the problem and fixed it.  0.66.4 is up now

[Bully@Wiiplaza]

Just the search tab?  Does disasm context menu's memview shortcut work?  How about Show Mem during a breakpoint with a load or store?

This is probably a result of some changes that I needed to make so that the selected cell isn't changed when switching tabs.  I'll look into it when I get off work tonight.

EDIT:

Found the problem and fixed it.  0.66.4 is up now

correct address lookup still fails when trying to trace back a pointer in pointer code for example.
I couldn´t get to the right address, but with 0.66.1 I could.

[dcx2]

I don't understand what you mean.  Do you mean double clicking on address in memview?

[Bully@Wiiplaza]

I don't understand what you mean.  Do you mean double clicking on address in memview?

yes pretty much what you said.
It doesn´t show the right address when I double click.

---

On Pokemon Battle Revolution, the game crashes, when a C2 code is sent twice (when the code was still active and even when it wasn´t modified)
I ticked "undo after disabling" and "undo after sending" but it still froze :(
I even pressed disable and sent again, but it froze.

On other games like Call of Duty, it does not freeze when I send C2 codes twice.

And I really need to send them multiple times to test them out. I don´t want to manually unhook each time either :(
The issue mostly occures on older codeshandlers but sometimes aswell with gecko 1.9.3.2. if I multi-send and/or disable F6 codes.

[dcx2]

On Pokemon Battle Revolution, the game crashes, when a C2 code is sent twice (when the code was still active and even when it wasn´t modified)
I ticked "undo after disabling" and "undo after sending" but it still froze :(
I even pressed disable and sent again, but it froze.

Do you have the GCT Code Undo line?  That is, the line "##undo_addr undo_val"?

Sending the same C2 code twice shouldn't cause problems on 1.9.3.x code handlers.  The codes are executed immediately after they are uploaded and before the game can run, and the branches are flushed/invalidated after being written.

Go to the Breakpoint tab and press Step Into after the crash.  Do you get anything?

EDIT:

Double-clicking a pointer in memview takes you to that pointer.  I'm not sure what problem you're having...

[goemon_guy]

On Pokemon Battle Revolution, the game crashes, when a C2 code is sent twice (when the code was still active and even when it wasn´t modified)
I ticked "undo after disabling" and "undo after sending" but it still froze :(
I even pressed disable and sent again, but it froze.

I have had this same problem in the past. If I send a C2 ASM code, it works the first time, but if I try sending any other codes afterwards, while that same C2 code was active, then it froze. Also, when I modified the ASM code, recompiled it and re-sent it, it froze the game.

What I had to do to be able to modify the C2 ASM code and re-send it was go back to the disassembler and restore the original instruction to the ASM address, then I could send it again... Which was tedious.

MOD EDIT: fixed improper quote

[dcx2]

I have had this same problem in the past. If I send a C2 ASM code, it works the first time, but if I try sending any other codes afterwards, while that same C2 code was active, then it froze. Also, when I modified the ASM code, recompiled it and re-sent it, it froze the game.

What I had to do to be able to modify the C2 ASM code and re-send it was go back to the disassembler and restore the original instruction to the ASM address, then I could send it again... Which was tedious.

The tedious process you describe is automated using GCT Code Undo.  A line of the format "##undo_addr undo_val" will poke undo_addr with undo_val when codes are disabled and/or sent again.  For instance, I have a code for RT4EAF which unlocks characters for leveling.  It hooks 8009F828:  80010024   lwz   r0,36(r1) and it's stored in my GCT tab as the following.

##8009F828 80010024
C209F828 00000003
2C030000 4082000C
38600001 7C7FF1AE
80010024 00000000

To assist with creating the undo line, I added a keyboard shortcut.  Double click the C2 word of the code, so that e.g. C209F828 is highlighted.  Then press ctrl+u and it will automatically read the word at the C2 address with a ba=80000000 and insert the appropriate undo line.  You can also ctrl+d or ctrl+m to get to the disassembler/memview for the selected code word, again with ba=80000000.

---

Okay, so here's the deal with the C2 code bugs.  An unpatched debugger does not automatically execute codes after they are uploaded to the code list.  Immediately after codes are uploaded, it goes back to the game loop for one frame.  I call this the "virgin frame" because the C2 code is a "virgin" code - the "back-branch"/very last word of the C2 has not been written to so it is still 00000000.

When a C2 code is executed, a branch over-writes the hook address, and the back-branch of the C2 is written to branch to the hook address + 4 (i.e. the instruction after the hook).  The first time a C2 code is applied, the hook address will be untouched during the virgin frame.  Then, the code handler will execute the C2 code before the next frame, over-writing the hook address and the back-branch.

The second time a C2 code is applied, the back-branch is virginized so that it is 00000000 again.  However, the hook address is still the branch from the first time the C2 was applied.  During the virgin frame, the branch is taken to the C2 code, but the back-branch hasn't been written yet, so it crashes trying to execute the "instruction" 00000000.  This is why Y.S. would use a bctrl back to the hook address + 4.  But in order to actually disable or "unhook" the C2 you need to over-write the hook with the original instruction.

---

If you tried to do a "classic" pause before sending the codes, you would find out that the codes are executed before the classic pause is entered.  Instead, I would set a breakpoint just before the codes are executed - this is the BPNext on the About tab.  If you did a BPNext pause, and uploaded codes, then when it resumed it would immediately execute the code handler.  This was the purpose of the Pause While Sending checkbox.

As of...some recent version, I can't remember which, one of the debugger patches will make sure the codes are executed immediately after they're uploaded, so you don't need Pause While Sending anymore.  There's also some small details about patches that flush and invalidate branches and another that resets the debugger registers, but this is already a novel...

[Bully@Wiiplaza]

k, I should start working with those ## lines then...

EDIT:

Adding Offset does not work properly.

Example:

9013AA70 + 9050 = 90143AC0 (Calculator)

but geckodotnet goes to...
90143A50

[dcx2]

Ah, I see what happened.  Add Offset works properly on addresstextboxes, but the memview context menu reads the wrong start address (it reads the "start of view" address instead of the "selected" address), so you end up short 0x70 short (because the view is usually 0x70 less than the selected).  I'll fix it tonight.

[Bully@Wiiplaza]

Request:
Mark an address on gct tab and press strg. + m to switch to mem. view and view that address
Mark an address on gct tab and press strg. + d to switch to disassembly and view that address
Pretty much like the undo generator, just that it detects the address as 8XXXXXXX etc. and shows disassembly/mem. viewer
it´s a lot nicer than copy pasting the address and replacing the codestype with 80 etc. and pressing enter to show address ;D
Idk if something like that already exists... :o

Restarting search is often greyed out, one needs to perform another search to make new searches possible

There´s a weird glitch with the 20 codestype and the ## disable thingy.

Sending the following code makes the codeshandler ignore the 20 checkline and always enables the C2:

##809CB1B4 807F138C
209CB1B4 807F138C
C29CB1B4 00000002
3860FFFF 907F138C
60000000 00000000
E0000000 80008000

but sending this one works like it should work:

209CB1B4 807F138C
C29CB1B4 00000002
3860FFFF 907F138C
60000000 00000000
E0000000 80008000

Why did I notice that?
I sent the first one and randomly crashed, because the code wrote even when the compare wasn´t true.
Example code is my AP Roulette Code for Yu-gi-oh.

[dcx2]

...strg = ctrl?  It already does this.   :P

Restart search grayed out...I'll need some way to reproduce this bug.

GCT Code Undo...it looks like you're using the 20 code the way an F2 code is supposed to be used.  Either way, the ## line is always poked when undoing codes.  It assumes that the ASM does not change.  If the ASM changes, it has no way to know and will poke anyway.