Does that mean that with this Atmosphere build of yours we'll have more free memory space for the sys-modules?
for now all it means is that mesosphere executes the patching of FS, and loader embeds the exefs_patches, which should remove the need for .ips patches or sys-patch.
if the end user still has sys-patch on their sd card, it will still run and just say most of everything is patched already by "file"
(olsc and loader being patched by sys-patch in my fork doesn't make any difference, as loader is edited, erpt edited, olsc config added into sys-mitm)
nifm saying "unpatched" is most likely the pattern needing more fine-tuning due to its length (and length of the patch overriding some of the bytes in the pattern)
Why would it mean that? sys-patch doesn't use any extra memory. It loads at startup, does its thing, then it's gone. What you see in the overlay comes from its settings and its log... (to my understanding)
the overlay module itself hogs a lot of memory,
anyway, sys-patch itself is flawed in some aspects, as it runs by svcdebug editing memory of running applications, which can potentially cause the patches to become un-patched if HoS reinitializes itself such as after sleepmode.
for both mesosphere patching (fs_patch) and loader patching (exefs_patches), it is done before the application is started.
for the fs_patch inside of mesosphere, it patches it the moment mesosphere decompresses FS, right before it is loaded into memory and executed. (both hekate and fusee.bin loads mesosphere, regardless of boot method, so both methods of booting gets full set of patches using this type of patching)
Or at the very least you have a great initial setup.
