just the 2ndline.I have a question:
I found some codes on Max-Cheats.com for "Legend of Zelda: Majora's Mask" US Version to change what is in a Bottle. The code format looks like this:
[#BOTTLE 1 MOD#]
00000000 00000000
[Red Potion]
20775384 00000013
For the Red Potion example I listed, do I need to put both parts (00000000 00000000 and 20775384 00000013), or just the second part (20775384 00000013)? Thoughts/help appreciated
If I am not mistaking since the pointer code is at or above 10000000, and since there is not enough room for the 6 or B code, as that takes place of the where that "1" would be. It could be a place holder for that "10000000" to let the GW know that the pointer is 157F7FE0 and not 057F7FE0. Although I am most likely wrong though. I simply used it to keep the 3DS from crashing. Although you could try it without it and see what happens.Sweet, one question, what is D3000000 10000000 doing? Once I know that, I can try it with Majora's Mask.
Point 1: The value may not be stored as an integer, but a floating point number. If the value is stored as a Float, then doing an Int search isn't going to help you. On top of that, the value may well be stored as a whole number representing the minutes, seconds and fractions of a second. It may well be stored as 'ticks' (1000th's of a second). The best way to possibly find this location is to do ram dumps and take screen shots (use your mobile phone) and use Cheat Engine to search for the various value types (Float, Double, Integer). There's still no guarantee you'll find the value.
If you're going to do the ram dump, then I believe that Gateway does't dump the whole ram (which is somewhat frustrating). And a trick to help: When searching for values using Cheat Engine, do a range search. So if you're looking for 4:30.28 (4 minutes, 30.28 seconds), then search between 4:29 and 4:31. You may need to convert that to seconds (ie 269 and 271), then repeat the search with subsequent ram dumps. In these weird instances, I usually do around 10 ram dumps.
Also of note, the memory location may well not be static for time, that is, it moves around in memory. This might move every level you load, every time you load the game, or in some rightfully painful times, it might move every few seconds. If that's the case, you've got no hope.
One last thing, even if you do find the memory location, if the value is stored as something other than an integer, you may not be able to write an integer value to it using Gateway and have it work.
I'd love to see Gateway expand the search parameters to include Float, Double and ranged searches.
If I am not mistaking since the pointer code is at or above 10000000, and since there is not enough room for the 6 or B code, as that takes place of the where that "1" would be. It could be a place holder for that "10000000" to let the GW know that the pointer is 157F7FE0 and not 057F7FE0. Although I am most likely wrong though. I simply used it to keep the 3DS from crashing. Although you could try it without it and see what happens.
Just curious one how are you finding your pointer codes?
whats the password on the download page?If you use NTR CFW, speedfly have codes: http://www.speedfly.cn/11886.html
Yeah, it can get confusing. However to manually check to see if you have the right pointer address, is to use the RAM viewer or Hex viewer, whatever it is called and go to the pointer address you suspect, at that address, copy the value on notepad or something, and add the offset to whatever shown in the viewer, the result should be the dynamic address as per the calculation. Then go and view your calculated address, and see if the value matches up to what you are expecting or that dynamic address if you happened to hacked it again.Well I tried for Majora's Mask, keeps crashing. Don't know if I got the wrong address or it not working but crashes haha.
Yeah, it can get confusing. However to manually check to see if you have the right pointer address, is to use the RAM viewer or Hex viewer, whatever it is called and go to the pointer address you suspect, at that address, copy the value on notepad or something, and add the offset to whatever shown in the viewer, the result should be the dynamic address as per the calculation. Then go and view your calculated address, and see if the value matches up to what you are expecting or that dynamic address if you happened to hacked it again.
That is how manual checking is done I think. Pointer code searching is not easy, at least not without a pointer code search tool. Pointer in Pointer is however very difficult if not possible to find and Majora's mask might need that instead.
Cool, Didn't know that such tool exist, I have been manually finding my pointer LOL. For simplicity lets say that the dynamic address is 1F003000 and you find a pointer code 1A000000 and the offset is 0x200. go directly to 1A000000 and view it's value as shown, it can by anything, but usually pretty close to the dynamic address as it's value, again lets say that the value at 1A000000 is 1F002E00, you would add 1F002E00 and the offset, in this case 200, by adding those two, it should show that dynamic address in this case the result should be 1F003000. With that in mind, then you can view the address result in a RAM viewer, to see if that dynamic address value is what you were expecting, for example if you have 9 lives, you should expect to see 09 or 00000009 for that dynamic address value. Although not a sure fire method but it is one way, also you can live edit that dynamic value to anything like 99 lives to see if that is the actual code that you want your pointer to point to.
Hope this clears it up. Also I almost forgot to mention that when viewing the pointer value with GW RAM viewer it will be in little endian format, so you will have to read the value backward (from right to left as appose to left to right) so it will look like this: 002E001F.
So if I am not mistaking that C080 is probably the magic meter, or that the result found in the dynamic address? You should try using a 32-bit search using the tool, instead of the 16-bit. Usually most codes should be found in 14000000 range.
Oh wow, didn't realize MJ had a moon jump code. You do not want to move the pointer code, so no adding the offset to the pointer code. The pointer codes point to that specific location, and that is why you need to add the value from the pointer code, i.e. specific location with a given offset, and the calculated result should take you to that dynamic code. So in short the answer is yes, adding the offset to the value will get you where you should be at, provided that you have found the right pointer. Problem is there are many pointers available, but not so much correct ones for a particular codes. Pointer codes are not exactly the easiest code to find, at least not without a proper tool, so after looking into that TempAR program, it appears for PSP, and not for 3DS. Generally most pointer codes are within a static areas of the memory ranges while dynamic is in the areas where its always changing.Why would you add the value and the offset? Don't you mean add the pointer address? Adding an offset to the value wouldn't go anywhere, would it? Sorry I'm just confused with pointers in general, if you could explain with the values I screenshoted, that could help my stupid ass. Sorry haha.
C080 is the value for Link standing in place. If you want him to fly, you would do an activator and 00004100. It's not 32bit, 16bit is only needed for the code. This is the current code I have for my Majora's Mask file.
[Hold X+A Moonjump]
DD000000 00000401
1907F4BA 00004100
D2000000 00000000
0907F4BA is the dynamic address currently, and I have another dump with 08EF20CA with Moonjump on that address. I put them into the program with the base address of 0x08000000 and it loooking for a maximum offset of 0x1000. Those are the pointers it popped up, with an offset of 0x6A. Those Addresses don't look like they are on the 3DS's memregions at all though. The ones the program spits out are like 0x001C6088 and is too small to be viewed.
Oh wow, didn't realize MJ had a moon jump code. You do not want to move the pointer code, so no adding the offset to the pointer code. The pointer codes point to that specific location, and that is why you need to add the value from the pointer code, i.e. specific location with a given offset, and the calculated result should take you to that dynamic code. So in short the answer is yes, adding the offset to the value will get you where you should be at, provided that you have found the right pointer. Problem is there are many pointers available, but not so much correct ones for a particular codes. Pointer codes are not exactly the easiest code to find, at least not without a proper tool, so after looking into that TempAR program, it appears for PSP, and not for 3DS. Generally most pointer codes are within a static areas of the memory ranges while dynamic is in the areas where its always changing.
Sometimes it does not matter if a code uses a 16-bit value, the code can be 32-bit long, unless the game actually restrict it in a 16-bit or 8-bit range, but most often time the games uses 32-bit addressing, even though the values generally never surpasses the 16-bit amount. Take for example Mario Kart 7 usable item values are all in 8-bit values, however the code itself is actually 32-bit long, so doing an 8-bit search would net you the code you need, however to find the code even faster, you could do a 32-bit search, as it mostly is filed with "0". As for the results in the pics above, it looks to be all invalid pointers, problem with GW ram dump, the dumps are actually splitted in ranges, so you will not get a complete dump. Most codes should be in the 14000000 and up to I think 18000000 range. I forgot exactly, but do know it generally starts at 14000000.
You could refer to here if you want to, while it isn't about 3DS, but it could easily apply when manually checking your pointer codes. I used that method when I checked my pointer code. Your best bet for now is to manually search for pointer codes, however this could take quite a time and skills.
That's probably the display value, which always compares to the real value. Instead of searching for the exact value, search for a 16 bit unknown unsigned value.i am trying to edit the number of main hearts on Pokemon shuffle
i found the address , but after edit it , it add the number and subtract it immediately.
what should i do ?
It's giving me error when trying this.That's probably the display value, which always compares to the real value. Instead of searching for the exact value, search for a 16 bit unknown unsigned value.
Format to Fat32. Fixed the errors for me on a 128gb card.It's giving me error when trying this.
The card is 64GB exFat.