Alt-F4 n°37 - Suite du cours accéléré sur les circuits logiques  28-05-2021

Écrit par pocarski, édité par stringweasel, Nanogamer7, Conor_, Therenas, Firerazer,
traduit par bev, Firerazer

Sommaire

En cette 37ième semaine de parution de Alt-F4, nous présentons notre 37ième parution ! Quelle surprise ! À l’intérieur, notre contributeur de longue durée pocarski est de retour avec des explications encore plus accessibles sur comment vous pouvez améliorer et optimiser votre base avec seulement quelques circuits logiques !

Réseaux logiques 2 : Logistique augmentée pocarski

Il y a quelques semaines, j’ai écrit un article sur l’utilisation des circuits logiques pour améliorer des constructions précises. Cette fois-ci, nous allons nous pencher sur les façons d’appliquer cet outil de manière plus générale, pour rendre toute votre usine plus efficace. Nous examinerons les pièges de la conception traditionnelle, nous trouverons des moyens de les résoudre et nous mettrons en œuvre ces solutions en utilisant les réseaux logiques. Ces améliorations peuvent être apportées aussi bien aux robots qu’aux trains, et les circuits sont si simples qu’ils ne nécessitent pratiquement pas de comparateurs. C’est parti !

Robots : Interface réseau à réseau

Nous avons tous connu ce problème : vous créez davantage de demandes de robots, et soudain tous les robots de l’extrémité de votre base décident que c’est une bonne idée de parcourir des milliers de tuiles à travers des zones sans roboport. Dans le meilleur des cas, cela provoquera une légère frustration en raison de la ressemblance frappante avec les services de livraison dans la vie réelle, et dans le pire des cas, les robots se feront sans cesse détruire par des déchiqueteurs, ou feront demi-tour en cours de route pour aller se charger dans les roboports qu’ils viennent de quitter, vous laissant sans la moindre ressource. Cela se produit lorsque votre réseau logistique a un angle concave, créant une énorme zone dépourvue de logistique, que les stupides robots à trajectoire directe chercheront immédiatement à traverser.

La majorité des robots du réseau sont bloqués dans les limbes de la portée de leur batterie.
Les robots de cette base n’ont pas assez de batterie pour traverser la concavité, donc ils font demi-tour à mi-chemin.

Donc, pour éviter cela, une règle a été écrite : “Tu ne créeras pas de réseaux logistiques concaves”. Ça semble simple, non ? Il suffit que votre base soit un rectangle massif de roboports, et il n’y aura tout simplement pas de coins à traverser. C’est une solution valable, mais elle impose des contraintes très importantes à votre expansion, puisque vous serez obligé d’étendre le rectangle pour couvrir tous les domaines que vous venez d’acquérir. Cela entraîne des situations où votre base réelle n’occupe qu’une infime partie de la zone couverte par votre réseau logistique.

Une base avec une “tige” maladroite qui gonfle le rectangle logistique.
Étendre le réseau logistique de cette base à un rectangle qui englobe cette longue tige en bas signifierait beaucoup d’extermination de déchiqueteurs.

Une bien meilleure façon d’aborder ce problème est de séparer vos réseaux. En gros, au lieu de créer un énorme rectangle, vous créez une série de petits rectangles non connectés, que vous pouvez ensuite arranger pour couvrir la forme que vous voulez. De cette façon, chaque réseau est toujours convexe, ce qui signifie que les robots ne quitteront jamais la couverture des roboports. C’est une bonne solution, mais comment faire pour que les objets traversent les espaces entre les réseaux ? C’est là que la logique entre en jeu.

Construisons deux réseaux avec un espace d’une tuile entre eux, et appelons-les réseau A et réseau B. Les objets traverseront cet espace en utilisant un bras haute capacité placé entre un coffre de demande et un coffre d’approvisionnement actif. Pour chaque objet que nous voulons déplacer de A vers B, nous devons configurer les coffres de demande de A avec la quantité d’objets que nous souhaitons transférer. Nous pouvons transférer des objets de B vers A de la même manière.

Bien que nous puissions concevoir des méthodes complexes pour déterminer la quantité exacte de ce qui doit aller où, nous nous en tiendrons à une solution simple qui fonctionne suffisamment bien pour la plupart des cas : maintenir les deux réseaux à une quantité égale d’objets. Pour ce faire, nous allons déterminer la moitié de la différence entre les contenus des réseaux pour chaque objet, et forcer le réseau avec le plus de cet objet à en envoyer autant au réseau avec le moins de cet objet. Voici un diagramme pourri décrivant cette idée :

Diagramme de l’idée

Nous connectons un roboport du réseau A à une paire de calculateurs, l’un multipliant par 1, et l’autre multipliant par -1. Cela nous donnera une valeur positive et une valeur négative pour chaque objet du réseau. Nous faisons de même pour le réseau B.

Réseaux de négation

Nous connectons ensuite la valeur négative d’un réseau à la valeur positive de l’autre. Cela nous donne la différence entre leurs contenus. Nous divisons ensuite cette valeur par 2 et la transmettons aux coffres de demande. Il est important que les coffres du côté avec plus d’objets aient une valeur positive, sinon le système fera exactement le contraire de ce que nous voulons. Il est également important d’arrondir la valeur à la taille de la cargaison de votre robot, sinon il risque de faire des allers-retours incessants en essayant de corriger une différence de deux objets en en déplaçant quatre à la fois.

Calcul de la moitié de la différence

Vu qu’avec un bras dans chaque sens, c’est un peu lent, nous pouvons en rajouter. Si nous ajoutons aveuglément plus de coffres, alors la demande de chaque coffre sera la moitié de la différence, ce qui signifie que la demande réelle sera plusieurs fois supérieure à ce qu’elle devrait être. Il faut diviser la différence en entrée par le nombre de coffres, et ajouter le reste à l’un des coffres. Une fois encore, il est primordial d’arrondir à la taille de la cargaison du robot. Cet arrondi signifie que les réseaux ne vont pas devenir strictement égaux, mais c’est un sacrifice nécessaire.

Demandeurs multiples

Ce circuit va maintenant faire de son mieux pour maintenir le contenu des réseaux au même niveau, avec une erreur de quelques objets. Les robots feront un peu d’aller-retour, car il y a un délai entre les objets retirés d’un réseau et ajoutés à l’autre, ce qui signifie qu’il y a une légère sur-correction au début. Avec plus de deux réseaux, ça ne change pas grand-chose. Comme chaque paire de réseaux essaie d’égaliser le nombre d’objets, tous les objets se répartissent progressivement de manière plus ou moins égale dans l’ensemble du système.

Ce circuit est infiniment réglable et personnalisable. Vous pouvez ajouter un facteur de pondération pour que le contenu du réseau soit dans un rapport spécifique, ou vous pouvez ajouter des conditions pour savoir quand appliquer la pondération et à quels objets, et même tout ce que vous pouvez imaginer. À mon avis, c’est une caractéristique encore plus importante que la simplicité.

Trains : Équivalent LTN, sans le mod

Passons des robots aux trains. Les trains sont très puissants, mais les trains sont aussi très stupides. Dans un système complexe avec de nombreuses gares portant le même nom, vous êtes pratiquement obligé d’utiliser la logique car sinon, les trains continueront à se diriger vers les mêmes gares, les encombrant et délaissant les autres. La méthode classique pour contrôler le trajet des trains consiste à désactiver les gares qui n’en ont pas besoin, ce qui oblige les trains à se diriger ailleurs. Il s’agit toutefois d’une méthode très rudimentaire et inefficace, qui pose de multiples problèmes : les trains qui changent de trajet à l’intérieur des carrefours peuvent provoquer des blocages, une seule gare activée génère une avalanche de trains, et les trains supplémentaires de cette avalanche créent un trafic inutile. Il existe également des systèmes logiques, tels que Haphollas’s Vanilla Train Network, qui atténuent certains de ces problèmes, mais pas tous.

La façon la plus connue d’éviter tout ce chaos est d’utiliser des mods. L’un des mods les plus populaires et les plus influents pour Factorio est LTN, ou “Logistic Train Network”. Il implante en fait le cerveau d’un robot logistique dans vos trains, et donne à vos gares la fonctionnalité de coffres d’approvisionnement et de demandes. Vous n’avez qu’à régler les besoins de chaque gare et les trains s’occupent eux-mêmes du reste. Inutile de dire que le mod permet des améliorations colossales en termes d’efficacité. On pourrait s’attendre à ce qu’un changement aussi fondamental du système soit presque impossible à recréer avec de la logique, et on aurait raison. Il est cependant extrêmement facile de créer une version beaucoup plus simple, bien qu’un peu moins efficace, de LTN en utilisant des circuits logiques.

Aujourd’hui, je vous présente le système “Demande et routage de trains par limite”, ou DRTL. Il s’agit d’un ensemble de circuits très basiques que plusieurs personnes ont inventé indépendamment, en utilisant les limites de trains qui ont été introduites dans la version 1.1, comme des indicateurs de demande de trains. La simplification majeure est que, contrairement au LTN proprement dit, dans le système DRTL, presque chaque train ou gare est dédié à une seule ressource. La logique est simple : pour chaque gare fournisseuse, calculez le nombre de “chargements de train” que vous avez en stock, et réglez-le comme votre limite de trains. Pour chaque gare demandeuse, faites de même avec la différence entre la demande et le contenu. Chaque train circule alors entre le fournisseur et le demandeur avec les conditions “Wagon plein” et “Wagon vide”.

Une gare fournisseuse extrêmement simple
Dans cet exemple, les plaques de fer entreposées à une gare fournisseuse sont divisées par 16 000, car c’est le nombre de plaques de fer qui peuvent être stockées dans quatre wagons.

DRTL résout tous les problèmes de la solution classique de désactivation des gares. Les trains ne provoqueront jamais de blocages en changeant de trajet à l’intérieur des carrefours, car contrairement à la désactivation d’une gare, la modification de sa limite de trains ne force pas le déroutage. Un nombre excessif de trains ne sera jamais envoyé dans une gare, puisque seuls ceux qui sont autorisés par la limite de trains pourront partir. Pas de surcharge de trains signifie moins de trafic, des débits plus élevés et moins de trains nécessaires, ce qui signifie également de meilleures performances de jeu.

Cependant, rien n’est aussi simple qu’il n’y paraît. Par exemple, si un train décharge à un demandeur, mais qu’aucun fournisseur n’est prêt, il reste là, privant le demandeur de débit. Cela signifie que nous avons besoin d’un dépôt central, afin que les trains aient toujours un endroit où aller pour libérer la gare de demande. Le dépôt peut être aussi simple que possible : juste un groupe de gares avec une limite de trains constante à 1, et quelques bras de ravitaillement. Les trains vont maintenant aussi du demandeur au fournisseur, en s’arrêtant au dépôt pour un court moment. Certains trains peuvent également s’arrêter dans le dépôt après avoir quitté le fournisseur, par exemple si le fournisseur est très éloigné.

Un exemple de dépôt
Un exemple de dépôt pouvant accueillir jusqu’à 100 trains dans un format compatible avec un canevas.

Mais attendez, il y a plus ! La zone d’attente dans les gares n’est pas illimitée, et si trop de trains sont demandés en même temps, ils peuvent commencer à faire la queue sur des voies où il ne devrait rien y avoir en attente. Pour résoudre ce problème, nous ajoutons deux comparateurs. Ceux-ci vérifient si le nombre de trains demandés est supérieur à une certaine constante. Si ce n’est pas le cas, la demande est transmise directement. Si elle l’est, la constante est émise à la place. Leurs sorties sont additionnées, simplement parce que la constante et la limite de trains utilisent des signaux différents, et qu’il nous faut un signal unique. Cette somme est ensuite envoyée à la gare comme limite de trains.

Limiteur de limite de trains

Ce circuit, tout comme le premier circuit de cet article, est personnalisable. Par exemple, vous pouvez faire en sorte que les demandeurs déterminent et règlent automatiquement leurs propres demandes, ou vous pouvez avoir quelque chose de complètement indépendant qui contrôle leurs demandes. Vous pouvez même changer la quantité d’objets chargés dans le train. En gros, toutes les constantes que le système utilise peuvent être transformées en valeurs dynamiques, contrôlées les unes par les autres, par un circuit indépendant ou même manuellement. Vous pouvez également modifier les horaires et les conditions des trains, par exemple en faisant en sorte que les gares relancent les trains dès que leurs demandes sont satisfaites, ou en permettant à un train de gérer plus d’une ressource.

Conclusion

Les circuits présentés ici sont conçus à la fois comme des produits finis utilisables et comme des bases pour vos propres projets de circuits. Je dirais qu’ils sont similaires à des figurines non peintes : vous pouvez encore en tirer beaucoup dans la forme où vous les avez reçues, mais vous avez des possibilités illimitées dès que vous faites preuve de créativité et d’habileté. Il n’y a intentionnellement pas de plans dans cet article, car son but n’est pas seulement de vous donner des circuits soignés, mais aussi de vous aider à mieux les comprendre. Bonne chance pour le câblage !

Contribuer

Comme toujours, nous attendons vos contributions pour les Alt-F4, que cela soit par la soumission d’un article ou en aidant pour les traductions. Si vous avez quelque chose d’intéressant en tête que vous souhaitez partager avec la communauté, vous êtes au bon endroit. Si vous n’êtes pas sûr, nous serons heureux de vous aider en discutant structure, contenu et idées. Donc si vous voulez vous impliquer dans les Alt-F4, rejoignez-le Discord pour ne rien rater !