Gecko dotNET Bugs and Requests

[Bully@Wiiplaza]

I don't provide support for backup launchers.
BTW, resize your Gecko.NET.  It isn't cleared, you just created a new line in the multi-line textbox.

You won´t only provide support for backup loaders, you will just support older gecko os versions.
It´s pointless to lose possibilities with geckodotnet, since people can always take the versions that are supported. *Makes life harder for no reason*
I prefer Gecko OS over Neo Gamma anyways. I don´t need disk backup launchers. If you won´t ever provide that older codeshandler support, though, I´ll just stick to previous builts that don´t have the compatibility disadvantage as long as I don´t need extended codes. Just my opinion on it, but you probably still won´t care. It´s your decison that is to be respected in the end.
@BTW. Thanks, that´s it. It was a good idea by you to add multi line search support.

[dcx2]

You don't get it, do you?

I have a real life, a job, a girlfriend, a house with a yard that needs mowed, etc.  I don't get paid to hack, so I take my time, and sometimes it takes a while before I can make a release.

I released .7 because I didn't want everyone to wait another week for me to port the patches to 1.9.3.2.  I could have just kept .7 to myself and not gave it to anyone, forcing everyone to wait even longer for the features I added to .7, like the GCT Code Undo shortcut and automatic extended code list support.  But I try to be a nice guy.

I primarily try to support 1.9.3.1, because that's the most common version of Gecko OS in use.  1.9.3.2 changed the address for just about all the debugger patches, and it takes some time to port the patches from one version to another.  If I supported 1.9.3.2 first, I'd have someone else bitching about how it doesn't support 1.9.3.1, because some people are never satisfied.

I also prefer Gecko OS, and the only reason I used NeoGamma is because I needed F2/F6 code support for hacking my GameCube games.  Gecko OS doesn't support GameCube games.  Gecko OS Mod doesn't support F2/F6 codes.

I will probably not add support for older versions of the code handler that don't support F2/F6 since WiiPower is updating Gecko OS Mod.  Adding support for older code handlers is non-trivial because the registers all changed, in addition to the patch addresses being changed.

[Deathwolf]

hmm dcx2 I have some bad problems with Gecko dNET.... I told you that long time ago.

1 BUG: When I freez my game cuz of poking a wrong address or wrong ASM code, I'm not able to connect anymore to the USB Gecko until I restart my PC.

2 BUG: The memory viewer.... When I click "Auto Update", the game freez after a few seconds for no reason ._.

3 BUG: The latest version of gecko dNET gives me an error "exe is defekt" or something like this. I redownloaded it and still doesn't work.

You said it's not USB 3.0...

How to fix that?

[dcx2]

I don't know why you have to restart your PC.  I never have that problem and I cause freezing all the time.  Try unplugging the USB and plugging it back in.

I don't know why memview auto-update gives you problems.  It doesn't give me any problems.

I don't know why you are getting the error.  Clearly it works for Bully since he's complaining about how it breaks 1.9.3.2.  I have not added any new libraries or anything.

[Deathwolf]

Yes idk why but unplugging the USB doesn't work too.
However hacking with WiiRd is not easy since gecko dNET is out.

[Bully@Wiiplaza]

hmm dcx2 I have some bad problems with Gecko dNET.... I told you that long time ago.

1 BUG: When I freez my game cuz of poking a wrong address or wrong ASM code, I'm not able to connect anymore to the USB Gecko until I restart my PC.

2 BUG: The memory viewer.... When I click "Auto Update", the game freez after a few seconds for no reason ._.

3 BUG: The latest version of gecko dNET gives me an error "exe is defect" or something like this. I redownloaded it and still doesn't work.

You said it's not USB 3.0...

How to fix that?

1) Idk why, this never happens to me.

2) This is because of the wrong hook type. Ossleepthread is not liked by any game, try to use VBI on the ones that freeze while auto-update.

3) No, the latest exe is fine as far as I know. Try to redownload in extract the whole package the right folder.
USB 3.0 is not supported anyways, so you could also use the original USB cable.

@dcx2:
I´m so sorry, I didn´t want to bother you or something like that.
Your work is appreciated and I was just wondering about the fact that you won´t *ever* make it somehow compatible, maybe without the extended codeslist support then, instead of freezing the game. I don´t need a new version until the 15th july anyways since I´m not at home during that time... even if I were.

[Deathwolf]

@Bully

2) it's wrong! I've tried every hooktype and it still freez ;)

[dcx2]

I was just wondering about the fact that you won´t *ever* make it somehow compatible

If you had read the release notes, you would know that support for the newer code handler was coming.

...
smaller debugger patches that aren't C2 codes anymore.  note: patches only work for 1.9.3.1 for now, I have to port them to .2 manually

[savage]

for some reason everytime i try and use 7 it freezes everygame i hook too... any ideas??

also i just talked to ropers and he is getting the same issue

[dcx2]

.7 requires Gecko OS 1.9.3.1 code handler.  There are a few patches that I make to the code handler to get rid of bugs.  One of the patches allows the code handler to be executed during a pause; without this patch, the game will freeze.

If you're having a freeze on 1.9.3.1, then make sure the debugger patches is checked on the about tab.\

EDIT:

I should add that this "executed during a pause" is the "old" pause; it's different from Gecko.NET's BPNext pause, which uses a breakpoint instead and does not crash.  Pause start uses the old pause, which normally freezes when it executes cheats because of a bug that now gets patched.  I was trying to make pause-start work with sending the Extended Codes Allocator, because the cheats are not executed if they are sent during a pause start, and the code handler doesn't run before the Allocator's hook is executed.  Quite the quandary there, so I had to fix execute cheats during pause start.  This was extra fun to debug on account of having to understand what the Gecko OS exception error messages meant whenever I would execute cheats.

Well, now that the execute-paused bug is fixed, I don't send cheats using BPNext pause anymore.  The old method of applying patches used C2 codes, so that it was easy to patch both 1.9.3.1 and 1.9.3.2, and it would send cheats when it attached to a running game to apply the patches immediately.  This is probably why it freezes without patches; it's sending cheats during an old pause, and then the cheats get executed.

The new method uses hand-crafted hooks and tucks the patches away at the very end of the code list so that it doesn't interfere with send cheats anymore.  It removes just 8 code lines now; previously the C2 codes used something like 20 code lines and required some degree of dancing to ensure that enabling and disabling and sending new cheats didn't screw things up.  I also made it look for existing SD cheats, since you can apply the allocator with SD cheats and I didn't want to get rid of it.

The new method is "installed" using only pokes, to make sure that the patches are installed safely without using send cheats at all, without worrying about whether the code handler has flushed and invalidated the branches, etc.

Ironically, the new method patches the debugger to make sure it runs itself after sending cheats, so the execute cheats that's causing the crash is probably unnecessary.  It will be removed in the next version, so hopefully this won't happen with unsupported versions.  But I'm also making patches mandatory for supported versions.

EDIT2:

Turns out there was another bug that would cause problems if you didn't have SD cheats.  I didn't catch it because while testing extended code list support, I was using SD cheats.  .8 should fix all the problems.

[Arudo]

Hmm. Don't know if this is a new bug with the .8 version or just something weird with the game I'm using.

Harvest Moon Animal Parade NTSC-U

I left the Auto-Update in the Memview checked and moved to another screen, which proceeded in causing the game to crash. Other than that no other issues as far as I can tell.

[dcx2]

This game has given you problems before, hasn't it?  Is there anything in your log folder that corresponds to the time when it crashed?

Can you reliably reproduce this bug by doing the following?

Start game.  Connect with Gecko.NET.  Switch to MemView tab.  Press auto-update.  Click some other tab (please note which tab).  Game crash.

[Arudo]

Okay. I've noticed that the game will crash when I'm changing locations that would require the game disc to load something, or events happenings.

Here's the log.

17:36: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.Dump(UInt32 startdump, UInt32 enddump, Stream saveStream)
   at GeckoApp.MemoryViewer.RedirectableDump(UInt32 startAddress, UInt32 endAddress, Stream dumpStream)
Inner Exception:

[dcx2]

Hmm, I tried reducing a time-out, maybe it's causing problems when disc loading is laggy.  I generally leave everything alone while the disc is loading, because I'm afraid of putting extra strain on it.  I've heard the motor go nuts during a pause or breakpoint sometimes.

[Arudo]

Yeah, I noticed that if I leave the auto-update off, things go fine.