Gecko dotNET Bugs and Requests

[dcx2]

I need to know what version of the code handler was being used.  A copy and paste of the details would help, too.

[Bully@Wiiplaza]

I personally wouldn´t bother about supporting "Ocarina" anyways >-<
There are way more important things to work at...

[Stuff]

So that's why I was considering putting it there.  Just a label "handler: " and then 1931, 1932, GOM, or ???  That way, when someone has a problem, I say "go to Tools tab and tell me what version of the handler you're using".  Instead of trying to figure out which various loader version x.y bz has what handler.

o.O That would be very nice, actually. I wonder what it'll say for cfg usbloader. You could probably also put it in the menu bar.(that's what it's called, right?) After (gameid) it could have the code handler. I mean, it's fine in the tools tab still. There is mad space there XD. idk. I just feel that it's better if it's all up in your face always. I could also see a reason not to put it in the menu bar, though. Too much text, then you'll look at it in the task bar and see "Gecko.NET (RMHE0...". It was just a suggestion. Do whatever.

[dcx2]

@Bully/Deathwolf - Well, it shouldn't *crash* with other code handlers, even if they aren't patched.  A lack of patches just means there are bugs that will pop up.  Ocarina is way old anyway, it doesn't have F6 codes etc.  You should really make sure your loader has at least 1931 handler.

@Stuff - that's the title bar.  Gecko.NET doesn't have a menu bar (file, edit, view etc).  I thought about putting it in the title bar, but it's not really an in-your-face type of thing.  Once you know that e.g. cfg usb has 1931 handler, you don't really need to see it anymore.

[Stuff]

that. I was just derpin there. And you right. The code handler isn't just gonna change over night. lol

[Arudo]

Huh. I just saw a small typo when the program can't find the Gecko.
Status:
No USB Gecko Connection availible <- available

And... I've noticed something odd when playing with a game that had GCTs already loaded.

GeckoDotNet constantly started to connect/disconnect with the USBGecko.

And when I tried to cancel connection, it would give the 'Retry Connect' dialogue box, and I clicked No, but it would proceed in popping up constantly and the process more or less bugged out.

*Unless this has already been dealt with earlier and I failed to notice*

New:

Oogh. Using the 66.7 Build and I went ahead to send some codes to Pandora's Tower and I got a nice exception crash that made me switch to the BP Tab. Went back to the 66.5 build and input codes as usual with no issue.

[spoiler]
2011/08/20 20:44:26: Opened log
20:44:26: Exception occured!
Exception: FTDIUSBGecko.EUSBGeckoException
TooManyRetries
Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
Stack Trace:
   at FTDIUSBGecko.USBGecko.sendfail(EUSBErrorCode error)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump)
   at FTDIUSBGecko.USBGecko.Dump(Dump dump)
   at FTDIUSBGecko.USBGecko.PokePatches()
   at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e)
Inner Exception: [/spoiler]

[Stuff]

nope. It happens to me sometimes. But not often enough to bug me. So never reported it. It happened yesterday. I'm using the 66.7 so it hasn't been dealt with. Interesting that it happens to you with gct codes...I guess that's what it's about. Just like you described it.
"Retry connect?"->no
"Error connecting blah blah blah. Would you like to retry?"-> >.> no
"Retry connect"->fffffffffffff no!
Vicious endless cycle. Must end task to close it.

It happens with a random disconnect which I thought was a me thing, but maybe gct codes are somehow associated with it. Strange...

Which reminds me. When my gecko 'disconnects' It's not really because it came loose or anything. I have to disconnect and reconnect the usb to get it to work again, but it doesn't do the usb sound until after I disconnected it. So I can't say it's my wire anymore. :/ I'll still blame it on these old wobbly front usb ports. Next time it disconnects randomly, I'll try reopening gecko.net instead of reconnecting the usb to see if that works. I'll try re-installing the driver also in case that's it.

Umm. What is that Taken/Not Taken in the BP tab?

[dcx2]

Taken/Not Taken refer to conditional branches.  If the conditional branch's condition is true, it will say Taken.  If it's false, it will say Not Taken.  You can click the button to toggle it if you want.

---

If your loader supports gameconfig poking, it can be used to install custom code handlers for all games, but it will probably break SD cheats (there is another gameconfig thing that might fix that part).  If anyone is interested in this, say something and I can make a post and release a tool.  Most loaders that support Brawl+ also support gameconfig poking.

[Stuff]

I don't get how gameconfig works, but this sounds interesting.

[dcx2]

If you look in the zip file that you get Gecko OS from ( http://geckodownloads.googlecode.com/files/gecko1931.zip ) then you'll see a docs folder.  In it you'll see "gameconfig file format.txt"  It describes all about how gameconfig.txt works, although not all loaders support all gameconfig features.  Most loaders support poke and some other stuff that's used for Brawl+.

gameconfig pokes are applied before control is passed to the code handler.  So you can just poke in a whole new code handler from scratch.  But it would screw up the code list.  But there's a gameconfig that relocates the code list too, but I haven't tried that.

The cool thing about gameconfig.txt is that it's located on the root of your SD card, so all the loader apps see the same file and would result in the same custom code handler.  The problem is that you wouldn't be able to shut off the debugger without modifying the gameconfig.txt.

EDIT:

I just tested it.  Using Gecko OS 1932, I set gameconfig.txt to poke the patched 1931 handler and redirect the code list.  Worked like a charm.

[Bully@Wiiplaza]

1.) I do a search on search tab
2.) Some results left, I switch to a different tab
3.) I somehow manage to crash the game that gecko.net loses connection
4.) I reconnect to the game (now the restart search button is disabled!)
5.) I need to perform another random search (with old results list)
6.) Now I can finally restart the search

Button greyed out glitch :p
Hope this is enough explanation.

Second thing:
You once said that you could speed up specific value searches, since there´s no need to compare everything.
Wouldn´t it be the same for any "first" dump and Pointer dump?
Thx.

[dcx2]

To speed it up, instead of returning the value of each address, I would return only the addresses that satisfied a specific equals condition.

Let's say you wanted to search for all the 3's in memory.  Normally, it dumps all of memory, and then searches for the 3's.  I'm considering a patch that would instead be told "okay, give me the addresses of all the 3's".  So if there were only ten 3's in memory, it would return 10 addresses (= 40 bytes) instead of 24MB.

This would ONLY work for a specific equals search with only one condition.  An unknown search requires a dump of every value so you can see who has changed.  A pointer search requires a dump of every value so you can see what pointers changed.  Neither of them could support faster dumping

[Bully@Wiiplaza]

can this be done with gecko.net?
At least it´s worth to try out that speeded up thingy ;D

[dcx2]

I'm working on a custom code handler that will be used to support other features like this quick-search and USB Gecko SE extensions.  Poking with gameconfig will be easiest, but I think you could also use Riivolution to easily swap out code handlers.  It will reduce the code space, perhaps by a lot depending on how things turn out.

[Stuff]

>.> Riivolution+usb gecko? Is that even possible? And swap out code handlers? XD. I look forward to that custom code handler.