Un énorme pack préconfiguré, bien que je ne l'utilise pas il reste intéressent et utile pour de nombreux utilisateur, merci a NightWolf et Shadow256 pour l'investissement dans la scène switch
- LS forums
- → Affichage d'un profil : Aime: bulle
Statistiques de la communauté
- Groupe Members
- Messages 0
- Visites sur le profil 5 520
- Titre Nouveau / peu actif
- Âge Âge inconnu
- Anniversaire Anniversaire inconnu
-
Sexe
Homme
Outils utilisateur
#1160356 [Switch] Switch_AIO_LS_pack 1.0.4 disponible
Posté par Linkynimes - 29 juin 2022 - 06:50
#1141830 [Switch] Ultimate-Switch-Hack-Script 4.3.163 disponible
Posté par Linkynimes - 03 septembre 2021 - 07:13
- bulle aime ceci
#1138652 [Switch] Nintendo sort le firmware 12.1.0
Posté par Linkynimes - 06 juillet 2021 - 08:46
Ben genial une mise a jour
Bon ne vous precipitez pas, la derniere en date, ben elle etait bugée... Donc attendez les retours.
Quand a ceux qui ont fait la mise a jour (a cuse du chien, du chat, des poissons, ou des enfants), ben la regle, c'est pas de console connectée a internet, ca evite cela. Et sans eux, le forum serait moins drole
Courage a nos devs qui se decarcassent aussi, et surtout
Même connecté a internet, normalement exosphere.ini (incognito) et les hosts (dns.mitn) sont la pour bloquer / filtrer les serveurs de Nintendo pour empêcher les majs ^^
- bulle aime ceci
#1116695 [Switch] Switch Army Knife (SAK) v0.7.6 disponible
Posté par eliboa - 27 octobre 2020 - 19:56
Alors bon impossible de savoir ce que contient ce programme car il est closed source.
Je recommande à tous ceux qui comptent l'utiliser de d'abord lire ça : https://github.com/dezem/SAK/issues/7
Les antivirus n'aiment pas ce programme et bien que l'auteur indique qu'il s'agit d'un faux positif, certains utilisateurs rapportent un virus/adware et vu qu'on a pas le code source, difficile de savoir qui dit vrai.
Donc ATTENTION, utiliser ce programme sans sandbox est à vos risques et périls.
Enfin, vu que le programme utilise 4NXCI, NSC Builder et hactool (qui ont fait leur preuves), et dans le doute, je vous recommande d'utiliser directement ces programmes (ou passer par le script de shadow).
#1112644 [Switch] SX OS Beta 3.0.5 disponible
Posté par DOCKY99 - 18 septembre 2020 - 07:35
@calo01
peux tu suprimer /sxos/titles/00FF0012656180FF/cach
et le fichiers /sxos/titles/00FF0012656180FF/SXAUTOLOADER.txt
puis relancer SXOS 3.0.5 beta a froid .
et dit moi s'il scan bien les jeux (dans SXAUTOLOADER.txt ).
Si c'est le cas alors SX AUTOLOADER 1.40 est 100% fonctionnel sur SXOS 3.0.5 beta ....
#1107060 [Switch] Hekate CTCaer mod v5.3.1 & Nyx v0.9.3 disponibles
Posté par Sun_Storm - 20 juillet 2020 - 07:44
Bonjour est ce que les sigpatch son inclus car j'ai fait la mise a jour par erreur en 10.1.0 et j'arrive pas lancer les jeux
Cette fameuse mise à jour par erreur, un vrai fléau
- bulle et Linkynimes aiment ceci
#1105806 [Switch] La mise à jour firmware officielle 10.1.0 disponible
Posté par issam77 - 14 juillet 2020 - 14:06
- bulle, Grunchimera, Batman23 et 1 autre aiment ceci
#1105729 [Switch] La mise à jour firmware officielle 10.1.0 disponible
Posté par Charpy - 14 juillet 2020 - 08:15
- bulle et crazycrazy aiment ceci
#989150 Shadow256 Ultimate Switch Hack Script
Posté par shadow256 - 14 mai 2018 - 19:23
Bonjour,
Ceci est un ensemble de script batch permettant de faire beaucoup de choses liées au hack de la Switch. Pour la liste des fonctionnalités du script, veuillez consulter ]le readme du Github ou la documentation du script. Le projet possède également une page sur Gbatemp.
Ce script ne couvre pas les méthodes de passage en mode RCM de la Switch, regardez sur cette page pour savoir comment, entre autre, passer en mode RCM.
Pour passer de SXOS à Atmosphere regardez ce sujet.
Pour préparer une carte SD contenant Linux (méthode obsolète aujourd'hui), regardez ce sujet qui vous indiquera la marche à suivre.
Pour le reste des questions, regardez la FAQ, je pense que vous y trouverez l'essentiel.
ATTENTION: Il semblerait que parfois, l'antivirus puisse poser problème lors de la mise en place d'une carte SD (peut-être aussi pour d'autres fonctionnalités du coup) donc surveillez bien celui-ci et désactivez-le au besoin durant l'exécution des scripts.
Vous pouvez télécharger la dernière version du projet sur Github via ce lien pour la version base (je recommande cette façon de faire) ou en utilisant ce lien pour la dernière version complète via les dernières sources (celle-ci n'inclus pas les sig_patches, il faudra mettre à jour avec le gestionnaire de mises à jour intégrées les fonctions ayant besoin de ceux-ci).
Pour consulter le changelog général, veuillez consulter cette page du projet Github et pour le changelog des packs, veuillez consulter cette page du projet Github.
Si vous appréciez mon travail, vous pouvez également me faire une petite donation en suivant ce lien pour faire une donation par carte bancaire ou ce lien pour faire une donnation en crypto-monnaies. Vous pouvez aussi faire une donation aux auteurs des projets initiaux comme Atmosphere par exemple, je vous invite à lire la section "Histoires de développeur" ci-dessous pour comprendre un peu mieux le temps passé sur les projets et pourquoi, même si on ne le fait pas pour gagner de l'argent à la base, ceci peut aider à la motivation de continuer. A l'origine je ne souhaitais pas formuler ce genre de proposition car je ne légitimais pas mon travail puisque se sont des scripts qui s'appuient en grande partie sur le travail d'autres personnes mais voilà, finalement je pense en fait aussi faire un travail à part entière et donc proposer ceci aux utilisateurs permet déjà de rappeler que ceci peut aussi se faire, sans aucune obligation bien sûr car l'ensemble de mon travail est et restera de l'open-sources, il est clairement hors de question que je change cela.
Histoires de développeur (écrite le 17 juin 2019):
J'écris cette petite partie un peu atypique histoire de montrer un peu que même sur un projet comme mon script, qui est un tout petit projet au regard de projets comme Atmosphere par exemple, et bien de petites choses en apparence peuvent prendre beaucoup de temps au final. Ceci n'est pas fait pour me plaindre, juste je prends un peu de temps pour relater des choses que les utilisateurs ignorent souvent et dont je pense qu'il est intéressant qu'on leur en parle un peu, nous les développeurs, chose que l'on ne fait au final que très rarement.
1) Les tests et contrôles d'erreurs, bienvenue en enfer!
Clairement, c'est une des choses qui prend le plus de temps, je dirais un bon gros tiers du développement, voir même 40%. Tester le comportement d'une application est fastidieux car déjà il faut tester les cas d'une utilisation normal mais aussi les cas d'une utilisation moins normale et parfois pendant ces tests il faut revoir complètement certaines choses car des bugs trop importants peuvent apparaître mais voilà, quand on change une fonctionnalité et bien il faut refaire l'ensemble des tests de celle-ci mais aussi de tout se qui y est lié et selon les choses testés ça peut vraiment prendre beaucoup de temps.
De plus, dans le cas d'un programme comme mon script qui s'appuie sur beaucoup d'éléments extérieurs, les tests sont parfois à refaire en partie ou totalement lors des mises à jour des éléments, par exemple lorsqu'Atmosphere a intégré Sept à son démarrage, j'ai eu pas mal de bugs car la version d'Atmosphere que je compilais moi-même ne fonctionnait plus pour les firmwares 7.X.X et supérieur car je ne possédais pas les clés nécessaires pour recompiler Atmosphere de manière fonctionnelle pour ces firmwares. Pour moi qui étais encore en firmware 6.1.0 à l'époque (je n'avais aucun intérêt à mettre à jour ma console et comme je n'en ai qu'une seule et que même si elle me sert comme console de test pour le développement elle est avant tout ma console que j'utilise tous les jours de manière plus conventionnelle), tout fonctionnait bien mais pour ceux qui avaient mis à jour c'était autre chose et identifier clairement le problème m'a pris un peu de temps.
Et des tests, j'en fait et j'en ferait encore, par exemple je ne compte plus le nombre de tests que j'ai pu faire sur la préparation d'une SD et des fonctions qui y sont directement liées, là déjà je pense qu'on peut comptabiliser une ou deux dizaines d'heures. Pareil sur les tests de la Nand Toolbox, là forcément comme les dumps ou copies peuvent prendre du temps les heures de tests grimpent très vite, même si souvent on trouve des subterfuges pour tenter de raccourcir un peu tout cela.
Voilà pourquoi, quand on rapporte un bug, il est important d'être précis sur les manipulations effectuées ainsi que sur les choses qui pourraient en dépendre, ça permet de localiser beaucoup plus facilement le bug et donc de pouvoir le corriger plus rapidement, c'est souvent beaucoup de temps de gagné pour tous le monde. Et clairement, comme je le dis souvent je n'ai pas le temps de tout tester en profondeur donc s'il vous plaît, en cas de bugs, rapportez-le, c'est vraiment le minimum et ça aide énormément.
2) Se tenir informé des évolutions et s'adapter à celles-ci, pas toujours si simple!
Souvent, lors de la mise à jour d'un élément, le fonctionnement reste le même, on met juste à jour l'outil ou l'élément souhaité. Par contre parfois, on a des changements plus radicaux qui peuvent obliger à revoir de petits détails, voir même parfois changer toute une organisation et sur la scène Switch qui est une scène très jeune et aussi très active, l'adaptation n'est pas toujours aisée à réaliser.
Pour illustrer cela je vais prendre pour exemple les modules qui, en plus d'avoir changé de méthode d'intégration aux différents CFWs, doivent être configurés de manière différente selon le CFW. Au départ, les modules étaient des fichiers ".kip" que l'on chargeait au démarrage du CFW en les mettant dans un dossier particulier ou encore en les paramétrant dans un fichier de configuration (Hekate par exemple). Et puis paf, voilà que tout bascule, les modules deviennent des dossiers nommés d'une manière très spécifique, contenant le module qui est lui aussi à nommé d'une façon spécifique avec d'autres éventuels éléments de configurations autour, en plus selon le CFW il ne faut pas faire la même chose pour que cela fonctionne (la configuration d'un module ne se fait pas de la même façon dans le dossier "titles" d'Atmosphere et dans le dossier "titles" de ReiNX). Et voilà comment, quasiment tout se que l'on a fait au départ doit être totalement réécrit tout en prenant en compte que l'utilisateur aura peut-être utilisé une ancienne version du script donc il faut en plus nettoyer au maximum les résidus des anciennes méthodes, sans pour autant trop interférer dans des réglages qu'aurait pu faire l'utilisateur extérieurement. Lectures, compréhension, réflexion, analyse, et adaptation, pas facile de concilier le tout car en plus il vaut mieux ne pas trop forcer l'utilisateur à tout reconfigurer depuis le départ, sauf si cela est vraiment nécessaire ou trop compliquer à mettre en place autrement.
Et parfois même c'est nos propres volontés d'évolutions du travail qui saborde se que l'on a fait, le meilleurs exemple dans le cas de mon script est la préparation d'une SD que j'ai dû totalement réorganiser et en grande partie réécrire lorsque j'ai décidé d'intégrer des gestions de profiles. Là, il a fallut que je repense intégralement quelque chose qui fonctionnait très bien en l'état mais qui n'aurait pas pu évoluer vers les fonctions que je souhaitais lui ajouter sans une réécriture complète. Et donc bien évidemment il faut repasser par la phase de tests qui s'ajoute à tout cela. Je me souviens qu'intégrer la gestion de profile m'a pris pas mal de temps avant d'être au point, je pense que plusieurs dizaines d'heures ont été nécessaires avant que le tout fonctionne de manière correct et que se qui fonctionnait avant refonctionne normalement.
Et des choses à faire de ce genre il m'en reste à l'heure actuelle, par exemple je dois réécrire intégralement l'installation de Linux qui est obsolète depuis bien trop longtemps mais ici tout est à revoir depuis le début, même pas moyen de réutiliser le travail précédent et en plus comme il y a des opérations très sensibles à faire durant le procéder cela va me prendre probablement encore quelques heures, au moins une bonne vingtaine.
Voilà, suivre les évolutions peut être très difficile, en plus de bien se renseigner il faut parfois recommencer un travail depuis le début tout en gérant les possibilités de configurations qu'aurait pu faire l'utilisateur en dehors du script, un travail intéressant mais pas toujours facile.
3) L'automatisation
Parfois, l'automatisation de tâches reste assez évidentes à mettre en place mais parfois cela est plutôt complexe alors que pourtant la chose semble assez simple.
Un exemple qui peut être assez parlant serait l'exemple de la réunification d'un dump de la rawnand. Au départ, c'est une simple ligne de commande qui permet de faire cela mais l'automatiser devient tout de suite plus complexe. En effet, déjà il existe plusieurs solutions pour dumper la nand de manière splittée, on a Hekate et SX OS donc il faut prendre en compte les différences entre les deux méthodes (ici la différence est le nom des fichiers, une contrainte certes pas très importante en apparence et qui pourtant n'est pas si simple à gérer, d'autant plus en batch). Après on demande à l'utilisateur dans quel dossier se trouve les fichiers, bon là c'est facile. Normalement, avec ces deux infos on est bon et on se dit qu'on peut lancer le traitement de la commande et pourtant, comme on est dans une automatisation il faut contrôler un maximum de choses avant de lancer la commande salvatrice, soumise en plus ici à des conditions liées au nom de fichiers. En premier lieu donc, on doit vérifier que le dump que l'on souhaite réunir est bien complet en vérifiant les fichiers présents. Ensuite, comme c'est un traitement de fichier volumineux, il faut savoir si l'endroit vers lequel on souhaite copier le fichier dispose d'un espace disque suffisant et là, le batch ne simplifie pas la chose puisqu'on ne peut gérer des nombres aussi grand. On lance la commande de réunification puis, une fois terminé, il faut encore vérifier que le fichier est bien de la taille attendu. Voilà, tout çà pour une pauvre commande.
Si je parle précisément de ce script c'est parce qu'à la base, j'avais développé cela en me disant que ça allait être un truc hyper facile qui ne me prendrait qu'une heure grand maximum à faire et pourtant, je pense qu'au final j'ai dû y passer 4 à 5 heures, peut-être même plus car c'était pas si simple d'automatiser le tout et le langage batch ne m'a vraiment pas simplifier les choses sur ce coup.
4) La documentation et les changelogs, souvent la négligence du développeur
Documenter un minimum le travail effectué et surtout informer des nouvelles choses n'est pas toujours facile ni passionnant, d'autant qu'il faut simplifier en partie pour que l'utilisateur comprennent concrètement se qui a changé d'une version à une autre. C'est un travail de rédaction qui n'est pas très intéressant à faire mais il est indispensable. Souvent, le problème dans ce genre de chose est qu'on développe un truc et puis tien, au milieu du processus on se rend compte d'un petit bug ailleurs donc on le corrige puis on se remet à développer et puis on a une nouveauté qui sort donc on l'intègre ... mais voilà, souvent on néglige de faire le changelog au fur et à mesure et à la fin on se demande parfois qu'est-ce qu'on a réellement modifié et puis difficile de faire un changelog à l'avance car au final on ne sait pas si se que l'on souhaite faire va fonctionner ou non avant de l'avoir fait donc le faire de manière anticipé n'est pas toujours judicieux.
Et je ne parle même pas des crédits ou autres petits détails qui sont un témoignage de respect en vers les différents contributeurs ayant permis de construire le projet mais dans un script comme celui-ci il y a tellement de programme différents que créditer tous le monde est pour ainsi dire impossible, même si j'essaie de faire au mieux il y a clairement beaucoup d'oubliés (ou plutôt de non nommés), surtout pour les homebrews/modules car il y en a beaucoup trop. Un jour je ferais des crédits intégrant au moins un lien vers chacun des projets mais clairement pour l'instant je préfère me concentrer sur d'autres choses mais je suis le seul à blâmer, faire cela correctement depuis le départ m'aurait épargner ce genre d'inconvenance vis à vis de la scène.
5) Le manque de retours
Une chose qui aide beaucoup est les retours des utilisateurs, pourtant bien peu en font et ceci est bien dommage. C'est un constat que je fais depuis mon premier script, mon Ultimate Wii U Hack Script, les utilisateurs ont tendances à vraiment très très peu s’investir, même un tout petit peu dans les projet et clairement c'est le plus décourageant. Heureusement, certains utilisateurs manifestent de l'intérêt aux projets et proposent ponctuellement des améliorations, indiquent les bugs en faisant des tests, me font une critique constructive, proposent de me faire une donation ou même me remercie mais les contributions restent vraiment marginales, la scène francophone est plutôt triste à ce niveau là. Et là je parle de mon travail mais pour beaucoup de projets il en va de même, la scène francophone manque de reconnaissance et l'utilisateur s’investit bien peu même quand on le lui demande.
Pour une comparaison avec le même genre de travail sur la scène Wii U, le sujet de WiiVC Injector Script, qui a d'ailleurs donné naissance à mon Ultimate Wii U Hack Script, avait de nombreuses participations, critiques, retours de bugs et propositions d'améliorations sur son sujet de Gbatemp alors que pourtant c'était, à la base, un script batch ressemblant fortement aux miens qui se sont largement inspirés de son fonctionnement d'ailleurs. Voilà, c'est un constat un peu triste mais bon après ça ne m'empêche pas de continuer à développer car avant de servir aux utilisateurs mon travail me sert à moi en premier lieu, au final si ça peut servir à quelques autres personnes c'est tant mieux mais avec un peu plus d’interactions avec les utilisateurs se serait plus sympa.
6) La mise à jour automatique
Voici une des fonctions qui fut très difficile à développer en batch car il fallait à la fois gérer cela en ayant pas à imposer un gros téléchargement à l'utilisateur pour intégrer cette seule fonction et à la fois quelque chose de modulaire pour ne pas imposer le téléchargement de choses trop inutiles à l'utilisateur. Vu les fréquentes mises à jour de mon projet il était également exclu de faire une mise à jour automatique récupérant tout le projet à chaque fois.
Donc voilà, avec tout ces éléments de réflexion il fallait créer quelque chose qui soit à la fois souple et à la fois précis en imposant le moins de contraintes possibles à l'utilisateur, tant au niveau du temps que la vérification et la mise à jour des éléments qu'au niveau des demandes d'actions. Pas facile de concilier et d'équilibrer au mieux le tout, cette fonction fut l'une des plus compliquer à théoriser puis à développer.
Bref, une fonction qui fut bien difficile à mettre en place, là je ne sais pas combien d'heures cela m'a réellement pris mais c'est assez important, d'autant que l'ajout d'une autre grosse nouveauté détaillée ci-après est venu perturber tout son fonctionnement.
7) Le multi-langues
Alors là on entre dans un point qui, s'il n'a pas été très difficile à théoriser, a été très très long à mettre en place. De plus, l'ajout de cette nouveauté m'a obligé à réécrire en partie le script de mise à jour automatique car il fallait prendre en compte un paquet de choses supplémentaires et traiter des erreurs possibles. L'ajout du multi-langues dans un projet n'ayant pas été prévu pour cela à la base est un énorme travail, c'est une chose à savoir.
Du coup, en premier lieu, il a fallu mettre en place le support du multi-langues en réécrivant tous le script en français, c'était la phase essentiel, avoir une base fonctionnelle et compatible avec le multi-langues. Tous les scripts sans exception ont dû être réécrits et quelques fonctions ont dû être ajoutées pour que cela fonctionne, cela m'a pris déjà pas mal de temps, environ un mois de travail (je ne vais même pas compter en heures là) pour plus de 15000 lignes de code écrites ou réécrites.
Mais voilà, ensuite il faut se lancer dans la traduction dans une première langue, j'ai choisi l'anglais. Bon ceci prend bien évidemment beaucoup de temps vu la quantité de choses à traduire mais c'est la documentation qui fut plus problématique au final car il faut adapter certains liens pour coller à la langue en question, par exemple dans la documentation anglaise on ne peut mettre des liens redirigeant sur des sites en français. Cette traduction m'a pris environ un mois à faire (là pareil je ne compte pas en heures) et ceci fut très chronophage.
Une fois ces éléments mis en place il ne resta plus qu'à implémenter les configurations diverses, pour initialiser la langue ou pour passer de l'une à l'autre, au final ceci ne fut pas le plus difficile du travail même si la logique n'était pas si simple et la mise à jour automatique ayant encore dû être réécrite en partie pour prendre en compte certaines particularités du passage d'une langue à une autre.
Conclusion, une fonction assez simple à théoriser peut prendre beaucoup de temps à être développée, d'autant que derrière il faut en plus refaire les phases de tests. Il faut aussi penser que chaque nouvelle chose doit être écrite dans les différentes langues disponibles, certes les fonctions du projet mais aussi la documentation et les changelogs, ceci obligeant donc à une rigueur encore plus importante qu'avant au niveau de la gestion du projet.
Bien évidemment je ne parle pas de la conceptualisation, de l'algorithmique ou même réellement du développement pur qui prend la majorité du temps mais bon c'est le travail de développeur de faire cela et ça ne parlera vraiment pas aux utilisateurs, se qui est tout à fait normal. Pour info, depuis le début de ce projet, je pense que je cumule plusieurs centaines d'heures de travail sur celui-ci, il est rare que les développeurs mettent en avant ceci et pourtant c'est un fait, développer prend beaucoup de temps et l'utilisateur se doit d'en tenir compte et de le savoir, d'autant plus dans la scène de l'open-sources pour laquelle les seules rétributions (ou presque) sont la passion et le partage, se qui n'est ceci dit clairement pas négligeable, je dirais même essentiel. Et là je parle donc de mon expérience personnelle sur ce projet que je considère comme étant un tout petit projet à côté d'Atmosphere par exemple, là je n'ose même pas imaginer le nombre d'heures passées à développer, conceptualiser, tester... ça doit être des milliers d'heures.
Pour conclure et à ceux qui m'auront lu, merci à vous et n'oubliez pas de participer aux projets que vous utilisez régulièrement si vous le pouvez (d'une manière ou d'une autre, même un simple merci assortie d'un petit commentaire par exemple sur les choses que vous appréciez dans le projet fait toujours plaisir et motive les développeurs), c'est important car c'est dans le partage que l'on progresse tous, pas dans l'individualité.
Procédure d'installation:
- Télécharger la version base du script.
- Extraire le fichier téléchargé quelque part sur le PC mais pas sur la SD qui sera utilisée pour la Switch.
- Lancer le fichier "Ultimate Switch Hack Script.bat" Du dossier qui a été extrait.
- En général, il sera nécessaire de faire les mises à jour car la version base n'intègre que le minimum donc seul les menus principaux fonctionnent, chaque fonction s'installe et se met à jour indépendamment les unes des autres pour que l'utilisateur ne récupère que se qui lui servira.
- Pour avoir la dernière version intégrant la totalité du script d'un coup, il est possible de récupérer la version complète mais dans ce cas je recommande vivement de supprimer l'ancien dossier du script et d'extraire la nouvelle version en cas de mise à jour. Cependant, le mieux à faire reste d'utiliser les fonctions de mise à jour intégrées au script, une fonctionnalité dans la partie "A propos" permet même de tout télécharger/mettre à jour d'un seul coup.
Vous pourrez retrouver les crédits pour tous les outils utilisés sur cette page ou dans la documentation du script qui contient également un certains nombre d'informations utiles.
N'hésitez pas à me faire part de vos retours, à me notifier des bugs rencontrés ou à me suggérer des améliorations, cela sera grandement apprécié.
#1103121 [Switch] N'utilisez pas ChoiDuJour-NX sur les consoles équipées de puces...
Posté par mke2106 - 19 juin 2020 - 06:04
- czerwinski76, bulle, RomAnOCrY et 5 autres aiment ceci
#1103008 [Switch] Nintendo s'attaque aux poseurs de puces SX
Posté par shadow256 - 17 juin 2020 - 22:57
Faire du business sur du HACK c’est une honte que ce soit niveau software ou hardware.
Et çà c'est plussoyé près de dix fois quoi! Bah ouai, vous les utilisateurs vous voulez tout et ne jamais rien donner. Et les techniciens qui défendez votre business (à raison je précise) vous êtes pires selon moi, vous gagnez de l'argent en vous reposant sur des projets gratuit mais je ne pense pas que vous fassiez de donations à ces mêmes projets. Par exemple, combien d'entre vous utilisent TegraRCMGUI au moins une fois par jour et combien ont fait une donation à @eliboa, si c'est comme pour mon Ultimate-Switch-Hack-Script le ratio doit être tout tout tout tout petit. Alors chers utilisateurs, pensez donc à participer un peu plus à la scène à votre niveau en parlant des projets, en remontant les bugs, en faisant des propositions d'améliorations et même parfois en faisant une petite donations aux projets que vous utilisez (même un euro se sera toujours grandement apprécié croyez-moi), même si on fait nos projets par passion un peu de reconnaissance n'est pas négligeable et en plus ici vous avez quelques développeurs plutôt actifs sur la scène à qui vous pouvez vous adresser, soyez donc un peu acteurs vous aussi à votre niveau.
Là on voit bien dans les commentaires que payer le hack hardware est plutôt défendu et d'ailleurs je suis tout à fait d'accord, ceci dit qui a défendu la partie software? Vous savez combien ça prend de temps de développer et de maintenir un projet, temps que pour beaucoup d'entre nous nous prenons sur notre temps libre? Alors oui, à un moment il est normal de demander un peu de participations aux utilisateurs, putin arrêtez d'être égoïste quoi.
Et puis tant que j'y suis je vais aussi un peu parler de moi, selon vous combien de personnes ai-je dépanné et combien m'ont fait ou m'ont proposé de me faire une petite donation? Réponse, à peine 0,01% à mon avis. Combien parlent et mettent en avant mes projets? Bah là pareil, ils ne sont pas nombreux. Si chacune des personnes que j'ai aidé m'avais donné 1 euro la somme serait non négligeable pour moi et aurait été très négligeable pour chacun, alors évidemment que ça ne doit pas être le cas à chaque fois, pour tout et que c'est pas le but visé par l'aide apportée mais bon pour un exemple comme celui de ce sujet osez me dire que mon aide ne valais rien (toi d'ailleurs au passage tu m'as bien dégouté, dans le genre je prends et je ne donne rien t'es parfait, non mais t'as juste pas honte quoi; bon au moins t'as quand même dit merci c'est toujours çà).
PS: Je ne généralise pas et certains utilisateurs/techniciens ne sont pas comme cela mais bon c'est très loin d'être la majorité quand même, d'ailleurs je remercie encore au passage ceux qui participent activement d'une manière ou d'une autre.
Bon après ce bon coup de gueule et pour parler un peu du sujet de la news quand même selon moi il n'est pas illégal de poser une puce permettant le hack (c'est pas du contournement de sécurité de la copie à la base car là je ne parles que de la puce et pas du reste), c'est se que l'on fait ensuite qui peut être problématique et sur ce point je rejoint totalement l'avis du magasin présenté comme exemple dans cette news. Si Nintendo gagne un procès du genre ça craindrait bien car après il y aurait juriste prudence sur le sujet et à mon avis c'est se qu'ils souhaitent, en plus c'est facile de s’attaquer au petit magasin qui n'ont de toutes façons pas les moyens de luter contre eux, toute la beauté de notre monde capitaliste consumériste quoi.
- bulle, Linkynimes et foxan aiment ceci
#1103017 [Switch] Nintendo s'attaque aux poseurs de puces SX
Posté par fabriceunko - 18 juin 2020 - 06:02
Faire du business sur du HACK c’est une honte que ce soit niveau software ou hardware.
Tu n'a pas du connaître la bonne époque de l'amiga et atari... du magasine TILT ou hebdogiciel..
à cette époque tu avais des centaines d'annonces de gens qui vendaient des disquettes avec des copies pour 10fr.
Le business à toujours existé. c'est simplement la contre attaque qui est plus efficace. Tant que la copie ou l'utilisation reste plus ou moins difficile pour le commun.... rien ne ce passe.. par contre desque cela devient très facile .. Ail le coup de bâton tombe.
- bulle aime ceci
#1103032 [Switch] Nintendo s'attaque aux poseurs de puces SX
Posté par shadow256 - 18 juin 2020 - 11:25
Si tu démilitarise une arme a feu pour un client, tu n'est pas responsable si la personne tue quelqu'un par la suite avec, voilà ce que je retiens de ça défense.
Je pense que ton interprétation n'est pas la bonne, à aucun moment il n'est mentionner l'exemple de l'arme à feu et à juste titre d'ailleurs, une arme à feu ne sert qu'à tuer/blesser contrairement à un couteau qui peut servir à bien d'autre choses qui sont d'ailleurs plutôt positives en général, c'est pas pour rien qu'un couteau est un des outils de survie les plus utiles. Encore une fois moi je suis plutôt d'accord sur la défense de la boutique, c'est pas l'outil le problème mais plutôt se qu'en fera la personne ensuite; après bon soyons clair la majorité des gens qui se feront installer cette puce pirateront leurs jeux mais la justice ne doit pas être fondée sur la présomption de culpabilité.
- bulle aime ceci
- LS forums
- → Affichage d'un profil : Aime: bulle
- Privacy Policy