If RXtools was maintained it wouldnt be a problem in the first placeTells the guy who maintains RXTools the problems with it as if he didn't already know. Seems legit.
Seems Legit
If RXtools was maintained it wouldnt be a problem in the first placeTells the guy who maintains RXTools the problems with it as if he didn't already know. Seems legit.
It was, then for whatever reason there was some problems and now they clearly need to be fixedIf RXtools was maintained it wouldnt be a problem in the first place
Seems Legit
How to Fix RXtoolsIt was, then for whatever reason there was some problems and now they clearly need to be fixed
But there's no reason to trash on the project, now that someone is actually trying to fix it and support it again.
So you are going to salty when the project is dead, then be salty when it comes back to life? This is what's wrong with the current Temp. The members have become ungrateful brats who are just going to throw shit at devs no matter what they do. And then turn around and wounder why so many projects leave the Temp and go into private development.How to Fix RXtools
Drop the Tools because Decrypt9 does all that way better than RX does.
Fix the bugs
Owait this sounds like every other firmware out there :^)
The project trashed itself there is a reason they dropped the tools inthe first place but doing that also defeated the point of the FW in the first place.
All this is doing is pushing a dead horse along.
There are tons of members who would love to see RXTools have a comeback and be the CFW it used to be, but at this point it's pretty obvious that the community really doesn't deserve that if they are just going to complain about it.
Why would you need those?Do not own a physical copy of cubic ninja or OOT
There's nothing special in CFW or tools part, since there was a number of projects started. But noone did a good customizeable GUI. All of them more or less uses the same internal code by the principle "because it works", I'm refactoring it fully, not just inserting or stitching small peaces together (thanks to the Pasta team they stalled development and I've got a carte blanche). This is not a closed development of any kind, you can read here my erly statements https://github.com/roxas75/rxTools/issues/394.How to Fix RXtools
Drop the Tools because Decrypt9 does all that way better than RX does.
Being that I was one of the early people to declare this dead, I am happy to see this project keep going. In fact, you can easily go back to me saying the same thing you are saying. But I am also a strong supporter in options. If people want RXTools and someone is willing to keep it alive, then I am going to support them for contributing to the community. We shouldn't close the project off because there's already options, we should strive to keep those options going. There's no reason to give up on RXTools when we can easily go back and improve upon the once functioning build.TLDR Rxtools is dead for many reasons there are better alternatives to pick up nostalgic reasons wont turn it magically good, just grab Rei/Luma/Cakes Source Add Decrypt9 to its boot menu call it RXtools and be done
Why would you need those?
You can update to 9.2 without a game.
Is there a guide with the safier upgrade process?
Before you upgrade from 4.x to 9.2, I highly recommend that you read Part 5 of this guide. It will help you understand a complication of upgrading that may result in save data loss if you don't take the necessary steps.Is there a guide with the safier upgrade process?
The slot0x25KeyX.bin is only needed if your sysNand firmware is less than 8. Otherwise it's not needed.@duke_srg
What are the prereq files for your fork? Can we use the generated firm folder from the main rxtools? or do we need to download a new firmware.bin or something?
I assume it also needs these keys on the root?
key_0x1B.bin
key_0x16.bin
slot0x25KeyX.bin
Thanks
Yeah I know that. My question was more of a general one, as in, do rxTools still use theseThe slot0x25KeyX.bin is only needed if your sysNand firmware is less than 8. Otherwise it's not needed.
Key files used as in an original version, their presence and hash validity check is added in diagnostics section. One can easily any file check as menu section in gui.jsonYeah I know that. My question was more of a general one, as in, do rxTools still use these
Key files used as in an original version, their presence and hash validity check is added in diagnostics section. One can easily any file check as menu section in gui.json
Firmware generation is the same, you can keep existing.
Font file is extracted automatically on boot
Just backup and remove settings.json since key names was altered.
And add gui.json, theme/*.json and subfolders.
Existing old theme, font.bin won't interfere. You can also replace en.json to have button glyphs drawn correctly.
I'd like to have them both, even have an idea how to have up to 3 emunands SD card in a more reliable way. As for the patches, I proposed long time ago to have a customizeable modes with patches selection, but I'm don't have enough knowledge to implement it and actually lost track of it since patches was migrated into elf. So It could take even more then Soon(TM) if no one will join.Will you add multiple emunand support or something like cakes patches?
People are Salty because not because RXtools dead because not because it died but because there was no mentioned actively blatantly stopped without a mention.
Have you seen squeee, he's always having a stroke... the fuck!? You havin' a stroke, or have you simply failed to grasp the concept of proofreading?
Anyhow, I agree with some of what you said.