Gecko dotNET Bugs and Requests

[Bully@Wiiplaza]

good idea, it would be useful to set a breakpoint and you´re sill able to switch tabs and do other stuff until it hits.
Well, what about mem80 + 90 searches at the same time on search tab?
If you have no clue wheter your value is on mem80 or 90, it´s a good thing to scan both mems at the same time. In my opinion.

[dcx2]

switching tabs while waiting on a breakpoint is a good idea but it won't be easy and it might be unreliable...

As far as a dual-mem search, that would require a great deal of under-the-hood changes, so probably not.

[goemon_guy]

I found a small bug when making GCT codes.

When you do an 8-bit or 16-bit search, and you send one of the values and addresses to the GCT tab, it creates a code like so:

[values made up on the spot]
8-bit
00XXXXXX 01020304

16-bit
02XXXXXX 06BCFFFF

However, 32-bit searches come out fine. (As expected.)

[Bully@Wiiplaza]

switching tabs while waiting on a breakpoint is a good idea but it won't be easy and it might be unreliable...

As far as a dual-mem search, that would require a great deal of under-the-hood changes, so probably not.

or maybe tabs switching while gecko.net dumps memory.
That wasn´t possible, yet. Managing codes on gct tab, while it dumps would be great.

[Skiller]

SNIP

would there be an option to Display the Float regesters as Hex instead of Floats .. since u can use them to store Normal Hex as well :P and some games iv ran into have done this .. ..
this is in the break points tab ..

thax ..

[dcx2]

Right click the Text View Show Mem button, I think.  One of those buttons has a context menu for showing the floats as hex or floats.

[Stuff]

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.

And now in memview, when you press enter instead of update, it goes to the right address but in the address box it's -0x70. Actually, when you hit update it also does this, but will only work once...update is just weird now.(messing with it as I type). Update works only if you input an address and it'll go to the right address but display -0x70 in the address box. After that, you can't click update to warp back to the address from before. Then, if you scroll up or down with the scroll bar, the address box changes to show the top most address Example:

80BFFF80   00000000   00000000   00000000   00000000
80BFFF90   00000000   00000000   00000000   00000000
80BFFFA0   *00000000*   00000000   00000000   00000000
80BFFFB0   00000000   00000000   00000000   00000000
80BFFFC0   00000000   00000000   00000000   00000000
80BFFFD0   00000000   00000000   00000000   00000000
80BFFFE0   00000000   00000000   00000000   00000000
80BFFFF0   00000000   00000000   00000000   00000000
80C00000   00000000   00000000   00000000   00000000
80C00010   00000000   00000000   00000000   00000000
80C00020   00000000   00000000   00000000   00000000
80C00030   00000000   00000000   00000000   00000000
80C00040   00000000   00000000   00000000   00000000
80C00050   00000000   00000000   00000000   00000000
80C00060   00000000   00000000   00000000   00000000
80C00070   00000000   00000000   00000000   00000000

After scrolling up or down to see this, the address box shows 80BFFF80.

...I'm pretty sure it never did that before. If you were working on a new feature, make it optional.

[dcx2]

The memview address in the upper left corner is the first visible address (i.e. the first address to be dumped).  It is not the selected address.  The two are very different, and trying to use one for the other's purpose was causing bugs like the Add Offset bug.

Manually entering a value into the visible addresstextbox and pressing enter will select and center the address that was just entered.  However, the visible addresstextbox will adjust itself to reflect the fact that some other address is now the visible address, and the new selected address will be passed to the addresstextbox in the poke groupbox.

I also think you misunderstand "update".  Update means to dump the contents of memory again and refresh the datagridview.  Hence, "auto-update", which presses the update button as fast as the technology will allow.

Now consider what happens if you're looking at the memview and you click update, because you have auto-update off.  If it tried to select and center the address in the visible addresstextbox, then every time you press update your memview would jump to center the visible address.  Press Update a bunch of times and it jumps a bunch of times.  That is incorrect behavior.

In your example, 80BFFF80 is the visible address in the upper left, 80BFFFA0 is the selected address in the poke groupbox.  If you press update again without changing the visible addresstextbox, you wouldn't expect the contents of memory to move, instead you'd expect the contents refreshed.  If you put a non-visible address into the addresstextbox then you would expect to be taken to the new address.

"when you hit update it only works once" - the reason is that when you change the addresstextbox the first time, it recognizes that the address is new and centers the selection on that new address.  However, when you press it again it knows the address is the same, and therefore it won't move; think of this as "refresh" instead of "update".

As far as warping....any warping that happened was purely a bug.  The visible addresstextbox should exactly match the address in the first cell of the datagridview at all times.  If it does not, then you will experience buggy behavior.

If you want to "warp back" to an address, click in the visible addresstextbox and either hit ctrl+enter or move the cursor out of the addresstextbox.  This will add it to the addresstextbox history.  Double click an addresstextbox to see its history contents.

[Stuff]

oh. I was so used to the address box having whatever I put in there. I can live with it, just thought it was a bug.

[dcx2]

I'll be considering a few things to make it simpler to "remember" what address you were on and such.  I'm not against changes to the memview architecture but it does need to be consistent.  If you want to brainstorm ways for the "warping" feel free.

[Stuff]

I think it was asked for before, but a back button would be nice. It would take you to the previous address you typed in. The same way it works for folders and web browsers. Forward also if it's not too much to ask. But I find forward much less useful than back.

The +/- offset thing, I still would rather have some box that I can +/- to the address. But this would sort of require the addressbox to remain "untouched"...The reason for the box is cuz right clicking to +/- B18 and then hitting Enter to jump from one monster to the next and having to do all that again, even entering B18 is a little much when you could have a box that keeps your offset and you can press enter 3 or 4 times. There are quite a few things that could use this. Jumping between monsters, players, characters, friends, weapons, items, anything you can find a nice spacing for. A "multiplier" box right next to it would be nice as well, to skip 4 whatevers, although that might be as useful as forward. The multiplier would default to 1 and would take 8 bit numbers, the offset box would take 16 bit numbers and default to 0000. Hitting enter in any of these 2 would take you to address+(multiplier*offset) and of course change 'address' to reflect the new position, and hitting Enter on the address box would just take you to 'address'.

I imagine the 'onEnter' function for the 2 boxes would be something like

address += (multiplier*offset);
whateverYouDoToTakeUseToTheAddress();

That attempt at helping with the code was probably about as useful as the forward button. lol.

[dcx2]

lol, am I the only person who uses the history function of the addresstextbox's?  That's how I get back to addresses that I don't want to lose.

I'll consider your suggestion about the offset/multiplier box, although space is at a bit of a premium right now.

[Stuff]

XD. The history function is bootleg though. I know you've explained it like 3 times already, but sometimes, it's like, "wut?"

Underneath the address box is a nice spot. But I see what you mean. increasing the window's size would make the other tabs bootleg. You could shrink the source dropdown cuz it doesn't look like it needs more space than "Open Dump...". And then...well it's hard to say remove the source label...it was so you can fit auto update there. But that needs that elbow room for it to show dps. idk. Do whatever whenever.

[Bully@Wiiplaza]

Mh3 issue:
when auto-update is enabled and one goes to a "now loading..." screen game crashes! (black screen)
No codes were active, obviously. Invalid register...

[spoiler]  CR:44200488  XER:20000000  CTR:0000F800 DSIS:04000000
DAR:049014AB SRR0:80001DCC SRR1:00003032   LR:80001E70
 r0:804B687C   r1:807AFB68   r2:8079FF60   r3:0000F800
 r4:00000000   r5:109014AC   r6:80000000   r7:80001808
 r8:00000000   r9:0011C264  r10:80001E70  r11:00000C63
r12:049014AB  r13:8079B2E0  r14:00000000 r15:800028B8
r16:0C000001  r17:0000F800  r18:80002774  r19:00000000
r20:CC000000  r21:00000000  r22:00000019  r23:000000D0
r24:CD000000  r25:00003032  r26:00003032  r27:80002784
r28:000000FF  r29:000000AC  r30:80001DA8  r31:80000000

80001DC0:  7D4802A6   mflr   r10
80001DC4:  7C6903A6   mtctr   r3
80001DC8:  39C00000   li   r14,0
80001DCC:  7C6C70AE   lbzx   r3,r12,r14
80001DD0:  4800001D   bl   0x80001dec
80001DD4:  4182FFF8   beq+   0x80001dcc
80001DD8:  39CE0001   addi   r14,r14,1
80001DDC:  4200FFF0   bdnz+   0x80001dcc
80001DE0:  7D4803A6   mtlr   r10
80001DE4:  4E800020   blr   [/spoiler]

EDIT:
corrected

[dcx2]

Oh wow.  That is actually mega helpful.

That's exisendbuffer crashing.  You're highlighting the wrong reg - r14 is supposed to be 0, it's the "index" (the x in lbzx) counting the number of bytes to send.  r12 is actually the reg that caused the crash.  r12 holds the first address to be sent over the USB Gecko.

Do you remember what memory range you were trying to dump?  Was it something like 9014AB__?

r12:049014AB

The 04 is the "command read-mem" command.  For some reason, readmem was sent twice.  So it used the readmem command byte as the first byte of the address.  -> fail

Wow.  I have to take some time to figure out exactly what went wrong and how to fix it.  In the mean time, I can show you how to recover from this crash.

1) Go to disassembly tab.  Find  80001904:  3AA00000   li   r21,0  and right-click "SRR0 here".
2) Make sure auto-update is off, and then click "Run".