Homebrew Question HBG shop new update and no full ram access

[blawar]

I also don't understand the message preventing to use Tinfoil if we don't use the fork. Why does it have to say that the installation is corrupted ? Just say that Tinfoil is not going to run on vanilla Atmosphere and that it requires your modifications, why would you talk about "corruption" ? It really seems like you're trying to mislead, I hope it's just an impression tho.

it’s not misleading, the installation is the entire zip file. if you didn’t copy the entire zip file, the installation is corrupted.

corruption: perversion of integrity.
corruption: debasement or alteration.

 

[Lacius]

Never going to happen. run reinx or sx os

SX OS costs money, and ReiNX doesn't have all of the features of Atmosphere, including but not limited to emuNAND and 9.0.0 support.

Atmosphere is arguably the best CFW.

reinx and sx os do not have any drm, you don’t need mercury for them.

As has been pointed out to you numerous times, the malware and DRM are pointless. The problem you're "solving" is imaginary, and it's petty. You're doing infinitely more work than if you just ignored the existence of Atmosphere and didn't support it if there are problems, but your vendetta against Atmosphere has caused you to infect it with malware.

 

[di4b0lik]

As has been pointed out to you numerous times, the malware and DRM are pointless. The problem you're "solving" is imaginary, and it's petty.

This sums up perfectly the whole story

 

[hippy dave]

One could say his decision making process on the entire subject has become corrupted.

corruption: perversion of integrity.
corruption: debasement or alteration.

 

[gamemasteru03]

Apparently tinfoil's fork of atmosphere also breaks all homebrew which is not compiled for 9.0. Here is a quote from the kosmos discord:

"@everyone PSA: The Tinfoil dev doesn't like some current changes in Atmosphere. So instead of fixing his shit, he decided to just make a custom fork of atmosphere and forces people to use it
And that custom fork apparently just doesn't have hid-mitm running properly
So using Tinfoil ultimately breaks button inputs in every single homebrew that hasn't been recompiled for 9.0.0 yet.
If you have any issues with EdiZon or any other homebrew not detecting button inputs, DO NOT USE TINFOIL/HBG. To fix the issue, clean your SD card and install a fresh copy of original Atmosphere/Kosmos."

 

[linuxares]

Okey I promised a person to stay out of it but I just gonna give my 2 cents.

1) Stop using Tinfoil DZ then!
2) Don't use an unofficial fork of Atmosphere just for one software?
3) Use another supported OS that works with Tinfoil DZ?
4) Use one of the unofficial fixes for Tinfoil DZ if need be?

Now I'm just going to back to monitor this thread.

 

[gizmomelb]

I'm sure all the atmosphere user's whining only strengthens Blawar's resolve.

 

[blawar]

Apparently tinfoil's fork of atmosphere also breaks all homebrew which is not compiled for 9.0. Here is a quote from the kosmos discord:

"@everyone PSA: The Tinfoil dev doesn't like some current changes in Atmosphere. So instead of fixing his shit, he decided to just make a custom fork of atmosphere and forces people to use it
And that custom fork apparently just doesn't have hid-mitm running properly
So using Tinfoil ultimately breaks button inputs in every single homebrew that hasn't been recompiled for 9.0.0 yet.
If you have any issues with EdiZon or any other homebrew not detecting button inputs, DO NOT USE TINFOIL/HBG. To fix the issue, clean your SD card and install a fresh copy of original Atmosphere/Kosmos."

I think its hillarious, @WerWolv is too stupid to know its not the atmosphere fork causing the issue, and he announced his ignorance on how many servers? lol.

The issue is my custom nxhbloader that has shortcut keys:

{
"DEFAULT": "sdmc:/hbmenu.nro",
"L": "sdmc:/switch/mercury/mercury.nro",
"ZL": "sdmc:/switch/tinfoil/tinfoil.nro",
"ZR": "sdmc:/switch/nxmtp/nxmtp.nro"
}

Initializing HID in hbloader breaks scires temporary HID fix for older homebrew, and there is no easy way around this due to how hbloader works.

So while I could remove those hotkeys to restore old homebrew, I do not think it is worth it. I did however release a signed hbl.nsp that does have the hotkeys disabled if anyone really wants to use old homebrew.

It would have taken WeWolv less time to recompile edizon for 9.0.0 than to type that announcement He isnt interested in fixing things, he just wants to whine.

 

[andyhappypants]

Surely if blawar doesnt want tinfoil to work with atmos then thats up to him? Entitled folk are going to cry but hey, it is what it is!

 

[Deleted-452294]

So basically, Incognito cannot write because Atmosphere is blocking something that the Switch itself wouldn't block (I mean, I have no knowledge in this field but I guess Nintendo wouldn't let people modify their certs so I don't see them leaving this wide open so I'm asking) ? Just like the other CFWs ? Or did Atmosphere start blocking from an update? Involving the fact that it actually changed its behavior after an update

Atmosphere started blocking writes after an update. The original firmware does not block writes.

He's already replacing files on the SD for the entire CFW + Hbloader, does that not require restarting? And how is blocking access to title mode or changing the buttons not breaking things? There's a bizarre double-standard here.

You're not taking what I'm saying in the proper context, and you're working under the assumption that I would agree on his choice. You did not understand my reply at all, as you seem to lack any understanding of the environment under which homebrew is executed.

Well, I asked for elaboration in order to understand your opinion. If you don't wish to provide further information, this point of discussion ends here.

I do not wish to spoon-feed people with my opinions and arguments, as I am trying to debate with you under the assumption that you have a minimal amount of knowledge and experience working with devkitPro's toolchains, should them be for Switch, 3DS, Wii U, DS, Wii, GameCube, or any other console.

I really don't know a lot of the politics behind this, but that doesn't mean I agree with hijacking a user's CFW/normal functioning. Why do you maintain tinfoilmod if you don't also hold this opinion to some degree?

Same this as the first point: you do not understand the context in which I said that. Should I reiterate: I do not agree with this decision and I do not believe that "hijacking" the configuration of an user's firmware modification is a proper way to do things, or should ever be. Homebrew should run under original firmware, or under original firmware with minimal modifications.

Software that can brick my Switch if it's on a certain OS should not be bundled with other software that provides an entirely different function. I do understand how if there is a given standard for how an .nro should function, and they're violating that standard, that an app could function in an unknown way, and that could shift the blame to the CFW's team instead, however, with something as serious as a brick, I'd personally go out of my way to either ensure I supported everything, or to ensure it wouldn't run if it didn't. I'd add a CFW whitelist for safety, to ensure there wasn't a brick, as blawar insists has happened. Even knowing an NRO should function a certain way, if I also know that there are more practical restrictions than that, I'm going to avoid doing anything that might cause catastrophic harm. That said, I also think this point of issue is neither here nor there, as incognito is not part of tinfoil, and this is ultimately a gish gallop.

CFW lists are not possible, as there can be as many as possible, and is not future proof. Plus, if one thing breaks or differs from original firmware, how can you be sure that any of the other things won't? The burden should be on the firmware modifications themselves; as it is completely safe under original firmware, which is the ground truth.

 

[hippy dave]

Never going to happen. run reinx or sx os

 

[Ashura66]

Do i find it irritating to have to install a forked atmosphere? Absolutely.

Do i still want the convenience of the app and free games? Abso-fucking-lutely.

I'll put up with it for now. Nobody is forcing me to use it.

Allow me to tell you about the wonders of the BigPP. All the convenience of HBG shop without the DRM, without forcing you to use pointless shit, containing all the first party tittles and without all the begging for donations

I would say: Do it!
I always wonder why Atmosphere users whine about everything and trying to start a flame war....
I've never saw SX OS users doing that (:
blawar ftw

You obviously haven't looked deep enough

@blawar since everyone already knows that HBG's tinfoil can be fully functional on atmosphere without any of the atmosphere mods or mercury; how about you stop this silliness and give the community what they want: a clean functional HBG without mecury and without atmosphere modifications? There's a mod for hbg that does this and several community versions we all know it can be done, its not at all a secret.

That's all you have to do to garner good will from this community you are so desperately trying to explain your point of view and reasons for your odd choices.

Something like that already exists using the tinfoil mod: The BigPP (Big Pirate Pack).All the convenience of HBG shop without the DRM, without forcing you to use pointless shit, containing all the first party tittles and without all the begging for donations. Currently doesn't have as many mirrors as HBGShop but it's getting there, the team behind it add mirrors everyday

 

[gizmomelb]

View attachment 180429

which emulators supposedly don't work properly under SX OS? I'm betting they were launched in applet mode, so don't have enough memory. Please give a list so I can test. Thank you.

--------------------- MERGED ---------------------------

re: SX OS users not flaming atmos users:

You obviously haven't looked deep enough

yeah there was that brief period of a few weeks where frankly the majority of SX OS users had had enough of the anti-SX OS bullshit that they retaliated and gave the trolls a taste of their own medicine. Wasn't very nice, was it?

 

[hippy dave]

which emulators supposedly don't work properly under SX OS? I'm betting they were launched in applet mode, so don't have enough memory. Please give a list so I can test. Thank you.

The new Flycast core apparently (check its thread). It's not a memory thing, it's a "missing vital features" thing, according to m4xw.

 

[Deleted User]

Honestly, as someone who's new to the Switch Homebrew scene, seeing people having CFW wars is hilarious and very pathetic. Every CFW has its positives and negatives. ReiNX and SXOS both are great in their own ways, and the only problem that is surfacing is that Blawar restricts Atmos for no structural reason whatsoever because he has a hard bias.

 

[The Real Jdbye]

While my TinfoilMod can remove this requirement for advanced users, the default behavior and configuration of hbl 2.2 is to be considered harmful for homebrew development. It heavily restricts the heap size for Applet homebrew, with no possibility of opt-in or opt-out.
I do not believe the current major toolkit developers for the Switch homebrew community have their community's best intentions in mind. While I would appraise them for building a handful of the tooling, it clearly shows that there is no intention to do things properly (libnx: apm bug, HID issue, no support for shared libraries, unstable API, ...) or listen to the developers themselves (see the devkitPro archival case, for an example of this point). Their efforts are commendable, but the results are often poor, disappointing and deceiving.
I can only partially agree on your point where you claim that "There's no "standards-compliant with the other two CFWs"". In order for homebrew to be generally as compatible as possible, ReSwitched and Switchbrew had decided on a common ABI for NRO-based homebrew, for which you can find more information about here. However, it has been broken often times; usually for the sake of compatibility. Nowadays, most homebrew will require a firmware modification or custom firmware to work; which defeats the entire purpose of NRO-based homebrew, in my opinion; unless modified. Some of the workarounds for these issues could have been implemented in nx-hbloader itself, but were instead implemented in Atmosphere. "New changes by the front-runner are always going to be out of "standards"" does not mean others should follow or that they should just be accepted. This kind of behavior could mean a lot of trouble in the future.
Finally, I can attest that there is no issue with security or privacy with DZ/Tinfoil, as I've reverse-engineered it. Would you wish to confirm this and make further claims about it, feel free to reverse it yourself. I do not believe that closed source software is an issue by itself.

Actually, there is a setting in one of the config files to adjust memory allocation in applet mode. I don't know how long it's been there, but it's at least been there for the past couple versions or so.
Although they did not exactly make it obvious how to modify the setting correctly. I'd like to see that simplified a bit.
In the end applet mode is always going to be a limitation. If you want more RAM, don't use applet mode. I don't see any problems with that.
Can't comment too much on the other things as I don't know the details personally, but the source is there for people to improve upon and make pull requests. That's what open source is all about, right?

you are mistaken. title mode was not intentionally broken, it was a consequence of a “bug” in atmosphere. if you invert the hold r functionality , like ams used to be, then you have to hold R to load games too which is not viable. the only way to disable hbmenu launching on vanilla ams with the r button inverted was to disable title override. i had to fork ams to get the functionality i wanted.

That is all well and good except for one thing. If you wanted to do it properly you would have added a setting in loader.ini to invert the behavior on the album app only, and not use a dirty hack like disabling title override altogether. You fix one problem but you create another. If you implemented it properly, you could even make a pull request and have it merged into Atmosphere. Instead of forcing changes on people who might not want them, if they were implemented properly with configuration options, you could make a pull request and all those features and changes you want could be merged into Atmosphere, and then you wouldn't have issues with it.

You never had prodinfo brick protection, even scires admits its a near worthless meme. It was a false sense of security. It didn't stop bricks, it caused some bricks, and generally annoyed most users. The BIS "protection" code in atmosphere is pretty much just a disaster that protected no one. Scires himself said it was not meant to prevent malicious software from bricking you.

Citation needed. When and where exactly did he say these things?

 

[blawar]

Actually, there is a setting in one of the config files to adjust memory allocation in applet mode. I don't know how long it's been there, but it's at least been there for the past couple versions or so.
Although they did not exactly make it obvious how to modify the setting correctly. I'd like to see that simplified a bit.
In the end applet mode is always going to be a limitation. If you want more RAM, don't use applet mode. I don't see any problems with that.
Can't comment too much on the other things as I don't know the details personally, but the source is there for people to improve upon and make pull requests. That's what open source is all about, right?

That is all well and good except for one thing. If you wanted to do it properly you would have added a setting in loader.ini to invert the behavior on the album app only, and not use a dirty hack like disabling title override altogether. You fix one problem but you create another. If you implemented it properly, you could even make a pull request and have it merged into Atmosphere. Instead of forcing changes on people who might not want them, if they were implemented properly with configuration options, you could make a pull request and all those features and changes you want could be merged into Atmosphere, and then you wouldn't have issues with it.

Citation needed. When and where exactly did he say these things?

Why do you assume I did not try to invert the setting in loader.ini? Inverting the setting loads hbmenu when you click on a normal game, which obviously wont work. Noone wants to hold R to launch legit games.

I'm too busy to find it, just search for scires gbatemp post history, we got into a debate about it on GBATEMP not too long ago.

 

[The Real Jdbye]

Why do you assume I did not try to invert the setting in loader.ini? Inverting the setting loads hbmenu when you click on a normal game, which obviously wont work. Noone wants to hold R to launch legit games.

I'm too busy to find it, just search for scires gbatemp post history, we got into a debate about it on GBATEMP not too long ago.

I'm saying modify the loader module to invert the setting only on the album app, and add a configuration setting to toggle it.

 

[blawar]

I'm saying modify the loader module to invert the setting only on the album app, and add a configuration setting to toggle it.

it is not in loader, and I did modify it, hence the fork.

 

[legion700]

I hope HBG won't decide to release a HBG CFW with a build in HBGSHOP and ban everyone using renix\atomsphere.
I have seen a lot of s**t about iOS jailbreak communituity.