foxan

Le problème est que le fichier "bootloader\hekate_ipl.ini" est hautement configurable donc l'intégrer dans un package peut devenir problématique. 

Mais voilà même dans ce fichier on pourrait vouloir changer des choses comme la ligne "autonogc=0" en "autonogc=1" pour utiliser les patches NOGC permettant de ne pas griller les Efuses du port cartouche (empêche le fonctionnement de celui-ci si les patches s'activent) (ce paramètre je le modifie via mon script qui donne un choix sur ce point) ou encore "bootprotect=0" en "bootprotect=1" pour protéger les fichiers de démarrage de la console. Bref pas si simple au final comme tu peux le constater.

PS: Ça fait plaisir de voir quelqu'un qui fait des efforts de recherches et de compréhension, au moins on se dit que les sujets que l'on a créés et les connaissances que l'on distille ne servent pas à rien, merci à toi pour ces efforts.

Oui, mais il pourrait y en avoir au moins un par défaut / simple. Et après ceux qui veulent et savent le configurer pour autre chose, le font (et le feront dans tous les cas) comme ils le souhaitent.

Ceux qui rajoutent les sig_patches, rajouteront la ligne qui va bien dans le fichier,  idem pour l'autongc, etc.. --> ca fait parti d'une manip complémentaire / donc pas une config par défaut.

(ou  mettre la ligne mais faire en sorte que la ligne ne soit pas active dans la fichier via l'ajout de " ;" ou autre élément de code qui permet cela).

Mais au moins avoir une base. Car au final, en apprenant sur le tas à mes dépends et ne le trouvant nul part de manière officiel,  je l'ai pris à partir d'une autre compilation sans savoir ce qu'il y avait dedans la première fois. (je pense que je ne suis pas le seul et que peu de monde s'y attarde vraiment).

Et le risque, de ce que j'en comprend est que si un ptit malin associe ces deux lignes  :

Et ben, j'ai mon icon emmuMMC dans hekate mais je vais lancer sur ma sysnand sans le savoir .

Alors oui, je sais je vais loin mais c'est pour exprimer l'importance d'avoir des fichiers de source fiable / officielle.

un fichier minimal qu'on fait évoluer suivant nos besoins.

Edit Nota :  faut rajouter "bootprotect=1 ? qu'entends-tu par protéger les fichier de démarrage ?

Nota 2 : pour les efforts de recherches et de compréhension, je par du principe que c'est un peu la base pour éviter de tout casser. Comprendre un minimum ce que l'on fait permet de résoudre soit même quelque porobleme et surout ne pas faire de connerie ou avoir de fausse idée/suivre bêtement de fausse idée.

Oué ^^, c'est pas vraiment structuré pour un tuto, je donne pas vraiment de détails pour savoir quoi mettre où ^^

Après, c'est vrai que je pourrais mieux expliquer si ça intéresse . . .

Allez, j'explique un peu plus en détails pour ceux qui serait intéressé:

- 1 - Dans un 1er temps, prendre la dernière version d'emuiibo ainsi que emutool ICI

- 2 - Décompressez les 2 fichiers

- 3 - Pour ce qui se trouve dans "emuiibo", copiez tout ce qui se trouve dans le dossier "SdOut", c'est à dire le dossier "atmosphere" et "switch" que vous collerez à la racine de votre µSD

- 4 - A ce stade, je vous suggère de créer le dossier (soit sur le bureau de votre PC ou à la racine de votre µSD) "emuiibo" avec un autre dossier à l'intérieur qui se nommera "amiibo", ça donne sur la µSD: emuiibo/amiibo

- 5 - Ensuite, rejoignez le dossier d'emutool, et lancez "emutool.exe" sur votre PC

- 6 - Dans l'onglet "1 - Choose a virtual amiibo" , cochez tout en bas "Generate all amiibos at once, instead of the selected one", ce qui aura pour effet de créer tout les amiibos

- 7 - Ensuite, dans l'ongle "3 - Generate the virtual amiibo" cliquez sur "Create virtual amiibo"

- 8 - Là, choisir le dossier de destination que l'on a créé à l'étape 4, et faites "OK", vous allez voir, c'est très rapide, mais c'est bon, tout est créé

- 9 - Si vous avez créé les dossiers de l'étape 4 directement sur votre µSD, vous avez terminé, et si vous l'avez fait sur votre PC, il ne reste qu'à copier/coller à la racine de votre µSD

- 10 - Vous n'avez plus qu'à démarrer votre CFW préféré, et vérifiez sous le menu "home" par exemple si vous avez bien vos amiibos dans le menu Tesla (Combinaison de touches en restant appuyé sur "L" + "croix du BAS" + "Appui du stick droit"), normalement, le menu "TESLA" apparait, sélectionnez "emuiibo" avec la touche "A", descendre sur "view amiibo" et touche "A" pour voir votre liste, dans "manage emulation" vous pouvez activer ou désactiver les amiibos. La méthode est bien sûr la même en jeu lorsque vous voulez utiliser un amiibo . . .

Info: Il faut bien sûr installer le menu Tesla, voir ce sujet

Voilà, mini tuto assez complet je pense ^^

La version 4.3.119 a été mise en ligne, elle contient entre autres la mise à jour vers Atmosphere 0.19.2 qui pourrait amener certains éléments à ne plus fonctionner correctement. Si vous rencontrez des soucis n'hésitez pas à m'en faire part.

Cette nouvelle version contient également pas mal de mises à jour de fonctionnalités diverses comparé à la version 4.3.118, pareil si vous rencontrez des bugs n'hésitez pas à me faire des retours.

Bref chinois VS chinois
Qui gagne

si la touche de ton joycon R ne fonctionne plus tu peux le remplacer par celui de "L" mais je sais plus dans quel fichier de config il faut le faire.

Une solution serait peut etre le spoofing comme sur PS Vita.
Une manip permettant de faire passer le jeu sur un firmware antérieur.

Ça existe déjà mais ça a aussi ses limites à cause du SDK utilisé par le jeu.

@foxan : Pour les consoles V2 on s'en fou de SXOS en lui-même maintenant qu'Atmosphere est compatible avec ces consoles, le seule problème est d'avoir une puce. Et comme tu le dis la seule vrai perte chiante entre SXOS et Atmosphere est les XCI sur disque dur externe, pour le reste Atmosphere fait au moins aussi bien et même bien souvent mieux. Et pour les sig_patches maintenant on peut les créer nous-même, via AutoIPS-Patcher que j'ai aussi intégré dans mon Ultimate-Switch-Hack-Script dans uine procédure en français (faut juste un fichier contenant les dernières clés communes et sinon le reste est totalement guidé durant le script).

Bonjour,

Vu les demandes grandissantes et récurrentes de ces derniers temps sur le forum je vais ici simplifier quelques tutoriels ou pointer directement certains tutoriels histoire de clarifier des démarches basiques pour les débutants.

Pour la plupart de ces démarches vous pouvez aussi utiliser mon Ultimate-Switch-Hack-Script, celui-ci permettant de simplifier grandement beaucoup de choses.

Avant tout je suggère fortement la lecture de ce sujet qui pose de bonnes bases, ainsi que ce sujet contenant pas mal d'infos sur le bannissement de la console.

Enfin, pour aller plus loin, vous avez également la FAQ qui contient tout un tas d'informations régulièrement mises à jour, je vous conseil vivement la lecture des parties "Lexique adapté à la Switch", "Structure de la SD", "Combinaisons de touches hardware:", "Injecter un payload", "Informations générales", "Bootloaders et CFWs", "Homebrews" (au moins le début de la section) ainsi que les infos au début de cette même FAQ. Je sais, ça fait beaucoup de lecture mais il n'est pas nécessaire de tout comprendre, cela permet de se familiariser un peu avec le hack Switch et les conceptes qui l'englobe. Enfin notez également la partie "Liste des tutos/sujets importants" qui, comme son nom l'indique, vous donnera une bonne liste de tutos divers concernant certains points du hack Switch.

Si vous voyez des choses à ajouter, modifier, clarifier, etc... n'hésitez pas à me le faire savoir.

Notes sur les consoles Mariko: S'il vous plaît veuillez impérativement lire ce sujet, vous y apprendrez les choses à ne vraiment pas faire sur ce genre de consoles.

Note sur les consoles (ou plutôt nand/emunand) utilisant un PRODINFO donneur: Il se peut qu'une erreur se produise lors de la mise à jour en 14.0.0 ou supérieur (erreur avec le programme "0100000000000025" affichée par le crash d'Atmosphere), dans ce cas il sera nécessaire de recréer le PRODINFO avec la dernière version du payload Prodinfo_gen (mode "donor" si on souhaite pouvoir utiliser le port cartouche, sinon le mode "scratch" fonctionne; lire le readme du projet pour savoir comment cela fonctionne), de le chiffrer avec les clés de la console avec NXNandManager ou la Nand Toolbox de mon Ultimate-Switch-Hack-Script et de l'injecter dans la nand/emunand avec NXNandManager ou la Nand Toolbox de mon Ultimate-Switch-Hack-Script. Vous pouvez regarder ce sujet dans lequel on parle de ce souci.

Règles de ce sujet:
Ce sujet ne doit pas servir à régler les petits problèmes des uns et des autres sur tel et tel démarche, ceci ne ferait que créer une discussion anarchique au vu du nombre de sujets abordés ici. Par contre vous pouvez me suggérer d'ajouter des informations, d'en modifier certaines, de clarifier certains points ou tout autre suggestion constructive et bien sûr les remerciement seront aussi appréciés. Les messages ne respectant pas ces règles feront l'objet d'une demande de suppression auprès des modérateurs du site et en cas d'insistance je leur demanderai une prise de sanction.

Compatibilité du hack:

Il y a quoi comme pack Atmosphere+SxOs de pratique ?

Ceux que tu cré toi-même, mon Ultimate-Switch-Hack-Script permet par exemple de faire cela de manière assez précise, par contre il n'intègre plus les sig_patches pour Atmosphere/Hekate donc c'est la seule chose à réinstaller soi-même et d'ailleurs à ce moment là il faudra faire attention à ne pas écraser le fichier "bootloader/hekate_ipl.ini" qui est souvent contenu dans les packs de sig_patches car ma version de ce fichier fonctionne très bien et couvre bien plus de cas que ceux qui se trouvent dans les packs de sig_patches.

Depuis cette news, mon ensemble de scripts batch permettant de faire de multiples choses liées au hack de la Switch a, comme toujours, un peu évolué et des bugs ont été corrigés.

Pour rappel, mon script permet par exemple de préparer une SD avec le contenu nécessaire au lancement d'un CFW, des homebrews, des modules et des overlays; de plus, il est possible de créer des profiles pour chaque élément se qui permet une configuration à la fois assez précise et qui peut être reproduite rapidement. Le script contient aussi de multiples fonctions permettant d'agir sur la nand (infos, dump, restauration, activation/désactivation de l'auto-rcm, montage d'une partie de la nand sur le PC grâce à Memloader...), il contient un lanceur de payload, on y trouve aussi NSC_Builder traduit en français et encore bien d'autres choses, voir cette page pour voir une liste de fonctionnalités plus détaillées.

L'évolution notable est surtout la suppression des sig_patches de la préparation d'une SD et du script de débrickage. Pour le reste se sont surtout des mises à jour des éléments, des corrections de bugs diverses, de petites amélioration ici et là mais tout de même quelques nouvelles choses comme la gestion du répertoire "sd_user" qui permet de copier le contenu de celui-ci sur la SD à la fin de la préparation de celle-ci pour garder vos configurations personnelles si souhaité, la création d'une emunand sur la SD (fichiers ou partition) via un dump (merci @eliboa pour l'intégration de cette fonctionnalité à la version CLI de NXNandManager), etc..., il me serait impossible de tout lister, je vous conseille d'aller lire les changelogs indiqués ci-après.

La version base est également passée en 4.3.63, notamment pour corriger quelques bugs sur le gestionnaire de mises à jour.
 

Je me permet de rappeler que mon script n'est qu'une aide pour le hack et même si les choses sont généralement expliquées durant l'exécution des fonctionnalités cela ne dispense pas de comprendre se que l'on fait, par exemple il y a la FAQ qui est un bon point de départ et qui contient pas mal d'informations et de liens vers différents tutoriels. Il y a aussi la documentation du script qui pourra parfois vous aiguiller sur les choses à faire ou sur les éléments contenus dans la préparation d'une SD, n'hésitez pas à la consulter et même à regarder les crédits qui peuvent contenir des infos intéressantes.

Pour voir les évolutions de mon script, vous pouvez vous rendre sur cette page pour le changelog du script et sur cette page pour le changelogs des packs de CFW/homebrews/modules/overlays/cheats.

La version base peut être téléchargée ici; pour la version complète vous pouvez cliquer ici mais je recommande plutôt de passer par la version base et d'utiliser le gestionnaire de mises à jour intégré au script pour ajouter ou mettre à jour les différentes fonctionnalités.

Histoire de clarifier le comportement du gestionnaire de mises à jour du script je vais réexpliquer son fonctionnement, la demande intervenant en premier lieu juste après le premier message du script met seulement à jour les éléments de base du script comme les menus ou les programmes indispensables au bon fonctionnement de l'ensemble, ensuite chaque fonctionnalité est gérée indépendamment et si la mise à jour est acceptée sur une fonctionnalité, les éléments de base seront aussi mis à jour. Bon maintenant pour expliquer en pratique on va imaginer que vous utilisiez le script pour lancer des payloads et préparer une SD se qui représente deux fonctionnalités différentes, pour avoir la dernière mise à jour des deux fonctionnalités il faudra lancer chacune d'entre elle et accepter à chaque fois la mise à jour. Après il y a aussi une fonction qui permet via le menu "A propos", de mettre à jour l'ensemble des fonctionnalités du script en même temps mais ceci peut donc prendre beaucoup de temps car il y aura beaucoup de choses que le script devra télécharger.

J'ai choisi cette façon de fonctionner car mon script est devenu assez volumineux avec le temps et tout mettre à jour en même temps n'est, selon moi, pas la bonne stratégie car même vérifier que tel ou tel élément est à jour est déjà très long alors qu'avec ma méthode déjà on ne récupère que se dont on a besoin et quand on en a besoin (bon plus parfois car par exemple dans la préparation d'une SD tous les packs sont récupérés alors que tout ne servira probablement pas mais bon encore une fois à un moment il faut faire des choix) et surtout les vérifications et mises à jour sont bien plus courtes et donc celles-ci peuvent être faites plus souvent tout en étant moyennement gênantes dans l'utilisation.

En cas de bugs, de propositions de fonctionnalités ou d’améliorations veuillez s'il vous plaît passer par le Github du projet ou bien par le sujet dédié à mon script sur le forum, de cette façon je peux traiter bien plus rapidement les informations/demandes.

Enfin, vous avez cette page pour voir les nombreux crédits pour les outils utilisés dans mon script à un moment ou à un autre, comme d'habitude remercions tout ce beau monde pour leurs travaux, leurs participation au projet d'une manière ou d'une autre et également un grand merci aux quelques donateurs.

Annonce pour ceux qui prépare leur SD avec mon script, maintenant les sig_patches ne sont plus disponibles dans celui-ci et la configuration de Hekate ou de FastCFW-switch n'intègre plus les configurations avec les sig_patches. N'oubliez pas que le répertoire "sd_user" à la racine du script permet de forcer la copie d'éléments sur la SD, il suffit de reproduire l'arborescence de se que vous souhaitez forcer à copier dans ce répertoire et cela sera reproduit sur la SD après la copie des autres éléments se qui vous permet de garder les choses que vous souhaitez (fichiers de configurations, licence SXOS, sig_patches, etc...) ainsi que de continuer à mettre à jour les éléments avec le script.