It's important to bring this to everyones attention.
Everyone knows, you can stop now.
Who supports TX is a traitor of the homebrew community.
Even if that were true, who do you think cares about that?
It's important to bring this to everyones attention.
Who supports TX is a traitor of the homebrew community.
Don‘t care either since I‘m installing both.
Game+update+dlcBy "custom built xci" ... do you mean game + update + DLC(s) of one game or multiple different games in one XCI (like Metal Slug 1 + 2 + 3 + 4)?
I created a XCI of BlazBlue Cross Tag Battle and another one for Pokken DX, both including any update and DLC available for the specific game. Both were working just fine for me with Checkpoint.
Because it was much more simple on them. It didn't really require a lot of modification on actual firmware more than third-party IOS to apply the same function. Sure there were DARKCORP that did make it more streamlined else Neogamma was quite popular. Or Softchip.A thread with no apparent solution. Up to this point I wonder how true Backup Loader could exist on Wii and WiiU and on Switch only talk about redirecting Backup as if it were cartridges with protected code. Was it on Wii and Wii U that it was also protected so that Backups Loaders existed?
Because it was much more simple on them.
XCI definitely does not keep your NAND clean.Still waiting for an XCI loader that's free. (Fuck NSP format, XCI keeps your NAND clean)
Why would releasing a free XCI loader help TX? Its the main advantage TX has over Atmosphere or any other CFW. Not wanting to provide "a better implementation" doesnt make sense. They don't need a better implementation to steal (since their own one works and is the only working one available).It is more complicated, but also nobody is interested in vindicating TX for supporting XCI (or providing TX with a better implementation)
People don't generally care about .XCI usage anymore than they cared about .3DS usage. Most of the people I encountered wanting to use .3DS files were people hesitant to leave Gateway, but Luma3DS natives could not have cared less. Generally speaking, Atmosphere/ReiNX natives don't seem to care either.And then theres the argument about there arent any advantages to XCI over NSP or at least no need for it, which again doesnt hold up cuz there clearly are reasons such as not having to install your games, being able to load XCIs off a HDD, etc.
Having all your XCIs on a HDD isnt made redundant with the portability of the device. You can store all your XCIs on the HDD just like how you would on a PC, except I can still play them all on the TV. And if I want to take any of the games away with me, I can install the XCI to the nand or mSD card. Nothing is "hindered" here. Its basically giving you a whole new option of convenience.People don't generally care about .XCI usage anymore than they cared about .3DS usage. Most of the people I encountered wanting to use .3DS files were people hesitant to leave Gateway, but Luma3DS natives could not have cared less. Generally speaking, Atmosphere/ReiNX natives don't seem to care either.
Many people, myself included, wouldn't use HDD storage, as it hinders or downright ruins the portability of the Switch, and the installation of an NSP file effectively isn't any different time-wise than sending an XCI file to an HDD or SD.
Considering the above, and considering that XCI files can easily be installed as if they were NSP files, XCI support is just not worth the trouble at all.
TL;DR, we have game backups already in the form of NSP files, and there doesn't seem to be any real advantage in using XCI files.
As you said, if I want to be portable, I need to install my backups to the NAND or microSD card. Using uninstalled XCI files is a hindrance in this regard.Having all your XCIs on a HDD isnt made redundant with the portability of the device. You can store all your XCIs on the HDD just like how you would on a PC, except I can still play them all on the TV. And if I want to take any of the games away with me, I can install the XCI to the nand or mSD card. Nothing is "hindered" here. Its basically giving you a whole new option of convenience.
My point was that people don't usually care about .XCI backup-loading in almost the exact manner they don't care about .3DS backup-loading.And the 3DS comparison isnt the same. 3DS flash carts used mSD cards for storage. When you can insert that same mSD card into your 3DS and install CIAs, its pretty much the same thing.
But when you have a 2TB USB drive plugged into your dock on SXOS, I cant just switch to Atmosphere and carry on using that same 2TB drive.
The only way this becomes the same without a free XCI loader is if someone creates a way to mount the HDD as the storage device when docked, and then allow us to install our NSPs onto it.
It's pretty much impossible to brick by installing an NSP file using an installer that checks to make sure the file is signed properly. On the other hand, XCI backup-loading doesn't do the same thing.And even then theres still the worry about not always knowing what you're installing and potentially risking a brick. I dont ever have to install XCIs before testing them and therefore never have to worry about it causing a brick.
Its not a "hindrance", its an option. No one is saying you have to pledge your allegiance to XCI, and then not be allowed to still use NSPs or install games.As you said, if I want to be portable, I need to install my backups to the NAND or microSD card. Using uninstalled XCI files is a hindrance in this regard.
Well it wasnt a very good comparison. You compared XCI loading (which literally has advantages), to 3DS backup loading that had zero advantages.My point was that people don't usually care about .XCI backup-loading in almost the exact manner they don't care about .3DS backup-loading.
How am I gonna brick anything with a XCI that never installs in the first place? In what way are NSPs more safer?It's pretty much impossible to brick by installing an NSP file using an installer that checks to make sure the file is signed properly. On the other hand, XCI backup-loading doesn't do the same thing.
In other words, NSP backup-loading is safer.
You're arguing semantics. The option is a hindrance.Its not a "hindrance", its an option. No one is saying you have to pledge your allegiance to XCI, and then not be allowed to still use NSPs or install games.
People keep looking at this like its some kind of war, where you need to pick a side. When actually this made up war is being used as a excuse to not provide an extra option that many people would use. Why the need to make excuses? I don't know.
This deep rooted mentality of creating a divide between the user base and then pitting them against each other, is really weird.
Well it wasnt a very good comparison. You compared XCI loading (which literally has advantages), to 3DS backup loading that had zero advantages.
Theres a good reason why people didnt care about .3DS backups, and those reasons dont apply here with XCI loading.
How am I gonna brick anything with a XCI that never installs in the first place? In what way are NSPs more safer?
It doesn't install, but it's still running code. That's where the danger lies, if the XCI file was messed with.How am I gonna brick anything with a XCI that never installs in the first place? In what way are NSPs more safer?
He doesn't understand.It doesn't install, but it's still running code. That's where the danger lies, if the XCI file was messed with.
This.It doesn't install, but it's still running code. That's where the danger lies, if the XCI file was messed with.
Im not arguing semantics. You're calling it a hindrance when the only hindrance is to the person having to create the XCI loader. If thats the real issue, then say it like it is.You're arguing semantics. The option is a hindrance.
When I'm making the point that a.) People generally only care that they have backup loading options, and b.) It's mostly users of Gateway and SX OS that care about .3DS and .XCI backup loading respectively, it's actually a very good analogy. Since it's an analogy, it's not going to be exactly the same.