Accès aux fichiers textes avec Unity.

[Winuty]

Ha bha oui et si j'ai rien d'inscrit sur les lignes précédentes je vais finalement écrire sur la ligne 1 vue qu'il ne va pas me faire tout seul des zones vide pour sauter à la ligne 4.

Donc je devrais d'abord initialiser toutes les lignes utilisées à 0 en début de projet pour par la suite écrire/lire que sur la ligne voulue.

Dans ma node j'aurai une boîte pour saisir le numéro de la ligne à récupérer.

Pour optimiser tout ça oui je pourrais faire appel qu'une seule fois une node GET pour relier toutes les autres.

Par contre j'ai remarqué qu'en Visual Scripting si tu places trop de ligne pour relier tes nodes bha l'affichage du visual ram au bout d'un moment. C'est pour cette raison que j'essaie de me servire le plus souvent les boîtes sur les nodes au lieu de les relier. C'est sûrement un problème qui va être corrigé dans les futures version.
Du coup j'ai splitté mes Visuals Scripting sur des GameObjects vide enfant pour en avoir un par fonction au lieu de tout surcharger dans le même. Quand l'un est fini, j'active le suivant.

[boubouk50]

Le VS a ces faiblesses/inconvénients comparé au code brut.
Je ne fais pas de VS donc je ne connais pas les limitations définies par les boites. Ici, ce que je vois, c'est que tout est séparé, mais doit agir au même endroit.
S'il t'est possible de créer un gameObject qui contient les fonctions de chargement / sauvegarde / création de fichier et que chacun des scripts le référence pour "donner des ordres" (ex : modifie la ligne 5 (index) avec la valeur 13 (value), sauvegarde, etc.), alors ce serait plus efficace.
Le problème avec la séparation est que si tu fais des tâches sans que les autres soient au courant, alors tu risques d'écraser des données.
Sinon, il faut que tu recharges toutes les données localement pour les modifier et les réinjecter. Tu perds énormément en rapidité d'exécution puisque tu dois continuellement lire et écrire dans un fichier (ce qui veut dire ouvrir et fermer le fichier).

De ce que je vois, la boite de l'objetCible pourrait avoir un index, une valeur et une référence à un manager. Quand la valeur est modifiée, elle appelle une fonction de Set de valeur au manager avec l'index et la valeur. Le manager s'occupe de modifier son tableau et de sauvegarder.
Le manager contient l'information de nom de dossier et de fichier. Il s'occupe de ne gérer que ça.
Tu peux donc avoir plusieurs managers, un par fichier. Tous les objetCibles auront la même boite qui référencera le manager dont il se sert.

[Winuty]

Pour la limite de VS pour le moment je la voie pas (mise à part l'affichage de l'éditeur qui ram si le VS est trop surcharger). Mais c'est uniquement dans l'interface d'édition, pour charger les VS dans mon APP j'ai aucun ralentissement.
Je peut si besoin créer une node avec le bout de code que j'ai besoin.

[boubouk50]

Et donc, y'a plus qu'à ?

[Winuty]

Oui je vais faire des tests.
Si j'arrive à quelque de chose de bien je vous partage ça.
Merci pour ton aide.