TchouVous allez tellement tester qu'une fois votre partie lancée vous serez rassasiés du jeu ! :p

Du tout, parce que le multi-joueur, c'est une tout autre philosophie pour concevoir la base. C'est pour ça que je fais quelques teste, afin de voir dans quelle mesure ça va "différer" du jeu solo Et j'espère que Marcant sera des nôtres, parce que même si le jeu est "différent", ce sera "localement la même chose" pour ceux qui ne veulent pas s'embêter avec le passage à l'échelle (par exemple, le fait de construire une petite base spécialisée dans un type de production, ça reste la même chose qu'en solo, mais après, il faut quand même faire en sorte que ça soit utilisable par d'autre, et je regarde comment faire pour que ça soit super facile d'interfacer ça avec d'autres bases )

Bon, j'ai testé la "smelting station" avec LTN. Pour rappel, l'idée est d'amener au même endroit du minerai de fer et de cuivre, et de faire du dispatch à partir de là. Ce n'est pas très concluant Dans mon layout de base, j'ai une station "dépôt" qui demande du minerai de fer ou de cuivre en fonction de la quantité de plaques du même type disponible dans la station de sortie. Entre les deux, y a une pléthore de fours électriques avec des diffuseurs (pour accélérer le traitement et diminuer la conso électrique). Pour la station de sortie, j'ai des coffres de part et d'autres avec des bras articulés pour charger le train.

Je comptais lire depuis LTN la demande à l'origine du train présent en station, mais ça ne marche pas, car LTN considère qu'un même provider peut satisfaire plusieurs requests différents, du coup, j'ai des requêtes avec à la fois du cuivre et du fer, et donc le train se charge des deux et ça mixe un peu tout. Je suis sûr qu'on peut s'en sortir avec le réseau logistique, mais ça devient complexe, donc j'ai finalement opté pour deux stations de sortie différentes, une pour les plaques de fer et l'autre pour les plaques de cuivre.

Avec cet autre layout, ça ne marche pas trop mal, mais on perd un peu l'intérêt d'avoir une "smelting station" sachant qu'il faut de toute façon distinguer les deux outputs (et idéalement, il faudrait distinguer les deux inputs, puisque les minerais se stackent par 50 alors que les plaques se stackent par 100 !). Du coup, l'intérêt d'avoir une "smelting station" pour deux types de composants perd un peu son intérêt, puisqu'on est pratiquement obligé de tout dédoubler (à part les fours, mais le gain est faible si on est en flux tendu !). Le seul avantage, c'est qu'en combinant les fours pour les deux types de ressources, on peut en placer beaucoup plus (i.e. s'il faut 40 fours pour le fer et 20 pour le cuivre, on en place 60 ensemble) et que les diffuseurs sont d'autant plus intéressants qu'il y a de fours à proximité (ce qu'on ne pourrait pas atteindre "optimalement" en ayant 2 séries de fours distinctes). Pas sûr que le gain justifie réellement la complexité

[Edit: je tâcherai de mettre l'un ou l'autre screenshot d'ici peu]

Merci pour cette étude complète du système^^

Bon, ça marche pas du tout J'ai du ajouter des bras filtrants pour sortir du coffre les minerais correspondant à la demande la plus "prioritaire" de plaques. Ca demande beaucoup d'effort pour pas grand chose finalement, je pense qu'il vaut mieux faire deux centres de "smelting" distincts pour ne pas se prendre la tête

Pendant ce temps, j'ai commencé les silos à fusées, avec une production de satellites en parallèle (deux silos, 3 satellites max pour dire d'en avoir un d'avance). La production a du mal à suivre, je sens que je vais être rapidement en pénurie de fer et de cuivre, et je regrette déjà d'avoir fait ce "test" dans ma partie, car je vais devoir dédoubler tout le système pour que ça tienne ^^

Ce site propose de charger un fichier midi, et output un blueprint permettant de le jouer avec les speakers du jeu :
miditorio.com/

Je suppose que ça reprend le principe illustré ici :https://www.youtube.com/watch?v=Q1fszKmpwZM

Je tiens juste à remarquer que tu as ignoré un jeu que je présentait récemment ici sous l'argument "beurk, c'est moche". J'dis ça, j'dis rien...

edit : et évidemment, le bouton d'enregistrement était le "Troller". Tu as mis une IA alimentée au blockchain ou quoi ? :D

Je ne vois pas de quoi tu parles Et oui, y a une AI pour décider du bouton, et les données sont transmises aux USA, the gafam-way of doing things!!


Sinon, en cherchant pour Factorio pourquoi je ne pouvais pas mettre de modules de productivité dans les diffuseurs, je découvre que (1) seul 50% de l'effet du module est diffusé, et (2) les diffuseurs consomment une blinde. Du coup, je doute que mon layout de fours électriques à base de diffuseurs soit très intéressant en pratique. Comme quoi, ça valait la peine de tester avant

Bon, j'ai remplacé ma base secondaire de "cuisson" par deux bases distinctes, une pour le cuivre et une pour le fer, car ce n'était pas tenable avec deux silos à fusée. Là, ça va

J'en ai "profité" pour délocaliser la production de circuits verts, que j'ai doublé par la même occasion. La prochaine étape est de délocaliser la fonte d'acier, afin de gagner un peu de place dans la base principale, et de pouvoir agrandir mon bus (notamment le plastique que je ne produis pas en assez grande quantité, et les circuits rouges qui manquent quand les deux silos sont actifs + la recherche).

Pour ajouter un peu de challenge, j'ai ré-activé l'expansion des bases ennemies. Ca m'a forcé à faire un "train d'artilleries", avec plusieurs outposts où il s'arrête, équipé d'une belle ligne de tourelles lasers. Ce n'est pas suffisant malheureusement, j'aurai du ajouter dans mon blueprint un roboport et de quoi réparer automatiquement ces bases, mais ça viendra

Vu que les outposts n'étaient pas suffisants pour se défendre contre les vagues ennemies (notamment suite aux tirs d'artillerie), je n'ai pas eu d'autres choix que de faire le bourrin et de mettre des roboports partout sur la carte afin de couvrir automatiquement les outposts en terme de réparation et de remplacement des pièces détruites.

C'est "pratique" dans le sens où je ne dois plus me soucier des attaques, mais en même temps pas très pratique quand on veut construire quelque chose de neuf, car la plupart du temps, les robots vont aller chercher le matériel dans la base principale plutôt que de le prendre dans l'inventaire, ce qui signifie un looooong temps de trajet pour ces petites créatures

Ce que j'en tire comme leçon, c'est que c'est utile d'avoir des roboports dans les outposts, mais qu'il vaut mieux "isoler" ces roboports du circuit principal (= ne pas les relier), et sans doute faire un train automatique qui dispatche des robots de construction, des outils de réparation, des murs et tourelles en fonction de la demande. C'est ma "prochaine étape" dans la partie : essayer de faire une sorte de "requester universel" et le dispatcher qui va avec, en utilisant LTN. L'idée, c'est de connecter un émetteur de constante sur un roboport, et de le brancher sur la station requester. L'émetteur de constante permettra de préciser ce qu'il doit y avoir en stock dans le réseau logistique du roboport, et si quelque chose manque, un train avec cette demande est automatiquement demandé sur la station requester. Dans la base, on fait l'inverse : un émetteur de constante qui indique ce qui est théoriquement disponible (pour ne pas rendre l'ensemble des ressources dispo, et faire en sorte que cette station provider soit utilisée en cas de requête), puis de brancher des coffres requesters sur la station, comme ça quand le train entre pour se charger, les coffres requesters émettent la demande pour le réseau logistique, les robots apportent ce qu'il faut, et ça remplit le train.

Plus facile à dire qu'à faire, mais bon, à ce stade de ma partie (j'ai envoyé une 50aine de fusées/satellites, et je boucle les recherches infinies), autant chipoter sur des détails En parallèle, j'améliore la production de sciences (je suis à environ 90 sciences par minute maintenant).

Et en attendant le début d'une réunion, je me suis amusé avec quelques tests de circuits. Je vois souvent de "gigantesques bases" avec des outposts tous reliés par un même fil vert (ou rouge, ou les deux, peu importe). C'est pratique pour transmettre de l'info de l'un à l'autre, mais je me suis demandé comment on pourrait être "plus malin" et faire en sorte que chaque base puisse communiquer sur son propre canal de communication, puisque de base, seul le canal rouge et le canal vert existent.

Je ne sais pas si c'est efficace ou pas, mais vu que chaque fil est mis à jour "plein de fois par seconde", je suis parti dans l'idée de faire un multiplexage temporel. L'idée est donc d'alterner, à chaque "tick", le contenu du canal afin de ne laisser passer que la communication correspondant au "sous-canal" du tick en cours.

C'est finalement assez simple à implémenter (du moins, la base). Grosso-modo, j'utilise la valeur numérique du signal "info" pour définir le sous-canal courant (par ex, si "info" vaut 1, alors le sous-canal est 1, si "info" vaut 2, le sous-canal est 2, etc.). Ensuite, les "émetteurs" vont fonctionner comme suit : l'émetteur commence à lire le sous-canal courant. Si c'est celui pour lequel il est configuré (via un comparateur de signal), alors il output un "V". Ce V, ainsi que tous les signaux de l'outpost, sont en entrée d'un autre comparateur. SI ce comparateur reçoit un "V", il output tout ce qu'il reçoit en entrée (la raison pour laquelle il faut deux comparateurs est pour éviter de retransmettre le n° de canal en retour, sinon ça bloquerait le système). Du coté des récepteurs, c'est encore plus simple : il suffit d'un seul comparateur qui regarde si le sous-canal est celui pour lequel il est configuré.

C'est basique, et ça marche pas trop mal, mais il faut encore ajouter deux choses :
- Une horloge, afin de pouvoir cycler sur les sous-canaux très rapidement, de sorte à minimiser la latence. Ca doit pas être trop dur avec un calculateur qui fait un "modulo" sur le numéro de canal, et un autre calculateur qui se contente de faire du +1 sur le signal "info" (= numéro du sous-canal). J'ai commencé à tester, et ça switche à une vitesse folle
- Un système de "cellule mémoire", afin de conserver en mémoire les signaux reçus sur un sous-canal dès qu'ils sont lus, de sorte à émettre un signal continu en permanence au delà du récepteur. Ca doit pas bien être compliqué à faire, sans doute avec un RS-latch.

Avec ça, il suffirait de "numéroter" les outposts pour pouvoir faire de la communication bi-directionnelle intelligente. Je testerai

Dès que j'ai un prototype, je poste le screenshot

Et dire qu'à la base ce n'est qu'un jeu parmi tant d'autre ^^