Oui ça n'est pas si complexe si tu as fait des circuits et a un background de base pour comprendre les algorithmes simples. Have fun!

Je vois plutôt deux soucis autre que la logique, en fait.

Le premier, c'est de savoir quand faire appel à un train (c'est-à-dire à quel moment le requester va faire sa requête), sachant qu'il faut le temps que le train fasse le trajet, se remplisse et revienne. Le faire trop vite signifie que le train va être utilisé souvent (et qu'il faudra plus de trains pour tout couvrir), et le faire trop lentement signifie un risque de pénurie.

Le second est en lien avec le fait que le train peut se remplir de plusieurs matériaux différents (par ex, une fois du minerai de fer, et l'autre fois du cuivre). Puisque le train quitte automatiquement la gare où il dépose son contenu au bout de 2 secondes d'inactivité (par ex quand les coffres sont pleins) ou au bout de 120 secondes (le timeout par défaut), il pourrait éventuellement repartir avec des minerais, qu'il mélangera à d'autres lors d'un futur trajet. Je vois sur les forums que la solution est d'avoir une sorte de "nettoyage" lorsqu'il attend au dépôt, mais (1) cela signifie qu'il y aura des coffres "fourre-tout" qu'il conviendra de vider un jour ou l'autre; (2) il faut s'assurer que le train se vide complètement dans ces coffres avant de repartir pour une autre demande, et (3) par précaution, cela signifie qu'il faut des bras filtrants dans les stations requesters, histoire de ne pas mélanger les objets dans les coffres/tapis si ça se produit. Je vais voir dans quelle mesure on peut faire cela facilement (ce n'est pas "compliqué", mais je n'ai pas envie d'avoir à faire ce genre de configuration à chaque station, et je n'avais pas envie de passer par un blueprint non plus ).

Pour moi il y a deux bien meilleures solutions au problème :
- Le mod a une option pour forcer le train à partir quand la requête est satisfaite sans attendre les deux secondes (ça s'appelle "finish loading" dans les options du mod. Le soucis est que ça ne fonctionne pas si tu transportes plusieurs matériaux différents avec un même train.
- Ma solution préférée est de gérer ça avec un circuit une chouille plus complexe au moment du chargement. En lisant le contenu du train avec un fil tu peux connaitre le niveau de chargement, et en lisant le contenu de la lampe LTN tu peux connaitre la requête. Un petit combinateur pour inverser l'un des signaux, tu branches le tout sur tes inserteurs qui doivent charger le train... et tu leur set un filtre qui dit de ne charger que tant qu'il y a besoin de charger. Et voilà!

C'est fun LTN!

J'avais pensé à la première solution, mais ça nécessite d'utiliser une configuration "pas par défaut", ce que je voulais éviter autant que possible

Pour la seconde solution, oui, tout à fait : on peut faire en sorte que le train ne charge que ce qui a été demandé (en terme de quantité). Mais dans ce cas, l'optimisation doit se faire au niveau du requester : il faut bien estimer "ce qu'il manque" et ajouter un petit surplus à cette demande afin d'anticiper ce qui va manquer concrètement quand le train va arriver. Cela dit, c'est un moindre mal

Mais du coup, oui, il faut commencer à bien configurer chaque requester/provider, et je suis sûr que c'est error-prone, d'où la nécessité de passer par un blueprint

Enfin, on verra. Je vais commencer mes tests dès que possible et voir comment gérer ça relativement efficacement. j'aime vraiment bien l'idée, surtout dans un contexte multi-joueur, où on pourra chacun partir un peu dans son "coin" une fois que le minimum "central" sera réalisé, et en fonction de ce dont on a besoin "localement", on peut émettre ces demandes, et attendre qu'un train finisse par passer pour les satisfaire (ça va permettre de "spreader" la traditionnelle base centralisée dans plein de petites bases "unitaires").

Je ne vois pas trop ce que tu entends pas bien estimer ce qu'il manque et gérer des surplus. Je pense que tant que ta requête à un requester ne dépasses pas le stockage que tu possèdes pour ce produit (dépendant de la taille des coffres, ainsi que de la taille d'une stack pour ce produit - attention à ce que tous les coffres soient bien connectés pour que leur contenu soit pris en compte), tu n'auras jamais de soucis.

Joues un peu plus avec et tu verras, c'est assez logique tout ça. Les filter inserter au déchargement restent intéressants pour sécuriser le tout, et comme tu auras des alertes dans la console en cas de train qui retourne au dépot non vide tu auras ce qu'il faut pour débuguer.

Ce que je veux dire, c'est que LTN va "lancer" un train vers un provider dès qu'un requester va lancer sa requête et qu'un provider est dispo pour l'assurer. Supposons que dans ta station "requester", tu consommes 1000 objets par minute. Supposons que cette station fasse une requête pour 10k objets, et supposons qu'il y ait un provider qui puisse satisfaire ça. Donc LTN va prendre un train et le balancer vers le provider avec une cible de 10k objets. Sauf que le temps que le train fasse la route, se remplisse, et arrive au requester, il peut s'en passer du temps. Disons 2 minutes, pour être gentil. Ca veut dire que ton requester qui va recevoir 10k en aurait bien voulu 12k volontiers

Après, je ne connais pas les rouages de LTN. Il est possible que la "requête" continue à s'incrémenter tant que le train n'est pas dans la station provider (supposons que sur le délai de 2 minutes ci-dessus, il y ait 30 secondes qui servent à envoyer le train vers le provider, alors la requête à l'arrivée du train sera d'environ 10.5k au lieu de 10k, mais ça signifie encore un "gap" de 1.5k quand le train arrivera pour décharger sa marchandise à la station requester).

Bon, ok, je cherche un peu la petite bête, mais sachant que le threshold par défaut est de 1000 (et non 10k ou même 15k, la taille classique d'un train), ça représente proportionnellement une jolie petite fraction

Ha oui dans ce sens là! Oui tu as tout à fait raison sur le fait que la gestion du buffer doit bien refléter ta consommation par minute. Tu penses mégabase en fait, j'avoue ne pas m'en être servi à cette échelle encore...

Une fois que le train part la requête ne change plus. Par contre dès que la livraison est terminée une autre requête peut partir. En fait LTN a beau permettre la logistique avec les trains, il faut quand même bien la doser. Note que il y a une notion de sous réseaux à base de bitmask, c'est important si tu veux choisir un dépot de train particulier qui va servir la requête. Sans cela c'est comme pour les bots, il prend le premier qu'il trouve et pas forcément le plus proche!

Tu utilises LTN en dehors d'une megabase ? Ca sert à "quoi" dans ce cas-là ? Je veux dire : dans une partie normale, où on ne voit "pas trop large", à priori un train par base secondaire est suffisant (et vu le coût d'un train, il n'y a pas vraiment de raison de se priver d'en fabriquer ^^).

Je pensais vraiment que tu t'en servais dans un contexte où, par exemple, tu avais délocalisé la production des différentes fioles, et que LTN te permettait justement de faire circuler les trains plus intelligemment entre les différents dépôts (voire même d'acheminer plus intelligemment les bons objets aux bons endroits, ce qui est quand même difficile à faire à grande échelle sans ce mod ).

La terminologie doit venir d'une question d'échelle^^ J'ai utilisé LTN pour faire une grosse base de 240spm, mais pas pour faire une mégabase de 1k spm ou plus^^

Ha et je m'en suis servi sur une base avec le mod seablock, que je n'avais pas terminée.

Ok

Je viens de procéder à quelques tests rapides. La station demandeuse émet "contenu des coffres - 38K4" (total possible dans les coffres), avec un requester threshold fixé (localement) à 8K (taille d'un train). La station émettrice envoie un signal "contenu des coffres", et est configuré à "max 1 train" (comme j'ai plusieurs "sources", ça permet de les faire alterner quand la demande dépasse la capacité de 1 de la gare émettrice).

Ca a l'air de marcher (j'ai juste converti mon circuit de pierre, et mes 2 de fers). On verra ce que ça donnera quand j'aurai ajouté le cuivre (2 trains actuellement pour 2 sources, comme le fer), le charbon (un train et une source) ainsi que l'uranium (1 train et une source). Cela me permettra aussi de voir le nombre de trains réellement nécessaires (pour l'instant, il y en a 7, et je pense que 4 ou 5 seraient sans doute suffisant).

Je vais aussi voir (sur les forums, probablement) s'il est possible de faire du "round-robin" sur les stations émettrices, afin de les vider plus ou moins au même rythme.