warzonefury

Le pack switch_AIO_LS_pack continu ses évolutions et passe en version 5.17.0.

Pour rappel ce pack contient tout se qu'il faut pour le hack de toutes Switch pouvant lancer un hack en prenant en compte le maximum de configurations possibles.
Le homebrew intégré AIO_LS_pack_Updater permet d'installer/mettre à jour le pack, le firmware et de faire tout un tas d'autres choses directement via la console (installation/mise à jour du pack non recommandée sur des SD en EXFAT à cause de la corruption de données possible avec ce format).
Le mode Beta de l'application permet d'avoir les dernières évolutions du pack ou du homebrew AIO_LS_pack_Updater, par contre ces versions peuvent être instables.
 

Depuis cette news les évolutions sont les suivantes:

- Changelog pour la version 5.17.0:

• Ajout de Sphaira qui remplace le Homebrew Menu, une sauvegarde de ce dernier se trouve au chemin "switch/hbmenu.nro" qui peut être restauré via les options de Sphaira.
• Mise à jour de Status-monitor-overlay.
• Mise à jour du homebrew AIO_LS_pack_Updater en version 7.01.00 contenant les évolutions suivantes:
  • Optimisation de l'écriture des logs.
  • Ajout de fonctions pouvant servir plus tard.
  • Quelques autres corrections mineures.

Note: Pour traiter les problèmes particuliers de lancement de la sysnand en firmwares 17.0.0 et supérieurs c'est très simple via ce pack. Une fois le pack mis en place sur la SD on boot sous Hekate (avec une puce ça se fera tout seul), à l'affichage du tout premier logo on appui sur "vol-" pour annuler l'auto-boot réglé dans Hekate par défaut dans mon pack, on clique sur "launch" et enfin sur "Atmosphere sysnand", une fois le système lancé on peut éteindre la console et voilà, la sysnand refonctionnera ensuite comme avant.

N'hésitez pas à faire vos retours qu'ils soient positifs ou négatifs, ils seront les bienvenues tout comme le signalement de bugs ou encore la proposition d'améliorations, c'est aussi une bonne façon de participer à la scène et de faire vivre les projets. Pour cela nous avons mis en place un questionnaire de satisfaction, en plus de pouvoir reporter les problèmes sur Github ou sur le forum vous pouvez utiliser ce questionnaire pour nous donner vos opinions de façon anonyme (pour des problèmes spécifiques il vaut mieux reporter sur Github ou ouvrir un sujet sur le forum, il y aura une réponse bien plus rapide et cela permet de demander plus de détails pour identifier et peut-être résoudre le possible problème.

Pour les détails des changelogs, le téléchargement et les instructions d'installation et d'utilisation du pack c'est sur cette page que ça se passe et vous avez aussi un tutoriel plus détaillé sur cette page, d'ailleurs ce dernier site contient aussi pas mal de tutoriels notamment sur la Switch. Enfin si vous souhaitez voir le changelog complet du pack il est consultable ici.

Si vous appréciez mon travail vous pouvez me faire une donation via ce lien si vous avez un compte Paypal (n'engendre pas de frais de transaction) ou via ce lien si vous n'avez pas de compte Paypal

Très bonne version, pour moi là on commence à avoir un homebrew qui devient très fonctionnel.

Au passage pour les utilisateurs de mon pack que préférez-vous que je fasse, je remplace directement le HBMenu par Sphaira (solution que personnellement je préfère) ou je le met juste comme simple homebrew?

Spacecraft-NX charge directement Atmo

les trinket ne fonctionnent que sur les non iPatched.

le ntfs, tu peux faire du chkdsk derriere si y'a un pb. Bon courage pour le exfat qui n'a pas de journalisation.

Juste ca ca devrait faire tourner des têtes.

@Oldsnake : quand la slim sortira.

@Lotus51 : meme reponse ^^

J'ai acheté ma PS3 en version SLIM, la PS4 en SLIM, la one en version S, et depuis les déboire des premières PS1, xbox 360, PS3 en version FAT... ben plus jamais de console Day One

J'attends la révision matérielle (celle qui chauffe moins, qui sera plus petite, qui consommera moins, et qui sera debugée).

Mais faut être patient, voila tout.

Et j’aurais plein jeux a 10€ d'okaze

Excellent çà!

Par contre correction sur la news à faire, pour SX OS il faut effectivement renommer le dossier "atmosphere" en "sxos" mais il faut aussi renommer le dossier "contents" qu'il contient en "titles".

Bon clairement ce truc va rejoindre la préparation d'une SD dans mon script pour la prochaine mise à jour.

@dem1980 : Pour bien comprendre il te faut décomposer SX OS en deux phases, la première est le payload "SX Loader" qui fonctionnera quelque soit le firmwares d'une Switch non patchée et la seconde phase est le lancement du CFW, phase qui ne fonctionnait pas en firmware 7.0.X avant cette version 2.6. De fait, quand on lance l'emunand avec SX OS, on boot donc d'abord sur le loader puis on boot l'emunand, cette phase ayant la particularité de rediriger les différents flux vers la SD avant de faire un soft reboot (en gros) puis de lancer le firmware stocké dans l'emunand, raison pour laquelle même avec une configuration Sysnand 7.X et emunand 6.2.0 il était possible de lancer SX OS en emunand. Du coup non, SX OS n'était pas compatible 7.0.X avant alors que maintenant oui, on peut lancer SX OS sur la sysnand et sur l'emunand en 7.0.X, avant c'était juste le fonctionnement de l'emunand qui était exploité pour la lancer car le firmware 7.X n'était en fait jamais chargé par la phase deux, le lancement du CFW. J'espère t'avoir un peu mieux éclairé.

@BostonCeltics : Tien bah toi tu est le parfait spécimen des personnes que je décris dans mon paragraphe suivant, pour rappel voici l'article en question qui est plutôt objectif contrairement à se que tu semble prétendre et qui avait juste pour but de clarifier les choses.

C'est fou, à chaque fois qu'on a une news sur SX OS c'est du grand n'importe quoi les commentaires et ça suit toujours la même logique, c'est d'une tristesse sans déconner. Et puis les "pro SX" c'est épuisant aussi, même face à la critique constructive pas moyen d'avoir de débats car soit c'est de la dénigration à la limite de l'insulte, soit les arguments avancés n'ont pas de fondements ou sont développés avec des raccourcis (je ne dis pas que dans l'autre sens ça n'arrive pas non plus mais c'est tout de même plutôt fréquent dans ce sens là).

En premier lieu on a les mercis, normal. Ensuite on a les "Bah alors vous voyez que la TX savent développer", chose que l'on sait déjà et qu'ils n'ont plus à prouver, c'est juste que par exemple SciresM est bien au-dessus d'eux, au moins en terme de hack pur sur cette console et çà aussi c'est plus à prouver. Après on a l'analyse de l'OS qui sort et donc le débat du vol de codes revient alors que là aussi il n'y a plus rien à prouver, la TX utilise du code d'Atmosphere et c'est un fait, là ils n'ont pas utilisé Sept dans leur OS mais à mon avis ils l'ont utilisé pour découvrir les clés permettant de lancer leur OS en firmware 7.0.X, raison pour laquelle il semble y avoir des traces de Sept dans les dernières beta selon moi. Et enfin quand c'est une beta, on a la discussion de qu'est-ce qu'une beta et comment on test les choses avant une release. Après on fait un mixage avec divers questions/réponses d'utilisateurs et on a le flux typiques des commentaires de news SX OS et ces mêmes débats qui reviennent inlassablement alors que rien ne change dans les faits, par exemple si demain SX OS n'utilise plus du tout du code d'Atmosphere alors là se sera l'occasion de relancer le débat mais sinon aucun intérêt, juste on note les choses qui sont toujours utilisées, celles qui ne le sont plus et celles qui sont apparues et on passe à la suite, à moins de prouver que se qui est dit est faux mais là il faut donc évidemment avancer des preuves valables et pas des allégations personnelles sans réel fondement.

Bon là je vois déjà d'avance se qu'on va me répondre, genr "Et l'emunand alors c'est toujours pas inclue à Atmosphere"... et bien je réponds de suite, c'est pas inclue car c'est pas la priorité de ce CFW et que bien évidemment quand on utilise le code des autres bah on a plus de temps pour développer le sien et la TX étant composée de bons développeurs tout de même cela fait la différence. Après niveau étique je ne vais pas encore expliquer la GPL et les conditions d'utilisation du code sous cette licence car je l'ai déjà fait un assez grand nombre de fois.

Pour la version 2.6 beta et ses bugs je trouve que c'était abusé comme bugs, juste l'activation de la licence qui ne fonctionne pas bah là je dirais juste que c'est sans commentaire et pour le bug du disque dur un simple test de deux minutes l'aurait mis en évidence. Alors oui, oublier des choses ça arrive mais bon on a à faire à une équipe de développeurs et pas à un développeur tout seul, ils développent dans un milieu professionnel en étant payés contrairement au milieu de l'open-source dans lequel on développe sur son temps libre (parfois on a une petite donation) et les tests ça prend beaucoup de temps donc les contextes doivent être mis en évidence quand on compare des choses et il est clair que de tel bugs dans une grande entreprise ne seraient pas passés. Après ils ont très vite corrigés le tir cette fois donc tant mieux mais l'excuse de "c'est une beta donc normal qu'il y ait des bugs" je veux bien mais pas des oublis aussi énorme car là c'est plus de l'ordre du bug, c'est clairement une erreur de négligence mais attention, je comprends aussi leur position car ils doivent se faire harceler par les utilisateurs. Ha oui et pour répondre au fait qu'il reste du code de Sept bah c'est probablement des oublis de choses testés pendant le développement, il n'est pas rare d'avoir de tels oublis dans le code, même chez les professionnels.

Pour info j'utilise aussi ce CFW, à la base c'était pour faire des tests mais maintenant je l'utilise aussi pour jouer à mes jeux dumpés car je trouve les XCI plus pratique quand on test souvent des choses et qu'on doit donc faire des restaurations fréquentes de la nand, pas la peine de passer des heures à tout réinstaller, juste les sauvegardes de jeux à sauvegarder puis à restaurer ça prend tout de même beaucoup moins de temps. Pour mes homebrews par contre j'utilise plutôt Atmosphere car les possibilités sont plus ouvertes sur ce CFW à ce niveau là, normal d'ailleurs puisque le but visé est l'optimisation et la personnalisation du firmware, c'est pas le piratage de jeux.

Détendez vous les gars .
Suite a mes soucis d'installation , warezonefury (qui est membre technicien de la team logicsunrise) est venu me donner un coup de main et on a fait des test .
Avec lithium, tinfoil (2.1 et la dernière), GoldLeaf , hgb et sx installer, pas moyen d'installer TOKI (testé differents dump) dans la NAND en 7.0.1 (aucun soucis en 6.2) et cela avec sx os ou atmosphere.
ET JE PARLE BIEN DE LA NAND ET NON DE LA SD !!!

J'en ai discuté avec softstar (que certain connaisse) lui aussi à remarqué avoir des petits soucis en 7.01.

Désolé si Warezonefury , Softstar et moi même sommes des mauvais utilisateurs ...
Mais non ce n'est pas pour critiquer mais pour donner l'info .
Donc merci de rester poli !!!


Apres vous en faites ce que vous voulez ....

Quelle différence (technique) y a t'il entre un NSP converti en XCI et un dump de cartouche ? Parce que à part dire que c'est un "faux" XCI tu expliques rien du tout. Je rejoins inconnux, il faut que t'argumentes sinon personne te prendra au sérieux.
 
Pour ma part ce que je peux dire c'est que XCI et NSP ont les mêmes NCA à l'intérieur. Les XCI est un HFS0 et le NSP un PFS0, les deux FS étant très similaires selon SwitchBrew.

Pour compléter, les différences entre un "vrai XCI" et un XCI converti sont l'absence de la mise à jour firmware (partition "update" du XCI qui est réduite au minimum), l'absence du certificat (du moins le certificat est falsifié), le XCI converti est trimé et le XCI converti est de type XCI 1 (je suis pas sûr pour ce dernier point). Du coup oui, jouer en ligne avec un XCI converti est aussi safe que de jouer avec un NSP (autant dire qu'il ne vaut mieux pas le faire) mais un XCI non monté n'est pas détectable par Nintendo (niveau structure) alors qu'un NSP installé laisse clairement pas mal de traces sur la nand (du moins un NSP non retraité par NSC_Builder pour supprimer les tickets/titlewrites parce qu'en ce cas c'est un peu différent). Perso j'utilise plutôt les super XCI car plus pratique quand on intervient très souvent sur la nand comme je le fais par période, pas besoin de tout réinstaller à chaque fois. Du coup @SPYCOS23 tu t'es clairement emballé pour rien et sans donner de vrais arguments en plus, l'utilisation de tel ou tel méthode dépend de comment on se sert du hack et @inconnux c'est très bien de dire que chacun fait comme il veut, c'est une marque de respect des choix de chacun mais bon c'est pas une argumentation non plus, faut aller plus loin.

Voilà voilà, se sera ma seule contribution à ce débat car j'ai déjà argumenté sur ces différences dans pas mal de sujets du forum donc je ne vais pas recommencer mais ça m'a agacé de lire tout çà.