|
Title: Gecko dotNET Bugs and Requests Post by: Mal1t1a on January 19, 2010, 12:08:54 AM WiiRd GUI
Bugs [2] 1. One of the bugs I've happened to notice in the GUI version, and I'm sure it's not just me noticing it, is that after awhile of searching, the GUI freezes up. Some of the buttons work, most of the controls are still active, however, none of them actually do anything. They just sort-of sit there, holding no functionality. I would search for something, the GUI would lock-up, I'd wait, it would still be locked up, the stop buttons still works, I click it, nothing happens, I click Restart, it asks me the questions, then it would clear the search (or not) and the GUI would still be locked up. 2. WiiRdGUI's "Next" button, even when set to 60 fps, sometimes appears to step over two frames instead of just one. Requests [7] 1. Search for "Same as First". After the first scan, you are given the option to see if the value is equal to the first scan. 2. Address Container. This is an Area where you can freely poke the Addresses, and ect. It's just so that you can continue to scan without having to lose a few address. Note, this is not the GCT list. 3. Some kind of option that allows you to update the Search List values, or a selected address(es). Most likely the Context (Right-Click) Menu. 4. An Auto Updater. There is a simple way to do so. You just build in a Check that will read the latest version from a file, and ask if you would like to update. Then you download the Auto Updater, and it'll auto update for you. I've done this in many of my 5. A built in Float to Hex Converter for poking floating point memory cells. 6. A Step Over button above Step on the Breakpoint tab. Step Over acts just like Step, except if the current instruction is bl or bctrl, in which case it will set an Execute Breakpoint on the instruction after bl/bctrl. This will let us skip functions without having to step all the way through them. Bonus points for not over-writing the current Breakpoint field and type. 7. Memory-viewer like snapshots, for the registers as well. Gecko dotNet Bugs [2] *fixed* 2. The GCT Code list seems like it's just a multi-line Textbox. When you edit codes, they like to mess up and bring codes from the line above where you were editing down, and it's a little bit of a hassle to bring them back up. *fixed* 4. GeckoDotNet's Auto-starting Gecko OS does not appear to work. It doesn't even initiate the countdown or start loading the game. You need to start Gecko form the Wii. Requests [6] *done* *done* 1. "Same as first" search type. This would be added after you make the first scan. 2. Being able to Manually Update the Value of an Address (not the Watch-List) in the Search List, or whatever one you choose. This can be done with the Context (Right-Click) Menu. 3. When you want to capture a Screen-Shot, You should have the option to choose where yo want to save them to, and as what file name (not file type). 4. A built in Float to Hex Converter for poking floating point memory cells. 5. An Auto Updater. There is a simple way to do so. You just build in a Check that will read the latest version from a file, and ask if you would like to update. Then you download the Auto Updater, and it'll auto update for you. I've done this in many of my 6. Memory-viewer like snapshots, for the registers as well. These are just my Bugs/Requests I've come across/came up with. If you guys feel something is wrong, or want to add your own, post here and I'll gladly add them. Fixed [3] 1. Some-how speed up the Search speed to atleast the same speed as WiiRd GUI. This was added into the latest Update of gecko dotNet Version 0.4 -block based search refining - VERY fast (outbeats WiiRd in most if not all situations) 2. Unable to save the Code-list for certain games. [N64] Kirby 64 (NAME). I believe this is because Gecko dotNet can not read the Game name. Gecko OS can do this though. It throws an exception at me saying that there are invalid Characters in the Path. I would assume it's because It couldn't read the Game Name. 3. When you play certain games (Like [N64] Kirby 64 (NAME)), the Notepad breaks, and throws an Exception saying Illegal Characters in path. Both of the above are fixed now. 2. Should be finally fixed (it actually copied null byte characters into the string) 3. Should be fixed along (also null-byte issue) Possible Solutions [1] An Auto Updater. There is a simple way to do so. You just build in a Check that will read the latest version from a file, and ask if you would like to update. Then you download the Auto Updater, and it'll auto update for you. I've done this in many of my The way I did it, was after 5 seconds from the program starting up, I created a new webclient, then downloaded a string from a text-file (lol I know), the string was a double, showing the current version (example: 0.61), if it was greater than the programs current version (a public double) it would tell you updates are available, and ask if you would like to update. If you said yes, it would check to see if the program called: "AutoUpdater.exe" was in the directory as the program, if not, it would download it, and when it's done downloading it, it would launch it, and close it-self. The AutoUpdater.exe would not do anything until the program was closed (process.exe). When it was closed, it would go online, and download a string containing all of the updates, and where to download them. After it finished downloading all of the updates, it would launch the process and it would be updated. Title: Re: A WiiRd bug/request (GUI) Post by: Romaap on January 19, 2010, 12:29:49 AM To solve some of those problems you could use Gecko dotNET, it won't freeze as much as WiiRD (or not at all).
Also, Gecko dotNET has a watchlist so you can add addresses to it and then update them a couple of times per second. I hope this helps you a bit. Title: Re: A WiiRd bug/request (GUI) Post by: wiiztec on January 22, 2010, 12:10:47 AM WiiRD has never locked up for me unless I do something that makes the game crash and then try to change tabs before I get my gecko rehooked to the game
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on January 23, 2010, 07:19:21 PM -nevermind-
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on January 23, 2010, 07:29:54 PM Um I'd rather you not ask to have my post deleted it still makes complete sense to me and it's a little rude to go around asking to have other people's posts deleted
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on January 23, 2010, 07:36:18 PM Sorry :( It's just that the topic changed a bit. They can stay if you want.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on February 15, 2010, 04:46:55 PM Requests -
A Step Over button above Step on the Breakpoint tab. Step Over acts just like Step, except if the current instruction is bl or bctrl, in which case it will set an Execute Breakpoint on the instruction after bl/bctrl. This will let us skip functions without having to step all the way through them. Bonus points for not over-writing the current Breakpoint field and type. Memory-viewer like snapshots, for the registers as well. Bugs - WiiRdGUI's "Next" button, even when set to 60 fps, sometimes appears to step over two frames instead of just one. GeckoDotNet's Auto-starting Gecko OS does not appear to work for me. It doesn't even initiate the countdown or start loading the game. I had to start Gecko from the Wii. EDIT: bug clarifications Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 06, 2010, 07:14:34 PM GeckoDotNet requests:
When using auto-update in the memory viewer, if I click on a different memory cell it returns to the previously highlighted cell immediately after that. On GCT codes tab, if you use the arrows keys to navigate codes, the code display doesn't update. It only updates on a mouse click. GCT codes tab, would a vertical scroll bar be better than a horizontal scroll bar? Integrated support with Link's AsmWiiRD? Perhaps right-click on a code, and it copies the code into the clipboard and launches asmwiird so you can paste it? Step on disassembler tab? Auto-preview on Screenshots tab? I've been considering CamStudio for some video tutorials and it would allow the recording to show what's going on in the game screen at the moment, even if it's only lke 0.5 FPS. Resizable window. This is a long and boring task but I would LOVE to be able to resize the window so I am definitely willing to go through and make the appropriate changes to the various controls' anchor and dock properties to make this happen, so don't worry about it. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Link on March 07, 2010, 09:13:48 AM Right-click -> Breakpoint on disassembler tab! <--- most important IMO In!When using auto-update in the memory viewer, if I click on a different memory cell it returns to the previously highlighted cell immediately after that. Fixed!On GCT codes tab, if you use the arrows keys to navigate codes, the code display doesn't update. It only updates on a mouse click. Fixed! That behaviour was on intention when the GCT list was very buggy.. right now, it seems much more reliable (FINALLY)GCT codes tab, would a vertical scroll bar be better than a horizontal scroll bar? Oopss... certainly! Fixed! (Stupid ListView style :p)Integrated support with Link's AsmWiiRD? Perhaps right-click on a code, and it copies the code into the clipboard and launches asmwiird so you can paste it? Difficult, but I'll see about it (not difficult because it's hard, it's hard considering the fact Gecko dNET should be cross-platform and AsmWiiRd is written in Delphi and thus Windows only)Step on disassembler tab? Would only work in breakpoint mode, I'll see about how it would be possible!Faster auto-update speed. WiiRD can do about 12 DPS I think, GDN does 4. In fact, super awesome would be the ability to slow down GDN from the max DPS, so that way you could sort of control the frame rate. Blame the .NET controls.. WiiRd uses a drawn component which acts quite fast.. if I disable output drawing in Gecko dNET I easily reach 25 DPS and higher.. I basically lose all speed at writing the output :(Auto-preview on Screenshots tab? I've been considering CamStudio for some video tutorials and it would allow the recording to show what's going on in the game screen at the moment, even if it's only lke 0.5 FPS. Phew.. that's an intesting one.. it would be hell slow for first, yes.. I personally HIGHLY HIGHLY recommend to get a video capture card! If demand is high for that feature though, I can add it!Resizable window. This is a long and boring task but I would LOVE to be able to resize the window so I am definitely willing to go through and make the appropriate changes to the various controls' anchor and dock properties to make this happen, so don't worry about it. [/quote] Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Link on March 07, 2010, 09:29:15 AM Bugs [4] 1. Unable to save the Code-list for certain games. [N64] Kirby 64 (NAME). I believe this is because Gecko dotNet can not read the Game name. Gecko OS can do this though. It throws an exception at me saying that there are invalid Characters in the Path. I would assume it's because It couldn't read the Game Name. 2. The GCT Code list seems like it's just a multi-line Textbox. When you edit codes, they like to mess up and bring codes from the line above where you were editing down, and it's a little bit of a hassle to bring them back up. 3. When you play certain games (Like [N64] Kirby 64 (NAME)), the Notepad breaks, and throws an Exception saying Illegal Characters in path. 4. GeckoDotNet's Auto-starting Gecko OS does not appear to work. It doesn't even initiate the countdown or start loading the game. You need to start Gecko form the Wii. 1. Should be finally fixed (it actually copied null byte characters into the string) 2. Hm.. actually it IS a multiline textbox... on purpose I should admit as the input box of WiiRd made my hair go up because: copy-cut-paste works horribly and such.. so I decided for myself to prefer that way. 3. Should be fixed along (also null-byte issue) 4. It's not really implemented yet.. I'd also like to see an option for Gecko OS to (finally!) use other hooks.. so far it doesn't do a thing other than waiting once you tell it to do! Requests [7] 1. Being able to step-through the frames in a game with the Pause Button. In WiiRd GUI, when you pause a game, you can click "Next" and it'll step through the frames. 2. Being able to Manually Update the Value of an Address (not the Watch-List) in the Search List, or whatever one you choose. This can be done with the Context (Right-Click) Menu. 3. When you want to capture a Screen-Shot, You should have the option to choose where yo want to save them to, and as what file name (not file type). 4. When using the Lower and Upper Search (Between these values search), I don't think there is a need to have the Comparison type, because you are looking for a value between the Lower, and the Upper. Which doesn't really have anything to do with the Comparison search. 5. A Step Over button above Step on the Breakpoint tab. Step Over acts just like Step, except if the current instruction is bl or bctrl, in which case it will set an Execute Breakpoint on the instruction after bl/bctrl. This will let us skip functions without having to step all the way through them. Bonus points for not over-writing the current Breakpoint field and type. 6. An Auto Updater. There is a simple way to do so. You just build in a Check that will read the latest version from a file, and ask if you would like to update. Then you download the Auto Updater, and it'll auto update for you. I've done this in many of my 7. Memory-viewer like snapshots, for the registers as well. 1. Done! 2. Sounds interesting, I consider that! 3. Will be added, so far it only gets the game name and basically sorts the files! 4. Well, the comparison types are there because in some rare cases you might need them.. I might remove the unneeded ones though automatically.. however, equal (between lower and upper (inclusive)) and not equal (NOT between lower and upper) will certainly remain 5. Well, I think we're talking about possible things here.. while stepping is handled on Wii side.. and the code handler simply has no "Step over" command.. I'll see if I can manually parse the assembly but yeah - as it just affects some commands it should be well possible.. it might be possible. Not overwriting the current Breakpoint field is simple though UPDATE: Implemented! 6. Cool thing.. yeah, I guess I can add this 7. Can you give me details? You mean saving the registers of the breakpoint in a list or something? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 07, 2010, 09:50:11 AM Requests [7] 5. A Step Over button above Step on the Breakpoint tab. Step Over acts just like Step, except if the current instruction is bl or bctrl, in which case it will set an Execute Breakpoint on the instruction after bl/bctrl. This will let us skip functions without having to step all the way through them. Bonus points for not over-writing the current Breakpoint field and type. 7. Memory-viewer like snapshots, for the registers as well. 5. Well, I think we're talking about possible things here.. while stepping is handled on Wii side.. and the code handler simply has no "Step over" command.. I'll see if I can manually parse the assembly but yeah - as it just affects some commands it should be well possible.. it might be possible. Not overwriting the current Breakpoint field is simple though 7. Can you give me details? You mean saving the registers of the breakpoint in a list or something? 5. You don't need to parse the asm too much. When you press "Step Over" look at the current ASM instruction, search the string for bl or bctrl, if you find it then set an execute breakpoint on the current address + 4 without updating breakpoint field, else just Step like normal. 7. WiiRDGUI's Memory Viewer will let you take snapshots ("Take Snapshot" button). Then later you can switch between the snapshot and current view ("Show Snapshot"/"Hide Snapshot" button). It's nice to toggle back and forth to see what changed. I'd like something exactly the same but on the breakpoint tab for the registers. This way, I could set a breakpoint and, say, pick up an item, take a snapshot, then go pick up a different item, and compare the two by flipping back and forth to see what other registers might be different. This could also help when trying to isolate some indication of whether we're processing a player or enemy (i.e. some register has a 1 for player and 2 for enemies or something) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Link on March 07, 2010, 09:58:33 AM 5. You don't need to parse the asm too much. When you press "Step Over" look at the current ASM instruction, search the string for bl or bctrl, if you find it then set an execute breakpoint on the current address + 4 without updating breakpoint field, else just Step like normal. 7. WiiRDGUI's Memory Viewer will let you take snapshots ("Take Snapshot" button). Then later you can switch between the snapshot and current view ("Show Snapshot"/"Hide Snapshot" button). It's nice to toggle back and forth to see what changed. I'd like something exactly the same but on the breakpoint tab for the registers. This way, I could set a breakpoint and, say, pick up an item, take a snapshot, then go pick up a different item, and compare the two by flipping back and forth to see what other registers might be different. This could also help when trying to isolate some indication of whether we're processing a player or enemy (i.e. some register has a 1 for player and 2 for enemies or something) 5. Exactly how I did it! 7. Ah, I see.. never used that feature! Yeah, I put that on my list of things to add! Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 07, 2010, 10:01:07 AM Thanks so much for all your hard work! ;D You're doing a fantastic job.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 07, 2010, 03:57:22 PM Auto-preview on Screenshots tab? I've been considering CamStudio for some video tutorials and it would allow the recording to show what's going on in the game screen at the moment, even if it's only lke 0.5 FPS. Phew.. that's an intesting one.. it would be hell slow for first, yes.. I personally HIGHLY HIGHLY recommend to get a video capture card! If demand is high for that feature though, I can add it!Some people (mabye me ;)) like to play the game at 0.5 FPS. It's rather good for glitching and such. =) Yes Link, you are doing a fantastical job. (Yes, I did just make up a word there :p). I still await feature developments! ;D Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 07, 2010, 04:35:01 PM I personally HIGHLY HIGHLY recommend to get a video capture card! Funny thing...I actually use a video capture card, (and two Wiis, and two TVs...we like screens!). But the desktop with the capture card is running ubuntu, and the laptops are running Windows. ...hey, need me to test a Mono build...? ;) Some people (mabye me ;)) like to play the game at 0.5 FPS. It's rather good for glitching and such. =) This is why I suggested a user-settable timer for auto-update on memory viewer, so you could slow the framerate down to 0.5 FPS, or 1 FPS, or 4 FPS, etc. It would be a lot more flexible than auto-preview for the purpose of slowing down the game. Hm...what if you could have the FPS somehow controlled by a gr or something which we could then change with a button activator? We could make our own custom bullet time! But you'd need a USB Gecko Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 07, 2010, 04:59:23 PM Bullet time would be cool, but just think on how bad it would be ;D All you do is just use massive amounts of the Wii's memory to get bullet time :P
It would still be a great thing to add though :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 07, 2010, 08:05:07 PM In the disassembly tab, when pressing left/up and right/down to scroll, it can't get past where the breakpoint's-disassembly-window. You need to use the scroll arrows on the side to get past the edge. I wish left-right would still work the same, but up-down would act more like the scroll bar's up and down. When setting a breakpoint, why does the cancel button get so big? Some changes to MemoryViewer.Update() - Code: public void Update() Those changes got me 11 FPS, 2-3x faster. The bottleneck is now Dump. --- I'm gunna start playing with the control properties to see if I can get everything to be re-sizeable now. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 09, 2010, 12:48:10 AM EDIT: Branch finder in the disassembly window. Enter a range of target addresses and it will scan up the disassembly, looking for branches that land in the target address range. Technically challenging but it would be SO satisfying to use. Find everyone who calls a certain function with bl. Find all of the execution paths that lead to a given instruction. The only problem would be that you couldn't parse blr or bctr or bctrl. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 11, 2010, 04:20:39 AM So I crossed off all the changes that Link and I have made so far. I also have more suggestions to add to this list...I keep coming back to this thread to see what else I can do.
--- EDIT: DifferentBySigned; so you can look for only a down-counting timer using differentBy -1 or only an upcounting timer with 1 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 12, 2010, 12:37:05 PM Instead of "differentBySigned", how about changing "upper" value searches to be more generic. Give "upper" a Comparison Type groupbox. Then, we could set lower to be >= and upper to be <=, inclusive, or exclusive if you use > or <. More interesting is using DifferentBy in combination with > or < to help find counters; DifferentBy 1 and < last value is always going down I think I've seen this before somewhere else, but if we added a "First" or "Cached" to complement the "Last", then there's even more flexibility in having the two groupboxes. A brand-new shiny combo box which can change the poke operation you're doing, idea courtesy of Dude (http://wiird.l0nk.org/forum/index.php/topic,3228.msg45134.html#msg45134). Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 12, 2010, 06:03:56 PM Combed the WiiRDGUI "Ideas for new WiiRD" thread for suggestions...
Load GCT From File, pops up an OpenFileDialog that lets us import codes from a GCT file. EDIT: Load gct files from geckocodes.org! The ability to copy the list of Breakpoint Conditions into the clipboard. Mostly useful if you have a list of addresses not to break on using SRR0 != conditions. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: GaryCXJk on March 12, 2010, 07:13:40 PM Instead of auto-updating I think the best would be a button to update the search results. Live updates will still severely slow down the game.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 13, 2010, 02:23:41 AM Hm...for the "next" button, the current mechanism is to "unpause, wait about 10+ ms, pause". Link has mentioned before that it wouldn't be too bad of an idea to set an execute breakpoint on the entrance to the code handler. Should the next button do that, instead, or are there good reasons to stick with the current mechanism?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 13, 2010, 03:16:04 AM You can always try, personally, I prefer the "unpause wait 1ms, pause" I've found that in my tests, 100 MS was wayy to much, and 1ms was perfect. I have not tried 10 ms. You guys just keep experimenting with stuff, and report back. if(betterway==True){ Msgbox("yay!") }else{ Msgbox("its okay!") }
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 13, 2010, 03:41:56 AM It's not 100 ms, it's 10 ms, but it's a call to sleep, which only promises to wait at least 10 ms. It usually will, but not always. So it's entirely possible you don't actually get to the "next frame", but like two or three frames after.
In contrast, breaking on the entrance to the code handler means that exactly one frame passes every time you hit next, no more, no less. And the processor will always be at the same point in the code when the game stops. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: elmoreas on March 19, 2010, 08:50:31 AM Not sure if it has been mentioned or if anyone else is having the issue but when I try to use the convert dec to hex radio button nothing happens, the button doesn't actually click nor does it convert the number to hex. Its not really an issue for me as I just use the Scientific mode on the PC calculator but dcx2 told me to drop by here if I ran into any issues while using Gecko dotNet. Other than that this works great and I am very happy with it, way to go. Since Wiird stopped working on WW/VC games for me this has been a god send so thanks again. Talk to you guys later.
Sincerely, Elmoreas Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Dude on March 19, 2010, 09:46:38 AM I've tried out Gecko.net and gotta say that it seems a lot more stable than WiiRD. I also have no issue with connecting with the GeckOS, too. Awesome work guys!
I have ran into an irritating bug though, I think. It seems that Gecko.net is removing valid finds in the found code list. I tested by doing a search in a small part of memory that I know isn't modified by anything at the time. I checked the values in the Memory viewer (the memory range I selected had about 6 sets of 32bit values all filled with FF) and did an 8bit equal search for FF. It found them all but when I refined the search it would decreases the found code list by one. It would keep decreasing everytime I refined until it reached down to one code found. I tested again using all search sizes (8/16/32) and even paused the game using the debugger but it always decreased the found code count by 1 and removed the last item in the list. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 19, 2010, 11:21:46 AM elmoreas - right-click the field you want to dec->hex. You can do dec->hex, hex->dec, float->hex, hex->float conversions from the context menu.
Dude - Hm...I'll look into this. EDIT: elmoreas - As it turns out, the Comparison type Value textbox does not have the conversion context menu attached to it. Right-click the Poke Value textbox to see the menu I'm talking about. I'll have this fixed for the next release. ^_^ EDIT2: O_O That dec -> hex box should only be enabled for DifferentBy searches...it turns out I wasn't properly disabling/enabling controls. That, too, will be fixed. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 19, 2010, 02:25:04 PM Wow, there's was a comparison that should have be <= and was only <. A very difficult thing to spot...and it didn't always appear to trim your search results. Good catch! The fix will be in the next release.
It appears there's also an odd bug where deleting an entry in the search results will cause the next set of refined results to be slightly different. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Panda On Smack on March 19, 2010, 02:59:21 PM Cheers guys, thanks for your hard work
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on March 20, 2010, 08:42:02 PM Adding support for version Digit ..
Game ID is the first 6 Digits . number 7 is Version Id .. 00 = 1 01 = 2 and so on .. this would help with sorting out some of the Multiversion games like Zelda and stuff .. cuz then we could know why codes dont work . :P if the version is diffrent .. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 20, 2010, 11:06:26 PM Gecko dotNet bugs:
When searching for the x amount of tries, when it is switch between blocks, it unpauses the game for the transition between one block and the other. This can be very bad, as sometimes that one little frame is very crucial to searching. It should always remain paused while searching. After you search and have many results, if you multi-poke alot of addresses, the "Restart Search" button becomes disabled. A rather minor inconvience, but is fixable by clicking: "Pause" then clicking "Run Game" Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 20, 2010, 11:57:32 PM When searching for the x amount of tries, when it is switch between blocks, it unpauses the game for the transition between one block and the other. This can be very bad, as sometimes that one little frame is very crucial to searching. It should always remain paused while searching. Are you using the latest Gecko dotNET? This should have been fixed in 0.51. I check if the game is Running and if so, I Pause it during the search and Resume afterward.In any event, Pausing the game before searching will keep the game paused even after the search finishes. Quote After you search and have many results, if you multi-poke alot of addresses, the "Restart Search" button becomes disabled. A rather minor inconvience, but is fixable by clicking: "Pause" then clicking "Run Game" Hm...multi-poke disables the Restart Search button? I haven't actually used multi-poke yet...does it always disable the button, or only sometimes? Do you need to multi-poke a certain amount of addresses? I know 0.51 has a small issue with controls being properly disabled, but they usually end up enabled when they shouldn't be, not the other way around.Adding support for version Digit .. I can look into this, but in the mean time, if you to go address 80000000 and switch the Memory Viewer to ASCII View mode, you will see the Game ID at the very beginning.Game ID is the first 6 Digits . number 7 is Version Id .. 00 = 1 01 = 2 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 21, 2010, 12:01:51 AM Are you using the latest Gecko dotNET? This should have been fixed in 0.51. I check if the game is Running and if so, I Pause it during the search and Resume afterward. I am using the Latest version of Gecko dotNet, and this only happens while the game is unpaused and you search (or atleast from what I notice).In any event, Pausing the game before searching will keep the game paused even after the search finishes. Quote Hm...multi-poke disables the Restart Search button? I haven't actually used multi-poke yet...does it always disable the button, or only sometimes? Do you need to multi-poke a certain amount of addresses? I know 0.51 has a small issue with controls being properly disabled, but they usually end up enabled when they shouldn't be, not the other way around. I just poke a whole page worth of addresses, and it does so.Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 21, 2010, 12:21:22 AM I am using the Latest version of Gecko dotNet, and this only happens while the game is unpaused and you search (or atleast from what I notice). That's really odd...this is the search code. Code: public bool Search(UInt32 sAddress, UInt32 eAddress, UInt32 lValue, UInt32 hValue, Maybe Pausing and Resuming doesn't work on yours? The Pause/Next button doesn't actually use gecko.Pause()/gecko.Resume(), but instead it breaks on the entrance to the code handler, because that's more reliable for single-frame stepping. Go to the About page and check the "Slow" button - that uses pause/resume. Does the game slow down? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 21, 2010, 12:24:32 AM Yes it does slow down, and no that's not what I mean. What I'm talking about, occurs during the Searching Process. When it's jumping between blocks.
Example: Search: while it's searching in a block, once that block is done being search, the game unpauses until it switches to the other block (which is about 1ms). Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 21, 2010, 12:50:34 AM Yes it does slow down, and no that's not what I mean. What I'm talking about, occurs during the Searching Process. When it's jumping between blocks. Example: Search: while it's searching in a block, once that block is done being search, the game unpauses until it switches to the other block (which is about 1ms). Yes, I know the bug you're talking about. Panda pointed it out a few days ago here (http://wiird.l0nk.org/forum/index.php/topic,4886.msg45243.html#msg45243). The game steps forward a few frames in between the blocks if doing a block search on more than one block. You shouldn't be experiencing it, though. See the code block I posted? I pause the game before starting the search and resume afterward. I asked you to try the Slow option because I wanted to see if there are any other reasons you might be experiencing this bug (like, for some reason, pause/resume don't work for you, in which case Slow wouldn't work either). Because I know I'm pausing the game before searches. I tested it myself, and the game didn't stutter during block searches any more. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 21, 2010, 02:12:51 AM ....oh my. It turns out that when I'm in Visual Studio Express and I hit the "Play" button, it launches the Debug build, which is built without optimizations. However, if you hit "Build" instead of "Play", it builds a Release version with optimizations. I think that, somehow, the call to pause is being optimized out.
When I test the Debug build, I pause between searches just fine. However, when I test the Release build...the sssstutttter is there again. I will look into this further. Thanks, Mal1t1a...the fascinating thing about computers is that we can both be right and wrong at the same time... EDIT: Okay, so it turns out that the optimized version is just...too fast? The call to Pause() is actually made, but the game doesn't always pause...it's like it takes a while to pause. Maybe you have to wait a while after calling Pause() and the Debug version is just that slow, while the Release version is just that fast. Regardless, it now loops repeatedly until the game actually pauses before doing the search. Hooray beta testers! ;D Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on March 21, 2010, 08:03:05 AM Adding support for version Digit .. I can look into this, but in the mean time, if you to go address 80000000 and switch the Memory Viewer to ASCII View mode, you will see the Game ID at the very beginning.Game ID is the first 6 Digits . number 7 is Version Id .. 00 = 1 01 = 2 I know about the game ID .. as u can see i Said Version ID not Game ID version ID is the 7th Digit after the Game ID (80000007 = Version ID in Hex) Look at Zelda if u have the Fixed version u will notice its 01,02 and the one that was released befor all the junk is 00 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 21, 2010, 09:42:40 PM Gecko dotNET Bug:
Covert Dec to Hex Button does nothing. Gecko dotNET Request: Search by more than one type. Example: Have a ComboBox that allows you to Select the Type of Search, and in it, have Whatever types. At the moment, I'd say: Hex, Float, and Decimal. This would make hacking games (or atleat for me) soooo much easier. Almost 10 times easier. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 21, 2010, 10:36:21 PM Covert Dec to Hex Button does nothing. That button is going away. It is being replaced by a right-click context menu that can do dec -> hex, hex -> dec, float -> hex, hex -> float. Actually, that button and the textbox next to it are only for Different By searches. They should be disabled if you aren't doing a Different By search, but that's a bug I accidentally added while trying to improve the ability to turn the form's controls on and off. It has been fixed for the next release. In 0.51, the context menu wasn't associated with the text box beside that Convert Dec to Hex button. In the next release, that context menu will be properly associated. If you want to see the menu I'm talking about...actually, I'll get to that with your next question. Quote Example: Have a ComboBox that allows you to Select the Type of Search, and in it, have Whatever types. At the moment, I'd say: Hex, Float, and Decimal. This would make hacking games (or atleat for me) soooo much easier. Almost 10 times easier. In 0.51, right-click the text box for the search value ("Lower value info"). The context menu I mentioned above will pop up. Using this menu, you can put 0.3333 in the text box and then change it to the hex representation of that float and search for that float...I've used that a few times already. That context menu is also available for the Poke Value (not Address). Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 21, 2010, 11:46:19 PM In 0.51, right-click the text box for the search value ("Lower value info"). The context menu I mentioned above will pop up. Using this menu, you can put 0.3333 in the text box and then change it to the hex representation of that float and search for that float...I've used that a few times already. That context menu is also available for the Poke Value (not Address). That's good to know, but not what I'm talking about. What I'm talking about, is searching and displaying by Float. So that Greater Than and Less Than Searches can be done on Float Values. Not convert to float (which is exactly what it is, just different). Sorry I didn't make that more clear. It would be nice if it could be that easy, is all I'm saying :smileyface: Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 22, 2010, 12:35:46 AM I think I see...so like, the Lower value info box has 32-bit, 16-bit, and 8-bit. Add "float" to this list?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 22, 2010, 12:38:18 AM It's like the Memory Viewer: "View Mode -> Hex | Ascii | Ansi | Unicode"
[Edit] Also, are you guys going to be hopefully adding Manual Updating to the Selected Addresses in the Search area? Like I've mentioned before, it can be done via Context Menu. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 22, 2010, 01:21:19 AM Manual updating...not sure what exactly you mean. You can delete results, though I think it's a little bit glitchy in 0.51.
Do you mean, instead of searching through all of the addresses when you click search, only search through the range that's highlighted? That's an interesting idea... Regarding your float thing, I think I follow you less now. Instead of searching for all ints that are less than 33, you wanted to search for floats less than 33.33, right? Also, searching for equals on a float is a bad idea. You need to do this thing called "fuzzy equals", which is actually a lot more like "different by less than" than it is equals. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 22, 2010, 01:35:57 AM By updating the Address I was talking about, Updating the Value of the Address.
Here is an Example of what I mean: You Select the Addresses you want to Update in the Found Addresses Area. (http://www.Mal1t1a.com/Downloads/example1.png) You then Right Click and Select "Update Value" (http://www.Mal1t1a.com/Downloads/example2.png) It will then Show you the Updated Values of the Selected Addresses. (http://www.Mal1t1a.com/Downloads/example3.png) I hope the Diagram Helps you understand what I mean. :) Regarding your float thing, I think I follow you less now. Instead of searching for all ints that are less than 33, you wanted to search for floats less than 33.33, right? Also, searching for equals on a float is a bad idea. You need to do this thing called "fuzzy equals", which is actually a lot more like "different by less than" than it is equals. Yeah, like say I did an Unknown Value Search. If I were to do a Less Than Search, then it would only calculate addresses that have the Hexadecimal Value lower than the Previous. Here's another Example: The Address of 811AC658 had the Float Value of 1200 (44960000 in hex), and then The next time it changes, I scan for a Less Than, and the Float Value is now -1200 (C4960000 in hex). It would remove 811AC658 from the Found Addresses because it's Hexadecimal Value increased (Even though for a float it is decreasing). A Possible Solution could be: Code: if(viewmode=="float"){Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Link on March 22, 2010, 04:43:22 AM Yeah, like say I did an Unknown Value Search. If I were to do a Less Than Search, then it would only calculate addresses that have the Hexadecimal Value lower than the Previous. Here's another Example: The Address of 811AC658 had the Float Value of 1200 (44960000 in hex), and then The next time it changes, I scan for a Less Than, and the Float Value is now -1200 (C4960000 in hex). It would remove 811AC658 from the Found Addresses because it's Hexadecimal Value increased (Even though for a float it is decreasing). Hm.. I get it.. however, not a float search would really help there (a float search indeed would not be easy as the inner core only handles integers during searches).. A feasible idea would be to allow the search for signed integers.. C4960000 is unsigned 3298164736 so indeed it is magnificently higher than 44960000 (1150681088). However, if allowing signed searches then C4960000 would be counted as -996802560 - and thus lower. That wouldn't allow searching for floats yet, but it would work for unknown searches and at least in the current build it would be easier to add! If that would be okay for you! Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 22, 2010, 11:42:22 AM a float search indeed would not be easy as the inner core only handles integers during searches I was thinking about this...all we'd have to do is add another bool to MemSearch::Compare(...). If the bool is true, then we can cast the integers "given" and "loExpected" to floats and return the comparison result. None of the other code needs changed, except a way for the user to specify what type of search they're doing, and that can be derived from the selected index of whatever combo box we use. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 22, 2010, 01:10:51 PM Version digit - I'm hesitant to make a change to the game name because there are other consequences than just the text that appears at the top of the window. For instance, the name of the GCT file is derived from the game name. Also, some time in the future I would like to add integrated support with the web site, and any changes to the game name would interfere with that as well.
If acceptable, I could try to selectively add "Version x" to *only* the title bar, but nothing else. But I would also like a chance to try this out before releasing it into the wild, and I have no versioned games that I'm aware of. :-\ -- Multi-poke-restart-disabled bug....I couldn't get this to happen. Learning from the previous lesson, I made sure to use the binary Link released, but I multi-poked every address on a page like 5 times and Restart Search was always enabled...were you doing a specific type of search when this happened? Unknown, last value, specific? Equal, not equal, less than, different by, etc? -- Regarding manual updating, this isn't exactly what you specified, but if you select a bunch of search results and right click -> add to watch list, you can see the values updating in real time with a selectable interval without changing the search results. It is much more powerful than that though... 1) You can also change the view type, so you can see the values as floats or 32- or 16- or 8-bits. 2) You can also rename them, so in addition to the address you see "x velocity" or "y height" or "health" or whatever. 3) You can provide offsets from a pointer to watch. You can even do multiple indirections - pointers to pointers to pointers... Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on March 23, 2010, 01:23:28 AM Version digit - I'm hesitant to make a change to the game name because there are other consequences than just the text that appears at the top of the window. For instance, the name of the GCT file is derived from the game name. Also, some time in the future I would like to add integrated support with the web site, and any changes to the game name would interfere with that as well. If acceptable, I could try to selectively add "Version x" to *only* the title bar, but nothing else. But I would also like a chance to try this out before releasing it into the wild, and I have no versioned games that I'm aware of. :-\ Its all good most games are goin to be version 00 since 90% of them have not been rereleased .. Final Fantasy CC has 2 versions Zelda twilight might have 3 versions . Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 24, 2010, 01:07:33 PM Skiller - the next release will have support for the version digit. It only affects the title bar and only shows up if the 7th digit after the start of the name is not 0. I fake tested it in the debugger but it would be nice if you could test it for real.
Mal1t1a - I added float comparisons to the Lower value info search type combobox. It now says 8-bit, 16-bit, 32-bit, and Single. The search results are still in hex (...for now?), but the actual comparisons are performed on floats. It does not respect the value in Upper value info. It should work with DifferentBy searches. FYI, the Exact checkbox on the Breakpoint tab wasn't fully functional in 0.52. It *looked* like it was, but it wasn't. So if it doesn't appear to work yet, that's why. Also, if you delete search results, do it one at a time. Deleting multiple search results was more complicated than I initially thought and 0.52 does not perform it correctly. -- I also have a few new features ready. Rather than annoying Link with requests to update the binary, I'm considering using mediafire to throw up "nightly builds", and then Link can release "official builds" when he has time to double check stability. Is there any interest in this? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 24, 2010, 03:44:33 PM Well that is atleast a start. However, it would be nice to show the search results in Floats(Singles) but oh well. I don't use the Upper Value to search so I'm okay with that. As for the Delete Search Results, It's not that easy? It seemed like it was. Couldn't you just assign a hidden value to each Search Result? Say, Index ID and just do a really bad RemoveAt Statement?
As for the "Nightly builds" idea, I think it is great, that way we don't really have to rely on Link being here :P Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 24, 2010, 04:10:32 PM However, it would be nice to show the search results in Floats(Singles) Since the Watch List can display watched variables as floats, and you can highlight a bunch of search results and throw them into the Watch List, I don't think I'll be reworking the search result grid view to support float representations any time soon. I'll still add your request to the "eventually..." list. Quote As for the Delete Search Results, It's not that easy? When you delete multiple selected rows, the Deleting event is raised once for each row. But the deleted row indices are not updated in between deletes! So if you delete rows 1, 2, and 3, it will: delete row 1, slide the remaining rows down, and then attempt to delete row 2, but since row 2 is now where row 1 was, deleting row 2 actually deletes what was row 3. Similarly, when it goes to delete row 3, it actually deletes what was row 5. The solution involved ignoring all but one of the multiple Deleting events, and for the one that's not ignored, deleting the selected indices from the results list. Then I had to find the first and last index so I could use RemoveRange. Well, if you drag the mouse down, the SelectedRows[0] actually holds the *last* index, not the first. (hmm...RemoveRange won't work if there are "gaps" of unselected rows between two sets of selected rows...looks like I'll have to do a loop starting from the last index and working backwards) And then there's the "current cell" which is the cell that has the keyboard focus, and when you change the selected cell, the current cell doesn't change. And so on. Quote As for the "Nightly builds" idea, I think it is great, that way we don't really have to rely on Link being here :P I am all for throwing them up, I just don't want to step on Link's toes 'cos gecko dotNET is 99% him and 1% small contributions by me. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 24, 2010, 06:16:27 PM Couldn't you do something along the lines of this? (VB.NET Code):
Code: Dim SomeArray As New ArrayList C# Code (I hope this works, I haven't tested it): Code: List<DataGridViewRow> SomeArray = new List<DataGridViewRow>(); This of course is when I set the SelectionMode to: "FullRowSelect" Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 24, 2010, 06:36:57 PM There are two problems with that approach.
First, each time you do RemoveAt(), all of the remaining rows after the deleted row will shift closer to the 0th index. So if you delete row 1, rows 2:n become rows 1:(n - 1). To delete row 2, you'd have to delete row 1 *again*, because after deleting an element, the new row 2 is actually the old row 3. Second, the search results are stored as a List<SearchResult>, and one page at a time is loaded from this backing store into the DataGridView. Deleting individual elements from the DataGridView does not delete them from the backing store. That's why I had to over-ride the DataGridView.Deleting event, so that it deleted from the search results list instead of the DataGridView, and then repopulates the DataGridView with the modified List. Now, your general approach is a good one, it just needs one tweak. SomeArray will hold row indices, and will need to be sorted descending. Then, I can go through the List, and starting from the highest indices, I can start deleting without worrying about changing the index of the rows I'm trying to delete. So, if I'm deleting elements 1, 2, and 3, when I sort descending the array will contain 3, 2, and 1. Then I will delete element 3, and rows 4:n will become rows 3:(n - 1), leaving elements 2 and 1 in the same place so that they can still be deleted. EDIT lol, I totally missed this part. You're getting the new index based on a cached copy of the selected rows. dataGridView1.Rows.RemoveAt(dataGridView1.Rows.IndexOf(item)); This makes problem 1 fuzzier, but still doesn't get around problem 2. The List probably has an IndexOf method, as well, but I'm still leaning towards start-deleting-from-the-end. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on March 24, 2010, 06:56:49 PM Maybe you could do it something along this lines:
Code: for(int i = 0;i > number_of_results_to_delete;i++) I dont know how you get the selected results, so i just left that out. :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 24, 2010, 06:58:59 PM Which is why I said "something like this" :) It was just supposed to be a general Idea. Now, would you be-able to modify the SearchResults based upon the Rows? You could store the Values and do an IndexOf() operation, which would sort them separately by the Values (if that is how the SearchResults work).
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 24, 2010, 07:38:37 PM Romaap - your solution would work when the SelectedRows are one contiguous block, but if you used ctrl + click to select multiple (EDIT: non-contiguous) results, it will get very confused. This is the same problem as the current solution (well, not really current, since 0.52 doesn't have these changes yet...), which is to find the first and last indices in the selected row and then use List.RemoveRange() to get them all at once.
Mal1t1a - I could reconstruct the SearchResult from the values in the DataGridView's Row and then pass that to List.IndexOf(). But traversing the List in search of the index of a given value is probably an O(n) operation, and if you put that inside another loop, the deleting event becomes O(n^2)... I probably shouldn't be worried about the performance implications too much, especially since deleting one element at a time is probably going to be far slower than using RemoveRange(). Thanks for having this nice discussion with me. ^_^ Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 25, 2010, 04:00:23 PM I'm sure we can sacrifice some speed optimization for quality. :)
Also, I would REALLY like the "Single" searching soon ;) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 25, 2010, 04:04:25 PM I posted here (http://wiird.l0nk.org/forum/index.php/topic,4886.msg45635.html#msg45635) with a link to the Nightly Builds folder. That test release is for you and Skiller, so you can test your Single search compares and he can test the Version digit. It also has other new features too...Show Mem button, conditional branch detection/toggling, and some more.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Jackal on March 25, 2010, 06:30:33 PM for the scollbar issue I mentioned in the release thread
the keyboard arrow keys are working as they should but the scrollbar arrows move 2 lines when I click them but if I click the arrow and move the mouse away it will only move 1 line if I leave the cursor on the arrow it will move 2 lines really dont understand why I am having this weird problem. btw, I am using win7 64bit. I have tried changing the compatibility mode but still the same Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 25, 2010, 06:41:45 PM Windows 7, you say? Interesting...I'm using XP.
More interesting is the fact that it sounds like the Scroll event is firing on Mouse Down and Mouse Up. Or it thinks you're holding the mouse down for long enough to keep scrolling. You can try clicking a blank area of the form, and then moving the mouse over top of the scroll button, and releasing. If it's catching Mouse Up then you'll see it scroll. If you're up for it, I can make a special build with diagnostic messages that pop up when you press the scrollbar buttons. That might also help narrow down the problem. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Dude on March 25, 2010, 07:09:09 PM I also have Windows 7 64bit.
I've never noticed this scroll bar issue myself. I'm using a laptop and my touchpad will occasionally detect a click\double click where I'm trying to move the cursor quickly across the screen - nothing related to the app though. It does sounds like your mouse button might be dying though. I once had a REALLY old mouse that would double click due to the button being worn. Do you have another mouse that you can plugin in and try? Or, you could swap the right and left mouse buttons using control panel. This will make your RIGHT mouse button act like your LEFT mouse button. Give that a try using the other mouse button and see if it still scrolls twice. This, or another mouse, should help rule out any hardware issues. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 25, 2010, 08:18:14 PM dcx2, great job! The Single searching works great as far as I can tell! However, there is a bug with the Searching, remember the last one? It would randomly unpause with it switching between search blocks? Well this one is a minor Bug, but still a bug. When you do an Initial Search, if the game is Unpaused, and you scan, it pauses the game, like how it should, but after the Search is done, the game remains to be pauses, and the Pause button says: "Pause game" which leads me to believe that the game "should" be unpause but isn't, I have to click Run Game, or click the Pause button twice. Just a minor bug, I'll report back with more if any!
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 25, 2010, 08:36:10 PM Dude/Jackal - hmm...you know, if your mouse is double-clicking when it should single-click, in theory that could be what caused the disassembler to crash the game...
Mal1t1a - Remember how I said calling gecko.Pause() sometimes wouldn't actually pause? I had to loop-until-paused. I was afraid that Resume() would suffer a similar flaw. Tonight I'll add loop-until-resumed and we'll see if that fixes your issue. In fact, I'll probably add "SafePause()" and "SafeResume()" that hide the looping business from the caller. Glad to hear Single searches are workin' for ya. 8) I'm considering adding more columns to the search results grid view. You'd have to resize the app to see them, but I'd like to add a "Difference" column which shows (old value - new value). Would work great with sorting... If that works as planned, I should be able to add "old float" and "new float" columns. You'd still see the hex values first, but if you resized the window you'd also see the float values. I think this would be sufficient for your purposes, yes? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mal1t1a on March 25, 2010, 08:42:33 PM It's not that big of an issue though :P
Sounds great! I'm doing just fine with seeing only the Hex Values, begin able to see the Actual Float values is another plus! ;D Keep it up! Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Jackal on March 25, 2010, 09:03:48 PM I dont think my problem is due to my mouse (I am using desktop)
It works perfectly on other apps only gecko dotNet is having this problem... anyway, this is just a minor issue (that only I encounter) I can live with it you guys should probably spend time on more important stuff Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Dude on March 25, 2010, 09:06:04 PM I solved the issue of my touchpad double clicking long before using wiird/gecko.net - turned off "tap pad to single click" O0
I think it would be best to rule out any potential hardware issue before assuming that it might be software related. just think it would be easier for you developers and it's simple enough to check for ;) I have been getting a crash and some odd activity with a specific game though: Playing the game De Blob (pal) i have found that when the game is paused by the debugger (searching or using the pause button) the in-game music continues to play. not sure if this is due to a bad hook, but can check. The debugger would also crash and give an error message - lost my notes on this though so I'll be going through the steps I took for this to happen as soon as I can and give all the details. I'll also take the chance to have a closer look and see if I'm getting that scrolling problem but just not noticing. If I find that i'm getting it then it might be something to do with Windows 7, who knows :p Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 25, 2010, 09:22:44 PM Some games, particularly newer ones, have a separate thread for playing music. I was pleasantly surprised when I went to hack Tales of Symphonia and the music kept playing when I paused it, because that awful sound startles me every time. You should double-check with the original WiiRDGUI to see if the music keeps playing when paused.
When you say the debugger "crashes", what exactly happens? Do you see an unhandled exception? Does gecko dotNET ask you to reconnect? Does the game freeze? If it freezes, and you reconnect, does the game un-freeze? Thanks for your help, btw. Your stunning detail in describing buggy scenarios (like the vanishing search results) is an immense help in narrowing down the bug. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on March 26, 2010, 12:47:31 AM the version number for wiiware and VC games is offset 6 if im looking at this right ..
HCFE=Wii Speak Channel 2.0(NTSC) _________ 45464348 0002FFFF _________ the 0002 is the version numbers .. o and dont know if this will help u guys but iv finished the NTSC Gamelist for wiird .. might be able to convert it to this apps Format http://www.codemasters-project.net/guides/showentry.php?e=279 download the gameslist only game that is Redsteel 2 Do hope this helps :P Note is has some Pal but not all of them .. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 26, 2010, 02:45:07 AM Gecko dotNET 0.52 Test Build r41 (http://www.mediafire.com/?nzgmgzg1xzi)
release notes -Added "View Mode" to search results. Options are hex, decimal, and single. -Added "Change" column to search results. new value - old value -Added "Step out" to breakpoint tab. Repeatedly calls Step Over until it reaches blr -Search-Pause-Resume finally works the way it should. Honest. >.> <.< No, really, I mean it this time. ... *crosses fingers* Skiller - Actually, that would be offset 5, because we start counting from 0. I'm wondering (hoping!) that the 00 before the 02 is actually a null byte terminating the previous string. If you could provide me with the first EDIT: Doh, meant to post this in the release thread, not bug requests... Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on March 26, 2010, 03:47:10 AM Gecko dotNET 0.52 Test Build r41 (http://www.mediafire.com/?nzgmgzg1xzi) release notes -Added "View Mode" to search results. Options are hex, decimal, and single. -Added "Change" column to search results. new value - old value -Added "Step out" to breakpoint tab. Repeatedly calls Step Over until it reaches blr -Search-Pause-Resume finally works the way it should. Honest. >.> <.< No, really, I mean it this time. ... *crosses fingers* Skiller - Actually, that would be offset 5, because we start counting from 0. I'm wondering (hoping!) that the 00 before the 02 is actually a null byte terminating the previous string. If you could provide me with the first EDIT: Doh, meant to post this in the release thread, not bug requests... Just like IOS the games can have upto version FFFF :P its a STH Most of my games are all version 1 .. :P Guitar Hero 3 V2 5247484535320001 Alone in the Dark 52524B4537300001 Birthday Party 5232594535340001 Cosmic Family 5243464534310001 Mario Party 8 (i know there is more then just 2 versions of this one . 524D384530310001 WiiSports 5253504530310001 The Legend of Zelda Twilight Princess (Ver 3) 525A444530310002 Game Party 5247584535440000 <-- Version 1 5247584535440001 <-- Version 2 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Dude on March 27, 2010, 02:35:08 PM @dcx2:
thanks for the compliment ;D Guess it's my perfectionist side really. I've tried pausing De Blob using WiiRD and the music continues in the same way, so no problem there. I've also looked a little more into that scrolling problem. It only scrolls down one item with the cursor keys and by clicking the down arrow on the mouse. I don't know how much more I can help though, sorry about that. I've not been able to get Gecko.net to crash like before but I remember that it was while I was hacking De Blob. It brought up a box saying about lost communication with Geckos. I think I was using codes at the time while I was searching, too. Most times it froze my wii and I had to restart by holding down the power button. the likely scenario is that Geckos or my Wii froze, thereby causing the loss in communication. I'll be able to give more when I get it to happen again lol I think that this has been mentioned before but when right-clicking in the found search list it would be easier if the item under the cursor at the time of the click is selected. Currently I need to select the item first, then right-click to bring up the pop-up menu. Also, would it be possible to be able to select items in the found search list and copy them to clipboard for pasting into a text document? I know that you can save searches but they are stored in binary format. I do a lot of notes and work in notepad and being able to select one or more items and copying them would be ideal ;D Mainly just the addresses would be good, but old and new values too would be great. Maybe in the form of a sub-menu with a list of copy actions. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on March 27, 2010, 03:52:05 PM r43 is in the wild!
Skiller - Please test the version digit. I tried my Wii Sports but it's version 1. It should work for VC games and Wii games this time. Panda - You can resize your columns now. It auto-sizes (increase or decrease) when you change the view mode, and it will increase column widths after filling the Search Results but will not decrease them if you changed the size to larger than necessary to hold the contents. You can also double-click a column divider to auto-size (inc or dec) that column's width. If there are any instances where the column widths should change size and they don't, let me know. I have to manually call auto-size on them, because if the CLR calls auto-sizing then it won't work with user-resizing...and CLR auto-sizing slowed things *way* down. Dude - If you see that dialog box pop up, try the disconnect and reconnect buttons. Try hitting the Run button after reconnecting. Try unplugging the USB, shutting down Gecko.NET, then plugging USB back in and restarting it. Most of the time when the game looks like it's frozen, it's not truly frozen, it's just paused or at a breakpoint. Gecko.NET is pretty robust in terms of handling errors. Your fixes are in, too. It's interesting that you use Notepad...I use OpenOffice's word processor, because I find it much easier to copy/paste a screenshot and annotate it. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Dude on March 28, 2010, 01:43:27 AM Hmm, I didn't think to check if I could get the game to resume. but it seemed like a complete Wii crash. i'll still take down all the details of it next time and try to recover things in the ways you said.
I use notepad for simplicity. I like to copy a bunch of valid addresses, even if I don't use them, and use them with other addresses to picture a "structure" of the memory space. It helps me figure out where other values might be, etc. I also like to have a textfile full of my results for storage and easier manipulation :p Thanks for the fixes and updates. I'm going to download and see how they go. Thanks dcx2! -------- EDIT -------- I've tried out the new release. Those little fixes sure make life that little bit faster and simpler :p Many thanks for that. I have noticed a new column in the results list. Value difference? Good thinking to whoever suggested that. It does seem to be showing the difference between the new and old values SOME of the time, but not always. Here are a few examples copied straight from the result list using that newly included "copy to clipboard" function (thanks dcx2! ;D) Address Old New Diff 808A7F48 BED67770 00000000 41298890 81129C14 00000020 0000001A FFFFFFFA 81129C20 00330032 00320036 FFFF0004 804A9FB4 D868AFAD 9B253F34 C2BC8F87 804C23CC BD75C28F BD23D70A FFAE147B 804C23D0 BF800000 BF7B0775 FFFB0775 804C23D8 3F803AEE 3F7B49BD FFFB0ECF 804C2414 3F7FFB74 3F7FF67E FFFFFB0A 800000D8 90670918 00000000 6F98F6E8 804A9FAC 80B196E9 196D3E9C 98BBA7B3 804A9FB4 80B819F5 1973E7E7 98BBCDF2 The differences in these don't appear correct. I first noticed the oddities during an 8bit scan. I might just be assuming that the column is a calculation of the differences between new and old values, but about 20% do show a correct difference calculation, but most don't. Also, the copy function works through the CTRL+C option, but maybe an inclusion in the right-click pop-up menu? This would just help to make it known to users that the function is there :) Only a minor suggestion though. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 01, 2010, 01:20:41 PM lol, post edits don't send notification emails. x.x The difference column was actually a personal idea. ^_^ I'm glad to hear that Gecko.NET has improved your hacking experience.
All of those differences look good to me. It's signed, so switch view mode to dec and you'll see they are correct. For instance, new - old = diff 0000001A - 00000020 = FFFFFFFA If that seems wrong, then you should google "twos complement". (aka "flip the bits and add one") FFFFFFFA = -6. 00000000 - BED67770 = 41298890 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on April 05, 2010, 05:01:29 AM I'm not sure if this will conflict with the wiird protocol, but I'll request it anyways. I have my wii set up to get lots of usb gecko output from the IOS and stuff. Obviously this can lead to issues when trying to debug games / system menu with wiird as there is a bunch of data coming down the pipe and geckoDotNET expects only data from the code handler. Would it be feasible to have geckoDotNET use "ConsoleWrite()" and pass along anything it receives while waiting for a command? Then we could start this program from a command line and that command window would display text from the fwrite /OSReport patch or IOSes or whatever.
I realize that any output that gets mixed in with the game would taint the results. But as long as the user was aware of this, it can be avoided by making sure the game is paused before dumping any memory. It would be a great help. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 05, 2010, 02:01:27 PM I admire your spirit, but I'm not sure that pausing would work. It stops the PowerPC processor, but I don't think we can stop the ARM or anything that IOS is doing. For instance, some games keep playing music when paused.
When I ran it using mono from the command line, I was still able to write to the console. Perhaps it works that way in Windows...how does one launch a .NET app in from the command line anyway? I'll add this to the list, but I haven't been doing much on this front lately, and this feature could get complicated because then I'd need to add something that periodically tried to read from the USB Gecko even if there was no reason to, and you'd need a way to turn this off, etc. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on April 05, 2010, 06:58:23 PM For launching c# stuff from the command line in ubuntu, i just type "mono <name of the program>" and it starts whatever .NET app i ask for. And that program can use ConsoleWrite() and output handy stuff to the console it was launched from. It works very well for debugging. I've never tried it in windows. But I assume that ConsleWrite() was not invented just for mono. :) .
And stopping the ARM really isn't an issue. Since the way it works is basically each IOS module waits for a request. While it is waiting for somebody to tell it what to do, there is no output. So, if you pause the PPC, then nobody is telling the IOS what to do. And then it has no reason to send any debug output. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 05, 2010, 07:24:05 PM For launching c# stuff from the command line in ubuntu, i just type "mono <name of the program>" and it starts whatever .NET app i ask for. Right, I know you use mono to launch .NET apps in Linux. I've written .NET console apps before, but they always launched their own console if double-clicked. If you run Gecko.NET from a console you can probably see output that is normally hidden if you double-click the icon in Windows Explorer. Quote And stopping the ARM really isn't an issue. Since the way it works is basically each IOS module waits for a request. While it is waiting for somebody to tell it what to do, there is no output. So, if you pause the PPC, then nobody is telling the IOS what to do. I understand what you're saying, but that doesn't always happen. Some games (not all of them) continue to play music while the PPC is paused, instead of repeating the same small sound buffer as a buzzing sound. So, someone is still telling someone else to do things while paused. This leads me to wonder what other things are doing stuff while the PPC is paused. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 06, 2010, 12:07:00 AM I tried searching for a 32bit unknown value with the new Gecko.NET build 5 times and every time it finished it said an error occurred please reconnect to gecko
also a few bugs and requests as you can see the text of the boarder address column is too white to see clearly (http://i42.tinypic.com/10ngner.jpg) the highlighted address in the memory veiwer resets to the top row when you change view mode, go up or down a page, or switch to another tab and switch back in WiiRd the top row of the memory viewer was always XXXXXX0X but Gecko.NET makes whatever address you choose to go to the top row it would be nice to be able to switch to the way WiiRd does it and/or have an "up/down a single line" control have the ASM and register windows separately resizeable, I'd like to be able to view registers CR through r31 all at once without having to make the whole Gecko.NET window larger Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 06, 2010, 03:14:04 AM r50 is in the wild (http://wiird.l0nk.org/forum/index.php/topic,4886.msg46052.html#msg46052), guys.
wiiztec: Wow, your memory viewer addresses look terrible. Certainly, if mine looked like that, I would have done something about it...I wonder if your color scheme is different, or if it's a Vista-thing, cos I use XP. Regardless, the addresses are black text now, and your other suggestions are included, too. Unfortunately, I was unable to replicate your issue with unknown search. I did three different 32-bit unknown value searches through all of MEM1, with "equal to last" searches after each unknown search, and restarting after each "equal to last" search. Every single one worked. giantpune: I don't have any custom IOS so I have no way to test your thing. I've added it to the to-do list but I can't say when I'll get around to it. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 06, 2010, 03:47:04 AM I use XP too and the default blue luna theme and replacing the 15 line skip with a one line skip isn't really what I had in mind the 15 line skip should be the default and there should be an additional control for a one line skip
also whatever the problem with the search was it's fixed in r50 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on April 06, 2010, 03:48:56 AM i sent you pm dcx2
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 06, 2010, 01:10:13 PM Doh, I forgot I use the "classic" win2k visual style instead of that bubbly lookin' Luna theme.
If you're in the Memory Viewer Grid (not the Address text box) you can use pageup/pagedown to increment/decrement the address by 0x100/skip 16 lines. In r50 you can also use shift-up/shift-down to inc/dec by 0x10/skip 1 line without moving the selected cell (so it doesn't have to be at the top or bottom). Tonight's build will make clicking the Address-up/down inc or dec by 0x100, like before. Also, pressing up/down arrow keys in the Address box will inc/dec by 0x10 and pageup/pagedown inc/dec by 0x100. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 06, 2010, 05:07:31 PM Could you also put a control to the right of the auto update check box?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 06, 2010, 05:25:41 PM There's not a lot of room to fit anything, and we generally try to keep similar controls together and that's not really associated with auto-update. And then I would need more room for labels or something so you knew which one would inc/dec by 0x10 and which one would inc/dec by 0x100.
It's not that I'm against adding another control, but I'd rather not jam it in there, especially since space is at a premium on that tab. I'll see if I can't rearrange some things, but I still need some way to distinguish the 0x10 from the 0x100 one. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 08, 2010, 04:32:22 PM Some bugs/requests
• in the mem viewer if you try to go to an address in another memory range without changing the range in the drop down box first, it gives you an unhandled exception error • Gecko.NET doesn't remember your setting for the division between registers and ASM instructions on the breakpoint tab anymore • space for 10 characters in all value boxes (to convert to hex, dec numbers more than 8 digits long) • be able to search for an unknown value with an upper limit • disassembler option for mem viewer context menu • copy option for mem viewer context menu • step controls on the disassembler tab • a "comment out all/comment out none" check box for the GCT codes tab • defined border between the scrollbar and the rightmost addresses in the mem viewer Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 08, 2010, 05:11:00 PM • in the mem viewer if you try to go to an address in another memory range without changing the range in the drop down box first, it gives you an unhandled exception error I'll look into this further, but when you say "go to an address", what specific way(s) fail? Did you type a value into the Memory Viewer address text box and hit enter? Are you using the search result context menu or the Breakpoint's Show Mem button? Double-clicking a pointer in the Memory Viewer? Quote • space for 10 characters in all value boxes (to convert to hex, dec numbers more than 8 digits long) You're right, we should be able to convert 10 digit decimals, but I think there's a limit on a lot of the text boxes that keeps their digits maxed at 8. This helps prevent entering invalid values. I would probably make this setting into a checkbox so you could enable/disable the 8-digit limit. It would be difficult to resize the text boxes to show all 10 digits, though, so removing the limit could create issues where two digits can be pushed past the edge of the text box. I consider this acceptable. Quote • be able to search for an unknown value with an upper limit You can sorta do this already, by looking for a specific value greater than or equal to 0 and less than your upper limit. I'm actually planning on eventually making the "upper limit" a more general "second comparison" that can do more than act as a "less than" test. Quote • copy option for mem viewer context menu Hm...what exactly do you mean? Place the contents of the memory viewer in the clipboard? Quote • a "comment out all/comment out none" check box for the GCT codes tab What exactly is your goal with this? How does the current checkbox that enables/disables a whole code fail to achieve that goal? Do you want to be able to comment out specific code lines? Groups of code lines? Quote • defined border between the scrollbar and the rightmost addresses in the mem viewer I'm not sure I really follow what you mean by "defined border". Is this just an aesthetic thing or is there a functional reason? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 08, 2010, 05:59:04 PM I'll look into this further, but when you say "go to an address", what specific way(s) fail? Did you type a value into the Memory Viewer address text box and hit enter? Are you using the search result context menu or the Breakpoint's Show Mem button? Double-clicking a pointer in the Memory Viewer? Yeah typed into the text box, but I didn't test the others so you should check them out too Quote Hm...what exactly do you mean? Place the contents of the memory viewer in the clipboard? Just the selected word Quote What exactly is your goal with this? How does the current checkbox that enables/disables a whole code fail to achieve that goal? Do you want to be able to comment out specific code lines? Groups of code lines? Say you have a really long code and you want to comment out most of the lines, you would check the "comment out all" check box and manually un comment out the few lines that you don't want commented out. The check box that enables/disables the whole code doesn't put -- before all the lines and it wouldn't work if it did anyways since when you checked the box again it would remove all the --'s Quote I'm not sure I really follow what you mean by "defined border". Is this just an aesthetic thing or is there a functional reason? Just aesthetic, that's why it's at the end of the list Oh I forgot to mention that in the mem viewer typing an address into the address box and hitting enter doesn't highlight the address you typed in, it should behave like it does when you jump to the mem viewer from the search tab's context menu Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 10, 2010, 01:17:13 AM Still got a few things to go on wiiztec and giantpune, but here goes...this is my brainstorm list, let me know if any of you like any of these ideas and how much.
General - Address text boxes would be combo boxes that would have a history of addresses entered, use right click or Shift + Enter to add an address to the history - Show values that changed in red (in particular, memory viewer and breakpoint registers) - Snapshots (memory viewer, breakpoints, disassembly, address text box histories?) with full clipboard support - Customizable shortcuts that can be launched from a tools menu, which can pass the game name as part of an argument (i.e. "calc", "notepad %g.txt" where %g would be replaced with the game name) - Mono support Search - Simultaneously search MEM1 and MEM2 - Add "First" to "Last" and "Specific" dropdown - Upper value to have eq/neq/lt/le/gt/ge/diff - Multi-level undo with compressed binary search results - ...new Search Result columns? Use with multi-level history to show every result? Memory Viewer - Auto View mode that attempts to discriminate floats from ints from strings from assembly all in one view - Expand Memory Viewer to show more than 16 lines, so that it can fill a resized form Breakpoints - Breakpoint condition groups; since different instructions will use different registers to load or store, I want to be able to break on { SRR0=xx and r0=y } or { SRR0=zz and r3=y } or { etc } - Allow disassembly view to be scrolled up beyond the current instruction - Automatically move the register view down when the current instruction deals with floating point registers - Show the current value at the destination of a load or store as a label somewhere Disassembler - Labels with the current register's values - Step controls like the breakpoints tab - Branch Finder - give it a target branch-destination-range, like 80123450-80123460, and you click a button to automatically scroll up looking for branches which jump to a value in that range GCT Codes - Add more codes to code wizard - Integrated support for the code database website, so you can load cheats directly from the web and maybe even upload your codes if you have the account - Somehow integrate asmwiird support Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 10, 2010, 05:20:49 AM - Show values that changed in red (in particular, memory viewer and breakpoint registers) What does this mean for the memory viewer will all the addresses that change rapidly just be red all the time? how you you indicate more than 1 change? Quote - ...new Search Result columns? Use with multi-level history to show every result? I hope not unless there's an option to just use the standard two, don't really wanna squeeze the columns so they all fit or have to stretch out the whole window Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 10, 2010, 12:34:00 PM What does this mean for the memory viewer will all the addresses that change rapidly just be red all the time? how you you indicate more than 1 change? If a value keeps changing, it would just stay red. Also, if the value changed two times before Memory Viewer read the new value, it would have no way to know about the intermediate change. If it was 0 and changed to 1 and then back to 0 before Memory Viewer read it, I wouldn't be able to color it red because it would not appear to have changed. Quote Quote - ...new Search Result columns? Use with multi-level history to show every result? I hope not unless there's an option to just use the standard two, don't really wanna squeeze the columns so they all fit or have to stretch out the whole windowAny extra columns would go on the right side, so that the most important columns are always visible. I could probably also make the columns re-arrangable, but that could be a tedious process. And of course there would be a way to not use it, so you don't have a bunch of unused columns...maybe another button that says "Search and Add". Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hawkeye2777 on April 10, 2010, 04:28:25 PM Here's some ideas for the Mono version (non-win32 builds):
* Replace Win32 features with cross-platform equivalents * Redo the GUI in GTK# (Winforms is not pretty on non-win32 platforms) Of course, getting it to connect to the USB Gecko is top priority, then critical bug fixes would come next. After that would be replacing the win32 features, and then lowest priority is GTK#. That's all I can think of right now. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 18, 2010, 06:22:17 PM Some more bugs and requests•
• in WiiRd if you set a breakpoint and then set a breakpoint condition and press step It will step through the ASM instructions automatically until the condition is met, I would like Gecko.NET to be able to do this as well • a whole lot of things involving breakpoint conditions * be able to disable conditions individually without deleting them * a button to disable/enable all conditions * a button to automatically add an SRR0 ≠ (current value of SRR0) condition * a button to clear all SRR0 ≠ conditions * pretty crazy idea but how about the conditions in the box default to OR instead of AND and you could highlight a few conditions and bring up the context menu that would have the option "create "AND group"" which with multiple AND groups (which would be represented by different color text) would work like [break IF (AND group 1) or (AND group 2) = true] also on the context menu for when you just want everthing to be AND would be a "make all AND/make all OR" option I know the breakpoint tab is pretty tight on space but the text view/edit view button doesn't need to be as big as it is and there's always context menu's if you really don't have enough space • a log steps option like WiiRd's • a ctrl F like text search of the disassmbler window for searching for branches • in the memory viewer if you jump to an address and then use the arrows by the address to go down and then back up a page then the previously selected address will be unselected at the top row instead of selected and centered • the thing that tells you whether a conditional branch is taken or not is almost always wrong Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on April 19, 2010, 08:27:26 AM i got a crash. im not sure if this only in the mono version or if it affects all versions.
1- start debugging a virtual console game 2- search for a 8-bit value 3- while the search is running, click the fst tab 4- after a few seconds geckodotnet disappears, and in the console i launched it from, i get this LFTDI::Read() 1 bytes LFTDI::Read() 47965 bytes LFTDI::Write() 1 bytes LFTDI::Read() -9 bytes Stacktrace: at (wrapper managed-to-native) libftdi.LFTDI.ftdi_usb_close (libftdi.ftdi_context&) <0x00056> at (wrapper managed-to-native) libftdi.LFTDI.ftdi_usb_close (libftdi.ftdi_context&) <0xffffffff> at libftdi.LFTDI.Close () <0x0001b> at FTDIUSBGecko.USBGecko.Disconnect () <0x0001f> at GeckoApp.MainForm.DisconnectButton_Click (object,System.EventArgs) <0x0002b> at (wrapper remoting-invoke-with-check) GeckoApp.MainForm.DisconnectButton_Click (object,System.EventArgs) <0xffffffff> at GeckoApp.ExceptionHandler.HandleExceptionInternally (FTDIUSBGecko.EUSBGeckoException) <0x00043> at GeckoApp.ExceptionHandler/<HandleException>c__AnonStorey3.<>m__5 () <0x00017> at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0x0004e> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0xffffffff> at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <0x000bb> at System.Reflection.MethodBase.Invoke (object,object[]) <0x0002a> at System.Delegate.DynamicInvokeImpl (object[]) <0x0017b> at System.MulticastDelegate.DynamicInvokeImpl (object[]) <0x0003b> at System.Delegate.DynamicInvoke (object[]) <0x00015> at System.Windows.Forms.XplatUIDriverSupport.ExecutionCallback (object) <0x00053> at System.Security.SecurityContext.Run (System.Security.SecurityContext,System.Threading.ContextCallback,object) <0x00117> at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) <0x0003b> at System.Windows.Forms.XplatUIDriverSupport.ExecuteClientMessage (System.Runtime.InteropServices.GCHandle) <0x0009f> at System.Windows.Forms.XplatUIX11.GetMessage (object,System.Windows.Forms.MSG&,intptr,int,int) <0x02bc7> at System.Windows.Forms.XplatUI.GetMessage (object,System.Windows.Forms.MSG&,intptr,int,int) <0x0004c> at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x00d97> at System.Windows.Forms.Form.ShowDialog (System.Windows.Forms.IWin32Window) <0x0034b> at System.Windows.Forms.Form.ShowDialog () <0x0000f> at System.Windows.Forms.MessageBox/MessageBoxForm.RunDialog () <0x00063> at (wrapper remoting-invoke-with-check) System.Windows.Forms.MessageBox/MessageBoxForm.RunDialog () <0xffffffff> at System.Windows.Forms.MessageBox.Show (string,string,System.Windows.Forms.MessageBoxButtons,System.Windows.Forms.MessageBoxIcon,System.Windows.Forms.MessageBoxDefaultButton) <0x00073> at GeckoApp.ExceptionHandler.HandleExceptionInternally (FTDIUSBGecko.EUSBGeckoException) <0x0017b> at GeckoApp.ExceptionHandler.HandleException (FTDIUSBGecko.EUSBGeckoException) <0x000ab> at GeckoApp.MemSearch.Search (uint,uint,uint,uint,bool,GeckoApp.SearchType,GeckoApp.SearchSize,GeckoApp.ComparisonType,uint) <0x004a7> at GeckoApp.MainForm.Search_Click (object,System.EventArgs) <0x00453> at System.Windows.Forms.Control.OnClick (System.EventArgs) <0x00069> at System.Windows.Forms.Button.OnClick (System.EventArgs) <0x00053> at System.Windows.Forms.ButtonBase.OnMouseUp (System.Windows.Forms.MouseEventArgs) <0x000f9> at System.Windows.Forms.Button.OnMouseUp (System.Windows.Forms.MouseEventArgs) <0x00013> at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message&) <0x00124> at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) <0x00213> at System.Windows.Forms.ButtonBase.WndProc (System.Windows.Forms.Message&) <0x0008f> at System.Windows.Forms.Button.WndProc (System.Windows.Forms.Message&) <0x00013> at System.Windows.Forms.Control/ControlWindowTarget.OnMessage (System.Windows.Forms.Message&) <0x00024> at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) <0x00036> at System.Windows.Forms.NativeWindow.WndProc (intptr,System.Windows.Forms.Msg,intptr,intptr) <0x002bb> at System.Windows.Forms.XplatUIX11.DispatchMessage (System.Windows.Forms.MSG&) <0x0001f> at System.Windows.Forms.XplatUI.DispatchMessage (System.Windows.Forms.MSG&) <0x00024> at System.Windows.Forms.Application.RunLoop (bool,System.Windows.Forms.ApplicationContext) <0x00c7f> at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext) <0x00053> at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) <0x00033> at GeckoApp.Program.Main () <0x0003f> at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /usr/bin/cli [0x47a5ef] /usr/bin/cli [0x4ada3f] /lib/libpthread.so.0 [0x7f2910f7c190] /usr/lib/libftdi.so [0x7f290368e790] /usr/lib/libftdi.so(ftdi_usb_close+0x1b) [0x7f290368ebab] [0x411d0cc6] Debug info from gdb: [Thread debugging using libthread_db enabled] [New Thread 0x7f290823d910 (LWP 26771)] [New Thread 0x7f290f833910 (LWP 26770)] [New Thread 0x7f2911a83910 (LWP 26769)] 0x00007f2910f7b0cb in read () from /lib/libpthread.so.0 4 Thread 0x7f2911a83910 (LWP 26769) 0x00007f2910f7b8f1 in nanosleep () from /lib/libpthread.so.0 3 Thread 0x7f290f833910 (LWP 26770) 0x00007f2910f7a3c1 in sem_wait () from /lib/libpthread.so.0 2 Thread 0x7f290823d910 (LWP 26771) 0x00007f2910f785a9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 Thread 0x7f2911c57730 (LWP 26767) 0x00007f2910f7b0cb in read () from /lib/libpthread.so.0 Thread 4 (Thread 0x7f2911a83910 (LWP 26769)): #0 0x00007f2910f7b8f1 in nanosleep () from /lib/libpthread.so.0 #1 0x0000000000553fa2 in ?? () #2 0x00007f2910f73a04 in start_thread () from /lib/libpthread.so.0 #3 0x00007f2910a5980d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f290f833910 (LWP 26770)): #0 0x00007f2910f7a3c1 in sem_wait () from /lib/libpthread.so.0 #1 0x00000000004e32ba in ?? () #2 0x000000000050305a in ?? () #3 0x000000000056da83 in ?? () #4 0x000000000058b6e1 in ?? () #5 0x00007f2910f73a04 in start_thread () from /lib/libpthread.so.0 #6 0x00007f2910a5980d in clone () from /lib/libc.so.6 #7 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f290823d910 (LWP 26771)): #0 0x00007f2910f785a9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000558338 in ?? () #2 0x000000000057128d in ?? () #3 0x000000000050061b in ?? () #4 0x00000000411c38fe in ?? () #5 0x0000000002c84d50 in ?? () #6 0x00007f28a2371d98 in ?? () #7 0x00007f28a4e2df90 in ?? () #8 0x00000000411c3764 in ?? () #9 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f2911c57730 (LWP 26767)): #0 0x00007f2910f7b0cb in read () from /lib/libpthread.so.0 #1 0x000000000047a764 in ?? () #2 0x00000000004ada3f in ?? () #3 <signal handler called> #4 0x00007f290368e790 in ?? () from /usr/lib/libftdi.so #5 0x00007f290368ebab in ftdi_usb_close () from /usr/lib/libftdi.so #6 0x00000000411d0cc6 in ?? () #7 0x00007fff9eebf520 in ?? () #8 0x00000000403e2944 in ?? () #9 0x00007f290897f000 in ?? () #10 0x00007f290f8519f0 in ?? () #11 0x0000000002ecb8a8 in ?? () #12 0x00007fff9eebf330 in ?? () #13 0x00007fff9eebf260 in ?? () #14 0x00007f290bcef000 in ?? () #15 0x00007f290bcef000 in ?? () #16 0x00007f290bcef000 in ?? () #17 0x00007f290891fbb8 in ?? () #18 0x00000000411d0c1c in ?? () #19 0x00007f290bcef000 in ?? () #20 0x00007f290861fed8 in ?? () #21 0x00007f290bcef000 in ?? () #22 0x00000000411d0be0 in ?? () #23 0x00007f2908869230 in ?? () #24 0x00000000411d0b1c in ?? () #25 0x00000000411d0f70 in ?? () #26 0x0000000000000000 in ?? () ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Aborted anyways, thats what i did. i havent been able to reproduce it yet. but im guessing that it has to do with the read -9 bytes. i dont think he knows how to do that. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 19, 2010, 11:15:42 AM -9 is actually the error code returned by ftdi_read_data. The funny thing is...you shouldn't be able to change the tab when you're doing a search (for this very reason). There's actually some code specifically to prevent you from changing tabs during searches and breakpoints. It frightens me that the same code built in mono is missing all of this functionality (the context menu, tab-locking during searches, etc)
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 19, 2010, 11:59:05 AM What's mono?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 19, 2010, 12:16:07 PM It helps run the Linux version of Gecko.NET.
.NET (the framework used to run Gecko.NET) is designed to be...*cough* platform independent. But Microsoft only really bothers with writing Windows versions of .NET. So there's a project called mono that ported .NET to Linux. It appears to be a little rough around the edges, but with it you can now run Gecko.NET on Linux (well, Ubuntu...if you compile from the latest source...) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 19, 2010, 11:33:36 PM Whew, now that I can take a break from the mono-side of things...
• in WiiRd if you set a breakpoint and then set a breakpoint condition and press step It will step through the ASM instructions automatically until the condition is met, I would like Gecko.NET to be able to do this as well So...it hits Set Breakpoint for you automatically if you hit Step without hitting Set Breakpoint first? Quote * a button to automatically add an SRR0 ≠ (current value of SRR0) condition I've been thinking about this. I think a context menu might be better, so that way it can work with any register and not just SRR0, although I can see an argument for including a button for SRR0 *in addition to* the context menu that works with any register, since it's a pretty common operation. Quote • a log steps option like WiiRd's I never actually used that feature. What exactly did it do/what would you like it to do? Write the current instruction each time a breakpoint was skipped? Store register values? Where did the output go? Quote • the thing that tells you whether a conditional branch is taken or not is almost always wrong No way. I could have swore I parsed the CR correctly. I'll look into this...maybe I read the bits backwards. Quote • in the memory viewer if you jump to an address and then use the arrows by the address to go down and then back up a page then the previously selected address will be unselected at the top row instead of selected and centered ...I think I know what you're trying to get at, but I'm not 100% sure. I'll play with the up/down control and see if I notice anything odd. Quote • a ctrl F like text search of the disassmbler window for searching for branches This ties into my branch finder suggestion. The problem with ctrl+f to search for branches is that branches don't always land where you think they would land. Sometimes they land a few instructions early, or sometimes you know the code needs a branch to get where you are right now, but you don't know what instruction that branch landed on. So I wanted to make a branch finder that would search for branches that land in a specified region. Quote • a whole lot of things involving breakpoint conditions Many of these tie into the breakpoint-condition-groups that I alluded to at the top of page 7. Let's say you're following some address in memory with write breakpoints. Two different stw's are writing to this address. It's writing your health (for example), and you want to set a breakpoint condition so that it breaks when it would change your health. But unfortunately, the first stw uses r0 for the stw and the second stw uses r3. I'm envisioning a tree-list-view where you can group together different breakpoint conditions. This way, you could break on address xxx if r0<>zzz, or break on address yyy if r3<>zzz. -| |-Group 1 |--SRR0 == xxx |--R0 <> zzz |-Group 2 |--SRR0 == yyy |--R3 <> zzz Basically, the contents of each group are ANDed, and the result of each group is ORed, so that if all the conditions of any single group are true, it would break. I really like this idea and I don't think it would be hard to implement the guts, but it's the interface that I think would be difficult to polish. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 20, 2010, 12:01:15 AM Whew, now that I can take a break from the mono-side of things... So...it hits Set Breakpoint for you automatically if you hit Step without hitting Set Breakpoint first? No after a breakpoint is triggered you can set a breakpoint condition and then press step and it will step through the ASM instructions automaticly and break when the condition is met Quote I never actually used that feature. What exactly did it do/what would you like it to do? Write the current instruction each time a breakpoint was skipped? Store register values? Where did the output go? It would log into a text file a list of the ASM instructions you stepped through (or WiiRd did for you in the case of it's above mentioned feature) and their addresses Quote but it's the interface that I think would be difficult to polish. I think my idea would work well Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on April 20, 2010, 01:25:43 AM ive had i little more time to play with the mono version to see about the bugs specific to it. heres some stuff i came up with.
* as far as the part of the program that says "while a search is happening, clicking tabs shouldnt work", that kind of works. the actual tabs themselves dont change. but the main part of the program changes. so you end up with a display that doesnt match the tabs. search tab, but the rest of the page is the "tools" (http://img341.imageshack.us/img341/2826/geckooopsie.png) *the context menu is correct for what i would describe as "the big part on the right". but for all the individual fields throughout the program they are not correct. *heres a funny one. the new super-special memory-history boxes have a mind of their own. i can click to bring up 2 of the little boxes and then drag the main window and the 2 history boxes stay where they are. (http://img535.imageshack.us/img535/2175/geckooopsie1.png) (http://img62.imageshack.us/img62/5792/oopsie2.png) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 27, 2010, 08:27:08 PM Some more questions/bugs/requests
• why is their no copy/paste options in some context menu's just stuff about history which I thought would be automatic, also trying to copy or paste history gives an unhandled exception error • make the search comparision drop down box expand enough so that all options are visible without having to use a scrollbar, it's annoying to have to scroll up to select equal when doing unknown value equal/not equal searches and it's only one line that you have to scroll to see so why not just expand the drop down box more? • copy/pasting a register value into the breakpoint conditions box via the context menu gives an unhandled exception error ctrl-v works though • in mem viewer when you do a text search and then go up or down a page, it jumps back to where it was that you started the text search, also happens when you search again • the problem about mem viewer that I described in an earlier post doesn't happen when you use the page up/down keys so it should work like that, excluding the qwerk with the page up/down keys that after jumping to an address with the address box you have to manually select a value in the mem viewer window before the page up/down keys will respond • As I understand the watchlist is supposed to be like a mem viewer of custom addresses that you specify, but I think it updates a little too slow for this purpose and it gets slower with each address you add to it, one time I had like 35 addresses in it at once and it had lagged the update speed consideribly mem viewer with auto update can display 64 addresses at a time much faster than the watchlist can display 35 or even one • saved searches don't always give you the option to continue them, I think it's unknown value searches don't and specific value searches do • Excite Truck crashes when you apply codes with Gecko.NET it doesn't with WiiRd • infrequent seemingly random disconnects from the Gecko happen sometimes (can't really give any specifics) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hetoan2 on April 28, 2010, 10:34:05 AM • Excite Truck crashes when you apply codes with Gecko.NET it doesn't with WiiRd Its more than just excite truck. The same thing happens with MWR and WaW. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on April 30, 2010, 04:32:06 AM I'll try to do some of the simple things (unhandled exceptions, search dropdown) soon. In the mean time, could you elaborate on the following?
why is their no copy/paste options in some context menu's just stuff about history which I thought would be automatic, also trying to copy or paste history gives an unhandled exception error I'm pretty sure ctrl+c and ctrl+v will work. I just didn't add Copy and Paste to the context menu. And that's weird that the copy/paste-history doesn't work, because I know I tested it. But I'll re-test it again. And what do you mean by "automatic"? The text boxes have an automatic history mode, but I hesitated to have it on by default. I could make Gecko.NET remember the address boxes' automatic history settings... Quote As I understand the watchlist is supposed to be like a mem viewer of custom addresses that you specify, but I think it updates a little too slow for this purpose and it gets slower with each address you add to it, one time I had like 35 addresses in it at once and it had lagged the update speed consideribly mem viewer with auto update can display 64 addresses at a time much faster than the watchlist can display 35 or even one Memory Viewer can grab all 64 addresses in one shot. Depending on the values you put into the Watchlist, it will have to perform multiple reads, which will be slower than Memory Viewer. But I must admit I never used the Watchlist yet, so I'll give it a try to see if I can see how slow it is, and if there's anything I can do to speed it up. Quote saved searches don't always give you the option to continue them, I think it's unknown value searches don't and specific value searches do That makes sense, because it only saves what's in the Search Results. The first Unknown search that you perform doesn't show any Search Results, so it has nothing to save, even though you did a search. I can look into making this also save the first Unknown search, but it will be kinda low priority. Quote Excite Truck crashes when you apply codes with Gecko.NET it doesn't with WiiRd Until I can find a game that suffers from the crashing when you apply codes, I won't be able to solve this bug... Quote infrequent seemingly random disconnects from the Gecko happen sometimes (can't really give any specifics) I get the feeling that sometimes the communication with the USB Gecko is not error free. This also applies to WiiRDGUI...have you ever been skipping a bunch of breakpoints and it just suddenly stops for no reason, and you have to hit Set Breakpoint again to get it started? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on April 30, 2010, 12:24:20 PM I'm pretty sure ctrl+c and ctrl+v will work. I just didn't add Copy and Paste to the context menu. And that's weird that the copy/paste-history doesn't work, because I know I tested it. But I'll re-test it again. And what do you mean by "automatic"? The text boxes have an automatic history mode, but I hesitated to have it on by default. I could make Gecko.NET remember the address boxes' automatic history settings... Could you put them back on the context menu? I keep openinf it expecting copy & paste to be there and then having to close it and use ctrl-c/ctrl-v. What I meant by automatic was like how a web browser remembers your frequently visited sites either by a dropdown box of choices or filling in the rest of the address bar for you like when I type in y my browser automaticly assumes youtube Quote That makes sense, because it only saves what's in the Search Results. The first Unknown search that you perform doesn't show any Search Results, so it has nothing to save, even though you did a search. I can look into making this also save the first Unknown search, but it will be kinda low priority. I meant after multiple searches I would never save after the first unknown search, I also meant that if you load a saved unknown search and then continue it by a specific value search it will work, but if you try to continue it by an unknown search it will just start a new search, the same is true of saved specific value searches. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 03, 2010, 03:23:08 AM I get the feeling that sometimes the communication with the USB Gecko is not error free. This also applies to WiiRDGUI...have you ever been skipping a bunch of breakpoints and it just suddenly stops for no reason, and you have to hit Set Breakpoint again to get it started? I forgot to say that the disconnects almost never happen to me with WiiRD, Gecko.NET disconnects just from prolonged periods of inactivity I have experienced some odd behavior with breakpoints with both WiiRd and Gecko.NET but the don't usually cause a disconnect, the problem you described goes away after waiting a bit Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 05, 2010, 12:40:22 PM Setting breakpoint conditions does does not work in r70 clicking add does nothing
also I noticed that the conversion of float to hex rounds the result it would be great to have an option on the tool tab or something to make them rounded or absolute Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 08, 2010, 09:02:01 PM ive just tried to get this to work in windows 7 and im not having any luck. ive set up the usb gecko from the old ass drivers on the CD. everything appears fine in the device manager. when i start geckodotnet, it just hangs. if i force close it, i can get this text that may say exactly why it is hanging.
Description: A problem caused this program to stop interacting with Windows. Problem signature: Problem Event Name: AppHangB1 Application Name: Gecko dNet r71.exe Application Version: 1.0.0.0 Application Timestamp: 4be3856e Hang Signature: 4f5a Hang Type: 256 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033 Additional Hang Signature 1: 4f5a6f51b9638756a8f9edaf073ce0ef Additional Hang Signature 2: 3325 Additional Hang Signature 3: 33252ca15ec4bb98b372497709fbe858 Additional Hang Signature 4: 4f5a Additional Hang Signature 5: 4f5a6f51b9638756a8f9edaf073ce0ef Additional Hang Signature 6: 3325 Additional Hang Signature 7: 33252ca15ec4bb98b372497709fbe858 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409 If the online privacy statement is not available, please read our privacy statement offline: C:\Windows\system32\en-US\erofflps.txt its all greek to me, but maybe it helps Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 08, 2010, 09:36:01 PM Do you have 64-bit Windows 7? The drivers on the CD are probably 32-bit and won't work.
Also, try the official release instead of r71, but I doubt that will change much. Oh, btw, make sure you aren't running WiiRDGUI at the same time. That might cause Gecko.NET to hang, because WiiRDGUI has exclusive control of the virtual serial port. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on May 09, 2010, 04:07:39 AM ive just tried to get this to work in windows 7 and im not having any luck. ive set up the usb gecko from the old ass drivers on the CD. everything appears fine in the device manager. when i start geckodotnet, it just hangs. if i force close it, i can get this text that may say exactly why it is hanging. Description: A problem caused this program to stop interacting with Windows. Problem signature: Problem Event Name: AppHangB1 Application Name: Gecko dNet r71.exe Application Version: 1.0.0.0 Application Timestamp: 4be3856e Hang Signature: 4f5a Hang Type: 256 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033 Additional Hang Signature 1: 4f5a6f51b9638756a8f9edaf073ce0ef Additional Hang Signature 2: 3325 Additional Hang Signature 3: 33252ca15ec4bb98b372497709fbe858 Additional Hang Signature 4: 4f5a Additional Hang Signature 5: 4f5a6f51b9638756a8f9edaf073ce0ef Additional Hang Signature 6: 3325 Additional Hang Signature 7: 33252ca15ec4bb98b372497709fbe858 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409 If the online privacy statement is not available, please read our privacy statement offline: C:\Windows\system32\en-US\erofflps.txt its all greek to me, but maybe it helps WIn 7 Auto installs the best drivers for it .. iv never had to use the CD even when i was on vista :P once u plug in USBgecko it Auto Detects and gets u the best drivers .. the only thing i can seem to find is Geckoreader i cant seem to get it to work it cant detect the Gecko since i cant change the Coms . or anything like that .. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 09, 2010, 05:25:38 AM windows 7 didnt auto install any drivers for it. i tried several times. i even went to the ftdi website and got the latest ones from them ( both the normal ones and the VPC ones) . with the drivers from that site, i can enumerate the port based on the chip ID and access the gecko fine and send data to and from it , so it is at least part way working. but for some reason geckodotnet doesnt like something about the setup.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 09, 2010, 05:38:08 AM hmm...I think Gecko.NET might make certain assumptions about how the USB Gecko connects to the PC. Having installed multiple drivers, the right USB Gecko connection might be pushed back, somehow. I'll take a look into the connection stuff.
What are you using to connect to it successfully? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on May 09, 2010, 06:12:38 AM windows 7 didnt auto install any drivers for it. i tried several times. i even went to the ftdi website and got the latest ones from them ( both the normal ones and the VPC ones) . with the drivers from that site, i can enumerate the port based on the chip ID and access the gecko fine and send data to and from it , so it is at least part way working. but for some reason geckodotnet doesnt like something about the setup. WHat version of Win7 u using .. i have win7 Pro 64bit and its setting up the drivers auto FTDI 22/10/2009 Version: 2.6.0.0 USB Serial Converter alows me to use Wiird and Gecko dot net .. anyway to put GeckoReader into the Gecko dot Net app ? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 09, 2010, 09:34:26 AM ive got win7 pro x64 also and it doesnt get the drivers itself here. i got the FTDi driver version 2.6.2.0 from their website and installed it manually.
EDIT>>> ok, well i figured out part of the issue. it was half user error, half a bug in the program. :) i had turned off the option to load the debugger in geckoOS. so at least for me, geckodotnet is completely unresponsive if the debugger is not loaded. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 09, 2010, 07:50:21 PM Gecko.NET basicly IS the debugger
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 09, 2010, 08:16:08 PM When you set a read breakpoint on a file name and then cancel it and try to go to the memviewer if it's currently at the location of said file name it will freeze the game & Gecko.NET and then give an error message about loosing connection with the gecko, when you reconnect it will take you to the memviewer tab but the game will still be frozen, if you click run game the same thing will happen when you try to go back to the breakpoint tab except the game will unfreeze
Also step over doesn't work And the single line control for memviewer has a problem similar to the one the whole page control had, I noticed this after being brought to an address by clicking show mem in the breakpoint tab Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 10, 2010, 12:03:32 AM When you set a read breakpoint on a file name and then cancel it and try to go to the memviewer if it's currently at the location of said file name it will freeze the game & Gecko.NET and then give an error message about loosing connection with the gecko, when you reconnect it will take you to the memviewer tab but the game will still be frozen, if you click run game the same thing will happen when you try to go back to the breakpoint tab except the game will unfreeze I've had the same problemsAlso step over doesn't work Setting a read (or read/write) breakpoint and, canceling it and then going to the memory viewer will result in Gecko.NET losing connection. The game will be paused (maybe because Gecko.NET itself will trigger the breakpoint?) and Gecko.NET will bring up 2 popups about reconnecting. I can also confirm the step over bug. Also, the step out function steps through the code until it sees "blr", but wouldn't it be faster to set a breakpoint on the LR? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 10, 2010, 01:01:25 AM Gecko.NET basicly IS the debugger geckodotnet is only half of the setup. this program by itself cannot debug anything. theres a engine running on the wii that it talks to. if i start a game through geckoOS with the setting that says "load debugger" turned off then geckodotnet is unresponsive. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 10, 2010, 01:38:49 AM That's what I meant by basicly, the debugger is that engine
I got the impression that you expected Gecko.NET to work with the debugger option off, am I wrong? the debugger option is for WiiRd/Gecko.NET it tells the Gecko to send information to your PC so it can be recieved by WiiRd/Gecko.NET Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 10, 2010, 03:10:23 AM I think he accidentally had the debugger option unchecked. What he would prefer is a dialog box that said "hey, dumbass, turn on the debugger in Gecko OS", instead of just freezing without any explanation.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 10, 2010, 03:48:31 AM And the single line control for memviewer has a problem similar to the one the whole page control had, I noticed this after being brought to an address by clicking show mem in the breakpoint tab I'm not sure what "single line control" you're referencing. The scrollbar next to the DataGridView? The arrows next to the TextBox? Keyboard keys?When you set a read breakpoint on a file name and then cancel it and try to go to the memviewer if it's currently at the location of said file name it will freeze the game & Gecko.NET and then give an error message about loosing connection with the gecko, when you reconnect it will take you to the memviewer tab but the game will still be frozen, if you click run game the same thing will happen when you try to go back to the breakpoint tab except the game will unfreeze Setting a read (or read/write) breakpoint and, canceling it and then going to the memory viewer will result in Gecko.NET losing connection.The game will be paused (maybe because Gecko.NET itself will trigger the breakpoint?) and Gecko.NET will bring up 2 popups about reconnecting. I don't understand what "read breakpoint on a file name" means. We set breakpoints on addresses don't we...? Quote I can also confirm the step over bug. Step Over worked for me yesterday. Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl. It essentially "steps over" function calls without going into them.Quote Also, the step out function steps through the code until it sees "blr", but wouldn't it be faster to set a breakpoint on the LR? It would be faster, unless you already hit a bl in the current function, in which case that bl has overwritten the value in the LR. However, in that case you could peek at the stack for the LR save word (where the function prologue stored the LR so that the function can safely bl). However, a function doesn't need to store the LR save word if it doesn't call any functions itself, so you can't always peek at the stack. There are even some functions with multiple return paths (i.e. multiple blr's), so you can't even search for the next blr.Unfortunately, the safest way to Step Out is to repeatedly Step Over until you encounter a blr. Also, if Step Over doesn't work then Step Out wouldn't work either. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 10, 2010, 04:14:39 AM I'm not sure what "single line control" you're referencing. The scrollbar next to the DataGridView? The arrows next to the TextBox? Keyboard keys? The scrollbar Quote Exactly, for some reason the Cancel Breakpoint does not seem to work very well. If you do a read breakpoint and you go to Memory Viewer, it will break on itself. You should be able to hit run or reconnect to fix it. I don't understand what "read breakpoint on a file name" means. We set breakpoints on addresses don't we...? You have to hit run and then the breakpoint tab to fix it, I meant I set a breakpoint on the address at which a file name was loaded into memory I've since found out that the problem is not exclusive to such circumstances Quote Step Over worked for me yesterday. Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl. It essentially "steps over" function calls without going into them.. I thought it just stepped over any instruction or at least all jumps/branches Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 10, 2010, 11:53:40 AM Quote I can also confirm the step over bug. Step Over worked for me yesterday. Step Over should act like Step Into except for a bl, in which case it sets an execute breakpoint on the instruction after bl. It essentially "steps over" function calls without going into them.Quote Also, the step out function steps through the code until it sees "blr", but wouldn't it be faster to set a breakpoint on the LR? It would be faster, unless you already hit a bl in the current function, in which case that bl has overwritten the value in the LR. However, in that case you could peek at the stack for the LR save word (where the function prologue stored the LR so that the function can safely bl). However, a function doesn't need to store the LR save word if it doesn't call any functions itself, so you can't always peek at the stack. There are even some functions with multiple return paths (i.e. multiple blr's), so you can't even search for the next blr.Unfortunately, the safest way to Step Out is to repeatedly Step Over until you encounter a blr. Also, if Step Over doesn't work then Step Out wouldn't work either. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 10, 2010, 01:10:05 PM I remember it didn't step over the branch created by a C2 code, but I dont remember if it did that for a "bl". A C2 code doesn't create a function call...it's more like a detour. The code handler has to set up custom branches to and from the hooked address. It does this because not all functions push the LR on the stack, so bl is not safe. But it's a bit awkward because of the to and from branches. Normally, that's what the Link Register is for. It creates a link from the function caller to the callee, so that when the callee is done it can return back to the caller. Step Over does not really skip over code, preventing it from being executed. The processor still executes the bl, does all the work, and blr's back. We just don't have to put up with watching all the stuff inbetween the bl and blr. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 12, 2010, 01:14:01 PM I've been using this the last 3 days, love it! Thanks guys! :)
The ability to copy the text on the mem viewer and disassembler is great! Code tab is also much improved. :D Few questions/requests though, since that's what the thread's for: 1) Could you make it tell me when there are no results, please? :P 2) How do you do a multi poke? It didn't work on WiiRDGUI so I was really hoping to have it back since GCN hacking.... 3) Another "yes please" for an undo button in the search. ;) 4) Breakpoint Condition for Address -making it not break on some address x is super useful. (if it's there, I just looked over it, my bad..) 5) Take/Show/Hide Snapshot in memory viewer would be a nice convenience. Tis useful when searching around pointers to similar objects. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 12, 2010, 07:16:52 PM I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from.
It could be just like the step out, but it should stop when a specified register is used. Anyway, I would still like to thank you guys for the effort. Its a great app :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 12, 2010, 07:41:22 PM 1) Could you make it tell me when there are no results, please? :P 2) How do you do a multi poke? It didn't work on WiiRDGUI so I was really hoping to have it back since GCN hacking.... 3) Another "yes please" for an undo button in the search. ;) 4) Breakpoint Condition for Address -making it not break on some address x is super useful. (if it's there, I just looked over it, my bad..) 5) Take/Show/Hide Snapshot in memory viewer would be a nice convenience. Tis useful when searching around pointers to similar objects. 1) I will put in a message box that indicates a lack of results 2) Select as many addresses as you want (using ctrl or shift), then right-click -> poke 3) I'll see what I can do about undo. Loading/Saving searches can be slow and I'm not sure why. 4) Don't-Break-On-Address-Xyz can be accomplished with SRR0 != conditions. 5) I would like to eventually add snapshot support to Memory Viewer, and the Breakpoint tab. I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from. Hm...I like this idea. Repeatedly Step Into, until a specified register is a source or destination operand. Any implementation suggestions? Pop up a dialog box with a dropdown that allows you to select what register you are interested in? What could we call this? "Step Until"? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 12, 2010, 09:41:24 PM I would like to see a something for in the Breakpoints to let it break on the next time rX is being written to/ read from. Hm...I like this idea. Repeatedly Step Into, until a specified register is a source or destination operand. Any implementation suggestions? Pop up a dialog box with a dropdown that allows you to select what register you are interested in? What could we call this? "Step Until"? Step Until sound good, and yeah I was thinking of a popup with the controls. It could have a dropdown with the registers and maybe a selection for destination/source/both ? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 12, 2010, 10:08:23 PM That is a good idea!
Thanks dcx2! One thing though: Multi poke doesn't work. (for me) When I do what you said, it just makes the address part of the poke red and empty and I can't poke.. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 12, 2010, 10:15:48 PM Doh! You must be using a test build with AddressTextBoxes instead of generic TextBoxes. They validate inputs to make sure they're legitimate addresses - and when you Multi-Poke it fills the textbox with MP, which isn't a legitimate address. (they also have a history, kinda like the web browser address bar) I'll have to improve multi-poke support in the test builds.
The official 0.61 binary on the first post of this thread (http://wiird.l0nk.org/forum/index.php/topic,4886.0.html) should do multi-poke correctly, because it still uses generic TextBoxes. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 13, 2010, 05:07:09 AM Ah thank you!
There is no wild card search value (that I'm aware of). Could you add that, please? =) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 13, 2010, 11:31:25 AM Wild card search value? Could you elaborate on this, because I don't think I've ever seen this feature in WiiRDGUI.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 13, 2010, 02:08:02 PM It works in WiiRDGUI too, just checked.
32 bit search for: ?A?A?A00 returns results like: 1A2A7A00, 0A0A0A00,AAAAAA00 and so forth. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 13, 2010, 02:27:41 PM So they're like don't-cares? Normally you would want bit-level resolution for specifying such things, but I guess nibble-level resolution would be okay.
I might make a Mask field to do this, so we get the bit-level resolution. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 13, 2010, 02:34:58 PM Something I was thinking about is like a "Step To" or "Log Steps", which would step into until it has reached a specified address (or until the user cancels it) and everything is logged.
The log could contain at least the instructions executed, and maybe the values of the registers used. Also maybe making something like: 80151A8E0 Start 80151A908 branch to 80138F20 80138F20 start of subroutine 1 80138F34 branch to 802A8380 802A8380 start of subroutine 2 802A83F4 end of subroutine 2 80138F6C end of subroutine 1 80151A940 end but it wont be really necessary ;) Oh and I guess I found a bug? In the one line assembler I can't change something to "blr", so I have to poke it with 4E800020 every time. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 13, 2010, 06:03:32 PM I might make a Mask field to do this, so we get the bit-level resolution. That would be awesome!Just want to second that blr thing, can't assemble them either. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 13, 2010, 09:21:52 PM wiiztec has asked for logging before, but I like the idea of indenting function calls and echoing register contents. He has also mentioned Step until the Breakpoint conditions are satisfied; this could be an option in the Step Until... dialog box. This would be a somewhat lengthy adventure so it might be a while before such a feature shows up.
Regarding blr, I think I noticed the assembler throwing a hissy fit when I tried to put in bctrl. I'll look into this. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 15, 2010, 07:48:15 PM Could you move show mem to that vacant spot in the step group often one would press show mem after stepping so it would make sense for them to be close together,
also if you squeezed the registers a little closer togehter and maybe just make Gecko.NET as a whole a tiny bit longer you could use that space where show mem used to be for the active conditions textbox (you could put "skipped" beside the "step" that denotes the step button group (it is related after all)) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 17, 2010, 01:08:07 AM Could you move show mem to that vacant spot in the step group often one would press show mem after stepping so it would make sense for them to be close together, Step Until is probably going to go in that blank spot. It will have two functions that you choose from a popup; it will repeatedly Step Into until a specified register is used as a destination or source, or Step Into until the Breakpoint Conditions are satisfied (you asked for this earlier). Quote also if you squeezed the registers a little closer togehter and maybe just make Gecko.NET as a whole a tiny bit longer you could use that space where show mem used to be for the active conditions textbox (you could put "skipped" beside the "step" that denotes the step button group (it is related after all)) I'll consider moving Show Mem up to the top beside the Step box, and perhaps Delete/Clear so that they're above the Breakpoint Conditions. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 19, 2010, 09:25:54 PM How about something like this?
(http://i47.tinypic.com/2iqohnm.jpg) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 19, 2010, 10:39:09 PM lmao
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 20, 2010, 02:41:21 AM Thanks for all the work on this man, much appreciated. =)
Another Request: A search option to swap between signed/unsigned comparisons on the type (8/16/32/Single Float). Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 20, 2010, 01:37:14 PM I am already considering a multi-level Undo with a complete history that optionally will add extra columns to the search result ListView for each level, so you can see every search result there ever was. I mentioned this back in my "what do I have planned?" post, at the top of page 7 of this thread.
I am also considering looking for a + or - in front of the search value as an indication of a signed search. No + or - would indicate an unsigned search. FYI, there won't be much motion on this for a week or two. I might do some rearranging of the Breakpoint tab, because that's quick and easy and wiiztec gave me a few ideas. Eventually, though, I'd like to rev up to 0.62. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 21, 2010, 09:08:22 AM Repeatable Bug: If USB Gecko disconnects, you can't restart the search when you re-connect (the button is greyed out).
Request: In unknown searches, "equal to old value" would rock my socks. ;) Good luck with whatever's got you busy on the outside! Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 21, 2010, 12:16:06 PM I'll look into the button greyed out thing. If any buttons get greyed out and they shouldn't be, pressing the Reconnect button should fix it.
Not sure what you mean by "unknown equal to old value". On an unknown search (which is only the first search), there is no old value. After your first unknown search, you're comparing against last value. And we do have "equal to last value". Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 21, 2010, 10:34:54 PM Yeah, I don't know why I specified the start type search. Anyway, Equal to last is comparing the "New" value in the search history. If there was one that compared to the "Old" value that would be awesome.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 21, 2010, 10:36:15 PM Ah, okay, I kind of see where you're going.
This ties in somewhat with the multi-level undo. I was also considering adding "first" to "last" and "specific". Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on May 22, 2010, 12:07:08 AM I was thinking about something like an auto-poke.
Like you start autopoke like you would with multipoke, but it just pokes the first address then 1 second later it pokes the second address and 1 second later it pokes the third etc. It could be a popup with options like what value to poke and if it should repeat after the last address, set the delay and maybe like if the value should be increased with every poke/after last address is poked. And like a Start button, a Stop button, a Pause button and a Step button? Edit: Also something I would love to have is keyboard shortcuts for Step into, Step out and Step over. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 24, 2010, 07:03:07 AM The text view of the registers is screwed up in r75 also there's an unnecessary horizontal scrollbar at the bottom of edit view
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 24, 2010, 12:13:49 PM Could you post a screenshot of the unnecessary horizontal scrollbar? Everything looked fine to me.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 24, 2010, 01:14:41 PM (http://i50.tinypic.com/28i6pnc.jpg)
(http://i45.tinypic.com/jkyq2t.jpg) Also not trying to be demanding but why didn't you use the layout I suggested? your's wastes a lot of space, are you planning to put some things there? log steps? register snapshots? ah well no big deal although show mem is still a little farther from step into then I would perfer Also what's with the space below the active conditions box? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 24, 2010, 03:18:20 PM ive got a simple request. how about less prompt windows? there is a status bar at the bottom of the program, i would like to make more use of that and not have prompt windows except on errors. Like the "successfully saved gct list" or whatever it is message, a simple message in the status bar would suffice.
and for the promptwindows that do show up, it would be nice to have them aligned to the rest of the program rather that to pop up in the middle of the screen. in my PC i have dual monitors. both use the same desktop. if i have dragged the program to my second monitor, and then started watching a movie on the first monitor and i get a prompt from this program, the prompt shows up right in the middle of my movie. is there a way to tell the promptwindows to pop up in the middle of the geckodotnet window instead of in the middle of the primary monitor? also, if i have the notepad open and a do a search, it closes the notepad. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 25, 2010, 01:16:24 AM @wiiztec Isn't the window re-sizable?... Think that might solve your problems there.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 25, 2010, 01:38:25 AM It's not horizontally resizable
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 25, 2010, 03:31:04 AM @wiiztec: There's more stuff that needs to eventually go on the Breakpoint tab, like logging. I'm also open to moving things around a bit more. For instance I might try to get rid of Text/Edit View button somehow. But I figured what you wanted was an Active Conditions that resized independently of the registers/disassembly.
The space below the Active Conditions box is a result of the ListBox always wanting to be an integral height. It won't show partial rows. Watch it when you resize slowly, and you'll see what I mean. Oh, by the way, it does resize horizontally too. @Romaap: I like the idea of a step-multi-poke. I don't know if I like auto-multi-poke as much, but I might change my mind once step-multi-poke is there. I *really* like the idea of shortcutting the Step's. I'd do just like Visual Studio; F10 is Step Over, F11 is Step Into, Shift+F11 is Step Out. Maybe Shift + F10 for Step Until or something. F9 for Show Mem? Only if Breakpoint Tab is active... @giantpune: I can empathize with the dual monitor situation. I actually have three monitors at work. ^_^ There should be a way to coax the message box into popping up centered above the app. And I'll see what I can do about moving from message boxes to the status bar. I usually just hit the space bar to make the message box go away. Regarding the notepad...I've never even used the notepad. I use OpenOffice's word processor, so that I can save screenshots. But I'll look into it. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 25, 2010, 03:49:50 AM I know the whole Gecko.NET window is horizontally resizable I was talking about the register window, not that I want it to be horizontally resizable I just thought that was what James was talking about.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on May 25, 2010, 04:22:21 PM while youre busy adding in those keyboard shortcuts for breakpoint stuff, how about making the Del button remove addresses from the watchlist?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: paprika_killer on May 27, 2010, 06:41:44 PM I have a request (either app):
A built in (dis)assembler, like asmwiird. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 27, 2010, 06:51:48 PM I was considering adding a Tools menu, which you could use to launch calc, PyiiASMH/asmwiird, a word processor, etc. It would support the game name as an argument. e.g. notepad %game%.txt where game = SB4E01 would actually run "notepad SB4E01.txt".
I also considered adding a button to the Code Wizard or a shortcut to the GCT Code Context Menu that would copy the C2 code into the clipboard and then launch PyiiASMH/asmwiird. Not quite built in... If someone would like to try porting one of those apps to C#, I would consider integrating it directly into Gecko.NET. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on May 27, 2010, 08:23:59 PM Some more bugs/requests
• As the screenshots I posted above show the register window is screwed up (especially in text view) • also concerning the register window I noticed that if you were looking at the floating point registers the text view jumps back up to the normal registers when you press step edit view doesn't have this problem • in mem viewer if you do any action that will result in mem viewer jumping directly to a specific address and then you manually change the highlighted cell, and then change the page with the arrows next to the address box the highlighted address will change to the address at the grid position where the address you originally jumped to was • continuing from a saved search still doesn't work most of the time (I think I got it to work right about 3 times) • when reordering codes on the GCT code tab somehow the code you're moving frequently will somehow overwrite some of the codes you drag it over on the way up/down • a back button for mem viewer for if you accidentally double click a pointer address or something • In the context menus applicable clicking "new GCT code" and then pressing cancel won't do anything it just creates the code anyways • deleting codes from the code search doesn't work • on the search tab when you select multiple result and make a new GCT code the values of the code created will all be zeros instead of either the last or the new values of the search • just got a great idea for a search option a different kind of pointer search, not one that searches for a pointer but one that searches starting at the address that a pointer points too, searches would return pointer offsets instead of addresses.The purpose of this new "pointer search" would be to find values that you think would fall under a pointer you've already found, to use it you would put [] brackets around the start address on the search tab A non hypothetical example of this being useful would be a code I am trying to make for SMG2 that gets rid of the shaded corners the prankster comet missions, the only way to do a search for this would be to change levels from levels with the shading to levels without it, but doing so would probably cause the dynamic memory to change, however I have found a pointer that is related to things displayed on the screen & with this new pointer search (assuming the pointer is indeed related to the shading) I would be able to make the code Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hawkeye2777 on May 28, 2010, 03:37:28 AM I also considered adding a button to the Code Wizard or a shortcut to the GCT Code Context Menu that would copy the C2 code into the clipboard and then launch PyiiASMH/asmwiird. Not quite built in... If someone would like to try porting one of those apps to C#, I would consider integrating it directly into Gecko.NET. You'd just need the CLI portion ported, right? (no gui specific parts) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on May 28, 2010, 03:46:26 AM Well, if you'd like to draw up the form in the Designer view for me, that'd be even better. ;D But anything would be a good start.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hawkeye2777 on May 28, 2010, 10:04:31 PM Well, if you'd like to draw up the form in the Designer view for me, that'd be even better. ;D But anything would be a good start. Can't do that, sorry (I do have a Windows partition, but I do not have enough space to install VS). Monodevelop only has a GTK# designer, not a Winforms designer. Should be able to whip up a port in a week or two; I have a few other projects I have to focus on in the meantime. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on May 31, 2010, 07:24:26 PM When you flip to the last page of code results, the table still displays the max number of rows rather than just displaying the last page of results. The rows beyond the end of the results have the data from the previous page.
edit: Also a request for LR in BP conditions list. =) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 01, 2010, 12:03:45 AM I think the problem you're having with the table showing too many rows is related to wiiztec's search results that aren't deleted. I think I actually found that bug while making SMG2 codes.
re: LR in BP cond list, it's there. Oddly, LR is listed between the normal and float registers. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: adam5366 on June 02, 2010, 11:03:12 AM It would be good if there was a simple search for the FST in Gecko.net
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 03, 2010, 08:17:32 AM If USB Gecko becomes disconnected, auto update in mem view should be turned off by the program.
This game an hero'd because I created an inf loop *twirls finger in air*. Gecko dotNet then went to its own happy infinite loop of telling me the USB Gecko was disconnected, via the popup. =) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on June 03, 2010, 12:40:00 PM That's new to you?? just unplug/replug
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 03, 2010, 01:34:54 PM I got hit by that infinite Disconnected dialog the other day, after it had been left on all night. I don't think disconnecting the cable helped. It might have something to do with the making the Connect button cancel-able...
EDIT: oops, missed adam's post. I've never used the FST tab or any of its functions, so I wouldn't know really where to start...I believe hetoan also said that the FST tab didn't work? Maybe that was for one game in particular... Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 07, 2010, 01:24:38 AM Requests:
Breakpoint Tab * Edit FP registers in "edit view" * Let "Show mem" work for indexed asm instructions * The ability to set breakpoints within a range of values, or even in multiple places at the same time- if that's possible. Most frequently useful though would be just to set the bpw,bpr,bprw range to anywhere in the 32 or 16 bits- depending on the address alignment. Memory View Tab * Value Poke only grabs the memory at that address you select when "write" is selected. Else default value is 0 (or 1 if 1 is the current value). * World Peace I sincerely appreciate your work on this app man. Thank you!! =) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 07, 2010, 02:05:51 AM * FP registers cannot be edited. That is a limitation of the PowerPC, I believe.
* Can we get a list of instructions, specifically? lbzx/lhzx/lwzx/lbzxu/lhzxu/lwzxu? Any others? * Multiple breakpoint addresses is probably another limitation of the PPC. * Are you telling me how you want the MemView poke to behave, or how it is behaving right now? I am keeping track of the list of requests. I'll probably publish an updated wish list again soon. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 07, 2010, 05:48:57 AM lfsx
lhax lhaux lswx lwbrx lhbrx lfsux ....does show mem work for storing words? I can't remember.. And the MemView Poke stuff is how I'd like it to behave. Sorry for being unclear. I love that it's there at all though! :P Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 07, 2010, 03:31:39 PM Where the hell did some of those op codes come from? lswx (load string word indexed?)? lhbrx (load halfword branch indexed?)?
Yes, Show Mem is supposed to work for any data access instruction, Load or Store. Instead of doing string comparisons on the assembly, I may just try to parse the machine code directly... Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 07, 2010, 09:56:31 PM String word indexed, yep. The 'br' means "byte reversed". If you read these 32 bits (FF223456) you get this (563422FF).
The 'a' means "algebraic". Dunno why it's that word but it sign-extends 16 bits to 32 bits by copying the first bit of the half word to the remaining 16 bits. And just for completeness sake, 'fs' is "float single". I haven't ever used the byte reversed ones. But the rest of them in my post are all in ASM WIP files from way back in GCN hacking. Yay ^^ =P Anyway, this is where I learned them from and I always use these references when my code wont compile or I see something new-- however there are handfuls of op codes I've seen in games that are not in these though!: http://class.ee.iastate.edu/cpre211/labs/quickrefPPC.html http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangref02.htm#ToC_237 I have more in my bookmarks somewhere, but those are my 2 favs. Cheers! =) Oh, Request: When you double click on a value in mem view, it will go to it if it's an address. Could you please add a "go back" to the right-click context menu? If it's not a big pain, maybe even a small, 4 or 5 history stack? :3 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 07, 2010, 10:12:53 PM Wow, there's a byte reversed load? That's typically the kinda thing you see on a DSP, not a general-purpose processor like the PowerPC.
You sure a = algebraic, and not arithmetic? When doing bit shifts, a "logical" right-shift will not sign extend but an "arithmetic" right-shift will sign extend. That kinda makes sense, and is actually quite useful at sparing an extsh or extsb. One of the very rare multi-tasking RISC instructions...like stwu. I use this link for most of my inquiries into PPC ASM. http://pds.twi.tudelft.nl/vakken/in1200/labcourse/instruction-set/ Finally, the request...all text boxes that hold addresses support a History function. Right-click on it; there are also keyboard shortcuts for this purpose. They should be on automatically, but you're the second person to make this request, so they might not be on auto...anyway, I can look into making the MemView-Double-Click also add the address to the History of the MemView Address textbox. Not quite a "go back", though. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 08, 2010, 03:17:07 AM @ History Request stuff: Oh, wow, missed that. Thanks man. =) Adding the double click to history would be much appreciated!
@ the ppc link: I have that one bookmarked too :P @ meaning of 'a': Uh.. I dunno what it means for sure I guess. That's just what I learned it as. If you do find out for sure one way or the other, let me know too, eh? :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 08, 2010, 04:55:56 PM I believe double click will show the history. I also believe the hotkey for adding to the history is ctrl+enter. You can also ctrl+shift+c/v to copy/paste the history contents to/from the clipboard.
In the next release, I think I'll try to add the shortcuts in parentheses in the context menu. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Skiller on June 15, 2010, 02:06:19 PM Here's 2 Bugs 1. Memory viewer crashes the game randomly. 2. Randomly Disconnecting while doing a search. Also, when bug 2 does occur, my search is gone. No undo button either. So basically, I have to start over >:( Im goin to guess that this happens with Wiird .. iv had this issues alot on wiird.. normaly if your Moving in and out of Tabs to fast . Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on June 15, 2010, 02:29:21 PM It doesn't
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: ardemii on June 15, 2010, 04:58:09 PM wiirdGUI and geckodotNET request an adress searcher.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 18, 2010, 05:21:17 PM Mine does that too, so did GCNrd. But I think this thread is just for WiiRD (console) and Gecko dotNet (GUI).
You should use Gecko dotNet though; it has many more features and abilities than WiiRDGUI. =) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 18, 2010, 05:55:11 PM Wait, you're losing codes? As you say, losing codes is a deal breaker...Gecko.NET used to lose codes when I first used it in like March, but I thought Link fixed that.
Can you explain the sequence of events that leads to lost codes? i.e. add a new code, give it a name, select it, etc. Does it only lose codes that haven't been saved by pressing Save Code List? I wonder...when a disconnect happens, all of the GUI controls are disabled. Perhaps this disabling is what causes the codes to get lost? I also wonder if it's not the crappy USB cable...a ferrite bead (http://en.wikipedia.org/wiki/Ferrite_bead) might help. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 19, 2010, 03:04:31 AM Mathew - thanks for pointing out the vanishing codes bug. It's been fixed now...I'm sorry you had to go through that frustration.
EDIT: Some background might help explain why there was a bug...when you connect to a game, it will load the codes for the game from the file. When reconnecting, it would load the codes from the file again. Unfortunately, it wouldn't prompt you if the codes were modified. That's fixed, too. But now, if you're reconnecting to a game that's the same as the game you disconnected from, it will no longer load from the file. However, if you change games, it will prompt you and then load from the new game's file. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hronny on June 19, 2010, 04:38:03 PM I am a beginner with USB Gecko, but i have a little problem with Gecko dotNet. If i search for a value in a game, and the Gecko dotNet loose the connection after the search, you can connect to the game with the button "reconnect". The button works and the reconnect works too, but all buttons in the Gecko dotNet are disabled except the disconnect button.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 20, 2010, 01:10:24 AM I think I've seen that happen to me once before. If you reconnect a second time, all of the buttons will be enabled. I'll look into it once I have some time.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hetoan2 on June 20, 2010, 10:25:37 AM A good feature would be something like the snapshot feature that wiiRD has, only less annoying. I'd prefer that the button would have to be held to show the snapshot, not just clicked, because in WiiRD i forget that it's a snapshot and think the address isn't changing. Either that or add an easier way to identify if it's the real value or snapshot.
Also it'd be very helpful if you could Poke Ascii values, without having to find a converter online. James's version is great for making codes, but having it done automatically with pokes would be great. Also i dont know if this will help fix the FST viewer, but the original one with GeckoDotNET was amazing :( http://wiird.l0nk.org/forum/index.php/topic,3519.0.html Ehh... also it'd be good if we could get something to upload files to the game like the dump and upload commands for WiiRD (not gui) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on June 20, 2010, 08:02:45 PM A good feature would be something like the snapshot feature that wiiRD has, only less annoying. I'd prefer that the button would have to be held to show the snapshot, not just clicked, because in WiiRD i forget that it's a snapshot and think the address isn't changing. Either that or add an easier way to identify if it's the real value or snapshot. Yeah, and if a value is different from the real give it another colour so it is easier to see if a value has changed. =DTitle: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hetoan2 on June 20, 2010, 11:49:54 PM Just to add onto that color idea. It'd be best if the colors were done in 8 bit that way you can see the individual change instead of having to find it within the 32 bits
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Panda On Smack on June 21, 2010, 10:57:51 AM I find that if you drag a code (A) in the list above another (B) it overwrites the content of that code with what you moved above it so you end up getting a duplicate of what you moved
So code A dragged above B moves them correctly but Code B ends up having its content replaced with Code A Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on June 21, 2010, 12:11:34 PM Yeah I posted about that back on page 11
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 21, 2010, 01:29:42 PM Panda was explicit about the conditions for creating the bug...wiiztec was a little vague about dragging and dropping. Even with Panda's explicit instructions for reproduction, it still took me like two hours to figure out what was going wrong, and one line of code to fix.
I know there's also a Text View bug but that bothers me a lot less than screwed up codes. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mokuro on June 23, 2010, 01:06:52 AM I dunno what happened to the breakpoint not doing anything. I've been using the program for days and suddenly breakpoint function stopped woking for me since today. Notice in the video I've included when I click Text view, everything disappears. I tried rev80 and I still get the same issue. I'm on Vista though. http://tinypic.com/player.php?v=2n02ek5&s=6 I named the video bp,lol. Thanks O0 Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 23, 2010, 02:23:39 AM When you click GCT code from the code search box. It will add them but the value will always be 00000000. It's very annoying to have to change it every time I add a code. What exactly would you like the default value to be; old value, new value, etc? Do you have any reasoning behind your decision? Quote Mario galaxy seems to have issues with sending cheats. It sets the game into this weird lag with music still playing. This is weird, because I've hacked both Galaxies with this app...Do you have Pause While Sending checked? That should be the only thing that can cause that sort of issue... Galaxy 1 or 2? What hook are you using? What types of codes are you using (04ish codes, or C2ish codes, or F6ish codes?)? If you have BPNext checked on the About tab, and you press Pause/Next a few times, do you have the same problem? If you're feeling particularly adventurous, you could provide me with dumps of the cheat stream from both apps. When you "send cheats", the application generates a bunch of bytes and sends them to Gecko OS. If you do a 16-bit search for "C0DE", you should see three results that are really close to each other very low in memory. Switch to Memory Viewer at those addresses and you'll see what WiiRDGUI and Gecko.NET have sent to Gecko OS. You can easily Copy All in Gecko.NET's memory viewer and paste the text here, and to get WiiRDGUI's cheat stream you can Send Cheats from there, then switch to Gecko.NET and Copy All in Memory Viewer again. Sorry to place that burden on you, but I can't replicate your problem... =( I dunno what happened to the breakpoint not doing anything. I've been using the program for days and suddenly breakpoint function stopped woking for me since today. Notice in the video I've included when I click Text view, everything disappears. I tried rev80 and I still get the same issue. I'm on Vista though. Have you tried older versions of Gecko.NET? Also, Text View won't show any registers until a breakpoint has been hit. Have you tried BPNext and pressing the Pause button? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mokuro on June 23, 2010, 03:37:36 AM Alright I just found out what was preventing the breakpoint from functioning. I realized that I had to reset the game each time I want to use breakpoint. So this means that I can only do 1 breakpoint until I reset the game. This really needs to be fixed. ::)
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 23, 2010, 04:12:59 AM Mathew - I did ten MEM2 searches and I had no disconnection problems. I even tried pausing the game and doing unknown-equal searches so that way it would query every address in memory. I'm going to leave MemView Auto-Update on all night to see what happens.
Mokuro - Until you provide me with the instructions I need to reproduce your bug, I can't help you. And with that attitude, why should I? No one else has problems with breakpoints, so as far as I know, the app is not what needs fixed. ::) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mokuro on June 23, 2010, 04:49:04 AM Will provide you with more information regarding the issue I have with breakpoint later today. Because I still can't access the breakpoint even though I told you that I had it fixed when it's not. :-\ I've never had problems using BP with Wiird except that Wiird crashes and freezes several times on me.
Edit: My bad. I should have asked you nicely. I do appreciate the time you spend fixing the bugs. :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Romaap on June 23, 2010, 10:58:00 AM Mokuro, are you sure you have set the breakpoint on the right bit-alignment?
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: hetoan2 on June 23, 2010, 11:42:00 AM Mokuro, are you sure you have set the breakpoint on the right bit-alignment? Thats what i was thinking. If its a 32 bit ram write (most are), then you have to have the address end in 0, 4, 8, or C.I'm almost positive this is just a noob error. I occasionally even click on the wrong bit when moving it over to the BP tab. You should probably stay away from exact matches... it helps to prevent user error. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: James0x57 on June 23, 2010, 12:23:23 PM Some games BP's crash the game on use, shortly after use, or on next use. I really don't think it's a GUI problem though; for me WiiRD GUI has the same result.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on June 23, 2010, 02:54:57 PM I've also experienced the problem of Gecko.NET lagging Super Mario Galaxy to a nearly a complete stop when applying codes, I've tried all the hooktypes and none of them fix the problem yet with WiiRd I experience no such problem, I can't remember if I tried with "pause before sending" unchecked though
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mokuro on June 23, 2010, 03:34:21 PM Alright. I just checked BPNext box and pressed pause and pressed "set" and guess what? It WORKS. :eek: Do I have to do this every time I want to use breakpoint ?
and thank you guys for all your efforts. Keep it up. :cool: Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 23, 2010, 06:29:59 PM wiiztec - the original SMG? No problems with SMG2? What codes are you using?
Pause While Sending was designed to overcome a problem where repeated application of C2 codes can cause games to crash. This is a symptom I first observed with WiiRDGUI and Ghost Squad, though I have seen it in other games too, like Okami. All it does is pause; send cheats; unpause. In theory you could do the same thing with WiiRDGUI (and in fact that is what I had to do before I started working on Gecko.NET) I don't see why Pause While Sending would cause any slowdowns... --- mokuro - WiiRDGUI's next button isn't very reliable; it pauses the game, waits for a few milliseconds, and then unpauses the game. Sometimes, you will see two frames go by after only a single click. This was a pain in the ass when trying to find timers using different-by-1 searches, so I had to find some way to advance the game one frame at a time. Before Gecko.NET, this involved setting an Execute Breakpoint on 800018A8 (the first instruction in the code handler, which *should* execute once per frame). This led to a lot of switching back and forth between the Breakpoint tab and the Code Search tab. Gecko.NET's BPNext streamlines this process. It makes the Next button set an Execute Breakpoint on 800018A8. That's why I asked you to try BPNext; because if you can use BPNext then there is no problem with Breakpoints. BPNext should have nothing to do with the actual act of setting a breakpoint. You need to provide information. Are you setting a read, write, read/write, or execute breakpoint? On what address? Is "Exact" checked? Do you have any Breakpoint Conditions? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Mokuro on June 25, 2010, 03:34:02 PM Never mind. I'm the one who needs to be fixed. I didn't know the real purpose of the breakpoint function until yesterday when I hacked some flash games on FaceBook using Cheat Engine. The BP in Gecko.Net is working like a charm. I no longer need to check the BPNext box anymore. dcx , thank you so much for your support for this great app. Keep it up.
:D Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 25, 2010, 04:11:23 PM Glad to hear that your issue has been resolved. Happy hacking!
In case you aren't aware of how the Step buttons work... Step Into always go to the next instruction, and this includes going "into" a function call (bl/bctrl) Step Over will usually go to the next instruction, except for function calls; it will instead go "over" the function call to the instruction after it, allowing the function to do all of its work without forcing you to Step through all of it. Step Out will repeatedly Step Over until it gets to the blr; it goes "out" of the function to the caller. I plan on working on an update to Step Out that will hopefully avoid the "Step Over repeatedly" by analyzing the stack frame for the LR Save Word, or using the value in the LR directly if we're in a leaf function that has not created a stack frame. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on June 25, 2010, 06:29:49 PM I don't see why Pause While Sending would cause any slowdowns... That's not what you said before This is weird, because I've hacked both Galaxies with this app...Do you have Pause While Sending checked? That should be the only thing that can cause that sort of issue... wiiztec - the original SMG? No problems with SMG2? What codes are you using? Pause While Sending was designed to overcome a problem where repeated application of C2 codes can cause games to crash. This is a symptom I first observed with WiiRDGUI and Ghost Squad, though I have seen it in other games too, like Okami. All it does is pause; send cheats; unpause. In theory you could do the same thing with WiiRDGUI (and in fact that is what I had to do before I started working on Gecko.NET) Yes Super Mario Galaxy not Super Mario Galaxy 2 i'm never vague about what I'm talking about, It doesn't matter what codes I use it's pressing the send to game button that causes it, I am aware of the purpose of the pause before sending checkbox, back when I used WiiRd I would usually pause before sending codes or ASM instructions. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on June 25, 2010, 06:46:02 PM The reason I said it could be Pause While Sending is because that should be the only difference between how WiiRDGUI and Gecko.NET send cheats. Several weeks ago, I noticed there was a difference in how they create the cheat stream, but I fixed that.
Have you tried sending codes with no codes checked? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on July 08, 2010, 04:32:00 PM I moved your post, Panda.
That's weird because I know I tried testing it out to make sure it works...check the GDNdebug.log that's in the same folder as the app. Do you see any exception code text at the bottom? What type of search are you doing? Unknown, specific? 32-, 16-, 8-bit, or Single? Are you sorting search columns? r87 had a bug where the search MUST be sorted by address ascending (the default); any other sort will cause a crash...but that's when a search begins. r88 is just released, that might fix your problem. I fixed the sorting bug, and added search comparison groups. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on July 08, 2010, 04:53:26 PM Not to be rude, Panda...but please quit posting bug reports in the release thread. The release thread is meant to be for detailed explanations of the new features that are being added, and the occasional encouraging reply of "this feature rocks".
Also, please provide more details so that I can replicate your bug. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Panda On Smack on July 12, 2010, 03:42:40 PM yeah, misunderstanding there dcx, browser went a bit funny and it didn't show my post so I resubmitted.
anyway, here is the error when I debug with VS: (http://img180.imageshack.us/img180/2231/errorhjt.jpg) I'm on Win 7 64 if that helps. I have fixed it by downloading Ionic.Zip.Reduced.dll and putting it in my Gecko dNet directory. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on July 12, 2010, 04:05:08 PM DUH! I can't believe I forgot that. After a search runs, the result is compressed using DotNetZip (free and open source). I was supposed to investigate post-build events and ILMerge so I wouldn't need to distribute an additional file...but I was too eager to distribute the new build.
For anyone else who has problems searching, you can use this copy of Ionic.Zip.Reduced.dll (http://www.mediafire.com/?ddznjnqzjwj). BTW Panda, you don't need Visual Studio. If you go to the folder where Gecko.NET is running from, you will see GDNdebug.log, and in it should be a copy of any exception that gets thrown, as well as a date/time when it happened, and the Call Stack that generated the Exception. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Panda On Smack on July 12, 2010, 04:27:08 PM No worries :)
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Bully@Wiiplaza on July 25, 2010, 08:40:54 PM - yeah searches are compressed as zip files, and they can´t be loaded... (Nothing happens, when you press Load Search)
- It would be useful, if you could include this: "The same as the value 2 searches before" Because e.g. if you want to make an item hack and got a fake box. You search unknown value, then if you got a banana, you should search unequal. But if your third item is a fake box again, you would like to say: "The same value as 2 searches before" Got me? :) I hope it´s possible... best would be, to select, how much searches you want to go back with the "equal value search". Finding values will be easier... :eek: - Ability, to check geckocodes.net for codes for the running game and puts the codes in the gct codes tab, if you want it this way. ---> specific button to do that (Easier to check the made codes, and no long copying of codes) It should be stored as an extra wmg file, that it won´t overwrite your codes! - history for the disassembler that you can get the original instruction back, if you forgot to copy it and overwrote it. Otherwise you sometimes need to restart, to work on ::) Greets Bully! :o Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on July 25, 2010, 11:29:19 PM Bully -
Save/Load search will probably disappear soon. They were made obsolete as part of the search history stuff. Most of your other suggestions seem to be handled by the search history thing...use the spinners above the New and Old columns to go back and look at or compare against previous search results. Scrolling New will adjust the search result address list to match the value you scrolled to. Scrolling Old will keep the current search result address list, and flip back through old searches. I've also considered integrated support with the code database, but I haven't gotten around to it yet. I like the idea of the disassembler history. I think if I dumped a compressed copy of the MEM1 contents when Gecko.NET is loaded, the "history" could just look at the original value. Though this feature would get foiled by games that only keep a few chunks of ASM in memory at a time. --- Mathew - That's much more clear. You want the value in the New column to be pre-loaded as the value when you create a new code. I'll get that in the next test build. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on July 28, 2010, 02:16:28 PM Save/Load search will probably disappear soon. They were made obsolete as part of the search history stuff. Is search history kept even after closing Gecko.NET? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Deathwolf on July 28, 2010, 02:27:15 PM dcx2 please can u change the size in memory viewer of values?
like a size modifier^^ Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on July 28, 2010, 02:35:41 PM They're not deleted, but they are recycled every time you start a new search. I have 14 dumps right now in the history and they're 20 MB total...so I didn't think about deleting them. I was also considering a temporary sub-folder for those kinds of files (and logs etc) to keep the main folder a bit cleaner.
There is no support for loading a previously abandoned search history, though if there's interest I could probably wing it. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on August 01, 2010, 05:18:34 PM There is no support for loading a previously abandoned search history, though if there's interest I could probably wing it. Well the reason I used to save searches with WiiRd is in case the it crashed or if I wanted to resume a search later, WiiRd had 10 number'd searches you could save. I liked how Gecko.NET allowed you to have an unlimited number and allowed you to name them something meaningfull, now with r91 it seems the save search button if it even does anything doesn't allow you to name the search anymore. Is this removed support or a bug? Anyways I have a few bugs to report • I haven't used it much yet but everytime I do searches with r91 the status bar eventually gets stuck between 0 and 100 percent, even though the search and subsequent searches seem to finish fine, it's not purely a cosmetic problem however as it renders Gecko.NET incapable of restarting the search • "skipped" only records instructions skipped when you set a breakpoint with conditions, not when you step into, or step until Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 01, 2010, 06:14:23 PM r94 is out, btw. A few minor improvements, like a Show Mem context menu
Yes, save and load buttons were disabled when Undo Search was added back in r85. This is something I would have to add back, as the search functions have undergone major changes to support things like Undo Search and Search History. I hear your concern about crashing, but as of r90 the search is crash- I'm not sure what you mean by being incapable of restarting the search. When it recovers from an exception, I think the search progress bar will re-start from 0. Is this what you're talking about? Does it gray out the Restart Search button until you do another search? Do the search indexes keep counting normally? I'll look into making Step Until count the Skipped Instructions up, but it will have to wait until after I promote r94 to official. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on August 01, 2010, 07:07:33 PM I'm not sure what you mean by being incapable of restarting the search. When it recovers from an exception, I think the search progress bar will re-start from 0. Is this what you're talking about? Does it gray out the Restart Search button until you do another search? Do the search indexes keep counting normally? There is no error message the progress bar(not the search itself) gets stuck at around 70-80 percent and the restart search is gray'd out no matter what you do, besides that everything is normal Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: wiiztec on August 01, 2010, 08:59:45 PM Ok I just tried r94 and it gives me a "Gecko.NET has encountered a problem and needs to close" message when a write breakpoint triggers at 8102C29C in prince of persia the forgotten sands. I tried another address to break on and it didn't cause Gecko.NET to crash. judging by a similar code I made the instruction at 8102C29C is probably a stwx
I just checked with r91 and it is a stxw and I think the problem is related to the show mem context menu Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 02, 2010, 03:09:39 AM Yeah, it's related to Show Mem, I tried to add support for all the memory operations but I messed up the indexed load/stores. I found that bug earlier today while trying to hack some RE4. I'll be releasing something tonight that fixes the stwx type stuff.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 06, 2010, 10:44:41 PM wiiztec, I am unable to replicate the search-stall bug. So I can't address it. If you run into it again or you come up with any more details, I can try to find it again.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on August 19, 2010, 04:18:44 AM I found a bug using r95 on windows XP x64. The program crashes if you try to open its built-in notepad and there is no game ID. To reproduce it...
1) eject any game from your wii 2) start geckoOS 3) start the rebooter. it says "rebooting... no disc inserted" or something like that. then the system menu comes up. 4) start geckodotnet.exe r95. it starts as normal. the title bar just says "Gecko dotNET()" as there is no game ID for it to read. 5) click the "open notepad" button. 6) Code: See the end of this message for details on invoking 7) its not a fatal error, as i can just click continue and it keeps on chugging, but it cant open up the notepad and keep notes for debugging the system menu Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 19, 2010, 02:20:31 PM Mathew - I think multi-poke is a 32-bit thing only...I'll have to double check.
The more important issue is lost searches. I tried to make it so you can unplug the USB Gecko during a search, plug it back in, and continue searching. Are you doing anything to cause the disconnect, or is it at random? Can you go into the GDNdebug.log file and see what exception you're getting? giantpune - I will look into the notepad thing. It should be a relatively simple fix. Thanks for the Exception text...the stack trace is the most important thing anyone can provide. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 19, 2010, 03:25:06 PM I think I actually encountered that with Fatal Frame 4, when searching for CCCCCCFF, for some reason it would get all the data transferred and just...fail. I think I fixed that bug recently...we'll see if it fixes things in the next release.
BTW, the log is time/date stamped, so if you know about what day you had the problem (August 7th was your post) then that might make it easier. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 21, 2010, 06:21:18 AM giantpune - I realized after posting r96 that I didn't take the 30 seconds needed to fix the Notepad support for the System Menu. Rather than add another release post to the thread, I'm going to just point you at test build r97 (http://www.mediafire.com/?iti7cv1z1ahrp0l), which added Notepad support for System Menu debugging.
Mathew - I'll have to test multi-poke a bit more, but apparently the size of the poke is determined by the number of bytes you have in the poke text box. Also, r96 has a fix for searches that might help the problem you were having. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: DR4G0N on August 23, 2010, 11:43:51 AM maybe u would be so kind to consider adding a pointer tab ;D
as i have problems keeping wiirdgui to stay working and dotnet has given me no probs whatso-ever so far, i would greatly appreciate it Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 23, 2010, 01:35:25 PM Link mentioned ages ago that he wanted to make a separate pointer-search app. But since it looks like everyone really wants that feature, then I would need a good description of how it works. I never understood how the pointer tab worked...and it seemed like so much work and hand-waving for an uncertain outcome when an ASM patch or a C2 hook would be almost trivial.
Any descriptions of how the FST tab is supposed to work would be good, too. Apparently that sometimes doesn't work? Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: IRS on August 23, 2010, 02:32:06 PM in my experience. one i dont really have a clue what good the FST tab is.. all it does is write a 06(+1)=07 string type.. and replaces the data from the file being swapped to the file being swapped over (ie source file over the destination file) i thought it was supposed to change the ASM reading those areas?
also for the pointer search.. i hate the GUI pointer search.. its not very clear as to which pointer it is supposed to be.. my preferred route of looking up a pointer when i was still working with them.. locate the address that is being "pointed" to. jot that down in a note pad. find another address that follows the same patterns. jot it down. open calculator find the difference between them.. then search all of mem1 with the search parameters "different by" and fill in the difference between the addresses you calculated. then you should have somewhere around 100 addresses. look for an address whose value is withing a 4 digit offset (below) the actual addresses you had located. if it is not the pointer.. try again. anytime i worked with the pointer search it took an insane amount of time to dump the file and was honestly just painful trying to "guess" which area was correct.. not to mention for the only "my own" pointer code i made.. when searching in the pointer tab i failed to ever locate the address.. i made a code out of all of the addresses indicated in both the "good" and normal areas. then i gave my above method a shot.. found it very quickly.. so in my own experience and work.. a pointer tab is rather useless... Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on August 25, 2010, 08:31:56 AM About the FST tab, I never used the one in wiird, so im not sure what its intended use is, but i know it had something to do with the files contained in the game disc and replacing one with another. i can provide information that may be useful if you ever do figure out what the fst tab is supposed to do.
when the game is booted, the apploader is run which reads the main.dol into memory and the fst among other things. the fst is read into the upper bit of mem1. since the fst's size is directly determined by the number of files in the game, and the length of their names, it is not a constant size. so, because of this the memory address of the beginning of the fst is always different. to make finding the table easy, the apploader writes the address of the beginning of it to 0x80000038. so, you read 0x80000038 and it will tell you another address and you go to that address and there is the fst. each file/folder in the game has an entry that is 0xc bytes and after all the entries, there is a string table that contains all the names of the files ( null terminated ). here is the struct of the 0xc bytes for each entry. Code: typedef struct so, by finding the fst and reading it, you can build a tree that shows the files and folders that make up the game. to swap files, you can read the offset and size of file2. then put overwrite the entry for file1 using these new offset and size. now when the game tries to read file1, it will actually read file2. heres what it looks like in SSBB-U the address of the fst is 0x817DA5A0. the next address holds the size of the fst including the name table. (http://img137.imageshack.us/img137/3898/fstmem.png) if you go to that address, you get this (http://img825.imageshack.us/img825/8984/fstmem2.png) the first 0xc bytes is the root entry. it is type 1 ( folder ), name offset & parent offset doesnt matter for the root entry, and its size is 0x1595. this means that there is 5525 files & folders in this game. and if you read 0x1595 * 0xc into the fst, you will be at the name table. (http://img178.imageshack.us/img178/4503/fstmem3.png) the second entry in the fst was type 0 ( file ), name offset is 0x0, file offset = 0x39c00000 and size 0x01000000. if you jump back to the name table and add the name offset, then you will be at the name of this file. so, this means that if the game ever wants to read "/border.dat" it will tell the IOS to give it the file at 0x39c00000 << 2 inside the game partition of the disc. moving on to the 3rd entry in the fst, it is a file with nameoffset 0xB, offset 0x00140000, size 0x0BEBC200. 0xB past the start of the name table is "dummy.dat". so, by switching the 32bit values of 0x817da5b0 and 0x817da5bc you have switched the offset inside the disc that the game will request if it wants these 2 files. if you switch the 32bit values at 0x817da5b4 and 0x817da5c0 then you have switched the filesize the game will use for these files. the 2 files i used here are never actually read by this game, but i chose them for simplicity. you can use this same principal to switch music files for example and every level in mario can have the same music. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 25, 2010, 12:25:27 PM Damn skippy. Is this written down anywhere? If not, it should be.
Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: giantpune on August 25, 2010, 01:09:53 PM theres already plenty of code written to deal with the fst format. nintendo has been recycling this struct for years. it is the same layout using in GC games. i think it is used in the U8 archive format http://www.wiibrew.org/wiki/U8_archive (http://www.wiibrew.org/wiki/U8_archive). the only thing specific here is its location in RAM. the earliest documentation i saw of it is in yagcd http://hitmen.c02.at/files/yagcd/yagcd/chap13.html#sec13.4 (http://hitmen.c02.at/files/yagcd/yagcd/chap13.html#sec13.4). though i havent seen anyhting written down about it as it pertains to RAM hacking and switching files.
homebrew implementations include many of gamecube tools, trucha signer, wiiscrubber, wit/wwt, SNEEK, my fst creator, the fst devotab library from FTPii, and probably many more. you can look at them for guidance turning the fst into a filetree. the only code ive ever seen for it is c/c++ but im sure you can work up a c# version quickly. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Bully@Wiiplaza on August 27, 2010, 08:19:03 PM I need to say something:
The v.95 update from geckodotnet fixed all codes applying bugs, meaning, it doesn´t freeze anymore! Awesome, geckodotnet ftw :eek: And requests: - The abillity to search for more than 8 characters at once in the memory viewer or everywhere where you can search for values, (like wiiRD could in the Memory Viewer. -> Up to 3 adresses in a row!) - A pointer search in geckodotnet or an extern application, because wiiRD often fails with the results and you can´t do a pointer search without it. (very important and requested often) Some people like doing a pointer search more than using ASM. - The ability to automatically set the breakpoint again after it hit like with "autoupdate" in the Memory viewer - When you select any adress and press gct code, it should always take the actual value from the adress and not 00000000. Especially when using "multiselected adresses" (CTRL + Mouse Click) in the search tab. (Matthew_Wi also requested that a few pages before) - Is it possible to add a feature that you can write back the original instruction/value when the game froze or do anything except restarting and unfreeze the game? :eek: (not paused, crashed) Greetings... :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 27, 2010, 10:09:14 PM - It's not v .95. It's r95. There's a big difference. Official builds that are supposed to be more stable have version numbers like 0.62 and alpha builds that introduce new features have release numbers like r95. The alpha build of Gecko.NET is at r100 right now, and pretty soon the official build will be 0.63
- I'll see what I can do about searching for more characters. - Link mentioned long ago wanting to make an external pointer app. I'm not that interested in it, especially because I never managed to use the pointer search to find anything. - If you want to set a breakpoint again immediately after hitting one, use a breakpoint condition that can never be true. Like SRR0 == 00000000. I must ask...why would you want to do this? - This feature already exists, since r93 it began using the value in the New column as the second half of a GCT code created by using the Search Result Context Menu. - It is possible to unfreeze games, but it is a lot like Black Magic. It's not something that Gecko.NET could do for you. Even if Gecko.NET knew which instruction caused the problem, it doesn't necessarily know what value it needs. You need to reconstruct the data in the appropriate registers by hand. By the time a game freezes, you may be past the instruction that froze the game, so you may also need to change the SRR0 register so that you can re-execute the botched portion of code. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Bully@Wiiplaza on August 28, 2010, 12:29:33 AM - Link mentioned long ago wanting to make an external pointer app. I'm not that interested in it, especially because I never managed to use the pointer search to find anything. - I must say, I also never managed to get any code with pointer search, but SOMETIMES you can´t do the code how you want it with ASM. Or maybe you can do it, what do you think? For example in MKWii, if you make an ASM Item Hack, every COM Player has also the hacked item and not just you, because the Breakpoint is also used for the COM players! With pointer search you can just give yourself the inf. items for example, because the item adress keeps moving.(The actual popular code is written with Pointer!) If there would be a new app, the results won´t be such a mess all the time, that´s my hope for the project xD - If you want to set a breakpoint again immediately after hitting one, use a breakpoint condition that can never be true. Like SRR0 == 00000000. I must ask...why would you want to do this? - Why I want to automatically set the breakpoint again? Easy! Sometimes you want to crack the values for a code like item/cloths modifier. Then, when you change cloths or used item, the breakpoint shows you the new value and if it is set instantly again, you can keep on playing the game and change stuff and write down all the values, without clicking set breakpoint again ;D As you see, it can be useful. :p - It's not v .95. It's r95. There's a big difference. Official builds that are supposed to be more stable have version numbers like 0.62 and alpha builds that introduce new features have release numbers like r95. The alpha build of Gecko.NET is at r100 right now, and pretty soon the official build will be 0.63 OK I´ll remember that!- It is possible to unfreeze games, but it is a lot like Black Magic. It's not something that Gecko.NET could do for you. Even if Gecko.NET knew which instruction caused the problem, it doesn't necessarily know what value it needs. You need to reconstruct the data in the appropriate registers by hand. By the time a game freezes, you may be past the instruction that froze the game, so you may also need to change the SRR0 register so that you can re-execute the botched portion of code. What I already know is that I can forget about using this "black magic"^^It´s too hard for me now... I started with the ASM stuff 6 month ago and you are programming for 15years, hui. :o Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: dcx2 on August 28, 2010, 01:23:45 AM I also never managed to get any code with pointer search, but SOMETIMES you can´t do the code how you want it with ASM. Or maybe you can do it, what do you think? For example in MKWii, if you make an ASM Item Hack, every COM Player has also the hacked item and not just you, because the Breakpoint is also used for the COM players! With pointer search you can just give yourself the inf. items for example, because the item adress keeps moving.(The actual popular code is written with Pointer!) There is nothing that can't be done with ASM. It sounds like the "ASM Item Hack" just needed a "player activator" to selectively enable. One of the registers probably has a clue; player or COM. Compare against that register to do different things. You could also look for a different hook that only runs when handling the player. Quote Easy! Sometimes you want to crack the values for a code like item/cloths modifier. Then, when you change cloths or used item, the breakpoint shows you the new value and if it is set instantly again, you can keep on playing the game and change stuff and write down all the values, without clicking set breakpoint again ;D Click the "Log Steps" checkbox on the breakpoint tab. It writes it down for you. Also, when you find the address of interest, go to Memory Viewer, use Poke with 1, but change "Write" to "Add". Quote What I already know is that I can forget about using this "black magic"^^ It´s too hard for me now... I started with the ASM stuff 6 month ago and you are programming for 15years, hui. :o Eh...more like 12. But programming is only half of the story, the software. There's a lot of hardware too. The software is the actors, and the hardware is the stage. Without knowledge of both, you cannot understand the story. Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Bully@Wiiplaza on August 28, 2010, 10:20:16 AM Click the "Log Steps" checkbox on the breakpoint tab. It writes it down for you. Nice method, and it´s working as wanted aswell... :PAlso, when you find the address of interest, go to Memory Viewer, use Poke with 1, but change "Write" to "Add". There is nothing that can't be done with ASM. It sounds like the "ASM Item Hack" just needed a "player activator" to selectively enable. One of the registers probably has a clue; player or COM. Compare against that register to do different things. This would be awesome, if it works. I´ll ask for it later I guess, if I don´t find it out for my own (what I believe more)You could also look for a different hook that only runs when handling the player. But every instruction I ever found was executed for every com player as well... ??? We´ll see... :) Title: Re: WiiRd/Gecko dotNet Bugs and Requests Post by: Link on August 30, 2010, 10:37:16 AM Link mentioned ages ago that he wanted to make a separate pointer-search app. But since it looks like everyone really wants that feature, then I would need a good description of how it works. I never understood how the pointer tab worked...and it seemed like so much work and hand-waving for an uncertain outcome when an ASM patch or a C2 hook would be almost trivial. Any descriptions of how the FST tab is supposed to work would be good, too. Apparently that sometimes doesn't work? The pointer tab works extremely simple.. Basically it opens the two dumps provided as a FileStream and runs through them.. which is also the cause why it's so slow. It literally goes like: read 80000000 -> check if pointer (meaning if it is a possible address) on both dumps--> no.. go ahead 80000004 -> check if pointer on both dumps -> no .... 80434458 -> check if pointer on both dumps -> yes ---> now if you do not do a pointer in pointer seach (double pointer would be the easy word) it basically compares the addresses the pointer is pointing to.. if the offset to the target address is identical for both pointers and the offset is within the given limits (normally 0 to 8000) then it is accepted as a possible pointer. In case of a pointer in pointer search the search is actually extended at that place: Check if [80434458]+0 is a pointer on both dumps -> no, next Check if [80434458]+4 is a pointer on both dumps -> no... until: Check if [80434458]+8000 is a pointer on both dumps -> no, next If it finds pointer it handles it just like above. So the basic pointer search is pretty straight forward. I already did an attempt to write a pointer search application however so far it does not really work the way I want. I am trying to create a list of possible addresses - addresses which qualify as pointers as well as the address they point to. Additionally I want my application to be able to search the 80 and 90 area at the same time - there were cases already when people tried searching pointers and failed because an address in MEM1 pointed to the required address in MEM2 - as the current search cannot handle cross pointers that is certainly something I want to fix!+ Using the pointers in a sorted list in memory should technically allow for very quick pointer searches and even allowing 3rd or 4th recursion of pointers. Most important however for such a search would be a good seeking algorithm to seek within the lists and I really haven't yet managed to get that planned in algorithm form. The basic idea is there and should easily outbeat kenobi's mechanisms in case of speed by lengths - it will however be much more memory intense and heap intense - however: even if I stored 2 complete MEM1+MEM2 dumps in the PC memory it would require 176 MB - an amount of memory all PCs of today should manage to carry. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 30, 2010, 04:49:15 PM hope you can manage it, Link :D
Funny that you wrote the same post 2 times :P ------------- @dcx2: the version r103 has a bug. When I try to assemble something, the program crashes. It may need more exact coding with the assembly history :) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 03, 2010, 05:47:49 AM Bully:
In the future... 1) please make a new post instead of editing. I don't get notification emails for post edits. So I missed this until now. 2) when providing a bug report, if you get an exception window, please copy the stack trace into a spoiler in your post. 3) when providing a bug report, please give as many details as possible. It is impossible to give me too many details. More often, I do not get enough details. A very important detail would have been what instruction you were trying to assemble. It had a problem with instructions that were less than 8 characters, because the diassembly history automatically parses the stored address out. Fortunately, I stumbled onto this, but it would have been really helpful to know what instruction was causing you to crash. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 04, 2010, 03:22:43 PM It was stw and I replaced it with nop.
But unfortunatelly, geckodotnet crashed because of this action. Every previous version worked :( Maybe you messed it up because of the asembly history or anthing like that. Else bugs: - If I copy a code into the gct codes tab and move the code up or down before saving it, the numbers in the code are gone (I need to recopy it to there again!) - If the inserted code is invalid, geckodotnet deletes the whole code, but it shouldn´t do this. Then I could edit it, without writing it again! - Another issue is that the ascii unicode search never finds results when searching for a text like: Mario I am sure that it´s in the RAM, WiiRD does find it every time, but geckodotnet not! I selected ascii unicode Search Mode and inserted e.g. "Mario" and also used display Ascii Unicode Mode, from the Memory Viewer. If I did anything wrong, tell me please, how to search correctly. This feature is important for some funny stuff... :o The text is in unicode and I want to use the ascii search... if this helps you to describe how to do it well with geckodotnet ;) - Request: Right click an adress and press "go to gct codes" and geckodotnet saves the line into the clipboard and changes to gct codes tab, then you can paste it to the code you want... before it always made a New Code with only this line. GCT Wizard sometimes adds just 00000000 00000000 as your code (when you rightclick from the search tab or memory viewer, I don´t know atm, but one of them for sure), that´s why I am requesting this ;D - Request: Bigger numbers in the memory viewer would be cool ??? Thanks for appreciating it!! :smileyface: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 04, 2010, 07:54:33 PM You're a little late regarding assembler crash. It's already been fixed. Check the release thread.
I'll look into the other issues. Particularly the disappearing GCT codes...that's always my first priority to fix. I'll check the search thing. Note that ASCII and Unicode are two COMPLETELY different things. ASCII/ANSI is 8 bits per letter, and Unicode is 16 bits. For instance, Mario in ASCII/ANSI is 4D6172696F, but in Unicode it is 004D006100720069006F. I may add a configuration file that you can go to in order to change the font of the Memory Viewer, so you can make bigger text if you want etc. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 05, 2010, 12:46:54 AM You're a little late regarding assembler crash. It's already been fixed. Check the release thread. Yes I noticed that,too after I posted the post.Ok I look if it works like you said... another thing: when I delete the search value in the search tab, it is blank, obviously. When doing an unknown value serach, this tab goes grey (also normal) but if I hit the search button, it says: Search Value invalid I even don´t try to search for a known value, do you get it? It´s a pointless bug to fix, anyway, just to let you know :p With every else number in the box, it works. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 08, 2010, 07:43:16 PM Thx for fixing the "Bully bugs" dcx2 :D
you could include an auto update function for the geckodotnet test versions... but how to do this is by you :smileyface: Title: Re: Gecko dotNET Bugs and Requests Post by: spunit262 on September 09, 2010, 09:31:10 PM For some reason only the first 4 letters are showing in the memory viewer. Does any one know how to fix this?
(http://i204.photobucket.com/albums/bb125/spunit262/GeckodotNetmemviewer.png) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 09, 2010, 09:34:53 PM Weird...are you using Windows 7 or something? Did you change your system fonts?
The problem is that the DataGridView cell is not wide enough to show all 8 digits, and so it uses an ellipsis (the ...) to indicate there's more data than can be displayed. This is very weird behavior. I'll look into it when I get some time. There's probably a setting that allows the columns to be resized. BTW, thanks for the screenshot. Title: Re: Gecko dotNET Bugs and Requests Post by: Link on September 10, 2010, 03:53:57 AM Weird...are you using Windows 7 or something? Did you change your system fonts? The problem is that the DataGridView cell is not wide enough to show all 8 digits, and so it uses an ellipsis (the ...) to indicate there's more data than can be displayed. This is very weird behavior. I'll look into it when I get some time. There's probably a setting that allows the columns to be resized. BTW, thanks for the screenshot. Juding the Window border it looks like a skinned XP or so. I personally use Windows 7, I actually did all development of Gecko dotNET on Windows 7 - the main reason I decided to start the project basically WAS because WiiRd - while working fine in XP - had major stability troubles in Windows 7 for me. Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on September 10, 2010, 04:43:43 AM That is the Royale theme for XP if I'm not mistaken.
Title: Re: Gecko dotNET Bugs and Requests Post by: Dude on September 10, 2010, 08:53:15 AM This is the Royale theme, I use that myself on my XP Machines lol
I think dcx2 is right - it could be new fonts. When you install the Royale XP theme it also installs a few additional fonts. I can't remember if the cells are resizable...but increasing the cell width should fix that. Just click the line between the top most cells and drag to a new size. @dcx2 I think you can prevent any further problems like this by making your gridview use a specific font, not the system selected font. This might mean having to include that font into your binary when compiled, just incase somebody doesn't have that font. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 11, 2010, 08:16:25 PM The only time that message will appear is if there are no addresses in the Multi Poke list. To view the Multi Poke list, double-click the Poke Address text box; (it uses the history function of the address text box)
You must ALSO make sure that the Poke address text box says "MP" or you won't get Multi Poke. Finally, selecting search results and then using the Poke box isn't going to work. You have to select them, then right click and select Poke to add them to the list. If you select new results and select Poke again, it will clear the previous list and add only the new results to the Multi Poke list. EDIT: you can also manually add entries to the Multi Poke list by using regular Address History functions. Finally, don't forget that you can copy/paste entries to/from the Poke address text box history. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 11, 2010, 10:31:19 PM It's actually the same amount of work as it was before (select search results, right click, poke; everything is automatically filled in for you).
But before, you couldn't change the multi-poke select list. You couldn't even *look* at it to see what was being poked, let alone making arbitrary entries or copying/pasting lists of addresses Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on September 12, 2010, 12:34:39 AM The pointer tab works extremely simple.. Basically it opens the two dumps provided as a FileStream and runs through them.. which is also the cause why it's so slow. It literally goes like: read 80000000 -> check if pointer (meaning if it is a possible address) on both dumps--> no.. go ahead 80000004 -> check if pointer on both dumps -> no .... 80434458 -> check if pointer on both dumps -> yes ---> now if you do not do a pointer in pointer seach (double pointer would be the easy word) it basically compares the addresses the pointer is pointing to.. if the offset to the target address is identical for both pointers and the offset is within the given limits (normally 0 to 8000) then it is accepted as a possible pointer. A regular pointer search is nearly instantaneous for me so I don't get why everyone says it takes forever. I even change the max offsets to 00FFFFFF (I don't get why they're defaulted to the less inclusive 00008000) Quote Additionally I want my application to be able to search the 80 and 90 area at the same time - there were cases already when people tried searching pointers and failed because an address in MEM1 pointed to the required address in MEM2 - as the current search cannot handle cross pointers that is certainly something I want to fix!+ I remember one time that I couldn't find a MEM2 pointer within the safe memory range so I tried using MEM1 dumps with the MEM2 addresses and it worked Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 14, 2010, 03:43:22 AM Can you please fix the "No multi poke data available"? It only works when I select a small ammount, but when I choose like 20 addresses it says that msg. Actually, the problem was that the multi-poke address history wouldn't accept any addresses if the current value wasn't a valid address. This was protection designed into the address text box class. So, if it was blank or MP, it would not load any addresses. A really stupid copy/paste bug when I was creating the class months ago, that apparently didn't display any erratic behavior until I tried to add the Serial Poke which would use the address history. *dies* But it's fixed now. *resurrected!* Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 16, 2010, 09:03:10 PM And again, requests, I still have some thoughts for improvements... :D
- No "Should a game be automatically loaded" message when starting gecko os, because it won´t do it ANYWAY, if you press "yes!" Maybe trying to do that by using some of WiiRDs source code... ??? - No repeated message " Connection to the gecko has failed" if you just didn´t boot up a game in the same minute, while you are still connected - Disassembly search should search till it finds what you wanted to search and no "couldn´t be found, want to continue searching?" message. The abililty there to select to search above or after the adress is very nice/useful ;) - Often, if I press "next frame" it doesn´t go further, only if I press it multiple times, maybe you could do something there? WiiRD made bigger "leaps" which were more useful generally. ;D - Feature to download the codes from geckocodes.org for the given game ID to the gct codes tab, when wished (it´s cooler not to copy in all the codes :P) - Hex to Ascii converter and a calculator in the gui, ready to use! (Same as decimal to hex and so on!) You guys already made the notepat feature, which is a great idea! Why not more of this hacking related useful stuff? :smileyface: - A function to check automatically for new geckodotnet test or release versions at startup of the program... Greets Bully ;D Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 16, 2010, 09:32:48 PM - No "Should a game be automatically loaded" message when starting gecko os, because it won´t do it ANYWAY, if you press "yes!" I would love to make it automatically load. But, unfortunately, I do not have access to WiiRDGUI source code. I'll look into killing the dialog.Maybe trying to do that by using some of WiiRDs source code... ??? Quote - No repeated message " Connection to the gecko has failed" if you just didn´t boot up a game in the same minute, while you are still connected I don't understand this request. I'll search through the source for this message...remember, I picked Gecko.NET up after Link had done all the heavy lifting, so there are many pieces of Gecko.NET that I am unfamiliar with because I've never touched them.Quote - Disassembly search should search till it finds what you wanted to search and no "couldn´t be found, want to continue searching?" message. The abililty there to select to search above or after the adress is very nice/useful ;) If disasm search were to continue indefinitely, Gecko.NET could potentially end up dumping all of MEM1. This could take a long time. That's why I put the built-in range limit; most of the time if you're searching for something, it's going to be within 1000 instructions (I think that's the window). If you want to continue searching, you could just hold down the keyboard key that corresponds to "OK" or "Yes".Also, regarding "search above or after"...the disasm search already does this, using the up and down radio buttons. But I can't tell from your comment if you were asking for that feature or complementing it. Quote - Often, if I press "next frame" it doesn´t go further, only if I press it multiple times, maybe you could do something there? Do you have BPNext checked on the About tab? BPNext makes the "Next Frame" button set an Execute Breakpoint on the code handler. So if the Gecko OS hook you're using is executed more than once per frame, BPNext will hit multiple times per frame.WiiRD made bigger "leaps" which were more useful generally. ;D I have seen other instances where I do in fact *know* that the game moved forward one frame, but the screen didn't change. The only way to really know the passage of time is to find a timer that is incremented once every frame. In the event that you find such a timer, you can change the BPNext address to set an Execute Breakpoint on your once-per-frame instruction. Finally, if BPNext is not checked, then Gecko.NET will use the same unpause/wait/pause method that I believe WiiRDGUI uses. However, I made the wait period as small as possible, because I hated it when WiiRDGUI would skip two frames while I was looking for a timer using different-by-1 searches. The unpause/wait/pause method is unreliable, in my opinion, which is why I created the BPNext method instead. If you want "bigger leaps", you should try using the Slow checkbox/spinner on the About tab. You can pause the game; then set the Slow spinner to maybe 2 frames per second (FPS); then check the Slow checkbox, and the game moves forward at about 2 FPS. Uncheck the Slow checkbox and the game goes back to being paused. You can slow the game down to 0.1 FPS (one frame every 10 seconds!), up to about 12 FPS. Quote - Feature to download the codes from geckocodes.org for the given game ID to the gct codes tab, when wished (it´s cooler not to copy in all the codes :P) I was considering this. Haven't gotten around to it yet, though. EDIT: you could try opening the wgc file in the codes directory and copying/pasting the codes directly into that file, saving it, and then hitting "Load Code List" on the GCT tab.Quote - Hex to Ascii converter and a calculator in the gui, ready to use! (Same as decimal to hex and so on!) This is actually a great suggestion. BTW, the Notepad was Link's creation. Personally, I would rather have a context menu full of tools that can be called with customizable command lines. I use OpenOffice's word application for my notes, because I can paste screenshots into the document.You guys already made the notepat feature, which is a great idea! Why not more of this hacking related useful stuff? :smileyface: Quote - A function to check automatically for new geckodotnet test or release versions at startup of the program... I doubt that I'll do this. I would need a server for Gecko.NET to phone home to when it started up. You should just click "Notify" on the release thread so that you get emails when I make new releases.Title: Re: Gecko dotNET Bugs and Requests Post by: Romaap on September 16, 2010, 10:00:43 PM If you want the auto update function, you could just use my server.
The only code you need is one that downloads a txt file wich holds the latest version number and checks if it is the same as the installed version. If it is not the same, downloads the latest version. Maybe a fancy hash check to confirm a proper download. At least, thats what I would do. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 16, 2010, 10:16:35 PM Yeah, but then that's just one more thing I have to do when I go to release. Here's what I go through for each and every test build.
1.) Test alpha builds on my local machine 2.) Create a list of all the changes made since the last SVN commit 3.) Commit the new changes to SVN 4.) Build the new binary 5.) Rename the binary to match SVN log 6.) Zip it up 7.) Upload the zip to mediafire 8.) Create an edited change log that is more user-friendly (i.e. leave out all the developer-centric comments) 9.) Post the new build to the release thread with the user-friendly change log I imagine I would have to FTP into your server and edit the latest version file. But I'm not eager to add any more steps to this process. Releasing an official build is even more troublesome. I have to FTP into the server where the official build is stored. But the real pain in the ass is updating the source zip, because I have to double check that I didn't add any new source files, and I have to make sure I don't include stuff that isn't source. Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on September 17, 2010, 02:13:42 AM - No "Should a game be automatically loaded" message when starting gecko os, because it won´t do it ANYWAY, if you press "yes!" I would love to make it automatically load. But, unfortunately, I do not have access to WiiRDGUI source code. I'll look into killing the dialog.Maybe trying to do that by using some of WiiRDs source code... ??? MOD EDIT: removed code tag because it screws up spoiler tag case 0x42: // Debugger on, pause start off config_bytes[7] = 0x01; config_bytes[5] = 0x00; usb_recvbuffer_safe(gecko_channel,&oldconfigbytes,2); // Get config config_bytes[0] = oldconfigbytes[0]; switch (oldconfigbytes[1]) { case 0x00: config_bytes[1] = 0x00; break; case 0x01: config_bytes[1] = 0x01; break; case 0x02: config_bytes[1] = 0x00; break; case 0x03: config_bytes[1] = 0x01; break; case 0x04: config_bytes[1] = 0x03; break; case 0x05: config_bytes[1] = 0x03; break; case 0x06: config_bytes[1] = 0x02; break; case 0x07: config_bytes[1] = 0x02; break; } menu_number = 8; apploader_thread(); gecko_command = 0; break; case 0x43: // Debugger on, pause start on config_bytes[7] = 0x01; config_bytes[5] = 0x01; usb_recvbuffer_safe(gecko_channel,&oldconfigbytes,2); // Get config config_bytes[0] = oldconfigbytes[0]; switch (oldconfigbytes[1]) { case 0x00: config_bytes[1] = 0x00; break; case 0x01: config_bytes[1] = 0x01; break; case 0x02: config_bytes[1] = 0x00; break; case 0x03: config_bytes[1] = 0x01; break; case 0x04: config_bytes[1] = 0x03; break; case 0x05: config_bytes[1] = 0x03; break; case 0x06: config_bytes[1] = 0x02; break; case 0x07: config_bytes[1] = 0x02; break; } menu_number = 8; apploader_thread(); gecko_command = 0; break; the short version here is that if you send a 0x42 or 0x43 it will read 2 more bytes from the gecko which determine a couple settings, and then boot the game in the DVD drive. 0x42 = paused start OFF, 0x43 = paused start ON. the next 2 bytes, i believe, are the language and video mode bytes. here is a bit from the rest of the source... MOD EDIT: removed code tag because it screws up spoiler tag switch(langselect) { case 0: config_bytes[0] = 0xCD; break; case 1: config_bytes[0] = 0x00; break; case 2: config_bytes[0] = 0x01; break; case 3: config_bytes[0] = 0x02; break; case 4: config_bytes[0] = 0x03; break; case 5: config_bytes[0] = 0x04; break; case 6: config_bytes[0] = 0x05; break; case 7: config_bytes[0] = 0x06; break; case 8: config_bytes[0] = 0x07; break; case 9: config_bytes[0] = 0x08; break; case 10: config_bytes[0] = 0x09; break; } // Video Modes if(pal60select == 0 && ntscselect == 0 && pal50select == 0){ // config[0] 0x00 (apply no patches) config_bytes[1] = 0x00; } if(pal60select == 1){ // 0x01 (Force PAL60) config_bytes[1] = 0x01; } if(pal50select == 1){ // 0x02 (Force PAL50) config_bytes[1] = 0x02; } if(ntscselect == 1){ // 0x02 (Force NTSC) config_bytes[1] = 0x03; } char languages[11][22] = {{"Default"}, {"Japanese"}, {"English"}, {"German"}, {"French"}, {"Spanish"}, {"Italian"}, {"Dutch"}, {"S. Chinese"}, {"T. Chinese"}, {"Korean"}}; So, if i had to take a stab at it, i would send 0x42, 0xcd, 0x00 ( start the game, no paused start, default language, default video mode ) and i also have a request, it has to do with the mono version, but i figure i can put it here. i would like to request that you use the method to talk to the gecko used in wiifuse & wiiload. it has functions to open/read/write/flush that dont require the ftdi package on linux. which means that the program does not need to be root, and it does not hikack the usb gecko from all other programs. this file ( gecko.c ) can be found in the hackmii installer download. i would prefer to submit a patch myself, but my c# sucks. you can convert it from c to c# much better than i could. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 17, 2010, 11:08:51 PM Quote I don't understand this request. I'll search through the source for this message...remember, I picked Gecko.NET up after Link had done all the heavy lifting, so there are many pieces of Gecko.NET that I am unfamiliar with because I've never touched them. well, it´s a kind of little "bug" that this messages pops up about every 30 seconds even if you are connected to the gecko, but haven´t booted a game yet. Then you hear this "bling" sound from windows. A little annoying! Quote If disasm search were to continue indefinitely, Gecko.NET could potentially end up dumping all of MEM1. This could take a long time. That's why I put the built-in range limit; most of the time if you're searching for something, it's going to be within 1000 instructions (I think that's the window). If you want to continue searching, you could just hold down the keyboard key that corresponds to "OK" or "Yes". Also, regarding "search above or after"...the disasm search already does this, using the up and down radio buttons. But I can't tell from your comment if you were asking for that feature or complementing it. I liked this up and down feature, no complaining here. Maybe you could bring in a feature which alows you to set the amount of instructions which should be dumped for the search ;) Quote ... okay I will try that, seems to do the job well :)If you want "bigger leaps", you should try using the Slow checkbox/spinner on the About tab. You can pause the game; then set the Slow spinner to maybe 2 frames per second (FPS); then check the Slow checkbox, and the game moves forward at about 2 FPS. Uncheck the Slow checkbox and the game goes back to being paused. You can slow the game down to 0.1 FPS (one frame every 10 seconds!), up to about 12 FPS. Quote I doubt that I'll do this. I would need a server for Gecko.NET to phone home to when it started up. You should just click "Notify" on the release thread so that you get emails when I make new releases. After I read all the points you would need to add to your "to do" list for considering the autoupdate feature, it´s not worth it!It´s fine how it is with the notification :D Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on September 20, 2010, 08:21:42 AM i just hit a crash in geckoDotNET.
1) start scoobydoo ( SJ2EWR ) 2) go to 0x800cf534 in the disassembler "addi r4, r4, 1" 3) change it to 2 instead of 1 and click assemble 4) the disassembler disappears and says "random error" 5) Code: ************** Exception Text ************** (http://img180.imageshack.us/img180/3889/gdnerror.png) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 20, 2010, 02:41:25 PM You're using an old version; I can tell because I don't see the disasm search. I think that is fixed in newer versions.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 24, 2010, 03:10:09 PM I think that is fixed in newer versions. yes it is... ;D@giantpune try to get built 108 from the release thread (last post) Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on September 27, 2010, 08:15:09 PM is it maybe possible to search for 3 32 bit values?
like 3F8000003F8000003F800000 via codesearch Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 27, 2010, 08:18:31 PM Go to Memory Viewer
Switch the Search mode to "Hex" Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on September 27, 2010, 08:21:26 PM Go to Memory Viewer Switch the Search mode to "Hex" yep that's right, via memory viewer but after second search you lose the first address. sometimes there are more than 300 addresses. is it possible to save it? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 27, 2010, 08:28:54 PM There's no real support for that type of thing. You should either copy and paste the addresses that you find into a notepad, or use the History for the Memory Viewer address text box.
I can look into making Memory Viewer search results automatically add themselves to the History. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on September 27, 2010, 08:35:24 PM okay thanks a lot ;D
btw what about a search mode for memory viewer without "next search" , like code search. search.... if found add to the history.... search.... if found add to the history.... and and and if finish, show all addresses Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 27, 2010, 09:27:51 PM I personnally don´t see the point of that... :-[
Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on September 29, 2010, 09:53:39 PM ok, i took your advice and grabbed the latest version of geckoDotNET and this one is throwing exceptions at me left and right. im not using any codes, just setting breakpoints and poking around in the memory viewer ( guitar hero 6 )
See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.IO.IOException: The process cannot access the file 'C:\Documents and Settings\Administrator\Desktop\vmware_wiishit\geckoDotNET\diss.bin' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode) at GeckoApp.Disassembly.Disassemble(UInt32 address, Int32 commands) at GeckoApp.Disassembly.DissToBox(UInt32 address) at GeckoApp.MainForm.DisPage_Enter(Object sender, EventArgs e) at System.Windows.Forms.Control.OnEnter(EventArgs e) at System.Windows.Forms.TabPage.OnEnter(EventArgs e) at System.Windows.Forms.ContainerControl.UpdateFocusedControl() ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll ---------------------------------------- Gecko dNet Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///C:/Documents%20and%20Settings/Administrator/Desktop/vmware_wiishit/geckoDotNET/Gecko%20dNet.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 29, 2010, 10:01:37 PM whooooa...that's weird.
The interesting bit is the part about The process cannot access the file 'C:\Documents and Settings\Administrator\Desktop\vmware_wiishit\geckoDotNET\diss.bin' because it is being used by another process. lol, "wiishit". Anyway, when you switched to the Disassembly tab, the game has to dump the memory where the instructions are. This dump is stored in the "diss.bin" file, and then passed to the external applications via command line. However, if some other process has a lock on diss.bin, then Gecko.NET won't be able to put the dump into it, and you will get this exception. There's a .NET class that can generate random temporary file names (in fact, there's even a proper folder for all this temporary stuff!)...I considered doing that to avoid this problem. However, we could in theory end up with dead garbage files lying around. Boo. Unfortunately, there's no way for Gecko.NET to force diss.bin to be released by whoever is holding onto it. Your best bet is to shut down Gecko.NET and then try to delete diss.bin. At the very least, I'll try to catch the exception and throw up a dialog instructing the user to shut down Gecko.NET and try to delete the file manually. Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on September 30, 2010, 06:23:17 AM in case you couldnt tell from the path name, im running this in a vmware pc. it is running stock winXP. i have no other programs running, and no services or garbage running that isnt already installed with XP. the only things that can be accessing the diss.bin are geckoDotNET and whatever processes it spawns to run the external exes it uses.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 30, 2010, 12:21:40 PM Try deleting diss.bin. Also try restarting your VM, that would bring down any process that's holding on to the file. You can also create a new folder and copy the exe's to that folder, without the diss.bin.
Title: Re: Gecko dotNET Bugs and Requests Post by: Dude on October 08, 2010, 11:25:40 AM I've got a small request regarding the search groups.
Would it be possible to integrate a textbox so that you could give a name to each group? This would help identify the kind of search for that specific group. Slotting a textbox directly under the group and having it load the given name as you change between the groups would be sufficient enough :P Hope it's not too much work, but I think this would be a great help. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on October 09, 2010, 04:47:20 PM This post made me think of an idea: http://wiird.l0nk.org/forum/index.php/topic,6856.msg59233.html#msg59233
If you had a 'block search' where the searcher pastes in multiple words, the background could search for that many lines and do a quick xor check (and then check if the order matches after xor is positive). ex: I search for 12345678 87654321 09ABCDEF 00000000 before the dump, it counts the words=4, calculates the searching_xor = 9CFAD8B6 then checks that searching_xor != 0 after the dump: xor the first 'words' words of the dump while(in range of dump){Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 09, 2010, 06:56:57 PM @James, Is there a purpose to using the hash for the search instead of just searching for those bytes? Because the Memory Viewer Search in Hex mode can search for an arbitrary number of bytes, up to like 200 or something. It used to be a string-only search, but I added Hex to make things like F6 codes easier.
EDIT: @Dude, I'm not really sure why naming the individual conditions would be helpful if you still had to scroll through the conditions. You could just look over and see "less than 7" or "different by 1 from previous 'new dump'". Perhaps I could make a dropdown that would list them all, but instead of having you name each one, it could go (assume this search will be the 4th dump) "[4] < 7" if you did a specific less than 7, or "[4] - [3] = 1" if you did a different by 1 search against the previous dump, etc. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on October 09, 2010, 06:59:44 PM OH
I didn't know that.. Nope, no purpose then. I apologize. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 09, 2010, 07:05:51 PM haha, yeah, that's why I want to work on documentation. So people know that it can do these things.
Problem is, I want the docs here, on the Google Code page, and on Gecko Codes. But each place has its own formatting rules. I don't want to maintain three sets of docs...talk about a nightmare. Perhaps I'll have to write some script that can take one generic format and spit out the other two... Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on October 09, 2010, 07:09:01 PM If you chose the one you like best, I'll just program GeckoCodes to read it from a file and add an option to your admin to edit (or upload) that file.
Title: Re: Gecko dotNET Bugs and Requests Post by: Dude on October 09, 2010, 09:47:43 PM I just thought that being able to provide a name to a search group would be helpful for saying what it is you're searching for in that group lol
I once tried doing about 5 individual searches at the same time and kinda got them mixed up XD So, for instance, looking for health and ammo and energy, etc. Just naming each one what it's for :p I normally use a notepad to name each group to remind me what I'm looking for, and thought that having a little textbox associated with each group would be helpful. No need to worry about it if others have no need for this function :) Seriously loving this app, dcx2!! Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on October 09, 2010, 10:33:26 PM @Dude: If I understand correctly, you basically want the saved searches to be "nameable"?
If they're not already nameable, I agree that would be helpful. I have a bunch of GCN searches saved and no idea what they are. =P @dcx2: I offered to do that mod to the database mostly because I have a non-hacking-related site idea that I've been sitting on for years and a "template" type of parsing would be useful for it. SO this would be a decent way for me to practice the coding. And I've been studying, practicing, and learning a LOT on regular expressions in the last 3 weeks, so my ability for parsing text have greatly increased! In sum, I'm just trying to make it clear that I wouldn't mind this small project, but- beyond that- I'd also enjoy the practice. ..Hopefully this makes it is easier for you to choose any direction you want for your doc! Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 09, 2010, 10:42:02 PM I think Dude is trying to do two searches at once (i.e. one dump, look for health and ammo). But that's not how the Search Group Conditions work.
Let's say you were looking for a value, and it was less than 7. But you know it's not zero. If you did a "less than 7" search, you would get a lot of 0's. So you'd have to do another search, "greater than 0" to get rid of those results. Rather than do two separate dumps, you can use the Search Group Conditions to make sure that any results found in the dump are BOTH greater than 0 AND less than 7. Or let's say you're looking for a timer that's counting down. You can search the dump for values that are BOTH different by 1 AND less than the previous value. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on October 09, 2010, 10:46:14 PM Ahh. I should probably stop posting in here. lol I just love all the work put into this and can't stay away. hahah
Much appreciated mate. ^^ Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 11, 2010, 10:30:33 AM i found a bug in r109. i was messing with Smash Bros. No codes loaded, i was only setting breakpoints and looking at the memory. Anyways, I managed to get the game t hang, so I had to turn it off and restart it. Once I got geckoOS up, I clicked the reconnect button on geckoDotNet. He asked if the game should be started, I said yes. The game loaded fine. But now geckoDotNet is stuck at the breakpoint tab. Everything on this tab is disabled ( greyed out ). I can click the other tabs, and they blick quickly like they normally do. But he doesnt change tabs. He is stuck on the breakpoint tab.
I closed geckoDotNet, and restarted it. It dumps the gameID and puts it at the titlebar. I can click the different tabs and change between them. But most of the controls are disabled still. Pretty much everything on the search, disassembler, memory viewer tabs is disabled. I closed him and restarted him again and he's back working like expected. im also getting a crash sometimes when dumping the memory with r109. But for some reason this crash doesnt look like it used to. There is no call stack or anything to post. Only the "geckodotnet has encountered an error. Do you want to send a report...". If i click the debug button in that prompt, it will tell me that there is an IO error in geckodotnet. but thats all the information it will give. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 11, 2010, 01:40:22 PM Bully mentioned this earlier, but the "should I start the game?" thing is actually broken. =(
Once the app starts to glitch out a bit, all of the boxes can become disabled. I'm not surprised it got stuck at the BP tab...it might have thought it was at a BP. You shouldn't have to close it...pushing Reconnect once or twice was usually enough to fix things like that. hmm...that is weird. Normally, the CLR will show you the unhandled exception call stack. If it doesn't, then that must mean something terrible happened in the CLR, like someone started writing garbage all over everything and it can't trust that the contents of the stack are not corrupted. That's why you get that more generic looking dialogue. That means something outside of the Managed world is probably being naughty. How many searches on average before you see this? Does it hit randomly? Does it only affect larger dumps like searches, but not smaller dumps like memview/bp/disasm? Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 11, 2010, 11:10:48 PM It happens pretty consistently if i search mem2 and the returned matches are only like 1 or 2 items.
EDIT: Ok, so I just started recording my desktop and messing with geckoDotNet trying to record the crash so you could reproduce it. I managed to record it, and this time i spent more time dicking around in the "this program has crashed..." dialog. It seems it does provide more information than I thought before. Basically it looks like the exact same issue that was making it crash before ( diss.bin is used by another process ). But this time it is the .log file that is used by another process. Anyways, heres the video so you can see if it happens for you. http://www.multiupload.com/KB8V3VQCUA Whenever this happens, it turns out that i cannot even save to the .log file using notepad. I opened up the taskmanager, and there are a couple different instances of geckodotnet.exe running. I think that one or more of these is a zombie of an instance of the program which i tried to close. And it still has a lock on the diss.bin & .log file, which is causing the crash. Is there a way for geckodotnet to detect if there is already an instance of itself running and force it to die? or something similar? EDIT AGAIN: ok, i got another bug. When i started geckoDotNet, he loaded values into the gui from last time i was using the program ( memory viewer tab ). you can see the values he loaded in the screenshot below, i have not typed anything into the gui. Then i click an empty spot in the scrollbar on the left to try to get him to scroll down 1 page. and he spits out a chain reaction of invalid address messages. (http://img98.imageshack.us/img98/4586/gdotnetanotherfuckup.png) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 12, 2010, 04:39:48 AM I'll look at your video soon. However, diss.bin isn't used anymore, ever. It's always a unique file name in the temporary folder now.
However, there is a log file for exceptions. I'll poke around at the logging after I watch your vid. Also, regarding the bug in your screenshot...I think the problem comes from the Memory Range dropdown showing 80, while the Memory Address is in the 90 range. I'll look into this, too. Thanks for catching bugs. I have a hypothesis...if this search crashing is recent, it might be the SetLatencyTimer...if you build from source, you can try going to USBGecko.cs, find the Connect() function, and there will be a line that sets the LatencyTimer = 2. Try something like 10, and see if you keep getting crashes. If you don't build from source, I can furnish a special test build just for you. :) Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 12, 2010, 07:55:39 AM I have formed a hypothesis also. I think the diss.bin and the .log crashes are both caused by the same thing. Whenever geckodotnet crashes, or possibly other times when it closes, the program doesnt actually get terminated. This is the only reason I can think of for there to be several different instances of geckodonten.exe running in the task manager. And since those paths are hard-coded, the new instance will try to access the exact same files that the zombie processes are still locked onto. I havent noticed the zombie instances when the program exits normally.
So, If you stop all other occurrences of the program crashing, and it always exits normally, it should probably fix this crash by itself :P . Also, IDK how the C# api is, but it seems that there would be a way to try to open the files and check their return value of the opening without the program crashing. I can see it crashing if you just try to open a file and start writing without checking that you can access that file. This wouldnt really allow the program to work like it should, but it would at least keep it from crashing. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 12, 2010, 01:05:22 PM http://code.google.com/p/geckowii/source/browse/trunk/GeckoDotNET/Gecko%20dNet/disassembly.cs (http://code.google.com/p/geckowii/source/browse/trunk/GeckoDotNET/Gecko%20dNet/disassembly.cs)
Starting at line 225 FileStream values; string filename = System.IO.Path.GetTempFileName(); try { values = new FileStream(filename, FileMode.Create); } catch (Exception e) { return new String[] { "Couldn't open diss.bin!" }; } try { gecko.Dump(address, eAddress, values); } catch (EUSBGeckoException e) { exceptionHandling.HandleException(e); return result.ToArray(); } finally { // This will always close the FileStream, even if the exception is handled values.Close(); } Note that every disassembly dump anymore is a unique file name in the temporary folder. If a file is write-protected, or otherwise illegal to touch, the FileStream constructor will throw an exception. It shouldn't bring down the app, it should just say "Couldn't open diss.bin!" If something happens while dumping memory from the USB Gecko, the finally block will ensure that the FileStream is always closed. The finally block always executes, whether or not an exception happens. I believe the only time a finally block *won't* fire is if you get an exception in a catch block, because the second exception wipes out the first. Now, there's still a chunk where vdappc plays with this file. I'm going to assume vdappc isn't the problem, although I've had assumptions like this nail me before. If a finally block fails to execute, that usually means the CLR was brought down (the .NET equivalent of the Apocalypse). This isn't normal...this isn't even abnormal. This is paranormal. This is where you jump up and down a few times to make sure gravity is still working... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 13, 2010, 01:07:32 AM I've been giving this some more thought. The next time you have zombie processes, try disconnecting the USB Gecko from the PC. I've seen that if USB devices don't play nice with memory they can lock up their associated application until the device is disconnected.
The log file error you're seeing is definitely the result of a zombie process holding on to it. The question is...what causes your zombie process? It just so happens that the log file is written to after a search, and that's why searching seemed to trigger the exception. But it's weird...you say it doesn't always trigger that exception? In the mean time, I'm going to make a sub-folder for logs, and I'm going to create uniquely-named date/timestamped files. This will solve that part of the problem. I'm also going to stop logging the search sort times...that might help too. As far as bringing down other instances...I'm not sure how OS-specific that may or may not be. And it would probably require UAC elevation/root to kill another process. I'm more interested in what causes the instance to hang around after it's been closed... BTW...what's that funny call-graph-looking app? EDIT: I have a new theory. The watch list is a little...dirty. It's being terminated with Thread.Abort(), which doesn't give a thread a chance to shut down gracefully...and that means we could get zombies. I'll see if I can end the thread more gracefully. Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 13, 2010, 07:00:35 AM are you talking about the disassembler or the hex editor? the disassembler is ida pro 5.2. the hex editor is hex workshop 6.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 13, 2010, 08:11:39 PM Request:
- Better adress recognition: If you enter for example C2xxxxxx into the memory viewer text box and click update (hit enter) , it should automatically recognise 80xxxxxx as the input (but without a notification message box pls) and no invalid adress like before. Same with all the 80,81 prefix codestypes (00,02,04,05...) The same for the 90,91,92,93 codestypes (10,12,14,4A,48...) but this time, it should recognise 90xxxxxx as the adress. :p Wouldn´t it be useful? ;) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 13, 2010, 08:22:44 PM I can see how automatically interpreting a ba code type might be useful, since the vast, vast majority of the time it is used as 0x80000000. But there definitely won't be any interpreting of the po.
I think you misunderstand the po codes. They are not MEM2 codetypes...the po can be used for anything, even 0x80000000. You can also use the ba to touch MEM2. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 13, 2010, 08:25:34 PM I can see how automatically interpreting a ba code type might be useful, since the vast, vast majority of the time it is used as 0x80000000. But there definitely won't be any interpreting of the po. wait, I meant this:I think you misunderstand the po codes. They are not MEM2 codetypes...the po can be used for anything, even 0x80000000. You can also use the ba to touch MEM2. 48000000 9y00000 14xxxxxxx zzzzzzzz E0000000 80008000 Yeah, I failed a bit lol. It´s the 48 codestype, only 10,12,14... :eek: what do you say now? ??? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 13, 2010, 08:38:02 PM Yes, I know how to use the po and write to MEM2. The problem is that you want to copy a code type - say, 14567890 - and paste it into an address text box. Then you want the app to figure out what you really wanted it to do.
Most people assume ba = 0x80000000. So it's not hard to take C2567890 and turn it into 80567890. Most people would not be surprised to see this happen, so this is okay. However, it is still possible for ba = 0x90000000 or 0x92000000. But this is not common. I still think you misunderstand po code types (10/12/14/16/D2/etc). They are not by default in MEM2. You must use po with pointers in MEM1. I think most people would be surprised if they put in 14567890 and got 90567890. Title: Re: Gecko dotNET Bugs and Requests Post by: live2play on October 18, 2010, 08:29:33 PM Source and Target seem to be reversed in the FST tab. If I select a file and then "Set as Source", then select another file and select "Set as Target", the source file is replaced with the target file.
Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on October 19, 2010, 02:56:06 AM Code: System.ArgumentOutOfRangeException: ControlCollection does not have that many controls Not sure what the cause of this was; GDN crashed when I was working on a different workspace. I think it has to do with the Notepad though. Might be Mono only, not sure. Title: Re: Gecko dotNET Bugs and Requests Post by: Link on October 19, 2010, 03:39:56 AM Source and Target seem to be reversed in the FST tab. If I select a file and then "Set as Source", then select another file and select "Set as Target", the source file is replaced with the target file. That's the way I developed it and that was my understanding. THe game tries to access the source file however its access gets redirected.. to the new target file. However, it could be swapped easily in worst case! Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 19, 2010, 03:47:42 AM maybe just rename the labels instead...
"file the game tries to read" & "file the game will read instead" i dont see there being any way somebody will get confused about what they do then :P Title: Re: Gecko dotNET Bugs and Requests Post by: live2play on October 19, 2010, 09:08:26 PM I guess that the FST Source/Target functionality makes sense after reading your response. Thanks!
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 21, 2010, 04:44:56 AM I have to report some geckodotnet issues again (the first two are happening to WiiRD,too!) :p
Game: The Conduit - If I applyed a C2 code, it works fine. But if I press apply a SECOND time, while the code is already written into the disassembly, it CRASHES! The code itself is right and working! It always crashes when doing this. Note that this only happens to "The Conduit" On some other games, it already got fixed. - Second issue is that if you do a memory search, the game takes extremely long time to "run" again. Example: I made a Mem90 Dump and searched for 00000006. When it reached it´s 100%, it displays the results, BUT the game was only running again after 10 more seconds of waiting!! Why does it take longer? (Only happenes to The Conduit) ??? - Third is a general issue on adding codes. If you rightclick something and press gct codes, it will ask you: "Enter the new codename!" There, you can press OK and CANCEL. But if you select CANCEL, it will STILL add the code to the list. Normally, cancel should NOT add the code, if you press it. (If you select OK, it just adds the code aswell, but it should only do it, WHEN pressing YES xD :P) Bully... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 21, 2010, 01:40:56 PM 1) Do you have "Pause While Sending" checked? It sounds like this would solve the problem you're having. If it doesn't, I still have another suggestion for you...but PWS always fixed that problem for me.
2) Weird...try pausing before searching and then unpausing after it's over and let me know how that worked out for you. 3) lol, you're right, the cancel button wasn't wired up properly. 4) Re: FST, I think I'm going to say Original and...Replacement? New? Destination? 5) I'll look into the Notepad DelCurSheet_Click. I've never touched the Notepad stuff before, really. 6) I think the zombie process is caused by the watch list, perhaps...so I'm going to try to rework how that runs. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 21, 2010, 02:53:38 PM 1) Do you have "Pause While Sending" checked? It sounds like this would solve the problem you're having. If it doesn't, I still have another suggestion for you...but PWS always fixed that problem for me. 2) Weird...try pausing before searching and then unpausing after it's over and let me know how that worked out for you. 1.) hmm... I didn´t use "Pause While Sending" Anyway, it froze even with it enabled in the past (I think) But I will try again, maybe it got fixed somehow :D 2.) If this works? Seems too easy and I could bet that I tried this too. I´ll also do it again. 3.) Would be good, if you can fix the cancel issue, it is a bit annoying if you don´t want to add the code, but it does though... ::) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 22, 2010, 01:02:19 PM k James.
now I´m coming back to The Conduit! - I ticked Pause while sending and sended a C2 code - Now, if I send again ANY code, if ASM or not, the game crashes (but only if I had applyed an ASM code before) WHY?? This is weird and annoying... I wish I could make every code without ASM to prevent crashes. How could I/someone fix this? :confused: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 22, 2010, 01:56:08 PM Hold on there...you can't just remove a C2 code on-the-fly! It will create a "dangling branch" that will cause your game to crash. You should be able to replace the C2 code with another C2 code. Or if you want to "unhack" the code, you must replace the branch with the original instruction.
Imagine using an 04 write to nop out a stw. Now imagine you want to turn this hack off. If you disable your code on-the-fly...your code will still be on. That's because nothing wrote the original stw back. That's your responsibility, and thus why I added History to the disassembler, so you could unhack ASM patches at will. If you C2'd the stw instead of nop'ing, the same rules apply; nothing writes the original stw over the b to the C2's ASM...but if you disable the C2 code, the b doesn't go to that ASM anymore...fail. I actually have a copy of the Conduit somewhere...got it from newegg for like $8 or something...I will take a look at this. I'm assuming yours is PAL though, huh? If you want to be extra-safe, uncheck Pause While Sending, and then manually pause the game before applying codes, and then check every address that you've ever C2 hooked in the disassembler tab. If you don't see the original instruction, write it in. After you've checked all addresses, you can hit Run Game again. Sorry if that's hard...no one ever said hacking was easy. Some tips that might help...you can edit your code in the disassembler tab. You can't add lines, but you can nop stuff and modify lines. Set a breakpoint on your C2 hook address, and then Step Into. Then switch to the Disassembler tab and you'll see your code. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 22, 2010, 02:07:38 PM you were right, writing back the original instruction and then apply back some codes doesn´t cause a crash.
Btw. I posted something to the game hacking help related to The Conduit xD If you can take a look at it for your own, it may be easier. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on November 02, 2010, 09:47:42 PM Since there's the search history now; a sweet feature would be to "highlight results with a pattern" or "eliminate results that aren't in a pattern".
example usage: I have 3 items and want to find which one I have out. So I'll switch, unknown search, switch, unknown search, repeat repeat. If I keep searching when I switch the items in the same order and don't skip any, then I press the pattern results button and it will show me which addresses have values that follow a repeating pattern in the search history! A number field that gives the length of the pattern (so I'd do 3 for the example above) would make the checking algorithm much faster. Also could be useful for finding coordinates (the Y coord would be easiest if you moved between different-height flat areas). Anything that could be repeated but is unknown would benefit from a post-search filter like this! =) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 03, 2010, 05:30:53 PM request:
multi select adresses in the memory viewer (strg + click) and able to create the whole code with gct wizard like it´s possible on the search tab Title: Re: Gecko dotNET Bugs and Requests Post by: Romaap on November 03, 2010, 06:06:59 PM request: strg = Ctrl on non-German keyboards. ;)multi select adresses in the memory viewer (strg + click) and able to create the whole code with gct wizard like it´s possible on the search tab Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 03, 2010, 06:39:37 PM request: strg = Ctrl on non-German keyboards. ;)multi select adresses in the memory viewer (strg + click) and able to create the whole code with gct wizard like it´s possible on the search tab Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on November 03, 2010, 10:17:07 PM I think the Memory Viewer was originally designed so that only one cell could ever be selected. There are a lot of assumptions based on being able to select only one cell at a time. So I doubt that I will do that...sorry.
Regarding the search result pattern, the problem really becomes "how do you specify a pattern?" I find it easier to just scroll through the Search History Old up/down, and delete the results that don't match the pattern I'm interested in. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 03, 2010, 10:51:48 PM I think the Memory Viewer was originally designed so that only one cell could ever be selected. There are a lot of assumptions based on being able to select only one cell at a time. So I doubt that I will do that...sorry. and how would you test about 6 adresses on a memory viewer site very fast, if they are doing something?poking them is a bit slow and it isn´t as good as freezing the value :confused: Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 06, 2010, 03:44:11 PM i got another idea:
can it be done? ...that geckodotnet searches about 5 seconds in the RAM, then it unpauses and let it run the game run for about 1 sec, then search again for 5 sec and so on till the search is complete? :P This is not useless for sure, I could need it sometimes :D Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on November 06, 2010, 07:48:02 PM I suspect that you only want that so you can hack online.. Searching like that would very much limit your range of hacks too...
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 06, 2010, 07:51:37 PM Searching like that would very much limit your range of hacks too... why would it limit anything? :confused:Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on November 07, 2010, 12:01:41 AM Hmm...I think James is right, don't they kick you off the game if you do a RAM search because your character goes idle for too long?
You have some serious balls trying to ask *me* to make it easier for you to hack online. >:( Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on November 07, 2010, 12:20:05 AM lol :eek:
are u maybe mad o,o Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 07, 2010, 08:34:20 AM it was a little joke, so just forget it xD
They boot you, if you pause your wii for about more than 10 seconds, because then you aren´t sending any ping anymore, which shows the server that you are "connected". Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on November 07, 2010, 08:46:25 AM @Bully Because during the time you start the dump and finish the dump, the memory is changing.
If you were careful about what was going on in the game during a staggered search, then I guess it wouldn't really limit that much.. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 07, 2010, 11:51:40 AM @Bully Because during the time you start the dump and finish the dump, the memory is changing. yep if i do little searches like from 80100000 to 80200000 it may not disconnect.If you were careful about what was going on in the game during a staggered search, then I guess it wouldn't really limit that much.. It´s just a matter of time the game is paused... with some clever steps you can still get your results... haven´t tried that yet. @dcx2: you do not idle out because of being inactive for about 30 secs, it´s because of the paused game. You could just stay there and do nothing, you won´t ever be kicked that fast. Title: Re: Gecko dotNET Bugs and Requests Post by: Panda On Smack on November 09, 2010, 05:28:45 PM Is it possible to have more info when doing a search from the memory tab
It does quick mini searches as it pages through the memory for whatever string you put in the box, Unicode, ASCII etc but it would be handy to show what address area its searching so you can get an idea of how long or how far its looked ta Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on November 09, 2010, 05:33:48 PM I thought it was refreshing the current 0x100 memory being shown and looking through that over and over. >.>
Title: Re: Gecko dotNET Bugs and Requests Post by: Skiller on November 10, 2010, 01:52:44 AM Somthing i dont know why its kinda not already a part or no one elts has asked . :P
Full Search 80+90 section in 1 go .. example put the value u want and it searchs both Areas .. not just 80 or 90 to many times im looking for a value and i have to Swap back and forth in them 2 .. it be much easyer to just do 1 search.. and have it scan both areas .. sure it takes a bit longer but it takes longer to do all them searchs in 1 section to come up empty :P this is a would be nice function.. u know the Cosmetics :) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 10, 2010, 05:12:35 AM exactly, that would be really helpful... you´ll always get your right adress or need to do something else to get it :P
Title: Re: Gecko dotNET Bugs and Requests Post by: Panda On Smack on November 10, 2010, 03:16:57 PM I thought it was refreshing the current 0x100 memory being shown and looking through that over and over. >.> Oh I see, WiiRd used to work its way through the whole memory until it reached the end. Is this possible? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on November 10, 2010, 03:41:42 PM It does that already. Starts with the cell after the selected cell*, and will continue searching until you cancel or it hits the end of the current memory range. * allows you to press the button after a successful search to find the next instance.
Panda, you should see the status bar indicating the rapid fire transfers as it starts crawling through memory. I can probably make it a little nicer, like changing the current MemView address textbox to show where the search is at the start of each dump. - Skiller, I like your idea about the 80/90 search, but it's actually a little difficult because dumps are stored as a start address and a series of offsets. So I can't make it one big chunk, I need two chunks, and that means changing some stuff to support dualdump. I'll see what I can do...it may or may not be that hard, or I may half-ass it somehow that's just good enough. Title: Re: Gecko dotNET Bugs and Requests Post by: Nuke on November 19, 2010, 06:44:57 AM This is not really a bug report, but I found that libftdi has slight issues when using synchronous transactions. When sending back an ACK, RETRY it seems to mess things up. Only one windows this sync method seems to work for me, on the mac I just get corrupt data when dumping memory.
Edit: I have made the change to usbgecko.cs but I just need to edit the handler to match things up, then I'll submit the change. Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on November 20, 2010, 03:45:19 AM Sometimes equals searches fail to weed out results that changed
I'm using r115 Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 20, 2010, 05:37:28 PM Sometimes equals searches fail to weed out results that changed what? the latest built is r114, I thought...I'm using r115 Title: Re: Gecko dotNET Bugs and Requests Post by: Skiller on November 25, 2010, 07:10:58 AM It does that already. Starts with the cell after the selected cell*, and will continue searching until you cancel or it hits the end of the current memory range. * allows you to press the button after a successful search to find the next instance. Panda, you should see the status bar indicating the rapid fire transfers as it starts crawling through memory. I can probably make it a little nicer, like changing the current MemView address textbox to show where the search is at the start of each dump. - Skiller, I like your idea about the 80/90 search, but it's actually a little difficult because dumps are stored as a start address and a series of offsets. So I can't make it one big chunk, I need two chunks, and that means changing some stuff to support dualdump. I'll see what I can do...it may or may not be that hard, or I may half-ass it somehow that's just good enough. seems to be a bug that i will be checking tomorrow on this game Donkey kong Quote Well I just tested that, and gecko.net doesn't check on 80000007 its checking on 80001807 which only shows 00 unlike the 80000007 which does show 01 iv not checked this with my version of the game but last time i checked it was reading the version numbers right but if its true that its using the 80001807 then ya there will be a bug on some games .. Title: Re: Gecko dotNET Bugs and Requests Post by: benny3t3 on November 27, 2010, 02:23:07 AM Hey Nuke, I think Gecko DotNet works on Leopard as well as Snow Leopard.
I have a 10.5 Macbook (Leopard for those who don't know) It works at least when it isn't connected, I haven't tried any actual functions with the USB Gecko though. The only thing is, it quits immediately if you try to access the memory viewer or dissasembler tab when not connected. Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on November 27, 2010, 02:36:43 AM The only thing is, it quits immediately if you try to access the memory viewer or dissasembler tab when not connected. That's a bug with using it on Mono in general. Title: Re: Gecko dotNET Bugs and Requests Post by: Panda On Smack on November 27, 2010, 12:47:55 PM Hey dee cee x to the 2
What do people think of putting notes on individual addresses and having a basic text pop-up when you roll-over them? Inspired by a CSS ToolTip really: http://downloads.sixrevisions.com/css-tooltips/index.html Mock-up of what I mean below. I'm thinking 2 or 3 words of text as a reminder just so you don't have to make a note elsewhere of what each address is in a certain area. You could store a list of note addresses and check them when you loop through the current memory section that's visible. It could be a 8, 16 or 32 bit 'note' which is selected at the time of creating/saving the note. Perhaps be able to turn them on or off globally in case you have lots and it gets annoying at that moment in time. (http://img440.imageshack.us/img440/3149/infoc0.png) Title: Re: Gecko dotNET Bugs and Requests Post by: Skiller on November 27, 2010, 09:59:57 PM Hey dee cee x to the 2 What do people think of putting notes on individual addresses and having a basic text pop-up when you roll-over them? Inspired by a CSS ToolTip really: http://downloads.sixrevisions.com/css-tooltips/index.html Mock-up of what I mean below. I'm thinking 2 or 3 words of text as a reminder just so you don't have to make a note elsewhere of what each address is in a certain area. You could store a list of note addresses and check them when you loop through the current memory section that's visible. It could be a 8, 16 or 32 bit 'note' which is selected at the time of creating/saving the note. Perhaps be able to turn them on or off globally in case you have lots and it gets annoying at that moment in time. (http://img440.imageshack.us/img440/3149/infoc0.png) THis kinda goes with the idea of what i was trying to do with WiiDis (Not an actual App) If we could make like Notes/Lable functions that be sweet .. i like the idea.. and maybe starting a Lable Database up were ppl can download the Lables for the game that users have Made .. .. Title: Re: Gecko dotNET Bugs and Requests Post by: Dude on November 28, 2010, 07:47:28 PM I like the sound of that idea.
There have been a few times where I've wanted to be able stick little notes on address cells as a quick reminder of where I am in memory... I second this idea ;) Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on December 03, 2010, 10:20:02 PM Hey dcx2, if you read this, could you help me fix a few bugs? It's probably all Mono related, using the most recent SVN. I've tried to fix a couple of them, but I'm having some trouble finding where the problems are located (can't seem to get MonoDevelop's debugger working right).
Search Tab: - Restart Search, Cancel Search both throw exceptions - Address field of the poke area clears all letters (A-F) after a poke - Load Search does nothing... no error messages at all either - "Equal", "Not Equal" menu is disabled after an unknown search. Workaround: switch to specific search and back to unknown search again. Disassembler Tab: - The disassembly always updates twice... I'm not sure if it is supposed to do this, but it takes me forever to use this tab effectively because it updates nearly every time I click on something (e.g. from text box to address field).[/quote] These are some that I can recall that were bigger annoyances for me. There are others... but they are either minor or not that big of a deal. I can post logs of some of the error messages later; I just don't have them saved right now. Thanks for helping out by making this work on Mono in the first place too; it saves me from having to try and run Windows on a VM or on a small partition. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on December 03, 2010, 10:27:04 PM Yeah, you'll have problems navigating the source if you can't start double-clicking on stuff in the Design View of Visual Studio...
What exceptions are the search buttons throwing? Address Text Boxes validate their input. There is an AddressTextBox class. Somewhere inside of it, it uses regex to replace all G-Z with empty strings. Sounds like the regex detection isn't working right? I think you should at least get a dialog from Load Search... The Search Condition menu should be disabled for unknown searches...it should be re-enabled, but I can't remember where it gets re-enabled. I think it's in the function that gets fired when you click the Search button. Disassembly updates...whenever you switch to that tab, it automatically loads the disassembly. Perhaps it thinks you're switching to the tab when you're already there? --- I haven't really touched my Wii in like a month (been too busy with L4D2). But I have a new laptop and I've been meaning to throw ubuntu on it. I may get back into Wii hacking here soon, and I'll see if I can dig around the sources and provide you with better answers. Title: Re: Gecko dotNET Bugs and Requests Post by: benny3t3 on December 03, 2010, 10:40:48 PM I feel selfish asking for this... because I am sure that this would be difficult, but being able to access preferences (such as the ones in the 'about' tab) and turning adress notes on/off/(maybe scroll over?) while in ANY tab, such as a toolbar or menu bar at the top?
Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on December 04, 2010, 01:14:31 AM The regex was working okay; the problem came in that the text box changed all of the letters to lowercase (which was not in the regex pattern). Simply adding a-f to the regex or converting that string to all uppercase fixed it.
And I finally got the MonoDevelop debugger working again (yay). Shouldn't be too hard to find some of the other stuff now, thanks. And the load file dialog does come up; it just doesn't do anything after you select a file. Title: Re: Gecko dotNET Bugs and Requests Post by: hawkeye2777 on December 17, 2010, 02:29:32 AM Forgot to post this, these are some of the exceptions I'm talking about (ignore the X11 one, that only happened once):
Code: hawkeye2777@Powerhawk:~$ gecko-dotnet It's hard for me to try and reproduce this bug with the Restart Search failing (along with others)... it happens pretty infrequently. My only guess is the amount of searches I do (>20), or it seems to happen after I set breakpoints. My computer's a bit too old to run the debugger for MonoDevelop (not enough RAM), so I'm having trouble finding possible problems. Any guidance to fixing the problems would be appreciated. Title: Re: Gecko dotNET Bugs and Requests Post by: Romaap on January 02, 2011, 05:03:52 PM I got a little request, when logging steps and Gecko.NET skips over a branch it would be cool if the changed registers would be saved too.
Now it is saved like this: Code: | 800F4E44: 481B36B1 bl 0x802a84f4 But it would be cool if Gecko.NET compares the registers from before the branch and after the branch and logs the changed registers. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on January 02, 2011, 05:16:42 PM That's a good idea, but it would be hard to fit the register list in without being really really wide...although that might not be such an issue.
Also, r14-r31 will never change after a bl returns; they are non-volatile, so they have to stay the same after the callee completes, hence pushing/popping them on the stack. r5-r12 are volatile and input-parameter-only registers, so any change to them is a result of some function inside the bl loading them with new values before calling some third function. The only registers that can change in a meaningful way for the caller after a bl are r3 and r4, which return values from bl. Title: Re: Gecko dotNET Bugs and Requests Post by: Patedj on January 23, 2011, 05:07:17 AM I don't know if you're aware of this but..
Spelling check. Immediately instead of immediantely. In the GCT Code Tab. 1 Search Save doesn't work properly ----> made it work buy saving it directly into the Gecko folder. (in theory you can create a SaveSearch Folder. Within the folder create a DumpHistory Folder and it should save perfectly. ( it's looking for the DumpHistory Folder.) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on January 23, 2011, 11:27:26 PM A few things, I would like to have (besides the stuff above <3)
1.) WiiRd had 10 save slots, I´m missing something like that on geckodotnet. You´ll press the save search button and a .rar file is created... but when you hit load search and select the file, it doesn´t load it. -> Make save searches without .rar, like WiiRd did and make it possible to load it please :-\ 2.) In the Memory Viewer of geckodotnet, you can do "write", "add", "sub", "diff", etc. If you are dividing through 0, the app crashes. I know that it´s mathematically not allowed to divide through 0. -> Change behaviour to do nothing, when dividing through 0 3.) Sometimes, I forget to write down my original ASM instruction and I just replaced it... I can´t get it back without restarting... -> Add something like a history, which writes down all Disassembly changes to look up previous instructions. The existing one didn´t work for me... 4.) Let´s say you hit a breakpoint. The instruction is lwz r4, 32 (r31) I want to calculate r31 + 0x32 to get my destination adress, that´s a bit annoying to do per hand for everytime it hits. -> Include a new tickable option "Redirect to location in Memory Viewer" Geckodotnet calculates it for you when the breakpoint hit, it will ask you to jump to specific memory location (only asks when option is enabled)! If you say yes, it goes to e.g. r31 + 0x32 in the Memory Viewer. 5.) Better features for F6 codestypes. -> Press CTRL +Click to select multiple adress in a row (disassembler/memory viewer) and rightclick it "Scan for F6 template". It will go to Adress 800000000 and scans for the adress row and tells you, if it is a working template (redirected to your position again) or not. If branches are selected, it gives a warning message ("Branches aren´t regionfree!"), but still allows you to go on. 6.) A tab, where you could see a ton of codes templates, which can be used. As an example, all RAM writes in ASM "lwz rD, d r(S) -> lis r12, XXXX ori r12, r12, YYYY stw rD, d (rS)" and the whole new codes document from geckocodes aswell. 7.) Set the amount of time, the game is paused when pressing pause (off or a specific amount) 8.) Possibility to lower game´s framerate when using "Auto Update"; Ability to change letter size; Go large should make all options to grow, not just the window without contents :( 9.) When you froze, geckodotnet becomes very slow. -> That´s not useful, can this behaviour be stoped to still run at same speed or an option to reboot wii, if clicked on? ----------------- That´s it for now, thanks for appreciating Title: Re: Gecko dotNET Bugs and Requests Post by: hinks on February 22, 2011, 01:34:52 PM Hi all,
I've compiled GDN trunk with mono under ubuntu 10.10 and it runs quite fine.. The only thing I really can't seem to get working are disassembly addresses, they are always like this - see image. Keep up the good work!!! Title: Re: Gecko dotNET Bugs and Requests Post by: hinks on February 22, 2011, 04:05:47 PM The only thing I really can't seem to get working are disassembly addresses, they are always like this - see image. SOLVED! I got vdappc src from http://wiird.l0nk.org/wp/download and tried it out of the box and it produced weird addresses. After running it under debugger I spotted that offset parameter was not parsed correctly. Simple parsing issue. I've put a repo online and committed vdappc code + my fix there if anyone is interested - http://code.google.com/p/hiinks/. ;D Title: Re: Gecko dotNET Bugs and Requests Post by: hinks on February 22, 2011, 06:35:00 PM On another note..
I want to give something back.. :cool: I've modified GDN disassembler view a bit: - flickering when loading new lines - displaying of 10 instructions prior the address wanted Patch is small, and attached. If anyone sees this fit it can be included in the official sources. ;D Possibly irritating is the fact that the list is refreshed twice. Still needs addressing. Now it does not flicker, though :) Cheers! EDIT: After trying out the patch-001 I've noticed that it broke Breakpoints view :(. Please do not use it.. Here is the modified patch (patch-002), that only tries to flickering when loading new lines. EDIT2: Another minor change - GDNdebug filename did not include 'month', but 'minute'.. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on February 23, 2011, 02:19:56 AM Thanks for this effort. When I get some time I'll look into it. However, I don't have any spare time right now, and probably won't for a week or two.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on March 04, 2011, 05:23:47 AM Can someone explain to me how the serial poke function works? I tried playing around with it and reading the documentation, but I don't really get it.
Also: Would it be possible to include a function that is like a multi-poke (unless it already exists and I'm just ignorant of it) where I can choose to plug in a number of addresses and Write values and then mass poke them [somewhat like a GCT code but without having a constant Write function]? Title: Re: Gecko dotNET Bugs and Requests Post by: Link on March 04, 2011, 06:10:17 AM Can someone explain to me how the serial poke function works? I tried playing around with it and reading the documentation, but I don't really get it. Also: Would it be possible to include a function that is like a multi-poke (unless it already exists and I'm just ignorant of it) where I can choose to plug in a number of addresses and Write values and then mass poke them [somewhat like a GCT code but without having a constant Write function]? Unless it was removed, you should be able to multi select many search results and right click "Poke" - it will show "MP" in the address value but internally it will poke all selected addresses. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on March 04, 2011, 06:18:35 AM Link is right, when you right-click multiple search results and click Poke, it adds all the addresses to a Multi Poke list, and the Poke Address text box will say "MP" to indicate that multiple addresses will be poked when you click Poke.
When I implemented Address Textbox History, I also made it so the Multi Poke list would be loaded in the History, allowing you to see what values are being poked, remove values you don't want poked, that sort of thing. if you have many addresses that aren't search results, put them one on each line and you can Paste the whole set of addresses into the History. To Serial Poke, load up a bunch of addresses into the Poke Address history, view them, and click on the very first address. Now, if you click Serial Poke, that single address will be poked, and the Poke Address textbox will update to show the next address in the history. You can click Serial Poke very fast, and when you see the effect you're looking for, you can stop and know that the address of interest is one of the recent ones in the list. --- Your question at the end...not quite sure I understand. Multi Poke will poke all addresses in the Poke Address history with the same value simultaneously. I think you want to poke multiple addresses, but each with a different value? Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on March 04, 2011, 09:44:58 AM That would be the idea yes, to poke multiple addresses, but just put the value in an ascending or something.
i.e. Item 1 x 99 Item 2 x 98 ... So on, so that there's like a countdown/count-up or something. But if the multipoke already exists then I don't think it should be a problem. I just want to poke the addresses where certain items are located so that I can max them out without having to go back and forth. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on March 05, 2011, 01:44:38 AM Sounds like you should try copying and pasting the list of addresses into the address textbox. Right click and you'll see the context menu. Then, change the address text box to MP and it will poke everything. This way you don't have to search for the addresses if you already know what they are.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on March 12, 2011, 06:54:24 AM Cool, I'll have to check that out.
Title: Re: Gecko dotNET release thread (version 0.64 now!) Post by: Sorzad12 on March 20, 2011, 11:04:09 PM I have a request.
When saving a search and saving out of the folder DumpHistory it gets an error Unhandled exception has occurred in your application if you click continue the application will ignore this error and attempt to continue if you click Quit the application will close immediatly Details See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\Documents and Settings\Sorzad12\Desktop\DumpHistory'. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption) at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption) at System.IO.Directory.GetFiles(String path) at Ionic.Zip.ZipFile.AddOrUpdateDirectoryImpl(String directoryName, String rootDirectoryPathInArchive, AddOrUpdateAction action, Boolean recurse, Int32 level) at Ionic.Zip.ZipFile.AddOrUpdateDirectoryImpl(String directoryName, String rootDirectoryPathInArchive, AddOrUpdateAction action) at GeckoApp.SearchHistoryManager.SaveHistory(String path, Int32 DumpNum, SearchSize size) at GeckoApp.MemSearch.SaveSearchHistory(String path) at GeckoApp.MainForm.buttonSaveSearch_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- Gecko dNet Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///D:/Documents%20and%20Settings/Sorzad12/Desktop/Gecko/Gecko%20dNet.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///D:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. So maybe you could make it so that it creates a new folder to save the search results to? Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on March 28, 2011, 04:30:14 AM ive got a bug ive been meaning to report for a while.
1) set some breakpoint 2) play the game and make it trigger that breakpoint. the game freezes and shows you the disassembly and registers and stuff. you can go to the "disassembler" tab and everything looks like you would expect it to. 3) switch to the "tools" tab. click "browse" and select a path to save a dump to. 4) click the huge "dump" button and wait while it dumps the memory 5) when its done dumping, go to the "disassembler" tab. instead of disassembly, it now says "vdappc.exe not found" 6) change to the breakpoint tab. in the last revision of GeckoDotNet i was using, it would show the same message "vdappc.exe not found". however, i just updated to the latest revision 64.3 and this version has different behavior. it shows still the registers and asm from a couple minutes ago when it hit the breakpoint. but when i click the "step into" button, the program crashes... See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.ArgumentOutOfRangeException: InvalidArgument=Value of '10' is not valid for 'SelectedIndex'. Parameter name: SelectedIndex at System.Windows.Forms.ListBox.set_SelectedIndex(Int32 value) at GeckoApp.Disassembly.CenteredDissToBox(UInt32 address) at GeckoApp.Breakpoints.GetRegisters(Stream regStream) at GeckoApp.Breakpoints.GetRegisters() at GeckoApp.MainForm.BPStepButton_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll ---------------------------------------- Gecko dNet Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///C:/Documents%20and%20Settings/Administrator/Desktop/vmware_wiishit/geckoDotNET/Gecko%20dNet_64.3.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. this is happening on many different games and different types of breakpoints i have tried. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on March 28, 2011, 04:42:39 AM Patedj said he was having a "vdappc not found" problem, too. I was unable to replicate it, however I didn't try doing a tools -> dump (I'm assuming your dump's save path is not the same folder as the exe). It makes me think that somehow a current working directory gets changed and it messes up the path to vdappc...
The reason it acts differently in 0.64.3 is because I made it so the first instruction is in the middle-ish of the ListBox (hence "CenteredDissToBox"), instead of the beginning. This bug should be straightforward to fix...without vdappc, there's no list of disassembly, so selecting the non-existent 10th entry will throw the exception. It didn't fail before, because it looked for the 0th entry, and the text "vdappc not found" was the 0th entry. Fix one thing, break another...heh. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 09:03:13 AM Bugs/Possible Improvements:
- If you rightclick an adress, accidentally select "add gct code" and press the cross or cancel button, it will still add the code to the list... - I don´t like the behaviour of "filling code with 0000000". If a code is incomplete, it should leave it like it is, because you don´t want your code being messed when 00000000 is inserted into the gap... - Select directory to store RAM Dumps Awesome work, thx a lot dcx2 Title: Re: Gecko dotNET release thread (version 0.64 now!) Post by: ropers on April 02, 2011, 10:15:43 AM could the FST be made so you can relace a file ?
Title: Re: Gecko dotNET release thread (version 0.64 now!) Post by: Bully@Wiiplaza on April 02, 2011, 10:29:40 AM could the FST be made so you can relace a file ? wrong thread, this belongs to the request thread.Btw. I never got why to use the FST function... ??? Title: Re: Gecko dotNET release thread (version 0.64 now!) Post by: Deathwolf on April 02, 2011, 10:33:09 AM could the FST be made so you can relace a file ? Doesn't work for all games. It allows you to replace stage/ level 01 with stage/ level 02 etc Title: Re: Gecko dotNET release thread (version 0.64 now!) Post by: hetoan2 on April 02, 2011, 10:57:04 AM that is swapping. replacing involves a new file.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 03:29:25 PM - I don´t like the behaviour of "filling code with 0000000". If a code is incomplete, it should leave it like it is, because you don´t want your code being messed when 00000000 is inserted into the gap... I don't know what you're talking about. Quote - Select directory to store RAM Dumps Do you mean the dump on the Tools tab? Click the "Browse" button. could the FST be made so you can relace a file ? To *replace* a file, you will need to modify the ISO directly. The FST tab is for swapping files by changing the pointers to the file names. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 03:40:46 PM - I don´t like the behaviour of "filling code with 0000000". If a code is incomplete, it should leave it like it is, because you don´t want your code being messed when 00000000 is inserted into the gap... I don't know what you're talking about.And you changed the moving behaviour to have the same code still selected, therefore, no loss of the code. Then, you added the function that incomplete codes are filled up with 00000000´s. Don´t you remember? If I write 28XXXXXX 12345678 E00000000 80008000 and click on another code, it will put 00000000 where the XXXXXX were or sometimes moves all codeslines. -> like this: 28000000 00000000 12345678 E0000000 80008000 00000000 I mean that you should be able to store unfinished codes... ;) AND The new geckodotnet has a horrible bug. If you switch to memory viewer, when a game is loading something, it crashes and isn´t recoverable. I noticed this with at least 2 games now!!! Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 05:00:25 PM I cannot replicate any problems with Memory Viewer. You will have to be more specific than "switch to memview when 'the game is loading something'". Define 'loading'?
Make sure that the Code Search tab is not dumping data when switching to memview. Make sure there are no breakpoints set when switching to memview. Make sure there is no active disasm search or call stack loading. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 05:07:15 PM I cannot replicate any problems with Memory Viewer. You will have to be more specific than "switch to memview when 'the game is loading something'". Define 'loading'? right, the game is always loading something XDMake sure that the Code Search tab is not dumping data when switching to memview. Make sure there are no breakpoints set when switching to memview. Make sure there is no active disasm search or call stack loading. But I mean the beginning of a match on goldeneye or a round on Wii Play or Monster Hunter Tri is loading BEFORE you can start playing and I switch to Mem Viewer, it crashes... happened on those games without codes on... You should try it aswell on Mario Galaxy, after you selected a star for the level. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 05:27:44 PM I cannot reproduce this failure.
I used Wii Play (RHAE01 Version 2). I was switching back and forth between the Search tab and the MemView tab constantly. I loaded the tank game. I quit the tank game. I loaded the shooting range game. I quit it. I put auto-update on, and loaded the tank game, played a few rounds, quit, loaded the shooting range, same deal. I used Super Mario Galaxy (RMGE01). Again, switching between Search and MemView non-stop. I loaded a save, loaded a star, quit that star, loaded a different star, quit that star too. I used Gecko OS. If this problem is related to using a USB loader, I can't help you. EDIT: I also made sure to use the exact same binary that is distributed, instead of building from source like I usually do EDIT2: I have also tried holding ctrl+tab down so that I constantly scroll through all tabs. I even did that with auto-update checked. Super Mario Galaxy was able to load and quit stars without any problems. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 05:36:52 PM that was a blast, maybe I´m using a bad hooktype.
I played with USB Loader though but it never made problems... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 05:40:52 PM I used the default hook for both Super Mario Galaxy and Wii Play. I'm pretty sure the default is VBI.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 05:47:09 PM Game: Wii Play
Hook: VBI Where: Bootstrap Screen Loader: USB Loader Changed from GCT Codes to Mem. Viewer Freeze and geckodotnet refuses to connect :rolleyes: EDIT: Tried with Gecko OS and VBI... worked and no freeze... :eek: I´m wondering how you managed to do this... as we know that you won´t support any USB Loaders with your work Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 05:55:33 PM "bootstrap"? Do you mean the screen at the very beginning of the game, that warns you about strapping the Wiimote to your wrist?
I see your edit. That is odd, because I don't do anything to prevent it from working with USB loaders. I wouldn't even know where to start. You write F6 codes, so your USB loader must be using a recent version of the code handler. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 05:58:31 PM "bootstrap"? Do you mean the screen at the very beginning of the game, that warns you about strapping the Wiimote to your wrist? Yes, there.I see your edit. That is odd, because I don't do anything to prevent it from working with USB loaders. I wouldn't even know where to start. Yeah that´s true, the code handler should be almost the newest.You write F6 codes, so your USB loader must be using a recent version of the code handler. Config. USB Loader ≧ Gecko OS because of it´s config. Options and it´s updates Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 06:08:48 PM There *are* legitimate uses for USB loaders. I won't deny that. But consider: if your Linux was crashing, would you go to Microsoft's tech support?
Another reason I only support Gecko OS is because it requires you to have the original disc. A legitimate user of a USB loader will still own the original disc. I honestly have no idea why it crashes for you. I might not help people solve their USB loader problems, but I won't create such problems for them either. I'm even tempted to try it myself, to see if I can replicate the problem. I also wonder if it's because your games are PAL. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 06:17:32 PM Another reason I only support Gecko OS is because it requires you to have the original disc. A legitimate user of a USB loader will still own the original disc. It won´t hurt me much, but I don´t like to switch disks all the time.I also don´t think that it´s because of PAL games... it worked before. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 06:42:11 PM So I went ahead and got myself that USB loader you were talking about. I repeated my test with Wii Play and Super Mario Galaxy. No crashes.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 06:55:04 PM So I went ahead and got myself that USB loader you were talking about. I repeated my test with Wii Play and Super Mario Galaxy. No crashes. I feel dumb now, why does it happen to me?What about a little video ::) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 07:00:33 PM You can try to debug the crash.
First, before causing the crash, make sure that you have hit at least one breakpoint. A good one to try is an EXBP on 800018A8, which is the first instruction of the code handler. Once you have set at least one breakpoint, you can hit run again. I don't know why, but this step is required for debugging crashes. Once you cause a crash, immediately switch to the BP tab. Press the Step Into button (and ONLY that button, nothing else). You should hopefully see the registers and assembly for the crash. Usually, it's a bad pointer...like a lwz r0,0(r3) and r3 = 00000000. Also, look in the Logs folder, for a file that was written to today. It's a text file; inside of it, you should see timestamped lines. Is there an entry for when your crash occurs? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 07:08:17 PM well the problem is that if I switch from gct codes to mem. viewer at loading screens,
the game makes the beep sound and geckodotnet disconnects from the game and won´t reconnect either (therefore, setting breakpoints won´t work) Then it throws "Received an invalid reply from USB Gecko. Do you want to reconnect" If I press no, it asks me a few more times till it stops and if it´s yes, it tells me "Connection to the gecko failed, retry?" Anyway, it´s not that important, I can also use an older geckodotnet for example. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 07:28:52 PM I think you misunderstood me. You do not set a breakpoint after the crash. If you go to the BP tab and press Step Into *immediately* after a crash, it will sometimes get the crash data. Also, you might want to try unplugging the USB Gecko from the PC and plugging it back in again, before reconnecting.
Or you could just...not switch to MemView when stuff is loading. --- I recommend against older versions. There is a bug in how the code handler dumps memory, sometimes inserting an extra byte, and this offset causes searches to fail. Because it's in the code handler, it affects all versions, Gecko.NET or WiiRDGUI. You can verify this for yourself; pause the game so the memory cannot change, and do repeated unknown-equal searches. You should always get 6,291,456 results for MEM1 or 13,631,488 for MEM2 (it doesn't dump all 64MB of MEM2 because I think the upper part is protected). But if you keep equals searching for long enough, you'll start getting fewer and fewer results, even though the game is paused. Older versions of Gecko.NET usually make a very large dump; an extra byte will cause all the search results to shift, so if it hits early it will corrupt a whole search. On average, if it strikes in the middle it ruins 12MB of data on a MEM1 dump. Worst case is all 24MB. WiiRDGUI dumps in 1MB chunks. If a byte gets corrupt, it only interferes with the last bit of that chunk. On average, if it strikes in the middle, it only ruins 512kB of memory. Worst case is 1 MB. If you open the WiiRD console, you can even see which chunk got corrupted. 0.64.4 begins verifying that the dump transferred without any extra bytes (it also dumps in 1MB chunks, too). If it finds a corrupted byte, it is fixed. I think on average, there's a corrupted byte for me every 150 MB or so; sometimes more, sometimes less. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 02, 2011, 08:19:18 PM that makes perfectly sence.
But I have the feeling that the search became slower due to the verification, is it true? If no adresses are lost and no searches will be deleted, that´s worth it. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 02, 2011, 08:24:05 PM If you look very carefully at the Search label during a dump, it says "Dumping...", but every now and then you'll see it blip for a split second to something else. It's so fast you can't even see it. It says "Verifying..."; I put the label there in case verification would cause a crash, you would know it crashed due to verification and not something else.
So yes, it is slower, but you wouldn't notice it without using a watch. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on April 03, 2011, 09:46:33 PM Is there anyway for the Gecko dotNET to save previous settings for the memory viewer?
Sometimes I have a tendency to forget to change the search there from ANSI to hex, then I get annoyed when I don't find anything and realize I did something stupid. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 03, 2011, 10:27:17 PM Yes, it can store settings to an XML config file. It should already store some, like the addresses for breakpoints and memview and disasm. Just let me know what others you want to be persistent. I'll make the memview Search Type persistent in the next release.
By the way, I don't know if you realized, but the top-left corner of memview will tell you what chunk of memory is being dumped. And 0.64.5+ can add words to the memview Search if you shift click on a cell. The shift click will also automatically change the search mode to hex for you. You can shift click multiple cells to form longer searches. Great for porting with dumps. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on April 04, 2011, 12:27:29 AM Well, I just downloaded the 0.64 one. I kind of forgot that you guys update it from time to time.
Looks good so far. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 04, 2011, 12:42:11 AM Make sure you have 0.64.6. There's a bug in the dumping that causes corrupted searches...it affects old version of Gecko.NET pretty severely, and it even affects WiiRDGUI to a degree. New versions of Gecko.NET scan the dump to make sure there wasn't an error.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 04, 2011, 12:50:00 AM There are three links in my sig. Make sure you're using the one that can be found via "latest test build" link.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on April 04, 2011, 12:50:49 AM All right then.
Title: Re: Gecko dotNET Bugs and Requests Post by: strakn on April 05, 2011, 03:00:42 PM I have two different problems with 0.64.6
One problem happens on my vista machine but not on my win7 machine The other happens on my win7 machine but not on my vista machine. On Vista, If I try to do a search, it stops at 4%, the game freezes/breaks, it just says verifying, and then connection to usb gecko is lost and it keeps asking me to try to recconnect. This problem does not happen on my win7 machine, searching works great now using win7. This is the error log that gecko.net spits out when this happens. 05/04/2011 11:35:03 AM: Opened log 11:35:03 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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 GeckoApp.MemSearch.VerifyDump(Dump checkDump, Int32 leftIndex, Int32 rightIndex) at GeckoApp.MemSearch.SafeDump(UInt32 startdump, UInt32 enddump, Dump memdump) at GeckoApp.MemSearch.PerformBlockSearch(Dump blockDump, List`1 dumpranges) at GeckoApp.MemSearch.SearchRefactored(UInt32 sAddress, UInt32 eAddress, List`1 comparisons, SearchSize searchSize) at GeckoApp.MainForm.Search_Click(Object sender, EventArgs e) Inner Exception: 11:35:28 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDICommandSendError 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MemoryViewer.RedirectableDump(UInt32 startAddress, UInt32 endAddress, Stream dumpStream) Inner Exception: 11:35:32 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:35:33 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:35:53 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDICommandSendError 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MemoryViewer.RedirectableDump(UInt32 startAddress, UInt32 endAddress, Stream dumpStream) Inner Exception: On win7 machine, If I am in memory viewer and have auto update checked, after a few seconds the game freezes/breaks, connection to usb gecko is lost and cannot reconnect. This problem does not happen on my vista machine. This is the error log that gecko.net gives for this problem. 05/04/2011 11:43:36 AM: Opened log 11:43:36 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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 GeckoApp.MemSearch.SafeDump(UInt32 startdump, UInt32 enddump, Dump memdump) Inner Exception: 11:44:00 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIReadDataError 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 GeckoApp.MemSearch.SafeDump(UInt32 startdump, UInt32 enddump, Dump memdump) Inner Exception: 11:44:57 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MemoryViewer.RedirectableDump(UInt32 startAddress, UInt32 endAddress, Stream dumpStream) Inner Exception: 11:45:00 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:01 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:01 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:04 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:05 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:05 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:06 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 11:45:16 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDICommandSendError 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MemoryViewer.RedirectableDump(UInt32 startAddress, UInt32 endAddress, Stream dumpStream) Inner Exception: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 05, 2011, 03:52:02 PM The game pauses at the beginning of a search in order to prevent memory from changing when it starts dumping the next block. If the search does not complete, it will not unpause. It is not really frozen.
The FTDIInvalidReply during FTDIUSBGecko.USBGecko.Dump() means that something with the connection to the USB Gecko broke in some probably unrecoverable way. The cascade of SendError's and InvalidReply's are failed attempts to re-establish connection to the USB Gecko. Does this happen reproducibly at the 4% marker? Sounds like the first block transferred okay (16 packets of ~63k each). It proceeded to verify the dump, which involves dumping a mere two bytes. And then started to fail. I would be surprised if this happens repeatably at the same point. How about a MEM2 search? --- For the second one, there is some confusion. You said it breaks during Memory Viewer. But there are no calls from Memory Viewer in the log. It says that SafeDump was called...but there are only two ways to call SafeDump; called by PerformBlockSearch when searching, as in the first error log, or dumping on the tools tab. But I don't see the event handler for the Tools' dump button. For that matter, I don't see any event handler. How was SafeDump called? It can't just call itself...maybe it was called from within an exception handler, which explains the missing stack trace? This time we got another invalid reply, but during the main dump instead of during verification. It's odd that it's the same type of error as before, just at a different time. Why are you getting all of these invalid replies? Have you tried unplugging the USB Gecko from the PC, waiting for the device removal to complete (Windows will ding), and then reconnecting it? Title: Re: Gecko dotNET Bugs and Requests Post by: strakn on April 05, 2011, 05:24:38 PM Does this happen reproducibly at the 4% marker? Sounds like the first block transferred okay (16 packets of ~63k each). It proceeded to verify the dump, which involves dumping a mere two bytes. And then started to fail. I would be surprised if this happens repeatably at the same point. How about a MEM2 search? For mem1 it happens everytime at 4%, once the connection is lost, i can not reconnect, unpluging and replugging the usb cable does not help,and am forced to reboot the wii. For mem2 it happens at 2%, i was able to reconnect and unpause the game, but the search fields were all greyed out so i had to close/reopen gecko.net, to try again. Same thing at 2% again For the second one, there is some confusion. You said it breaks during Memory Viewer. But there are no calls from Memory Viewer in the log. I am not sure, all I do is put it on memory viewer, and within 3 seconds of ticking auto-update, the game pauses and then disconnects.It also does this if auto-update is not ticked but I click the scroll bar area quickly to change pages. Why are you getting all of these invalid replies? Have you tried unplugging the USB Gecko from the PC, waiting for the device removal to complete (Windows will ding), and then reconnecting it? I do this anytime I get a disconnection, I almost always have to do this if the usb cable is plugged in before I start gecko.net, it tells me there is no connection try again, so I have to unplug it, plug it back in click yes then it works.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 05, 2011, 05:47:42 PM For mem1 it happens everytime at 4%, once the connection is lost, i can not reconnect, unpluging and replugging the usb cable does not help,and am forced to reboot the wii. Very odd. What if you change the dump start/end to 80000000/80001000? This is less than one packet.Quote For mem2 it happens at 2%, i was able to reconnect and unpause the game, but the search fields were all greyed out so i had to close/reopen gecko.net, to try again. Same thing at 2% again If you reconnect and the fields are greyed out, press reconnect again and they should become enabled.Also...can you try using the Dump on the Tools tab, and see if it can get a full dump? Also, do you have the same problem with the 0.64 build (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.zip)? That has no search verification, so that would rule one thing out. Quote I am not sure, all I do is put it on memory viewer, and within 3 seconds of ticking auto-update, the game pauses and then disconnects. It also does this if auto-update is not ticked but I click the scroll bar area quickly to change pages. If you scroll too quickly? What about if you click the Update button quickly and repeatedly?Quote I do this anytime I get a disconnection, I almost always have to do this if the usb cable is plugged in before I start gecko.net, it tells me there is no connection try again, so I have to unplug it, plug it back in click yes then it works. That's odd. I know it complains if there is no game running on the Wii, but once the game is running it starts right up without requiring any unplugging.This makes me believe that there's something odd with your drivers. Can you do this? device manager -> right click the USB Gecko (might be under Ports?) -> properties -> driver tab -> driver details button. What are the driver file names, providers, and versions? Title: Re: Gecko dotNET Bugs and Requests Post by: strakn on April 07, 2011, 08:19:27 PM Quote from: dcx2 Very odd. What if you change the dump start/end to 80000000/80001000? This is less than one packet. I did two test where I started with 80000000/80001000 then moved up to 80000000/80002000 and then 80000000/80003000 and so on.The first time searches all worked until I hit 80000000/80005000 The second time searches all worked unitl I hit 80000000/80009000 Quote from: dcx2 Also...can you try using the Dump on the Tools tab, and see if it can get a full dump? I tried to take a couple dumps of mem1, once it got to 100% but then gecko.net stop responding then connection to usb gecko was lost.second try It only made it to 20% before not responding then disconnecting. This is the log from one of those dump attempts 4:45:31 PM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 4:45:32 PM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: 4:45:33 PM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply 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(UInt32 startdump, UInt32 enddump, Stream saveStream) at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) Inner Exception: Quote from: dcx2 Also, do you have the same problem with the 0.64 build (http://geckowii.googlecode.com/files/Gecko%20dNet%200.64.zip)? That has no search verification, so that would rule one thing out. This does not happen with 0.64 through 0.64.3It does happen with 0.64.4 through 0.64.7 Quote from: dcx2 This makes me believe that there's something odd with your drivers. Can you do this? device manager -> right click the USB Gecko (might be under Ports?) -> properties -> driver tab -> driver details button. What are the driver file names, providers, and versions? I have already uninstalled and reinstalled the drivers many times, once using your method through the command line (It was me who started the thread "USB Gecko not finding Search Values) below is what is installed currently.ftdibus.sys, FTDI Ltd., 2.08.02 ftbusui.dll, FTDI Ltd., 1.2.0.1 ftd2xx.dll, FTDI Ltd., 3.02.00 FTLang.dll, FTDI Ltd., 1.5.0.1 **Good News All of the latest versions (0.64.4 and up are working perfectly on my windows xp machine. I dont know why my Vista and Win7 machines do not work I can only speculate maybe its drivers (Xp is using older preinstalled 2.04.xx drivers) or .NET Framework (xp is still at 2.0 while vista and 7 are at 4.0) Maybe a few others can post how the latest versions of gecko.net are working for them and what os they are using. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 08, 2011, 01:55:12 PM I develop Gecko.NET on Windows XP SP3. I have the same driver files as you, but my versions are different: ftdibus.sys (the actual kernel-mode driver) is 2.06.02. ftd2xx.dll (user-mode interface driver) is 3.01.19. FTLang.dll (probably some internationalization library..?) is 1,4,0,1. Yes, those are commas.
The timing of the bug is odd. Major USB Gecko changes were made in .3, and yet there was no problem for you. However, .4 only modified the searching, not the USB Gecko interface. I have a theory. I'll get you a custom build to see if it resolves this problem. Thanks for the extra effort you put into finding which version introduced the problem. I did make a somewhat hacky move with search verification. Because of the extra accidental byte in the stream, there's actually one byte left over in the transfer buffer that hasn't been read. I didn't want this leftover byte to interfere with the next command, so I tried to consume it. However, there is a cost to consuming a byte. If there is no byte to consume, you must wait until the transfer times out. This meant that each time you finished dumping a block, you would sit uselessly for 500 ms before asking for the next block. To mitigate this cost, I tried to do a "fast read" which temporarily reduced the timeout to 5 ms, read, and then restored the normal timeout. This appeared to work without any problems on my machine, so I left it in. I figured, 24 blocks * 5ms = 120 ms, no one should notice the slow down, it keeps the transfer bug from screwing other things up, and it didn't cause any problems...so it was a fair trade. Title: Re: Gecko dotNET Bugs and Requests Post by: strakn on April 08, 2011, 03:05:26 PM A quick test of the r123 and r124 you linked me to show no difference.
On Vista, searching, full mem dumping and memory viewer (w/auto update, fast scrolling or fast clicking of update) all cause the game to freeze, connection to be lost, and unable to reconnect until wii has been reset. On Win7 searching and dumping work (I did notice once a disconnect on a search but it reconnected and continued), but the same problem using memory viewer as on Vista. Also as a note, Vista and Win7 are both using the exact same driver files and version numbers, I listed previously. I will track down an older version of the drivers and see how they work. EDIT: I upgraded the drivers to 2.08.12 on both the Vista and Win7. This fixed the bug in memory viewer. So now the Win7 machine is working perfectly. I installed a very old version 2.02.04 on Vista, and the bug with the memory viewer is also not present, however searching and full mem dump still not possible on any driver version for Vista machine. Put 2.08.02 back on Vista and checked memory viewer, and it crashed with auto update on (just confirming its 2.08.02 causing the issue with memory viewer) As a side note 2.08.02 was the version that the Win7 machine downloaded automatically from windows update, but the newer version is on the ftdi website, it just hasn't been WHQL Certified yet. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 08, 2011, 08:08:17 PM On Vista, searching, full mem dumping and memory viewer (w/auto update, fast scrolling or fast clicking of update) all cause the game to freeze, connection to be lost, and unable to reconnect until wii has been reset. On Win7 searching and dumping work (I did notice once a disconnect on a search but it reconnected and continued), but the same problem using memory viewer as on Vista. :eek: ??? This makes no sense. Let me make sure I got all this... -Everything works on XP. -Nothing works on Vista. -Everything but MemView works on 7. I keep forgetting to ask, what's the 64-bitness of your various systems? hmmm....I trimmed the timeout from 2000 to 500 to make some things snappier...I wonder if the shorter timeout confuses the driver somehow? EDIT: Just saw your edit. -Everything works on XP -With 2.08.12, everything works on 7 -With any driver, dumping never works on Vista (r123 and r124?) -With 2.08.02, MemView doesn't work on Vista or 7 Title: Re: Gecko dotNET Bugs and Requests Post by: strakn on April 08, 2011, 10:19:18 PM I keep forgetting to ask, what's the 64-bitness of your various systems? All 32 bit OSs The Vista machine has an Athlon 64 dual core cpu(s) -Everything works on XP -With 2.08.12, everything works on 7 -With any driver, dumping never works on Vista (r123 and r124?) -With 2.08.02, MemView doesn't work on Vista or 7 Yes XP drivers are stock - 2.04.xx r124 same result as r123 and 0.64.4+ Title: Re: Gecko dotNET Bugs and Requests Post by: hetoan2 on April 09, 2011, 09:10:31 PM I am also getting these issues on the latest version. not fun. Occasionally, the gecko will even control my mouse and other system inputs. After the game has crashed (whenever you even attempt to go into disassembly tab), and GeckoDotNet has been forcefully shut down (exiting the window will leave process still open), the gecko will generate huge outputs of data to geckoreader. They are nonsensical, just random bytes.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 09, 2011, 09:21:40 PM WTF?
Are you using Vista? Are you using the latest FTDI driver? Title: Re: Gecko dotNET Bugs and Requests Post by: hetoan2 on April 09, 2011, 09:56:07 PM Windows 7 64 bit :S
I'll look into those FTDI drivers. Title: Re: Gecko dotNET Bugs and Requests Post by: hetoan2 on April 09, 2011, 11:29:33 PM 2.08.12 made everything work, before this i was using 2.04.x, which microsoft says is the most up to date ._.
EDIT: nevermind, that just fixed somethings. Just got a random crash when trying to do autoupdate in memviewer :\ Title: Re: Gecko dotNET Bugs and Requests Post by: ropers on April 10, 2011, 01:32:29 AM 2.08.12 made everything work, before this i was using 2.04.x, which microsoft says is the most up to date ._. same here i got the newest driver 2.08.0 im on windows 7 32 bit it when i goto mem viewer it crash EDIT: nevermind, that just fixed somethings. Just got a random crash when trying to do autoupdate in memviewer :\ and i have to restart my computer to get it to work. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 10, 2011, 01:44:39 AM Make sure you're using 2.08.12, from the FTDI website. Windows Update will not give you the latest driver. Go here to get them. http://www.ftdichip.com/Drivers/CDM/CDM20812.zip (http://www.ftdichip.com/Drivers/CDM/CDM20812.zip)
Use this procedure to verify what version is installed. Note: in these screenshots, I have 2.06.02, but I'm using XP, which has not had any problems yet. (http://www4.mediafire.com/imgbnc.php/e2368ec16f9039fd691615ba38b1f9522b74ef6c4a03a4d3f77f0594f58d39dd6g.jpg) Title: Re: Gecko dotNET Bugs and Requests Post by: ropers on April 10, 2011, 09:53:22 AM ok i got the new divers now ill let you know if it helps
Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 10, 2011, 07:39:23 PM The new Gecko dNet works fine on Wii games but it freez Gamecube games during hooking the game after patching the hook address 8034b09c. Why is that? However, the Pointer Search tab is great too. Thanks a lot.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 12, 2011, 06:10:06 PM ropers - did the new drivers resolve your problem?
deathwolf - What Windows are you using? Are you playing GameCube games with Gecko OS Mod? I've never tried it, so I don't if it would work. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 12, 2011, 06:19:08 PM ropers - did the new drivers resolve your problem? deathwolf - What Windows are you using? Are you playing GameCube games with Gecko OS Mod? I've never tried it, so I don't if it would work. I'm still on Windows xp and yes, GameCube games with Gecko OS Mod. After Gecko dNet hooks the game, it freez but it works great on Wii games. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 12, 2011, 10:17:59 PM Breakpoint doesn't work anymore on the new Gecko dNet. After setting breakpoint, the game freez and gecko dNet lose connection (On Wii games). Tested 4-6 and still doesn't work....
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 12, 2011, 10:27:21 PM I have had no problems with breakpoints, and I know some others who haven't either. You will have to be more specific about what your problem is.
What type of BP are you setting? Is Exact checked? What games are you trying? (I know for a fact that Super Mario Galaxy should work, because I've been testing that particular game lately) When it freezes, do you see any registers or disassembly? Does it freeze if you set a breakpoint that will never be hit? For example, does it freeze on an Execute BP on address 80000000? Does it freeze if you hit the Pause button and then the Run button? Is this a disc-based game or a WiiWare/VC game? Are you using Gecko OS? (Bully said he had some issues with a USB Loader, but I was unable to replicate those issues) What version is your FTDI driver? See the screenshot a few posts back to see how to answer this. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 12, 2011, 10:33:52 PM Game : New Super Mario Bros
Region : PAL DISC Gecko 1.9.3.1 BP READ: On life address Gecko dNet freez after breaking (shows no registers etc) lost connection. WiiRd breaks on READ but it breaks on a wrong addresses!? WiiRd breaks on WRITE right! Gecko dNet doesn't break anything. IDK why but the new gecko dNet seems it doesn't work for me . Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 12, 2011, 10:39:41 PM WiiRd breaks on READ but it breaks on a wrong addresses!? non-exact Breakpoints are 8 bytes. It is a common mistake to hit the wrong BP. You should always check a read or write BP to make sure it hit the correct address. The latest Gecko.NET will ignore unaligned breakpoints, so you can't hit the wrong address. --- Did you try setting EXBP on 80000000? Did you try pressing pause and then run? Does Search, MemView, and Disassembly work correctly? Are you using an original USB Gecko, or a USB Gecko SE? What version is your FTDI driver? http://wiird.l0nk.org/forum/index.php/topic,4954.msg67958.html#msg67958 Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 12, 2011, 10:50:39 PM uff ok I've tried to connect to USB Gecko over XX times and I'm not able to connect anymore o_O
Yes I'm using the original White USB Gecko. FTDI is now 2.08.12. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 12, 2011, 10:53:57 PM If you can't connect to the USB Gecko even after rebooting the Wii, you might have to unplug it from the USB port on the computer. The next version of Gecko.NET should be able to reset the USB Gecko without manually unplugging it.
Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 12, 2011, 10:56:36 PM Hmm ok. WiiRd can connect to USB Gecko but Gecko dNet don't. Hmm ok I'm going to unplug it.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 13, 2011, 02:31:42 AM The new Gecko dNet works fine on Wii games but it freez Gamecube games during hooking the game after patching the hook address 8034b09c. Why is that? However, the Pointer Search tab is great too. Thanks a lot. I was reading the Gecko OS Mod thread. Someone else had trouble with hooking. Did you decrypt an AR code and forget to delete the verifier? Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on April 13, 2011, 12:51:59 PM No, nothing.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 15, 2011, 01:18:11 PM I noticed freezes with the "Ossleepthread" Hook on some games (Mario kart Wii, Pokemon Battle Revolution) while auto update in the memory viewer is checked. It runs fine for a few seconds but then locks up. This only happens on very less games like the two mentioned above. Ossleepthread does never freeze on e.g. Call of Duty games.
However, using another hook like the VBI Hook does fix the freezing problem on the games which freeze with Ossleepthread + Auto Update. Is there an explanation for the freeze? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 15, 2011, 01:23:51 PM Are you using 0.64.8? I just released it yesterday. It has some fixes.
However, there appears to be at least one nasty bug in the actual code handler. It occasionally causes a byte to get lost in transmission. If one of these bytes belongs to, say, an address that you want to dump, then you end up dumping illegal addresses and it freezes the Wii. If you go to the BP tab and hit "Step Into", you would probably see some lwzx involving an r12 that's an illegal address...at least that's what I would run into occasionally. I'm currently working on trying to decipher the code handler. I'm comparing the USB Gecko interface in the code handler to libogc's USB Gecko interface. Nuke also released some stand-alone C code that interfaces with the USB Gecko from the Wii-side. Hopefully, between the three I should be able to figure out what's causing the bug. The next step is then coming up with some sort of patch to apply that will fix the bug. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 15, 2011, 01:27:58 PM I didn´t use the newest built yet, but this error happens since LONG ago even with the newer geckodotnet builts (0.64.6) and the newest gecko OS (1.9.3.2.)
You seems to be right to me that the code handler may need a few fixes! (Would increasing allowed codeslines also work?) Title: Re: Gecko dotNET Bugs and Requests Post by: ropers on April 19, 2011, 08:16:43 PM ropers - did the new drivers resolve your problem? yes it even fix my problem with it connecting with neo gamma.deathwolf - What Windows are you using? Are you playing GameCube games with Gecko OS Mod? I've never tried it, so I don't if it would work. Thanks for all the work you put into this. Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on April 23, 2011, 05:15:14 PM So you changed the SetLatencyTimer to 1? Does that actually work as expected? The FTDI docs say that 2 is the minimum for the USB Gecko chipset. (The USB 2.0 Hi-Speed chipset supports 1 and 0 as well, but I wouldn't expect that to work on the USB Gecko chipset.) I'm very curious about this....
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 23, 2011, 05:24:57 PM Yeah, they *say* it only goes down to 2...
I have a timing function built into Gecko.NET's logger. I timed 100 "status" commands. This involves one byte going to the USB Gecko and one byte coming from it. I always got 100 * SetLatencyTimer's value. When I changed it to 1ms, I got 100 ms for 100 status commands. I also know that you can queue multiple dumps in a single transfer. So, a given memory transfer requires sending 9 bytes to the USB Gecko (cmd_readmem, start address, end address). It turns out that if you stream like this in one chunk, I think you actually need to send the command *twice*, so you actually send 10 bytes...I don't know why, but one of the bytes gets lost, I think even after applying the rx/tx patch. If you want to dump six areas of memory, you could send 60 bytes in one go. You should send a pause command first. When the code handler has "paused" the game, it will basically sit and poll the EXI bus, so it can run through all your dumps as fast as possible before sending a resume command. --- Another alternative to SetLatencyTimer is the Event Character, but I'm not sure how to use this yet. Currently, I fancy hacking some VC SNES games... See this guide for more info on. Note that the USB Gecko is FT245R, a FIFO and not a UART. http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on April 23, 2011, 07:13:46 PM Yeah, they *say* it only goes down to 2... Yep, I read that PDF while developing GeckoTunnel; GeckoTunnel uses a 2ms latency timer. That's quite interesting that 1ms works on a USB Gecko. So here's a question, what happens when you use 0? The FTDI docs for the hi-speed chip say that 0 should eliminate the delay completely... if 1 works for the USB Gecko, I'm quite curious whether 0 does anything. (I wouldn't expect it to work, but I wouldn't expect 1 to work either....)I have a timing function built into Gecko.NET's logger. I timed 100 "status" commands. This involves one byte going to the USB Gecko and one byte coming from it. I always got 100 * SetLatencyTimer's value. When I changed it to 1ms, I got 100 ms for 100 status commands. I also know that you can queue multiple dumps in a single transfer. So, a given memory transfer requires sending 9 bytes to the USB Gecko (cmd_readmem, start address, end address). It turns out that if you stream like this in one chunk, I think you actually need to send the command *twice*, so you actually send 10 bytes...I don't know why, but one of the bytes gets lost, I think even after applying the rx/tx patch. If you want to dump six areas of memory, you could send 60 bytes in one go. You should send a pause command first. When the code handler has "paused" the game, it will basically sit and poll the EXI bus, so it can run through all your dumps as fast as possible before sending a resume command. --- Another alternative to SetLatencyTimer is the Event Character, but I'm not sure how to use this yet. Currently, I fancy hacking some VC SNES games... See this guide for more info on. Note that the USB Gecko is FT245R, a FIFO and not a UART. http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf Title: Re: Gecko dotNET Bugs and Requests Post by: BLiTz* on April 27, 2011, 09:34:45 PM Could you add a random search method?
Let me explain: The random search method would search an area specified by the user. Then the user could do something. Say move a little. The user would start the search again. The program would then search again for the values changed. The ones that didn't change would be removed from the table. Simple enough right? Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on April 28, 2011, 01:12:37 AM Could you add a random search method? Forgive me if I misunderstand, but isn't there already a "not equal" search type present?Let me explain: The random search method would search an area specified by the user. Then the user could do something. Say move a little. The user would start the search again. The program would then search again for the values changed. The ones that didn't change would be removed from the table. Simple enough right? Title: Re: Gecko dotNET Bugs and Requests Post by: BLiTz* on April 28, 2011, 01:14:47 AM Could you add a random search method? Forgive me if I misunderstand, but isn't there already a "not equal" search type present?Let me explain: The random search method would search an area specified by the user. Then the user could do something. Say move a little. The user would start the search again. The program would then search again for the values changed. The ones that didn't change would be removed from the table. Simple enough right? Yes but this method would speed up the time it takes to find a "unkown" address, because it only returns what addresses changed. and then you can trim it up some. and you got ur address Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 28, 2011, 02:24:16 AM That's been there since before I took over development. Look a little more carefully through the Search Condition dropdowns and you'll see Unknown Value.
Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on April 28, 2011, 02:35:26 AM It's only unknown the first search- after that you compare to a previous result.
Title: Re: Gecko dotNET Bugs and Requests Post by: Dude on April 28, 2011, 07:21:43 AM That's like the "changed" comparson search type in CheatEngine.
It already exists in Gecko.NET. It's called "not equal". It compares all addresses with the last memory dump for anything that has "changed". Start an "unknown" search, then choose "not equal" from then on. this will compare the new dump with the old dump for anything that changes. ------ Talking about CheatEngine though, I've got a suggestion: Would it be possible to search for 8bit, 16bit and 32bit values in one search? Let me explain. normally, you'd have to choose either 8bit, 16bit or 32bit before searching. You'll then be stuck only finding values of that size. In CheatEngine, you are able to search for all value sizes in one. If 3F800000 then becomes 3F900000 then you could list in the results: "3F900000" -32bit "3F90" -16bit "F9" -8bit "90" -8bit You could put the size of each value in a new column at the end to show what it is, just for simplicity. This would, however, require more memory on your PC/laptop due to the increased number of results. Keeping the individual 8/16/32bit choices can be kept for searching for values that you know are within a set size, narrowing results. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on May 08, 2011, 06:56:11 PM The new Gecko dNet 0.65 screws my USB Gecko up as hell. After a few minutes it says "lost connection" and it freez. When I try to restart it, then I'm not able to connect anymore to my USB Gecko. Tried it over XX times. There's something wrong...
But the 0.64 works great. Memory viewer bug: I've no idea but sometimes my game freez when the "Update button" is activated. The values are changing sooo fast that I can't follow them anymore. Is it because I'm using USB 3.0? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 08, 2011, 07:08:31 PM Because of the under-the-hood C2 patches that are applied to the code handler, whenever Gecko.NET connects to the USB Gecko, it has to send codes.
I noticed today that if Gecko.NET attaches to the game while at the loading screens, it would cause a crash. I assume this is because of how BPNext + Sending Codes works. Wait until the game is at the first menu screen before you run Gecko.NET. --- Others reported MemView problems if they didn't have an updated version of the USB Gecko driver. No, the values are not changing fast because of USB 3.0. The USB Gecko is limited to Full Speed (aka USB 1.1 speed). Title: Re: Gecko dotNET Bugs and Requests Post by: BLiTz* on May 12, 2011, 01:16:27 AM Sometimes when the gecko freezes(the game is still running) i unplug the cord from my computer. and it comes up with a box about connection issues. so then i plug it back in
and click yes. the search, reset, buttons are still faded, so i have to reconnect again. could you fix this? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 12, 2011, 03:00:13 PM "when the gecko freezes"
Which Gecko? Gecko.NET, USB Gecko, Gecko OS? Were you doing something when this happened (Memory Viewer, Search, Breakpoint, Watch List, etc?) I've known about the "have to reconnect twice" bug. Just pressing the button twice is so much easier that I just never felt like trying to figure out what was going wrong. It doesn't cause an error or data loss, so it was no big deal to me. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on May 14, 2011, 11:10:38 PM I don't know if this is just my computer's issue or something with Gecko dotNet but I do notice when I open Task Manager, gecko dotNet's process is still running even though I've closed it, disconnected it from the USBGecko etc. Thoughts on this dcx?
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 14, 2011, 11:49:37 PM Sounds like the Watch List not closing properly. 0.65.1 will ask you to try closing again.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on May 15, 2011, 12:30:02 AM In regards to that, does the Watchlist just open in the background even if I don't use it?
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 15, 2011, 12:54:50 AM Sorta? The thread runs, but it doesn't do anything unless the watch list tab is active.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on May 15, 2011, 01:11:32 AM Weird, because I hardly ever use that function.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on May 20, 2011, 03:38:55 PM I noticed today that if Gecko.NET attaches to the game while at the loading screens, it would cause a crash. That´s what I wanted to tell you recently...!"Switching to the Mem Viewer during a loading screen crashes the game" <- like this Would it be possible to both, the crash and the C2 codes issue in one geckodotnet version? --- However, I would like to have an option to "add current value to the search box" when an adress in the mem viewer is left-clicked with held control button (in my opinion better than right click and choose the option "add to search box" from the list) (http://i42.tinypic.com/10ngner.jpg) Hope it´s possible to understand what I´m requesting. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 20, 2011, 03:53:36 PM It didn't crash for all my games. Wii Play worked, Tales of Symphonia did not.
--- Hold shift when left clicking a memory cell and it will automatically change MemView Search to Hex mode and add the cell you clicked on. This was added in 0.64.5 http://wiird.l0nk.org/forum/index.php/topic,4886.msg67656.html#msg67656 Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on May 21, 2011, 02:42:29 PM kk thanks!
Little bugs: - Ticking a memory range in the pointer search tab crashes the application, since it is intended to press the dump button instead (after the dump, it´s ticks the box by itself). However, using the pointer search button (when at least 2 dumps + adress were made) in the GUI doesn´t work, should I use Dr.Pepper´s app then? - If you start a search and notice that you want to cancel it, the app still searches through the results and gives the list, which takes about 5-10 secs. Instead, there should be possible to "instant cancel" - GCT Code Undo with invalid adresses crashes the game (already mentioned) Requests: - A new tab, where you can put e.g. button activator values, codes templates and stuff you want to take some looks at when hacking which can be saved there and always used, no matter which game you "debug" (other than the notepad that saves your notes game specific) - It would be great, if you can directly start a pointer in pointer search, that´s what you can neither do on geckodotnet nor on Dr.Pepper´s app (as far as I know) if normal Pointer results were found... (WiiRdGUI does the job then, but it´s unhandy and slow) Hope these things seem useful ;) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on May 21, 2011, 02:54:16 PM I don't get a crash when I tick a memory range. I get what is supposed to appear - an open file dialog that asks you what dump you want to load. Checking those checkboxes allows you to load arbitrary dumps that you have collected at any time.
You might want to try putting a valid pointer into the textbox before clicking the dump buttons. What do you mean, "pointer search button in the GUI doesn't work"? You'll have to get Dr. Pepper to update his app with some command-line switch to force pointer-in-pointer. I saw you posted in his thread; try PMing him. I will fix GCT Code Undo with invalid address in the next build. --- I might do the instant cancel thing, but I doubt it. The combined time it takes for everyone to wait for canceled searches is likely greater than how much time it would take for me to make it faster. As far as the notes thing...why not just use regular old Notepad? I have about 5-10 instances of Notepad open during any hacking. I copy and paste a LOT of stuff; disassembly, memview, notes, step logs, etc. I don't even use the built-in Notepad feature. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on May 21, 2011, 03:37:55 PM You'll have to get Dr. Pepper to update his app with some command-line switch to force pointer-in-pointer. I saw you posted in his thread; try PMing him. done!And thanks for the tips with notepad and stuff. You were right, I didn´t put a pointer in the box before trying to load a file. Maybe you could fix this, though... Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on May 26, 2011, 02:59:33 AM Okay... here's something odd that came up using the latest build of Gecko OS and Gecko dotNET
I put three addresses I was searching for on the watchlist and when I clicked on the watchlist to go mem-view for that address, it reset my game and gecko dotNET froze. For information's sake I was checking for an AP address in Xenoblade (JP) version. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on May 28, 2011, 06:48:57 AM Tools Tab:
From the 3 utility links, PyiiASMH gives a crash message. The other 2 link to the main WiiRd thread(s). Informationen über das Aufrufen von JIT-Debuggen anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung. ************** Ausnahmetext ************** System.ArgumentOutOfRangeException: Der Index lag außerhalb des Bereichs. Er muss nicht negativ und kleiner als die Auflistung sein. Parametername: index bei System.Collections.ArrayList.get_Item(Int32 index) bei System.Windows.Forms.LinkLabel.LinkCollection.get_Item(Int32 index) bei GeckoApp.MainForm.linkLabelPyiiASMH_LinkClicked(Object sender, LinkLabelLinkClickedEventArgs e) bei System.Windows.Forms.LinkLabel.OnMouseUp(MouseEventArgs e) bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) bei System.Windows.Forms.Control.WndProc(Message& m) bei System.Windows.Forms.Label.WndProc(Message& m) bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Geladene Assemblys ************** mscorlib Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4959 (win7RTMGDR.050727-4900). CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll. ---------------------------------------- Gecko dNet Assembly-Version: 1.0.0.0. Win32-Version: 1.0.0.0. CodeBase: file:///C:/Users/Admin/Documents/Wii%20Hacking%20Tools/gecko.net/Gecko%20dNet.exe. ---------------------------------------- System.Windows.Forms Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll. ---------------------------------------- System Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll. ---------------------------------------- System.Drawing Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll. ---------------------------------------- System.Windows.Forms.resources Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll. ---------------------------------------- System.Configuration Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll. ---------------------------------------- System.Xml Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll. ---------------------------------------- mscorlib.resources Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4959 (win7RTMGDR.050727-4900). CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll. ---------------------------------------- ************** JIT-Debuggen ************** Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der Konfigurationsdatei der Anwendung oder des Computers (machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden. Die Anwendung muss mit aktiviertem Debuggen kompiliert werden. Zum Beispiel: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten Ausnahmen an den JIT-Debugger gesendet, der auf dem Computer registriert ist, und nicht in diesem Dialogfeld behandelt. If you deny the USB Gecko Connection at fire up of the app (without one connected) gives this extention: Informationen über das Aufrufen von JIT-Debuggen anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung. ************** Ausnahmetext ************** System.DllNotFoundException: Die DLL "FTD2XX.DLL": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden. bei D2XXDirect.D2XXWrapper.FT_Close(UInt32 ftHandle) bei D2XXDirect.D2XXWrapper.Close() bei FTDIUSBGecko.USBGecko.Disconnect() bei GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e) bei System.Windows.Forms.Form.OnShown(EventArgs e) bei System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj) bei System.Threading.ExecutionContext.runTryCode(Object userData) bei System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) bei System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme) bei System.Windows.Forms.Control.InvokeMarshaledCallbacks() ************** Geladene Assemblys ************** mscorlib Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4959 (win7RTMGDR.050727-4900). CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll. ---------------------------------------- Gecko dNet Assembly-Version: 1.0.0.0. Win32-Version: 1.0.0.0. CodeBase: file:///C:/Users/Admin/Documents/Wii%20Hacking%20Tools/gecko.net/Gecko%20dNet.exe. ---------------------------------------- System.Windows.Forms Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll. ---------------------------------------- System Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll. ---------------------------------------- System.Drawing Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll. ---------------------------------------- System.Windows.Forms.resources Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll. ---------------------------------------- System.Configuration Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll. ---------------------------------------- System.Xml Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4927 (NetFXspW7.050727-4900). CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll. ---------------------------------------- mscorlib.resources Assembly-Version: 2.0.0.0. Win32-Version: 2.0.50727.4959 (win7RTMGDR.050727-4900). CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll. ---------------------------------------- ************** JIT-Debuggen ************** Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der Konfigurationsdatei der Anwendung oder des Computers (machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden. Die Anwendung muss mit aktiviertem Debuggen kompiliert werden. Zum Beispiel: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten Ausnahmen an den JIT-Debugger gesendet, der auf dem Computer registriert ist, und nicht in diesem Dialogfeld behandelt. If no USB is connected, the app sometimes freezes when switching tabs. "Geckodotnet doesn´t work anymore. Searching for problems" (directly translated sentence) And it closes itself. Note that I discovered these on a Win7 laptop. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 04, 2011, 04:56:00 PM Wouldn´t it be great to set a breakpoint read/write/execute on multiple adresses at the same time? (Similar to multi poke)
It should then display the adress that broke first... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 04, 2011, 05:03:52 PM Yes, it would be great, if it were possible. Unfortunately, the PowerPC architecture only really allows one data or execute BP at a time.
In theory, if you wanted to do multiple execute BP, you could set up a series of C2's that write to a reserved area of memory and set a Write breakpoint on that. It would in effect create multiple execute BP, because nothing else but your C2's will write to that address. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 04, 2011, 07:49:48 PM Nothing on any known bugs that has gecko force-reset/crash games?
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 04, 2011, 08:50:45 PM Were you doing anything in particular? I've had a few issues with sending codes to the game, probably because of the C2 patches. Though I don't mess with the Watch List and it might cause some problems too.
Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on June 04, 2011, 09:05:59 PM Hmm I'm just asking again for fixing this freez error. Everytime if the latest version of Gecko dNET have an error, I have to restart my PC to connect to the USB Gecko. This error comes when Gecko dNET dumps the game. For some reason WiiRd have the same bug but then I'm still able to connect once again. So really please fix this bug because I need Gecko dNET for porting the file patch code.
Thanks... Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 04, 2011, 10:22:17 PM Were you doing anything in particular? I've had a few issues with sending codes to the game, probably because of the C2 patches. Though I don't mess with the Watch List and it might cause some problems too. I was searching for the EXP or AP addresses, and I found them. So I stuck them into the Watchlist so I could remember what they were. So when I wanted to Right-click on it, Gecko went boom and the game/wii reset itself. This was before I had applied any GCT codes however. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 04, 2011, 11:29:39 PM When Gecko.NET experiences a problem it writes to a GDNDebug.log file in the Logs folder. It's timestamped to correspond to when the problem occurred. If you can post or PM me the contents of the log file corresponding to a problem that you had, it will help me out.
I can't believe that the Wii resets itself, though. I've never had that happen. It's really weird. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 05, 2011, 12:59:45 AM Interesting I'll have to check when I get home.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 09, 2011, 03:44:19 PM Aww... I was trying to debug one of my C2 codes, since it froze after the developers´ logo if the code was enabled right from the beginning.
-- So I set a conditional breakpoint after the bootstrap screen and geckodotnet skipped lots of instructions because the condition wasn´t true yet, but the instruction was executed there. Then, the game randomly froze quite fast and geckodotnet didn´t react anymore (I couldn´t cancel the breakpoint nor could I successfully press the "run" button) Damn it, this appears to only happen with the newer version(s) of geckodotnet (probably because of the C2 codes fix codeshandler?) and only when the game is *before* the main screen therefore still *booting up* Why I don´t use WiiRd then? It´s somehow blocked by my firewall/anti virus program and I don´t know how to reenable it -.- That bug makes it therefore almost impossible to debug this C2 code. :( If someone cares which code I was trying to debug... it´s the "offline only" inf. health code for Conduit2 that´s posted on the database. The freeze can be bypassed by using button activators but that´s not what I want though! Conduit2 and The Conduit are pretty much the biggest bitches with assembly of all games out there anyways... (you can never be sure that your assembly patch doesn´t randomly freeze at a certain point, instant freeze or your game gets glitchy) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 09, 2011, 04:27:38 PM 0.65.2 can disable the RX/TX patches on the About tab. I would restart the game after disabling the patches, though.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 09, 2011, 06:22:47 PM 0.65.2 can disable the RX/TX patches on the About tab. I would restart the game after disabling the patches, though. Haha, nevermind.Didn´t notice that it´s the feature I need to disable here. Disabling it in-game could have possible crashes etc.? If yes, I wouldn´t bother about it, though. (restarting doesn´t hurt since I crash often enough aswell xD) EDIT: I could possibly disable it before connection to a game to prevent the game from a restart? It would also be nice if the change is saved on geckodotnet each time it is booted up, does it do it yet? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 09, 2011, 06:28:59 PM The RX/TX patch suffer from the same problem as any C2 code. When you apply a hook, and then try to disable it, the original instruction is not restored.
The game won't crash immediately, but the next time you send codes, the code handler will probably fail when it tries to execute the missing patches. EDIT: Yes, the RX/TX enable is a persistent setting. So you won't need to disable it every time. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 09, 2011, 06:37:54 PM *got fixed* Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 23, 2011, 12:45:23 PM i´d like to have the ghost add bug fixed. If you press "add gct code" and cancel it afterwards, it STILL adds the code... ???
Also, a little codeslines counter would be cool on the gct tab to see the amount of codeslines that are enabled (like the one that WiiRdGUI has!) I discovered on geckodotnet 0.63.3 that some breakpoints don´t hit and just skip over (the counter tells me that it happened) even if no conditions were set by the user...! That makes it hard to create the specific code. Even though, it somtimes works afterwards, but not always. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 24, 2011, 12:36:43 AM i´d like to have the ghost add bug fixed. If you press "add gct code" and cancel it afterwards, it STILL adds the code... ??? Also, a little codeslines counter would be cool on the gct tab to see the amount of codeslines that are enabled (like the one that WiiRdGUI has!) I will look into these. Quote I discovered on geckodotnet 0.63.3 that some breakpoints don´t hit and just skip over (the counter tells me that it happened) even if no conditions were set by the user...! That makes it hard to create the specific code. Even though, it somtimes works afterwards, but not always. What you are seeing is called Skip Unaligned Data Breakpoints. It skips false breakpoints. You can disable this on the (EDIT --- The technical explanation is that a data breakpoint, such as read or write or read/write, actually has double-word (8-byte) alignment. Let us say that *something* is writing the value 00000000 to the address 80123444. Let us say you set a write breakpoint on 80123440. Your write breakpoint will generate a false hit when *something* writes to 80123444. This is because 80123444 is double-word aligned with 80123440, even though it is not word aligned. You can verify this for yourself. Look at DAR. You will see that DAR does not match your breakpoint sometimes. These are the false breakpoints; they are not word-aligned, but they are double-word aligned. In binary terms, a non-exact breakpoint asks the following question. (memory_access_address & 0xFFFFFFFE) == (breakpoint_address & 0xFFFFFFFE) That is, the addresses are masked with a series of 1's ending with three 0's. This enforces double-word alignment. Skip Unaligned Data Breakpoint does a second check to ensure that the following is true. (memory_access_address & 0xFFFFFFFC) == (breakpoint_address & 0xFFFFFFFC) That is, the addresses are masked with a series of 1's ending with two 0's. This will prevent the false breakpoint write to 80123444 from happening when we were actually interested in 80123440. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 24, 2011, 12:47:20 AM Learned something new again :smileyface:
I just need to get sure that my BP address is the EXACT same address than the one found in the Memory Viewer/Search. If it still does not trigger I can also disable this option, ok (I didn´t like the unexact BP´s though, but that´s not a problem). Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 24, 2011, 02:04:26 AM It's not quite that simple.
An exact BP must match the address exactly. Let's say you find a value in memory, like Mario's HP which is 3. It might look like 00000003. This is at address 80123444. Is this a word access on 80123444? a half-word access on 80123446? a byte access on 80123447? If you use exact, you must know exactly. an lhz on 80123446 will not hit an exact BP on 80123444. If you use non-exact, then any access to that word will hit. Trust me. Unless you fully understand the meaning of double-word breakpoint alignment, just leave the checkbox enabled. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 25, 2011, 08:14:56 PM great work with the update!
Sry to say that now, but I noticed that the "paste" option on the Breakpoint Condition Field gives a crash message. But if Ctrl + v is pressed pasting works fine. It says something like the command wasn´t assigned yet on the crash log. And there´s still a ghost add on the memory viewer ("add gct code"). Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 27, 2011, 08:39:15 AM Apply this code via send cheats to activate the extended codes feature how many codeslines become useable then?It was like 220 before, wasn´t it? One mostly doesn´t need that many codeslines but sometimes... it´s useful :P e.g. on brawl or mkwii since there are lots of long and good codes. I get a "too many codes found" message on brawl if I want to use sd cheats plus debugging. SD Cheats alone does work since it doesn´t break the limit yet. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 27, 2011, 11:14:38 AM Not sure how many code lines it was before, but if you use the Code Extender set to 32k, that would give you room for about 4,000 additional code lines. Note that any non-extended codes after "Activate extended codes" will not be executed, so make sure that it is the last non-extended code in the GCT tab listbox. Extended codes can be anywhere in the listbox, before or after Activate Extended Codes.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 27, 2011, 01:52:45 PM Not sure how many code lines it was before, but if you use the Code Extender set to 32k, that would give you room for about 4,000 additional code lines. Note that any non-extended codes after "Activate extended codes" will not be executed, so make sure that it is the last non-extended code in the GCT tab listbox. Extended codes can be anywhere in the listbox, before or after Activate Extended Codes. Do you mean that the extender code must be the last code on my "non extended" codeslist or otherwise codes below it won´t be executed/applied?After this was enabled, I can send more codes? ___ There something else I want to mention. If I close geckodot.net after e.g. my game crashed, it sometimes remains active on the system, even though, the gui is gone. It plays this (windows) notification sound from time to time. Probably because it couldn´t connect or something. On task manager I can still see it that geckodot.net is there. I need to close it with task manager to get rid of the notification sound. It´s a little annoying glitch that exists since geckodot.net was released. It still happens quite often. ??? But no worries, any time in the future there won´t be any glitches anymore that I can discover Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 27, 2011, 02:52:58 PM First, you must use SD cheats to load the Extended Codes Allocator that I modified from Y.S. The hook runs as soon as the game starts (before even the wrist-strap safety screen), so you must use SD cheats or pause start (pause start is tricky, just use SD cheats). The allocator allocates 32kB at the bottom of the stack; some games may not like such a large stack so you may have to shrink it down a bit. The allocator also places a pointer to the extended code list into block 0. Once the allocator runs, it is safe to remove from the code list.
F6000001 80008180 54030034 48000008 D2000000 00000007 54030034 3D8000D0 618CC0DE 91830000 91830004 3980FFFF 91830008 9183000C 38630008 3D808000 906C1848 38637FF8 60000000 00000000 E0000000 80008000 --- Once the SD cheat is applied, I suggest going to 80001848 and make sure there's a pointer. If there isn't, the SD cheat failed. If there is, then you can continue. Next, apply the Extended Codes Activator. This uses a 64-code type (return) to "link" from the original code list to the extended code list. As a result of "linking" lists, anything that was leftover in the original code list after the 64-code is not executed. If you remove the activator, the extended code list will not be executed. 26001848 81800000 24001848 80000000 64000000 00000000 E0000000 80008000 --- So you ran the allocator from SD cheats. You ran the activator through send cheats in Gecko.NET. Now go to the About tab and make sure Extended Codes is checked. Now go to the GCT tab. The code checkboxes have three states now; unchecked, checked, and red-checked. Codes that are just checked will go in the original code list. Codes that are red-checked will go in the extended code list. red-checked codes can be in any order; the activator should be the last checked code, because any remaining checked codes will be ignored. EDIT: btw, if you have problems with zombie Gecko.NET processes (which I don't have, so I can't fix it...) try unplugging the USB cord. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 28, 2011, 04:18:09 AM What games/code sets would require using the extender/activator?
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 28, 2011, 03:08:58 PM Brawl has the File Patch code. SMG2 has the Transformations code. Neither of these codes can be loaded with the debugger, which makes them almost impossible to work on.
Keep in mind that the code line limit with the debugger is something like 200 or so lines. Even if you don't have those codes, some games have a lot of codes and sometimes they're very long. Also, Gecko.NET code handler patches take up code space. Now that we can have 4000 lines of codes, I can start making all kinds of code handler patches. For instance, I have plans to make a patch which can load new values into the float registers. Another patch could get all 64-bits out of the float registers, instead of just 32-bits. These patches will no longer compete for code space. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on June 28, 2011, 03:23:20 PM Have to have a good solution for the non-hackers though....
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 28, 2011, 03:29:01 PM Who cares about cheaters? =P Just kidding.
I mentioned in the other topic about the code extender that we could use gpf files and a new Extended Codes Allocator that also copies the codes that were gpf'd. We just need a suitable memory area to gpf the extended codes to. It doesn't need to be permanent, it just needs to be unused by all games until the Allocator runs. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on June 28, 2011, 07:55:30 PM Eh... I don't like the gpf idea personally.
These code handler patches you're excited about would only be optional through Gecko dotNET, right? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 28, 2011, 08:00:27 PM What's wrong with the gpf idea? I can make an app which creates a gct and gpf for a game. Place them on the SD card, turn on SD patches, done. No changes to the code handler, no changes to Gecko OS. And it leaves USB and backup loaders in the dust because they don't support gpf.
Also, I should have been more clear, they're *debugger* patches. From a plain old cheater's perspective, there is nothing wrong with the code handler. The debugger needs a few patches and I can envision some extensions, none of which affect cheaters. Title: Re: Gecko dotNET Bugs and Requests Post by: James0x57 on June 28, 2011, 08:27:10 PM @debugger patches Ahhh. I see.
@gpf: 1) /another/ file on the sd card 2) no common game enhancer apps currently support it (including accio hacks and geckocodes.org) compression *could* be a cleaner, more epic solution if a code handled the decompression. implementing compression to creating gct files is less of a pain in the arse than handling /another/ file. Just IMO. I'm not going to argue any of it- I can see reasons against compression too. (probably isn't a good-enough solution that'll fit in the footprint with the compressed codes AND allow the expanded area to be even 50% filled up after decompression.) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 28, 2011, 09:07:15 PM 1) You're already putting one file on the SD card. No harm in putting a second. Besides, the gct file will be the same for all games and never changes; if they want to add or change codes, all they have to do is replace the gpf file. So technically they're still managing only one file.
2) gpf files are really easy to make, especially if they have only one patch. That's practically identical to gct files, just with a different header. 3) I can't envision a compression solution that fits in the <1kB while leaving enough room to fit a reasonable amount of codes into the remaining space. And the existing game enhancer apps don't support compressed gct, either, so you still need changes to them. Adding compression is arguably more difficult than swapping "00D0C0DE00D0C0DE" with "0190000000[byte length in hex]". Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 29, 2011, 06:46:04 PM I'm getting some -severe- lag going on with ram dumping MEM90 on my system. Hopefully it's just the one game, but I hardly ever make ram dumps and even the ones I do make usually don't freeze up Gecko.Dotnet on my system.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 29, 2011, 06:49:32 PM Doing search dumps, MemView dumps, Disassembly dumps, Tools tab dumps?
The lag happens while dumping, or after dumping is over? What game? What do you have the top of MEM2 set to on the Tools tab? It doesn't affect MEM1? Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 29, 2011, 07:05:55 PM Went to Tools -> Memory Dump -> DUMP90.BIN
Mem2 boundary: 93400000 Doing this for Harvest Moon Animal Parade NTSC-U Clicked Dump -> The progress got to 99% and the process for GeckoDotNet started to hang on my PC. The Dump was made, but was a 0 byte bin file. The MEM1 Dump80 worked fine, I got 24mb bin file. And during the lag/hang of GeckoDotNet, the game (which was playing it's intro scenes) started to skip/lag much like how it would if Memory Viewer's auto-update was on. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 29, 2011, 07:10:16 PM ...very weird. IOS has protected memory at the top of MEM2. Accessing it is a big no-no (unless maybe you're using AHBPROT). That's what the MEM2 boundary is supposed to protect against.
When doing a Tools dump, instead of using 93400000 as your end value, try 93300000 as the end value. Title: Re: Gecko dotNET Bugs and Requests Post by: XeR on June 30, 2011, 02:19:27 PM Would it be possible to have jokers in WGC names?
For example, if I put a F6 code in RSB_01.wgc, the code will be shown in RSBP01, RSBE01 and RSBJ01 Or even ______.wgc for codes that will work on every games (mdmwii's slowdown, or a C0 code for example) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 30, 2011, 03:04:27 PM I think the term you're looking for is wild card. I can look into adding that feature. It would certainly make it easier to apply the Extended Codes Allocator.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 30, 2011, 06:22:25 PM I support linkleguerier´s idea.
___ There are some supply at requests, bugs etc. now :D I messed a bit around and got some ideas, too (plus I made pictures to describe things better O0) Requests: 1.) Poking/Assembling on a RAM Dump makes permanent writes to it. They can not be reversed without poking back the original value (solution: only grey these options out, if a dump is loaded. Editing RAM Dumps is somehow pointless and a HEX Editor can do better anyways) (http://image-upload.de/image/VFfyng/86fccd684a.jpg) 2.) Allow F2/XOR Calculator without a USB connection (and further tools, that may be added anytime soon since there´s some more space left on that tab) (http://image-upload.de/image/rrTp3K/2b9ba0bce8.jpg) 3.) Add history log for RAM Dumps, to be able to load previous dumps again (they should still remain on the list of dumps to select below "USB Gecko" and "Open Dump...") See picture. (http://image-upload.de/image/a7bxeV/afeec582e0.jpg) 4.) Option to syncronisize mem. viewer/disassembler with a tick (on abouts tab?) if dumps are loaded (e.g. if you load a dump on the mem. viewer, it is not loaded on the disassembler. Ticking the option will then load the same dump for the disassembler automatically) Bugs: 5.) Modified font size on the memory viewer does not save after closing the app. If you visit the disassembler once, the Mem. Viewer coincidentally has the right font size again. Why not right away? ??? (http://image-upload.de/image/zcEb9a/a3c6d88b3a.jpg) 6.) If you selected a Dump to load on Memory Viewer and press "Open Dump" again and cancel the selection, it will jump back to "USB gecko" source 7.) Fix "Geckodotnet doesn´t work anymore. The program doesn´t executed properly due to a problem. The program will be closed and you will be notified, if there´s a solution" (app crashes very often due to this message, not instantly but at random times. Only if no USB Gecko is connected) (http://image-upload.de/image/iKMUM7/589e8bd901.jpg) 8.) It says "Dr.Pepper´s v3 Pointer Search" on Tools Tab but it´s actually v4 Error extentions: - Clicking on Source "USB Gecko" on Mem. Viewer without having connected the USB Gecko nor loaded a dump, gives an error extension 9.) Rightclicking the "Disassembly" without having loaded contents gives an error extension 9.1.) Loading the "call stack" without a USB Connection gives an error extension I attached my error log file. EDIT: Added numbers! Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on June 30, 2011, 06:53:51 PM 1) Uh, yeah, poke/assemble on a dump should write to the dump, it kinda makes sense. Besides, I do in fact assemble on RAM dumps. A hex editor does not calculate branch offsets very well. I make a copy of the original dump if I plan on making any edits.
2) F2 XOR calculator on RAM dumps is a good idea. 3) I've been thinking about multiple dump support (and moving "Open Dump..." to the bottom so you can scroll through with the arrow keys). Busy with debugger patches and the extended code list. 4) I've been considering a synchronize option for memview/disasm, too. 5) Not sure why the font size doesn't get set. There shouldn't be anything particular about the disassembly tab, it should happen when you come from any tab, unless you used a right-click context menu to change tabs. 6) It would be easiest to cancel to the dump if it exists, rather than canceling to whatever you were on before open dump 7) Not sure what's causing this. The exception handling architecture is a bit messy. =( At some point I may have to rewrite it. I'll try to look at the logs to get some clues. 8) No, it uses Dr. Pepper's v3 search. v4 is a GUI search, v3 is the command line search. 9) I think I found the right-click disasm one. And without a USB Gecko source you'll have some problems. Call Stack requires being at a breakpoint, for instance. EDIT: !!! All your logs are in German. =( It looks like SecretDump was causing most of your issues. It was supposed to be a "fast" dump, but I think it ended up causing instability so I tried to remove it. Guess I missed one. You also have what look to be random send errors. Not sure why you're getting them. Also, I've reworked the debugger patches so they don't use C2 codes, which may help improve stability. EDIT2: I see you were on the Watch list. I would be careful with the Watch list. It is another thing I want to re-work. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on June 30, 2011, 08:37:41 PM 1.) So, it´s still reasonable to keep? But it wouldn´t be bad to have a poke/assemble verification question (e.g. Are you sure to write the new value to the file?), only on RAM Dumps, obviously. At least in my opinion
3.) Thought that worked like this on an older built, maybe I´m wrong 5.) It´s probably ANY tab, I didn´t really paid attention there 6.) I already loaded a dump, pressed "open dump..." and canceled. The source jumped to "USB Gecko" instead of staying at loaded my RAM Dump. 9.) I knew that you need to be in a breakpoint, but I just went for bug tracing by perfoming non-intended actions... :p There´s no big issue about the German on my logs since it´s still almost completely in English. I can´t change my computer language to English, or maybe you know how? Anyways... I just translate one for you. There you can see what these words mean here. It´s the same for every log I posted. 09.06.2011 20:59:45: Opened log 20:59:45: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIReadDataError Message: An exception of the type "FTDIUSBGecko.EUSBGeckoException" occured. Stack Trace: Inner Exception: 21:21:21: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIReadDataError @Edit2: It didn´t only crash on the watch list, it is a kind of random crash that could (and did) occur on some other tabs aswell. This error never pops up, if a USB Gecko is connected though. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on June 30, 2011, 11:57:22 PM I'm not sure if this is a normal issue or not:
But in regards to the GCT codes tab, after I input all the codes I want to use, hit store immediately/save codes etc, I've noticed that geckodotnet still gives me the 'The Code list has changed, store code list? Yes/No' dialog box whenever I close it. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 02, 2011, 02:05:44 PM 0.65.6 had a pretty bad bug, please get .7 WTF, The new built instantly freezes the game OR dumps data all the time (flashing progress bar).That´s really bad... :-[ Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 02, 2011, 02:16:29 PM er....what? It didn't crash for me. I've tried Super Mario Galaxy, Super Mario Galaxy 2, and a Gamecube game (Tales of Symphonia). With SMG1/2, I was testing the Extended Codes List. I both loaded the Allocator via SD cheats *and* I loaded it using pause-start. I was also testing GCT Code Undo with a mixture of things. I'm also hacking Tales *right now*.
Remember to use 1.9.3.1 handlers. If you're not using Gecko OS, I dunno what version it has, and it might break non-1.9.3.1 handlers. The bug was a problem in turning strings into numbers. i.e. the "letters" 80000000 into the number 0x80000000. To make it more robust, I tried removing everything that wasn't a hex digit, but the bug was that I removed lower-case hex digits. (my regex was [^A-F0-9] and it should have been [^A-Fa-f0-9]) So .7 fixed that. EDIT: What game? I'll try to connect to a few more to see if I get this problem. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 02, 2011, 02:31:06 PM What game? I'll try to connect to a few more to see if I get this problem. goldeneye (crashed on gdn connection)conduit2 (gdn always dumped something for no reason...) idk about others. none of these problems occured on 0.64.5 ??? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 02, 2011, 03:33:08 PM Do you have the debugger patches enabled? They're required now. If you don't use them the game will crash.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 02, 2011, 05:26:38 PM Do you have the debugger patches enabled? They're required now. If you don't use them the game will crash. how do I use these again?It would be better to avoid a crash at all circumstances :-\ Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 02, 2011, 07:08:53 PM Give me a break, I was working on making it seamless to use the extended codes list. I also forewarned that non-1.9.3.1 handlers won't work. When there are large fundamental changes to the app, it's expected that it will hiccup a few times. The next version will have better support for other handlers.
If extended codes doesn't matter to you, use an old version. And I have to admit, your two examples that crashed are not games that I care about people being able to hack. To make sure the patches are applied, go to the About tab. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 02, 2011, 07:22:09 PM If extended codes doesn't matter to you, use an old version. And I have to admit, your two examples that crashed are not games that I care about people being able to hack. To make sure the patches are applied, go to the About tab. it´s any game that is affect btw.I wasn´t using 1.9.3.1 though. Conduit2: 1.9.3.2. (laggy progress bar) Goldeneye: older than 1.9.3.1. (instant freeze) and thx for the infos, older builts will do a good job on these aswell. Extended codeslist is interesting for brawl and smg2. Get your break ;) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 02, 2011, 07:24:58 PM Try with 1.9.3.1. Make sure About box Debugger patches are enabled.
Just for you, the next rev will throw up a message box when it can't apply patches so you know about the failure, and I will force debugger patches to always be applied. Title: Re: Gecko dotNET Bugs and Requests Post by: Patedj on July 06, 2011, 08:48:41 AM Does this mean that .net will only be working with gecko Os from now on? In other words, everyone that uses backed up games on external hard drives will not be able to use the homebrew apps such as neogamma, and the usb loaders with .net?
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 06, 2011, 11:09:49 AM Does this mean that .net will only be working with gecko Os from now on? In other words, everyone that uses backed up games on external hard drives will not be able to use the homebrew apps such as neogamma, and the usb loaders with .net? yeah, the newest version 0.65.7 does freeze on any backup launcher, because they use an older codeshandler than 1.9.3.1.It obviously freezes on gecko os mod and on any older gecko os. It´s made for gecko os 1.9.3.1 ONLY for now, if you use the app with gecko 1.9.3.2. you´ll notice a glitchy progress bar on geckodotnet. Please give us an option to apply the extended codeslist patches or not, dcx2 :D As you said before, a window at connection with the game should ask the user to apply the patch or not. If it would freeze the game ("older codeshandler") throw an error message instead of freezing the game. Another bug I found: - If you input some ASCII text into the memory viewer search box and press enter, the search does not start. Instead, it clears the window. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 06, 2011, 01:23:09 PM I don't provide support for backup launchers. However, if they use the 1.9.3.1 code handler, then they will work.
I use NeoGamma to play my retail GameCube discs because it has 1.9.3.1 code handler. Gecko OS Mod doesn't support F2/F6 codes. =( The extended code list patch is not what's causing other code handlers to fail. .7 was designed ONLY for 1.9.3.1; I never tested it with anyone else, it was not meant to be used with anything else, and and the glitchy progress bar is .7 trying and failing repeatedly to patch the debugger. A new version will support 1.9.3.2. I looked into supporting older code handlers, but WiiPower says he's working on a Gecko OS Mod update so I probably won't. BTW, resize your Gecko.NET. It isn't cleared, you just created a new line in the multi-line textbox. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 06, 2011, 03:51:22 PM I don't provide support for backup launchers. You won´t only provide support for backup loaders, you will just support older gecko os versions. BTW, resize your Gecko.NET. It isn't cleared, you just created a new line in the multi-line textbox. 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 06, 2011, 04:12:58 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on July 06, 2011, 04:26:19 PM 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? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 06, 2011, 04:36:00 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on July 06, 2011, 04:39:12 PM Yes idk why but unplugging the USB doesn't work too.
However hacking with WiiRd is not easy since gecko dNET is out. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 07, 2011, 06:14:44 AM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on July 07, 2011, 08:42:31 AM @Bully
2) it's wrong! I've tried every hooktype and it still freez ;) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 08, 2011, 12:54:25 PM 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 Title: Re: Gecko dotNET release thread (version 0.65 now!) Post by: savage on July 09, 2011, 04:12:50 AM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 09, 2011, 12:34:36 PM .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. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on July 09, 2011, 10:47:35 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 09, 2011, 11:07:05 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on July 09, 2011, 11:38:09 PM 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: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 10, 2011, 12:00:55 AM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on July 11, 2011, 06:48:47 AM Yeah, I noticed that if I leave the auto-update off, things go fine.
Title: Re: Gecko dotNET Bugs and Requests Post by: Patedj on July 11, 2011, 07:08:18 AM Am I the only one that can't load cheats with .8?
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 11, 2011, 07:25:06 PM All these bugs occured while using the "load RAM Dump" feature (without a USB Gecko, obviously)
2 - 3 of these were already mentioned, but not fixed, yet. Here´s the little collection list: - switchting to the watch list tab often crashes the app, if no USB Gecko is connected ("geckodotnet doesn´t work anymore") the watch list causes problems, but I guess you already know that... - trying to load "call stack" without being in a breakpoint gives an error extension (It would be nice to put a message like "must be in a breakpoint to load call stack" instead of the error extention though) - F2/XoR Calculator is disabled, if no USB Gecko is connected - Mem. Viewer adjusts the font size, if one switches to another tab and back (if this is done, the loading time of the memory viewer takes a bit longer than normal) It should be font 8 as default right away, in my opinion - If I start a memory viewer search with no input, it gives a crash message - If I press "ctrl" and click onto an address in the memory viewer, it gives an error extension (lol, I know that one needs to press shift to add an address to the memory viewer. Anyway...) - disassembler search bug: if I search for e.g. "stw" it will proceed to the next result and it´s doing a good job. But if I search e.g. lwz r5, 876 (r31) it locks up and nothing happens, even though there are some instructions like the example one quite near to the address where I started the search. It sometimes says "Could not find search query" if there ARE corresponding results above/below the address, though. Request: - Adding "Pointer 1/2/3" task to the context menu if one rightclicks an address on any tab. It should then switch to the Pointer tab and fill in that address. Ready to do a Pointer dump! :D It´s basically like what WiiRd GUI had just that three Pointers are now supported. P.S. Thanks for supporting other codeshandlers now! I also attached some *new* error extension files. I can´t test with my Gecko since I´m not at home yet. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 11, 2011, 07:44:48 PM I'll look into these, and the others from page 34. My hacking laptop decided to start blue screening at the logon screen, so I have to get it fixed first.
Regarding the disassembly search bug, the problem is that you're using lwz r5,876(r31), with a *space* between lwz and r5. However, the actual disassembly text has a *tab* between lwz and r5. If you copy and paste a tab character from notepad, it will work. I've been meaning to come up with a way to treat tabs and spaces the same. If you really need to work around it, check the Regex Search checkbox on about tab, then go back to the disassembly search and use regex instead. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 12, 2011, 10:13:25 AM If you copy and paste a tab character from notepad, it will work. k, that should work then :)Is it possible to fix the lock up though? Some people just need to not pay attention and the app locks up due to wrong ascii. I once lost a few codes, because they generally don´t get saved in the end if you close the crashed app with task manager. I couldn´t get to the gct tab to save them anymore :eek: --- - Adding a code to the GCT tab while using RAM Dumps always puts 00000000 as it´s value instead of the one that is in memory - Completely deleting a code from the GCT tab without removing the code name doesn´t save it as "blank code". If you switch back to that code, it is still there instead of being gone (appears on RAM Dumps and USB Gecko Users) e.g. my code is 04123456 00000000, I clear it that there´s nothing left and switch to another code and back to that code, it shows 04123456 00000000, even though, it was removed before. - "Adding 0´s to fill up codes" messes up codes, if the code format was not correct or if "non hex" numbers were used. (appears on RAM Dumps and USB Gecko Users) What about allowing variables to be saved in codes or what about removing the "adding 0´s part"? It´s not cool to have codes lines moved up/down, if you accidentally didn´t get the format/numbers right somewhere in the code. If it does the intended thing, it´s no problem at all. Unfortunately, it mostly doesn´t. Pictures: (http://image-upload.de/image/LrCWoT/c9c8245611.jpg) (http://image-upload.de/image/meQtHZ/6b6bbf8d30.jpg) (http://image-upload.de/image/5y8XIo/2f13d4541d.jpg) EDIT: - I noticed that the memory viewer "remembers" the last address you retrieved after the app was closed. The disassembler however does always start at 80000000 or 9XXXXXXX (or at a random address?) and not at the last one that was viewed there. Therefore, it would be cool if the disassembler also "remembers" the last address... --- Take your time and good luck with fixing your "hacktop" ;D Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 13, 2011, 12:48:09 AM Losing codes; I am in the habit of pressing Save Codes every time I add a code to the list. It's a good habit. Maybe I should hotkey ctrl+s to be save codes.
Deleting GCT codes to blank codes; I think I noticed this once. If you delete the code and press Save Codes, it will store the blank code. I actually kinda like it, as it's a form of protection against accidentally deleting a code unintentionally. Adding 0's; the way the code is written, a code line MUST be 8 hex digits, a space, and 8 hex digits. Everything else will get stripped out during a save. The codes must be saved in a manner which can be sent to Gecko OS. What would happen if you hit Send Codes while you had a line with XXXXXXXX? If you want to mark a variable, you could use EEEEEEEE. At least it's a valid hex word. Disassembler remembers the address for me. I did see it go to MEM2 once or twice, and I never knew why. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 13, 2011, 07:41:33 PM I must be boreing you to death with my bugs posts :-[
Well, here´s some more again. :rolleyes: - Starting an "Up" Disassembly Search if address 80000000 is selected -> error EDIT: I understood how to do proper disassembly searches now btw. It´s just that you need to use the copy function in the context menu. - Mem90 Dump recognision bug: If a mem90 dump is loaded, it is *just* loaded into the mem80 part of the Memory Viewer. Therefore the problem arises that you only have access until mem818. If one then checks Mem90 for contents (after a Mem90 dump was loaded), everything is completely empty. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 13, 2011, 07:49:26 PM I don't mind bug posts. I rely on the community to do my QA testing.
When you say "extention", I think you mean exception. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 14, 2011, 05:46:32 AM When you say "extention", I think you mean exception. yes, my fault.That word doesn´t even exist :P EDIT: - If one uses the "copy" context menu function on tasks that are empty, it throws an error exception (tested on Disassembly) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 18, 2011, 12:27:42 PM While using RAM Dumps:
Disassembler (Context Menu): - "Copy All Frames" -> error exception - "get SRR0 here" -> error exception - "Copy" on empty address field -> error exception - "Copy History" or "Cut History" when history is empty -> error exception Breakpoint (COndition Window): - "Copy" or "Copy all" on empty field -> error exception - "Paste" with wrong input format -> error exception GCT Tab: - "Disable Code Lines" + "Enable Code Lines" on empty codeslist -> -> error exception --- - I´d like to be able to add hex AND dec offsets at will (since ASM uses decimal and pointers use hex) For now, the offset adds "hex values" - Could you plz also make any of the memory patches (th/rx bug patch, codes sending patch) that geckodotnet applies optional in the about tab? Thx a lot, if you appreciate looking into these. The application is REALLY good for now, there´s almost nothing left to improve. ^-^ Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 24, 2011, 06:49:22 PM - GDN Zombie process
1.) game crashed 2.) app almost locked up, it takes some seconds to execute the close command 3.) it always asks: "Want to save codes?" (but I´m pretty sure that I mostly saved it by myself before) 4.) It closes but seems to remain open when viewing processes in task manager (the annoying thing is that it keeps playing the information sound from windows, probably because it wants to say that it couldn´t connect to the USB Gecko) If it isn´t completely closed, one can´t open another one and connect to the game as far as I know. annoying thing... :o I can´t imagine that it never happens for anyone else. btw. I used version 0.65.8 fyI Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on July 24, 2011, 06:56:42 PM Actually, that happens to me too when a game crashes.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 26, 2011, 02:51:49 AM Wow, that's kinda old, you don't even have the pointer tab. You might want to update, it probably solves most of your problems. I have to release a new version today or tomorrow because 0.66 has some issues saving codes, so I recommend 0.65.8.
"different by less than 2" does not mean what you think it means. It means anything different by +1, 0, or -1. You want "different by 2". That will find stuff that changes by +2 or -2. Then you click Add in the Search Groups. This creates a new search condition, and you can change this one to "less than". The two conditions together will then get everything that changed by -2. The number in ()'s is the total number of groups. The number in the up-down spinner is the currently displayed search condition. Spin this number up and down, and you'll see the two conditions. EDIT: I will look into making Restart Search reset the search type and condition back to specific and equal, although I'll leave the data type alone. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 26, 2011, 03:19:51 AM Click the latest test build link in my sig. I just uploaded 0.66.1 which should fix the issue I just found.
The major new search features compared to WiiRDGUI are: Complete search history (the spinners above Old and New). This allows you to scroll through each previous search result to see how an address changed over the searches. These numbers also correspond to the New and Old column in the Search Conditions. You could use Old (1) to, for example, do "equal to first". View Mode - you can change this to decimal and single (single = float). The search columns are sortable. This includes the Diff column. Individuals entries are delete-able so you can "prune" your search results. The Data Type dropdown also supports Single searches, so you can search for floats as if they were floats. Load Search can be used to recover a previous search even if Gecko.NET crashed. Look in the DumpHistory folder. Search Groups allow you to place multiple conditions on search results. For instance, you could do less than 9 for one and not equal to 0 for the second. This would show all results that were 1-9. Any "equals" condition can be true for a result to show up; all other conditions that aren't "equals" must be true for a result to show up. EDIT: 0.66 fixed the "constantly pester you about saving GCT", and it also fixed the disassembler remembering addresses. In fact it auto-saves GCT so you don't have to worry. And it also keeps a history of every GCT ever saved so you can't lose codes. One of my plans is to sense when you're in GameCube mode and prevent MEM2 access. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 26, 2011, 11:07:55 AM what´s different in the RAM when hacking a Wii and GCN game?
Is there something at the beginning of mem80 like the game ID that indicates the game type? --- When the game crashed, gecko.NET gets slowed down by a lot. Would it be possible to prevent that? Sometimes, you still want to do things with it while rebooting before connection to the game is up again. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 26, 2011, 12:35:06 PM When I lose connection and I try to do something like view memory or disasm, I get a yes/no error message. I click no, sometimes twice, and it stays disconnected. If you know the game crashed you could try pressing Disconnect before doing anything else. If you accidentally hit yes instead, you can click cancel connection.
EDIT: If you unplug the USB from the PC, it should instantly time out instead of slowly timing out. GameCube game IDs begin with G. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 26, 2011, 04:05:52 PM EDIT: k that seems reasonable and I can remember that plugging off the cord instantly times out.If you unplug the USB from the PC, it should instantly time out instead of slowly timing out. I think it´s more useful to auto-disconnect from the game, if it crashed (but after it switched to breakpoints tab and the crash bp automatically hit). Good luck with the gamecube mem90 prevention then... However.... do you *ever* need mem90 on the disassembly? But since you fixed address remembering on disassembly... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 26, 2011, 04:33:24 PM I really don't like the idea of auto-disconnect. Now the breakpoint handler is installed on connection (previously, you had to set a breakpoint for it to be installed, so if you didn't set a breakpoint before you crashed you couldn't recover). You should always be able to diagnose and recover from a crashed game.
I have uncrashed games dozens of times, although some crashes are harder to fix than others. Set SRR0 helps a lot here; you can SSR0 on the function epilogue to walk the stack while avoiding any processing that might cause more crashes. I've even used the information from the crash dump to make a few anti-freeze codes which prevent the crashes from happening in the first place. --- GCN MEM2 protection shouldn't be too hard. Link laid the framework for limiting the range of MEM2 (because IOS protects stuff from about 93400000 to 94000000). If I limit MEM2 to nothing, it should hopefully prevent GCN crashing. --- The disasm was actually using the last MemView address for some strange reason. Must have been a copy/paste bug. I've never used disasm on MEM2, however VC games store the ROM there. VC ASM hacks will therefore patch MEM2. I did have some plans to make the disasm tab show results from e.g. Tracer, but that ended up being more difficult than it was worth. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on July 27, 2011, 12:11:48 AM When I load a saved search I get:
See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.NullReferenceException: Object reference not set to an instance of an object. at GeckoApp.MemSearch.PrintPageAlt() at GeckoApp.MemSearch.UpdateGridViewPage(Boolean ResizeGridView) at GeckoApp.MainForm.numericUpDownNewSearchIndex_ValueChanged(Object sender, EventArgs e) at System.Windows.Forms.NumericUpDown.OnValueChanged(EventArgs e) at System.Windows.Forms.NumericUpDown.set_Value(Decimal value) at GeckoApp.MainForm.buttonLoadSearch_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- Gecko dNet Assembly Version: 1.0.0.0 Win32 Version: 1.0.0.0 CodeBase: file:///D:/wiisd%20root/Gecko.Net/Gecko%20dNet.exe ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. Quote from: James0x57 32 bit search for: ?A?A?A00 returns results like: 1A2A7A00, 0A0A0A00,AAAAAA00 and so forth. Is it possible to have the option to turn on specific lines of a code to test without deleting the whole line itself, then having to put the line back? (Wiird had this option.) Quote from: James0x57 Oh, Request: When you double click on a value in mem view, it will go to it if it's an address. Could you please add a "go back" to the right-click context menu? If it's not a big pain, maybe even a small, 4 or 5 history stack? :3 still hasn't been added ^ Quote from: Mathew_Wi Bug: Multi Poke It works fine at first, then I switch to, say, 8 bit search, I do a multi poke and the poke box says some random number. So, start with 32 bit, multi poke works. Switch to 8 bit, multi poke says random crap. I noticed this too. I made a mention in the first part of my post. Quote from: James0x57 Hex to Ascii converter and a calculator in the gui, ready to use! (Same as decimal to hex and so on!) You guys already made the notepat feature, which is a great idea! Why not more of this hacking related useful stuff? :) Not a bad idea. Don't know why that hasn't been made yet. (http://dl.dropbox.com/u/24514984/lolmemview.png) I know you can "copy all cells" but it's hard to ask for a memview snapshot feature. I like to illustrate what I'm saying with images. But that's not all that important. Copy all cells is convenient enough. That's all the bugs/requests for now.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 27, 2011, 02:35:27 AM @Sharkbyte :eek: Wow, that's quite a list there. Thanks for all of the feedback. Taking it from the top...
1) 16-bit poke. It should take the existing value. At least, 32-bit pokes will do that. I'm not exactly sure what a 16-bit poke will do, so I will look into it. Honestly, I use MemView poke more than Search poke, since MemView poke supports operations beside write. Search poke does have Multi-Poke and Serial-Poke support, though. 2) Search Ranges. I'm not sure precisely what you mean here, because you use value and address. Fortunately, Gecko.NET can do both. For Address ranges, look at the Memory Range groupbox at the top-left of the Search tab. Here, you can specify start and end addresses. The "end address" is one byte AFTER the last byte to dump (i.e. 81800000 means the last dumped byte is 817FFFFF). For value ranges, you will need to use the Search Groups. First, create a Search Condition "Specific Value" "Greater or equal" "3F800000". Then go to Search Groups and click Add. You will see Search Groups (2), and the spinner will increment to 2. Now change Search Condition to "Less or equal" "3FC00000". Click the spinner up and down and you should see your two search conditions. Since this is obviously a float, you should also change View Mode to Single. Also, since you're doing floats, you will be interested in the value textbox context menu. Right click a value textbox (like the Search Condition Value) and you can use that menu to convert to/from hex/dec/float/ASCII. 3) "Cheats Sent!" dialog. I'm not sure why this bothers everyone. Assuming your one hand is still near the keyboard, just hit the space bar. I will consider moving this to the status bar at the bottom. 4) The 0-fill in GCT codes. There's not much I can do about this. Codes are not stored as text, but instead they're stored as two sets of 8 hex digits (with a few bookkeeping bools). If you don't provide a valid code line, it fills it with 0's until the line is valid. It needs to do this; imagine if you tried to Send Codes with half a code line...what should happen? What if your code had non-hex digits, or symbols, how should Gecko.NET format the codes before sending to the game? There is also error checking to prevent invalid codes from being saved. I can't do much about that, because codes need to be valid before they can be sent or saved. My only suggestion is that if you're building a code, make it in Notepad first and then copy/paste the final result into the GCT tab. 5) >32-bit searches in the Search tab. Probably not happening, too many major changes required, not the least of which would require major modifications to how searching is done so it supports something like arrays of bytes. Your best bet is to use MemView Hex Search. 6) Not sure about wiiztec's text search page-up/down. I'll have to try to replicate the issue. 7) 0x100 byte alignment in MemView. One of the things I specifically *hate* was this forced alignment. I can't tell you how many times I was looking at memory and I had to keep switching pages up and down just to see the last row of one page and the first row of the next. Instead, Gecko.NET centers the selected MemView address when you use shortcuts like the Search result context menu. This way you can see all around the value of interest. This is why it might look "random"...don't put too much focus on the Address groupbox at the top left of MemView, which denotes the beginning of the currently visible chunk in MemView. The Value Poke groupbox's addresstextbox is probably what you're really looking for, because it corresponds to the selected cell's address. As far as jumping back to old addresses when you switch tabs...now that you mention it, I think I've seen that behavior a few times. I have replicated the behavior and I'll try to fix it. 8) Is this...undo multi-poke? 9) You can't do straight to text, but you can dump raw binary using the Tools tab. There is also Copy All Cells in the MemView DataGridView's context menu. I can look into supporting other types of dumping besides raw binary files on the Tools tab. I can even try to one-up that by not only printing the hex and ASCII, but also the float and ASM. It would be quite wide. 10) 2-seconds to pause. I do not experience that issue. When I press Pause, it happens instantly. Although you're probably using Gecko OS Mod, which means your code handler is old and won't have the debugger patches. This means breakpoints can "miss" (among other unrelated issues). If BPNext somehow "missed", it could take a few seconds until it tries again. You could try unchecking BPNext on the About tab so it uses old-style pausing, although I would verify that you're having the 2-second pause problems in Gecko OS 1.9.3.x first. 11) James' idea for search masks. I've been trying to consider this, but I can't think of a reasonable approach. ?'s would have 4-bit granularity, which I don't think is good enough. I'd like to somehow add another value textbox that allows you to specify a bitmask. 12) Disabling code lines. Prefix -- and the code line will be disabled. BTW, there is also GCT Code Undo; prefix a line with ##, then give a full address (not 04 code!) and a 32-bit poke value, and the address will be poked for GCT Undo. You can also double-click any 00/02/04/C2 code word (just the first word), and then press ctrl-u and it will automatically create an undo line with the current value of the address with ba=80000000 (this means you should do it before applying any codes! Ideally, restart the game so everything is "unhacked") 13) Double-click MemView remember old address. To an extent, you can do this, though it might be a bit odd at first. Every addresstextbox has a built-in history function. When the text caret (the blinkie | thinger) leaves an addresstextbox, the contents will automatically be added to the history. To remember an address, then, all you need to do is click in the addresstextbox once; when you click on something else (like a pointer you want to follow) it will automatically add the last address to the history. When you want to come back, double-click the addresstextbox to see the history dropdown. Select the address you want, and then press Update. 14) I think multi-poke must be 32-bit. I'm not sure. I'll look around at this a bit. 15) All value textboxes have a context menu that can do hex/dec/float/ASCII conversions. I just use Windows calc in scientific mode...no need to reinvent the wheel. For ASCII conversions >4 chars, I've been thinking about re-using the MemView Search textbox. 16) 30-second "ding" when connected but not booted. ...I'm not really sure what you're talking about, honestly. My sound is always muted so I wouldn't hear a ding. Is that the message prompting you to auto-boot the game? 17) Tab Order. I tried to put these into the order of more frequent use coming first. The Search/MemView/BP/Disasm tab order is non-negotiable, as these are my most common tabs. The rest I'm more flexible on, if you'd like to try again. Though I'd prefer some reasoning behind the order. 18) Dr. Pepper's pointer search app supports 3 separate dumps, to help eliminate false positives. 19) Lag closing. not really sure. Other people report some zombie Task Manager killing. I'm beginning to think it's a debug/release problem...I always run from source, so I'm in Debug mode. When I close Gecko.NET, I never get zombies. I'll try some release testing. Making sure I got this right...load Gecko.NET with a USB Gecko connected but no game loaded, and then exit? 20) Changing Search memory range while searching is a bad idea, that's why I froze it during searches. If you want to narrow down the results, sort by address, and then highlight results that you don't want and press delete. --- @Stuff 1) Can you somehow send me the save you tried to load? Was it an srh file? Or a zip? 2) See my comments to Sharkbyte above 3) Adding offsets to addresses. Right-click any addresstextbox or any datagridcell in MemView. "Add Offset". Give it a hex address without 0x, prefix with - if you want to subtract. How I normally use this: right-click, "o", "800", "enter". This will add 0x800 to the address. 4) Show more MemView data. I was thinking about making it longer vertically, but I doubt I would make it wider. There are a lot of assumptions based on a 256-byte window. 5) I've been considering a full MemView history, like there's a Search history and GCT history now. It could remember everything, kinda like unlimited snapshots. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on July 27, 2011, 03:29:48 AM oh. I never new about add offset XD. wow. That's so handy.
The longer memview, I'm just saying to make it longer vertically. It'll be weird if you made it wider. I guess you can do a ascii column if you want, but we already have ascii view. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 27, 2011, 03:42:27 AM Yeah, try to right-click any and everything you possibly can. A lot of functionality is in the context menus.
I've been thinking about adding another column for the simultaneous ASCII view if you want to expand out that far. That seems like the typical thing that hex viewers do. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on July 27, 2011, 04:46:30 AM Well the context menu doesn't really always work. Paste from the context menu is bootleg, while ctrl+V works as expected. I tried convert ascii->hex in the search box and nothing happened. I'll still right click everything I can to see what I find. And then report some weird stuff like paste.
Quote from: dcx2 12) Disabling code lines. Prefix -- and the code line will be disabled. What?Also, the way wiird had that asterisk for on was pretty cool. But then deleting lines was awkward. If you can do that "check for on" without doing that grid thing it had, great. Otherwise, I'm good with --. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 27, 2011, 06:22:11 AM wow, complete page got filled.
1.) Let´s clarify the "specific lines enabled" thing. Put it into the GCT tab like this: -- 0453453A 60000000 0453453A 38000000 Send codes and it will then apply the second line, but not the first one. 2.) How the zombie process occures is described by me above somewhere: Crash the game, close gecko.NET voila, you got the zombie process that makes you hear the "bling" sound every few seconds until it was completely closed with task manager 3.) Please include the "Cheats sent!" into the status bar 4.) "Want to automatically boot a game?" dialog that pops up when using Gecko OS does nothing when Yes was pressed. WiiRd really launches the game, but Gecko.NET doesn´t 5.) Adding support for multipoke "poke every address´ previous value" and fixing the general "8bit/16bit previous value poke" would be awesome! 6.) Resizing the window to get an overwhelming mem. viewer address view would be nice, I agree Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on July 28, 2011, 04:56:39 AM @Sharkbyte
I suppose I should be a bit more clear. While I'm quite willing to take suggestions for new features, they are subject to my own whims. I use a complicated metric to determine whether and when new features are added, weighing factors like how useful it is to me, or others, how long it will take to implement, and any significant modifications that need made to the "engine" behind all the tabs. Sometimes I won't do stuff yet, but I usually weigh what someone asks for pretty well. - Value range searching. While a different set of controls may be more intuitive, they will also be inherently less flexible than the existing controls. For instance, you can currently do a search condition that is less than the previous value, not equal to the specific value 0, and different from the first value by less than 3, all at the same time. I'm not convinced that making something easier is worth reducing its utility. Now, what I might consider is a "search wizard" kinda like the GCT Wizard and perhaps it could have these more intuitive controls, and you could use it to set the base controls. This is a maybe sooner or later. - 0-filling; I'm not sure what version of WiiRDGUI you were using, but it also enforces the rule about how codes are stored and just flat out refuses to save a partially completed code line. Maybe you mean the textbox at the top that lets you write one code line at a time before you add it to the list? - Quote No, I am saying that I would like to do an unknown search with various values and have the multipoke option still work for every value, even though every address is pretty much a different value the new multipoke option (if added) would make it so I can poke the old value of whatever value was at the address at the time of the search. Uhm...can you or Bully give me an example of where this feature might have helped you make a hack? I hardly use multi-poke so I'm not sure why this would be useful. - 9) You can't do straight to text, but you can dump raw binary using the Tools tab. ... I can look into supporting other types of dumping besides raw binary files on the Tools tab. It's not a matter of "it can't do it ever". It's a matter of "it can't do it yet, so I'll add it to my list of things to do". - It is a big deal if pausing doesn't happen instantly. You say this is on Windows 7? Are you sure you're using the latest driver from the manufacturer? 32-bit windows (http://www.ftdichip.com/Drivers/CDM/CDM20814_WHQL_Certified.zip) or 64-bit windows (http://www.ftdichip.com/Drivers/CDM/CDM20814_WHQL_Certified.zip). I think I'll put a check in Gecko.NET that makes it easier to find drivers. - Bully got it right, put -- in front of a code line to disable it. I brought up GCT Code Undo as a side-thing. Imagine you make a code that nops the stw. You send cheats. Then you don't want the code anymore. So you uncheck the code and send cheats again, but the stw is still nopped! GCT Code Undo allows you to tell Gecko.NET what the original value of an address was, and it can use this info to disable cheats. This can also be used to unhook C2 branches in 1.9.3.1 handlers. - multi-poke, "I hope not, cause that will suck not having support for 8bit and 16bit." I'm pretty sure you can still 8- and 16-bit poke. I'm just not sure if multi-poke supports it. Like I said, I'll take a look. - tab order, not sure what you mean by "seems to change with every release". The only time it changed was when the Pointer tab was added. - Changing search address range. I know you mean once dumping is over, but I can't let you change the start or end addresstextboxes once searching has begun. They're frozen for a good reason. The engine relies on those values staying the same once you start searching. It's not worth the time to implement such changes when you can prune search results by deleting the addresses you don't want, or setting the range before you do the first search --- @Stuff - what textbox were you trying? Paste worked for me, but ASCII did not. @Bully - >.> er...auto-boot works for me. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 28, 2011, 05:59:13 AM Uhm...can you or Bully give me an example of where this feature might have helped you make a hack? I hardly use multi-poke so I'm not sure why this would be useful. Uhm... pretty often.I tried to make a "gun modifier" and used unknown value searches. I got like 20 results left. So I went to multipoke and wanted to poke the previous value to check if any of those gives back the old gun. I did one by one and finally found it... Since poking 10 suspected addresses at the same time is more effective than 1, it´s useful to use that feature. Same for almost any other unknown value code. Value changed, you want to poke back the previous value from multiple address to see if any of them does what you wanted. Poking one value to *all* the selected adresses often fucks everything up, as you can imagine O0 But still, there should be *both* "previous value poke" and "specific value poke for all of them" In my opinion, it is definetely one of the best new feature suggestions... Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on July 31, 2011, 06:42:30 AM Pointer Dumps do not remember directory.
They are always in the default folder again. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 01, 2011, 02:33:29 AM Not like it bothered me, but the cheats sent msg box was still showing up for me.
Quote MemView now shows ASCII for selected cell below the float value Also didn't happen. I was looking at my character's name. Just a floating point value.And now the memview font is weird. Only sometimes though. o.O (http://i46.servimg.com/u/f46/16/26/51/46/weird_10.png) I think it has to do with starting gecko.net with no game connected.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 01, 2011, 05:12:34 AM Check the About box, I don't think you're using 0.66.2.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 01, 2011, 05:31:43 AM Check the About box, I don't think you're using 0.66.2. true.His font is bigger, it must be version > 0.66.1. since it changed on 0.66.1. But.... Gecko.NET 0.66.2 it says version 0.66.1 on the abouts tab.http://geckowii.googlecode.com/files/Gecko dNet 0.66.2.zip (http://geckowii.googlecode.com/files/Gecko dNet 0.66.2.zip) Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 01, 2011, 05:45:15 AM yeah it says 0.66.1 :/ Must've been that link >.<
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 01, 2011, 05:52:55 AM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 01, 2011, 05:56:13 AM When I made the zip file for 0.66.2 I put the wrong exe in it. rofl ;DTitle: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 01, 2011, 05:39:16 PM When I made the zip file for 0.66.2 I put the wrong exe in it. win xD Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 01, 2011, 08:10:53 PM - switching from search tab to memory viewer using the context menu takes me to wrong addresses (bad bug :-\)
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 01, 2011, 09:00:06 PM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 02, 2011, 09:10:58 AM Just the search tab? Does disasm context menu's memview shortcut work? How about Show Mem during a breakpoint with a load or store? correct address lookup still fails when trying to trace back a pointer in pointer code for example.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 I couldn´t get to the right address, but with 0.66.1 I could. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 02, 2011, 01:17:22 PM I don't understand what you mean. Do you mean double clicking on address in memview?
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 02, 2011, 01:51:12 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 02, 2011, 11:50:32 PM 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) Do you have the GCT Code Undo line? That is, the line "##undo_addr undo_val"?I ticked "undo after disabling" and "undo after sending" but it still froze :( I even pressed disable and sent again, but it froze. 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... Title: Re: Gecko dotNET Bugs and Requests Post by: goemon_guy on August 03, 2011, 12:13:43 AM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 03, 2011, 02:07:24 AM 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. 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.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. ##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... Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 03, 2011, 11:56:30 AM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 03, 2011, 01:15:19 PM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 07, 2011, 02:08:59 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 07, 2011, 03:23:55 PM ...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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 07, 2011, 04:38:47 PM ...strg = ctrl? It already does this. :P 1.) yeah, I forgot to take the english meaning. It´s ctrl.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. 2.) It happens, when I do a search with some results left and change tabs (that bug often happened to me, it shouldn´t be too hard to reproduce) 3.) I mean that the C2 code is always active, when having the undo code infront of it, ignoring the 20 condition. I don´t mean that it pokes the undo either way. It´s about the way how the code is applied in-game. Without the undo line above, there are no problems with my 20 condition. :p However, how to code in F2? Can you show it on my code example? I don´t understand the XOR part. The rest should be clear. Thx :) There´s also the XOR calculator... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 07, 2011, 05:57:31 PM 2) Without a specific series of actions that reliably reproduces the bug, I can't find it. It's not as simple as looking for the bug after noticing a button is disabled; I have to see what causes it to become disabled as it happens. I have had search results left and switched tabs with no problem.
3) Think carefully about what happens. -a) You click send cheats -b) GCT Code Undo pokes 809CB1B4 with 807F138C -c) The codes are then sent -d) When the codes are executed, the 20 code says "is 809CB1B4 == 807F138C?". Well...you just poked it in step -b! So of course the 20 code will say it's true 4) Do you understand the purpose of the F2 code? http://www.geckocodes.org/index.php?arsenal=1#F2 Explaining XOR is beyond the scope of this post. XOR is another binary function, like AND, OR, NOT. Do some googling if you want to know what XOR means. Windows Calculator in scientific mode can do XOR. But it's tedious to XOR many values together, which is what the XOR calculator is for. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 07, 2011, 08:46:03 PM 2) Without a specific series of actions that reliably reproduces the bug, I can't find it. It's not as simple as looking for the bug after noticing a button is disabled; I have to see what causes it to become disabled as it happens. I have had search results left and switched tabs with no problem. 2.) kk, I may post later being more accurate3) Think carefully about what happens. -a) You click send cheats -b) GCT Code Undo pokes 809CB1B4 with 807F138C -c) The codes are then sent -d) When the codes are executed, the 20 code says "is 809CB1B4 == 807F138C?". Well...you just poked it in step -b! So of course the 20 code will say it's true 4) Do you understand the purpose of the F2 code? http://www.geckocodes.org/index.php?arsenal=1#F2 Explaining XOR is beyond the scope of this post. XOR is another binary function, like AND, OR, NOT. Do some googling if you want to know what XOR means. Windows Calculator in scientific mode can do XOR. But it's tedious to XOR many values together, which is what the XOR calculator is for. 3.) obviously! I understood it now... 4.) It´s checking if the XOR checksum is true, then it executes the codes (like 20 + C2) Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 08, 2011, 03:57:46 AM 2) Without a specific series of actions that reliably reproduces the bug, I can't find it. It's not as simple as looking for the bug after noticing a button is disabled; I have to see what causes it to become disabled as it happens. I have had search results left and switched tabs with no problem. I get this issue too. Usually when I have to reconnect, though. Cuz it randomly disconnects. >.> So maybe something in the "connect gecko" function.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 04:13:56 AM ...it randomly disconnects?
When you experience a random disconnection, close Gecko.NET, go look in the ./Logs/ folder for a file called GDNDebug [date/time].log. This is a record of all the exceptions that have been caught. See if there's an exception that correlates with your random disconnect. All entries in the log are date/timestamped as well, so if you do it immediately after the random event it should be the last thing in the log with a very recent timestamp. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 08:13:02 PM explain me the following dcx2, plz ;D
1.) I send the following code on the main menu of the game. ## 801E8B28 40800020 041E8B28 48000020 2.) I get myself to the part of the game, where the address executes (branch in this case) 3.) The code works, I press "disable codes" to let the undo code poke the default value -> It crashes and disconnects gecko.net! Also, if I send the code when it´s already executing, crashes the game. Idk why this happens... :confused: Btw. I´m using codeshandler < 1.9.3.1. with gecko.NET 0.66.6 08.08.2011 22:07:47: Opened log 22:07:47: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply Message: Eine Ausnahme vom Typ "FTDIUSBGecko.EUSBGeckoException" wurde ausgelöst. Stack Trace: bei FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump) bei FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream saveStream) bei GeckoApp.Disassembly.Disassemble(UInt32 address, Int32 commands) Inner Exception: And if I just send the code in this format: 041E8B28 48000020 crashes instantly also. Btw. poking the value does not crash, it works. It´s not a "crashy" code. 08.08.2011 22:15:54: Opened log 22:15:54: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDICommandSendError Message: Eine Ausnahme vom Typ "FTDIUSBGecko.EUSBGeckoException" wurde ausgelöst. Stack Trace: bei FTDIUSBGecko.USBGecko.SafeResume() bei GeckoApp.MainForm.GCTSndButton_Click(Object sender, EventArgs e) Inner Exception: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 08:24:16 PM Usually, when an ASM patch fails, but the poke works, it means there was a problem invalidating and flushing the cache. I saw the same problem with SafeResume when my C0 codes were crashing. When you say "code handler < 1931", do you mean you're using Gecko OS Mod or some USB loader that's using the old code handler? If so...then I have no clue what the problem is, because none of my debugger patches would be applied in that case. EDIT: Hm. It works by poke. I bet it also works when it's loaded as SD cheats, too. When it crashes, does the BP Tab show anything when you press Step Into? Are there any other codes active? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 08:29:50 PM Usually, when an ASM patch fails, but the poke works, it means there was a problem invalidating and flushing the cache. I saw the same problem with SafeResume when my C0 codes were crashing. When you say "code handler < 1931", do you mean you're using Gecko OS Mod or some USB loader that's using the old code handler? If so...then I have no clue what the problem is, because none of my debugger patches would be applied in that case. EDIT: Hm. It works by poke. I bet it also works when it's loaded as SD cheats, too. When it crashes, does the BP Tab show anything when you press Step Into? Are there any other codes active? 1.) It works by poke and obviously by SD Cheat 2.) I can´t get/click anywhere after it crashed. It says "Connection failed" and the app is frozen. "Error sending command to the gecko" and everything greys out. That´s normally the case when it crashed :( 3.) This is the only active code. I doublechecked and the lines counter said 1/220 --- It never failed like that with the codeshandler I often use. Same happened with gecko.NET 0.66.5 btw. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 08:33:48 PM You didn't answer this question. When you say "code handler < 1931", do you mean you're using Gecko OS Mod or some USB loader that's using the old code handler? My patches aren't applied to old code handlers.
Do you have this issue with WiiRDGUI? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 08:37:51 PM You didn't answer this question. When you say "code handler < 1931", do you mean you're using Gecko OS Mod or some USB loader that's using the old code handler? My patches aren't applied to old code handlers. I used config. USB Loader.Do you have this issue with WiiRDGUI? Connecting gecko.net didn´t crash. Progress bar is a bit laggy on v 0.66.6 WiiRd GUI does not work on my laptop: (http://image-upload.de/image/mXfZTk/6ed17df264.jpg) I´m too lazy to switch disks all the time. >_< I always use USB Loader except for the game that´s in the disk slot. Same disk mostly remains there for a pretty long time... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 08:48:23 PM Progress bar is a bit laggy on v 0.66.6 What do you mean, "laggy"?I should probably include some message box that pops up when you connect to a debugger that can't be patched. But if your loader supports F6 codes then it's definitely using a supported code handler. I don't know what's causing your 04 code to fail. Since it's just a branch, you could try using a C2 code. You'll need to make sure CTR and LR are safe to use, and then you can load the destination address of the branch into r12 and then bctr. lis r12/ori r12/mtctr r12/bctr. If that works, the problem was likely the cache not being invalidated or flushed. EDIT: also, since this seems like more of a problem with a specific code than with Gecko.NET you might want to create a thread in Wii Game Hacking Help. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 08:55:12 PM Progress bar is a bit laggy on v 0.66.6 What do you mean, "laggy"?I should probably include some message box that pops up when you connect to a debugger that can't be patched. But if your loader supports F6 codes then it's definitely using a supported code handler. I don't know what's causing your 04 code to fail. Since it's just a branch, you could try using a C2 code. You'll need to make sure CTR and LR are safe to use, and then you can load the destination address of the branch into r12 and then bctr. lis r12/ori r12/mtctr r12/bctr. If that works, the problem was likely the cache not being invalidated or flushed. EDIT: also, since this seems like more of a problem with a specific code than with Gecko.NET you might want to create a thread in Wii Game Hacking Help. 2.) yep, it supports F6 codes (probably version 1.8 or so) 3.) other branches with same game, same loader, same gecko.net don´t crash! Well, as long as the freezing 04 code works as gct, it´s fine. Is there are way to fix "cache not being flushed or invalidated" ? Seems like it´s a "random" error. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:02:19 PM 1) When you switch to the GCT tab, it auto calculates how many code lines are available. The first time you switch to the tab, it does this for each code that's loaded, and I'm not sure why but it's harmless. Then, each time you select a code to enable or disable it, it re-calculates the code size. Keep in mind that the total code list can change depending on whether you're using extended code list, or 1932 code handler (the 1932 handler keeps an "unhook list", and the list takes up space in the code list)
3) If the branch was a conditional branch, you could try to make the condition always true. Then you won't need to patch the branch. As far as fixing the cache problem, there wouldn't be any way to do it without a code handler patch to the 04 code. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:06:57 PM Default condition:
801E8B28: 40800020 bge- 0x801e8b48 My code makes it an always branch: 801E8B28: 48000020 b 0x801e8b48 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:09:13 PM Yeah, there's some kinda cmp or . instruction before the bge-. You could change it so it always evaluates to greater-or-equal.
Try this C2 code. It might work, although I'd need a Copy Function on the hook address to know for sure. lis r12,0x801E ori r12,r12,0x8B48 mtctr r12 bctr If that C2 code works, and the 04 code does not, then I would blame the cache. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:13:15 PM Yeah, there's some kinda cmp or . instruction before the bge-. You could change it so it always evaluates to greater-or-equal. Try this C2 code. It might work, although I'd need a Copy Function on the hook address to know for sure. lis r12,0x801E ori r12,r12,0x8B48 mtctr r12 bctr If that C2 code works, and the 04 code does not, then I would blame the cache. The C2 code crashes aswell. Code: C21E8B28 00000003 801E8AEC: 9421FFF0 stwu r1,-16(r1) 801E8AF0: 7C0802A6 mflr r0 801E8AF4: 90010014 stw r0,20(r1) 801E8AF8: 93E1000C stw r31,12(r1) 801E8AFC: 3FE08066 lis r31,-32666 801E8B00: 3BFF2688 addi r31,r31,9864 801E8B04: 801F3164 lwz r0,12644(r31) 801E8B08: 2C000000 cmpwi r0,0 801E8B0C: 41820010 beq- 0x801e8b1c 801E8B10: 28000001 cmplwi r0,1 801E8B14: 41820054 beq- 0x801e8b68 801E8B18: 480000AC b 0x801e8bc4 801E8B1C: 807F30BC lwz r3,12476(r31) 801E8B20: 38030001 addi r0,r3,1 801E8B24: 28000005 cmplwi r0,5 801E8B28: 40800020 bge- 0x801e8b48 801E8B2C: 807F3168 lwz r3,12648(r31) 801E8B30: 38800052 li r4,82 801E8B34: 4BFFAFC5 bl 0x801e3af8 801E8B38: 38000000 li r0,0 801E8B3C: 901F3150 stw r0,12624(r31) 801E8B40: 901F314C stw r0,12620(r31) 801E8B44: 48000080 b 0x801e8bc4 801E8B48: 807F3168 lwz r3,12648(r31) 801E8B4C: 38800000 li r4,0 801E8B50: 38A00006 li r5,6 801E8B54: 4BFFB369 bl 0x801e3ebc 801E8B58: 807F3164 lwz r3,12644(r31) 801E8B5C: 38030001 addi r0,r3,1 801E8B60: 901F3164 stw r0,12644(r31) 801E8B64: 48000060 b 0x801e8bc4 801E8B68: 801F3128 lwz r0,12584(r31) 801E8B6C: 2C000000 cmpwi r0,0 801E8B70: 41820038 beq- 0x801e8ba8 801E8B74: 80DF316C lwz r6,12652(r31) 801E8B78: 3C600001 lis r3,1 801E8B7C: 38038000 subi r0,r3,32768 801E8B80: 3880000C li r4,12 801E8B84: 7C6600D0 neg r3,r6 801E8B88: 38A00000 li r5,0 801E8B8C: 7C633378 or r3,r3,r6 801E8B90: 38C00000 li r6,0 801E8B94: 7C63FE70 srawi r3,r3,31 801E8B98: 7C001838 and r0,r0,r3 801E8B9C: 60000022 ori r0,r0,34 801E8BA0: 5403043E rlwinm r3,r0,0,16,31 801E8BA4: 4BFDE4A1 bl 0x801c7044 801E8BA8: 3C808066 lis r4,-32666 801E8BAC: 38000000 li r0,0 801E8BB0: 38842688 addi r4,r4,9864 801E8BB4: 38600001 li r3,1 801E8BB8: 90043150 stw r0,12624(r4) 801E8BBC: 9004314C stw r0,12620(r4) 801E8BC0: 48000008 b 0x801e8bc8 801E8BC4: 38600000 li r3,0 801E8BC8: 80010014 lwz r0,20(r1) 801E8BCC: 83E1000C lwz r31,12(r1) 801E8BD0: 7C0803A6 mtlr r0 801E8BD4: 38210010 addi r1,r1,16 801E8BD8: 4E800020 blr Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:20:28 PM Okay, there's no way the C2 code had a cache problem.
Try doing this. 801E8B24: 28000005 cmplwi r0,5 -> cmpw r3,r3 # this will always be equal, should effectively make bge- into b or 801E8B20: 38030001 addi r0,r3,1 -> li r0,6 # will make the cmpwi always greater than Also...if you poke the branch when it's already executing, does it still work? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:26:44 PM 801E8B24: 28000005 cmplwi r0,5 -> cmpw r3,r3 # this will always be equal, should effectively make bge- into b Poking did never crash.Also...if you poke the branch when it's already executing, does it still work? --- gct code 041E8B24 7C031800 ("cmpw r3, r3") crashed the game. gct code 041E8B20 38000006 ("li r0, 6") crashed the game. Gecko.NET always says stuff about error extentions... FTDIUSBGecko.EUSBGeckoException: Eine Ausnahme vom Typ "FTDIUSBGecko.EUSBGeckoException" wurde ausgelöst. bei FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump) bei FTDIUSBGecko.USBGecko.GetExiSendAddress() bei GeckoApp.CodeController.UpdateActiveCodeCount() bei GeckoApp.CodeController.UpdateCode(Int32 index, String codeInput) bei GeckoApp.CodeController.codeOutput_SelectedIndexChanged(Object sender, EventArgs e) bei System.Windows.Forms.ListView.OnSelectedIndexChanged(EventArgs e) bei System.Windows.Forms.ListView.WmReflectNotify(Message& m) bei System.Windows.Forms.ListView.WndProc(Message& m) bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) --- bei = at wurde ausgelöst = was triggered Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:42:52 PM Are you sure you poked the address while that part of the game was executing? Because it sounds like this isn't a problem with the code or the code handler, because otherwise other ASM hacks would fail too.
Did you try pausing before you send cheats? It shouldn't make a difference but maybe it will. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:50:46 PM Are you sure you poked the address while that part of the game was executing? Because it sounds like this isn't a problem with the code or the code handler, because otherwise other ASM hacks would fail too. 1.) I´m 100% sure that it worked by poke.Did you try pausing before you send cheats? It shouldn't make a difference but maybe it will. I tried it again and switched from default to modded value and nothing crashed. The code took effect, how it was intended. But if I send the same 04 code operation, it crashes. Pausing the game before sending crashed aswell. I´m really clueless now. Using the code as GCT works :eek: Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:53:58 PM Pausing the game before sending crashed aswell. Did it crash before or after you unpaused? The game should not be running while it's paused, and therefore it shouldn't crash until the game is run. So... 1) Pause Game 2) Send Cheats 3) Switch to memview tab and see if you can read memory. If you can, then the game didn't crash yet. Quote Using the code as GCT works :eek: You mean via SD cheats?EDIT: Other things to try. 1) Set a breakpoint on the instruction just before the 04 code's target. i.e. 801E8B24 2) While at the breakpoint, send cheats. 3) While still at the breakpoint go to disasm tab and see if the target was changed You can also try the same thing, but instead set the breakpoint on the blr (801E8BD8) instead of the instruction before the target address. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:55:25 PM Pausing the game before sending crashed aswell. Did it crash before or after you unpaused? The game should not be running while it's paused, and therefore it shouldn't crash until the game is run. So... 1) Pause Game 2) Send Cheats 3) Switch to memview tab and see if you can read memory. If you can, then the game didn't crash yet. Quote Using the code as GCT works :eek: You mean via SD cheats?I paused the game. Sent the code. (I can now still view memory) Unpaused, game was crashed. (gecko.net froze up) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 09:57:27 PM Did you switch to memview after sending the code and before unpausing? Did memview work while paused after sending codes?
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 09:58:15 PM Did you switch to memview after sending the code and before unpausing? Did memview work while paused after sending codes? yes, I could still view memory before unpausing.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 10:00:39 PM Try this, too.
1) pause game 2) send cheats 3) go to disasm tab @ 801E8B28 4) is it 40800020 or 48000020? 5) Poke it while paused 6) unpause Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 10:02:30 PM Try this, too. 1) pause game 2) send cheats 3) go to disasm tab @ 801E8B28 4) is it 40800020 or 48000020? 5) Poke it while paused 6) unpause 4) it´s the new value (the value that got written) 5) which value? Wouldn´t it be overwritten by the 04 code? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 10:05:18 PM 5) I would use the hack value (48000020). If you're on disasm tab, just press "assemble" and it will poke it with the current instruction.
Yes, it will be over-written by the 04 code... *at the next frame*. After you send cheats, the codes are executed. If you then poke the address, it won't be over-written until the code handler runs at the next frame. So, for the current frame of the game, it will be the poked value. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 10:08:29 PM 5) I would use the hack value (48000020). If you're on disasm tab, just press "assemble" and it will poke it with the current instruction. yep, still crashes after pressing "run"Yes, it will be over-written by the 04 code... *at the next frame*. After you send cheats, the codes are executed. If you then poke the address, it won't be over-written until the code handler runs at the next frame. So, for the current frame of the game, it will be the poked value. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 10:10:42 PM This makes me doubt your claim that you're 100% sure poking works. Because you poked the address with the hacked branch and it still crashed.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 08, 2011, 10:14:28 PM This makes me doubt your claim that you're 100% sure poking works. Because you poked the address with the hacked branch and it still crashed. why did the "poked" hack then work for me?It´s not a joke! it must be something with gecko.net because it spits error exceptions after it crashed... as you may noticed, NONE of my tries to send this 04 (and once the C2) code did not freeze the game. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 08, 2011, 10:17:38 PM There's an addi counting something, and that count is used to determine whether to take the branch or not. Perhaps if you patch that branch in the middle of the count, something gets messed up.
You said the poked hack works, and then later after doing pause/send cheats/poked hack/unpause you say it doesn't work. I don't know what to make of it. Try the breakpoint stuff I suggested a few posts back. Other things to try. 1) Set a breakpoint on the instruction just before the 04 code's target. i.e. 801E8B24 2) While at the breakpoint, send cheats. 3) While still at the breakpoint go to disasm tab and see if the target was changed You can also try the same thing, but instead set the breakpoint on the blr (801E8BD8) instead of the instruction before the target address. EDIT: Gecko.NET will throw exceptions if the game crashes in a way that the debugger can't handle. The exceptions are Gecko.NET saying it lost communication with the game. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 09, 2011, 10:20:03 AM - paste context menu on search tab does not paste stuff (it does nothing)
- selecting multiple address and pressing "gct wizard" to add them all to a specific code does only add one of them to the list (one, where I rightclicked at) - can´t input values that have more digits than selected bits amount, for instance, if I want to have dec 100 as 8bit search, I can´t write it into the box and convert to hex (64). Since the dec amount is 3 digits and the hex amount only 2, it does not allow me to convert using gecko.net. Same for 9 digit dec that I want to search with 32bit. I know that I can use the calculator instead, but oh well it´s extra efford. Btw. the 04 freeze issue seemed to be a problem with my computer, it was fixed after restarting it ._. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 09, 2011, 07:26:34 PM Yeah the paste from the context menu is bootleg like I said before. Can it just do the same paste that ctrl+v does? it really is a different function. Lets say the address box it at 80C55470 and I have some 0214CCFE 00008768 and I want to see what's going on in 8014CCFE. I would copy 14CCFE from anywhere highlight C55470 and expect to get 8014CCFE when I paste. But that only happens when I ctrl+v. If I right click and paste, it overwrites the entire textbox. so I get 14CCFE in a red box that I can't update to because it's an incomplete address. The "convert to"s from the context menu don't work for me either. I think that's just me though cuz Bully seems to be using them....
The load search problem I was able to find a good "when it happens". It gives me an exception error if I load with no previous search, probably because it's trying to fill in rows that don't exist. It gets stuck at "Loading columns..." and then I get exception error, quit/continue. If I do a real quick search for anything and cancel or whatever just to have a few boxes, then my searches work properly. I'll try to see what happens if I load a search with more results than the current results. ...it randomly disconnects? Yeah. I found this (http://wiird.l0nk.org/forum/index.php/topic,7909.0.html) and then this (http://wiird.l0nk.org/forum/index.php/topic,8125.0.html) browsing through some threads. Not for a solution to this. It was just there. It sounds a lot like strakn's problem. I bought a usb gecko SE like him. It was like that at first with the difficulty connecting, but then that fixed like my pc started geting along with the gecko. Now it just disconnects out of nowhere, sometimes it feels like a "inactive so I'll d/c" function, but sometimes I'm actively searching and then everything turns to 00s and I'm greeted with that "USB gecko not found" dialog box. And the solution would be to disconnect and reconnect it and THEN "click connect to gecko". It's tolerable but it does get very annoying sometimes. I don't think I had these disconnects with wiird, though. I'll try with wiird and I'll also look for that log and post it here.When you experience a random disconnection, close Gecko.NET, go look in the ./Logs/ folder for a file called GDNDebug [date/time].log. This is a record of all the exceptions that have been caught. See if there's an exception that correlates with your random disconnect. All entries in the log are date/timestamped as well, so if you do it immediately after the random event it should be the last thing in the log with a very recent timestamp. Another weird issue that I think might just be monster hunter...I'm scared of loading with the gecko connected. If the game has to load anything, quest, city, area, just about anything that makes that "now Loading" pop up, if the gecko is connected the game just freezes. Sometimes it doesn't, but it freezes more often than not. And there's nothing gecko.net can do to save it. I have to disconnect the gecko before I go do any kind of loading. I haven't tried to hack any other games, so it might just be a MH3 thing... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 09, 2011, 07:37:37 PM re: paste, I'll look into this.
re: convert to's...that's odd, they should be working. I fixed the ASCII conversions. Can you give an example conversion? re: load search problem, I'll take a look at this. re: random disconnects...the only thing I can think of is that your USB cord is flakey. =( re: "now loading"...that's quite weird. I can't explain it. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 09, 2011, 08:23:57 PM re: paste, I'll look into this. re: convert to's...that's odd, they should be working. I fixed the ASCII conversions. Can you give an example conversion? re: load search problem, I'll take a look at this. re: random disconnects...the only thing I can think of is that your USB cord is flakey. =( re: "now loading"...that's quite weird. I can't explain it. re: "now loading" remember dcx2? One of the previous gecko.net versions had this loading bug I also experienced (froze the game) I guess it was the one where you included the tx patches. It´s fixed now, I think. Not all of these conversions work fine. The hex to float function is swapped with the float to hex function I can remember. I´m not quite sure, but the ascii search in memory viewer didn´t find results last time I tried. It´s probably because the memory viewer got messed up in one built? The gct tab caculations take up to 5 seconds when the codeslist is huge :/ are they really needed? it´s extra waiting time :-X Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 09, 2011, 08:29:53 PM Not sure about this 'now loading' thing. If you aren't doing anything in Gecko.NET it shouldn't cause problems...
I'll double check the conversion functions but I thought they worked. I remember using them. Perhaps you're thinking of them backwards? What you have in the box comes first, what you want from the box comes last. 3F800000 -> hex to float -> 1.0 Pretty sure ASCII memview search works. If you can give me an example on some game I have that would be best. The GCT tab slow down should only happen the first time a new wgc is loaded. It shouldn't take a long time after that. I might look into finding some way to speed it up, but the other things are more important. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 09, 2011, 08:40:19 PM 2)The conversions are working now that I want to reproduce the bug >.>. Forget it. I'll post when it doesn't work again. It usually does nothing when I want to use it.
3)it only happens if the are no results. It works fine if you have 13 results and load a search with 800 results. If you restart search is included in the when it happens. If I continue after the exception error, this happens to the results: (http://dl.dropbox.com/u/24514984/loadderp.png) You can actually go into memview and still see the right address. But that doesn't mean that bootlegness is ok. lol4)I'll try the wire I use for my ps3 controller. But the usb gecko is still fairly new and the it's been like that since it was out of the box(I don't remember if it came in a box though. I'm just saying). I would've blamed the extension cord I bought and the front usb hub. I know the front hub is a little messed up. It's old and it gets everything plugged in and out of it so tapping whatever is connected to it is enough to disconnect and reconnect it. But I've put it in the back ports where I usually have my speakers 3TB and nothing. I moved the wii to the computer to use only the wire that it came with in those ports. And it still happens. But I'll try a different wire.... 8/9/2011 4:44:39 PM: Opened log The light did turn off. It's probably the wire.4:44:39 PM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDICommandSendError 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: 5)I think it has to do with auto-update. I always have that on. But while it's on, I notice the game slows down a bit, so maybe auto-update causes the game to freeze when it goes into loading because it's loading too slow? There wouldn't be much you can do then... I'll try unchecking auto update when I load instead of disconnecting.It didn't freeze with auto update off. It's most likely that auto update causes some lag or something. idk. Make it send only the visible addresses since you can't really see more addresses when you expand anyway. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 09, 2011, 08:50:34 PM 3) err....AJ is not a valid search value. The search value must always be in hex.
You say it happens when there are no results. Does that mean if you load Gecko.NET and immediately try to load a search it fails? Or do you have to do a search which returns no results? When you get no results, a dialog automatically pops up asking if you want to undo...what do you say? 4) The cord is just a stab in the dark. If you hear Windows ding like you just disconnected and connected something to USB, it makes me think it's the cord. I don't use a USB Gecko SE, so I'm not sure what the LED is supposed to do. 5) auto-update will constantly stream data from the Wii. It's like spam-clicking the Update button. The game will slow down because it's pushing so much data out of the USB Gecko. I would definitely turn auto-update on only when you're interested in seeing values change in real-time. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 09, 2011, 09:02:13 PM 3)Yeah. If you load gecko.net and load a search, it fails. If you restart search and load a search it fails. To load a search, there just has to be results on that window. I'll undo a 0 result search now. The AJ was just there cuz I was looking at what Bully was saying about not being about to put more than X digits in the box to convert them to hex or whatever. And then I got sidetracked and wondered what would happen if I did a ascii search. It would've be awesome if it found AJ. The results of that search was everything that was 000A, in case you wanted to know.
If you successfully load a search and try to load a search, it successfully loads. If you undo you a search you can load a search. If you click no and load a search it fails. If start a new search for STUF and can't find it, you can't undo so loading a search is gonna fail. A new bug. If you load a search and refine, get no results and try to say yes to undo, you can't undo. 4)hmm. I always have my speakers off. XD. I'll turn them on to see if it does the disconnect sound. 5)Yeah but sometimes I want to see what's going on during loading. You can see things happening in addresses you normally use for certain stats while it's loading. Look at the last post, I was trying to edit it before anyone responded. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 09, 2011, 09:10:50 PM 3) Finding all 000A's is what I would expect it to do. It strips out illegal characters before searching.
5) Yeah, it is nice to see what's happening during a load. I haven't seen it happen anywhere myself, though. At least you figured out what was causing it, though Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 09, 2011, 09:18:45 PM lol. Again I edited my post too late.
5)Yeah I guess it's good to know I don't have to disconnect, but it's still inconvenient. Especially if your not even in the memview tab. Make an option to uncheck auto update if your not in the memview tab. And another to auto-check it when you switch to it. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 09, 2011, 09:22:27 PM 3) Thanks for all the effort you put into finding a pattern to reproduce the behavior. It is invaluable for me.
5) I agree it's inconvenient, but without a way to reproduce this behavior, there's not much I can do. However, I'm surprised that it's still pulling auto-updates even when you aren't in the MemView tab. It should be pretty easy to make auto-update only pull data when you're in MemView. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 10, 2011, 04:58:52 AM 3) Anytime. You've been very helpful since I got my gecko. The least I can do is find bugs for you to fix. >.>
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 10, 2011, 10:38:04 AM 5) I agree it's inconvenient, but without a way to reproduce this behavior, there's not much I can do. However, I'm surprised that it's still pulling auto-updates even when you aren't in the MemView tab. It should be pretty easy to make auto-update only pull data when you're in MemView. yeah it does, but it doesn´t always switch, when auto-update is checked.It also slows down the applications´ buttons around it. On WiiRd you could not switch tabs while it´s ticked. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 10, 2011, 02:35:00 PM I think I know what you mean...the first click after enabling auto-update is lost. I'm not sure why. Anyway, I'll still make it so auto-update "goes to sleep" when you leave that tab.
I'm also considering something that might allow you to do things like memdumps while waiting for breakpoints, and perhaps even auto-switching to the BP tab when a breakpoint happens. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 10, 2011, 09:44:15 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 10, 2011, 09:46:10 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: goemon_guy on August 10, 2011, 11:10:48 PM 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.) Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 10, 2011, 11:25:32 PM switching tabs while waiting on a breakpoint is a good idea but it won't be easy and it might be unreliable... or maybe tabs switching while gecko.net dumps memory.As far as a dual-mem search, that would require a great deal of under-the-hood changes, so probably not. That wasn´t possible, yet. Managing codes on gct tab, while it dumps would be great. Title: Re: Gecko dotNET Bugs and Requests Post by: Skiller on August 12, 2011, 01:19:18 AM 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 .. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 12, 2011, 01:30:29 AM Right click the
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 12, 2011, 06:35:18 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 12, 2011, 07:05:51 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 12, 2011, 08:11:08 PM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 12, 2011, 08:34:36 PM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 12, 2011, 09:29:44 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 12, 2011, 09:36:05 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 12, 2011, 10:45:23 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 13, 2011, 04:00:42 PM 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... 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 EDIT: corrected Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 13, 2011, 07:03:00 PM 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". Title: Re: Gecko dotNET Bugs and Requests Post by: standardtoaster on August 13, 2011, 08:21:31 PM I'm not sure if this has been posted yet, but I noticed that if you switch to the MemView in Gecko.NET without changing the address it only shows 80000000 00010203 04050607 08090A0B 0C0D0E0F.
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 13, 2011, 08:42:47 PM Interesting. I'll go try and freeze the game with auto-update and see this workaround in action.
I'm not sure if this has been posted yet, but I noticed that if you switch to the MemView in Gecko.NET without changing the address it only shows 80000000 00010203 04050607 08090A0B 0C0D0E0F. You have to connect your gecko first XD. That's the column headers.Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 13, 2011, 09:40:20 PM Oh wow. That is actually mega helpful. yes, it was a mem90 address lol Do you remember what memory range you were trying to dump? Was it something like 9014AB__? You´re right... :P --- Here´s a code sending freeze issue: If I send any code *before* pressing A on the main screen of Yugioh 5D´s Duel Transer, it freezes up when one presses A to start. I tried to use the same codes with gct, worked fine. Sending the code(s) *after* pressing A on title screen, worked fine. It´s therefore definetely not a code fail. Take a look at the crash function (note that this address always pops up, doesn´t matter through which code it froze) CR:28222488 XER:20000000 CTR:809CAD8C DSIS:04000000 DAR:0000138D SRR0:809CB1B4 SRR1:00009032 LR:809CA52C r0:00000005 r1:806A9670 r2:8069FA40 r3:80AA5484 r4:FFFFFFFF r5:8059CD00 r6:91937AAC r7:00000000 r8:00000000 r9:00000000 r10:00000000 r11:FFFFFFFF r12:809CAD8C r13:8069E5C0 r14:00000000 r15:00000000 r16:00000000 r17:00000000 r18:00000000 r19:80590000 r20:805A0000 r21:805A0000 r22:80570000 r23:805712B8 r24:80570000 r25:805A0000 r26:805A0000 r27:805A0000 r28:8059C940 r29:00000001 r30:81213CE0 r31:00000001 809CAD8C: 9421FFD0 stwu r1,-48(r1) 809CAD90: 7C0802A6 mflr r0 809CAD94: 90010034 stw r0,52(r1) 809CAD98: 93E1002C stw r31,44(r1) 809CAD9C: 93C10028 stw r30,40(r1) 809CADA0: 7C7E1B78 mr r30,r3 809CADA4: 93A10024 stw r29,36(r1) 809CADA8: 80C30064 lwz r6,100(r3) 809CADAC: 80060010 lwz r0,16(r6) 809CADB0: 2C000000 cmpwi r0,0 809CADB4: 41820038 beq- 0x809cadec 809CADB8: 2C000001 cmpwi r0,1 809CADBC: 41820124 beq- 0x809caee0 809CADC0: 2C000002 cmpwi r0,2 809CADC4: 418201A8 beq- 0x809caf6c 809CADC8: 2C000003 cmpwi r0,3 809CADCC: 4182027C beq- 0x809cb048 809CADD0: 2C000004 cmpwi r0,4 809CADD4: 418202F0 beq- 0x809cb0c4 809CADD8: 2C000005 cmpwi r0,5 809CADDC: 418203C8 beq- 0x809cb1a4 809CADE0: 2C000006 cmpwi r0,6 809CADE4: 41820460 beq- 0x809cb244 809CADE8: 4800054C b 0x809cb334 809CADEC: 4B6789CD bl 0x800437b8 809CADF0: 809E00B8 lwz r4,184(r30) 809CADF4: 4B676939 bl 0x8004172c 809CADF8: 38800000 li r4,0 809CADFC: 4B6759CD bl 0x800407c8 809CAE00: 880300BB lbz r0,187(r3) 809CAE04: 3FE080AA lis r31,-32598 809CAE08: 3BFF53D0 addi r31,r31,21456 809CAE0C: 3880FFFF li r4,-1 809CAE10: 5400063C rlwinm r0,r0,0,24,30 809CAE14: 60000001 ori r0,r0,1 809CAE18: 980300BB stb r0,187(r3) 809CAE1C: 387F0091 addi r3,r31,145 809CAE20: 4B66CD95 bl 0x80037bb4 809CAE24: 7C7D1B78 mr r29,r3 809CAE28: 807E006C lwz r3,108(r30) 809CAE2C: 809E00B8 lwz r4,184(r30) 809CAE30: 4B6768FD bl 0x8004172c 809CAE34: 7FA4EB78 mr r4,r29 809CAE38: 38A00001 li r5,1 809CAE3C: 4B675401 bl 0x8004023c 809CAE40: 387F0091 addi r3,r31,145 809CAE44: 3880FFFF li r4,-1 809CAE48: 4B66CD6D bl 0x80037bb4 809CAE4C: 7C7D1B78 mr r29,r3 809CAE50: 807E006C lwz r3,108(r30) 809CAE54: 809E00B8 lwz r4,184(r30) 809CAE58: 4B6768D5 bl 0x8004172c 809CAE5C: 3CA080AA lis r5,-32598 809CAE60: 7FA4EB78 mr r4,r29 809CAE64: C0255358 lfs f1,21336(r5) 809CAE68: 4B6757FD bl 0x80040664 809CAE6C: 3FE08059 lis r31,-32679 809CAE70: 38800001 li r4,1 809CAE74: 3BFF4CE0 addi r31,r31,19680 809CAE78: 38A00000 li r5,0 809CAE7C: 387F5154 addi r3,r31,20820 809CAE80: 4B680F39 bl 0x8004bdb8 809CAE84: 80BF5174 lwz r5,20852(r31) 809CAE88: 3C808889 lis r4,-30583 809CAE8C: 3C004330 lis r0,17200 809CAE90: 90010018 stw r0,24(r1) 809CAE94: 1CA50384 mulli r5,r5,900 809CAE98: 38848889 subi r4,r4,30583 809CAE9C: 3C6080AA lis r3,-32598 809CAEA0: C8235360 lfd f1,21344(r3) 809CAEA4: 38000001 li r0,1 809CAEA8: 7C842896 mulhw r4,r4,r5 809CAEAC: 807E0064 lwz r3,100(r30) 809CAEB0: 7C842A14 add r4,r4,r5 809CAEB4: 7C842E70 srawi r4,r4,5 809CAEB8: 54850FFE rlwinm r5,r4,1,31,31 809CAEBC: 7C842A14 add r4,r4,r5 809CAEC0: 6C848000 xoris r4,r4,32768 809CAEC4: 9081001C stw r4,28(r1) 809CAEC8: C8010018 lfd f0,24(r1) 809CAECC: EC000828 fsubs f0,f0,f1 809CAED0: D0030014 stfs f0,20(r3) 809CAED4: 807E0064 lwz r3,100(r30) 809CAED8: 90030010 stw r0,16(r3) 809CAEDC: 48000458 b 0x809cb334 809CAEE0: 3FE08059 lis r31,-32679 809CAEE4: 3BFF4CE0 addi r31,r31,19680 809CAEE8: 801F5158 lwz r0,20824(r31) 809CAEEC: 540007BD rlwinm. r0,r0,0,30,30 809CAEF0: 40820444 bne- 0x809cb334 809CAEF4: 3C6080AA lis r3,-32598 809CAEF8: 3880FFFF li r4,-1 809CAEFC: 386353D0 addi r3,r3,21456 809CAF00: 38630091 addi r3,r3,145 809CAF04: 4B66CCB1 bl 0x80037bb4 809CAF08: 7C7D1B78 mr r29,r3 809CAF0C: 807E006C lwz r3,108(r30) 809CAF10: 809E00B8 lwz r4,184(r30) 809CAF14: 4B676819 bl 0x8004172c 809CAF18: 3CA080AA lis r5,-32598 809CAF1C: 7FA4EB78 mr r4,r29 809CAF20: C025535C lfs f1,21340(r5) 809CAF24: 4B675741 bl 0x80040664 809CAF28: 801F5174 lwz r0,20852(r31) 809CAF2C: 3C608889 lis r3,-30583 809CAF30: 38838889 subi r4,r3,30583 809CAF34: 38A00000 li r5,0 809CAF38: 1C00001E mulli r0,r0,30 809CAF3C: 38600000 li r3,0 809CAF40: 38C00000 li r6,0 809CAF44: 7C840096 mulhw r4,r4,r0 809CAF48: 7C040214 add r0,r4,r0 809CAF4C: 7C002E70 srawi r0,r0,5 809CAF50: 54040FFE rlwinm r4,r0,1,31,31 809CAF54: 7C802214 add r4,r0,r4 809CAF58: 4B6AC0F5 bl 0x8007704c 809CAF5C: 807E0064 lwz r3,100(r30) 809CAF60: 38000002 li r0,2 809CAF64: 90030010 stw r0,16(r3) 809CAF68: 480003CC b 0x809cb334 809CAF6C: 3FE080AA lis r31,-32598 809CAF70: 3880FFFF li r4,-1 809CAF74: 3BFF53D0 addi r31,r31,21456 809CAF78: 387F0091 addi r3,r31,145 809CAF7C: 4B66CC39 bl 0x80037bb4 809CAF80: 7C7D1B78 mr r29,r3 809CAF84: 807E006C lwz r3,108(r30) 809CAF88: 809E00B8 lwz r4,184(r30) 809CAF8C: 4B6767A1 bl 0x8004172c 809CAF90: 7FA4EB78 mr r4,r29 809CAF94: 4B6753AD bl 0x80040340 809CAF98: 2C030000 cmpwi r3,0 809CAF9C: 41820398 beq- 0x809cb334 809CAFA0: 387F009D addi r3,r31,157 809CAFA4: 3880FFFF li r4,-1 809CAFA8: 4B66CC0D bl 0x80037bb4 809CAFAC: 7C7D1B78 mr r29,r3 809CAFB0: 807E006C lwz r3,108(r30) 809CAFB4: 809E00B8 lwz r4,184(r30) 809CAFB8: 4B676775 bl 0x8004172c 809CAFBC: 7FA4EB78 mr r4,r29 809CAFC0: 38A00001 li r5,1 809CAFC4: 4B675279 bl 0x8004023c 809CAFC8: 4B6787F1 bl 0x800437b8 809CAFCC: 809E00B0 lwz r4,176(r30) 809CAFD0: 4B67675D bl 0x8004172c 809CAFD4: 38800000 li r4,0 809CAFD8: 4B6757F1 bl 0x800407c8 809CAFDC: 880300BB lbz r0,187(r3) 809CAFE0: 3880FFFF li r4,-1 809CAFE4: 5400063C rlwinm r0,r0,0,24,30 809CAFE8: 60000001 ori r0,r0,1 809CAFEC: 980300BB stb r0,187(r3) 809CAFF0: 387F0091 addi r3,r31,145 809CAFF4: 4B66CBC1 bl 0x80037bb4 809CAFF8: 7C7D1B78 mr r29,r3 809CAFFC: 807E006C lwz r3,108(r30) 809CB000: 809E00B0 lwz r4,176(r30) 809CB004: 4B676729 bl 0x8004172c 809CB008: 7FA4EB78 mr r4,r29 809CB00C: 38A00001 li r5,1 809CB010: 4B67522D bl 0x8004023c 809CB014: 807E006C lwz r3,108(r30) 809CB018: 809E00B0 lwz r4,176(r30) 809CB01C: 4B676711 bl 0x8004172c 809CB020: 38800000 li r4,0 809CB024: 4B6757A5 bl 0x800407c8 809CB028: 888300BB lbz r4,187(r3) 809CB02C: 38000003 li r0,3 809CB030: 5484063C rlwinm r4,r4,0,24,30 809CB034: 60840001 ori r4,r4,1 809CB038: 988300BB stb r4,187(r3) 809CB03C: 807E0064 lwz r3,100(r30) 809CB040: 90030010 stw r0,16(r3) 809CB044: 480002F0 b 0x809cb334 809CB048: 3FE080AA lis r31,-32598 809CB04C: 3880FFFF li r4,-1 809CB050: 3BFF53D0 addi r31,r31,21456 809CB054: 387F0091 addi r3,r31,145 809CB058: 4B66CB5D bl 0x80037bb4 809CB05C: 7C7D1B78 mr r29,r3 809CB060: 807E006C lwz r3,108(r30) 809CB064: 809E00B0 lwz r4,176(r30) 809CB068: 4B6766C5 bl 0x8004172c 809CB06C: 7FA4EB78 mr r4,r29 809CB070: 4B6752D1 bl 0x80040340 809CB074: 2C030000 cmpwi r3,0 809CB078: 418202BC beq- 0x809cb334 809CB07C: 387F00A9 addi r3,r31,169 809CB080: 3880FFFF li r4,-1 809CB084: 4B66CB31 bl 0x80037bb4 809CB088: 7C7D1B78 mr r29,r3 809CB08C: 807E006C lwz r3,108(r30) 809CB090: 809E00B0 lwz r4,176(r30) 809CB094: 4B676699 bl 0x8004172c 809CB098: 7FA4EB78 mr r4,r29 809CB09C: 38A00001 li r5,1 809CB0A0: 4B67519D bl 0x8004023c 809CB0A4: 3C608059 lis r3,-32679 809CB0A8: 38800001 li r4,1 809CB0AC: 386344B8 addi r3,r3,17592 809CB0B0: 38000004 li r0,4 809CB0B4: 90830514 stw r4,1300(r3) 809CB0B8: 807E0064 lwz r3,100(r30) 809CB0BC: 90030010 stw r0,16(r3) 809CB0C0: 48000274 b 0x809cb334 809CB0C4: 3C8080AA lis r4,-32598 809CB0C8: 3FE08059 lis r31,-32679 809CB0CC: C004535C lfs f0,21340(r4) 809CB0D0: 387F44B8 addi r3,r31,17592 809CB0D4: C0260014 lfs f1,20(r6) 809CB0D8: 38800007 li r4,7 809CB0DC: 38A00000 li r5,0 809CB0E0: EC010028 fsubs f0,f1,f0 809CB0E4: D0060014 stfs f0,20(r6) 809CB0E8: 4B6688B9 bl 0x800339a0 809CB0EC: 2C030000 cmpwi r3,0 809CB0F0: 41820050 beq- 0x809cb140 809CB0F4: 3C6080AA lis r3,-32598 809CB0F8: 3880FFFF li r4,-1 809CB0FC: 386353D0 addi r3,r3,21456 809CB100: 386300B4 addi r3,r3,180 809CB104: 4B66CAB1 bl 0x80037bb4 809CB108: 7C7D1B78 mr r29,r3 809CB10C: 807E006C lwz r3,108(r30) 809CB110: 809E00B0 lwz r4,176(r30) 809CB114: 4B676619 bl 0x8004172c 809CB118: 7FA4EB78 mr r4,r29 809CB11C: 38A00001 li r5,1 809CB120: 4B67511D bl 0x8004023c 809CB124: 3860001B li r3,27 809CB128: 38800000 li r4,0 809CB12C: 4B6AC06D bl 0x80077198 809CB130: 807E0064 lwz r3,100(r30) 809CB134: 38000005 li r0,5 809CB138: 90030010 stw r0,16(r3) 809CB13C: 480001F8 b 0x809cb334 809CB140: 809E0064 lwz r4,100(r30) 809CB144: 3C6080AA lis r3,-32598 809CB148: C0035358 lfs f0,21336(r3) 809CB14C: C0240014 lfs f1,20(r4) 809CB150: FC010040 fcmpo cr0,f1,f0 809CB154: 408001E0 bge- 0x809cb334 809CB158: 3C608059 lis r3,-32679 809CB15C: 38800001 li r4,1 809CB160: 38634CE0 addi r3,r3,19680 809CB164: 38A00000 li r5,0 809CB168: 38635154 addi r3,r3,20820 809CB16C: 4B680CBD bl 0x8004be28 809CB170: 3860001E li r3,30 809CB174: 4B6ABE95 bl 0x80077008 809CB178: 807E0064 lwz r3,100(r30) 809CB17C: 38800006 li r4,6 809CB180: 38DF44B8 addi r6,r31,17592 809CB184: 38000000 li r0,0 809CB188: 90830010 stw r4,16(r3) 809CB18C: 7FC3F378 mr r3,r30 809CB190: 38800003 li r4,3 809CB194: 38A00028 li r5,40 809CB198: 90060514 stw r0,1300(r6) 809CB19C: 4BFF85C1 bl 0x809c375c 809CB1A0: 48000194 b 0x809cb334 809CB1A4: 3C6080AA lis r3,-32598 809CB1A8: 3880FFFF li r4,-1 809CB1AC: 386353D0 addi r3,r3,21456 809CB1B0: 386300B4 addi r3,r3,180 809CB1B4: 807F138C lwz r3,5004(r31) 809CB1B8: 7C7D1B78 mr r29,r3 809CB1BC: 807E006C lwz r3,108(r30) 809CB1C0: 809E00B0 lwz r4,176(r30) 809CB1C4: 4B676569 bl 0x8004172c 809CB1C8: 7FA4EB78 mr r4,r29 809CB1CC: 4B675175 bl 0x80040340 809CB1D0: 2C030000 cmpwi r3,0 809CB1D4: 41820160 beq- 0x809cb334 809CB1D8: 807E006C lwz r3,108(r30) 809CB1DC: 809E00B0 lwz r4,176(r30) 809CB1E0: 4B67654D bl 0x8004172c 809CB1E4: 38800000 li r4,0 809CB1E8: 38A00001 li r5,1 809CB1EC: 4B675051 bl 0x8004023c 809CB1F0: 807E006C lwz r3,108(r30) 809CB1F4: 809E00B0 lwz r4,176(r30) 809CB1F8: 4B676535 bl 0x8004172c 809CB1FC: 38800000 li r4,0 809CB200: 4B6755C9 bl 0x800407c8 809CB204: 880300BB lbz r0,187(r3) 809CB208: 3CA08059 lis r5,-32679 809CB20C: 38A54CE0 addi r5,r5,19680 809CB210: 38800001 li r4,1 809CB214: 5400063C rlwinm r0,r0,0,24,30 809CB218: 980300BB stb r0,187(r3) 809CB21C: 38655154 addi r3,r5,20820 809CB220: 38A00000 li r5,0 809CB224: 4B680C05 bl 0x8004be28 809CB228: 80BE0064 lwz r5,100(r30) 809CB22C: 38000006 li r0,6 809CB230: 7FC3F378 mr r3,r30 809CB234: 38800017 li r4,23 809CB238: 90050010 stw r0,16(r5) 809CB23C: 4BFF8519 bl 0x809c3754 809CB240: 480000F4 b 0x809cb334 809CB244: 3C608059 lis r3,-32679 809CB248: 38634CE0 addi r3,r3,19680 809CB24C: 80035158 lwz r0,20824(r3) 809CB250: 540007BD rlwinm. r0,r0,0,30,30 809CB254: 408200E0 bne- 0x809cb334 809CB258: 4B678561 bl 0x800437b8 809CB25C: 809E00B8 lwz r4,184(r30) 809CB260: 4B6764CD bl 0x8004172c 809CB264: 38800000 li r4,0 809CB268: 4B675561 bl 0x800407c8 809CB26C: 880300BB lbz r0,187(r3) 809CB270: 5400063C rlwinm r0,r0,0,24,30 809CB274: 980300BB stb r0,187(r3) 809CB278: 4B678541 bl 0x800437b8 809CB27C: 809E00B0 lwz r4,176(r30) 809CB280: 4B6764AD bl 0x8004172c 809CB284: 38800000 li r4,0 809CB288: 4B675541 bl 0x800407c8 809CB28C: 880300BB lbz r0,187(r3) 809CB290: 3C8080AA lis r4,-32598 809CB294: C0045358 lfs f0,21336(r4) 809CB298: 3BE00000 li r31,0 809CB29C: 5400063C rlwinm r0,r0,0,24,30 809CB2A0: 980300BB stb r0,187(r3) 809CB2A4: 3CE080AC lis r7,-32596 809CB2A8: 387E0030 addi r3,r30,48 809CB2AC: 80BE0064 lwz r5,100(r30) 809CB2B0: 38810008 addi r4,r1,8 809CB2B4: 93E50010 stw r31,16(r5) 809CB2B8: 80BE0064 lwz r5,100(r30) 809CB2BC: D0050014 stfs f0,20(r5) 809CB2C0: 84C7EE34 lwzu r6,-4556(r7) 809CB2C4: 90C10008 stw r6,8(r1) 809CB2C8: 80A70004 lwz r5,4(r7) 809CB2CC: 80070008 lwz r0,8(r7) 809CB2D0: 90A1000C stw r5,12(r1) 809CB2D4: 90010010 stw r0,16(r1) 809CB2D8: 480004AD bl 0x809cb784 809CB2DC: 801E0040 lwz r0,64(r30) 809CB2E0: 3CA08050 lis r5,-32688 809CB2E4: 811E0044 lwz r8,68(r30) 809CB2E8: 80FE0048 lwz r7,72(r30) 809CB2EC: 80DE004C lwz r6,76(r30) 809CB2F0: 809E0050 lwz r4,80(r30) 809CB2F4: 807E0054 lwz r3,84(r30) 809CB2F8: 901E0058 stw r0,88(r30) 809CB2FC: 801E0068 lwz r0,104(r30) 809CB300: 911E005C stw r8,92(r30) 809CB304: 90FE0060 stw r7,96(r30) 809CB308: 90DE0040 stw r6,64(r30) 809CB30C: 909E0044 stw r4,68(r30) 809CB310: 907E0048 stw r3,72(r30) 809CB314: 8485DF10 lwzu r4,-8432(r5) 809CB318: 80650004 lwz r3,4(r5) 809CB31C: 907E0050 stw r3,80(r30) 809CB320: 909E004C stw r4,76(r30) 809CB324: 80650008 lwz r3,8(r5) 809CB328: 907E0054 stw r3,84(r30) 809CB32C: 901E0064 stw r0,100(r30) 809CB330: 93FE0068 stw r31,104(r30) 809CB334: 80010034 lwz r0,52(r1) 809CB338: 83E1002C lwz r31,44(r1) 809CB33C: 83C10028 lwz r30,40(r1) 809CB340: 83A10024 lwz r29,36(r1) 809CB344: 7C0803A6 mtlr r0 809CB348: 38210030 addi r1,r1,48 809CB34C: 4E800020 blr It´s not the only game, where sending legit codes crashes. You may messed something up, as you fixed the C2/C0 codessending? It only occures on the current gecko.net. That´s my guess, what´s wrong with it. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 13, 2011, 10:26:51 PM Are you using any GCT Code Undo lines?
Does it happen if send codes with none of the checkboxes enabled? You're positive it worked in 0.66.5 and fails in 0.66.6? Can you name other games where this happens? I'm assuming you're using cfg usb = 1931 handler. That crash isn't happening in the code handler. Something is screwing up the game. If you have no codes enabled, and you delete all the GCT Code Undo lines, then it should do nothing. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 13, 2011, 10:56:41 PM Are you using any GCT Code Undo lines? # no Does it happen if send codes with none of the checkboxes enabled? # idk yet... You're positive it worked in 0.66.5 and fails in 0.66.6? # it at least worked with very old builts like rev93 (and 0.66.5 I think) Can you name other games where this happens? # yes, it happens on e.g. black ops, when sending a button activated code that wasn´t enabled yet (= button not pressed) -> game crashed I'm assuming you're using cfg usb = 1931 handler. # correct That crash isn't happening in the code handler. Something is screwing up the game. If you have no codes enabled, and you delete all the GCT Code Undo lines, then it should do nothing. # any code screws it up, same crash bp each time Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 14, 2011, 02:46:04 AM idk if this is a bug, or maybe I'm doing it wrong. I set a XBP at the start of some asm function because that's what the write breakpoint took me to. (Looking for monster awareness). write bp on 9014BD7C takes you to 80130788 and a XBP on 80130788 takes you to 80130788. >.>. Maybe I'm doing it wrong.
Does it happen if send codes with none of the checkboxes enabled? Just sent codes with no codes on my list. didn't freeze. Now that I wanted the game to freeze, it doesn't >.>. I left on 5 quests. It usually freezes on one of the 1st 2. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 14, 2011, 04:35:27 PM Code search bug:
Searching in range 90 is not possible.... If you change 80 to 90 is shows: Start: 90000000 End: 90000000 I've tried to change the End: 90000000 to 91000000 but it's still red. If you start search, it shows all address with the value 00000000 http://imageshack.us/photo/my-images/38/71133514.png/ BTW on the picture, I actually set "unknown value" and not specific.... Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 14, 2011, 04:59:50 PM Gecko.NET prevents you from accessing MEM2 in GameCube mode (which normally would cause a crash). Looks like it's accidentally protecting a channel, too? I'll load a channel to try it out.
Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 14, 2011, 05:00:41 PM It's the Mii channel. But I think there is no mem 90 :o
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 14, 2011, 09:56:40 PM I had no problem loading searches. I did the following.
1) load Super Mario Galaxy RMGE01 with Gecko OS 1931. 2) search for 32-bit not-equal to 0 3) search for not-equal to last search (1) 4) Save history as RMGE01.srh 5) Quit Gecko.NET and open a new instance 6) Load history RMGE01.srh 7) It takes a few seconds, but eventually it loads everything. XD. The history function is bootleg though. I know you've explained it like 3 times already, but sometimes, it's like, "wut?" How about this. Now you can double click an addresstextbox to save it in the history and see the whole history. You can scroll through them with up/down arrows, too.Quote 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. I've rearranged the memview tab to make some more room. I'll see what I can do about making a multiply/add offset control.write bp on 9014BD7C takes you to 80130788 and a XBP on 80130788 takes you to 80130788. >.>. Maybe I'm doing it wrong. That sounds correct. A Write BP is used to find the instruction which is writing to some memory address. Read BP is used to find some instruction which is reading from a memory address. There can be many different instructions that can read or write to one address, and this can be used to find all of them.An Execute BP is used to freeze the game when an instruction is executed. It will always freeze it on the same instruction, but it won't freeze it until the CPU executes that instruction. There can be many different memory addresses that are written to or read by a single instruction, and this can be used to find all of them. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 15, 2011, 01:20:00 AM hmm.. Might be a mh3 thing? XD. Guess it's not such a big deal. Searches do load if I have results open already. Nothing I can't live with.
Less bootleg history, I see. :Thumbs up: o.O. You made a lot of room. Have any other plans for all that space? Looks like moving "View" and "Source" wasn't even necessary. But I like the new spot. Oh. I thought XBP would take you to some other function that's about to execute that asm. I was hoping to find something else to nop. nop'ing the sth(I think it was) had the same effect a 00 code had, which wasn't what I wanted. But the sth was at the beginning of the function, and I was hoping to find something else that calls this function. Just used search in memview for the first time. It's awesome but is there a way to search backwards or make it loop back to the beginning? 2 things(There was 3, but I forgot the 3rd): 1) Does the exisendbyteAA protection take up addition code space? I just finished reducing my codelist to avoid crashes when I connect the gecko. And now I had to do that again. >.<. If so, how many lines does it occupy? And you get exception error when it freezes like this. Don't think I got that before. 2) After a few exception errors, I wasn't able to switch out of the search tab. It would instead highlight the data type dropdown. It was weird and retarded and I don't think I can reproduce this bug. I think the exception errors had to do with it because you can either quit or continue, and I kept continuing. But who knows. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 15, 2011, 01:44:13 AM re: search tab, you can make it dump a sliver (like 80000000 to 80001000) just to get something loaded without having to wait long.
re: history, the real slick thing is to use the arrow keys to "scroll" through the selected address history and watch memview update in real time. The disassembler history can also scroll through and update in real time. re: plans for space, I was thinking a sort of history snapshot memory sortof thing too. Maybe a search up option. Maybe make it loop. When it comes to memview search, you should also check out the Hex search mode. You can also shift-click a cell to add its contents to the hex search; very useful for porting codes between regions. re: finding callers, at a breakpoint go to disasm tab and double click call stack and you'll be able to navigate along...mostly. It gets a little glitchy in areas where the compiler might have gotten frisky. Also, you could ask your question in Wii Game Hacking Help. Hit the breakpoint, get a copy of the registers into a spoiler, and go to disasm on the breakpoint address and Copy Function that into a spoiler, maybe even a copy of the Call Stack too just in case, then tell me what it is you're trying to do, and what values you think are in what registers. re: exisendbyteAA crashing, I think what happened is that a) memview autoupdate asks for a dump b) Wii game starts loading something from disc just before it sees the dump request c) Wii game takes forever to load something from disc, ignoring dump request for a long time d) Gecko.NET thinks something went wrong and asks for another dump e) Code handler gets to run, sees "dump", gets ready for the address, and the second "dump" gets considered to be part of the address. Crash. So anything that would result in ignoring the code handler for a long time could cause a problem, with these timeouts. I could extend the timeout but sooner or later it could still be...bootleg. So I made sure to drain the input buffer of any commands before trying to receive the address. Yes, this patch takes up additional space. I think I may be off a line or two. Gecko OS 1931 has the smallest code handler I've seen, as well. But if you're running out of code space you should be using the extended code list. As per the following thread, make a RMHE08.gct file with the following code, and only this code; it must be applied as a gct with SD cheats. Then, when you connect to the game, you should get about 4,000 code lines or so instead of the measly 200-ish. It works on most games that it's been tested on so far. http://wiird.l0nk.org/forum/index.php/topic,8549.msg71139.html#msg71139 Y.S. Allocate Extended Codes F6000001 80008180 54030034 48000008 D2000000 00000007 54030034 3D8000D0 618CC0DE 91830000 91830004 3980FFFF 91830008 9183000C 38630008 3D808000 906C1848 38637FF8 60000000 00000000 E0000000 80008000 re: exception errors...."after a few"? You shouldn't be having any. What are you doing that generates exceptions? Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 15, 2011, 02:09:08 AM re: search, I can also cancel a search. I get a few pages of results no matter how fast I cancel.
re: memview search, yeah I checked it out cuz I noticed it was in hex mode by default now. That shift click is very nice. re: finding callers, alright. I'll do that and post in Wii Game Hacking Help. Just posted here cuz I thought it might've been a bug. re: extended code list, I didn't want to do that yet because then I have to switch gcts whenever I go from playing<->hacking. But I should give it a try. re: exception errors: I tried connecting the gecko with a full code list 3 or 4 times. Continuing each time. I got another exception error trying to load a search, and then after that I couldn't switch out of the tab. I can't imagine anything else that would cause that. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 15, 2011, 04:01:04 AM re: extended code list, technically you don't *have* to use a gct. If you pause-start the game, and then send cheats the Allocate Extended Codes, it should also work.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 15, 2011, 11:24:03 AM great new built, it fixed the gct slowdown, the exception if one tries to save codes when the games has crashes and so on :eek:
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 18, 2011, 04:06:55 AM Time for some bugs and requests.
bug: Only one I can think of atm, but this neeeeeds fixing. If you scroll down(+ to the memory address) in the memory viewer after going to a new address, the visible address jumps to -0x60 of what it was. example, I put 902437C0 into the address box to go there, the visible address is 90243750, but if I scroll down, it jumps to 902436F0 and THEN I can scroll down just fine. It's retarded and bugs me out when I suddenly can't see what I was looking at until I scroll down a bit more. If I scroll up it worse. using the same example, it would jump up to 902436D0. Not really a bug, it takes a while to start up. Is this why there's no more gct slowdown? >.< request: Get ready for ridiculousness....I want Gecko.net to be extremely keyboard friendly. kb shortcuts all day. Shift+left/right through the tabs, alt+some letter to go to that tab. But then the idea gets stupid after that. Mem view and search results can get in the way, and it's just not possible to replace the mouse. After you said the F buttons in calc.exe switch through the different modes, I was like "oh ma gawd. There's liek no more reason to use the mouse in calc.exe. Imagine alt-tabbin through open windows just kb shortcutin with the ctrl-C, alt-tab, ctrl-V, +B18, enter, ctrl-C'in. XD. But oh noes. Gecko.net can't switch between tabs :o" And here I am. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 18, 2011, 01:26:08 PM I'll take a look at the memview scrollbar thing.
I'm not sure why it would take a while to start up. If you hold shift when you launch the app, it will start up without connecting to the USB Gecko. My guess is that it's just a big app now and probably needs a splash screen to distract users while it's loading. ctrl+tab, ctrl+shift+tab will switch through the tabs already. =P but I've been thinking about adding keyboard shortcuts for other stuff. VS for instance uses F5 for run, and I think F11 for step into, shift+F11 for step out, F10 for step over. Pretty much every button in calc has a shortcut. Look at the help file for it. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 18, 2011, 10:36:58 PM same for me.
Pressing the scroll button at first, "teleports" to a different address (lower or higher) and from there, it keeps scrolling like normal. Like Stuff said, it´s bugging people a bit... Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 19, 2011, 01:09:59 AM I wish there's an option for disabling the "debugger" info.... It shows me this info all the time after I click start searching. Actually, I had never any problems without Y.S. code which you included in Gecko dNET (I think you included it!? ). Codes like the File Patch Code should be an gct file. I even don't know why you need more free space? How many codes do you want to activate? Also WiiRd debugger don't use this code. I dunno how many codes you're activating via the USB Gecko but I still think it's not necessary. I don't want to be rude, I just think it not necessary at all. May I failed and there's already an option for this. If yes, so sorry for that.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 19, 2011, 03:37:42 AM I don't understand what you mean by 'debugger info'. You say searching, so that makes me wonder if you're using a code handler that I don't patch (Gecko OS Mod, or some old USB loader). I think I have a message box that pops up when I can't patch the debugger. I'll move the notification to a label in the Tools tab instead.
--- Quote I dunno how many codes you're activating with via the USB Gecko but I still think it's not necessary. Unfortunately, I do think the debugger patches are necessary. Since the TX bug is particularly dangerous when doing searches, I make sure that the patches are there starting a search dump. The patches fix multiple known bugs. If you don't want the patches, don't use Gecko.NET. They are that important. Without the patches, you will experience bugs that have already been fixed. If you don't believe me that the bugs are real, you can prove them to yourself. Start any game. Connect with WiiRDGUI. Pause the game so the memory cannot change, and then do an unknown search. Then keep doing equals searches; try at least seven equals searches in a row while paused. Try to do stuff with your computer while it's searching (watch some YouTube videos or something). You should always get 6,291,456 results for MEM1 or 13,631,488 for MEM2 (it doesn't dump all 64MB of MEM2 because IOS protects upper part of MEM2). Keep equals searching for long enough, you'll start getting fewer and fewer results, even though the game is paused. This is the TX bug. Connecting Gecko.NET causes some code handlers to be patched. You should be able to connect Gecko.NET, and then disconnect, and doing the search again with WiiRDGUI won't lose results (unless your code handler is old). The latest versions of Gecko.NET put the patch's ASM at the very end of the code list (80002FC0 - 80003000) using hard-coded branches, so it shouldn't interfere with sending any other codes and it will be invisible to WiiRDGUI. --- Regarding Y.S. extended codes, I think you are confused. Extended code list is not forced on anyone. You have to apply it yourself before Gecko.NET does anything. There are two parts; the "allocator" which you are responsible for applying, and the "linker" which Gecko.NET will apply only if it detects the extended code list. The 64 "linker" code is automatically applied only when there's a pointer in b0 (80001848). It assumes the pointer in b0 is a pointer to the extended code list. It will then automatically send all the cheats to the extended code list. The 64 code will redirect the code handler to the extended code list. It does not automatically apply the F6 "allocator" code, because that code needs to be applied before the game even starts. There would be no point in automatically loading the code unless you connected to the game while you were in the Gecko OS loader, and I haven't implemented that feature yet. If you do not apply the allocator yourself, you are not using the extended code list and it won't send the 64 code. Why would you want extended codes? Ask Stuff; he uses so many codes that they can't all fit when using the debugger. brkirch would probably have liked to use the debugger to mess with the SMG2 Transformations code. File patch code would have been easier to port with a debugger. biolizard wanted to allocate a pad data object for his 6-player Smash Brothers thing, and the extended code list would give him enough room for that. Y.S. had the overlay code. You could even write a super complex hack in C, using the standard library and stuff like that, and you would now have 32k to fit your code into. There are so many things that weren't even possible before. And again...if you don't use the allocator, then Gecko.NET doesn't send the linker. --- If Gecko.NET's patches bother you, just don't use it. Don't get me wrong, I want people to use it, but these patches are required to fix bugs, so they aren't going away and they aren't optional. I have more ideas for other patches; automatically patching the breakpoint beep out so you don't need to send the code yourself, and automatically freezing the Time Base register while the game is paused or breakpoint (this may have stopped some protections like the ones that caused your Metroid game to restart). I'm also considering a feature to get all 64-bits from the float registers (did you even know they're actually 64-bits?), as well as the ability to write to the float regs. There may also be a way to speed up searches that are specific, since they don't require comparing against a previous dump I can return just the addresses that match a specific value. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 19, 2011, 05:12:05 AM Hmm. So that's what those fregisters are.
Quote from: dcx2 There may also be a way to speed up searches that are specific, since they don't require comparing against a previous dump I can return just the addresses that match a specific value. o.O That would be epic.Not all that important, but the thing that keeps track of the mouse's position in memview uses more cpu than anything else. Again, it's not important. I only noticed this because I connected the wii to my computer and was playing through media player classic. moving the mouse around the memory would make the video stutter. Everything else would, but not so much. I am using a very old PC, though. You probably wouldn't notice on any other computer. But if you were ever gonna do some performance improvements, that's the first place you want to check. lol. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 19, 2011, 08:10:26 AM complete agree to dcx2´s last paragraph.
These would be great. Btw. can´t you finally include the F6 code I use that fixes a certain bug? I need to manually send it from time to time. It´s only 4 lines. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 19, 2011, 09:15:05 AM Error: Could not apply debugger patches
Codehandler: Ocarina Yup I see what you mean, I just wanted to say that. Quote If Gecko.NET's patches bother you, just don't use it. Unfortunately, I have to use Gecko dNET... WiiRd freezes the game after a few seconds with "Auto-Update" on the Memory Vewer or during dumping files.As I said, I wasn't sure about that all, Quote so sorry for that. However, actually I was just asking about an option which disables this Error message... or is it only me who get this error? Why I'm using Ocarina? Because the laser just died while playing for NO REASON. I'm almost afraid for these Japan lasers from wii's. So I bought a new wii only for USB LOADER .Shit happened, that's why I hate discs. Anyway, this is offtopic. Error: http://imageshack.us/photo/my-images/571/unbenanntpdj.png/ You don't have to fix anything. Just want to say that. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 19, 2011, 10:54:57 AM Bug on (Wiiware Game: Texas Hold´em Poker)
Sending C2 codes (I also used the correct undo line above it) crashes, even when the instruction is not executing at that time. It then says: "Wii Exception caught, switch to breakpoints tab!" It´s also the first time to send a code after booting the game. 3.) Here´s the function: CR:24000400 XER:00000000 CTR:00000000 DSIS:06000000 Seems not to be my fault, since this same function popped up on any C2 code (I tried with 3 different ones)DAR:00006814 SRR0:80001DEC SRR1:00003032 LR:80002FF0 r0:800A9A44 r1:807C0DD8 r2:8041D960 r3:D0000000 r4:00000001 r5:00000000 r6:80000000 r7:80001808 r8:00000000 r9:005DB3E0 r10:80001EF0 r11:FFFFFFFF r12:80001D44 r13:8041AE00 r14:00001800 r15:80002988 r16:08400000 r17:00001800 r18:8000283C r19:00000002 r20:CC000000 r21:00000000 r22:80002988 r23:00000000 r24:00000000 r25:00001032 r26:00003032 r27:80002980 r28:000000FF r29:00000040 r30:80002FA4 r31:80000000 f0:3F800000 f1:3F800000 f2:3F800000 f3:00000000 f4:00000000 f5:3F800000 f6:43A00000 f7:43A00000 f8:C382C294 f9:4B800000 f10:3F800000 f11:BB088889 f12:3ACCCCCD f13:00000000 f14:00000000 f15:00000000 f16:00000000 f17:00000000 f18:00000000 f19:00000000 f20:00000000 f21:00000000 f22:00000000 f23:00000000 f24:00000000 f25:00000000 f26:00000000 f27:00000000 f28:00000000 f29:00000000 f30:00000000 f31:00000000 80001DEC: 92F86814 stw r23,26644(r24) 80001DF0: 90786824 stw r3,26660(r24) 80001DF4: 92D86820 stw r22,26656(r24) 80001DF8: 80B86820 lwz r5,26656(r24) 80001DFC: 70A50001 andi. r5,r5,1 80001E00: 4082FFF8 bne+ 0x80001df8 80001E04: 82186824 lwz r16,26660(r24) 80001E08: 90B86814 stw r5,26644(r24) 80001E0C: 4E800020 blr It´s clearly a bug. I used gecko.net 0.66.7 plus gecko OS 1.9.3.2 Older gecko.net versions work fine and don´t have that freeze. Code(s) work. I tried with built r93. Hope you can fix it, dcx2. Thx Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 19, 2011, 01:21:36 PM @Stuff - yeah, the MouseMove event for MemView probably eats up a lot of cycles when the mouse is moving through it. That's what auto-calculates the address under the cursor. Not much I can do, because this is needed to be able to easily set breakpoints on non-word aligned addresses.
@Deathwolf - yes, I will get rid of the "could not apply debugger patches" message box. It will instead be a label on the Tools tab. But if you have to use a USB loader because of your dead laser, I recommend cfg usb. From what I hear, it uses the 1931 code handler, which means you'll have F2/F4/F6 codes as well as the debugger patches. I'm also considering an app that lets you splice your own code handler into the .dol of almost any loader app. That way you can update apps that use the old code handler (e.g. Gecko OS Mod) to use a new code handler, or even a custom code handler that I might release which is pre-patched. @Bully - hmmm, that's odd. It crashed on checkexisend. Did the message box alerting you to the crash bother you? I was considering making it more prominent so that any time it happened while you weren't waiting on a breakpoint, it would notify you. Or maybe even auto-switch to the BP tab and get the crash data. Would that be too invasive? You can go to disasm tab, 80001914: 3AA00000 li r21,0 (for 1932), and Set SRR0 and then hit Run. That *should* recover from the error, but I don't know why it even happened. It looks like the kinda thing that one of the debugger patches is supposed to fix. Note that with 1932, you don't need Undo codes for C2, just 04 ASM patches. 1932 keeps an "unhook list" after the code list. Have you tried sending non-C2 codes? Have you tried sending no codes? Have you tried sending codes with undo disabled? Have you tried Gecko OS 1931? I think this is due to exisendbyteAA flushing...it fixed problems with memview crashing the game, but now it might make codes crash the game...looking at the LR, it's 80002FF0, which is where I put my debugger patches. But that is the rx patch, and not the AA patch. The message to switch tabs would only appear *before* the codes are actually sent. If it is the AA flushing then 0.66.6 wouldn't have that problem. I'll have to look into this when I get some time. It might not be in the next build, because first I want to push one that has the scrollbar fixed and moves the "unpatched debugger" notification to the Tools tab. Depends on how much time I have. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 19, 2011, 02:46:46 PM You can go to disasm tab, 80001914: 3AA00000 li r21,0 (for 1932), and Set SRR0 and then hit Run. That *should* recover from the error, but I don't know why it even happened. Yes it recovers with 0.66.7 (but older gecko.net versions freeze up instead) lol ;DI tried sending the C2 code without the undo line, same crash. Gecko.net version 0.66.5 -> same thing happens, crash. --- Wow, it also crashes on a useless 04 RAM Write with same value like the one in RAM... On GCT Tab, it says that there are 192 codeslines available, just as a side note. It even crashes when I send an empty codeslist xDDD Damn, I need to put this game aside for now, it´s just horrible to hack with those sending bugs >.< Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 19, 2011, 02:57:40 PM mousemove: Alright. Like I said, it's not a big deal. It was only noticeable when the cpu was at it's limit. I was gonna ask about the click/right click event or even just doing it in the gotobreakpoint()(you know), BUT then I'll miss the little address thing in the upper left corner. If it ain't broke, don't fix it. :p
msg boxes: The msg boxes are important for errors/exceptions/all that. The switch to bp tab thing is a good idea, just make the msg box pop up and ask if you want to go there(haven't seen it myself so, sorry if it already does this). Reasons I would like to stay in the current tab can vary...usually something that can be done later, but just switching to the bp tab with no notification is like "wtf >.>". Yes, msg boxes are inconvenient, but would you rather it keep it to itself/have the msg hidden somewhere? For the unpatched codehandler I was leaning against removing the msg box, but putting that in the tools tab brought up a better idea. Put it in the status bar. Right there where every other msg you hardly ever look at is at. if (connected && code handler unpatched) then status = "your codehandler sucks :p" So instead of "transfer completed"(I think that's what's always there), you can see that your codehandler sucks. Because it's more of a status than a...whatever you planned to do with it in tools. I use cfg usbloader when I'm too lazy to change the disc and I also like it's 'manage cheats' option. But yeah, if not 1931, it has some bootleg code handler that's similar and I never get that status msg. Just somethings don't work properly. Unfortunately, the extended codelist is one of those things. >.< He needs to fix that hook without cheats thing though >.> Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 19, 2011, 03:39:30 PM @Bully - good to hear that it's recoverable. I think I know how to fix this issue then.
Like I said before, the msgbox pops up before the actual codes are sent. It goes something like this. 1) Send a byte to the code handler that says "prepare for cheats" 2) Code handler replies "AA" = Acknowledged 3) Gecko.NET turns all the codes into a cheat.bin, and sends the bin to the code handler. If you get the msgbox, then 2) failed and instead you got "11" = breakpoint. So your cheats were never even sent - it crashed before that, and would crash even with an empty codelist. The AA thing also happens with dumping for searches, memview, registers, disasm etc so there must be something different about how 1932 is sending cheats (I almost always use 1931 handler so I would have seen this earlier). I'm now considering a feature that detects code-handler crashes and automatically sets SRR0 to the right place to recover from it. Perhaps with msgbox "crash detected in code handler! Reset SRR0? yes/no" Could you try again with 1931 to confirm it's a problem common to both code handlers? --- @Stuff - Perhaps I could do a hybrid approach. Do it in the click event, and also have a "refresh timer" so that the address marker updates at, like, 10 Hz or something reasonably quick. But yeah, ain't broke don't fix at least for now. I've been meaning to make the watch list use a timer instead of a thread (because the watchlist is bootleg) Yeah, I think I'll do a msgbox "crash detected! Switch to BP tab? yes/no". If yes, it will also automatically grab the disasm and regs. Maybe even some extra feedback by automatically parsing SRR1 to determine what type of exception. I see what you mean about putting it in status, but I actually would like to try to use that more often for its intended purpose. Besides, there's already a label on the tools tab that tells you whether your USB Gecko driver is good or needs updated. If it needs updated, I even provide a link to the FTDI page for the driver. ^_^ 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 19, 2011, 03:52:31 PM It does not happen on gecko OS 1.9.3.1 :o
Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 19, 2011, 08:11:32 PM Some random crashes while sending codes.
http://imageshack.us/photo/my-images/805/unbenanntfxy.png/ FTDIUSBGecko.EUSBGeckoExeption Codehandler: Ocarina Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 19, 2011, 08:14:47 PM I need to know what version of the code handler was being used. A copy and paste of the details would help, too.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 19, 2011, 11:05:28 PM I personally wouldn´t bother about supporting "Ocarina" anyways >-<
There are way more important things to work at... Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 20, 2011, 12:28:33 AM 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.Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 20, 2011, 01:03:03 AM @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. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 20, 2011, 01:29:29 AM that. I was just derpin there. And you right. The code handler isn't just gonna change over night. lol
Title: Re: Gecko dotNET Bugs and Requests Post by: Arudo on August 21, 2011, 02:49:29 AM 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. 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: Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 21, 2011, 03:08:03 AM 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? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 21, 2011, 04:28:23 AM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 21, 2011, 04:32:10 AM I don't get how gameconfig works, but this sounds interesting.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 21, 2011, 05:59:02 AM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 21, 2011, 10:48:22 AM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 21, 2011, 02:08:50 PM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 21, 2011, 05:28:25 PM can this be done with gecko.net?
At least it´s worth to try out that speeded up thingy ;D Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 21, 2011, 05:38:59 PM 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.
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 21, 2011, 05:43:25 PM >.> Riivolution+usb gecko? Is that even possible? And swap out code handlers? XD. I look forward to that custom code handler.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 21, 2011, 05:51:28 PM Yes, Riivolution supports the USB Gecko.
http://rvlution.net/wiki/Ocarina_Codes Riivolution also supports wifi redirection. So you can keep the code handler binary on your computer, so you can easily swap in new code handlers. But you would have to restart (EDIT: restart Riivolution not the PC), because Riivolution copies the codehandler.bin file into memory when the game is loaded. About as brain-dead simple as it gets in terms of upgrading your code handler, but that's if you get Riivolution working, and it doesn't support channel cheats or GC games. Hence why I lean more toward using gameconfig pokes, because it's widely supported due to Brawl+. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 21, 2011, 09:04:16 PM @dcx2:
there are still some issues with monster hunter and gecko.net! If I set a breakpoint, before the game goes into a black screen loading thing, windows says that "gecko.net doesn´t work anymore" And on Breakpoints tab it writes "invalid address" where the instructions are supposed to be put. Therefore, gecko.net closes itself. If I open it up to connect again and switch to memory viewer, it freezes the game for at least 15 seconds and continues after a while. Setting an execute breakpoint recovers. However, the freezing issue through auto-update is fixed ;D (gecko.net version 0.66.7.) EDIT: damn, it´s fixed in 0.66.8. cool O0 Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on August 21, 2011, 09:08:09 PM Yes, Riivolution supports the USB Gecko. For Project M too?http://rvlution.net/wiki/Ocarina_Codes Riivolution also supports wifi redirection. So you can keep the code handler binary on your computer, so you can easily swap in new code handlers. But you would have to restart (EDIT: restart Riivolution not the PC), because Riivolution copies the codehandler.bin file into memory when the game is loaded. About as brain-dead simple as it gets in terms of upgrading your code handler, but that's if you get Riivolution working, and it doesn't support channel cheats or GC games. Hence why I lean more toward using gameconfig pokes, because it's widely supported due to Brawl+. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 01:02:50 AM yes, it also improved the ability to catch breakpoints. 8)
Great, I just made a crash fix code that wasn´t possible before. :p No problems so far. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 22, 2011, 08:37:44 AM Without permanently modifying a dump, I would like for the disassemble tab to work with dumps So I can jump to an instruction's address and see the asm there. With assemble working like usual, just not modifying the dump.
Also, in addition to the gct code option in the context menu, I want it to do a 'copy code'. So instead of having to go to the gct tab an make a new code, I can just have it in my clipboard for pasting everywhere. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 12:24:14 PM switching to memory viewer while gecko.net is doing a ram dump disconnects gecko.net and freezes the game.
No BP or reconnect is possible. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 12:44:08 PM @Stuff
You're the second person to ask for dumps to be read-only. Believe it or not, I actually assemble dumps on purpose all the time. I have yet to find a really good way to calculate branch offsets for codes from dumps. Pasting the branch into a dump is pretty much the best solution I can think of because the branch displacement operand will depend upon the address being assembled. I'm not really sure what you're asking though. You can already load other dumps into disasm and jump to ASM. So, instead of making a new code on the GCT tab you want the code put into the clipboard? That should be easy enough. The context menu is getting pretty long though... --- @Bully Doing *anything* while dumping will crash the game. That's why it disables all the buttons while it's dumping. Were you doing a Tools tab dump? Because search should lock you to that tab... Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 12:49:36 PM yes, as I said, it was a "RAM dump" (therefore: tools tab)
you may want to fix the freezing OR disable tab switching. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 12:53:28 PM Technically, search tab can dump, pointer tab can dump, tools tab can dump. I guess I should verify all those are tab-locked while dumping, because there's no way to fix that freeze.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 01:03:15 PM It was pointer tab, but same thing I guess...
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 22, 2011, 04:02:24 PM disassemble tab: Oh I didn't see the source dropdown in that tab XD. nvm then. Well. Guess I could make a backup dump then. :/
context menu: I guess if size is an issue, you could put the gct related stuff in a sub menu. :/ Don't really want that, though. And it's only one more option. Give it a kb shortcut if it has to go in a sub menu. I think it would be one of the more used options. The gct tab could use a button for that too. Right next to Store Immediately, Copy to Clipboard. This one would copy the current code with the name as well. I'd say one for the gct wizard, but I've never used that. :p How come add to gct is only available in the disassemble tab?(I don't use that either. Just wanna know. It's not all that serious.) Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 05:20:50 PM Yeah, I make backups of the original dumps before I do any working on them.
If size starts to become an issue, I'll try to use lesser-moved functions like the F2 XOR, SRR0 stuff to a sub-menu. Store Immediately is kinda obsolete now that GCT's autosave. Heh. I created Add to GCT because when I was making a long list of 04 ASM patches, I got tired of copying and pasting from "New Code"'s into the code I was adding to. Some codes are just a dozen or so 04 ASM patches. So I made the Add to GCT, and I populate the dropdown with the reverse list of the GCT codes so the most recent code (which is usually at the bottom of the GCT list) is what pops up first. It's not anywhere else because...well...99% of my hacks are ASM so I end up using either disasm GCT or PyiiASMH/ASMWiiRD. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 10:25:35 PM errgh.. >.<
gecko.net 0.66.8 still freezes on some C2 codes... (tried on 1931) " Wii Exception caught, switch to BP tab" The destination/source register is always 00000001 (or 00000000) when that happened (I noticed...) I used an old built (r93) and sending the same code didn´t crash. It just worked :eek: There´s definetely something wrong with the checkexisend command... :( CR:20200828 XER:00000000 CTR:80575F44 DSIS:06000000 DAR:00000041 SRR0:8074F674 SRR1:00009032 LR:80575FD8 r0:80575FD8 r1:8024DD28 r2:802459C0 r3:FFFFFFFF r4:807D021C r5:80EA77D8 r6:80EA77D8 r7:00000000 r8:3F800000 r9:80EA77E4 r10:80EA77E4 r11:8024DDF8 r12:80575F44 r13:80244680 r14:00010005 r15:8017D510 r16:806329A0 r17:00000000 r18:00000000 r19:00000004 r20:00000000 r21:8036F000 r22:73433744 r23:00010005 r24:73433744 r25:00000000 r26:808F0C1C r27:00000055 r28:80EA7668 r29:00000001 r30:80793C68 r31:808045C8 8074F654: 9421FEF0 stwu r1,-272(r1) 8074F658: 7C0802A6 mflr r0 8074F65C: 90010114 stw r0,276(r1) 8074F660: DBE10100 stfd f31,256(r1) 8074F664: F3E10108 psq_st f31,264(r1),0,0 8074F668: DBC100F0 stfd f30,240(r1) 8074F66C: F3C100F8 psq_st f30,248(r1),0,0 8074F670: DBA100E0 stfd f29,224(r1) 8074F674: 909D0040 stw r4,64(r29) 8074F678: DB8100D0 stfd f28,208(r1) 8074F67C: F38100D8 psq_st f28,216(r1),0,0 8074F680: 396100D0 addi r11,r1,208 8074F684: 4B90E7E5 bl 0x8005de68 8074F688: 3F608080 lis r27,-32640 8074F68C: 3B7B4898 addi r27,r27,18584 8074F690: 3F808079 lis r28,-32647 8074F694: 3B9C3FC8 addi r28,r28,16328 8074F698: 901D0054 stw r0,84(r29) 8074F69C: 3C6080A1 lis r3,-32607 8074F6A0: 9803EE6C stb r0,-4500(r3) 8074F6A4: 3FA080A1 lis r29,-32607 8074F6A8: 807DF108 lwz r3,-3832(r29) 8074F6AC: 3BC00000 li r30,0 8074F6B0: 97C30054 stwu r30,84(r3) 8074F6B4: 90630004 stw r3,4(r3) 8074F6B8: 93C30008 stw r30,8(r3) 8074F6BC: 4BFFFF09 bl 0x8074f5c4 8074F6C0: C3FC0044 lfs f31,68(r28) 8074F6C4: 807DF108 lwz r3,-3832(r29) 8074F6C8: 82E3002C lwz r23,44(r3) 8074F6CC: 3BE30028 addi r31,r3,40 8074F6D0: 3AC10058 addi r22,r1,88 8074F6D4: C39C004C lfs f28,76(r28) 8074F6D8: C3BC0050 lfs f29,80(r28) 8074F6DC: FFC0F890 fmr f30,f31 8074F6E0: 480001F8 b 0x8074f8d8 8074F6E4: 80B7000C lwz r5,12(r23) 8074F6E8: 80970008 lwz r4,8(r23) 8074F6EC: C0240020 lfs f1,32(r4) 8074F6F0: C0050020 lfs f0,32(r5) 8074F6F4: EC010028 fsubs f0,f1,f0 8074F6F8: D0010058 stfs f0,88(r1) 8074F6FC: C0240024 lfs f1,36(r4) 8074F700: C0050024 lfs f0,36(r5) 8074F704: EC010028 fsubs f0,f1,f0 8074F708: D001005C stfs f0,92(r1) 8074F70C: C0240028 lfs f1,40(r4) 8074F710: C0050028 lfs f0,40(r5) 8074F714: EC010028 fsubs f0,f1,f0 8074F718: D0010060 stfs f0,96(r1) 8074F71C: C024002C lfs f1,44(r4) 8074F720: C005002C lfs f0,44(r5) 8074F724: EC010028 fsubs f0,f1,f0 8074F728: D0010064 stfs f0,100(r1) 8074F72C: 38C50010 addi r6,r5,16 8074F730: 38E40010 addi r7,r4,16 8074F734: C09C0044 lfs f4,68(r28) 8074F738: C07C0038 lfs f3,56(r28) 8074F73C: 38600000 li r3,0 8074F740: 38000003 li r0,3 8074F744: 7C0903A6 mtctr r0 8074F748: 7C251C2E lfsx f1,r5,r3 8074F74C: 7C071C2E lfsx f0,r7,r3 8074F750: EC410028 fsubs f2,f1,f0 8074F754: 7C261C2E lfsx f1,r6,r3 8074F758: 7C041C2E lfsx f0,r4,r3 8074F75C: EC210028 fsubs f1,f1,f0 8074F760: 7C161C2E lfsx f0,r22,r3 8074F764: FC00E040 fcmpo cr0,f0,f28 8074F768: 40810034 ble- 0x8074f79c 8074F76C: EC020024 fdivs f0,f2,f0 8074F770: FC040040 fcmpo cr0,f4,f0 8074F774: 40810008 ble- 0x8074f77c 8074F778: 48000008 b 0x8074f780 8074F77C: FC800090 fmr f4,f0 8074F780: 7C161C2E lfsx f0,r22,r3 8074F784: EC010024 fdivs f0,f1,f0 8074F788: FC030040 fcmpo cr0,f3,f0 8074F78C: 40800008 bge- 0x8074f794 8074F790: 4800005C b 0x8074f7ec 8074F794: FC600090 fmr f3,f0 8074F798: 48000054 b 0x8074f7ec 8074F79C: FC00E840 fcmpo cr0,f0,f29 8074F7A0: 40800034 bge- 0x8074f7d4 8074F7A4: EC020024 fdivs f0,f2,f0 8074F7A8: FC030040 fcmpo cr0,f3,f0 8074F7AC: 40800008 bge- 0x8074f7b4 8074F7B0: 48000008 b 0x8074f7b8 8074F7B4: FC600090 fmr f3,f0 8074F7B8: 7C161C2E lfsx f0,r22,r3 8074F7BC: EC010024 fdivs f0,f1,f0 8074F7C0: FC040040 fcmpo cr0,f4,f0 8074F7C4: 40810008 ble- 0x8074f7cc 8074F7C8: 48000024 b 0x8074f7ec 8074F7CC: FC800090 fmr f4,f0 8074F7D0: 4800001C b 0x8074f7ec 8074F7D4: FC02F040 fcmpo cr0,f2,f30 8074F7D8: 4181000C bgt- 0x8074f7e4 8074F7DC: FC01F040 fcmpo cr0,f1,f30 8074F7E0: 4080000C bge- 0x8074f7ec 8074F7E4: 38000000 li r0,0 8074F7E8: 48000024 b 0x8074f80c 8074F7EC: FC041840 fcmpo cr0,f4,f3 8074F7F0: 4081000C ble- 0x8074f7fc 8074F7F4: 38000000 li r0,0 8074F7F8: 48000014 b 0x8074f80c 8074F7FC: 38630004 addi r3,r3,4 8074F800: 4200FF48 bdnz+ 0x8074f748 8074F804: FFE02090 fmr f31,f4 8074F808: 38000001 li r0,1 8074F80C: 2C000000 cmpwi r0,0 8074F810: 418200C4 beq- 0x8074f8d4 8074F814: 8337000C lwz r25,12(r23) 8074F818: 83570008 lwz r26,8(r23) 8074F81C: 82BB008C lwz r21,140(r27) 8074F820: 801B0088 lwz r0,136(r27) 8074F824: 7C00A800 cmpw r0,r21 8074F828: 40810008 ble- 0x8074f830 8074F82C: 7C150378 mr r21,r0 8074F830: 807DF108 lwz r3,-3832(r29) 8074F834: 3B030060 addi r24,r3,96 8074F838: 3875FFFF subi r3,r21,1 8074F83C: 7C7418F8 not r20,r3 8074F840: 80180004 lwz r0,4(r24) 8074F844: 7C001A14 add r0,r0,r3 8074F848: 7E850038 and r5,r20,r0 8074F84C: 38650014 addi r3,r5,20 8074F850: 80180008 lwz r0,8(r24) 8074F854: 7C030040 cmplw r3,r0 8074F858: 4081000C ble- 0x8074f864 8074F85C: 38A00000 li r5,0 8074F860: 48000008 b 0x8074f868 8074F864: 90780004 stw r3,4(r24) 8074F868: 2C050000 cmpwi r5,0 8074F86C: 40820038 bne- 0x8074f8a4 8074F870: 7F03C378 mr r3,r24 8074F874: 480146D1 bl 0x80763f44 8074F878: 3875FFFF subi r3,r21,1 8074F87C: 80180004 lwz r0,4(r24) 8074F880: 7C001A14 add r0,r0,r3 8074F884: 7E850038 and r5,r20,r0 8074F888: 38650014 addi r3,r5,20 8074F88C: 80180008 lwz r0,8(r24) 8074F890: 7C030040 cmplw r3,r0 8074F894: 4081000C ble- 0x8074f8a0 8074F898: 38A00000 li r5,0 8074F89C: 48000008 b 0x8074f8a4 8074F8A0: 90780004 stw r3,4(r24) 8074F8A4: 93450004 stw r26,4(r5) 8074F8A8: 93250008 stw r25,8(r5) 8074F8AC: D3E5000C stfs f31,12(r5) 8074F8B0: 93C50010 stw r30,16(r5) 8074F8B4: 809DF108 lwz r4,-3832(r29) 8074F8B8: 93C50000 stw r30,0(r5) 8074F8BC: 8064005C lwz r3,92(r4) 8074F8C0: 38030001 addi r0,r3,1 8074F8C4: 9004005C stw r0,92(r4) 8074F8C8: 80640058 lwz r3,88(r4) 8074F8CC: 90A30000 stw r5,0(r3) 8074F8D0: 90A40058 stw r5,88(r4) 8074F8D4: 82F70004 lwz r23,4(r23) 8074F8D8: 7C1FB840 cmplw r31,r23 8074F8DC: 4082FE08 bne+ 0x8074f6e4 8074F8E0: 3C6080A1 lis r3,-32607 8074F8E4: 8063F108 lwz r3,-3832(r3) 8074F8E8: 80C30048 lwz r6,72(r3) 8074F8EC: 480001D8 b 0x8074fac4 8074F8F0: 80A6003C lwz r5,60(r6) 8074F8F4: 2C050000 cmpwi r5,0 8074F8F8: 418201C8 beq- 0x8074fac0 8074F8FC: 80850000 lwz r4,0(r5) 8074F900: C0640000 lfs f3,0(r4) 8074F904: C0040020 lfs f0,32(r4) 8074F908: EC43002A fadds f2,f3,f0 8074F90C: D0410028 stfs f2,40(r1) 8074F910: C0240004 lfs f1,4(r4) 8074F914: C0040024 lfs f0,36(r4) 8074F918: EC01002A fadds f0,f1,f0 8074F91C: D001002C stfs f0,44(r1) 8074F920: C0240008 lfs f1,8(r4) 8074F924: C0040028 lfs f0,40(r4) 8074F928: EC01002A fadds f0,f1,f0 8074F92C: D0010030 stfs f0,48(r1) 8074F930: C024000C lfs f1,12(r4) 8074F934: C004002C lfs f0,44(r4) 8074F938: EC01002A fadds f0,f1,f0 8074F93C: D0010034 stfs f0,52(r1) 8074F940: FC031040 fcmpo cr0,f3,f2 8074F944: 40800008 bge- 0x8074f94c 8074F948: 48000008 b 0x8074f950 8074F94C: FC601090 fmr f3,f2 8074F950: D0610018 stfs f3,24(r1) 8074F954: C0240004 lfs f1,4(r4) 8074F958: C001002C lfs f0,44(r1) 8074F95C: FC010040 fcmpo cr0,f1,f0 8074F960: 40800008 bge- 0x8074f968 8074F964: 48000008 b 0x8074f96c 8074F968: FC200090 fmr f1,f0 8074F96C: D021001C stfs f1,28(r1) 8074F970: C0240008 lfs f1,8(r4) 8074F974: C0010030 lfs f0,48(r1) 8074F978: FC010040 fcmpo cr0,f1,f0 8074F97C: 40800008 bge- 0x8074f984 8074F980: 48000008 b 0x8074f988 8074F984: FC200090 fmr f1,f0 8074F988: D0210020 stfs f1,32(r1) 8074F98C: C024000C lfs f1,12(r4) 8074F990: C0010034 lfs f0,52(r1) 8074F994: FC010040 fcmpo cr0,f1,f0 8074F998: 40800008 bge- 0x8074f9a0 8074F99C: 48000008 b 0x8074f9a4 8074F9A0: FC200090 fmr f1,f0 8074F9A4: D0210024 stfs f1,36(r1) 8074F9A8: 80610018 lwz r3,24(r1) 8074F9AC: 8001001C lwz r0,28(r1) 8074F9B0: 90610080 stw r3,128(r1) 8074F9B4: 90010084 stw r0,132(r1) 8074F9B8: 80610020 lwz r3,32(r1) 8074F9BC: 80010024 lwz r0,36(r1) 8074F9C0: 90610088 stw r3,136(r1) 8074F9C4: 9001008C stw r0,140(r1) 8074F9C8: C0640010 lfs f3,16(r4) 8074F9CC: C0040020 lfs f0,32(r4) 8074F9D0: EC43002A fadds f2,f3,f0 8074F9D4: D0410048 stfs f2,72(r1) 8074F9D8: C0240014 lfs f1,20(r4) 8074F9DC: C0040024 lfs f0,36(r4) 8074F9E0: EC01002A fadds f0,f1,f0 8074F9E4: D001004C stfs f0,76(r1) 8074F9E8: C0240018 lfs f1,24(r4) 8074F9EC: C0040028 lfs f0,40(r4) 8074F9F0: EC01002A fadds f0,f1,f0 8074F9F4: D0010050 stfs f0,80(r1) 8074F9F8: C024001C lfs f1,28(r4) 8074F9FC: C004002C lfs f0,44(r4) 8074FA00: EC01002A fadds f0,f1,f0 8074FA04: D0010054 stfs f0,84(r1) 8074FA08: FC031040 fcmpo cr0,f3,f2 8074FA0C: 40810008 ble- 0x8074fa14 8074FA10: 48000008 b 0x8074fa18 8074FA14: FC601090 fmr f3,f2 8074FA18: D0610038 stfs f3,56(r1) 8074FA1C: C0240014 lfs f1,20(r4) 8074FA20: C001004C lfs f0,76(r1) 8074FA24: FC010040 fcmpo cr0,f1,f0 8074FA28: 40810008 ble- 0x8074fa30 8074FA2C: 48000008 b 0x8074fa34 8074FA30: FC200090 fmr f1,f0 8074FA34: D021003C stfs f1,60(r1) 8074FA38: C0240018 lfs f1,24(r4) 8074FA3C: C0010050 lfs f0,80(r1) 8074FA40: FC010040 fcmpo cr0,f1,f0 8074FA44: 40810008 ble- 0x8074fa4c 8074FA48: 48000008 b 0x8074fa50 8074FA4C: FC200090 fmr f1,f0 8074FA50: D0210040 stfs f1,64(r1) 8074FA54: C024001C lfs f1,28(r4) 8074FA58: C0010054 lfs f0,84(r1) 8074FA5C: FC010040 fcmpo cr0,f1,f0 8074FA60: 40810008 ble- 0x8074fa68 8074FA64: 48000008 b 0x8074fa6c 8074FA68: FC200090 fmr f1,f0 8074FA6C: D0210044 stfs f1,68(r1) 8074FA70: 80610038 lwz r3,56(r1) 8074FA74: 8001003C lwz r0,60(r1) 8074FA78: 90610090 stw r3,144(r1) 8074FA7C: 90010094 stw r0,148(r1) 8074FA80: 80610040 lwz r3,64(r1) 8074FA84: 80010044 lwz r0,68(r1) 8074FA88: 90610098 stw r3,152(r1) 8074FA8C: 9001009C stw r0,156(r1) 8074FA90: C0010080 lfs f0,128(r1) 8074FA94: D005000C stfs f0,12(r5) 8074FA98: C0010090 lfs f0,144(r1) 8074FA9C: D0050020 stfs f0,32(r5) 8074FAA0: C0010084 lfs f0,132(r1) 8074FAA4: D0050034 stfs f0,52(r5) 8074FAA8: C0010094 lfs f0,148(r1) 8074FAAC: D0050048 stfs f0,72(r5) 8074FAB0: C0010088 lfs f0,136(r1) 8074FAB4: D005005C stfs f0,92(r5) 8074FAB8: C0010098 lfs f0,152(r1) 8074FABC: D0050070 stfs f0,112(r5) 8074FAC0: 80C60034 lwz r6,52(r6) 8074FAC4: 2C060000 cmpwi r6,0 8074FAC8: 4082FE28 bne+ 0x8074f8f0 8074FACC: 3C6080A1 lis r3,-32607 8074FAD0: 8283F10C lwz r20,-3828(r3) 8074FAD4: 7E83A378 mr r3,r20 8074FAD8: 48001189 bl 0x80750c60 8074FADC: 5479083D rlwinm. r25,r3,1,0,30 8074FAE0: 408101AC ble- 0x8074fc8c 8074FAE4: 38610068 addi r3,r1,104 8074FAE8: 48001155 bl 0x80750c3c 8074FAEC: 5737103A rlwinm r23,r25,2,0,29 8074FAF0: 387B00C0 addi r3,r27,192 8074FAF4: 389B00C4 addi r4,r27,196 8074FAF8: 4BC3E1ED bl 0x8038dce4 8074FAFC: 7C651B78 mr r5,r3 8074FB00: 38610068 addi r3,r1,104 8074FB04: 7EE4BB78 mr r4,r23 8074FB08: 38C00000 li r6,0 8074FB0C: 38FB0104 addi r7,r27,260 8074FB10: 48001075 bl 0x80750b84 8074FB14: 7C751B78 mr r21,r3 8074FB18: 387B00C8 addi r3,r27,200 8074FB1C: 389B00CC addi r4,r27,204 8074FB20: 4BC3E1C5 bl 0x8038dce4 8074FB24: 7C651B78 mr r5,r3 8074FB28: 38610068 addi r3,r1,104 8074FB2C: 7EE4BB78 mr r4,r23 8074FB30: 38C00000 li r6,0 8074FB34: 38FB0104 addi r7,r27,260 8074FB38: 4800104D bl 0x80750b84 8074FB3C: 7C761B78 mr r22,r3 8074FB40: 387B00D0 addi r3,r27,208 8074FB44: 389B00D4 addi r4,r27,212 8074FB48: 4BC3E19D bl 0x8038dce4 8074FB4C: 7C651B78 mr r5,r3 8074FB50: 38610068 addi r3,r1,104 8074FB54: 7EE4BB78 mr r4,r23 8074FB58: 38C00000 li r6,0 8074FB5C: 38FB0104 addi r7,r27,260 8074FB60: 48001025 bl 0x80750b84 8074FB64: 7C771B78 mr r23,r3 8074FB68: 81340004 lwz r9,4(r20) 8074FB6C: 81140008 lwz r8,8(r20) 8074FB70: 80F4000C lwz r7,12(r20) 8074FB74: 7EA6AB78 mr r6,r21 8074FB78: 7EC5B378 mr r5,r22 8074FB7C: 7EE4BB78 mr r4,r23 8074FB80: 5720103A rlwinm r0,r25,2,0,29 8074FB84: 7F150214 add r24,r21,r0 8074FB88: 38600000 li r3,0 8074FB8C: 48000038 b 0x8074fbc4 8074FB90: 91260000 stw r9,0(r6) 8074FB94: 9069000C stw r3,12(r9) 8074FB98: 81290010 lwz r9,16(r9) 8074FB9C: 91050000 stw r8,0(r5) 8074FBA0: 9068000C stw r3,12(r8) 8074FBA4: 81080010 lwz r8,16(r8) 8074FBA8: 90E40000 stw r7,0(r4) 8074FBAC: 9067000C stw r3,12(r7) 8074FBB0: 80E70010 lwz r7,16(r7) 8074FBB4: 38630001 addi r3,r3,1 8074FBB8: 38C60004 addi r6,r6,4 8074FBBC: 38A50004 addi r5,r5,4 8074FBC0: 38840004 addi r4,r4,4 8074FBC4: 7C06C040 cmplw r6,r24 8074FBC8: 4082FFC8 bne+ 0x8074fb90 8074FBCC: 7E83A378 mr r3,r20 8074FBD0: 7EA4AB78 mr r4,r21 8074FBD4: 7F25CB78 mr r5,r25 8074FBD8: 4BFFB2CD bl 0x8074aea4 8074FBDC: 7E83A378 mr r3,r20 8074FBE0: 7EC4B378 mr r4,r22 8074FBE4: 7F25CB78 mr r5,r25 8074FBE8: 4BFFB2BD bl 0x8074aea4 8074FBEC: 7E83A378 mr r3,r20 8074FBF0: 7EE4BB78 mr r4,r23 8074FBF4: 7F25CB78 mr r5,r25 8074FBF8: 4BFFB2AD bl 0x8074aea4 8074FBFC: 80150000 lwz r0,0(r21) 8074FC00: 90140004 stw r0,4(r20) 8074FC04: 80160000 lwz r0,0(r22) 8074FC08: 90140008 stw r0,8(r20) 8074FC0C: 80170000 lwz r0,0(r23) 8074FC10: 9014000C stw r0,12(r20) 8074FC14: 48000040 b 0x8074fc54 8074FC18: 38950004 addi r4,r21,4 8074FC1C: 80150004 lwz r0,4(r21) 8074FC20: 80750000 lwz r3,0(r21) 8074FC24: 90030010 stw r0,16(r3) 8074FC28: 7C952378 mr r21,r4 8074FC2C: 38960004 addi r4,r22,4 8074FC30: 80160004 lwz r0,4(r22) 8074FC34: 80760000 lwz r3,0(r22) 8074FC38: 90030010 stw r0,16(r3) 8074FC3C: 7C962378 mr r22,r4 8074FC40: 38970004 addi r4,r23,4 8074FC44: 80170004 lwz r0,4(r23) 8074FC48: 80770000 lwz r3,0(r23) 8074FC4C: 90030010 stw r0,16(r3) 8074FC50: 7C972378 mr r23,r4 8074FC54: 7C15C040 cmplw r21,r24 8074FC58: 4082FFC0 bne+ 0x8074fc18 8074FC5C: 38000000 li r0,0 8074FC60: 8075FFFC lwz r3,-4(r21) 8074FC64: 90030010 stw r0,16(r3) 8074FC68: 8076FFFC lwz r3,-4(r22) 8074FC6C: 90030010 stw r0,16(r3) 8074FC70: 8077FFFC lwz r3,-4(r23) 8074FC74: 90030010 stw r0,16(r3) 8074FC78: 38610068 addi r3,r1,104 8074FC7C: 48014351 bl 0x80763fcc 8074FC80: 38610068 addi r3,r1,104 8074FC84: 3880FFFF li r4,-1 8074FC88: 4BC3D6A1 bl 0x8038d328 8074FC8C: 7E83A378 mr r3,r20 8074FC90: 48000239 bl 0x8074fec8 8074FC94: 3EA080A1 lis r21,-32607 8074FC98: 8075F108 lwz r3,-3832(r21) 8074FC9C: 83230054 lwz r25,84(r3) 8074FCA0: 3A800000 li r20,0 8074FCA4: 480000D4 b 0x8074fd78 8074FCA8: 80190010 lwz r0,16(r25) 8074FCAC: 2C000000 cmpwi r0,0 8074FCB0: 408200C4 bne- 0x8074fd74 8074FCB4: 80790008 lwz r3,8(r25) 8074FCB8: 80030060 lwz r0,96(r3) 8074FCBC: 90010008 stw r0,8(r1) 8074FCC0: 80790004 lwz r3,4(r25) 8074FCC4: 80630060 lwz r3,96(r3) 8074FCC8: 9061000C stw r3,12(r1) 8074FCCC: 82D5F108 lwz r22,-3832(r21) 8074FCD0: 7C030040 cmplw r3,r0 8074FCD4: 40810014 ble- 0x8074fce8 8074FCD8: 3B000001 li r24,1 8074FCDC: 9001000C stw r0,12(r1) 8074FCE0: 90610008 stw r3,8(r1) 8074FCE4: 48000008 b 0x8074fcec 8074FCE8: 3B000000 li r24,0 8074FCEC: 38610010 addi r3,r1,16 8074FCF0: 3881000C addi r4,r1,12 8074FCF4: 38A10008 addi r5,r1,8 8074FCF8: 4BE1D4B9 bl 0x8056d1b0 8074FCFC: 38760004 addi r3,r22,4 8074FD00: 38810010 addi r4,r1,16 8074FD04: 4BE1D41D bl 0x8056d120 8074FD08: 7C771B78 mr r23,r3 8074FD0C: 2C030000 cmpwi r3,0 8074FD10: 41820010 beq- 0x8074fd20 8074FD14: 7F04C378 mr r4,r24 8074FD18: 4BE1D251 bl 0x8056cf68 8074FD1C: 48000054 b 0x8074fd70 8074FD20: 7EC3B378 mr r3,r22 8074FD24: 4BE1D23D bl 0x8056cf60 8074FD28: 80160008 lwz r0,8(r22) 8074FD2C: 7C030000 cmpw r3,r0 8074FD30: 40800040 bge- 0x8074fd70 8074FD34: 7EC3B378 mr r3,r22 8074FD38: 4BE1D1C1 bl 0x8056cef8 8074FD3C: 7C771B78 mr r23,r3 8074FD40: 2C030000 cmpwi r3,0 8074FD44: 4182002C beq- 0x8074fd70 8074FD48: 38810010 addi r4,r1,16 8074FD4C: 7F05C378 mr r5,r24 8074FD50: 4BE1D175 bl 0x8056cec4 8074FD54: 38760004 addi r3,r22,4 8074FD58: 38810010 addi r4,r1,16 8074FD5C: 7EE5BB78 mr r5,r23 8074FD60: 4BE1CE69 bl 0x8056cbc8 8074FD64: 8016000C lwz r0,12(r22) 8074FD68: 9017008C stw r0,140(r23) 8074FD6C: 92F6000C stw r23,12(r22) 8074FD70: 92F90010 stw r23,16(r25) 8074FD74: 83390000 lwz r25,0(r25) 8074FD78: 7C14C840 cmplw r20,r25 8074FD7C: 4082FF2C bne+ 0x8074fca8 8074FD80: 3C6080A1 lis r3,-32607 8074FD84: 8083F108 lwz r4,-3832(r3) 8074FD88: 8064006C lwz r3,108(r4) 8074FD8C: 80040050 lwz r0,80(r4) 8074FD90: 7C001800 cmpw r0,r3 8074FD94: 40810008 ble- 0x8074fd9c 8074FD98: 48000008 b 0x8074fda0 8074FD9C: 7C601B78 mr r0,r3 8074FDA0: 90040050 stw r0,80(r4) 8074FDA4: 3E8080A1 lis r20,-32607 8074FDA8: 8074F108 lwz r3,-3832(r20) 8074FDAC: 38630054 addi r3,r3,84 8074FDB0: 4800A1B5 bl 0x80759f64 8074FDB4: 8074F108 lwz r3,-3832(r20) 8074FDB8: 38000000 li r0,0 8074FDBC: 94030054 stwu r0,84(r3) 8074FDC0: 90630004 stw r3,4(r3) 8074FDC4: 90030008 stw r0,8(r3) 8074FDC8: 3C6080A1 lis r3,-32607 8074FDCC: 9803EE6C stb r0,-4500(r3) 8074FDD0: 82D4F108 lwz r22,-3832(r20) 8074FDD4: 3AB6000C addi r21,r22,12 8074FDD8: 8296000C lwz r20,12(r22) 8074FDDC: 4800005C b 0x8074fe38 8074FDE0: 7E83A378 mr r3,r20 8074FDE4: 38800001 li r4,1 8074FDE8: 4BC3E88D bl 0x8038e674 8074FDEC: 2C030000 cmpwi r3,0 8074FDF0: 4182001C beq- 0x8074fe0c 8074FDF4: 3AB4008C addi r21,r20,140 8074FDF8: 7E83A378 mr r3,r20 8074FDFC: 38800001 li r4,1 8074FE00: 38A00000 li r5,0 8074FE04: 4BC3E849 bl 0x8038e64c 8074FE08: 4800002C b 0x8074fe34 8074FE0C: 8014008C lwz r0,140(r20) 8074FE10: 90150000 stw r0,0(r21) 8074FE14: 7E83A378 mr r3,r20 8074FE18: 4BC3DE05 bl 0x8038dc1c 8074FE1C: 7C641B78 mr r4,r3 8074FE20: 38760004 addi r3,r22,4 8074FE24: 4BC3DA45 bl 0x8038d868 8074FE28: 7EC3B378 mr r3,r22 8074FE2C: 7E84A378 mr r4,r20 8074FE30: 4BC3D9F9 bl 0x8038d828 8074FE34: 82950000 lwz r20,0(r21) 8074FE38: 2C140000 cmpwi r20,0 8074FE3C: 4082FFA4 bne+ 0x8074fde0 8074FE40: 3C6080A1 lis r3,-32607 8074FE44: 8063F108 lwz r3,-3832(r3) 8074FE48: 3AA30034 addi r21,r3,52 8074FE4C: 3AD50008 addi r22,r21,8 8074FE50: 8083003C lwz r4,60(r3) 8074FE54: 3A800000 li r20,0 8074FE58: 48000030 b 0x8074fe88 8074FE5C: 80040000 lwz r0,0(r4) 8074FE60: 2C000000 cmpwi r0,0 8074FE64: 40820018 bne- 0x8074fe7c 8074FE68: 80040008 lwz r0,8(r4) 8074FE6C: 90160000 stw r0,0(r22) 8074FE70: 7EA3AB78 mr r3,r21 8074FE74: 4BC3D575 bl 0x8038d3e8 8074FE78: 4800000C b 0x8074fe84 8074FE7C: 3AC40008 addi r22,r4,8 8074FE80: 92840000 stw r20,0(r4) 8074FE84: 80960000 lwz r4,0(r22) 8074FE88: 2C040000 cmpwi r4,0 8074FE8C: 4082FFD0 bne+ 0x8074fe5c 8074FE90: E3E10108 psq_l f31,264(r1),0,0 8074FE94: CBE10100 lfd f31,256(r1) 8074FE98: E3C100F8 psq_l f30,248(r1),0,0 8074FE9C: CBC100F0 lfd f30,240(r1) 8074FEA0: E3A100E8 psq_l f29,232(r1),0,0 8074FEA4: CBA100E0 lfd f29,224(r1) 8074FEA8: E38100D8 psq_l f28,216(r1),0,0 8074FEAC: CB8100D0 lfd f28,208(r1) 8074FEB0: 396100D0 addi r11,r1,208 8074FEB4: 4B90E001 bl 0x8005deb4 8074FEB8: 80010114 lwz r0,276(r1) 8074FEBC: 7C0803A6 mtlr r0 8074FEC0: 38210110 addi r1,r1,272 8074FEC4: 4E800020 blr Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 10:36:58 PM What game? What loader/code handler? (look at Tools tab to identify handler) What C2 code?
There's something fishy about that ASM. Look at the pattern. I'm going to insert line breaks so that the pattern becomes obvious. 8074F660: DBE10100 stfd f31,256(r1) 8074F664: F3E10108 psq_st f31,264(r1),0,0 8074F668: DBC100F0 stfd f30,240(r1) 8074F66C: F3C100F8 psq_st f30,248(r1),0,0 8074F670: DBA100E0 stfd f29,224(r1) 8074F674: 909D0040 stw r4,64(r29) # ???? Should be psq_st f29,232(r1),0,0 8074F678: DB8100D0 stfd f28,208(r1) 8074F67C: F38100D8 psq_st f28,216(r1),0,0 This stands out to me because it's the "right" way to push/pop the float registers on the Wii. The Wii supports Paired Singles (ps*) instructions, which operate on two single-precision floats in one float register. The float regs are actually 64-bits, but the code handler only displays the first 32-bits. It is an error to load a double (= 64-bit float) and then store as a Paired Singles (= two 32-bit floats). Therefore, to ensure there are no errors, float regs are pushed and popped as both doubles and paired singles. Something is over-writing your ASM. Check 8074F674 without any codes activated and I bet you'll see psq_st f29,232(r1),0,0 EDIT3: Another fishy thing to look for. Where did r29 come from? Arguments are passed in using r3-r10. Arguments are never passed in using r14-r31. Nothing in the beginning of the function has loaded r29. A compiler following the EABI would never do this. EDIT4: Look at the function epilogue, which pops the float regs off the stack. Notice the symmetry with the function prologue. 8074FE90: E3E10108 psq_l f31,264(r1),0,0 8074FE94: CBE10100 lfd f31,256(r1) 8074FE98: E3C100F8 psq_l f30,248(r1),0,0 8074FE9C: CBC100F0 lfd f30,240(r1) 8074FEA0: E3A100E8 psq_l f29,232(r1),0,0 8074FEA4: CBA100E0 lfd f29,224(r1) 8074FEA8: E38100D8 psq_l f28,216(r1),0,0 8074FEAC: CB8100D0 lfd f28,208(r1) EDIT: You should avoid speculating about what happens in the code handler unless you have studied it. This crash is nowhere near checkexisend, which exists way down in 80002XXX range. EDIT2: Check for GCT Code Undo which is poking something it shouldn't be. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 10:44:32 PM There's something fishy about that ASM. Look at the pattern. I'm going to insert line breaks so that the pattern becomes obvious. you´re right, it´s a psq_st on disassembly (when game is running) but it froze on that stw that popped up on breakpoints tab. 8074F674: 909D0040 stw r4,64(r29) # ???? Should be psq_st f29,232(r1),0,0 Something is over-writing your ASM. Check 8074F674 without any codes activated and I bet you'll see psq_st f29,232(r1),0,0 I sent a C2 code to hook the button address on main screen. It´s handler 1931. Weird thing is that it doesn´t freeze anymore when the ASM has changed due to selecting a different spot in-game (8074F674 has different instructions now) Even though, the actual code is hooking "base" assembly. Undo was correct. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 10:47:53 PM "when the ASM has changed"?
You should never use GCT Code Undo on ASM that changes. You should never C2 hook ASM that changes. If the ASM changes, you will need an F2 code to make sure you only patch it when the right ASM is loaded. You say "undo was correct", but are you sure? If the ASM is changing, you can "undo" the wrong value. Load the game with pause-start. Look at the ASM. Nothing will have been swapped in yet, so if it's not what you expect to see then you cannot hook it with a C2 code and you cannot use GCT Code Undo. Quote (8074F674 has different instructions now) !!! You CANNOT use C2 codes or GCT Code Undo on ASM that changes. That's all there is to it. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 10:48:49 PM listen!
The ASM where it crashed changes (8074F674) Not the hook I used (it was something like 8010XXXX) After it changed once, sending that code doesn´t cause that crash anymore I noticed. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 22, 2011, 10:49:53 PM >.>
I might have known that, had you bothered to...you know...show me the C2 code like I asked. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 22, 2011, 10:50:23 PM show me the C2 code like I asked. C210XXXX 00000007 39600400 7D6C0038 7C0B6000 40A20024 8163FED0 2C0B000F 40800010 396B0001 7C0C0050 48000008 39600000 9163FED0 90030000 00000000 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 23, 2011, 12:18:53 AM Okay, well, it sounds like it's not Gecko.NET's problem, but your code's problem. And since you won't tell me the name of the game, and you're censoring the hook address, I'm guessing this is a code for a wifi game.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 23, 2011, 01:02:15 AM Okay, well, it sounds like it's not Gecko.NET's problem, but your code's problem. And since you won't tell me the name of the game, and you're censoring the hook address, I'm guessing this is a code for a wifi game. Seems like I need to send the code later to prevent it from freezing.I just didn´t want to "release" that one, that´s why I censored it. ::) But I´ll tell you what it does: It´s a button rapidfire code with adjustable fire rate. A lá mdmwii, just not for mkwii this time. It´s pretty much universal for all games, if one puts the right default instruction and hook (breakpoint write on button address). Interesting code :D Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 23, 2011, 04:18:03 AM Store Immediately is kinda obsolete now that GCT's autosave. Heh. Ah sounds great. now you can reuse that button XD.What happened to "next frame"? I could've sworn it was there before. I was about to go to the next frame after breakpointing to see the effects in memory. But the button doesn't exist anymore. >.> Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 23, 2011, 04:20:54 AM <.<
Next frame is multiplexed with the Pause game button. When you press "Pause Game" it turns into Next Frame. When you hit Run, Next Frame turns back into Pause Game. ...perhaps hitting a breakpoint doesn't change the button's text from Pause Game to Next Frame? You should be able to just click Pause Game anyway. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 23, 2011, 04:25:00 AM oh there it goes. thanks. This helps me better understand what some instructions are doing.
---Moar request In the notepad, can you add sub tabs to it? Or something that can expand/collapse. Sorry about this one. It's kind of random, but my notes are starting to get a bit sloppy both in my txt and the built in notepad which should've been neater thanks to the tabs. Add like "<entry name="subgroup">" or something with "content" enclosed in that tag. And add a save button to it. Because when I randomly disconnect, the notepad closes. And that closing might not save anything I put there. It might, though.. Not sure. Never actually happened to me, but it I just checked to see what would happen if I unplugged the usb gecko. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on August 23, 2011, 09:44:26 PM And add a save button to it. Because when I randomly disconnect, the notepad closes. And that closing might not save anything I put there. It might, though.. Not sure. Never actually happened to me, but it I just checked to see what would happen if I unplugged the usb gecko. Yep, the notepad doesn´t always save when it closes.Often happens to me. That´s why I use the "normal" editor notepad. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 26, 2011, 12:26:38 AM Even though you're taking a break from this,
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 26, 2011, 12:50:57 AM Don't use b0. Gecko.NET considers it reserved for extended codes. If it finds a pointer there it assumes it's a pointer to the extended code list.
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on August 26, 2011, 01:08:25 AM ah. I was thinking about that just now. I'll go edit the code then. But what about the cheats sent disabling my codes thing? Was it always like that. I don't think it was. It only if I send codes the first time.
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on August 26, 2011, 01:14:19 AM When you send codes, only the ones that are checked will be sent. Any codes that aren't checked (for instance, codes loaded via SD cheats) will not be sent again; they will be lost.
Some codes only need to be applied once. e.g. most 04 ASM patches. They're the kinda thing that needs GCT Code Undo'd. Other codes need to be applied every frame and if they aren't in the code list they won't be in effect. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 01, 2011, 11:34:56 PM I don´t get it.
I boot up MKWii, start a race, everything is normal. Then, I´ll send an empty codeslist with gecko.net (0/215 codes). The timer suddenly freezes (time stop). Why does that happen each time I press "Send codes"? I don´t have a gct enabled. I once messed around with branches to get a timer hack. Since then, it always happens when sending codes. ...what the hell? I don´t want to enable these FTW cheats. --- EDIT 2: I wish it was possible to save codeslists containing variables. I don´t like the "fill with 0´s". It´s not possible to undo the code filling part. :eek: Instead, it could say "Error sending codes, variables not set" and refuse to send the code(s) to prevent crashes. It should still reformat codes correctly, but not changing anything inside it. It obviously freezes, too, if that messed code was then send. There´s no difference btw. a "filled with 0´s messed code" and a "code containing invalid characters". Crashes either way, but second one is more useful to work with. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 14, 2011, 04:22:30 PM My gecko driver was at 2.2.4.0 and for some reason, windows didn't want to update it. Gecko.net says it's fine, so I didn't know until now after reading this (http://wiird.l0nk.org/forum/index.php/topic,8178.0.html). Updating now, and it'll hopefully stop the random disconnects. Looks like Sharkbyte was having the same problem just on windows 7 64-bit, which I am upgrading to as soon as my laptop gets here. It's the only reason I found the thread. XD
------------ Anyway, moar bugs to queue: The gct list is awkward. I think it happened because you did the gct tab speed up thing. It's hard to click on a different code without swapping them and it does some kind of loading thing when that happens and also when you check/uncheck the code. It might be related to Bully's bug. Also with the gct tab, this is a bug(imo) and a request at the same time. I wish I said something earlier cuz this was always there, just not important. I don't want to rename the code when I click it while it's selected. If I want to rename it, I should have to double click it. It sounds silly, but I click already selected codes because the swapping thing confuses the hell outta me and I just want to make sure I'm looking at the right code. And the renaming thing also happens when I am trying to swap to codes. It bugs me now because my code list is cluttered with unnamed experimental codes that I don't bother to delete, and yeah. Pretty bootleg. ------ Another thing was the connection error message. It needs to not be centered with Gecko.net. When the message pops up it's just behind Gecko.net cuz it's set to always on top and you can't move the window to get to the popup box. Instead, you have to right click the error message in the taskbar and select move so you can move it from behind Gecko.net. The next message box with the red X too. ------ I did have a request, but I haven't posted due to the hiatus, but now I can't remember what it was. It was a big deal at the time...Well any future ideas, I'll be posting from now on so that doesn't happen. Give you a nice big queue to take care of when you get back to this. XD Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on September 18, 2011, 09:37:25 AM Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error. Here's the log:
9/18/2011 4:29:45 AM: Opened log 4:29:45 AM: Exception occured! Exception: FTDIUSBGecko.EUSBGeckoException FTDIInvalidReply Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown. Stack Trace: at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump) at GeckoApp.MemSearch.VerifyDump(Dump checkDump, Int32 leftIndex, Int32 rightIndex) at GeckoApp.MemSearch.SafeDump(UInt32 startdump, UInt32 enddump, Dump memdump) at GeckoApp.MainForm.ToolsDump_Click(Object sender, EventArgs e) Inner Exception: I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight, and I'm fairly confident that r115 (the previous version I was using) didn't have any of these problems. One of the other crashes I got was when I had auto-update in the memview turned on, while the game was paused... it went up to like 500 updates per second, and then suddenly got a USB Gecko error. Unfortunately I don't think I have a log of that one. I'm using Neogamma beta 50, so it's a current code handler. Is this a known bug? Any other info I can provide to help diagnose it? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 18, 2011, 02:57:22 PM Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error. Here's the log: ... I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight When you say "the latest Gecko.NET", are you using the latest test build? I haven't updated the "official build" link in some time. The About tab should say 0.66.8; if it doesn't, click "latest test build" in my sig. The errors you describe appear to relate to bugs I believe I already found. Especially the Memory Viewer thing. Also, you didn't try to switch tabs during the Tools tab dump, right? That would screw things up. Another thing to keep in mind. Gecko.NET applies patches to the debugger in order to fix bugs. The patches are applied when you connect to the game. However, if you connect to the game, and it crashes, and you leave Gecko.NET alone and restart the game, and then try to continue using Gecko.NET, it won't know that the game has been restarted and the patches won't be applied. Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed. If you don't click Reconnect, then you will continue to experience bugs. Also, you should be able to go to the Tools tab and see what version of the code handler you're running. It will be either GOSM (Gecko OS Mod), 1931, 1932, or ??? --- The gct list is awkward. I think it happened because you did the gct tab speed up thing. It's hard to click on a different code without swapping them and it does some kind of loading thing when that happens and also when you check/uncheck the code. I think I know what you're talking about. The 1932 code handler automatically unhooks C2/D2/F2/F4 codes when you send new codes. It can do this because it keeps an Unhook List at the end of the code list. As a result, the Unhook list takes up some space that would otherwise belong to codes. Therefore, whenever you check or uncheck a code, I dump the code handler to see whether you're using the 1932 code handler (I also check for the extended codes pointer during this step). And then if you are, I dump the code list and grab the size of the unhook list, and subtract it from the total amount of active codes available. Unfortunately, I think for 1931 handlers, the step where I examine which handler you're using causes a glitch with the mousedown/mousedrag event for the code listbox. I'm not quite sure how to fix this. I think you can compensate somewhat by using arrow keys and the space bar. Quote I don't want to rename the code when I click it while it's selected. If I want to rename it, I should have to double click it. I'm not sure this request is possible. The click-renaming functionality is handled by Windows itself, and I would have to do some research to determine whether you can over-ride how the listbox base class handles clicks for renaming and such. Quote Another thing was the connection error message. It needs to not be centered with Gecko.net. When the message pops up it's just behind Gecko.net cuz it's set to always on top and you can't move the window to get to the popup box. hr'm. Probably because the messagebox should have had the main form as its parent, then it might inherit the value of the AlwaysOnTop property. By the way, if you hold shift while you start Gecko.NET it won't try to auto-connect. You should also be able to alt-tab to the messagebox. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 18, 2011, 04:41:43 PM I'm not sure this request is possible. The click-renaming functionality is handled by Windows itself, and I would have to do some research to determine whether you can over-ride how the listbox base class handles clicks for renaming and such. :/ Isn't there a onClick and onDoubleClick event? That wouldn't be enough to over ride it? Anyway, I'll try changing window's clicking setting and see if it changes anything.Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed. If you don't click Reconnect, then you will continue to experience bugs. Reminds me of a bug. If you reset without disconnecting, first it doesn't notice that you've reset, so no error message for some reason. Probably because of the loading screen fix. :/ But the main bug, after resetting, if you click Reconnect without disconnecting, the game will freeze. You can handle the exception if you do something but the message won't pop up until that something happens. idk what "something" is. I never debugged any of the errors. I always reset. >.<Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 18, 2011, 04:55:06 PM Some .NET controls (TextBox is well-known for this) handle some events "beneath" the .NET framework, in "Win32 land". It can be quite difficult to intercept these things, and occasionally involves sub-classing base classes and forwarding messages and other Win32 voodoo. It might not be hard to make double-click do a rename, but the tricky part is getting it to stop renaming after a single click.
--- Quote Reminds me of a bug. If you reset without disconnecting, first it doesn't notice that you've reset, so no error message for some reason. Probably because of the loading screen fix. :/ But the main bug, after resetting, if you click Reconnect without disconnecting, the game will freeze. You can handle the exception if you do something but the message won't pop up until that something happens. idk what "something" is. I never debugged any of the errors. I always reset. >.< Err....what? You lost me. Reset = reboot the game? Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on September 19, 2011, 12:17:04 AM Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error. Here's the log: ... I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight When you say "the latest Gecko.NET", are you using the latest test build? I haven't updated the "official build" link in some time. The About tab should say 0.66.8; if it doesn't, click "latest test build" in my sig. The errors you describe appear to relate to bugs I believe I already found. Especially the Memory Viewer thing. Also, you didn't try to switch tabs during the Tools tab dump, right? That would screw things up. Another thing to keep in mind. Gecko.NET applies patches to the debugger in order to fix bugs. The patches are applied when you connect to the game. However, if you connect to the game, and it crashes, and you leave Gecko.NET alone and restart the game, and then try to continue using Gecko.NET, it won't know that the game has been restarted and the patches won't be applied. Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed. If you don't click Reconnect, then you will continue to experience bugs. Also, you should be able to go to the Tools tab and see what version of the code handler you're running. It will be either GOSM (Gecko OS Mod), 1931, 1932, or ??? Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 19, 2011, 02:15:04 AM :/ well don't sweat it. It's really annoying, but even more annoying is that swapping glitch. I'll have to update gecko os.
Err....what? You lost me. Reset = reboot the game? Yeah. Rebooting the game. I forgot there was a reset button. lol. idk if it happens there too. I could check. So rebooting the game without disconnecting the gecko.net, gecko.net doesn't notice, and clicking reconnect without first disconnecting freezes the game. No cheats. Maybe inf rage cuz I'm too lazy to delete the gct. But that's not a C2 code. Disconnecting first clears the funkiness.Ways I would imagine you could fix this would be to make it check for the patches on every connect(which I'm not too exited about. But I believe it has to do with it expecting the patches to be there.), or make it notice that you've turned of the game(which would probably bring back the loading bug. No liek :/) Another thing was if you BP, and disconnect, you can't unpause the game when you reconnect. It's not a big issue since my random disconnects is fixed, but it was annoying before when I would try to follow some asm and suddenly I disconnect. I'd have to reset and it doesn't catch that exception. But it still haunts me. The other day I was in a BP for a while and forgot about it. Then I clicked disconnect turned around and "ffffff >.<". I tried to reconnect and run game, but nope. It was paused forever. What do you mean by latest test build? You released 0.66.8 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg73292.html#msg73292). Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 21, 2011, 06:26:35 PM :/ well don't sweat it. It's really annoying, but even more annoying is that swapping glitch. I'll have to update gecko os. Actually, there's no real motivation to use 1932. It has a significantly smaller code list, and the two primary fixes (unhooking C2 codes, and debugging code handler crashes) are handled via GCT Code Undo and a debugger patch, respectively. 1932 was useful before I started patching debuggers, but these days loaders with 1931 are the way to go.Quote Yeah. Rebooting the game. I forgot there was a reset button. lol. idk if it happens there too. I could check. So rebooting the game without disconnecting the gecko.net, gecko.net doesn't notice, and clicking reconnect without first disconnecting freezes the game. Very odd. I know for a fact that it doesn't happen for me like that. I have reconnected after a crash several times.I do know that during boot, the USB Gecko sends a byte to the PC. I have a special (Visual Studio) breakpoint in the source code when running with the VS Debugger attached to Gecko.NET. It is for catching left-over bytes like that. But it discards any bytes it wasn't expecting, and the breakpoint isn't triggered if no debugger is attached to Gecko.NET. Quote Ways I would imagine you could fix this would be to make it check for the patches on every connect(which I'm not too exited about. But I believe it has to do with it expecting the patches to be there.) I'm pretty sure it already does this. Immediately after connecting, I dump the code handler and search for the checkexisend routine. I use the address of checkexisend to determine which version of the code handler you're running. Then I check exireceivebyte, which gets the rx debugger patch, to see whether the handler has been patched or not. If exireceivebyte is unpatched, I poke all the patches in a very specific order to prevent any crashes, because pokes are always invalidated and flushed, which is important when modifying ASM that might be executed soon.Quote Another thing was if you BP, and disconnect, you can't unpause the game when you reconnect. I'm not sure what you mean here. If you're at a BP, with the game currently frozen? If you set a BP, but it hasn't been hit yet? Quote What do you mean by latest test build? You released 0.66.8 (http://wiird.l0nk.org/forum/index.php/topic,4886.msg73292.html#msg73292). I refer to "official builds" as a build which is relatively stable, and gets promoted to the first post of the release thread with a summary of the major changes since the last official build. I refer to "test builds" as builds which are posted at the end of the release thread. They're like beta builds; they're stable enough for me but I want some other people to bang on it to see if anything breaks. You can see this reflected in my sig; the "release thread" points to the first post and the "latest test build" points to the last post.--- Yes, I'm on 0.66.8. I did not switch tabs during the dump. However, I just tried the old version which worked fine for me before, and I got a crash there too. So now I'm wondering if my USB Gecko is screwed up. I have a spare USB Gecko, so I'll try it out and report back on whether that fixes it. Hm. I was pretty sure I fixed the problem that was causing this issue. I don't think it would really be a USB Gecko issue...if the USB Gecko was bad you'd wouldn't even get a connection. Others had the same issue where Memory Viewer auto-update would cause a freeze. But that was fixed in between the last official and the most recent test build. That's why I wanted to verify that on the Tools tab, that it says "Driver Good" and "Handler: 1931" Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 21, 2011, 11:21:33 PM Very odd. I know for a fact that it doesn't happen for me like that. I have reconnected after a crash several times. I'll get back to you on this. It might be related to something else. I would've made a video to demonstrate it, but it didn't freeze on reconnect. Gecko.net didn't notice the disconnect, though.I do know that during boot, the USB Gecko sends a byte to the PC. I have a special (Visual Studio) breakpoint in the source code when running with the VS Debugger attached to Gecko.NET. It is for catching left-over bytes like that. But it discards any bytes it wasn't expecting, and the breakpoint isn't triggered if no debugger is attached to Gecko.NET. When you hit a BP and the game freezes, if you disconnect for whatever reason, you can't unpause when you reconnect. Another fun fact is that you can step into once. And then you can't step into anymore. Clicking the button makes the asm "jiggle" like it was gonna go to the next one but it can't. You might want to classify 2.2.4.0 as something other than "Good". Updating the driver seemed to stop the random disconnects. So it's no good. lol. Windows update didn't want to update it, though. Not even on Windows 7. W7 installed 2.2.4.0 automatically and said it was the best match for this device. No need to update. :/ What is the utilities for? I can browse to them and select them, but for nothing. I thought it would've let me open pyiiasmh by clicking a button there, but it just becomes a non link without adding extra functionality. It does have a button for tracer. Whatever that is. But nothing else. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 21, 2011, 11:49:39 PM You might want to classify 2.2.4.0 as something other than "Good". Updating the driver seemed to stop the random disconnects. So it's no good. lol. Windows update didn't want to update it, though. Not even on Windows 7. W7 installed 2.2.4.0 automatically and said it was the best match for this device. No need to update. :/ I don't label 2.2.4.0 as "good". It should only accept a driver with a version at or above 2.8.14.0. Gecko.NET checks the driver version when connecting to the USB Gecko, so if you aren't connected it might show "Driver Good" when it's not. Windows Update rarely has the latest driver for any hardware. You will have to go to the manufacturer's web site in order to get the latest version. http://www.ftdichip.com/Drivers/D2XX.htm They have a beta version, 2.8.17, but 2.8.14 is WHQL signed so I would go with that one. Quote What is the utilities for? I can browse to them and select them, but for nothing. I thought it would've let me open pyiiasmh by clicking a button there, but it just becomes a non link without adding extra functionality. It does have a button for tracer. Whatever that is. But nothing else. ASMWiiRD and PyiiASMH can be launched by right-clicking a code in the listbox on the GCT tab. It checks to see if an instance of ASMWiiRD or PyiiASMH is already open. If so, it brings it to the front; if not, it launches one.Then, for ASMWiiRD, it will automatically copy and paste the full contents of the code into the appropriate textbox and have it converted to ASM, using some magic win32 tricks. For PyiiASMH, because it's built in Python I can't perform those win32 tricks. So instead, the contents of the code are put into the clipboard. You will have to paste and convert on your own. The Pointer search is required for the Pointer tab to work. Tracer is a SNES disassembler. It's useful if you're hacking SNES VC games. You can pipe the output of Tracer into the RiiTracer app that I package with Gecko.NET, too. Title: Re: Gecko dotNET Bugs and Requests Post by: biolizard89 on September 24, 2011, 12:49:55 AM Yes, I'm on 0.66.8. I did not switch tabs during the dump. However, I just tried the old version which worked fine for me before, and I got a crash there too. So now I'm wondering if my USB Gecko is screwed up. I have a spare USB Gecko, so I'll try it out and report back on whether that fixes it. Hm. I was pretty sure I fixed the problem that was causing this issue. I don't think it would really be a USB Gecko issue...if the USB Gecko was bad you'd wouldn't even get a connection. Others had the same issue where Memory Viewer auto-update would cause a freeze. But that was fixed in between the last official and the most recent test build. That's why I wanted to verify that on the Tools tab, that it says "Driver Good" and "Handler: 1931" EDIT: It's 2.8.14.0. So I doubt it's the driver. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 24, 2011, 01:47:49 PM when no usb gecko is connected and one moves to the "tools" tab there´s a button that says "update driver".
Clicking it gives an error message instead of guiding one to a site where the newest driver can be found. (Unhandled error, bla bla) --- I hate those code sending bugs (gecko.net 0.66.8.) It is NEVER my fault that it crashes. Most of the games I tried just freeze when I send a code that doesn´t crash when it is poked (e.g. 04 code). It then shows some .word instruction (or sometimes valid ASM that crashed with legit codes) as crash breakpoint. Also, if I set a XBP on moving assembly and it then moves -> game pauses and is crashed (tested on Mario Sports Mix): 800028D0: 00000000 .word 0x00000000 CR:88222888 XER:00000000 CTR:81601AA4 DSIS:00000000 DAR:00000000 SRR0:800028D0 SRR1:00089032 LR:81602668 r0:00000001 r1:805D8C58 r2:805CA980 r3:00000000 r4:80ACC2A0 r5:81640000 r6:81630000 r7:00000004 r8:636F6E00 r9:000000E0 r10:805D8D28 r11:805D8CA8 r12:81601AA4 r13:805C87C0 r14:00000000 r15:00000000 r16:00000000 r17:80ACE740 r18:00000000 r19:80ACE740 r20:00000000 r21:00000000 r22:00000000 r23:80ACE740 r24:81637368 r25:80B7A040 r26:81636CB8 r27:80ACC728 r28:816375B0 r29:81640E30 r30:81641158 r31:43300000 800028C8: 04ACC878 .word 0x04acc878 The game doesn´t recover.CR:88200888 XER:00000000 CTR:81601AA4 DSIS:00000000 DAR:00000000 SRR0:800028C8 SRR1:00089032 LR:81602668 r0:00000001 r1:805D8C58 r2:805CA980 r3:00000000 r4:80ACC2A0 r5:81640000 r6:81630000 r7:00000004 r8:636F6E00 r9:000000E0 r10:805D8D28 r11:805D8CA8 r12:81601AA4 r13:805C87C0 r14:00000000 r15:00000000 r16:00000000 r17:80ACE740 r18:00000000 r19:80ACE740 r20:00000000 r21:00000000 r22:00000000 r23:80ACE740 r24:81637368 r25:80B7A040 r26:81636CB8 r27:80ACC728 r28:816375B0 r29:81640E30 r30:81641158 r31:43300000 Another example, I sent the following code (Mario Sports Mix again) 284CDDA2 FDFF0200 04ACC878 00000100 04ACC8A0 07000100 04ACC8C8 07000100 E0000000 80008000 INSTANT freeze. (No crash BP, gecko.net disconnects from the game) The button activator obviously wasn´t pressed, so the code didn´t do anything. However: This bug doesn´t occur on all games, but on too many. --- In opposite to these crashes, everything works fine with WiiRd GUI (and older Gecko.net builds). It must be one of the patches... if a patch crashes, it definetely missed the point. :-\ Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 25, 2011, 04:13:53 AM when no usb gecko is connected and one moves to the "tools" tab there´s a button that says "update driver". This didn't happen to me. It takes me to the site with no problems.Clicking it gives an error message instead of guiding one to a site where the newest driver can be found. (Unhandled error, bla bla) The crashing thing...it might be your wii. I know that sounds weird and maybe I should just try another game, but before that, I don't experience that in monster hunter. Except for sometimes with 1 code that I can't share. I thought the issue was solved, but I was having trouble with it the other day. It was a memory copy code. Anyway, I used the usbgecko on my friend's wii, and at some point I was stuck in a black screen. I didn't know what happened, but I immediately said "your wii is bootleg". I was testing some C2 codes and looking at his friends list(s) in memory cuz he has more than 1 capcom id. I just wanted to see if they are all in memory. But...I messed up with his friend requests and ended up making him friend me in the same slot as his 1st id and with the same character >.>. And the crashing thing just f***ed the mood up. But I don't think this is the same crash. Yours is as soon as you send codes. I don't remember if I sent more codes during the crash, but that was out of nowhere and unexpected and doesn't happen on my wii even with my old unstable connection when I had the old drivers. Is it possible to use wild cards in memview searches searches? If so, how? If not, that would be a nice feature. The standard wild cards would be nice. # for any number(in ansi), ? for any character(I think), and * for any string. This way I could do a hex search for ??????03??????02??????03??????01??????01 and whatnot and find a 20 byte string with 03 on the 4th, 02 on the 8th and so on. Because I have no idea what I'm looking for except for the fact that the last byte might be an item's rarity. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on September 25, 2011, 06:32:18 PM well, sometimes it works again on some games with code sending.
Pretty weird... @Stuff: MH3 is fine, only some specific games have code sending crashing issues. "CoD Black Ops Zombie Mode" "Mario Kart Wii" "Mario Sports Mix" are critical with codes sending for me. Okay, the "update driver" link does work. Probably my fault. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 28, 2011, 03:56:30 PM I know a while back I asked for dumps to be "read only" in the disassemble tab, but now I've found an awesome bug. Assembling doesn't change the..assembly. >.> This is what happened
originally: 8011F924: A87D083C lha r3,2108(r29) 8011F928: 7C7B1850 sub r3,r3,r27 So I assembled this: 8011F928: 38600000 li r3,0 Tail wasn't coming off. I didn't understand. So I step into: 8011F924: A87D083C lha r3,2108(r29) ##r3=35 8011F928: 38600000 li r3,0 ##r3=26 (wuuuuut? shouldn't it be 0?!) r27 happens to be 9 Well that was bootleg. I thought maybe the game was being stubborn so I sent this code: 0411F928 38600000 Tail came off from my weakest hit which was definitely < 26 dmg. I can't understand how that works. A change in asm fails but a change in asm doesn't? Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on September 28, 2011, 04:06:43 PM Was the disassembly tab source a dump? If so, the dump was modified, and the BP tab was likely reading its disasm from the dump instead of the USB Gecko. It probably shouldn't, but oh well, you'll just have to remember to set the disasm source to USB Gecko.
When the disasm source is a dump, it is both read from and written to. The main purpose for assembling dumps is so you can write "absolute branches" into the assembler and it will calculate the offset from the instruction being changed to the address you're trying to branch to. Otherwise, you need some sort of calculator and some bit masking. If you want to open a dump while using the USB Gecko, I recommend opening *two* instances of Gecko.NET. One trick is holding shift while opening the second instance, which prevents it from trying to connect to the USB Gecko. Then, set the first instance's disasm source to the USB Gecko, and the second instance to a dump. This also allows you to open multiple dumps as well, by loading third/fourth/etc instances. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on September 28, 2011, 06:24:44 PM hmm...I was looking at a dump before setting this breakpoint, but I switched to usbgecko. The dump looks untouched. I checked all three just incase. They're untouched. I remember noping a branch and doing that li. They're not in there. Maybe it was reading memory and writing to nothing because I had a dump open before. >.> Sounds like a bug anyway.
One trick is holding shift while opening the second instance, which prevents it from trying to connect to the USB Gecko. That's awesome. I think you mentioned this before, but I never actually used it. It would be nice if some other button did this though. Like ctrl. You can press it after double clicking the .exe. And you know. Windows does that shift thing.Another possible bug that wasted 15mins of my life(oh noes). In the search tab, I was doing specific search and every time I refined, it started a new search instead. I noticed after feeling that it was taking too long doing this 5th/6th search. So the next search I noticed that it went from 900ish pages to 1000ish pages. That's not right >.<. And then I realized it wasn't showing anything in the old results column. I think this happened because I started with an unknown search, didn't continue, and hit restart to start a specific search. That was the last thing I did. I had to close gecko.net to get some valid searches. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 03, 2011, 02:01:17 PM Another possible bug that wasted 15mins of my life(oh noes). In the search tab, I was doing specific search and every time I refined, it started a new search instead. I noticed after feeling that it was taking too long doing this 5th/6th search. So the next search I noticed that it went from 900ish pages to 1000ish pages. That's not right >.<. And then I realized it wasn't showing anything in the old results column. I think this happened because I started with an unknown search, didn't continue, and hit restart to start a specific search. That was the last thing I did. I had to close gecko.net to get some valid searches. yeah, often happened to me that the search never takes previous results and always starts a new search on refine.It seems like it happens when one cancels an existing search and starts a new one (unknown value). Well, happens pretty randomly also :( But once it happens, one can fix it by closing gecko.net. I noticed that gecko.net sometimes freezes after one search was completed. Probably when one "spams" refines or something like that. One can´t push any button and the application doesn´t recover also. Only way to close it is task manager and the search obviously gets lost. :rolleyes: Maybe you can add an option to "remember" search results on gecko.net next time it´s opened until one restarts the search? Address remembering on disassembly doesn´t work right. Each time I boot the app, it get´s to a low 8000XXXX address that contains a branch instruction. Above it, there are only .word´s. (Same for any game I tried) And if one opens a mem90 dump, everything gets recognised as mem80 addresses. If I ctrl + M a mem90 address on gct codes tab, it always guides me to mem80 in memory. Example: 92345678 will guide me to -> 80345678 but since my input is an mem 90 address, it should go there instead of thinking that 92 was a mem80 codestype. Thanks, Bully Title: Re: Gecko dotNET Bugs and Requests Post by: The D3mon on October 14, 2011, 01:58:36 PM Do not know if this request was posted before or if it is possible.
I was thinking how nice it would be to memory view a set of address you want to look at at the same time it would be simialar to the multi poke. With exception of in memory viewer. To explain this better You do a search usually can get it done to 20 or so address. Then ctrl select the 20 or so address right click and select memory view when you get to memoryview you only see the address you want to see. I think this would help narrow down some address easily instead of poking a address that may cause a freeze. Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 14, 2011, 02:25:07 PM I think the Watch List tab does that already. It can be a little flakey, though.
Title: Re: Gecko dotNET Bugs and Requests Post by: The D3mon on October 14, 2011, 05:23:41 PM I have yet to realy need to use the watch tab but will check it out. I think I might have used it once but has been awhile
Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on October 21, 2011, 09:12:57 AM Something with recent versions of geckoDotNET has slaughtered the rebooter.
start geckoOS 1.9.3.1 select paused start, OSThreadSleep hook start the rebooter start geckoDotNET on the computer press "run game" using 0.64.3 the system menu will start up like it is supposed to. using 0.65, it just hangs forever with a blackscreen Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 21, 2011, 02:13:11 PM Weird, I never tried rebooter.
0.65 is old, though. I never updated the first post. You should use 0.66.8 instead. http://wiird.l0nk.org/forum/index.php/topic,4886.msg73292.html#msg73292 EDIT: I tried rebooter and I had no problem connecting to it. But you have to wait until the system menu is running before you can connect to it. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 23, 2011, 09:00:41 AM I find it interesting that you avoided my typo fixed gecko.net, dcx2.
I didn´t do anything else to it, except for changing the version number and fixing "availible" :P (http://image-upload.de/image/VUYHTN/e79fe41bfe.jpg) Hope there will be updated builts again some time like e.g. moving the "Codes saved!" message to the status bar. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on October 23, 2011, 04:59:35 PM actually, "0.66.9" was a little slower for some reason. Still, I thought it was interesting that you did that, so it's not on my shift+del queue. But I do use 0.66.8 still and now I always notice "availible" XD.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 23, 2011, 07:56:50 PM actually, "0.66.9" was a little slower for some reason. Still, I thought it was interesting that you did that, so it's not on my shift+del queue. But I do use 0.66.8 still and now I always notice "availible" XD. -___-uhm... how can it be slower? :confused: That makes no sense ;D I don´t have the source code, but I can still edit the application... which is funny to do. Actually, I always use 0.66.9. and I´m happy to see "available" spelled correctly. xD Title: Re: Gecko dotNET Bugs and Requests Post by: giantpune on November 02, 2011, 08:34:45 PM with the newer games coming out that require 1000s of patches, our gameconfig.txt may become really huge. it is also a bit of a headache to put the SD card in the computer to edit this file. what do you think about a button somewhere in geckoDotNET to perform some of the functions of the gameconfig.txt? i guess really the poke/searchandpoke/pokeifequal functionality would be the parts that would make sense to have.
Title: Re: Gecko dotNET Bugs and Requests Post by: matt123337 on November 10, 2011, 01:42:02 AM Anyway we could get the latest source code? I'm trying to migrate away from windows (into linux) and having a really outdated version of GDN is annoying.
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 10, 2011, 07:37:02 PM we really need gecko.net´s newest source code, but dcx2 doesn´t seem to bother with it... not giving us the chance to mess with it, while he retired from updating anything. I don´t see the actual point at doing so. Isn´t sharing progress? The app still has some glitches that are worth to be fixed. :-\
Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on November 18, 2011, 06:58:21 PM I just updated to the newest Gecko.NET from using r115 for the longest time, and I went to test if saving a loading searches finally work and I got this error message when I tried to load the search I just saved
object reference not set to an instance of an object details v Code: See the end of this message for details on invoking Also I noticed it now has a pointer search tab, does that have a max offset limit? if so what is it? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 18, 2011, 11:10:25 PM no, the pointer tab is only for doing dumps.
Searching must be done with an external app (like Pointersearch v4 by Dr.Pepper). Also, bug reports became quite pointless. Nobody cares anymore. Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on November 19, 2011, 12:57:34 AM Are you sure because the pointer tab asks for dumps, you dump the dumps on the tools tab
Nobody cares about bugs anymore? That's not cool Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 19, 2011, 09:48:06 AM Are you sure because the pointer tab asks for dumps, you dump the dumps on the tools tab yeah, they are supposed to be put into an external application so that gecko.net doesn´t lock up and you can continue working with codes instead.Well, that´s what I do and I´m fine with it. The only damn thing with PointerSearch by Dr.Pepper is that one can´t "force" pointer in pointer. The app only performs a pointer in pointer search when there´s no regular pointer that got found. The tool itself is very fast, no comparison to WiiRd ;D Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on November 19, 2011, 02:42:46 PM If you're supposed to be using an external application then why is their even a pointer search tab? Also I've used Dr.Pepper's tool and it takes just a couple seconds just like WiiRd, it doesn't really seem faster
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on November 19, 2011, 04:24:26 PM If you're supposed to be using an external application then why is their even a pointer search tab? Also I've used Dr.Pepper's tool and it takes just a couple seconds just like WiiRd, it doesn't really seem faster lol?WiiRd takes AGES on pointer in pointer searches while PointerSearch does it in like 1 minute. Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on November 19, 2011, 05:00:07 PM In my experience neither of them has ever taken a whole minute, I don't know what you were doing wrong
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 07, 2011, 05:25:56 AM Wut is this?
http://www.youtube.com/watch?v=li3FCPBHsZ8 How am I supposed to debug my codes if I can't see the breakpoint? >.< I was trying to debug this code: http://wiird.l0nk.org/forum/index.php/topic,8972.msg76254.html#msg76254 Also, since I used the pointer tab for the first time, I think the results should be clickable so that it takes you to that address in memory. Probably not necessary, but since it was my first time doing a pointer search, I wanted to make sure the results were good. And I don't think you can copy from the results textbox. And memview should have right click options for the pointer tab. Also, the dumps checkboxes are bootleg. I was adding dumps from 3 to 1 and it ended up checking the boxes for dumps 1 when I did dumps 2. So I was afraid it might go wrong. But it didn't. Other than that, the pointer tab is awesome. It does most of the work for you and then sends the data to dr. pepper's tool I think. Edit: saw this at the code's address 804EB33C: 4800002B bla 0x28 Well now I know why the code doesn't work >.> it should be b 0xsomething. But that was totally gecko.nets fault too XD. But it was though. I did right click->gct code on this. But whatever. Still wanna know why gecko.net gave me a blank BP. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 07, 2011, 09:32:12 AM yep, gecko.net sometimes gives "invalid address" message as crash breakpoint.
Or it just shows blank. Idk what went wrong with it then... :| The exception message is misleading, too. It often asks more than once to change to breakpoints tab. And it crashes some games when an empty codelist is sent. (Also brings up the exception message). A source/destination register was then damaged. It´s not just me. Maybe I´ll make a video of it. >_< So yeah, I can replicate the exact same you showed in your video. :p You were hacking Kirby. If you hadn´t applied the patches, it would enter a deadloop which just disconnects gecko.net. So that´s not it. P.S. Your screen recording software is quite retarded. May you find a non-advertising one. xD Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 07, 2011, 09:14:16 PM Well the code was wrong and that was the reason for the crash. I connected the gecko to see what was the problem. After the code was fixed, there's no more crashes.
re: P.S. Yeah I hated AVS after I saw that. Worst watermark ever. Who would want to buy it after seeing that? I uninstalled it with the quickness. The search continues. >.< Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 11, 2011, 02:11:10 AM Finally, the video ;)
http://youtu.be/87uKqme7F3E Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 13, 2011, 02:29:54 AM This happened enough times to be a problem. I'm doing a search to find spark charge in Kirby's return to dreamland. The stuff I found in the 80s didn't help, so I thought maybe the 90s.
Unknown 8-bit search in the 90s with kirby just being spark Greater than search at full charge Less than search when it goes down one level(green) Less than search when it goes down another level(a little static). But gecko.net stops responding instead. This happened 3x in a row, so I stopped. I posted enough codes for one day. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 13, 2011, 10:44:07 AM This happened enough times to be a problem. I'm doing a search to find spark charge in Kirby's return to dreamland. The stuff I found in the 80s didn't help, so I thought maybe the 90s. you should be looking through mem80 since NONE of the existing codes were located in mem90...Unknown 8-bit search in the 90s with kirby just being spark Greater than search at full charge Less than search when it goes down one level(green) Less than search when it goes down another level(a little static). But gecko.net stops responding instead. This happened 3x in a row, so I stopped. I posted enough codes for one day. I don´t think that there´s anything useful in this area for Kirby. Games with very little ISO size will mostly likely never use mem90 since their needed RAM is too little to be expanded to mem90. There´s not much data. Anyways, it may NOT disconnect Gecko.Net... I noticed that reconnecting sometimes doesn´t work with Ossleepthread Hook. I plug the USB cable, close gecko.net, plug back in, reconnect (won´t reconnect like if the game was crashed), but game is still running. Title: Re: Gecko dotNET Bugs and Requests Post by: shadowofchaos on December 24, 2011, 05:56:07 AM Yes, Riivolution supports the USB Gecko. http://rvlution.net/wiki/Ocarina_Codes Riivolution also supports wifi redirection. So you can keep the code handler binary on your computer, so you can easily swap in new code handlers. But you would have to restart (EDIT: restart Riivolution not the PC), because Riivolution copies the codehandler.bin file into memory when the game is loaded. About as brain-dead simple as it gets in terms of upgrading your code handler, but that's if you get Riivolution working, and it doesn't support channel cheats or GC games. Hence why I lean more toward using gameconfig pokes, because it's widely supported due to Brawl+. I'm pretty much confused. I have the options on my screen because of the XML file. I can change the hook type... RFEE01 (Fire Emblem Radiant Dawn) And I can see on Gecko.NET that it recognized the game on Riivolution. The problem is... whenever I do something, ANYTHING, like sending cheats, or even looking at the memory viewer by entering an address... the game freezes. And I can do nothing but turn off the Wii by holding the power button. I've changed it to different hooks and I still can't do anything but freeze. The regular SD cheats work, but doing anything with the USBGecko kills it. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 24, 2011, 07:18:44 AM Same with me. Except it just freezes if I connect the gecko. I'm not sure what I'm doing wrong. I kind of want the convenience of swapping files with riivolution and having the power of my gecko at the same time. But no can do. :(
I was gonna look into it eventually. It looks like instead of gameconfig.txt you can put the stuff in the xml... I want the gecko to work first though. >.< Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 24, 2011, 08:46:13 AM OMG, I finally found out about the "empty codelist freezing issue".
It was because I once had a bad undo line somewhere on the codelist which is poked when I send/disable codes. It gets executed and crashes. Not too good when there´s moving assembly, because I won´t be able to keep all those codes in one list since all undo lines will be poked, no matter which codes I send/don´t send. I suggest to only poke the ones, that are ticked. Anyways, it´s one of my favorite features on Gecko.Net. ;D Title: Re: Gecko dotNET Bugs and Requests Post by: shadowofchaos on December 24, 2011, 09:22:44 AM Same with me. Except it just freezes if I connect the gecko. I'm not sure what I'm doing wrong. I kind of want the convenience of swapping files with riivolution and having the power of my gecko at the same time. But no can do. :( Argh... (http://i22.photobucket.com/albums/b336/shadowofchaos725/Hacking/RFEE01-011.png) I want to be able to mess with text AND use the gecko. Argh. So I'm guessing this is on the Riivolution's end and not the GeckodotNET because I tried it with WiiRDGUI and it still froze as well. I also found out all the Japanese text is still there... so the features the Japanese people were cheated out of like the widescreen aspect ratio could be fixed with Riivolution or just a few patch codes with Gecko. Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 24, 2011, 06:25:56 PM Oh? All the text is in a file that we can modify? I wonder if it's like that in MH3...
It looks like dcx2 and megazig have no problems with that, though. I never wanted to say anything because I don't like requesting something that isn't being worked on...but I did look forward to that riivo guide dcx2 mentioned. @Bully: Even with them unticked? o.O I guess a list of undo codes is a bad idea. Quote from: dcx2 Quote from: Stuff invisible players fixed :D invisible players 044EB33C 48000028 The reason your first code failed is that it was a bla (branch and link absolute). bit 0 (from the right) is the "link" bit; set it and your branch becomes branch-and-link. If bit 1 of a branch is set, it's an "absolute" branch instead of "relative". Unless you're writing an interrupt handler (you aren't), absolute branches are fail. When the Wii generates an exception, it usually places the address of the instruction about to execute into SRR0. Gecko.NET then reads SRR0 to determine what assembly to load. However! If an ISI exception is generated by branching to an illegal address, the illegal address is placed in SRR0! That's why SRR0 was 0x28 for you. Since 0x28 isn't a valid address, Gecko.NET can't grab any disassembly, which is why it looked "blank". In cases like this, your best bet is to use the LR to figure out approximately where you are, and then go looking for nasty evil branches like bla 0x28. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 24, 2011, 10:08:52 PM @Bully: Even with them unticked? o.O I guess a list of undo codes is a bad idea. sure they were unticked, I wouldn´t have taken that long to realise...note how some games use moving assembly. It will f*ck everything up, if "wrong" values get poked. Or if there´s just one mistake in the whole code list that has a bad undo line. Freeze with an empty list, when codes are sent/disabled. Finally, I know why that happened. :-\ Title: Re: Gecko dotNET Bugs and Requests Post by: matt123337 on December 25, 2011, 06:30:21 AM dcx2, any way we could at least get the latest source code put on the SVN? I really want to use my USBGecko in Ubuntu,with latest build of GeckoDotNET. It's a pain to boot into windows everytime I want to just use GDN.
Title: Re: Gecko dotNET Bugs and Requests Post by: megazig on December 25, 2011, 07:30:50 AM I am still around on occasion on freenode irc server in channel #rvlution regarding riivolution. I have helped a few people with usbgecko and riivolution so far. it works very well with me which is a blessing as I wrote my own codehandler for the wii that I can't use with precompiled gecko\os obviously. if I'm not on when you come around, just be patient. I have a family and a job and lots of projects in my rl too
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on December 25, 2011, 08:11:59 AM ah cool. Well I'm not in a rush. I won't be on now cuz it's late, but I'll lurk around irc an hope to find you. Thanks for offering help.
Title: Re: Gecko dotNET Bugs and Requests Post by: shadowofchaos on December 26, 2011, 04:17:17 AM I am still around on occasion on freenode irc server in channel #rvlution regarding riivolution. I have helped a few people with usbgecko and riivolution so far. it works very well with me which is a blessing as I wrote my own codehandler for the wii that I can't use with precompiled gecko\os obviously. if I'm not on when you come around, just be patient. I have a family and a job and lots of projects in my rl too I'll check in sometime then. I REALLY want this darn thing to be able to work with text patches with Riivolution... and in fact, since the Japanese text is still in the disc, be able to add the missing text for the features the Japanese version didn't have... and maybe TRY to search for the ASM that's preventing Japanese characters from being used in Forge Weapons in FE10. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on December 31, 2011, 11:36:00 AM another bug:
When gecko.net hasn´t connected yet (after a crash, reboot etc.) and I press "Send Codes", it gives an error exception. Then, if I press it a second time, it works. Furthermore, the "restart search" button is greyed out, if I crash and reconnect while having search results in the list. I need to refine the search and then I can restart the search. And I don´t like how gecko.net almost locks up/slows down significantly when the USB Cord is connected, but no game is hooked. I think that it keeps trying to connect and therefore loses reaction time for anything else that the user is doing with the app. What was the button combination again to prevent it from trying to connect? Or is there a general fix without doing anything? I want to connect using the "Reconnect to Gecko" button only and not automatically. :smileyface: Gecko.net pokes every undo line in the codelist on send/disable codes. That´s bad because if there´s moving ASM the game will crash! So we want it to only undo the codes that are "ticked". We don´t need to make a new codelist just to move somehwere else in the game where assembly has moved. It doesn´t happen on most games, but it DOES happen on some... It would be so beast if my requests get fullfiled one day :/ Bully Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on January 16, 2012, 05:47:47 AM i3 2.4 ghz cpu.
gecko.net eats up 20% of my cpu while doing nothing. I thought it was firefox that was putting my laptop on fire. Title: Re: Gecko dotNET Bugs and Requests Post by: Clay10 on January 16, 2012, 04:24:50 PM i3 2.4 ghz cpu. Gecko.net uses 50% CPU for me.gecko.net eats up 20% of my cpu while doing nothing. I thought it was firefox that was putting my laptop on fire. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on January 16, 2012, 07:57:57 PM when gecko.net is doing hard work (like dumping the ram), it takes about 25% of my cpu.
While doing nothing, it´s about 0% till 1% :-\ (Work space 21.000 k) So it´s nothing critical for my laptop... Title: Re: Gecko dotNET Bugs and Requests Post by: WiiOs-Ozelot on January 22, 2012, 11:53:15 PM Tool has bugs -.- i using the old wiird
i will poke a Value in RAM but it dosent work -___________- I will add a Value in Watch list, i can not see the Window!!! Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on January 23, 2012, 12:08:31 PM WiiRd ftw...
Title: Re: Gecko dotNET Bugs and Requests Post by: Clay10 on January 24, 2012, 07:47:27 PM Gecko.net won't hook on VC/wiiware games. I've tried all of the hooktypes on multiple games, but I still can't connect gecko.net. The game itself boots fine from the channel rebooter, I just can't connect.
Sent from my iPod touch using Tapatalk Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on January 25, 2012, 09:31:38 AM Gecko.net won't hook on VC/wiiware games. I've tried all of the hooktypes on multiple games, but I still can't connect gecko.net. The game itself boots fine from the channel rebooter, I just can't connect. how come?I could hack any vc and wiiware game using gecko os 1.9.3.2. and gecko.net 0.66.9 Title: Re: Gecko dotNET Bugs and Requests Post by: WiiOs-Ozelot on January 29, 2012, 04:04:54 AM WiiRd ftw... ah death is alive ;D I'm using Gecko.NET Bully has advised me ::) Gecko.net is better for Assembly Codes, so said me Bully. ah i see, Font size is available :D yay I lost my Database Password. I hope james give me a new password. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on January 29, 2012, 08:25:45 AM WiiRd ftw... Thank you for the suggestion. I'm sure this information will help with future development. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on January 29, 2012, 09:54:32 AM No, he just retired.
That´s what he said somewhere... Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on January 29, 2012, 10:04:40 AM "Now hacking Left 4 Dead 2"
Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on March 11, 2012, 12:43:43 AM So I have this in gameconfig:
#Monster Hunter Tri RMHE08: codeliststart = 807AD808 codelistend = 807B57E8 poke(804CAB30, 38037FFF) But gecko.net doesn't acknowledge the new code space size. Codes are still sent to the right place. This isn't an issue at all until I try to send 529 lines of code. idk what the limit before I have problems is. I do know I can send around 300/215ish no problem. The 529 lines is a few regular codes, MID, and like a bajillion modded weapons. And gecko OS can load the 529 lines just fine. If I send it via gecko.net, the game freezes, and connection is lost, and that's it. No debugging or anything. I think it might be related to the code lines counter. I was planning on trying with an older version. But yeah. Think there's a way around this? Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on March 23, 2012, 11:43:31 AM No debugging or anything. I think it might be related to the code lines counter. I was planning on trying with an older version. But yeah. Think there's a way around this? Same always happened to me, I tried with extended codelist etc. and still it freezes when I send like 250 codelines. No more debugging is possible.Even when it says that I have 4XXX lines available. Too bad that nobody really managed to make that work properly. Maybe we´ve everything fixed in 2014. I would help if I knew enough about it. >_> Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on May 16, 2012, 07:46:42 AM Some bugs considering "loading RAM dumps" using Gecko.NET:
- Mem90 RAM dumps are treated as Mem80 (therefore, I can only view half of the file which is disadvantageous) - Poking Dumps on Memory Viewer doesn´t work "Connection to the USB Gecko has failed" (but it does work on Disassembler) - The XOR calculator is disabled Other: - The Memory Viewer Search box is filled with "FF FF" on bootup. Would be better to have it cleared. - When an unknown value search has been performed and the user reconnects to the game, the "Restart Search" button becomes disabled and the value (which is supposed to be unknown) becomes un-greyed (which fixes itself after reselecting unknown value search) - Fix invalid value on Memory Viewer (in case the user has entered a 9-digited value, just take the first 8 digits for poking) - Deleting search results only works on single addresses, selecting multiple ones for deletion will not succeed - Remove "Error sending command to the USB Gecko!" command (I think we don´t need two notifications that it failed to connect) - Add "Codes saved!" to status bar - Hitting the "screen capture" button twice (rapidly) will freeze the game (there are also other ways to freeze the game by hitting a same button/command twice and quickly, either by coincidence or on purpoise) - Permanently save/set mem2 boundary to extend to 93800000 (some Wii games have stuff there plus it´s legit memory without access crash) - Sometimes, when sending codes, it gives a crash message (possibly because I didn´t reconnect to the game or something) Sending once again works (therefore no big deal, but still a weird thing) - GCT tab is slow (my processor isn´t old). The bigger the auto codes archive file, the slower the click recognition or movement of codes (sometimes it takes a few seconds to response again). May there be a way to have it as fast as e.g. WiiRd code management, but still some kind of backup file? Alternatively with "codebackup on/off" option (more risk to lose codes though) - Pointer Tab: Search Button -> In case the path to the pointer app isn´t correct, let us select the path we want to use (for now, it will just say "Is the path to the Pointer app correct?") Title: Re: Gecko dotNET Bugs and Requests Post by: shadowofchaos on July 07, 2012, 04:24:05 AM Hmm...
You know how you can load memory dumps in the memory viewer? Would there be any way to enable the cheat search tab using memory dumps you already have? Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on July 07, 2012, 04:14:28 PM That would be awesome. I don't think that's possible with gecko.net. You'll probably have to compare the dumps in a hex editor, which probably isn't going to be fun.
Some stuff to add: Bugs I'm not sure if this still has to do with >x/x codes, but I added my Show Real value codes to the codelist and sent them along with everything I already have active, but some of them didn't activate. Now here's the strange thing. It was 3 lines and the 1st line was the one that didn't get sent. I checked in disassembler wondering why my code wasn't working(maybe the code wasn't good), but I saw that nothing changed for only the first code. The code is way at the bottom of my codelist, but I don't understand why the 2nd and 3rd lines were sent and then the 1st line wasn't.It wasn't that it was a bad code. I swapped them around and had the code activate. Features shadowofchaos reminded me that I was thinking about how the search tab should be able to shift to a different location for things that move around. You could tell it to use a pointer or pointer in pointer and tell it the size you want to search. For example pointer:806BBC74 size:B20 search unknown...blah blah Now I can go in a quest, and it'll search my data there, return from a quest and search my data there. Maybe there's something that changes when you go in quest or back to the village. And that'll probably help with gestures...because some are disabled in quest. That sounds like a great idea to me. Too bad I can do it myself. Oh one more feature. In disassembler, I like to go to code addresses and enable them there so that I can use the drop down to disable them later. There needs to be a "save instruction" so I don't have to grab the code address from the code and then do my stuff. It'll be a saved list of commonly assembled stuff. and a batch assemble where you check the ones you want and plow! they're enabled with the original instruction on the dropdown list. There also needs to be a way to label these instructions. Sometimes that dropdown gets pretty long with nonsense and I might want to go back to one of them, but I'm not sure which one. I ran into so many bne-'s. And a way to clear that list. idk if it's possible, but I haven't been able to do anything about it. Title: Re: Gecko dotNET Bugs and Requests Post by: XeR on October 07, 2012, 10:39:47 AM I DCX2 stopped the development, but I have found a bug.
http://youtu.be/b2BCD9ln7xo << Check the number of results. I have no idea how and why it happens. Title: Re: Gecko dotNET Bugs and Requests Post by: Deathwolf on October 07, 2012, 10:50:22 AM Not sure but I think that's because you didn't search through "Old Condition 1"
Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 07, 2012, 10:52:14 AM There´s a also an issue with restarting search when it has been canceled. If you do another search, it will always perform the first stage of search, without comparing to the previous results... restarting gecko.net fixes it. Gecko.net sometimes gets stuck with comparing results after a big search (mem90), more likely if the CPU power is low. It´ll say "105 %" and never continues to unlock it´s functionalities again. It surely happens a few times per intense hacking day with many searches...
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on October 07, 2012, 08:49:37 PM For what it's worth, Gecko.NET automatically stores the history of each search after it is dumped and before it is processed. These histories are in a zip file that can be opened by any standard zipping software. So if Gecko.NET crashes, you can just load your old search history. If something's wrong with one of the searches in your history, you should be able to hack it at with a hex editor if needed, or just delete the bad one.
@XeR, without a detailed history of what you did to get to your first search, it's difficult to say. However, the numbers above the Old and New columns should change each time you grab a new dump (those are the histories of each search you've ever done). The fact that New was still 1 after you did your Specific Value search for 0 is odd. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on October 08, 2012, 01:57:18 PM Ah, got to learn something new about this application every time I´m wondering something. The auto archive thingy has saved my codelists 2x or 3x from getting lost already. Due to Gecko.Net´s massive functionalities, it may be cool to have some kind of manual. I don´t even know everything 2 years later, lol. But who´s going to write it? I don´t see great chances in it, currently. :eek:
Title: Re: Gecko dotNET Bugs and Requests Post by: XeR on October 09, 2012, 07:28:26 PM @dcx2: Oh, you're right. I didn't notice the numbers.
I remember trying to make a search in MEM80, then a refine in MEM90. Of course it crashed, so I restarted my search in MEM90. It may have been the cause. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 15, 2013, 01:31:06 PM 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. :( Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 15, 2013, 03:26:26 PM 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? Title: Re: Gecko dotNET Bugs and Requests Post by: γRB on April 15, 2013, 05:05:25 PM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on April 15, 2013, 05:13:19 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 15, 2013, 07:09:28 PM I'm not 100% sure I follow, but I think Link's watch list tab does what you want. Just booted everything and took some closer looks at the tab I never used so far. xDBasically 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? 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. Title: Re: Gecko dotNET Bugs and Requests Post by: γRB on April 16, 2013, 01:28:08 PM 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 Title: Re: Gecko dotNET Bugs and Requests Post by: Stuff on April 17, 2013, 08:11:22 PM I'm not 100% sure I follow, but I think Link's watch list tab does what you want. Just booted everything and took some closer looks at the tab I never used so far. xDBasically 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? 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. Title: Re: Gecko dotNET Bugs and Requests Post by: Bully@Wiiplaza on April 21, 2013, 12:17:17 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: CosmoCortney on May 19, 2013, 02:06:38 AM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on January 04, 2014, 06:08:40 AM 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?
Title: Re: Gecko dotNET Bugs and Requests Post by: dcx2 on January 04, 2014, 08:29:19 PM 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. Title: Re: Gecko dotNET Bugs and Requests Post by: wiiztec on January 04, 2014, 11:44:39 PM 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
|