Oxygen Not Included: Rimworld par les papas de Don't Starve

[Yank31]

gg

Débit à 1kg/s ou 10kg/s ?

[bobe]

10kg/s, le temps, c'est de l'argent
Les premières lampées d'hydrogène liquide qui viennent d'apparaître. L'or rose

[Yank31]

Oui c'est émouvant les premières fois. Et ça sent un peu la fin... ou les trucs idiots à base de 148,13388 wild arbor tree par secondes par cycle. Ahem.


Et donc tes pipes marchent dans du C02 à 386°C, et à 10kg/s. Ca c'est étonnant quand même, enfin ça marche chez moi aussi mais je suis dans le vacuum de l'espaaaace, par contre je vois bcp de youtubeurs qui galèrent avec ça. Après les vidéos datent peut-être un pneu

[Yank31]

J'ai commencé à router un peu la flotte vers la production d'hydrogène, du coup je reviens rapido là dessus :

Elle pompe bien 500g/s, mais comme tu as de l'o2 par intermittence si ça bouchonne à un moment tes 2 fois 500g pompé à la suite se compriment entre les "parenthèses" d'o2.

Hmm, je crois que je vois ce que tu veux dire, mais non ça filait tout droit là. Pas d'arrêt.

Le setup général c'est ça :




Et j'ai fait un gif (mon premier ) du truc :




Donc c'est pas lié au bouchonnage... !

[Pierce Inverarity]

J'allais dire "ah ouais, étonnant !" ...

Mais je crois que je comprends pas tout avec tes ponts/filtres, d'ailleurs y a un petit peu d'H qui ne part pas dans le bon conduit
Y a des chances que ça se joue aussi là dedans.

Bon de toute façon, ce qui compte pour calculer le débit de la pompe, c'est pas de prendre les quelques sections à 500g et + mais aussi ceux avec 0g

[Jeager]

Un electro qui tourne à plein régime c'est (théoriquement) 888g/s d'oxygène et 111g/s d'hydrogène, un duplicant normal (pas de perk diver's lungs) consomme 100g/s d'oxygène. Du coup 1 electro tient 8 dupes en gros.

La beauté du truc c'est que vu que ça sort aussi 111g/s d'hydrogène, tu peux y attacher un hydrogen generator (mange 100g/s d'hydrogène) et là ça devient, selon ton setup, self powered (d'où l'acronyme SPOM : self powered oxygen maker). En gros si tu as le matos, l'énergie ne devrait pas être un problème.

Oui je l'avais fait dans ma partie precedente le probleme c'est que niveau sensor c'etait pas trop ca apparament et je me retrouvais avec pleins d'hydrogene dans ma base (problme de valeur ?)

Pareil pour la chlorine, j'ai fait un chambre hermétique en bloquant l'entrée avec l'eau pour le slimelung mais j'ai l'impression que la chlorine disparait de la piece petit a petit (j'ai pourtant un gaz filter qui pompe et reinjecte seulement la chlorine dans la piece :/)

[bobe]

yank31 : ta pompe a pompé genre 100g d'oxygene et 400g d'hydrogene. Elle pousse en sortie les 100g d'oxygene, puis la seconde suivante, les 400g d'hydrogene de la précédente seconde + les 500g qu'elle vient de pomper.

J'allais dire "ah ouais, étonnant !" ...

Mais je crois que je comprends pas tout avec tes ponts/filtres, d'ailleurs y a un petit peu d'H qui ne part pas dans le bon conduit
Y a des chances que ça se joue aussi là dedans.

C'est un filtre mécanique. Tu créés une petite boucle avec une valve réglée par exemple sur 10g. Le seul gaz qui pourra passer par cette boucle sera celui qui peut fusionner avec ces paquets de 10g bloqués dans la mini-boucle.

https://forums.kleientertainment.com...l-pipe-filter/

/!\ Attention: ce topic est vieux et à cette époque, les couleurs des entrées et sorties étaient l'inverse d'aujourd'hui.

[Pierce Inverarity]

C'est un filtre mécanique. Tu créés une petite boucle avec une valve réglée par exemple sur 10g. Le seul gaz qui pourra passer par cette boucle sera celui qui peut fusionner avec ces paquets de 10g bloqués dans la mini-boucle.

https://forums.kleientertainment.com...l-pipe-filter/

/!\ Attention: ce topic est vieux et à cette époque, les couleurs des entrées et sorties étaient l'inverse d'aujourd'hui.

ouais je connais, mais y a les entrées sur la deuxième ligne, qui me font buggé.

edit : AH MAIS OUI. c'est la valve ! (c'est bon)

[Yank31]

Bon de toute façon, ce qui compte pour calculer le débit de la pompe, c'est pas de prendre les quelques sections à 500g et + mais aussi ceux avec 0g

yank31 : ta pompe a pompé genre 100g d'oxygene et 400g d'hydrogene. Elle pousse en sortie les 100g d'oxygene, puis la seconde suivante, les 400g d'hydrogene de la précédente seconde + les 500g qu'elle vient de pomper.

Ptet que c'est ben ça, faudrait que je regarde les cases 2 par 2, si ça dépasse jamais 1000g effectivement on resterait conforme. Et je me demande là si les pompes ont une réserve perso (façon metal refinery ou sweeper), je suis pas sûr, ça pourrait expliquer qq trucs aussi.

Et oui filtres mécaniques compactés, j'aurais cillé aussi au vu du truc. Mais y'a les mêmes chiffres sur le screenshot de la page d'avant (avec rien d'autre qu'une pompe et sa pipe) (...).


Ceci dit, y'a effectivement un putaing de petit point rose qui s'échappe, ça arrive soit quand la pipe est bouchonnée (pas le cas ici) soit quand... ben on monte le truc à l'envers et je me rends compte que c'est que j'ai fait. Il faut mettre les circuits en counterflow pour éviter ça. Là ils tournent dans le même sens, derp.

[bobe]

oh là là, stop, n'en jetez plus



edit: première fusée à hydrogène envoyée. rdv dans 27.3 cycles (avec normalement 2t de niobium dans la soute )

[Yank31]

Ah ouais mais t'as construit hyper bas toi

Perso j'ai collé la limite. C'est marrant de regarder les bases des autres

T'as 2 fusées côte à côte dans le CO2 ? Ton scanner à côté du telescope, il est content avec les panneaux solaires en dessous (mais c'est celui des fusées non) ? Les sweepers, tu les refroidis comment (ou alors c'est wip?) ?

[bobe]

Ah ouais mais t'as construit hyper bas toi

Perso j'ai collé la limite. C'est marrant de regarder les bases des autres

Je préfère qu'ils aient pas trop de chemin à faire depuis la base. Et plus le silo est profond, plus tu récupères de gaz et de chaleur des fusées qui décollent. J'aime bien jouer avec ça ^^

T'as 2 fusées côte à côte dans le CO2 ? Ton scanner à côté du telescope, il est content avec les panneaux solaires en dessous (mais c'est celui des fusées non) ? Les sweepers, tu les refroidis comment (ou alors c'est wip?) ?

J'ai pris un screen d'ensemble pour que tu te rendes mieux compte



Le scanner à côté du téléscope est pour la fusée de droite et sa qualité de détection n'a pas d'importance.
Y a un scanner pour la fusée de gauche, en haut à gauche au-dessus du silo. Le côté gauche est pas encore bien aménagé.

je refroidis pas les sweepers, j'ai eu la flemme de poser des drywall et une évacuation de gaz (faut bien faire quelque chose de tout cette oxygène ). Je vais bientôt avoir un chargement de niobium, donc je vais les reconstruire avec ça, 2 cases plus bas (là où les drywall sont déjà installés) et ça règlera le problème.

Note le mini-biome pétrole merveilleusement placé en bas à proximité immédiate. La cheminée de vapeur froide en bas à gauche (aménagée à l'arrache pour l'instant). La cheminée d'hydrogène dont je te parlais et environ 70 cases à gauche.
Pour l'oxygène et l'hydrogène liquide, tu vois que j'ai construit l'unité de production au plus près du silo, le trajet aller/retour est vraiment court.

[Yank31]

Sympa comme tout, on dirait une base secrète de film

En regardant tout ça me vient une question bonux. Si tu mets des pompes pour récupérer la vapeur... wait, c'est débile, les pompes vont overheat (même thermium). Meh, la question aurait été : est-ce jamais rentable de pomper de la vapeur ? (en terme de watts donc).


Du coup je résiste pas , voici mon ciel :




Une approche différente. Loin d'être fini... à gauche ça marche bien et je pourrais ajouter de quoi récolter la regolith mais franchement je leak déjà ~3kj par cycle avec les panneaux solaires, pas besoin de puissance. Le truc qu'il faut que je rajoute à gauche, c'est une water clock pour les saisons de meteor shower (mettre les scanners sur off pendant les acalmies).

A droite c'est loin d'être fini et ça me plait pas trop en fait, mais l'agencement final va dépendre du "programme spatial", j'aimerais faire genre 3 / 4 vols réguliers avec cargo, reste plus qu'à regarder les chiffres (de refresh des ressources, de saisons de meteor shower, de conso... bref) pour voir si c'est jouable et si oui comment. Du coup les pads de lancement devraient (encore et encore) bouger, et j'aimerai déplacer l'automation aussi.

J'ai parlé des jours de 240 heures ?

[bobe]

Ah ouais, t'as pris tes aises quoi
Moi, je suis parti du principe que plus tu t'étales à la surface, plus t'auras de regolith à gérer. Du coup, je me suis fait tout petit

Le water clock dont vous parliez sur le forum klei, je pensais à un truc. Une smart batterie perd 400J par cycle. Y a peut-être un truc à creuser aussi de ce côté, mais je sais pas si y aurait la précision voulue avec le sliders

[Yank31]

Ouais ça c'est pas fait tout seul ni en une fois, la ligne de défense à gauche là, elle m'a pris 260 cycles. Je l'ai refaite 3 fois. La deuxième fois y'avait tout pour récolter... mais je trouvais ça beaucoup trop gadget et moche, là c'est simple mais très efficace.


C'est pas con du tout ton idée, ça tient combien 20Kj, donc 50 cycles (mais c'est ouf en fait), les saisons durent 34 cycles, donc ça couvre à l'aise. Le curseur va de 1 à 100, donc 1 = 200J (1/2 cycles), donc 2 par cycle ? On cherche à sortir un signal vert entre par exemple le cycle 4 et le cycle 14 (iron season), une batterie qui se décharge envoie... rouge au dessus du plafond, rouge en dessous du plafond, vert sous le seuil. Ca c'est un peu chiant.

Je pense que ça peut, peut-être le faire (ce serait génial, super idée) mais je vois pas trop comment goupiller les signaux là. Idéalement il faudrait un truc qui s'allume vert au cycle 4 et s'éteint au cycle 14. Je vois pas comment une seule batterie pourrait faire ça, mais deux, sûrement ?

On charge à fond toutes les batteries au cycle 0.
La batterie 1 a un seuil à (100 - 4x2) 92. Elle envoie vert au cycle 4. Merci
La batterie 2 a un seuil à (100 - 14x2) 72. Elle envoie vert au cycle 14 (elle reset un memory toggle mettons, du coup ça donne rouge). Merci

etc.

Mais c'est génial ton truc ?

Par contre il faut trouver un moyen de leur sucer le jus vitesse grand V à la fin -- ou plutôt de les remplir à fond, pour le reset. Ce que pourraient faire des coal generator, avec tout le charbon qui se balade à force...

- - - Mise à jour - - -

Putain je vais tester de ce pas !

[Yank31]

Après je me dis trois choses. Ca va chauffer, enfin faut gérer le refroidissement (bénin donc s'ignore sous terre mais chiant dans l'espace). Ca va prendre de la place, enfin 6 batteries + les generators (bon ca va, une chtouille de CO2, bon). Et surtout ça va peut-être se décaler un peu, enfin tout dépend de la vitesse du reset. Hmmm!

[bobe]

En regardant tout ça me vient une question bonux. Si tu mets des pompes pour récupérer la vapeur... wait, c'est débile, les pompes vont overheat (même thermium). Meh, la question aurait été : est-ce jamais rentable de pomper de la vapeur ? (en terme de watts donc).

Une turbine a besoin d'au moins 800g de vapeur (deux ports ouverts). Ça fait 240W/5*8 = 384W. Si je me fie à oni-db.com, ça devient positif si les 800g de vapeur sont à au moins 212.4°C.
Mais bon, c'est bourrin. La turbine est une pompe en soi. Autant la placer de manière à ce qu'elle pompe directement la vapeur concernée.

Sinon, je t'ai lancé sur un truc avec l'histoire de la batterie on dirait.

edit: par contre, plutôt charger les batteries avec un transfo 4kj depuis un autre réseau pour charger la batterie en 5s (enfin plus si y a plusieurs batteries; ou bien alimenter tout ça avec plusieurs transfo xD)
edit2: pour la durée du reset, si elle est constante. débrouille toi ensuite pour consommer une quantité donnée d'énergie pour compenser (genre une loupiotte pendant x secondes)

[Yank31]

Mais à la limite la vitesse du reset et peut-être pas si importante, genre on pourrait imaginer les gaver de watt (generators en roue libre) un peu avant le début du cycle 0 et tout couper avec une clock. Après je sais pas exactement comment fonctionnent les saisons, si elles correspondent au début de cycle ou pas.

Et, je pense aussi qu'une water clock est beaucoup plus simple en fait. Mais l'idée est très très bonne !

[Yank31]

Bon, hier soir j'ai installé la water clock de papa Saturnus (c'est très simple à monter en fait), j'ai mis 13 ports because I can et puis je l'ai laissé s'auto-calibrer. Parce qu'elle s'auto-calibre, suffit de brancher un scanner qui detecte les meteor shower.

Alors c'est un truc faut être patient, faut attendre que toutes les saisons passent (donc 34 cycles). Ce que je fais, en la surveillant.

Ceci dit y'avait un truc bizarre, enfin la logique de calibration m'échappe, en gros la machine attend une pause de 8 cycles (un rouge qui dure > 8 cycles) pour ensuite se lancer au premier vert (se lancer = RàZ). Sauf que y'a pas de pause de 8 cycles, dans les saisons. Et se remettre à zéro au premier vert... euh... enfin ça aussi c'est bizarre parce que du coup ça implique qu'il compte à partir de ce vert (début iron season) mais toutes ses valeurs sont réglées comme s'il partait de la période calme juste avant (donc 4 cycles plus tôt).

Bref, l'iron season arrive, ça... prend pas, je vais donc lui poser la question hier.

Et ce matin je vais chercher la réponse, je cherche partout, et... il a supprimé son topic ce con


Bon, mais n'empêche ça laisse la question en suspend. Question assez importante pour l'usage d'une horloge : comment qu'on sait où qu'on en est ? Je la règle sur quoi, iléoù Greenwhich ?

[bobe]

Ouais, j'ai cherché aussi son topic parce que je comprenais pas comment il primait le truc.

Bon, là j'ai creusé une autre idée. Matérialiser la séquence entre les saisons sans/avec météorites au travers de conduits et j'en suis là (fait à la truelle juste pour poser l'idée):



Les paquets d'eau symbolisent les cycles des périodes calmes et les paquets noirs symbolisent les cycles des périodes de chutes de météorites.
Le premier détecteur d'élement à droite détecterait où on en est à cet instant. Le second détecteur est positionné pour une fusée qui partirait à 10000km et reviendrait 2.7 cycles après avec le bonus de astronaute expert (edit: peu importe en fait, c'est bon aussi avec un trajet de 3 cycles).
L'horloge est réglée sur 0%/1%. On envoit une pulsation dans le système not/and/buffer pour activer le disjoncteur pendant une seconde et donc laisser passer un unique paquet.

Si on veut envoyer une fusée à 10000km, on branche son automatisation sur ce détecteur (celui de gauche), ce qui l'autorisera à partir seulement si elle revient pendant un cycle calme (ce qui serait le cas dans cet exemple).
Ajouter d'autres détecteurs d'élément le long du conduit en fonction de la durée des autres trajets.
Par contre, le système représente un cycle complet de 34 cycles, or les longs trajets peuvent durer plus longtemps que ça, donc il faudrait plutôt couvrir deux cycles complets d'activité des météorites (donc une boucle de 68 conduits +1 après le disjoncteur).

Et donc là, j'en suis à me demander comment primer le truc (savoir quand on est au début d'une saison particulière et activer le build).

edit: ah, je crois que j'ai compris, le but est de détecter la période la plus longue possible dans le cycle d'activité des météorites, à savoir la période des météorites de fer d'où le 8 cycles
edit2: +ne pas détecter plus de 2 cycles calmes après la dernière chute. Bon, c'est un peu plus compliqué tout ça et c'est juste pour primer une fois le bordel. Je sais pas si ça vaut le coup d'automatiser ça ^^
edit3: non bah une boucle de 34 + 2 (disjoncteur) suffirait. Le détecteur pour les trajets à 10000km serait le même que pour les trajets à 120000km, etc (si je dis pas de bétise) (oula, ça carbure sec là-haut )

[Yank31]

Voilà encore une autre excellente idée, je suis admiratif parce que perso quand j'y pensais à identifier les saisons, je me disais qu'il fallait compter, et je ne voyais pour ce faire que des amas de clock, memory toggle et and gates, l'horreur s'il faut arriver à 34. Je pense que ton truc peut tout à fait marcher, mais je veux pas trop m'y pencher là parce que, je crois qu'on est d'accord, le premier truc à régler c'est :

comment qu'on sait où qu'on en est ? Je la règle sur quoi, iléoù Greenwhich ?

Et donc là, j'en suis à me demander comment primer le truc (savoir quand on est au début d'une saison particulière et activer le build).

Voilà et donc je dirais que c'est littéralement primordial parce que si on a pas ça, peu importe la tronche du système derrière (water drip, water pipes, batteries, cycle d'une plante (???)), il servira à rien.


Et je vais y venir parce que j'ai la réponse je crois, mais avant ça sur l'intérêt de l'automatiser, c'est une bonne question ça. Je suppose que tu parlais d'automatiser la calibration, et je suppose que Saturnus voulait le faire pour livrer une machine "clef en main", par contre pour nous y'a pas vraiment d'intérêt je pense (et mon truc devrait... enfin c'est du semi auto). Par contre on pourrait étendre la question un poil plus loin parce que c'est pas inutile de se le demander aussi : à quoi bon faire du full auto pour les fusées ?

Fun et plaisir de l'automation mis à part, je me dis d'emblée que les seules fusées qui valent le coup d'être full auto sont les fusées à cargo (solide / liquide / bestioles), la science est maxée assez vite et on veut a priori pas les envoyer au même endroit. Bref, donc le cargo. Et qui dit cargo, dit... "réserve" des planètes, et donc replenish rate. Et là ça devient un poil frustrant, les "space destinations" comme ils les appellent sur le wiki se régénèrent assez lentement. Sur une période de 34 cycles, les destinations à 10.000 km gagnent +5,75 tonnes, celles à 30.000 un peu moins de 2 tonnes.

Ca veut dire que si j'envoie 1 fusée à 2 tonnes (le meilleur rapport conso/cargo), 3 fois durant les 34 cycles (aux 3 périodes calmes par exemple), à 10.000 km, je surconsomme 250kg par "mega cycle de 34". Donc ça va tenir qu'un temps. Et bref, idem pour 30.000 km (non pas idem, c'est de pire en pire, plus on s'éloigne, et plus le ratio durée de trajet/replenish rate devient pourri), ça tombe difficilement "bien".

Ce qui, d'une autre manière je trouve, force un peu la question : mais à quoi bon automatiser tout ce bordel.


Bon, mais si ces considérations remettent un peu en cause l'intérêt d'automatiser, elle relèvent aussi plutôt de la programmation, une chose à la fois, revenons au calendrier astral. Je viens de passer les 2 meilleures heures de ma vie à regarder mon ciel et ma barrière de porte, en x3, pendant ~38 cycles. J'ai noté les jours avec showers et ceux sans, ainsi que le métal qui tombait. Et là je crois bien que je l'ai, mon cycle astral. Note au passage, y'a eu deux faux positifs (le scanner shower envoi un bref signal vert, puis rapidement rouge, et y'a rien qui tombe). J'avais déjà vu ce comportement mais l'avais attribué à une anomalie dans mes fils. Clairement c'est pas ça, les deux sont arrivés 1 jour trop tard, un peu comme si le jeu se disait "Vazy, balance leur la sauce" et que genre 5 secondes plus tard il se disait "ah merde c'est plus la saison, abort, abort". Les deux faux positifs sont arrivés respectivement le 11eme jour de l'iron season, et le 6ème jour de la gold season, donc hors saison, et rien n'est tombé.

Ce qui d'une autre manière conforte mon calendrier, je pense que je l'ai. J'ai eu de la chance parce que l'iron season était bizarre (8 cycles), par contre la copper season était parfaite (chute le 1er et le 7ème cycle, boom), du coup j'ai pu poser une prédiction, et la gold season l'a respectée (en tout cas elle a pas débordé), et j'ai eu un faux positif le jour d'après, mais rien qui tombe.

BREF, du coup là si mon cycle de 34 jours est valable, ça va pas être trop compliqué de calibrer ma water clock en semi-auto (genre une clock qui ping le début du cycle, couplée en AND avec un signal interne qui déclenchent un reset).


Voilà, donc la force brute la fine observation triomphe. Je crois. J'espère. Et sinon pour une détection auto, je pensais utiliser le fait que seules les périodes de chute de la gold season sont inférieures à 100s. Mais bon, ce serait long à affiner, et bref, à quoi bon se faire chier pour ça alors qu'une petite heure ou deux devant les portes en x3, un bic dans la main, et voilà c'est plié ().


Edit : bon et maintenant que j'ai sorti tout ça de mon cerveau, oui je sais pas pour les durées de trajet > 34 cycles effectivement. J'ai maxé la science et pour le moment j'étais plus focalisé sur un programme "commercial" genre cargo quoi, entre 10 et 30k donc faibles durées. Pour exploiter à fond l'info sur les accalmies. Je crois pas que ma fusée d'explo ait encore dépassé les 100k.

Mais après, enfin... si c'est pour l'explo, donc un seul lancement (en manuel vu qu'il faut sélectionner la cible), ça s'anticipe je pense. Tout ce qu'on veut c'est qu'elle arrive en période calme, du coup il faut la lancer X cycles avant (la clock ne faisant que t'aider au calcul, en te donnant un calendrier). Si c'est pour du cargo, donc X/lancements par cycles longs ou quoi, là... je sais pas trop (ou plutôt j'ai pas envie d'y réflèche là !).

[bobe]

Voilà encore une autre excellente idée, je suis admiratif parce que perso quand j'y pensais à identifier les saisons, je me disais qu'il fallait compter, et je ne voyais pour ce faire que des amas de clock, memory toggle et and gates, l'horreur s'il faut arriver à 34. Je pense que ton truc peut tout à fait marcher

Pour être honnête, l'idée m'est venu de ce topic où le gars décrit un système de détection d'un cycle. Là, je me suis dit "hey, pourquoi pas appliquer ça aux météorites ?"
https://forums.kleientertainment.com...-period-timer/

Voilà et donc je dirais que c'est littéralement primordial parce que si on a pas ça, peu importe la tronche du système derrière (water drip, water pipes, batteries, cycle d'une plante (???)), il servira à rien.

Et je vais y venir parce que j'ai la réponse je crois, mais avant ça sur l'intérêt de l'automatiser, c'est une bonne question ça. Je suppose que tu parlais d'automatiser la calibration, et je suppose que Saturnus voulait le faire pour livrer une machine "clef en main", par contre pour nous y'a pas vraiment d'intérêt je pense (et mon truc devrait... enfin c'est du semi auto). Par contre on pourrait étendre la question un poil plus loin parce que c'est pas inutile de se le demander aussi : à quoi bon faire du full auto pour les fusées ?

Ouais, je suis encore en phase de réflexion sur ce problème.
Pour les fusées, ouais, pour le fun surtout. Je regarde décoller avec émerveillement chacune de mes fusées donc bon...

Fun et plaisir de l'automation mis à part, je me dis d'emblée que les seules fusées qui valent le coup d'être full auto sont les fusées à cargo (solide / liquide / bestioles), la science est maxée assez vite et on veut a priori pas les envoyer au même endroit. Bref, donc le cargo. Et qui dit cargo, dit... "réserve" des planètes, et donc replenish rate. Et là ça devient un poil frustrant, les "space destinations" comme ils les appellent sur le wiki se régénèrent assez lentement. Sur une période de 34 cycles, les destinations à 10.000 km gagnent +5,75 tonnes, celles à 30.000 un peu moins de 2 tonnes.

Ca veut dire que si j'envoie 1 fusée à 2 tonnes (le meilleur rapport conso), 3 fois sur les 34 cycles (aux 3 périodes calmes par exemple), à 10.000 km, je perd 250kg par "mega cycle de 34". Donc ça va tenir qu'un temps. Et bref, idem pour 30.000 km, ça tombe difficilement "bien".

Ce qui, d'une autre manière je trouve, force un peu la question : mais à quoi bon automatiser tout ce bordel.

Pas pigé. Si tu connais le taux de renouvellement des ressources, tu peux déduire la fréquence à laquelle il est rentable de renvoyer une fusée sur cette destination.

Voilà, donc la force brute la fine observation triomphe. Je crois. J'espère. Et sinon pour une détection auto, je pensais utiliser le fait que seules les périodes de chute de la gold season sont inférieures à 100s. Mais bon, ce serait long à affiner, et bref, à quoi bon se faire chier pour ça alors qu'une petite heure ou deux devant les portes en x3, un bic dans la main, et voilà c'est plié ().

ouais voilà. C'est pour ça que j'hésite à me lancer dans l'automatisation de cette partie. L'intérêt est assez réduit. Tu fais juste un circuit témoin qui passe au vert si des météorites sont tombées dans la journée (ça évite de rester scotcher sur la surface toute la journée). Tu prends note en fin de journée et tu réinitialises. Tu fais ça jusqu'à que tu as déterminé où tu en es du cycle d'activité des météorites.

Edit : bon et maintenant que j'ai sorti tout ça de mon cerveau, oui je sais pas pour les durées de trajet > 34 cycles effectivement. J'ai maxé la science et pour le moment j'étais plus focalisé sur un programme "commercial" genre cargo quoi, entre 10 et 30k donc faibles durées. Pour exploiter à fond l'info sur les accalmies. Je crois pas que ma fusée d'explo ait encore dépassé les 100k.

Mais après, enfin... si c'est pour l'explo, donc un seul lancement (en manuel vu qu'il faut sélectionner la cible), ça s'anticipe je pense. Tout ce qu'on veut c'est qu'elle arrive en période calme, du coup il faut la lancer X cycles avant (la clock ne faisant que t'aider au calcul, en te donnant un calendrier). Si c'est pour du cargo, donc X/lancements par cycles longs ou quoi, là... je sais pas trop (ou plutôt j'ai pas envie d'y réflèche là !).

j'ai affiné le build pour couvrir deux fois 34 cycles avec la même boucle. Le capteur pour les trajets à 10000 est aussi celui pour les trajets à 120000km. Celui pour les trajets à 20000 vaut aussi pour les trajets à 130000km, etc

La partie inférieure avec les bacs de liquide était pour créer la boucle et ne servent plus ensuite.



Là, les destinations à 10000, 20000, 40000, 50000 et 90000 sont au vert (ou 120000, 130000, 150000, 160000 et 200000)
edit: Là, le premier capteur pour la destination à 10000km est celui juste avant l'entrée du disjoncteur. Mais c'est qu'une convention en fait.
edit2: c'est encore plus con pour la semi-automatisation. Un petit circuit logique pour mémoriser si on a 3 cycles consécutifs sans chute de météorite. Si oui, on sait qu'on doit regarder le type de météorite de métal deux cycles plus tard et basta.

[Yank31]

Pas pigé. Si tu connais le taux de renouvellement des ressources, tu peux déduire la fréquence à laquelle il est rentable de renvoyer une fusée sur cette destination.

Oui, mais ensuite il faut la faire coïncider aux fenêtres d'accalmies (données par ta clock), sinon la clock n'a aucun intérêt. T'as 2 fréquences à juxtaposer, la fréquence optimale de décollage (par rapport au réserve d'un astre), et la fréquence donnée par le cycle douche / paix. Et ça tombe juuuuuste mal, pour les destinations à 10.000 km.


Pour les destinations plus lointaines c'est nettement pire dans le sens où elles régénèrent de plus en plus lentement. Autrement dit ta "fréquence optimale de décollage pour pas les épuiser" est de plus en plus longue. Bref au final ça veut dire que soit tu vises le système clos (cargo = regen) et tes fusées restent au sol très longtemps (probablement plus que 34 jours dès les 30.000 km - qui ne régénèrent même pas 2T en 34 jours donc). Soit tu lances à toutes les fenêtres et ensuite tu changes de cible (mais là du coup c'est du manuel).

Bref, ça se goupille mal, et plus on vise loin, pire c'est.

j'ai affiné le build pour couvrir deux fois 34 cycles avec la même boucle. Le capteur pour les trajets à 10000 est aussi celui pour les trajets à 120000km. Celui pour les trajets à 20000 vaut aussi pour les trajets à 130000km, etc

La partie inférieure avec les bacs de liquide était pour créer la boucle et ne servent plus ensuite.

https://steamuserimages-a.akamaihd.n...10717B119003A/

Là, les destinations à 10000, 20000, 40000, 50000 et 90000 sont au vert (ou 120000, 130000, 150000, 160000 et 200000)

En plus c'est joli

[bobe]

Oui, mais ensuite il faut la faire coïncider aux fenêtres d'accalmies (données par ta clock), sinon la clock n'a aucun intérêt. T'as 2 fréquences à juxtaposer, la fréquence optimale de décollage (par rapport au réserve d'un astre), et la fréquence donnée par le cycle douche / paix. Et ça tombe juuuuuste mal, pour les destinations à 10.000 km.


Pour les destinations plus lointaines c'est nettement pire dans le sens où elles régénèrent de plus en plus lentement. Autrement dit ta "fréquence optimale de décollage pour pas les épuiser" est de plus en plus longue. Bref au final ça veut dire que soit tu vises le système clos (cargo = regen) et tes fusées restent au sol très longtemps (probablement plus que 34 jours dès les 30.000 km - qui ne régénèrent même pas 2T en 34 jours donc). Soit tu lances à toutes les fenêtres et ensuite tu changes de cible (mais là du coup c'est du manuel).

Bref, ça se goupille mal, et plus on vise loin, pire c'est.

Ah ok, quand tu parlais de rentabilité, tu parlais tout aussi bien d'optimiser le rapport fuel utilisé/quantités ramenées ET taux d'utilisation des fusées. gotcha

edit: de ce que je constate, le taux de renouvellement ne semble pas dépendre directement de la distance mais du type de destination (certains types d'objets célestes se retrouvent plus ou moins aux mêmes distances, mais pas toutes)

[Yank31]

Oui y'avait un AND gate.

Mais bref, l'idée principale je suppose c'est de justifier, ou rendre efficace, l'automatisation. Du coup, vu qu'on peut pas automatiser le changement de destination, 1°) il faut que le système soit clos (conso = regen ; stable), 2°) il faut que ça soit un minimum raisonnable au niveau du taux d'utilisation comme tu dis fort bien, parce que si forcer l'automation implique de laisser une fusée croupir sur son pas de tir pendant 128 cycles juste parce que c'est le ratio pour conserver l'équilibre, ben...

C'est pas efficace, du tout.


Perso j'ai transigé, mon programme n'est pas clos (légèrement déficitaire), mais en contrepartie les fusées décolleraient assez souvent. Semi auto donc, à un moment lointain mais certain, faudra que je change de destination.

- - - Mise à jour - - -

D'ailleurs à ce sujet, question bonux du jour :

Quand je met la priorité sur "!" (priority please comme dirait Brothgar ), ça fait une sirène. C'est chiant. Par contre ce serait hyper pratique si je pouvais déclencher ça à la demande (en automatique), pour indiquer par exemple que ma fusée explo est rentrée. Boom ca déclenche la sirène tout seul.

J'ai essayé avec des portes etc mais j'ai pas trouvé. Des idées ?

- - - Mise à jour - - -

Tu fais juste un circuit témoin qui passe au vert si des météorites sont tombées dans la journée (ça évite de rester scotcher sur la surface toute la journée). Tu prends note en fin de journée et tu réinitialises. Tu fais ça jusqu'à que tu as déterminé où tu en es du cycle d'activité des météorites.

Filtre les signaux verts < ~20 secondes si tu fais ça. J'ai eu deux faux positifs sur 38 jours (vert court, rien qui tombe).

[bobe]

ah, moi le glitch que j'ai eu plusieurs fois => Une pluie de météorite détectée par les deux scanners. Un des scanners qui repasse en standby brièvement avant de redétecter la pluie. Pouf les portes blindées qui se rouvrent.
J'arrive pas à voir le bug en direct, mais c'est sùr et certain que c'est pas un manque d'électricité.

Pour l'alerte, j'ai pas d'idée là tout de suite

[Yank31]

Bon je viens d'armer l'horloge.

Au poil du cul avec une clock réglée à 0,1% le petit matin, bim boum, précision quasi-atomique.


Et du coup comme j'ai viré toutes ces saloperies pour la recalibration-automatique-lol, j'ai 14 ports... et en allant réfléchir à comment utiliser tout ça, je vois que là mes scanners sont éteints (jusqu'ici c'est normal) mais continuent d'émettre vert. Pardon ? C'est nouveau pour moi ça... mais j'ai donné un peu de x3 ces derniers temps, du coup je sais pas si ça a joué. On verra plus tard

[Yank31]

ah, moi le glitch que j'ai eu plusieurs fois => Une pluie de météorite détectée par les deux scanners. Un des scanners qui repasse en standby brièvement avant de redétecter la pluie. Pouf les portes blindées qui se rouvrent.
J'arrive pas à voir le bug en direct, mais c'est sùr et certain que c'est pas un manque d'électricité.

Mais il pleut ensuite ou pas ?

[bobe]

oui oui, mais les portes blindées s'ouvrent (38s et des brouettes), puis se referment (idem). Si j'ai du bol, le cirque se termine avant que les météorites se pointent, sinon...
Ça m'est arrivé deux ou trois fois. J'ai pas encore trouvé comment ça se déroule.

Tes scanners sont éteints mais envoient vert ? par "éteint", tu veux dire qu'ils ne sont plus alimentés en énergie ?

[Yank31]

S'il pleut ensuite, c'est pas ce que j'appelle un faux positif. Les faux positifs que j'ai eu, c'est vert et rien derrière. Mais c'était... bref, voir ci haut.

Donc si chez toi il pleut ensuite, c'est un problème de détection. Quand les portes se ferment, tes scanners perdent énormément en network (forcément), du coup un peut perdre le signal (il a un network de merde), et envoyer rouge. Ca se rouvre, ils ont meilleur network, il se dit : "ah mais oui y'avait un truc, je le vois maintenant", ils renvoient vert. Et tu t'es pris 80s d'asteroides gratos.

Pour éliminer ça j'ai relié l'output des scanners au set d'un memory toggle. Du coup dès qu'ils envoient vert, ça le fige. Et bref tu le reset si et seulement si le rouge d'un scanner dure plus de 200 secondes. Ou tu fais ta sauce (en fait les valeurs dépendent du setup, perso j'ai 100% network donc tout est calé sur un avertissement de 200s, portes, shut-off, tout), mais l'idée c'est de verrouiller le vert dès qu'il apparait, pour éviter ces blagues.


Oui, coincés sur vert alors que pas alimentés. Une première...