We all play Pokémon for the …plot, right?But what are you going to do with the free hand?
If you mean simply simulating the DPad like CPad normally does, then yes, it should be possible.
Love your work! Can we get a version of the Animal Crossing: Wild World patch with running on the B button? It would be nice to be able to push the circlepad all the way without having to worry about bugs and fish being scared off, especially with spring right around the corner.
I've been playing Wild World with your circlepad cheat and someone else's widescreen cheat and it's been amazing, definitely the new best way to play the game IMO.
I've been playing Wild World with your circlepad cheat and someone else's widescreen cheat and it's been amazing, definitely the new best way to play the game IMO.
@shoco sorry for the long wait, I just couldn't get the debug text display to show, so you'll have to "deal" with the raster bars only.
The codebase of TWPach and all the patches is a total mess, and I don't know what it's doing, and to be honest, I don't really know what I'm doing either, I just try to make the patches work™, and once it works I'm never touching it again.
Hopefully the raster bars will be of any use. You don't need to do anything, it's already configured for you to be able to just open TWPatch, press START, and get a raster-bar rtcom patched in.
Although not sure if you need to do the kernel patches as well. Just in case, launch TWPatch fresh, then press Y+B, release, press X+A, release, press START, then once the lot of text has printed and says it's done, press B twice, and press SELECT to exit TWPatch.
The codebase of TWPach and all the patches is a total mess, and I don't know what it's doing, and to be honest, I don't really know what I'm doing either, I just try to make the patches work™, and once it works I'm never touching it again.
Hopefully the raster bars will be of any use. You don't need to do anything, it's already configured for you to be able to just open TWPatch, press START, and get a raster-bar rtcom patched in.
Although not sure if you need to do the kernel patches as well. Just in case, launch TWPatch fresh, then press Y+B, release, press X+A, release, press START, then once the lot of text has printed and says it's done, press B twice, and press SELECT to exit TWPatch.
I've added 3DS-NDS Key Remapper . If that's what you want and I haven't messed up, you should be able to map the CStick to the DPad keys
Sorry, I'm not very familiar with this game. How would pressing the B button be different from just pushing the CPad to run?
Thanks! Will definitely check this out. I've been having very rare crashes at launch, presumably when code executed first time on Arm11. Looks like code uploading sometimes goes wrong or something. I hope this will help.
There's bugs that come out during the warmer seasons and fish in the water at all times. If you walk near them you are able to catch them, but if you run near them they get scared and vanish. Normally when playing with the buttons you can only run if you're holding the B, L, or R buttons, that way you can easily sneak up on creatures and catch them, but with your circlepad cheat since running is the default option for moving the circlepad as far as you can, that means you either are constantly scaring off all the creatures, or you can never push the circlepad all the way out. Bringing back the run button would allow you to just walk instead of run without having to barely push the circlepad, allowing much more comfortable fishing/bug catching and making the controls much more like those of other entries in the series. Hope this helps!
Ok, I got it. Walking by default and running when the B is pressed. I've updated the patch
What about the CPad? Or ZR (that is supposed to open the Scan Visor)? Or other game patches like for SM64DS?
If I didn't break anything yesterday, and I might, It looks like you don't have a properly patched TwlFirm in a proper place. Have you read "In case something doesn't work ..." section in my first post?
@shoco you shouldn't be making these as cheats, but as ROM hacks instead. Reason being is because lengthy codes like these take up too much memory when loaded and or enabled, and it only gets worse whenever people want to enable others, making the load even bigger and more problematic. The more the codes, and depending on their size(s), you can cause game crashes, graphical and or audio related issues, etc. to occur, hence why it's most unwise to go this route. Your ideology to go about this without having to know the ROM structure on paper sounds great, but the execution is more impractical than anything. This in the form of ROM hacks is more beneficial since nothing extra has to be loaded from a separate engine to run the intended way, not to mention there is far less chances of something going wrong period. The other benefit is ROM hack developers being able to use these hacks as bases and or extensions for their own hacks, this in cheat form isn't universal for every hack out there, some are advanced to the point that the general game code structure is entirely different from within.
I put together some patches for one of the games you did, I may do the others later on if you don't feel like doing the rest.
Some instructions to apply and utilize the patches below for those interested.
Step #1:
Download the patches below, download xdelta UI from the appropriate source, and the latest version of TWPatch.
Step #2:
Extract the xdelta patches from the 7zip document and apply which ever version you want using xdelta UI.
Step #3:
Install and or run TWPatch on your (New) Nintendo 2DS/3DS system, be sure RTCom is enabled and apply the patches, this will automatically generate what's needed in luma/sysmodules.
Step #4:
Double check to make sure you have "external FIRMs and modules" enabled via the Luma 3DS configuration settings.
Step #5:
You are now good to go to run the patched game(s) via TWiLightMenu on your (New) Nintendo 2DS/3DS system, no cheat required.
Extra Precaution Step:
Double check and make sure you are running the latest version of TWiLightMenu and nds-bootstrap (latest version of TWiLightMenu already comes with the version of nds-bootstrap needed).
I put together some patches for one of the games you did, I may do the others later on if you don't feel like doing the rest.
Some instructions to apply and utilize the patches below for those interested.
Step #1:
Download the patches below, download xdelta UI from the appropriate source, and the latest version of TWPatch.
Step #2:
Extract the xdelta patches from the 7zip document and apply which ever version you want using xdelta UI.
Step #3:
Install and or run TWPatch on your (New) Nintendo 2DS/3DS system, be sure RTCom is enabled and apply the patches, this will automatically generate what's needed in luma/sysmodules.
Step #4:
Double check to make sure you have "external FIRMs and modules" enabled via the Luma 3DS configuration settings.
Step #5:
You are now good to go to run the patched game(s) via TWiLightMenu on your (New) Nintendo 2DS/3DS system, no cheat required.
Extra Precaution Step:
Double check and make sure you are running the latest version of TWiLightMenu and nds-bootstrap (latest version of TWiLightMenu already comes with the version of nds-bootstrap needed).
No, I don't think so. It's only possible by patching the game directly. Unlike buttons, the touchscreen doesn't go through Arm11.
Actually, it looks like Arm7 always stores the touchscreen data in the same place (0x027fffaa) where Arm9 can get it later and use it for a game. If we overwrite this location right after Arm7 writes to it and before Arm9 reads from it, we could probably "remap" the touchscreen. But the default position of the cheat engine in nds-bootstrap is not suitable for this. So you still have to patch the game manually.
playing through more of mario 64 ds, I do think that sideflips are a bit too hard to execute. unless you push the analogue stick in close to directly the opposite direction, mario will just do a U-turn. would it be possible to tweak the radius for triggering sideflips?
Thank you for the information and for your work. I didn't know that using these cheats can cause problems. Although, if I remember correctly, nds-bootstrap promises 32KB of space for cheats, which is quite a bit more than my regular ~2KB needs.
Anyway, while I do agree that it makes sense, I am not exactly fond of doing this myself for the following reasons:
- It's slow to test these kinds of patches. Just uploading usrcheat.dat to the console is about ten times faster.
- It's longer/harder for the users to install (it would be for me)
- It changes the checksum of a rom, which kills the ability to use usrcheat.dat without modifying it. It's probably true for applying other xdelta patches too.
- Cheats work fine for me, never had a problem (at least as far as I know)
- I lack knowledge of nds reverse engineering/patching and using/making xdelta patches
- I am lazy, tired, and unmotivated
- The patches aren't worth it. SM64DS and Metroid are interesting since they are kind of "feature complete" in terms of utilizing most of the New3DS features, but other 19 is just dumb copy-paste to get the CPad working. Only the Arm9 part changes a little bit
- The patches aren't exactly stable. There is a small chance to crash the Arm11 at launch (valid for all my patches). And for now I don't know how to fix it.
- It's nice that the cheat engine can always back you up. When a game overwrites my code, the cheat engine puts it back. It probably would be the same with xdelta's static patching if I do things properly, but then again, I don't know how it works.
If someone needs the source code for other patches/games, I am happy to share it.
All I can do is increase the range of the cpad. By default, it recognizes values in the range 40-145 (i.e. if you press the stick at a distance less than 40 (whatever units it means), the console will simply see it as 0). Let's try this. I have changed the range to 16-143
gave it a try but i'm not sure if it's helped. the problem is moreso if you're holding the analogue stick at say 15° then shift to 165°, it won't register a sideflip - i guess since the game's code expects you to be using a touchscreen? in which case i'd guess it'd need modifications to how the game handles sideflips and it'd probably be a different problem to the one that your codes address.
idk how your code works (or how sm64ds works either lol) so this is just a guess but maybe lower joystick values should be closer to the 'center' of the circle on the touchscreen? since maybe it expects the stylus to pass thru the center of the circle to register a sideflip - i'm probably explaining it weirdly though
either way your work on these patches is much appreciated and very cool
I can respect your reasons, hear me out on this though, and by no means am I trying to come off badly towards you or attack you, I just explain things in a very forward way.
It's slow to test these kinds of patches. Just uploading usrcheat.dat to the console is about ten times faster.
Maybe so, but speed isn't everything, stability matters, true research and development takes as long as it needs to take to make things stable and efficient. The problem in the modern age, everyone is so quick to pump stuff out, not to mention most people don't do proper extensive testing with their own work. Maybe people should stop doing that and start testing their work before releasing stuff, otherwise maybe whatever is being pushed just shouldn't be pushed at all, it's just going to be yet another problem left for others with more appropriate dedication to have to clean up, which it shouldn't be other people's job to do that, they could be spending that time improving and or extending upon the work instead.
In concept, these cheats could be more practical as methods to test the work, but direct patches are definitely more stable in comparison to cheats since all those changes are launched alongside the game code itself and not a few seconds after the original data loads, let alone having to be written constantly, which does reduce load times at boot since the engine doesn't have to work double time to load a chunky code afterwards, cheats are not instantly activated when the game boots, there is a delay in between, and depending on how many codes you have enabled, you can cause the load times to take a little longer, even with more legroom in memory for said cheats, more memory isn't going to yield faster load times when the cheat engine is involved with the game load times at boot.
It's longer/harder for the users to install (it would be for me)
That's kind of the point of learning how to do stuff. In terms of implementing things, you could ask those with experience to guide you, hell you could formulate a team to help out if you wanted, that way you don't have to do things alone. In terms of patching, it's actually really easy to do, we live in the age of patching tools with GUIs, and generally it's a simple three step process, choose the patch, choose the original ROM, set a patched ROM output name, done. It's only as hard as you make it out to be, while I can understand the work you put into this, inputting your feelings, preferences, ideologies as a whole into your work isn't a bad thing, you also need to remember and consider the fact that many people are going to utilize what you are providing, which means you need to keep a stable mindset regarding your operations with said projects.
It changes the checksum of a rom, which kills the ability to use usrcheat.dat without modifying it. It's probably true for applying other xdelta patches too.
Not exactly a great point to make, because your method also involves having to modify the database itself in this instance for the sake of adding in a code for a game(s), at least for those wanting to use an already populated database, which most people quite literally use a populated database anyways. Meaning regardless of which direction you go, the database still has to be modified, patched ROM or not.
Xdelta patches generally have a checksum in place that prevents people from applying patches onto the wrong ROM images, the only way they could is if they used modified versions of the patching software that bypass the checks forcefully or use a patching tool that has the option toggled off by choice, chances of that happening though is slim because the reputable places to find such tools only provide the correct versions of software to use, and even if modified versions exist in such places, they mention their modified nature in detail. All the user has to do is read, and if they can't, that's a user problem. Sourcing out the ROM image needed isn't difficult either, we live in the age of the internet, plus there are extremely easy methods to dump your own copies if you own a copy of said title. So there isn't really any excuses in this instance.
Cheats work fine for me, never had a problem (at least as far as I know)
You don't sound very confident with your own work, why should others trust this if you yourself can't say for certain? So they work fine currently, that's great, have you tested them all the way through to the end of the game(s)? If not then this might be a problem. As a cheat developer, I know that it's possible for cheats to break games bad enough to cause save data corruption for example, some cases the issues are apparent, and people can make the active decision to risk it all or stop without saving, however there are cases where visually there doesn't appear to be issues, but internally things can go wrong. Are you really confident that nothing here will do such things?
I lack knowledge of nds reverse engineering/patching and using/making xdelta patches
Much like my second point, this is why you learn, and again it's easy to apply and or create patches. As for reverse engineering, you reside on a forum full of knowledge, alongside individuals who may know tricks of the trade, asking for help is possible.
I am lazy, tired, and unmotivated
Well this definitely confirms a low trust value with your own work to the general public. If this was something for personal use then this logic would have merits, but at this rate, you would need a "guaranteed" label on the box to emphasize nonexistent quality. This is partly why I question why someone should release anything whatsoever if the end result is a potential forest fire of problems and or lack of practicalities, end result being someone else having to go behind and clean up a mess they didn't make in the first place. This might be coming off kind of harsh, however I tend to hold quality, efficiency, etc. pretty strongly, especially where developing in concept is concerned. We could use less bad bases to work with in the world and more improved working habits.
The patches aren't worth it. SM64DS and Metroid are interesting since they are kind of "feature complete" in terms of utilizing most of the New3DS features, but other 19 is just dumb copy-paste to get the CPad working. Only the Arm9 part changes a little bit
This is yet another problem, you aren't thinking in a broad perspective, maybe right now you don't see the value in it, but what about the useful applications it could have with ROM hacks in the future? Who knows maybe this could spawn other similar concepts. Maybe full fledged reverse engineered concepts in assembly language could utilize it. I've already been told that some folks have interest for it in ROM hack concepts already. However knowing how the current implementation is being handled, I can't recommend them using that stuff now, not until it's more appropriately stable and or fixed if any fixing is needed. What I provided was more of an example, a test of sorts to compare with for the sake of potential fixes to problems the codes may have brought at some point in the past, or to test the performance between both solutions. It would be better to hone your knowledge some more so you have more confidence on what potentially the problem(s) may be if and or when any occurs.
The patches aren't exactly stable. There is a small chance to crash the Arm11 at launch (valid for all my patches). And for now I don't know how to fix it.
So you aren't certain then?
It's nice that the cheat engine can always back you up. When a game overwrites my code, the cheat engine puts it back. It probably would be the same with xdelta's static patching if I do things properly, but then again, I don't know how it works.
Assuming is another mistake people make, don't do this, actually do some digging on the matter to actually have some form of constructive response. Xdelta patches do not work the same way cheats do, changes made to the ROM image(s) directly are permanent changes, and they work alongside the original code, patches merely carry the changes made to the original image, the patching tools apply the data that the patch contains directly to the original ROM image(s) (intended for distribution in a legal manner), this is why patches come in much smaller sizes than the ROM images, unless of course there is an extreme amount of custom data in the patch. Patching ROMs in this matter results in a permanently altered ROM image, meaning the custom data you applied is just as permanent as the original code presented, of course functionality of said custom data may vary depending on what the code is designed to do, when it's supposed to be activated respectively, etc. This means that the data doesn't have to constantly be written whatsoever, it writes in the respective times it needs to if at all. Cheat codes are NOT permanent changes, they are not meant to act as patches for anything, it's actually misleading to call a cheat a patch since it's not a permanent solution, cheats are intended for much smaller scale applications, generally meant for entertainment purposes or for getting an edge in unintended ways when playing the games, this is why no official solution allows the legroom for "patching" solutions like these, because this is not their intention. The legroom nds-bootstrap offers isn't even for such a use case either, it's there as a bonus for users to have more things enabled without running into problems. It's not to say cheats haven't been used to test things in the past, but even those use cases are much smaller scale in comparison to this. The patches I provided earlier carry your edits in a permanent manner, meaning the code is activated no different than that of the game code, it's loaded when it needs to be loaded just like the original data that occupied that space before, since it's permanent, nothing else has to do any work, no data has to be altered because the data is already altered before the game is even launched in the first place, which leads to better boot times and better performance depending on the situation, less issues overall, this also leaves room for people to enable other cheats that they'll likely have more interactions with and not wasting a bunch of memory just to do something that should be handled more appropriately via a ROM hack.
Reminder that I am not trying to come off badly towards you or attack you, as I stated, I am a very forward person. Hopefully you take all this the way I intended it to come off to be.
Last edited by DeadSkullzJr,
Side flips seem to work fine for me, although I don't know how to do them "right". I just run in one direction, then move the CPad to the opposite side (through the center) and press jump. It should be the same with the DPad (e.g. press Up, run, press Down, jump). Maybe you are doing it somehow differently or there is something wrong with your CPad?
As far as the game is concerned, you are using the touch screen (or I expect it to be that way). The CPad should be mapped 1:1 to the touchscreen joystick
@shoco Hey, I thought it might be useful to let you know that I finished a playthrough of SM64DS on my O3DS with the January 25th version of your analog cheat code! All 150 stars too (I know, I know, I'm just too cool). Thank you very much for the mod, otherwise I likely wouldn't have played the game at all I am curious though; do your codes work for ROM hacks of SM64DS? I could swear I saw someone talking about getting it to work with Another Super Mario 3D, but the codes don't seem to work (probably the wrong game ID) and the patched version also didn't work. Any help would be appreciated. I'll edit this reply if I end up figuring it out myself. Thanks again for the mod
I am curious though; do your codes work for ROM hacks of SM64DS? I could swear I saw someone talking about getting it to work with Another Super Mario 3D, but the codes don't seem to work (probably the wrong game ID) and the patched version also didn't work. Any help would be appreciated. I'll edit this reply if I end up figuring it out myself. Thanks again for the mod
Last edited by SmartIsh,
Thanks! It's great to know that this thing is playable from start to finish.@shoco Hey, I thought it might be useful to let you know that I finished a playthrough of SM64DS on my O3DS with the January 25th version of your analog cheat code! All 150 stars too (I know, I know, I'm just too cool). Thank you very much for the mod, otherwise I likely wouldn't have played the game at all
As for the hacks. It's impossible to answer ahead of time whether something will work or not. There must be a lot of hacks for this game.
But I've tried Another Super Mario 3D before and it worked. Did you choose the correct version of the cheatcode?
If I remember correctly, this mod was based on the version USA v1.0. But you could try some others. The signature (game code + checksum) of the patched rom is "ASME-8A9B0FD0" if it means something to you (it is shown in R4CCE)
Similar threads
- No one is chatting at the moment.
-
-
-
-
@
BigOnYa:
@SylverReZ I've never used a disposable, seems like a waste. kinda cool idea tho. It would be nice to have vape built in to a cell phone even. "The iVape"+1 -
-
-
-
-
-
@
K3Nv2:
I was hoping I could add a custom ROM to this fire HD 10 tablet but guess no one's made twrp available -
-
-
-
-
-
-
-
-
-
-
-
-
-
@
ZeroT21:
only ps5 updated to latest firmware can go on psn, jailbroken ones just don't use psn or they risk getting flagged or banned, altho spouting profanity in online play alredy does that -
