Gecko dotNET Bugs and Requests

[Bully@Wiiplaza]

I wish there was some feature called "pointer following".

If I do a search I will get results (pointing out the obvious). In case they change every level / race or whatever there could be some feature to use which asks for a pointer address in order to spot the same search results in memory again by doing calculations or however it manages that in order to continue searching with every address updated instead of restarting and searching again. Maybe some "update addresses" button.

Some codes are (almost) impossible to create without something like this. A value which is specified before loading a map / track etc. but should be modified on-the-fly will not be an easily doable code. Without restarting the map / level etc. while keeping all addresses at their spots and having the wanted value changed you´re definitely at a dead end in terms of making the hack. Incredibly annoying and a hassle to get through. :(

[dcx2]

I'm not 100% sure I follow, but I think Link's watch list tab does what you want.

Basically if you can build a pointer code that would see the value, you should be able to create a watch list entry that will do the same thing.  I think.  Or maybe I'm getting confused with CheatEngine?

[γRB]

Random request:
Show up EA immediately, too. For instance:
r29: 80654321
80123456: stw r0,12512(r29)     |   80654321+30E0=80657401
or
80123456: stw r0,12512(r29)     |   80657401

I hope I've been clear enough, just a little request, I get lazy to use the calculator at times.  :D

[dcx2]

During a breakpoint you can right or left click the Show Mem button and it will calculate the effective address of the current instruction.  You can also visually examine the DAR register during a breakpoint.

There's no way to calculate an EA when you're not currently at a breakpoint.  It makes no sense because you have no idea what the GPRs will be if you aren't at a breakpoint.

[Bully@Wiiplaza]

I'm not 100% sure I follow, but I think Link's watch list tab does what you want.

Basically if you can build a pointer code that would see the value, you should be able to create a watch list entry that will do the same thing.  I think.  Or maybe I'm getting confused with CheatEngine?

Just booted everything and took some closer looks at the tab I never used so far. xD

You´re right. It can see what pointers reach. I still would like to have everything ready for the search tab, though.

Random note:
If Gecko.Net is "on top" the "Add watch" dialog locks the application since it´s behind it and must be confirmed / canceled before something else can happen.

The watch list IMO should load entries automatically, just like the GCT tab.
It´s useful for pointers and changing values, seems like I missed out.

[γRB]

During a breakpoint you can right or left click the Show Mem button and it will calculate the effective address of the current instruction.  You can also visually examine the DAR register during a breakpoint.

There's no way to calculate an EA when you're not currently at a breakpoint.  It makes no sense because you have no idea what the GPRs will be if you aren't at a breakpoint.

Hah, I Obviously meant during a breakpoint :P

[Stuff]

I'm not 100% sure I follow, but I think Link's watch list tab does what you want.

Basically if you can build a pointer code that would see the value, you should be able to create a watch list entry that will do the same thing.  I think.  Or maybe I'm getting confused with CheatEngine?

Just booted everything and took some closer looks at the tab I never used so far. xD

You´re right. It can see what pointers reach. I still would like to have everything ready for the search tab, though.

Random note:
If Gecko.Net is "on top" the "Add watch" dialog locks the application since it´s behind it and must be confirmed / canceled before something else can happen.

The watch list IMO should load entries automatically, just like the GCT tab.
It´s useful for pointers and changing values, seems like I missed out.

actually, what I thought was meant by this request was like when you search, you get results, you search again, you narrow the results, and then the stage changes and everything moves. But you know where it moved since you know where the pointer is at. And you're searching for something new in this area.

For example, lets say I want to find the address that hold "player#", but the address moves when you are a different player number. We already know how to make pointer codes for the stuff related to the player, we just want to find the number because the game gets it from somewhere. So you search, change players, and then what? the addresses moved, and now the next search should be done in a different area in memory.

[Bully@Wiiplaza]

Something I found annoying though is that Gecko.Net freezes up on dumping or resizing / moving around. It can be handled with multi-threading (?).
Moving .gct codes also causes a lot of non-responding instances especially when CPU power is low. Double-clicking reconnect quickly causes the game to crash just like in a dead loop. Gecko.Net loses connection. Also if I have my USB connected and run Gecko.Net it´s VERY slow because it keeps trying to connect while there´s nothing to connect to. I have to unplug the USB to use it stand-alone.

[CosmoCortney]

it would be nice to be able to type some known values and some variables for unknown values into the textBox of the Memory Viewer like:
0AXX42XX03XX05XX15XX3B... or 15XXXX05XXXX12... to search for LUTs.

and it would be nice to be able to do 24 Byte searches (would be helpful for finding sizemodifiers).
i know this can be done in the memviewer, but it only allows me to test one address at a time.

[wiiztec]

I was making a log of a function when I noticed it was stuck on an instruction, it just kept logging the value of the instruction before an mtmsr instruction. apparently Gecko.NET doesn't know how to step into it. any hope for a quick fix?

[dcx2]

I think certain instructions can't be trapped for some reason.  Generally they're the kind of instructions you see in the code handler, not game code.

If you know the address of the instruction that's tripping you up, you could use Step Until.  It will log everything up to that instruction.  Then come back and set XBP on the instruction after the mtmsr.  Then run Step Until again.

[wiiztec]

That's what I was gonna do if it couldn't be fixed but I don't know how many more mtmsr's their are, I know their's one a few instructions after the first one if their is more than a few that could be a very annoying solution. btw if it wasn't clear step until is what I was using I set an execute breakpoint at the bl into the function and an SRR0= condition for the address of the blr at the end