It's an other solution but I'm speaking about the actual code witch already work, just the ES6 doesn't need to be tested on 18.0.0 by the module.No, it must be fixed for 18.0.0 support.
It's an other solution but I'm speaking about the actual code witch already work, just the ES6 doesn't need to be tested on 18.0.0 by the module.No, it must be fixed for 18.0.0 support.
Are you saying that it doesn't work as-is? I think it works just fine. "must" is a strong word...No, it must be fixed for 18.0.0 support.
*pull request...If you got time you can do a merge request on the new repo now
Are you saying that it doesn't work as-is? I think it works just fine. "must" is a strong word...
*pull request...
but people with certain types of jobs maybe shouldn't be establishing an account on a Russian web page...
Yep.Does this still work on the latest firmwares i have installed? (that i mentioned above)?
You only need one of them, but if you want both, that's an option as well. If you prefer to have less files/clutter on your SD card, pick one of them.
- Do I need to use this if I have sig patches installed?
- Should I keep this on my switch or remove it?
After it got removed from the Github, it needed to be updated once firmware 18.0.0 got released. Thankfully, someone was able to provide an update so that it works on 18.0.0 as well.Since it got removed from Github does that mean the dev is no longer work on it anymore?
There's also sys-patch-overlay.ovl in \switch\.overlays folder.How do I remove it, is it simply deleting the corresponding '420000000000000B' folder in /atmosphere/content? Anything else I need to do?
Depends on how you boot your Switch.Do I need to use this if I have sig patches installed?
Sorry i'm new to the scene. When would I need to use these payloads? I'm running a OLED Switch with HWFly so isn't the payload automatically executed to boot into Hekate from the modchip? Or which payloads am I using, is what you mentioned still relevant to me?Depends on how you boot your Switch.
If you use fusee.bin as payload (either directly or through Hekate) you need sys-patch because fusee no longer support kip patches.
If you use fss0 in hekate then you don't need sys-patch but it still wouldn't hurt to have both just to be sure
Ah, so you have an OLED with a modchip. Sure, you're booting into Hekate automatically.Sorry i'm new to the scene. When would I need to use these payloads? I'm running a OLED Switch with HWFly so isn't the payload automatically executed to boot into Hekate from the modchip? Or which payloads am I using, is what you mentioned still relevant to me?
[config]
autoboot=0
autoboot_list=0
bootwait=0
autohosoff=0
autonogc=1
updater2p=1
backlight=100
[CFW - sysMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
atmosphere=1
emummc_force_disable=1
icon=bootloader/res/icon_payload.bmp
[CFW - emuMMC]
fss0=atmosphere/package3
kip1patch=nosigchk
emummcforce=1
atmosphere=1
icon=bootloader/res/icon_payload.bmp
[Stock - sysMMC]
fss0=atmosphere/package3
emummc_force_disable=1
stock=1
icon=bootloader/res/icon_switch.bmp
fss0=atmosphere/package3
and kip1patch=nosigchk
are the important ones if you're using sigpatches in order to play your game backups.Ah, so you have an OLED with a modchip. Sure, you're booting into Hekate automatically.
If you plan on using sys-patch, you don't have to do anything additionally. Your game backups will work.
If you plan on using sigpatches, you'll need to check if your hekate_ipl.ini has entries like these:
Code:[config] autoboot=0 autoboot_list=0 bootwait=0 autohosoff=0 autonogc=1 updater2p=1 backlight=100 [CFW - sysMMC] fss0=atmosphere/package3 kip1patch=nosigchk atmosphere=1 emummc_force_disable=1 icon=bootloader/res/icon_payload.bmp [CFW - emuMMC] fss0=atmosphere/package3 kip1patch=nosigchk emummcforce=1 atmosphere=1 icon=bootloader/res/icon_payload.bmp [Stock - sysMMC] fss0=atmosphere/package3 emummc_force_disable=1 stock=1 icon=bootloader/res/icon_switch.bmp
Linesfss0=atmosphere/package3
andkip1patch=nosigchk
are the important ones if you're using sigpatches in order to play your game backups.
To reduce the clutter on your SD card, I'd suggest that you use sys-patch instead of sigpatches.
https://rentry.org/SwitchHackingIsEasyHi, I have just updated to Atmosphere 1.7.0 with FW 18.0.0 and got some issues when running my games, and as I searched the internet for some solutions, I found out that it's the update from 1.7.0 that caused the problems.
Currently I use modified fusee to be able to launch the game, and ran into this thread talking about sys-patch and hekate package 3 and I think those are better solutions. But I don't know how to enable/use those sys-patch / hekate package 3 mode, can you point me to the right direction?
Thanks
Well, I did check that site (from your post few pages back), but I can't find anything that can help me understand about this hekate package 3. And for the sys patch, do I just download and copy paste to SD Card? Any config or setup to "turn it on"?
Hi, I have just updated to Atmosphere 1.7.0 with FW 18.0.0 and got some issues when running my games, and as I searched the internet for some solutions, I found out that it's the update from 1.7.0 that caused the problems.
Currently I use modified fusee to be able to launch the game, and ran into this thread talking about sys-patch and hekate package 3 and I think those are better solutions. But I don't know how to enable/use those sys-patch / hekate package 3 mode, can you point me to the right direction?
Thanks
Thanks for the sys-patch info.sys-patch
and for fss0 method, everything is explained ONE message above yours, the one you quoted, actually...did you ever read it ?
- download sys-patch 1.5.1
- unzip (root of microSD card)
- done
Thanks for the detailed reply. So for my understanding what are the previous payloads you mentioned used for? Is it only for V1 Erista switches (if so why)? Why it not applicable to me?Ah, so you have an OLED with a modchip. Sure, you're booting into Hekate automatically.
If you plan on using sys-patch, you don't have to do anything additionally. Your game backups will work.
If you plan on using sigpatches, you'll need to check if your hekate_ipl.ini has entries like these:
Code:[config] autoboot=0 autoboot_list=0 bootwait=0 autohosoff=0 autonogc=1 updater2p=1 backlight=100 [CFW - sysMMC] fss0=atmosphere/package3 kip1patch=nosigchk atmosphere=1 emummc_force_disable=1 icon=bootloader/res/icon_payload.bmp [CFW - emuMMC] fss0=atmosphere/package3 kip1patch=nosigchk emummcforce=1 atmosphere=1 icon=bootloader/res/icon_payload.bmp [Stock - sysMMC] fss0=atmosphere/package3 emummc_force_disable=1 stock=1 icon=bootloader/res/icon_switch.bmp
Linesfss0=atmosphere/package3
andkip1patch=nosigchk
are the important ones if you're using sigpatches in order to play your game backups.
To reduce the clutter on your SD card, I'd suggest that you use sys-patch instead of sigpatches.
Well, I did check that site (from your post few pages back), but I can't find anything that can help me understand about this hekate package 3. And for the sys patch, do I just download and copy paste to SD Card? Any config or setup to "turn it on"?
The payload.bin is used on vulnerable V1 injected via USB and read by the modchip as the PAYLOAD.BIN file at the root of your SD card, is the bootrom replacement for mod the console.Thanks for the detailed reply. So for my understanding what are the previous payloads you mentioned used for? Is it only for V1 Erista switches (if so why)? Why it not applicable to me?
Okay thanks. I'll try to keep it up.Yep.
You only need one of them, but if you want both, that's an option as well. If you prefer to have less files/clutter on your SD card, pick one of them.
After it got removed from the Github, it needed to be updated once firmware 18.0.0 got released. Thankfully, someone was able to provide an update so that it works on 18.0.0 as well.
There's also sys-patch-overlay.ovl in \switch\.overlays folder.
It says it's off for me too. But all patches are orange, so the sigpatches are already taking care of everything. Just look at your logs, and if it says everything is patched (except for es6, if your build of syspatch has it in there, and you are on fw 18), or es7 if not on fw18). If it's all good, then don't even worry about it. IF all patches are green, then you know for sure it's sys-patch that's doing its job, but not your sigpatches... but again, it doesn't matter which is doing it for you, as long as it's done.Okay thanks. I'll try to keep it up.
Follow up question to this, under the Tesla Menu when i open Sys-patch it shows all patches are active (see images IMG_1476 - IMG_1478), however when I open the sysmodule menu, sys-patch is turned off (IMG_1479) and when i turn it back on then leave & re-enter the menu it stays off.
How do I fix the sysmodule menu for syspatch?
Does this mean my sys-patch is working and the sysmodule is not reading it right?