Cela fait un moment que nous n’avons pas fait le point sur l’association et ses activités, ses membres, ses objectifs, et il est temps de se plier à ce petit exercice, tout en restant synthétique ! Vous me savez concis, n’est ce pas ? ^^
Nous arrivons au terme de cette année 2021, qui a connu un événement fort et que nous attendions depuis la création de l’association côté Staff : un event KSP IRL, le KSPACECONTEST ! Et ce fut encore mieux que nous ne l’avions envisagé, il y a maintenant de ça… 4 belles et longues années ! Nous espérons bien sur que cela vous a autant plus à vous, participants, spectateurs, followers, et nous espérons bien remettre le couvert cette année et les suivantes 😉
Du côté des activités communautaires, les initiatives battent leur plein, avec notamment le tournoi BDA qui a repris pour sa 3ème Saison et devrait bientôt retrouver son rythme de croisière, ainsi que le défi d’Emilien concernant l’optimisation d’un lanceur sur la base d’une charge utile de 10 tonnes et plusieurs critères de cotations. En parallèle, l’équipe a remis en place son traditionnel Calendrier de l’Avent KSP sur nos plateformes d’échanges, avec un max de participations ! Bien sur, bien sur, vous allez demander « et KSC5 ? Et KSC6 ? » et vous en avez bieeeeen le droit. C’est votre humble serviteur actuellement à la plume qui porte la responsabilité de l’échec de la publication de ces derniers, comme cela fut évoqué sur le Discord, mais il est important de re-statuer ici même : nous ne savons pas quand et comment les résultats pourraient paraitre, mais probablement pas sous la forme de l’habituel article. Nous disposons d’un fichier de travail partagé, terminé à 70%, qui est un objectif plus raisonnable comme support de partage, et nous devons réfléchir à comment le terminer pour vous le présenter. Nos excuses, MES excuses.
Et puisque nous en sommes à parler staff, transition faite, accueillons officiellement Harpercix et BsamohT dans l’équipe ! Vous connaissez le premier de longue date dans la commu, puis en tant que modérateur du Discord, et les deux faisaient parti des éminents participants au KSPACECONTEST, deux hommes de qualité donc ! Tous deux rejoignent le staff afin d’apporter leur soutien et leurs idées, pour aller plus loin mais aussi renforcer nos acquis qu’ils ont vécu en tant que membres de la commu. Une assemblée générale a eu lieu, comme à chaque année bien sur, afin de les intégrer officiellement au registre de l’association. Ce fut d’ailleurs l’occasion de renouveler des postes, avec Guillaume en tant que président, Yann en tant que secrétaire, Stéphane en tant que Trésorier, Thomas, Oscar et Aurélien dans le bureau de l’association. Saurez-vous réassocier les prénoms avec leurs pseudos ? 😛
Je tiens à préciser personnellement, et je profite de ce billet, que je n’occuperai plus l’intégralité des fonctions du président, telle qu’elles furent menées les années précédentes. Ce fut un réel honneur et plaisir, mais j’ai désormais une petite fille et je me suis engagé, auprès de ma famille, à passer moins de temps pour KSC au profit de ces premières précieuses belles années. C’est après tout ce que j’ai fait pour l’association, depuis sa fondation, et avec l’aide du staff, un p’tit bébé à faire grandir et je pense qu’on a bien réussi, je suis fier de mon engagement pour faire vivre la commu à mon échelle, et je suis heureux d’avoir pu mener le KSPACECONTEST aux côtés de vous tous, quelques jours à peine avant la naissance de ma gamine. C’était un réel objectif depuis le début, qui apparait d’ailleurs en toutes lettres dans notre page A-Propos, depuis la création du site ! C’est un bel Event sur lequel terminer ma fonction de président pour désormais revêtir celle de président honorifique. N’ayez crainte, le staff a largement repris mes différentes tâches, et s’avèrent encore plus efficace et créatif 😀 Je reste donc dans l’équipe et disponible pour aider autant que possible, mais avec un simple commun accord sur le fait de dépenser bien moins de temps qu’à l’origine, c’est à peu près tout ce qui change 🙂
Je crois que c’est a peu près tout ! Pensez à nous suivre les réseaux, sur Twitter, Discord, Twitch, afin de ne rien louper de nos activités !
Aujourd’hui, nous vous proposons une petite plongée dans l’optimisation d’un Gravity Turn, ayant pour objectif de chercher les paramètres optimaux d’un lancement. Cette première partie permettra de vous présenter la genèse du projet et la phase de recherche ainsi que la récupération et le traitement des données. La seconde partie présentera le script en lui-même, disponible pour tous, et… C’est du lourd 😉
Ce projet est le fruit de nombreux échanges entre PhilippeDS et Dakitess, deux joueurs chevronnés de KSP, le premier ayant acquis une certaine expertise du mod kOS (son tuto est formidable !) permettant de coder des programmes et d’en profiter dans le jeu ; le second ayant l’expertise de la conception de vaisseau et une bonne connaissance des trajectoires idéales à suivre, notamment lors des Gravity Turn. Et on va pouvoir mettre cela à profit !
Mais d’abord, c’est quoi, un Gravity Turn ? Direction le Suivez l’Guide n°3 pour tout comprendre de cette manœuvre appliquée à KSP au sein d’un tuto très complet ! Mais elle est « si simple » que nous pouvons la résumer ici en quelques lignes : il s’agit de donner un petit décalage d’angle (le fameux PitchOver) à la fusée très peu de temps après le décollage, puis de mettre votre SAS en suivi prograde, et ainsi d’atteindre un profil d’ascension très lisse et propre, réduisant au mieux les pertes par gravité, par frottement, et par désaxe de poussée.
Vous l’aurez compris, puisque la fusée suit à tout instant son prograde, elle n’est globalement pas contrôlée pendant toute son ascension, ce qui signifie que tout (ou presque) est déterminé dans les premières secondes après le décollage par deux paramètres uniquement : l’amplitude du décalage et le moment, que nous nommerons respectivement Amp (pour Amplitude du PitchOver) et VPitch (pour Vitesse au moment du PitchOver). Cela entraîne deux remarques : tout d’abord, ces deux paramètres sont extrêmement sensibles ! La moindre variation se répercutera tout le long de l’ascension et aboutira à des résultats qui peuvent être très différents. Mais c’est pleinement répétable et c’est ce qui compte. Ensuite, puisque nous n’avons que 2 paramètres d’entrée en termes de contrôle, il va être relativement facile de mener une étude partiellement automatisée pour trouver les meilleurs couples (Amp ; Vpitch) en répétant plusieurs lancements.
Manuellement, on peut se figurer la méthodologie ainsi, en première approche :
Concevoir une fusée spécifique ;
La placer sur le pas de tir et choisir un angle de décalage, par exemple 5° depuis la verticale, en direction de l’Est (l’océan !) ;
Réaliser un premier décollage avec un Vpitch de 50 m/s et constater le résultat sur la trajectoire ;
Si la fusée parvient en orbite, alors on peut réduire Vpitch à 45m/s et constater si le résultat est plus efficace ou non ;
Si la fusée ne parvient pas en orbite, il faut alors augmenter la VPitch.
On décide qu’un Gravity Turn est plus efficace qu’un autre lorsque la quantité de carburant restant à la fin est supérieure : cela signifie que le Gravity Turn consomme moins de carburant pour un même travail. Cela est équivalent à comparer la masse finale du vaisseau : plus la masse est importante après la mise en orbite et plus il reste de carburant et donc plus le Gravity Turn est efficace.
Et ainsi de suite, jusqu’à tomber sur une valeur VpitchOpti qui maximise la quantité de carburant restante une fois en orbite, pour une amplitude de décalage donnée, ici 5°. On pourrait refaire cette approche avec une amplitude de décalage de 10°, ce qui abaissera le seuil des Vpitch, et voir si un nouveau couple de valeurs est encore plus bénéfique. Néanmoins un paramètre important demeure : la fusée. Elles sont toutes différentes, en taille, en structure, en étages, en proportions, en durée de combustion… et, bien sûr, ça compte.
Ce couple ne serait donc valable que pour une seule fusée spécifique, et difficilement adaptable à un autre lanceur ? Pas tout à fait, et heureusement.
L’un des paramètres les plus influents sur ce couple (Amp ; Vpitch) est le TWR au décollage de votre lanceur, et c’est une valeur que l’on peut aisément récupérer dans le jeu ou via un programme. Par expérience, deux fusées proches dans leur conception (proportions, rapport des étages, configuration), avec des TWR au décollage identique, mais une masse totalement différente, type 1000t ou 100t, donneront des couples de valeur (Amp ; VpitchOpti) très voisins, de sorte qu’il devient possible de rechercher ce couple de valeurs pour un TWR au décollage donné. Pratique !
Voici donc la formulation complète de la problématique traitée dans ce document :
Quelles sont les valeurs estimées du couple [Amp ; VpitchOpti] garantissant l’ascension optimale d’un lanceur quelconque à partir de son TWR au décollage ?
Il va nous falloir beaucoup de lancements pour construire de manière empirique des courbes permettant d’avoir ces optimisations ! L’avantage, c’est que l’on ne va pas avoir besoin de maths, ou pas trop. Nous utilisons une autre approche : celle de la quantité d’informations pour en tirer des données et être capable de construire un modèle par interpolation / extrapolation 🙂
Pour procéder, il faut commencer par concevoir un lanceur très standard, dont la configuration sera aussi commune et basique que possible pour correspondre au mieux aux lanceurs des joueurs. Nous sommes partis sur le lanceur disponible dans le Suivez l’Guide n°3 qui parle justement en détails de la manœuvre du Gravity Turn et invite les joueurs à faire varier le TWR pour voir l’impact sur la trajectoire.
Nous le modifions de sorte à simplifier sa Charge Utile et la résumer à un réservoir de carburant dont nous interdisons la consommation : voyez cela comme un bloc de béton inerte dont nous pouvons affiner la masse précisément si nécessaire. Le lanceur est constitué d’un simple étage central propulsé par un LVT-45, et, sur les flancs, nous retrouvons deux boosters à poudre BACC.
Au-dessus de l’étage central, un 2ème et dernier étage qui permettra la fin de l’ascension puis la circularisation, avec le célèbre LV909 pour la partie propulsion. Une coiffe est également présente pour protéger la charge utile et sera larguée à 70km, après avoir franchi la limite de l’atmosphère. Un lanceur somme toute très conventionnel !
Au décollage, le LVT-45 et les boosters à poudre sont activés en même temps, ainsi que les pieds de structure qui maintiennent le lanceur bien à la verticale. Le LVT-45 est configuré sur sa puissance maximale alors que la puissance des boosters à poudre est ajustée dans le BAV pour obtenir le TWR souhaité.
Cette configuration de lanceur permet d’ajuster le TWR au décollage sans ajouter / supprimer / échanger une part, en jouant seulement sur la puissance des Boosters à poudre et éventuellement sur les jauges de quantité carburant de la charge utile inerte. La valeur qui sera observée pour quantifier l’efficacité du lancement, sera la masse totale finale en orbite à 100km circulaire. Cela comprendra la charge utile encore solidaire de son dernier étage, et sans la coiffe.
Afin d’automatiser le tout, chaque craft sera équipé de modules propre à kOS, à savoir trois KAL9000. Le KAL9000 est le processeur de kOS le plus puissant avec une très grande capacité de mémoire. Il a été utilisé pour nos tests simplement parce que c’était le plus petit et le plus léger des processeurs proposés par kOS. Pourquoi en avoir utilisé trois ? Un seul est réellement important : celui qui contient le code nécessaire au lancement. Le deuxième est activé dès le décollage et permet d’enregistrer les relevés télémétriques jusqu’à la fin de la circularisation : Altitude, Pitch, TWR, vitesse verticale, vitesse par rapport au référentiel de surface, vitesse orbitale, pression de l’air, masse du vaisseau et delta-v restant. Le troisième enregistre les mêmes données télémétriques mais uniquement lors de l’activation du dernier étage. Ces deux processeurs télémétriques n’ont pas de réelles importances dans le déroulé du vol mais nous ont permis de décortiquer certains comportements, notamment les cas les plus limites.
La première étape indispensable constitue donc la sauvegarde d’un craft dédié pour chaque TWR testé, à partir de la base commune, en jouant sur la puissance des boosters, comme évoqué. Nous obtenons la liste ci-contre, avec un lanceur par dixième de TWR, de 1.2 à 2.08.
Note : les lanceurs de TWR 1.2 à TWR 1.8 ne font varier que la puissance des Boosters. Les lanceurs de TWR 1.9 à 2.08 font en parallèle diminuer la quantité de carburant de la charge utile pour atteindre ces valeurs élevées. Ils ne sont donc plus directement comparables les uns avec les autres mais l’étude se focalise bien sur la recherche de la trajectoire idéale pour un TWR donné.
Un programme kOS a été écrit intégralement par PhilippeDS. Afin d’automatiser au maximum les lancers pour un TWR donné, il était important d’initialiser un premier couple de valeurs (Amp ; Vpitch). La difficulté résidait ensuite en la récupération de ces valeurs et la modification automatique. Nous sommes partis de deux constats :
pour un TWR donné, plus Amp (angle par rapport à l’horizontal) est faible, plus Vpitch est élevée.
pour une valeur de Amp donnée, plus le TWR est élevé, plus Vpitch est faible.
À partir de là, pour un TWR donné, il suffisait d’initialiser le script avec Amp = 65° et une Vpitch suffisamment élevée (114 m/s pour un TWR = 1.2).
Si la mise en orbite se fait correctement, alors le script doit recharger automatiquement le lancement en diminuant Vpitch de 2 m/s. Cela se poursuit jusqu’à l’échec d’une mise en orbite, liée à une trajectoire trop agressive, qui signe la fin de cette première passe automatisée.
Une fois que le programme a déroulé les Vpitch d’une Amplitude d’angle pour obtenir le VpitchOpti correspondant, on passe à une autre Amplitude pour obtenir le spectre complet des possibles. Puisqu’il n’est pas question de tester pour chaque degré d’angle (car cela n’aurait aucun intérêt pratique, reproductible à la main notamment), les valeurs testées seront les suivantes : 85° ; 80° ; 75° ; 70° ; 65°. Un pitch supérieur à 65° semble peu pertinent dans la mesure où cela constitue déjà une consigne d’angle très violente de 25° d’un coup.
Il a été décidé qu’un lancement était automatiquement un échec lorsque le vecteur prograde passait sous l’horizon. Si, en condition réelle, cela n’est éventuellement pas rédhibitoire dans des conditions limites, c’est tout de même très rare qu’un tel lancement puisse parvenir en orbite et aboutir à un bilan optimal, dans la version Stock de KSP. Les échelles du dessus (RSS) seraient du genre à nuancer cette hypothèse, mais ce n’est pas le sujet.
EXPLICATION DU SCRIPT
Initialisations
Au début de notre code, on initialise toutes les variables : l’apogée cible ne correspond pas forcément à l’apogée de notre orbite après la circularisation. Il s’agit simplement d’une condition d’arrêt pour le gravity turn.
Nous lançons notre vaisseau depuis le KSC à l’équateur et en direction de l’est. Notre azimut est donc 90°.
Dans la dernière ligne, on voit apparaître un fichier CSV. Après chaque lancement, le script est réinitialisé et exécuté de nouveau depuis le début. kOS n’a pas de mémoire sur plusieurs lancements, il ne connaît pas les résultats des précédents scripts. Une façon de contourner cela est d’enregistrer les valeurs qui nous intéressent dans un fichier pour que kOS puisse retrouver ces valeurs.
Récupération des données
L’écriture dans un fichier est une méthode fournie par kOS directement, en revanche, il ne fournit pas la possibilité de lire un fichier. Tony48, le concepteur du mod kOS.Utils (entre autres) nous a beaucoup aidé et a ajouté à son mod la possibilité de lire un fichier avec la commande addons:file:readAllLines. Merci à lui ! Des détails sur son mod ici : https://github.com/tony48/kOS.Utils.
Cette commande permet de lire un fichier et de remplacer chaque ligne du fichier en une liste compréhensible par kOS. Ensuite, et c’est le but des lignes 2 à 4 ci-dessous, il faut séparer chaque liste en une liste de valeurs. De cette manière, on peut récupérer n’importe quel vol (une ligne du fichier) et, pour chacun de ces vols, on peut récupérer la caractéristique qui nous intéresse (la masse finale par exemple).
Dans notre cas, on récupère la vPitch du précédent vol (vitesse verticale à partir de laquelle le gravity turn commence) et l’amplitude (nommée thePitch dans le code).
Ces données vont être transmises à deux autres processeurs kOS présents dans le craft. Ces processeurs ont pour simple objectif de réaliser des mesures télémétriques pour nous permettre de vérifier nos données après les lancements.
La fonction doFlight
La partie présentée dans l’image ci-dessous permet d’initialiser le vol. On commence par enregistrer les noms des fichiers dont on aura besoin et on envoie aux deux processeurs télémétriques la vitesse et le pitch qui seront testés. Deux intérêts à cela :
s’assurer que les processeurs sont prêts à relever les mesures avant le décollage ;
permettre à ces processeurs de créer eux-mêmes des fichiers qui seront nommés à partir du nom du craft, de la vitesse et du pitch testés.
On obtient alors une liste de fichiers de ce genre :
On aurait été très embêté si on n’avait pas eu de noms clairs pour les distinguer.
Condition d’échec
Certains vols étaient voués à l’échec. On le sait. En cherchant le GT optimal, on s’approche forcément d’une limite en dessous de laquelle le vaisseau ne pourra jamais atteindre l’espace et va retomber sur Kerbin. Inutile alors de perdre du temps en continuant le vol jusqu’au crash. Il nous fallait donc une condition d’arrêt : nous avons choisi d’arrêter le vol lorsque le marqueur prograde passait sous l’horizon. kOS mesure les angles par rapport au “dessus” de la navball et non pas par rapport à l’horizon. Ainsi, si cet angle est supérieur à 90° alors, le prograde est sous l’horizon. Le prograde est exactement à l’horizon lorsque le vaisseau est au niveau de son apogée. Si le prograde passe sous l’horizon, ça veut dire que le vaisseau a passé son apogée et est en train de retomber. Bien sûr, cette condition d’arrêt n’est valable que lorsque le vaisseau est encore dans l’atmosphère.
L’échec est enregistré dans notre fichier avec une ligne de FAILED bien visible.
Gravity turn
Dans la fonction doFlight, on voit ensuite apparaître ces lignes. Elles disent simplement d’attendre que la vitesse soit supérieure ou égale à la vitesse qu’on teste actuellement. Une fois cette vitesse atteinte, on démarre le Gravity Turn.
J’ai utilisé la fonction gravityTurn que j’ai présenté dans l’épisode 6 de mon tutoriel.
Fin de la fonction doFlight
Tout d’abord, le processeur principal envoie un message aux autres processeurs pour leur indiquer que la circularisation est terminée. Ces derniers peuvent donc interrompre leur script. Ensuite, on enregistre tout dans notre fichier csv et, en fonction de la situation, on arrête définitivement la simulation ou bien on démarre un nouveau lancement avec une nouvelle vitesse.
Au final, pour chaque vaisseau testé, on obtient un tableau récapitulatif qui nous permet de déterminer, à la main cette fois, la meilleure valeur à conserver. On a constaté que, pour une amplitude donnée, la meilleure vitesse était toujours la plus faible. Et puisque nous parcourons les vitesses de haut en bas, il s’avère que le profil le plus optimal est toujours l’avant dernier, celui avant l’échec.
Sans plus attendre, voici les résultats synthétiques de ces quelques centaines (!) de lancements ! Nous avons concaténé pour chaque TWR les couples (Amp ; Vpitch) optimaux, afin de disposer de l’abaque suivant :
Chaque couleur correspond à une amplitude d’angle donnée, calculée depuis l’horizon. Les abscisses font figurer les TWR, et les ordonnées correspondent aux valeurs de VpitchOpti. En d’autre terme, la lecture de ce graphique vous permet, pour un lanceur quelconque, et à partir de son TWR au décollage, d’en déduire une bonne estimation du VpitchOpti conduisant à un GT optimal. Pour chaque TWR en abscisse, on a donc plusieurs couples de (Amp ; VpitchOpti). Le couple de valeur dont le Vpitch est le plus faible sera très généralement le meilleur, mais les résultats restent sensiblement identiques. Il restera plus simple pour une utilisation “à la main” de déclencher un GT à 16m/s plutôt qu’à 8m/s par exemple, en termes de temps de réaction et de rapidité d’exécution.
Prenons un exemple ! Le TWR 1.4 nous offre 5 courbes, donc 5 couples de valeurs possibles, les voici :
85° ; 22 m/s
80° ; 36 m/s
75° ; 50 m/s
70° ; 62 m/s
65° ; 78 m/s
Globalement, toutes ces combinaisons devraient vous amener à un GT très agressif et optimal. La combinaison dont la valeur de l’amplitude du PitchOver est la plus faible, ici 85° (5° d’amplitude depuis la verticale), permet la trajectoire la plus naturelle et la plus efficace. Le lanceur réalise un petit décalage de 5°, très tôt après le lancement, dès 22m/s, puis reste en prograde jusqu’à atteindre l’Apoapsis de 100km, et enfin circulariser.
Néanmoins, attention : il s’agit d’une valeur cible idéale pour notre craft précis. C’est donc une très bonne estimation de départ, mais qui pourrait s’avérer légèrement hors limite pour un autre craft quelconque du même TWR. Par précaution et si vous n’êtes pas du genre à relancer plusieurs fois un craft pour trouver son couple (Amp ; VpitchOpti) parfait, n’hésitez pas à simplement prendre un peu de marge, en ajoutant 5m/s par exemple !
Ces courbes peuvent donc servir pour l’utilisateur ne disposant pas de kOS et réalisant simplement ses lancements à la main. Il faut néanmoins apporter une considération importante : la réactivité d’un programme est certes bien plus importante que celle d’un humain, la consigne de décalage d’angle se fera pourtant plus lentement pour kOS que pour vous, car le programme reste dépendant de l’asservissement de KSP qui n’envoie pas une consigne binaire “tourner” au clavier.
De fait, pour Dakitess par exemple, il ajoute quelques m/s au feeling, pour obtenir la même ascension. Simplement parce qu’il atteint, au clavier, le décalage un peu plus vite que ne le fait kOS. Un autre joueur qui appuierait par petites touches, progressivement, pour rejoindre la consigne d’angle, sera peut-être exactement dans le même genre de valeur que notre graphique précédent.
Car notre ambition première avec cette petite méthodologie, c’est bien sur le fait de pouvoir vous proposer un programme kOS qui détecte le TWR de votre lanceur au décollage et lui associer, grâce à ces quelques courbes, le couple de valeurs optimal (Amp ; VpitchOpti). Pour cela, et puisqu’un programme ne sait pas forcément “lire” les données comme nous venons de le faire sur le graphique, il faut transformer ces courbes en fonctions, en les approchant à l’ordre 2 pour un maximum de précision et un temps de calcul raisonnable.
Cela donne les équations suivantes, de la forme VpitchOpti = f(TWR) pour chaque Amp :
On remarque que le R² est très proche de 1, ce qui signifie que nos courbes de tendances passent presque parfaitement par les valeurs que nous avons obtenues lors de nos essais concrets. Cela signifie surtout que nous allons pouvoir attribuer un VpitchOpti précis à une valeur de TWR intermédiaire du type 1.43 ou 1.77, et ne pas nous contenter des valeurs discrètes et entières définies lors de la méthodologie.
Par exemple, si un joueur charge une fusée dont le TWR au décollage est de 1.55, et qu’il utilise kOS, alors notre petit programme sélectionnera le couple dont l’Amplitude d’angle est la plus faible, ici 5° (85° depuis l’horizon), et utilisera la fonction pour lui retourner la valeur de VpitchOpti, ce qui donne ici : VpitchOpti (1.55 ; 85°) = 9.13m/s.
Y’a plus qu’à décoller ! Et voir ce que ça donne. On ne saurait trop insister : cette estimation correspond à l’idéal de la fusée de notre expérience, il est possible que cette combinaison entraîne une trajectoire trop agressive qui mène votre lanceur à sa perte, ou à une ascension légèrement sous-optimale. Mais, normalement, l’idéal est au voisinage et nous avons donc un très bon point de départ pour la suite.
En parlant de suite… Nous l’avons justement réalisé, ce script kOS à destination des utilisateurs, et capable de bien des merveilles ! Il permet notamment d’avoir une estimation des paramètres de décollage basé sur le modèle présenté dans cet article, bien sûr, mais introduit également des facteurs de corrections, des profils de vols basés sur votre propension au risque, et… Cerise sur le gâteau, un mode complètement automatisé permettant d’obtenir pour VOTRE lanceur, le GT parfait ! Mais ce sera l’objet d’un prochain article :p
En espérant que cet article vous aura plu, vous pouvez dès à présent profiter des données issues de l’abaque pour vos lancements à la main, et nous vous invitons à poser toutes vos questions directement en commentaire sur le topic dédié ^^ A très bientôt pour la suite !
Prenez le temps de parcourir tout le guide une fois, à tête reposée, sans le jeu. Un passage vous parait compliqué ? C’est sans doute qu’il va être détaillé et expliqué par la suite 😉 -
Utilisez les fichiers de téléchargements que l’on vous propose, ça permet d'avoir une base commune qui simplifie bien des choses ! -
Faites un clic-droit, ouvrir dans un nouvel onglet, sur les gifs et images, afin de profiter des visuels en plus grand. Ha, saviez-vous qu'en les survolant, vous disposez d'une petite légende pouvant apporter une info ou astuce bien pratique ? ^^ -
N’ayez pas peur de vous replonger dans un tuto que vous imaginiez acquis : vous pourriez retrouver des informations importantes ! -
N’hésitez pas à poser toutes vos questions dans les commentaires, en veillant à être suffisamment précis 🙂 -
Sauvegardez fréquemment pendant l’exécution InGame d’un tuto. Utilisez les outils Alt + F5 et Alt + F9 pour les nommer et les retrouver facilement. Les tutos vous proposent fréquemment des points de sauvegarde importants, mais rien ne vous empêche d’en faire davantage ! A ce propos, un petit mod permet de simplifier et robustifier cet aspect du jeu, testez-le ^^ -
Essayez les exercices en fin du tutoriel : via le téléchargement d’une save vous avez la possibilité d’essayer plusieurs contextes précis, permettant de vous améliorer et/ou d’identifier vos difficultés. Cela permet notamment de poser vos questions sur des points précis qui bloquent, sans avoir à repréciser la fusée que vous avez utilisée, l’endroit, les circonstances 😉 -
Découvrez en dernière page quelques mods directement liés aux éléments présentés dans ce tutoriel, mais attention : ils introduisent parfois quelques changements dans le GamePlay !
Plusieurs spoilers parsèment le texte : ils permettent de raccourcir sensiblement la taille des tutos tout en préservant de nombreux détails pour ceux qui aimeraient les lire. N’hésitez toutefois pas à les ouvrir pour découvrir leur contenu, ils peuvent s’avérer riche en vulgarisations et exemples concrets !
En dehors de la première, les vidéos intégrées le sont avec un minutage de début précis : les passages sélectionnés correspondent donc à votre lecture. Rien ne vous empêche de continuer à visionner la vidéo, mais sachez que les extraits ne ciblent guère plus d’une minute ! Vous aurez tout le temps de retrouver la suite au fil de votre lecture. Vous pouvez également la visionner en entier à tout moment pour vous imprégner de l'enchaînement d’étapes.
Certains liens permettent de télécharger des fichiers. Cela est fortement recommandé (sauf mention contraire) car permettant de tous nous retrouver avec une base commune et écartant donc toute erreur de conception : la plupart du temps vous apprenez une manœuvre, une technique, évitons d’emblée les bêtes oublis d’alimentation électrique ! Exit également les considérations exotiques liées à une conception farfelue : prenez les briques que l’on vous propose, apprenez avec et vous saurez par la suite adapter les explications à vos besoins et créations 😉
VAB : « Vehicle Assembly Building », le bâtiment d’assemblage des véhicules… Oui oui xD
SPH : « Space Plane Hangar », tout pareil mais pour les trucs plutôt « plats » et horizontaux 😉
Parts : élément de construction, comme les réservoirs, propulseurs, batteries, lumières…
Crafts : c’est une construction, comme une fusée, un satellite, un avion, un rover…
Comme dans la plupart de nos tutoriels, vous retrouverez une archive riche en documents KSP, comportant généralement une sauvegarde qui incluent des Crafts et des mises en situation pour vous entraîner et vous tester, voir les exercices en fin de chapitre 🙂 Pour rappel, cette archive doit être décompressée, et vous n'avez plus qu'à copier coller le dossier "KSC - NomDuTuto" au côté de vos autres sauvegardes. Il est bien sur préférable de dédier une installation propre et dénuée de mods pour profiter au mieux de nos tutoriels, vous aurez ainsi la possibilité d'y cumuler proprement vos sauvegardes ! Pour en savoir plus sur le maniement des dossiers de sauvegarde et la création d'une installation toute propre de KSP, nous vous redirigeons vers ces deux liens, c'est très très simple et rapide 😉 Et bien sur, pour manipuler les fichiers Crafts qui ne manqueront pas de vous être proposés au téléchargement, c'est ici que ça se passe.
Dans ce tutoriel, on commence pour de vrai cette rubrique téléchargements, puisque vous allez découvrir les premiers exercices d'application, patiemment mis en scène pour que vous puissiez vous entrainer et poser vos questions précisément sur ce qui bloque, avec un contexte partagé, que rêver de mieux ? Bien sur, vous aurez besoin des crafts associés, si bien que c'est une sauvegarde complète que nous vous remettons !
Dans l’espace, manœuvrer ne se fait pas au pifomètre. KSP est plutôt avare en information, en ne dispensant de base (sans mods) que bien peu d’indicateurs. Toutefois, il exploite un outil formidable : le point de manœuvre. Il faut voir ce dernier comme un point de calcul d’une trajectoire, on le positionne et on « programme » une injection selon les axes conventionnels de l’espace pour ensuite l’exécuter et se rendre où bon nous semble.
C’est un formidable outil qui devrait servir lors de pratiquement toutes vos escapades spatiales ! Prenez donc bien le temps d’appréhender l’ensemble de ses fonctions et subtilités 😉
Résumé
Les points de manœuvre sont avant tout des outils de projection : ils ne font pas le travail, permettant simplement de visualiser une injection. Reste ensuite à l’exécuter correctement pour avoir en sortie un résultat similaire à la prédiction, ce qui, nous le verrons dans ce guide, n’est pas nécessairement trivial ! Plusieurs éléments et cas d’utilisation seront abordés, de la manœuvre orbitale classique à l’atterrissage, en passant par la programmation en série de nœuds.
I) LE CONTEXTE
Un point de manœuvre se pose très majoritairement dans l’espace, là où aucun appui ne saurait vous guider : pas de surface, pas d’atmosphère, pas d’eau, votre seule solution pour vous diriger consiste en la propulsion chimique. Mais là où tourner un volant se fait « à vue de nez » en ajustant la force que l’on y met en fonction de la réaction obtenue, il est bien difficile de se diriger dans l’espace… Pas de référentiel immédiat, pas de décor qui défile devant soit, rien que l’univers immobile, en apparence du moins.
A cela s’ajoute le fait que dans l’espace, on ne va jamais tout droit et les corps ne sont pas fixes. Cela complique grandement les choses : comment se rendre sur Duna, en partant de Kerbin ? A quel moment ? Après tout, le temps que je voyage, la cible aura bougé, il faut prévoir cela, tout en sachant que pendant une grande partie de la mission, nous orbiterons sous l’influence gravitationnelle de Kerbol, après avoir échappé à celle de Kerbin… Que de paramètres ! Comment savoir quand pousser et dans quelle direction ?
Les points de manœuvre permettent cela. Ces nœuds que l’on pose où l’on veut peuvent être résumés à des petits calculateurs qui vont offrir en temps réel une visualisation de la trajectoire obtenue après modification d’un ou plusieurs axes. On la refait ? Un point de manœuvre présente la possibilité de simuler une injection, une manœuvre comme son nom l’indique. On lui dit « un peu de poussée vers le haut, un peu de poussée vers la gauche » et il propose en sortie une courbe, l’estimation de votre trajectoire si vous effectuez la manœuvre correctement, comme nous le verrons par la suite.
II) LA CONFIGURATION D'UN POINT DE MANOEUVRE
Entrons un peu plus dans le détail. Ouvrez KSP, dans une SAVE dédiée aux tutoriaux, comme on vous conseille souvent de le faire, ou dans l’une de vos sauvegardes usuelles. Comme souvent, il est également possible de récupérer une SAVE avec quelques éléments déjà en situation pour avoir une base saine et commune, et c’est encore le mieux ! Vous en retrouverez le lien et le mode opératoire très simple dans la rubrique déroulante « Téléchargements », et nous allons nous baser sur ces éléments pour ce document. Profitez-en !
Rendez-vous dans un vaisseau actif, en orbite stable autour d’un astre. Pour reprendre l’exemple de la SAVE fournie, nous allons choisir le module intitulé "KSC - Sl'G4 - MunAR 100km", disponible autour de Kerbin à 100km d'altitude comme son nom l'indique. Pour cela, passez par le bâtiment "Station de Contrôle", vous devriez retrouver les crafts actuellement en mission. Après la théorie, c'est partie pour un peu de pratique ! Cliquez simplement sur l’orbite, vous allez obtenir une petite interface et vous allez cliquer sur le bouton comme ci-contre.
Une fois sélectionné, l’interface change et fait apparaitre les poignées de couleurs que nous évoquions précédemment :
3 axes possibles sont imagés avec une couleur et deux directions opposées, le tout dans le référentiel considéré qui est affiché en haut de votre NavBall : vous pouvez par exemple switcher entre "Surface" et "Orbit", deux référentiels bien différents, et parfois même un troisième, "Target", mais nous y viendrons plus tard, chaque chose en son temps. 3 axes, donc :
Vert pour Prograde / Rétrograde : permet d'excentrer votre orbite : vue de votre vaisseau, c'est "vers l'avant", "vers l'arrière"
Violet pour Normal / AntiNormal : permet d'incliner votre orbite : vue de profil, c'est "vers le haut" ou "vers le bas"
Bleu pour Radial / AntiRadial : permet de faire pivoter votre orbite : vue de dessus, c'est "vers l'extérieur" ou "vers l'intérieur"
Tirez un peu sur la prograde, c’est-à-dire la poignée en forme de rond vert, qui désigne la direction dans laquelle vous progressez à tout instant, votre vecteur vitesse. Ajoutez-y un peu de radial en tirant sur la poignée ronde bleue : vous venez d’associer deux injections dans des directions différentes, vous l’avez programmé. Bien sûr, dans l’espace, on ne décompose pas une manœuvre « un peu vers le haut » puis « un peu vers la gauche », on cumule les deux en un seul vecteur :
Ici, le point de manœuvre offre la résultante sous la forme d’un indicateur bleu foncé sur la NavBall : c’est dans cette direction précise qu’il vous faudra pousser pour exécuter la manœuvre ! Si vous ne voyez pas cet indicateur, orientez votre module dans l’espace, et vous devriez tomber dessus. A noter qu’un module suffisamment équipé (le bon pod / le bon pilote) dispose d’une option à gauche de la NavBall permettant directement de pointer dans sa direction, mais ce n’est en rien une nécessité 🙂
L’une des principales informations que vous allez surveiller, c’est celle que vous obtenez en vue Mappemonde (touche [M]) : la trajectoire de votre module, en sortie de manœuvre. Elle apparait sous la forme de pointillé et correspond donc à ce que vous obtiendriez si vous exécutiez correctement la manœuvre. Cela fait quelques conditionnels et nous verrons pourquoi par la suite 😉
En soit, c’est à partir de cette interface que vous allez façonner votre point de manœuvre : en tirant sur les poignées, vous allez former la trajectoire désirée, pour rejoindre un autre module (rendez-vous), pour intercepter la Mun et y atterrir, pour monter un réseau de communication complexe, etc. Vous œuvrez donc sur une estimation de résultat, une préparation. Notez également l’apparition d’une jauge sur la droite de la NavBall ainsi que quelques chiffres exprimés en m/s : c’est la quantité de DeltaV (Lexique) que requiert votre manœuvre. Pour tout de suite comprendre ce qu’elle représente, accélérez le temps pour presque rejoindre votre point de manœuvre, revenez en temps réel une minute avant. Pointez votre module dans la direction de l’indicateur bleu foncé, manuellement ou via l’option dont nous avons parlé précédemment.
Faites [CTRL + ALT + F5] pour sauvegarder le contexte et donnez l’intitulé « DEPART » histoire de ne pas éjecter votre module de la sphère d’influence de Kerbin par mégarde 😉 Nous utiliserons cette sauvegarde rapide juste après. Et maintenant, augmentez un peu les gaz : observez comme la jauge descend, à droite de la NavBall, de même que la valeur numérique du DeltaV !
Vous êtes en train de réaliser votre manœuvre, c’est-à-dire que votre vaisseau va effectivement rejoindre ce que vous aviez programmé. Pour être précis, il faut bien sûr réaliser la manœuvre là où vous l’aviez configuré ! La même chose ailleurs sur l’orbite n’aurait pas de sens. Un peu trop en avance ou un peu trop en retard et vous introduirez de l’imprécision, avec pour résultat une trajectoire de sortie un peu voire sensiblement différente. Et justement, nous n’avons pas cherché à être très précis, ici.
Coupez les gaz et faites [CTRL + ALT + F9] ou [CTRL + ALT + F8] selon votre réglage, pour recharger la partie à son état initial en sélectionnant « DEPART ». Vraiment pratique ces sauvegardes rapides, usez et abusez de cet outil pendant votre appentissage ! Vous notez que le point que nous avons configuré est toujours présent après un chargement, nous allons l’annuler : pour cela, un clic droit dessus, et la croix rouge, plutôt intuitif !
Vous avez noté qu’à côté de la croix rouge, se trouve un autre bouton ? Ce dernier permet d’expliquer au jeu que nous voulons cette injection non pas pour la prochaine rencontre avec le nœud, comme c’est le cas par défaut et comme vous l’utiliserez principalement, mais pour 1, 2 ou plusieurs révolutions plus tard. De quoi prévoir une injection longuement à l’avance, ce qui trouve son utilité dans certains burns interplanétaires, dont nous aurons l’occasion de reparler, mais dans un autre tuto 😉
Nous allons maintenant programmer proprement une manœuvre d’élargissement d’orbite : toujours à bord du module KSC - Sl'G4 - MunAR, posez un point de manœuvre suffisamment loin de vous (un quart d’orbite par exemple), et tirez sur le vecteur prograde (rond vert) jusqu’à obtenir une estimation d’apogée (pointillés pour rappel) à 500km : est-ce qu’on vous a déjà recommander d’utiliser nos SAVEs pour avoir une base commune ? :p
Obsolète depuis la 1.5.1 : remarquez qu’en dessous de la jauge on peut parfois lire « N/A » : c’est ici que devrait se trouver la prédiction du temps d’injection qui a une certaine importance. Toutefois, pour permettre au jeu de faire une estimation, il faut que le module ait été allumé à pleine puissance, ne serait-ce qu’un bref instant. Or le chargement rapide [F9] « casse » cette mémoire, le jeu ne se rappelle plus des caractéristiques de l’appareil. Approchez-vous à 2 minutes du nœud de manœuvre, pointez dans la bonne direction, celle du vecteur bleu, et allumez les gaz à fond un bref instant : soyez rapide ou vous allez déformer votre orbite ! Deux touches claviers permettent respectivement d’allumer les propulseurs à fond et de les couper à zéro sans transition : [X] et [W] selon nos recommandations de settings vu dans un précédent tuto.
Toutefois cela peut parfois poser problème pour de toute petite injection ou pour les joueurs les plus exigeants : imaginez que le calcul du burn vous donne un temps de 5 secondes alors que vous venez juste de mettre plein gaz pendant presque une seconde ! Vous avez probablement tout faussé… Dans ce cas, l’astuce est simple, prévoyez le coup : faite [F5] pour sauvegarder la partie quelque part en amont du point de manœuvre, placez-vous comme si vous alliez l’exécuter, allumez à pleine puissance, mémorisez le temps affiché, rechargez la partie via la touche [F9] et à vous de jouer en pleine connaissance du temps exact requis pour cette manœuvre 😉
Ouf, depuis la 1.5.1, tout cela n’est plus nécessaire, le jeu parvient tout le temps à estimer la durée d’une manœuvre, même après un rechargement, même quand le propulseur n’a jamais été allumé, etc !
C’est ici que nous allons également parler du nouveau panel des manœuvres intégrées en version 1.7 du jeu, très intéressant pour être précis. Après avoir posé votre point de manœuvre sur la trajectoire, plutôt que d’agir directement sur les poignées, là où l’interface peut rapidement devenir un peu encombrée si vous avez pas mal d’éléments en orbite, vous allez pouvoir profiter de l’onglet en bas à gauche de l’interface, assez sobrement intitulé « Manœuvre » en français.
Vous retrouverez ici tous les outils nécessaires à l’ajustement d’une manœuvre, de manière beaucoup plus précise et avec quelques features bien pensées. Bien sûr, vous pouvez tirer sur les poignées comme nous l’avons vu précédemment, mais vous pouvez aussi cliquer sur chaque axe, pour incrémenter la valeur du dV sur cet axe, très finement ! Et ça, c’est vraiment pratique. A droite vous avez d’ailleurs un curseur qui vous permet d’ajuster le montant de dV qui sera incrémenté.
D’ailleurs, au centre des poignées, vous avez deux petites flèches qui vont vous permettre de déplacer le nœud tout entier, il est lui aussi concerné par le petit curseur de droite pour ajuster la finesse des incréments. On aura l’occasion de reparler de cet outil un peu plus bas 😉 Vous disposez aussi d’un sous-onglet qui permet de rentrer manuellement des valeurs numériques précises pour chaque axe, cela peut avoir un intérêt lorsque vous utilisez des calculateurs de trajectoires, mais c’est relativement secondaire.
III) L'INJECTION
Il est donc désormais temps d’effectuer notre injection. Nous avons, dans le cas de notre SAVE, environ 28s de prédiction pour rehausser notre apogée à 500km : bien ! Et nous savons qu’une manœuvre s’effectue correctement pile à l’endroit où l’on a configuré notre nœud. Sauf qu’en une demi-minute, on parcourt l’orbite, et on déborde de ce point précis… Eh oui ! Une manœuvre idéale est calculée par le jeu comme la capacité d’injecter toute l’énergie en un bref instant. Ce qu’un module est rarement en mesure de faire, la puissance de ses propulseurs n'étant pas infinie, toute manoeuvre nécessite une durée minimale de burn.
Typiquement, avec un Mansail sur notre petite sonde, nous développerions un TWR (Rapport Poussée / Poids) considérable qui nous permettrait d’effectuer la même manœuvre en 4 secondes, pour coller au plus près de la théorie ! Sauf que ce serait drôlement peu pertinent :
- Le Mansail n'a rien à faire dans l'espace, il n’y est pas très adapté : si l’on dispose d’un TWR suffisant pour écouler plusieurs centaines de m/s en 4 secondes, c'est que l’on embarque un propulseur bien trop puissant avec une ISP certainement perfectible et une masse dissuasive au regard du module. Rappelez-vous, nous avons abordé ces notions dans le tutoriel sur la conception basique d’une fusée 😉
- 4 secondes ?! Comment diable être précis à l'échelle de 4 secondes ? Même en utilisant les touches d'allumage et extinction à 100%, à l’instant où le bas de la jauge sera atteint pour tout couper, l’imprécision sera importante, alors que l’on peut généralement viser moins d’un m/s résiduel dans la jauge, sans souci 😉 Une manœuvre modérément longue n’est pas un problème.
L’idée est simple : répartir la manœuvre de part et d’autre du point, 14 secondes avant, 14 secondes après, pour que la moyenne, le barycentre, se trouve justement au niveau de la manœuvre : logique ! Alors à vous de jouer, c’est parti, on accélère le temps méticuleusement et on commence à 100% de puissance pile à la moitié du temps estimé. Pour rappel, vous avez les touches [W] et [X] pour respectivement couper et allumer les propulseurs à 100% d’un coup, sans phase transitoire.
On prend garde à stopper quand la jauge arrive à la fin, en observant le décompte des m/s : vous pouvez baisser la puissance en approchant du terme, pour être plus précis et ne pas dépasser par mégarde la fin de manœuvre. A la fin, on obtient une belle ellipse qui reproduit assez fidèlement la prédiction : l’apogée devrait être contenue entre 480 et 520km mais sachez qu’il est tout à fait possible de s’approcher d’une précision inférieure au kilomètre ! Essayez d’ailleurs, c’est un bon exercice 🙂
Il est largement préférable de proprement « consommer » une manœuvre (0.2 m/s près) et de terminer en retard en baissant les gaz pour être précis, plutôt que de couper pile au bon moment… Avec plusieurs mètres/seconde résiduel dans la jauge. La baisse de puissance, jusqu’à ne laisser qu’un mince filet de gaz à quelques pourcents, permet également de gérer le décalage de l’indicateur bleu foncé et de le « suivre » pour parfaire l’exécution 😉
Eh oui, ce dernier réagit en temps réel en ajustant sa position en fonction de l’erreur que vous introduisez dans votre manœuvre : ce n’est de la faute de personne, simplement quand on vise pile l’indicateur bleu, en réalité on est forcément un tout petit peu décalé… Et sur une minute de burn, ce décalage peut valoir 1 m/s, parfois plus, parfois moins. En arrivant au bout de la manœuvre, si l’indicateur bleu se décale, vous pouvez le suivre ! Mais pour cela encore faut-il en avoir le temps… Baisser les gaz en fin de manœuvre permet justement d’être assez réactif.
On avait prévu d’agrandir l’orbite entière et non seulement de former cette ellipse, donc on va valider / supprimer l’actuel nœud de manœuvre pour en poser un nouveau au niveau de l’apogée et c’est parti pour une nouvelle configuration permettant de rehausser le périgée autour de 500km également : vous ne devriez avoir besoin de ne toucher qu’au prograde et pas au reste, ‘tention, I’m watching you !
On effectue la manœuvre en se rendant un peu avant le point, on allume les propulseurs à 100% lorsqu’on arrive à la moitié de la prédiction, et on surveille la jauge et les valeurs pour ne pas dépasser 😉 Et hop ! Vous voilà en orbite élargie à partir de deux manœuvres successives simples. Avec de l’habitude, c’est une manipulation qui ne vous prendra plus que quelques secondes à chaque fois !
A noter que lorsqu’une manœuvre demande très peu d’énergie, comme par exemple pour une légère correction d’orbite, il est possible d’exploiter quelques astuces pour anticiper une éventuelle imprécision. En effet, qui dit très peu de DV, dit injection très courte, avec la nécessité de grimper à 100% de vitesse, suivre l’indicateur bleu, et couper les gaz, le tout parfois en moins de deux secondes… Voyons comment arranger cela ! Pratiquement tout repose sur un simple petit principe : multiplier le temps de burn en baissant les gaz : si l’estimation est donnée en fonction du dernier burn à 100%... autant réduire à 25% l’injection ! Cela augmente théoriquement la durée nécessaire d’un facteur 4 avec les bénéfices suivants :
Cela vous laisse le temps de gérer la fin de manœuvre, à savoir baisser les gaz au plus bas pour ajuster à 0.1 m/s près.
Suivre l’indicateur bleu s’il se décale afin d’aller au bout du bout de la manœuvre et ne pas le laisser s’échapper dans la précipitation.
Montée en puissance plus courte, moins d’imprécision si vous n’aimez pas allumer à pleine puissance directement (question de réalisme et de résistance à l’accélération de certains ensembles fragiles) : le temps de montée en puissance n’est pas compté dans l’estimation, et il faut plus d’une seconde, normalement, pour atteindre les 100%, pas négligeable ! A 25% de puissance max, ce seuil est atteint bien plus rapidement, de même pour la coupure progressive. Mais là, on cherche les détails :p
En bref, retrouver le temps d’effectuer une bonne manœuvre précise, même quand elle est terriblement courte 😉 Cette « méthode » sera suffisante dans 90% des cas, tout à fait valide et pertinente, pas d’inquiétude. Mais on peut aller encore un peu plus loin…
Quand on pousse prograde en un point de l’orbite, on gagne en vitesse et on élargit le point opposé. C’est exactement ce que l’on a cherché à faire dans notre exemple, augmenter l’altitude d’un point pour former une ellipse, puis injecter au sommet de cette ellipse pour rehausser le point le plus bas, parfaitement à l’opposé. Malheureusement, quand une manœuvre demande une minute, cela signifie que l’on va passer du temps à brûler un peu en dehors du point. 30 secondes avant et 30 secondes après, cela reste cohérent, on peut voir géométriquement qu’on reste au voisinage immédiat. Mais imaginez une manœuvre de 20 minutes autour de Kerbin qui demanderait donc de bruler 10 minutes avant et 10 minutes derrière ? On commencerait et terminerait l’injection presque un quart d’orbite en décalage avec le point configuré ! Ça n’a presque plus de sens, et on dépense beaucoup d’énergie à rehausser des « opposés d’orbite » dont on n’a pas besoin. Le bilan sera une manœuvre bien plus couteuse qu’à l’estimation : par exemple de 300 m/s annoncé, on dépenserait en vérité plus de 400 m/s, ce n’est pas négligeable !
De fait, la compréhension de ce phénomène est géométrique. Comme on l’évoquait, 20 minutes de temps de manœuvre en orbite basse de Kerbin, ça n’a pas grand sens. Mais la même chose en orbite de Kerbol, le soleil du jeu, devient parfaitement normal et classique… Pourquoi ?
Eh bien une révolution autour de Kerbol prend plus de 500 jours là ou une orbite basse autour de Kerbin est bouclée en 40 minutes ! Les échelles n’ont rien à voir, si bien que 20 minutes sont comparables à un minuscule point sur l’orbite autour de Kerbol, et on rejoint l’estimation impulsionnelle de la manœuvre, désormais correcte. Il convient donc de vérifier qu’une manœuvre programmée est cohérente d’un point de vue temps d’exécution. Autour de Kerbin en orbite basse, mieux vaut éviter les burns de plus de 6-10 minutes grand max. Autour de Kerbol, pas de limite, vous auriez du mal à atteindre 20h de burn et je ne vous le souhaite pas 😀 Il est donc parfois nécessaire de réévaluer légèrement à la hausse la valeur annoncée (et donc le temps de burn) si votre manœuvre semble déraisonnablement longue au vue de la trajectoire sur laquelle vous évoluez. A noter qu’il est également tout à fait possible de découper une manœuvre en 2 burns ! Pour s’échapper de Kerbin par exemple, un burn de 5 minutes qui rehausse l’apo, on coupe l’injection, et une révolution plus tard on remet les gaz au niveau du périgée pour compléter 🙂
Mais ce n’est pas la seule subtilité liée à l’exécution d’une manœuvre. Nous avons statué sur le fait qu’un point de manœuvre était une sorte de petit calculateur, qui estimait tout plein de chose dont le temps requis. Ce calcul se fait sur la base des données dont le jeu dispose, à savoir… Votre module au moment de la configuration, sa masse, sa puissance de propulsion, essentiellement. De fait, cela ne prend pas en compte que pendant l’injection elle-même, le module va consommer du carburant, perdre en masse et donc gagner en TWR (rapport puissance / poids, pour rappel) ! TWR qui, s’il augmente, raccourci le temps de la manœuvre : le module prendra moins de temps à glaner X m/s de manœuvre à la fin, après avoir consommé une partie de son carburant, qu’au début !
Cela induit une nouvelle erreur, plutôt en notre faveur cette fois, avec une durée réelle légèrement moindre. Attention, cela ne prend réellement effet qu’au cours de longues manœuvres énergivores qui vous amèneront à consommer une fraction importante de votre fuel, la moitié par exemple. Si vous effectuez une manœuvre de 100 m/s alors que votre vaisseau en contient 4000, la différence passera inaperçue ! Tout est affaire de proportion. Avec le module proposé dans la SAVE, les deux manœuvres précédentes ne nécessitaient par exemple aucun ajustement.
Dans ces deux cas, la correction se fait… Au pif. Ou plutôt : à l’expérience. Le jeu ne prenant pas en compte ces deux incertitudes, à vous de voir si vous souhaitez plancher sur de fastidieuses mathématiques, ou simplement vous dire… « 3’30’’ minutes de burn depuis Kerbin ? Ça le fait, ce n’est pas trop long, je peux le faire en une fois. Par contre, ça fait 1800 m/s pour me rendre sur Jool et dépenser pratiquement tout mon carburant avec pour conséquence une réduction drastique de la masse de mon vaisseau ?! Mmh, allez, visons plutôt 3’00’’ ! » Bien sûr, les mathématiques vous permettraient de préciser tout cela, mais nous n’allons pas aborder ces méthodes de calculs dans ce tuto.
On pourrait même encore ajouter qu’il faut théoriquement passer un peu plus de temps d’injection avant le point de manœuvre qu’après, compte tenu de l’allégement de ce dernier, le barycentre n’est plus au centre. Mais là, c’est vraiment pour pinailler 😉
EDIT : Depuis la 1.5.1, cela n’est plus vrai, le jeu intègre enfin la perte de masse à son calcul et vous pouvez donc faire pleinement confiance à l’estimation de temps ! Mais cet aparté reste intéressant, vous aurez l’information pour les versions antécédentes et ça vous permettra de vous familiariser avec les notions de TWR, entre autre :p De même, depuis la 1.5.1, le jeu prend en compte les étages à venir : si l’étage en cours n’est pas suffisant pour terminer la manœuvre, le calcul utilise les caractéristiques du prochain staging et vous montre un découpage sur la jauge. Pratique !
IV) APPLICATIONS, CONSEILS ET ASTUCES
Vous avez déjà probablement entendu parler des inclinaisons relatives entre les orbites. Mais si. Non ? Hé ben c'est parti ! Utilisez le module qui porte le doux nom de "KSC - Sl'G4 - Station Orbitale" qui évolue en orbite de Kerbin à l'altitude géostationnaire, oui, mais avec une petite inclinaison d'orbite par rapport à la Mun, quelques degrés que nous allons tâcher d'annuler, et que nous pouvons voir depuis la tranche sur le gif ci-contre.
Sélectionner la Mun comme cible, puis constatez l'apparition de deux nouveaux indicateurs verts, les Ascending Nodes (AN) et Descending Nodes (DN) qui matérialisent les points charnières entre les orbites, ce qui est bien visible quand on regarde à nouveau par la tranche. Cela ne nous plait pas, la station a subi des avaries mais était supposée orbiter proprement dans le plan équatorial, c'est donc la Mun qui va nous servir de repère, tout simplement, et ce sera souvent le cas dans vos parties !
Hé ben go, comment qu'on fait ? On place très simplement un noeud de manoeuvre sur l'un des points charnières et on tire sur l'une des deux poignées roses jusqu'à ramener la valeur de l'angle à 0°. On rappelle qu'il est possible de maintenir l'affichage d'un indicateur en faisant un simple clic droit dessus ! Lorsque c'est fait, il ne vous reste plus qu'à réaliser la manœuvre grace au propulseur et carburant d'appoint embarqué sur cette petite station. Vous savez faire, désormais !
Ils restent encore beaucoup de chose à évoquer concernant les points de manœuvre et notamment la possibilité de déplacer un nœud en entier, le faire bouger sur l’orbite de votre module ! Pour cela, rien de plus simple, il suffit de cliquer en son centre, en évitant les poignées de couleurs, et de le faire glisser sur la trajectoire. En quoi cela peut être utile ? Eh bien pour intercepter la Mun ou toute autre cible ! Jusqu’à présent, nous évoquions des modifications d’orbite, sans objectif particulier, autre que de faire varier la géométrie de notre trajectoire. Mais les nœuds de manœuvres sont utiles sinon indispensables dans toute tentative de rallier une cible ! Et dans ce genre de situation, il n’est plus permis de poser votre nœud où bon vous semble, il devient capital de générer une impulsion en un endroit précis.
Pour la mise en pratique de ce tuto, nous allons prendre le cas concret de la rencontre avec Mun. Profitez du module nommé « KSC – Sl’G4 – MunAR 200km » dans la SAVE fournie. Vous pouvez bien sur utiliser n’importe quel craft de votre partie, en orbite équatoriale globalement circulaire autour de Kerbin, mais rappelez-vous que pour rejoindre une cible il est clairement préférable de d'abord vous aligner dans son plan orbital, étape que nous venons d'expliquer juste au dessus ! Posez un point de manœuvre n’importe où sur la trajectoire en bleu, et tirez le vecteur prograde (rond vert) jusqu’à obtenir une tangence entre l’ellipse projetée en pointillé et l’orbite de la Mun, en bougeant la caméra pour vous en assurer, comme ci-dessous :
Si vous voyez tout plein de couleurs au niveau de Mun justement, c’est que vous êtes déjà à peu près au bon endroit… Coup de chance :p Mais prenez soin de glisser votre point de manœuvre comme nous venons de l’apprendre, pour obtenir une ellipse « normale », comme sur l’image ci-dessus.
Cette manœuvre programmée, c’est la trajectoire idéale en terme d’efficacité pour rejoindre Mun : imaginez votre petit module parcourir la phase ascendante de l’ellipse et pile au sommet, là où sa vitesse est la plus faible (pensez à un ballon que l’on lance en l’air et qui ralentit… Avant de retomber), PAF ! La Mun ! Vous arriveriez pile à l’équateur, pile dans le bon sens, et avec le moins d’énergie à annuler.
Reste qu’à cet instant, la Mun ne sera pas au rendez-vous… La manœuvre est bonne, belle amplitude, optimisée, vous avez le DeltaV, mais son emplacement n'est pas bon. On va donc pouvoir glisser le nœud comme expliqué précédemment : cliquez entre les poignées colorées et déplacer la manœuvre, lentement, le long de la trajectoire. Vous devriez subitement obtenir tout plein de couleurs comme ici !
Cette fois, cela signifie que notre manœuvre préalablement configurée, se trouve au bon emplacement : la Mun, alors encore « en retard », va se déplacer pendant notre ascension le long de l’ellipse et à l’issue, elle se retrouvera au même endroit que nous, à l’apogée : vous venez de programmer l’interception de la Mun. C’est l’occasion de glisser un peu le nœud au voisinage de là où il se trouve pour contempler l’effet sur les trajectoires qui se dessinent.
Le nouveau panel introduit en version 1.7 est d’ailleurs très utile pour bouger le nœud de manœuvre par petits incréments, en ajustant la précision avec la jauge. De la sorte vous pouvez observer quel emplacement du nœud semble être idéal pour parvenir à votre résultat escompté, et dans notre cas il s’agira de passer à proximité de la Mun, sans s’y crasher, et avec une trajectoire de sortie qui nous éjecte du système. Essayez d’obtenir quelque chose qui ressemble au gif ci-dessous, sans retoucher aux poignées du point de manœuvre, seulement en le faisant glisser avec précision :p
On a pu voir qu’un point de manœuvre générait une courbe en pointillés orange, celle de l’estimation de notre trajectoire si l’on exécute la manœuvre. Ici, en interceptant la sphère d’influence de Mun, de nouvelles trajectoires se dessinent : elles sont les résultats de l’interaction gravitationnelle de Mun avec notre module et sa trajectoire. En bref, notre trajectoire est celle en pointillé telle que nous la connaissons, jusqu’à ce qu’elle soit impactée par la proximité de la Mun qui va forcément l’attirer à elle par gravité, déformant sa courbe. Heureusement, le jeu est capable de simuler cette interaction et de dessiner pour nous la nouvelle trajectoire dans la sphère d'influence de la Mun : la trajectoire devient alors violette et c’est elle qui prend le relais. Elle ira même jusqu'à passer au vert, témoignant de votre trajectoire en sortie du système Munaire, lorsque vous retournez dans l'influence de Kerbin ! Si c'est pas fou, tout ça, hein, ma bonne dame.
Tentez de reproduire la situation ci-dessus, en ajustant les axes et la position du nœud, par petites touches. Normalement, les orbites sont parfaitement alignées, vous ne devriez avoir à utiliser que la poignée prograde, rond vert. Si vous êtes perdu, effacez le nœud complet, et reproduisez les étapes précédentes, pas de panique, ça se fait tranquillou, ça demande juste un peu de pratique 🙂 Pour mettre quelques mots sur l'image qui suit, vous devez : intercepter la sphère d'influence de la Mun, en passant par l'extérieur, ce qui vous donnera tellement de vitesse par effet de catapulte gravitationnelle, que vous serez éjecté du système Kerbinien, avec le petit symbole "Kerbin Escape" en bout de trajectoire !
Reprenons en synthèse ce que l’on peut voir dans l’image qui précède :
Pointillés orange : notre manœuvre au niveau de Kerbin nous amène à une belle ellipse qui croise Mun
Violet : l’interaction de Mun déforme notre trajectoire et l’accélère, formant une véritable catapulte gravitationnelle ou slingshot, en anglais, courbant fortement notre trajectoire de base
Vert : en sortant de la Sphère d’Influence de Mun (SOI = Sphere Of Influence in English !) le module aura tellement d’énergie qu’il sera expulsé du système Kerbinien ! On peut voir qu’au bout la trajectoire est interrompue et en survolant à la souris on peut lire « Kerbin Escape »
C’est-à-dire qu’en apportant environ 900 m/s au niveau de Kerbin, en une seule manœuvre on va passer à proximité de Mun, l’occasion de faire des relevés de science par exemple, et on va être expulsé du système alors qu’en temps normal une telle manœuvre aurait dû coûter quelques 100 m/s de plus ! C’est le pouvoir du point de manœuvre, la possibilité de projeter une simulation, d’essayer des choses, et ensuite de le concrétiser avec une estimation du DV, du temps, etc.
Ce n’est pas tout. Conservons encore un peu cette configuration et ajoutons, tenez-vous bien, un point de manœuvre… Sur le Periapsis a proximité de la Mun. Oui oui, c’est possible ! On va pouvoir programmer un nœud sur une courbe qui n’existe encore que fictivement, pour tester des combinaisons complexes. Par exemple dans notre cas, on va chercher à casser notre vitesse d'arrivée aux abord de la Mun pour nous mettre en orbite et éviter d'être éjecté. Pour cela, il suffit de tirer un peu sur la poignée rétrograde (Croix Verte) jusqu’à obtenir une orbite autour de la Mun :
On comprend ici, qu’après avoir injecté en orbite autour de Kerbin, on ira frôler Mun, freiner fort, ce qui aura pour conséquence de nous mettre en orbite autour du satellite naturel. Et ça marche toujours comme ça : on injecte et on intercepte une cible, puis on freine a proximité pour diminuer la vitesse relative, et se stationner aux abord ou se positionner en orbite. Docking, interplanétaire, c'est tout un pan du jeu qui s'offre à vous rien qu'avec les nœuds de manœuvre !
Donc là, on a posé un nœud de manoeuvre sur une trajectoire virtuelle issue d'un nœud de manoeuvre... On a encore rien fait en fait, juste un peu d'estimation pour voir ce que ça donne, on est toujours coincé en orbite de Kerbin. Et on sait qu'une injection ne respecte jamais à 100% une prédiction, on peut donc supprimer la seconde manoeuvre, il sera plus intéressant de la repositionner une fois qu'on se sera réellement injection en direction de la Mun. Allez, hop, vous savez faire !
Prenez le temps de bien ajuster votre première manoeuvre pour viser un periapsis entre 20 et 50km. Rappelez-vous : si vous êtes dans le bon plan avec une inclinaison relative nulle (AN/DN, tout ça), vous ne devriez pas toucher à autre chose que le prograde et la position du nœud. Effectuez aussi proprement la manoeuvre que possible. Constatez la différence entre prédiction et votre résultats, et ajustez si nécessaire via... un nouveau point de manoeuvre, après être entré dans la SOI de la Mun !
Vous voila bien lancé, avec un Pe bien ajusté. Il est temps de poser le second point de manoeuvre au niveau du Periapsis, pour circulariser, en utilisant la poignée rétrograde bien sur. Pro-tip : vous pouvez directement regarder la valeur de l'Ap pour vous arrêter quand ça vous va, plutôt que la jauge de la manoeuvre, ça revient globalement au même quand vous savez ce que vous souhaitez atteindre précisément : ce serait con de terminer proprement la jauge alors qu'elle vous amène 10km plus bas que prévu, alors que vous pouviez directement couper les gaz quand l'Ap atteignait votre valeur 🙂
Et si... Et si, tant qu'à faire, on voyait l'utilisation des noeuds de manoeuvre dans le cas d'un Landing sur la Mun ? C'est un excellent outil pour un aspect en particulier que l'on va aborder quelques lignes plus bas. Pour le moment, contentez vous de poser puis configurer un point de manoeuvre de sorte à obtenir une courbe de descente vers la partie éclairée du sol de la Mun. Inutile de vous re-préciser qu'il faut agir sur la poignée rétrograde pour freiner n'est-ce pas ? 🙂
Là, votre sort est plus ou moins scellé, vous allez à la rencontre du sol. Que faire ? Freiner, encore freiner, pardi ! Réduire votre vitesse par rapport au sol. Maaaaais le plus tard possible, pour de raisons d'efficacité que nous ne détaillerons pas ici. On appelle ça le... Suicide Burn. Tadam. Z'allez voir, c'est excitant. Dans un premier temps, assurez vous que votre NavBall passe en mode "Surface", comme sur le gif ci-contre. Si ce n'est pas le cas, cliquez simplement sur la vitesse de la NavBall justement 🙂
Maintenant, vous allez poser un noeud de manoeuvre pile à l'endroit ou votre trajectoire touche le sol, zoomez au besoin. Puis vous allez tirer sur la poignée rétrograde : logique non ? Vous voulez freiner, enlever de la vitesse, c'est la poignée qu'il vous faut. Tirez jusqu'à ce que la parabole disparaisse sous le sol, mais pas davantage. Vous obtenez à droite de la NavBall le temps et la valeur en DeltaV de ce que représente ce SuicideBurn, le tout sand mod.
Stylé hein ? Reste à effectuer la manoeuvre et cette fois, cette fois, on ne va pas répartir le temps de part et d'autres du noeud, parce que... Ben, de l'autre côté, c'est le sol. Et la mort. Non, cette fois il vous faut dissiper toute l'énergie de la manoeuvre avant ! Idem, vous n'allez pas suivre l'indicateur bleu, mais bien le rétrograde cette fois, en activant la fonction de suivi associée, à gauche de la NavBall. Et mise à feu au bon moment !
Devinez quoi ? Je vais vous abandonner là :p Oui, ce tuto traite des manœuvres, et l'atterrissage n'en fait plus partie, en dehors de la petite astuce permettant de connaitre le temps de la décélération pour commencer au bon moment ! A vous de jouer, de tester, d'ajuster, pour peut être réaliser votre premier Landing Safe. Et si jamais ce n'est pas le cas, dites-vous bien qu'une carrière KSP sans avoir connu de mission de sauvetage, ça n'existe pas 😀 Bonne chance !
Conclusion
On résume ? Vous allez voir, ça tient en quelques lignes à peine 😉
Une manoeuvre, c'est une sorte de calculateur, un moyen d'afficher une estimation de trajectoire, pour dessiner ce que vous souhaitez réaliser et ensuite le concrétiser
Ca implique des pertes et imprécisions multiples mais qui restent bien contenues, et pour lesquelles nous avons des outils et astuces pour parvenir à nos fins
Les applications sont nombreuses, qu'il s'agisse de donner une forme à une orbite, ou de rejoindre une cible pour un docking, d'intercepter une lune, une planète
On peut même détourner son utilisation pour en faire une petite calculatrice permettant de savoir le temps d'une décélération dans cas d'un SuicideBurn ou autre
Toute la puissance du noeud de manoeuvre réside dans la compréhension de ses axes, de leur impact, et de votre patience pour faire proprement les choses. Avec la pratique, vous irez très très vite, et avec une grande précision, c'est une garantie !
1) Réaliser une manoeuvre de circularisation du module KSC - Sl'G4 - Mun'AR 100km à 500km d'altitude. Soyez précis ! Votre PE et votre AP doivent être entre 490 et 510km.
2) Réaliser la correction de plan du module KSC - Sl'G4 - Station Orbitale, pour rétablir son orbite sur l'équateur. Attention, son inclinaison ne doit pas dépasser 0.1° et son PE et AP doivent rester entre 2850 et 2870km ! Corrigez au besoin avec une nouvelle manoeuvre.
3) Réaliser l'interception de la Mun avec le module KSC - Sl'G4 - MunAR'200km : le PE doit être "derrière la Mun", et contenu entre 10 et 50km !
Cette rubrique vous présente quelques mods en relation directe avec la thématique du tutoriel. Sachez que le jeu est totalement auto-suffisant et qu'AUCUN mod ne saurait être indispensable. Toutefois la communauté des modders KSP est plutôt prolixe et propose des ajouts de qualités, qui pourraient convenir au GamePlay de certains d'entre vous 🙂 N'hésitez pas à les tester, en veillant à respecter la compatibilité des mods avec votre version KSP et en préparant des Backup autant que possible pour éviter toute sauvegarde compromise ! Pour l'installation des mods, se référer à l'article dédié, bien sur ! Nous avons des ressources, il faut en profiter.
Attention, nous ne garantissons pas la compatibilité de ces mods avec l'actuelle version du jeu ou votre propre installation ! C'est pour cela qu'il faut bien lire les liens vers lesquels nous renvoyons ^^ N'hésitez pas à demander un coup de main bien sur !
Kerbal Alarm Clock : ce mod vous permet de définir des alarmes pour ne pas louper une manoeuvre, une injection, une fenêtre. Il permet même de détecter des "évènements" pour simplifier la configuration des alarmes, comme l'approche d'un Apo / Péri, ou d'un AN/DN, etc.
Precise Node Continued : essentiel pour certains, il permet de configurer très précisément une manoeuvre. Son utilisation est néanmoins mitigée par la nouvelle intégration du panel manoeuvre au sein du jeu stock depuis la 1.7.1 !
Maneuver Node Evolved : ici, il s'agit plutôt d'une aide à la pose des nœuds de manoeuvre directement sur les points d'intérêt, comme les closest approachs, ou d'autres points caractéristiques de votre orbite. Il y a de nouveau quelques outils pour l'ajustement précis d'une manoeuvre.
MechJeb : the aaaaaaallmighty MechJeb ! Vous n'en avez jamais entendu parler ? Really ? C'est le mod à tout faire, un outil d'AutoPilot (mais pas que !) formidable et au cœur d'un débat qui ne connait pas fin : "ça s'rait pas d'la triche, quand même ?" On ne peut que vous recommander de d'abord maitriser la mise en orbite sans MJ, sans quoi vous passez à côté d'une belle facette du jeu 🙂
BetterBurnTime : dans l'esprit de ce que l'on aborde dans cette fin de tutoriel, ce mod vous affiche automatiquement des informations selon le contexte : le temps avant impact au sol par exemple, ou celui avant une rencontre en orbite après avoir déclarer une cible, etc.
Et comme d'habitude, pour réagir à cet article, cela se passe sur le topic dédié du forum !
Un challenge sans contrainte ni objectif, ce n’est pas drôle ! Tout l’objet de cet article est de façonner un contexte commun, qui délimite les participations, pour que l’on soit tous confrontés aux mêmes enjeux, aux mêmes difficultés, et que l’on puisse échanger, s’entraider. Pas facile car il est également important de vous laisser suffisamment de marge de manœuvre pour inventer, créer, et nous surprendre ! Allez c’est parti, dans l’ordre et avec attention, on parcourt les quelques rubriques qui suivent pour ne rien louper 🙂 On pourrait croire que c’est long alors que… Pas du tout, en 5-10 min c’est réglé ! C’est juste que TOUTES les informations sont présentes, comme ça, pas de zone d’ombre… Let’s go ?
Première étape importante, vous inscrire via le formulaire ! Cela vous permet notamment de sélectionner votre catégorie de participation, un concept qui nous est cher et qui garantit à chacun d’y trouver son compte tout en préservant la possibilité d’évaluer vos participations correctement. Débutants notamment, n’hésitez pas à tenter l’aventure en profitant de la catégorie Juniors ! Vous disposerez bien sûr de l’aide de la communauté mais également d’un support personnalisé du Staff qui pourra débloquer une situation, partager un craft, une sauvegarde, etc. On a rarement vu plus rapide pour progresser 😉
Les DeVinci trouveront leur bonheur dans la marge de créativité que nous laissons aux participants : l'ingéniosité et l'innovation seront les maitres-mots de cette catégorie ! Les historiques seront quant à eux davantage tournés vers la reproduction fidèle de la mission, tant sur la conception des crafts que les trajectoires adoptées : y'a du boulot :p Les duos, enfin, peuvent comme le nom l'indique, rendre un dossier en binôme, avec la liberté de piocher dans les objectifs des autres catégories, en le précisant bien.
Pensez aussi à la catégorie Alacool, qui vous permet de participer sans prise de tête, avec les mods que vous souhaitez, vos propres contraintes, etc ! Profitez simplement du contexte et de l’évènement pour vous y rattacher, et si l’envie vous prend de nous envoyer un dossier à votre sauce, il est le bienvenu ! Cette catégorie reste un peu en marge de l’organisation générale du Challenge et n’est pas éligible par défaut à une évaluation du staff ou aux Goodies. Mais on a tendance à être cool :p
INSTALLATON KSP ET MODS
Votre participation impose d’avoir une installation dédiée afin de profiter au mieux du Challenge. Il est donc primordial de suivre ce petit guide pour disposer d’un dossier KSP 1.8.1 tout propre ! Cette version est actuellement celle qui supporte de loin le plus de mods de façon stable. Nos évènements utilisent également quelques mods obligatoires, le moins possible pour faciliter l’accessibilité. Nous ne proposons plus de « ModPack » pour être totalement conforme aux conditions des créateurs que nous comprenons, mais nous assurons bien sur le support pour vous aider si vous rencontrez des difficultés 🙂 Pour une installation manuelle, visitez les liens que nous donnons, et utilisez notre petit guide !
Les mods autorisés sont plus nombreux que par le passé, et englobent parfois tout ceux répondant à une définition / formulation plutôt qu’une liste qui ne serait jamais exhaustive : nous vous demandons de jouer le jeu de l’honnêteté et de ne pas chercher à flouer le staff et les autres participants en glissant des parts / fonctionnalités non autorisées ou en jouant sur les mots ! Une image (honnête, à nouveau ^^) de votre GameData sera demandée dans le dossier, et nous devons pouvoir ouvrir vos Saves et Crafts 😉 On compte sur vous ! Est-il nécessaire de préciser en préambule qu'il est de votre responsabilité de bien installer un mod non-obligatoire, en vérifiant sa compatibilité avec la version KSP utilisée ainsi que les dépendances exigées ? ^^ Bon jeu !
KSRSS : Kerbal Size Real Solar System, le fameux mod qui permet de retrouver toutes les planètes de notre système solaire et la plupart de leurs lunes, tout en conservant des échelles de distances compatibles avec les parts par défaut. La Terre est au diamètre de Kerbin, et le reste est ajusté en conséquence ! Nous utilisons désormais un mod développé par la communauté Francophone et vous en avez sans doute déjà entendu parler, merci à la KSRSS-Team : Kierra, Tony48, Natsukira, Fitz, Rezza et Invaderchaos pour cette petite gemme. Un guide très complet et éprouvé vous permet de l'installer et d'en personnaliser l'aspect.
Deadly Reentry : Un must-have point de vue réalisme pour que les réentrées atmosphériques soient palpitantes ! Absolument rien d’impossible ou de compliqué, pensez seulement à mettre un bouclier et à soigner un peu votre trajectoire d’interception.
Mods graphiques : tous les mods impactant les graphismes du jeu sont autorisés tant qu’ils n’interfèrent absolument pas avec la physique et le GamePlay en général. Concernant KSRSS, vous utiliserez naturellement KSRSSVE qui est inclus dans le processus d’installation, mais vous pouvez par exemple ajouter les mods tel que Engine Lightning Relit ou Distant Object Enhancement.
Mods de Reskin / Revamp / Decals / Peinture : tous les mods permettant d’améliorer l’apparence des parts STOCK sont autorisés, à condition qu’ils n’altèrent en rien les caractéristiques et n’introduisent pas de parts en plus en dehors des Décalcomanies. Par exemple, ReStock et Decalc'o'mania sont autorisés, mais Restock+ ne l’est pas.
Mods d’informations et de confort en vol : seuls les mods KER, TWP, KAC et Trajectories sont autorisés pour ce challenge, permettant de dispenser une information intéressante et pertinente, sans dénaturer l’expérience de jeu.
Mods « dans le VAB » : l’ensemble des mods permettant une conception simplifiée via l’apport d’informations intéressantes tel que HangarExtender, HangarGrid, RCSBuildAid.
Mods de fonctionnalités tierces : l’ensemble des mods qui servent une fonction n’altérant pas l’expérience de jeu, la physique ou les performances des parts, comme les mods de prises de vues (y compris celles ajoutant des parts caméra sur les crafts), VaporVent, etc. KJR-Next fait figure d'exception, il est autorisé malgré son impact sur la physique, car il s'agit d'une dépendance à certains mods et son fonctionnement est plus intelligent qu'il ne l'était à l'époque. Les habitués n'auront plus matière à râler :p !
DLC et mods impactants : les DLCs sont autorisés, de même que tout ou partie d’un mod permettant d’intégrer les systèmes robotiques de types bras, articulations, moteurs électriques. Cela inclus par exemple InfernalRobotics et ses dépendances, ou encore FireSpitter s’il est question d’utiliser les moteurs à hélices. KAS est d'ailleurs autorisé uniquement pour la partie Grapin + Point d'attache, afin de reproduire la phase finale de dépose du Rover par le Skycrane, pour ceux qui le souhaiteraient ! Cette catégorie de mods autorisés est difficile à totalement cerner, nous comptons sur vous pour en rester à ces définitions et nous consulter au besoin.
Mise à l'échelle : l'échelle de base de participation est Stock, c'est à dire environ 1/10 de ce que nous connaissons IRL. Cela permet à tous de participer avec les Parts Vanilla. Néanmoins, il est désormais toléré de jouer en échelle KSRSS x2.5 (via l'installation de Sigma Dimensions) mais cela n'aura absolument aucun impact en terme d'évaluation, ni positive, ni négative, et aucun autre mod que la liste qui précède n'est admis pour compenser l'échelle : x2.5 est parfaitement jouable en Stock (+ TweakScale pour ceux qui veulent). Attention ça reste un peu WIP ! Et le KSC est parfois pas tout à fait bien positionné 😉 A vos risques et périls donc !
MODALITES DU CHALLENGE
Le challenge débute à la publication de cet article, au décollage de la mission Mars 2020, c’est-à-dire le 30/07/2020 et prend fin le 15/10/2020, date maximale à laquelle il vous faudra nous envoyer votre dossier compressé sur notre adresse officielle (contact@kerbalspacechallenge.fr) au format .zip par WeTransfer, un service bien connu qui ne nécessite pas d’inscription. Pratique !
Nous insistons : vous avez le temps, prenez-le. Voyez ce challenge comme la possibilité d’exercer votre passion et de la partager avec les autres membres, faites-nous ressentir ce qui vous fait vibrer, sentez-vous libre de joindre à votre dossier de participation toutes les pièces pertinentes que vous avez pu créer, qu’il s’agisse de mathématiques, de tableurs Excel, de poésies, d’illustrations, de vidéos… Vraiment, c’est votre dossier. Attention néanmoins, désormais nous appliquons quelques limites max pour vous amener à un contenu plus synthétique afin d’alléger la lecture et en particulier de ne pas exploser le temps libre du staff en phase de relecture : rapport 40 pages + 30 images (hors rapport, en complément) + 15 min de vidéo + 2 documents (PPT / Excel / …). Forcément, tout dépend de la pièce principale de votre dossier, hein ? Si vous faites une vidéo en tant que pièce principale, elle peut faire 30-40 minutes, par exemple. C’est plutôt indicateur, vous avez compris l’idée ^^ Merci 😀 !
Nous vous demandons en parallèle une image (honnête hein ?) du GameData de votre installation, ainsi que vos crafts et sauvegardes utilisées dans le cadre de ce Challenge. Vous pouvez trouver tout cela très simplement en suivant ce petit guide ^^. Merci de préparer un petit fichier texte en complément donnant quelques infos essentielles sur vos crafts au départ de la mission : masse, poussée, taille, nombre de parts, au minimum ! Cela nous aide grandement, notamment pour compiler la magnifique infographie de cloture de Challenge 😉
Le respect des objectifs : soulignez bien quand tel ou tel aspect de votre dossier permet de valider une exigence du CDC, c’est important ! Et ça vous permet de checker et éventuellement argumenter sur une réussite / un échec ^^
L’originalité : étonnez-nous ! Par le format, par le contenu, il y a plein de façons de nous surprendre, il n’y a qu’à voir les participations précédentes ^^ Faites-vous plaisir, et avec ce que vous maitrisez le mieux.
L’aspect pédagogique / vulgarisation : pensez à expliquer vos démarches autant que possible, à vulgariser, essayez de sensibiliser les gens qui liront vos lignes, regarderont vos schémas, parcourront vos équations 🙂
La cohérence avec les autres éléments de votre dossier : liez les pièces entre elles, construisez un dossier cohérent, avec des éléments qui font appel les uns aux autres. Envisagez un (mini ?) document qui explique votre démarche et le rôle de chaque pièce de votre archive !
La synthèse : quelles informations sont essentielles, quelles sont celles que vous souhaitez mettre en avant, qui feront sortir votre dossier du lot ? Attention aux limites max décrites juste au-dessus, mais ça laisse de la marge 🙂
LES OBJECTIFS DE LA MISSION !
Ces objectifs sont volontairement brefs et synthétiques, parfois même évasifs : nous tenons à ce que vous puissiez avoir une part d’interprétation mais aussi et surtout à ne pas empiéter sur vos recherches personnelles au sujet de la mission : elle regorge de bien des détails que certains auront la fierté de mettre en avant dans leur dossier, et nous souhaitons préserver cela 🙂
Les challenges proposent une trame complète et « généreuse », les objectifs sont nombreux. Notre évaluation se base naturellement sur cette grille mais il va de soi que vous pouvez « sauter » une étape pour profiter de la suite de l’aventure, sans souci ! Ne restez pas bloqué à vouloir remplir l’ensemble des objectifs, faites-vous plaisir et n’hésitez pas à parler de vos difficultés ou de vos choix de passer outre certains aspects, dans votre dossier. Un challenge réussi, c’est un challenge que vous avez su relever jusqu’au bout, avec fierté, un millésime dans votre carrière KSP ^^ Tous nos participants sont fiers des dossiers qu’ils ont su remettre et dont nous reparlons régulièrement. A toi de jouer !
Conception des crafts
Juniors
2 étages centraux liquide et utilisation de boosters à poudre : on est sur de l'architecture classique !
DeVinci
Au moins 2 designs complets à destination de Mars ! Faites vous plaisir en termes de créativité 🙂
Historique
Reproduction des lanceurs Atlas 5, Vulcan et Ariane 6 ! Beau programme côté conception ^^
Décollage et mise en orbite
Juniors
On vise l'orbite stable, celle qui n'entre pas dans l'atmosphère et ne sort pas de la Sphère d'Influence
DeVinci
Orbites circulaires ou présentant un aspect intéressant, à illustrer / évoquer dans votre dossier
Historique
Décollage et transfert direct vers Mars !... Good luck, les faibles inclinaisons des orbites sont appréciables ^^
Transfert vers Mars
Juniors
Interception de la planète rouge
DeVinci
Interception de la planète rouge
Historique
Interception de la planète rouge
Atterrissage sur mars
Juniors
Orbite stable histoire de temporiser et atterrissage sur la face éclairée, en douceur
DeVinci
Au moins un landing côté jour de Mars ! Parlez-nous de votre (vos ?) site d'atterrissage choisis :p
Historique
Ré-entrée et landing direct côté jour, au voisinage du cratère Jezero
Sciences !
Juniors
Prise d'échantillon au sol de Mars : pensez RolePlay 🙂
DeVinci
Prise d'échantillon au sol de Mars et d'une des deux lunes
Historique
Prise d'échantillon au sol de Mars à l'aide d'une reproduction de Perseverance
Retour des échantillons
Juniors
Capsule de retour des échantillons qui revient au sol de la Terre avec succès ! C'est à dire sans casse, hein ?
DeVinci
Vous connaissez le film "Life" ? Garantissez l'inocuité des échantillons en passant par une station orbitale avant retour sur Terre !
Historique
Utilisation d'un second rover pour récupérer les échantillons, d'un micro-lanceur martien et d'un orbiteur de retour vers la Terre
Pour conclure cet article qui lance officiellement le déroulement du challenge KSC6 – MarsSampleReturn, nous tenons à vous rappeler que l’objectif n’est pas tant la compétition envers les autres que le sens du partage et de la communication : nous vous proposons un contexte et un support commun, KSP, c’est l’occasion idéale d’échanger avec les autres membres, qu’ils soient participants à ce challenge ou non, avec le staff, ou même avec des personnes extérieures ! Vous disposez d’un forum regroupant tout plein de catégories de discussions afin d’avoir un cadre de communication aux petits oignons : une section est d’ailleurs dédiée au déroulement des challenges, de quoi retrouver les autres joueurs et s’entraider, ou encore bavarder sur telles ou telles déconvenues / anecdotes. Vous pouvez aussi retrouver la communauté en direct sur notre Discord très actif ! Faites vivre nos challenges, appropriez-les-vous, et n’hésitez pas à nous faire savoir si ça vous plaît, en partageant sur les réseaux sociaux avec le Hashtag #KSC6MSR 🙂
Le Challenge KSC5 – CassiniTitan est désormais clôturé depuis 2 semaines et nous vous avions promis dans ce délai la mise à disposition des dossiers que les participants ont su soumettre à notre lecture dans les temps impartis ! Une belle occasion pour dévoiler le visuel officiel du Challenge par l’ami Alex, que nous trouvons absolument superbe ! Et vous ? 😀
Mais avant, petite rétrospective sur ce 5ème Challenge de l’association Kerbal Space Challenge. Prenant place dans un contexte un peu particulier puisque intégralement déroulé lors du COVID-19 qui a frappé le monde, ces 45 jours de participations n’ont ressemblé à aucun autre et nous espérons que cet évènement aura su occuper les plus isolés : c’est en général une fenêtre de tir toute particulière pour resserrer les liens de la communauté existante mais également pour faire découvrir l’initiative à ceux qui ne nous connaissaient pas encore. D’ailleurs, le nouveau Discord a vu le jour pendant cette période avec un succès retentissant, un grand merci à vous tous qui avez joué le jeu sur ce point ! Vous n’avez jamais été si actifs et passionnés 🙂
Revenons-en au challenge : avec 14 participations, nous n’explosons pas les standards malgré un nombre record d’inscriptions au lancement et pendant les premières semaines, quelques 40 motivés ! Nous avons eu l’occasion d’en parler avec pas mal d’entre vous, aussi bien sur le Forum, le Discord, que sur Twitter, où les personnalités et profils varient en profondeur. Il en ressort que la période COVID envisagée comme une parenthèse dans nos vies laissant pas mal de temps libre, en fut tout autrement pour nombre d’entre vous, notamment les étudiants mais également les professionnels. Passer l’essentiel de son temps devant l’ordinateur en télé-travail ou en télé-étude (on valide le terme ?) ne motive pas plus que cela à poursuivre en soirée, il fallait maintenir les rares contacts sociaux encore possibles et bien sur laisser reposer les yeux, penser à autre chose, déconnecter.
Au delà de ces aspects pratiques, la thématique Cassini-Huygens-Dragonfly que nous avions résumé à « CassiniTitan », revêtait son lot de complexités au sein du jeu et dans la confection des dossiers. Mission mythique et très complète, qui aura probablement refroidi les ardeurs de certains à la lecture du « cahier des charges », les joueurs nous ont confié vouloir à tout prix réussir l’intégralité des étapes, qui ne sont pourtant qu’une grille d’objectifs permettant de guider l’aventure avec quelques jalons bien définis. C’est probablement le niveau des dossiers existants qui a suscité cette exigence des joueurs envers eux-mêmes et nous souhaitons réinsister sur ce point : ces event doivent vous rendre fier vous et seulement vous dans un premier temps. Il va de soit qu’un joueur débutant ou même un confirmé n’ayant jamais réalisé d’assistances gravitationnelle, peut compléter l’expérience du Challenge sans en réussir une de ses étapes, bien sur ! Cela compte dans l’évaluation que nous en faisons, mais ce n’est qu’un « bonus » à votre aventure, notre retour n’est pas une finalité en soit, pas plus que le classement ou la comparaison avec les autres. Voyez plutôt cela comme un millésime, la représentation à telle date de ce que vous avez su faire et proposer dans KSP, en allant jusqu’à proposer un dossier qui vous ressemble, qu’il soit simple ou élaboré, c’est le vôtre ! Et vous aurez comme objectif naturel de faire mieux la prochaine fois. Un joueur découvrant le jeu avec plaisir aux côtés de la communauté n’a vraiment pas de raison de s’imposer la tenue de tous les objectifs 😉
Lors d’un Live sur notre Discord à la cloture du Challenge, nous avons pu approfondir ces éléments pour chercher à comprendre ce qui pouvait bloquer des participations, ce qui pourrait être amélioré. Tout cela fera probablement l’objet d’un article dédié, et nous vous remercions de vos retours ! Bien sur, nous considérons que 14 dossiers de qualité demeure une réussite, une vraie, de celle qui nous rend fier d’avoir entrepris cela, et dont nous espérions qu’elle vous rend fier ! Beaucoup de choses sont en cours du côté de l’association, dont nous espérons qu’elles iront au bout et que vous devriez grandement apprécier, l’article de cloture prendra donc un peu de temps comme d’habitude, mais nous avons eu écho que nos retours étaient précieux pour la plupart d’entre vous et nous tenons à soigner cela 🙂 En attendant, voici les dossiers en libres accès ! Nous avons bien sur commencer à les parcourir et les éplucher, et nous pouvons d’ores et déjà annoncer que c’est du lourd, et… Et ce sera tout pour le moment :p Enjoy !
Comme d’hab’, pour en discuter tous ensemble, se féliciter, poser des questions, ça se passe en priorité sur le topic du forum qui va bien, pour que ce soit accessible à tous, et pourquoi pas dans un second temps sur le Discord !
Hé oui, le titre dit vrai, nous changeons de serveur Discord ! Avant d’en dire plus et pour ceux qui souhaiteraient nous rejoindre sur le nouveau serveur et ne pas oublier, c’est simple, c’est juste ici :
Nous souhaitons, aujourd’hui, faire évoluer notre discord. Malheureusement nous en avons perdu les pleins droits. En effet, son créateur à quitté l’association il y a 3 ans, et, sans nouvelle de sa part, nous n’avons pu récupérer l’ensemble des pouvoirs sur notre channel.
Nous en profitons bien sur sur pour re-façonner un peu le Discord, notamment en anticipant l’arrivée prochaine de KSP2 qui profitera d’une catégorie de canaux dédiés, cotoyant ceux de KSP1. Des nouveaux rôles sont également à votre disposition, avec toujours cet esprit d’entraide en tête et nous vous invitons à les découvrir directement sur place. Nous comptons vraiment sur vous pour simplifier cette démarche autant que possible, elle n’est pas évidente pour nous car nous savons que nous allons perdre un certain nombre de comptes peu actifs, qui ont néanmoins le mérite de donner une crédibilité et une visibilité au serveur. Vous pouvez nous aider très simplement en rejoignant dès à présent le nouveau serveur, en le partageant auprès de passionnés de KSP bien sur, et en relayant cet article à ceux qui ne comprendraient pas forcément et à des moments ou nous ne serions pas disponibles pour en parler 🙂
L’actuel Discord verra donc des annonces régulières pendant cette semaine, avec une cloture des salons en dehors du canal Annonces qui contiendra le lien vers le nouveau Discord et cet article ! Merci par avance pour votre compréhension, c’est une décision lourde et je suis sur que la communauté suivra. Nous vous disons à très bientôt sur le nouveau Discord 😉
Cet article fait suite à la présentation du challenge KSC5 – CassiniTitan que nous vous invitons à lire avant d’entamer ce cahier des charges 😉 D’ailleurs vous y trouverez le Teaser vidéo, allez y jeter un coup d’œil ^^
Un challenge sans contraintes ni objectifs, ce n’est pas drôle ! Tout l’objet de ce cahier des charges est de façonner un contexte commun, qui délimite les participations, pour que l’on soit tous confrontés aux mêmes enjeux, aux mêmes difficultés, et que l’on puisse échanger, s’entraider. Pas facile car il est également important de vous laisser suffisamment de marge de manœuvre pour inventer, créer, et nous surprendre ! Allez c’est parti, dans l’ordre et avec attention, on déroule les petits spoilers qui suivent pour ne rien louper 🙂 On pourrait croire que c’est long alors que… Pas du tout, en 5-10 min c’est réglé ! C’est juste que TOUTES les informations sont présentes, pas de zone d’ombre… Let’s go ?
Commençons par rappeler que vous devez vous inscrire via ce formulaire, après avoir choisi votre catégorie de participation : là, ce n’est pas une contrainte mais au contraire une liberté, celle de pouvoir opter pour le style de jeu qui vous correspond 🙂 Comme lors de KSC4 , la catégorie DeVinci adapte la mission originelle pour faire la part belle à la créativité, en remplaçant la mission de l’atterrisseur Huygens par le fameux drone Dragonfly en cours de conception par la NASA ! Débutants, profitez de la catégorie Juniors que nous détaillons ICI pour bénéficier d’une aide personnalisée, ce serait dommage de s’en priver. Enfin, sachez que depuis KSC2 – VENERA, il est possible de s’inscrire à la catégorie Alacool, la moins contraignante, sans dossier (mais on reste carrément preneur :p), dont vous retrouverez toutes les infos ici-même.
Pensez tout d’abord à vous faire une installation KSP dédiée, quand vous démarrez un Challenge. C’est bien plus safe en termes de mods et de sauvegardes 🙂 Si vous ne savez pas comment faire, suivez ce Mini-Tuto ! Il vous faut utiliser la version 1.8.1 du jeu, avant-dernière release stable en date, permettant le bon fonctionnement de notre sélection de mods. Cette fois, pas de sauvegarde spécifique, il suffit d’en lancer une nouvelle, SandBox, communication désactivée pour ceux qui le souhaitent, cela ne pose aucun souci et ne fera pas de différence dans la « notation » 🙂
C’est tout chaud, nous vous avons préparé des archives qui incluent tous les mods obligatoires (compatibles KSP 1.8.1 uniquement) et même quelques-uns parmi ceux autorisés ! Testés sur plusieurs machines et disponibles en plusieurs « qualités » graphiques pour correspondre à votre PC. Pour en profiter, téléchargez l’un des dossiers suivants et placez le GameData dans votre installation de jeu, comme… Comme un Mega-mod! Dans l’ordre croissant d’exigences graphiques, le dernier inclut des mods cosmétiques pour plus de plaisir rétinien :p Super-lite – Lite – High – Explose moi la rétine. Le téléchargement d’un de ces packs tout-en-un est OBLIGATOIRE !
Les mods obligatoires sont les suivants (inclus dans les packs ci-dessus) : on reste sur une approche pratiquement FullStock en dehors du système solaire bien sûr !
KSRSS: Kerbal Size Real Solar System, le fameux mod qui permet de retrouver toutes les planètes de notre système solaire et la plupart de leurs lunes, tout en conservant des échelles de distances compatibles avec les parts par défaut. La Terre est au diamètre de Kerbin, et le reste est ajusté en conséquence ! Nous utilisons désormais un mod développé par la communauté Francophone et vous en avez sans doute déjà entendu parler, merci à la KSRSS-Team : Kierra, Tony48, Natsukira, Fitz, Rezza et Invaderchaos pour cette petite gemme !
Pensez bieeeeeen à supprimer le fichier .settings de votre installation avant le premier lancement ! Cela permet au jeu d’en re-générer un nouveau parfaitement adapté à KSRSS, et qui vous garantira d’avoir accès à certaines options spécifiques comme les réglages de qualité, on vous renvoi sur le super tuto d’install très complet de l’équipe KSRSS !
Pensez bieeeeeeeen à désactiver les communications dans les paramètres de difficultés avant de lancer votre Save ! Vous pouvez bien sur jouer avec mais cela ne fait pas parti des exigences du Challenge.
Les mods / DLC autorisés et recommandés s’adaptent, on retrouve bien sûr les essentiels et la robotique est cette fois à l’honneur avec Breaking Ground et / ou Infernal Robotics qui seront bien utiles aux DeVinci !
KER : on ne le présente plus, Kerbal Engineer Redux est un petit outil très utile, affichant les statistiques de votre vaisseau : DeltaV, TWR, le nécessaire à la réalisation avisée de vos fusées, et pour ne pas y aller au pifomètre ! Un peu moins utile depuis les dernières mises à jour 🙂
TweakScale : vous en avez désormais l’habitude et certains l’ont adopté, TweakScale est de la partie, totalement facultatif : il vous permettra d’ajuster la taille des parts Stocks tout en modifiant leurs caractéristiques de manière réaliste ! Besoin d’une minuscule batterie ? C’est possible ! Mais attention à sa capacité 🙂 Besoin d’un panneau solaire encore plus grand ? C’est faisable ! Mais attention à sa masse… Vous pouvez le découvrir en détail via notre mise en bouche !
Le DLC Breaking Ground est introduit dans ce challenge, pour permettre la conception de systèmes robotisés : cela est autorisé pour TOUTES les catégories, et pas seulement les DeVinci ! Il s’agit d’un contenu officiel payant, mais vous êtes libres d’utiliser des alternatives gratuites comme Firespitter, AirplanePlus ou d’autres encore, pas d’excuse pour celui qui voudrait se pencher sur ce Gameplay 🙂 On vous demande en revanche de réserver cette utilisation à la confection des moteurs et hélices ! La robotique de Infernal Robotics Next est également permise.
Le DLC Making History, parce que pourquoi pas, il n’ajoute pas une plus-value particulière dans ce challenge, et certains ont peut-être déjà commencé leurs conceptions avec, sans forcément s’en rendre compte.
kOS et kRPC sont de la partie pour ceux qui le souhaite ! A l’unite et importante condition de faire vos propre codes, bien sur, et d’en faire bon usage, en expliquant à minima ce qu’ils font dans votre dossier. Faites en un outil extraordinaire, et pas juste un gimmick de style !
L’ensemble des mods graphiques qui n’ajoutent AUCUNE part (pas de caméras par exemple) et n’impactent AUCUN aspect du GamePlay (attention à Ven’s Stock Part Revamps qui modifie quelques specs, par exemple, ou à Restock+ qui ajoute plusieurs Parts. Restock est lui bien autorisé !)
Exemples de mods interdits : mods d’autopilot (MechJeb…), mods de parts (Near Future…), mods d’impact physique (FAR…).
Le challenge débute à la publication de cet article, c’est-à-dire le 20/04/2020 et prend fin un mois et demi plus tard, le 31/05/2020, date maximale à laquelle il vous faudra nous envoyer votre dossier compressé sur notre adresse officielle (contact@kerbalspacechallenge.fr) au format .zip par WeTransfer, un service bien connu qui ne nécessite pas d’inscription. Pratique ! Merci de joindre vos Crafts et éventuelles Saves F5, et de nous faire un petit document texte décrivant le ou les Crafts : masse Charge Utile, masse totale, puissance, nombre de parts, a minima. Nous insistons : vous avez le temps, prenez-le. Voyez ce challenge comme la possibilité d’exercer votre passion et de la partager avec les autres membres, faites-nous ressentir ce qui vous fait vibrer, sentez-vous libre de joindre à votre dossier de participation toutes les pièces pertinentes que vous avez pu créer, qu’il s’agisse de mathématiques, de tableurs excel, de poésies, d’illustrations, de vidéos… Vraiment, c’est votre dossier. Attention néanmoins, désormais nous appliquons quelques limites max pour vous amener à un contenu plus synthétique afin d’alléger la lecture et en particulier de ne pas exploser le temps libre du staff en phase de relecture : rapport 40 pages + 30 images (hors rapport, en complément) + 15 min de vidéo + 2 documents (PPT / Excel / …). Forcément, tout dépend de la pièce principale de votre dossier, hein ? Si vous faites une vidéo en tant que pièce principale, elle peut faire 30 minutes, par exemple. C’est plutôt indicateur, vous avez compris l’idée ^^ Merci 😀 !
Quelques critères flexibles, pour vous guider dans la construction de votre dossier :
Le respect du CDC : soulignez bien quand tel ou tel aspect de votre dossier permet de valider une exigence du CDC, c’est important !
L’originalité : étonnez-nous ! Par le format, par le contenu, il y a plein de façons de nous surprendre, il n’y a qu’à voir les participations précédentes ^^
L’aspect pédagogique / vulgarisation : pensez à expliquez vos démarches autant que possible, à vulgariser, essayez de sensibiliser les gens qui liront vos lignes, regarderont vos schémas, parcourront vos équations 🙂
La cohérence avec les autres éléments de votre dossier : liez les pièces entre elles, construisez un dossier cohérent, avec des éléments qui font appel les uns aux autres. Envisagez un (mini ?) document qui explique votre démarche et le rôle de chaque pièce de votre archive !
La synthèse : quelles informations sont essentielles, quelles sont celles que vous souhaitez mettre en avant, qui feront sortir votre dossier du lot ? Attention aux limites max décrites juste au dessus, mais ça laisse de la marge 🙂
Ces objectifs sont volontairement brefs et synthétiques, parfois même évasifs : nous tenons à ce que vous puissiez avoir une part d’interprétation mais aussi et surtout à ne pas empiéter sur vos recherches personnelles au sujet de la mission : elle regorge de bien des détails que certains auront la fierté de mettre en avant dans leur dossier, et nous souhaitons préserver cela 🙂
Comme pour la fois précédente avec Apollo/Artemis : la catégorie DeVinci dispose d’un contexte différent, mettant en avant le potentiel en créativité, ingéniosité, etc. En lieu et place de la mission Huygens, votre objectif devient celui du drone Dragonfly actuellement en cours de conception à la NASA ! Exit l’atterrisseur figé, place à la mobilité. Il ne s’agit ici pas d’une reproduction d’un concept existant, mais tout au contraire de vous laisser libre d’imaginer le drone en question, avec seulement quelques objectifs et contraintes pour vous guider.
1. Conception du vecteur
Juniors
DeVinci
Historique
Mission non habitée : le lanceur doit utiliser des Boosters à poudre latéraux, pour le reste, vous êtes libres !
Mission non habitée, laissez parler votre créativité, car cette fois… vous avez pour objectif de concevoir un vecteur au moins partiellement réutilisable ! Oui !
Là, forcément, vous vous en doutez : reproduction de la Titan IV-Centaur ! Soyez astucieux et mettez en valeur vos trouvailles 🙂 Ne piquez pas celle du voisin sur le WorkShop !
2. Lancement et mise en orbite
Juniors
DeVinci
Historique
Votre objectif, c’est l’orbite stable ! Vous savez, celle qui ne touche pas l’atmosphère ^^ Veillez à bien avoir votre Periapsis à plus de 70km.
Orbite stable et circulaire autour de la Terre avec une tolérance de 1% ! Soyez précis, l’altitude est libre.
Transfert direct : selon l’étape suivante (3. Transfert), vous devez montrer une trajectoire d’interception avec un autre autre corps depuis l’orbite basse de la Terre !
3. Transfert
Juniors
DeVinci
Historique
Il nous faut une interception de la cible à savoir Saturne ! Le Periapsis doit être inférieur à 2 millions de kilomètres pour valider cette étape.
DEUX assistances gravitationnelles vous sont demandées avant de rejoindre Saturne ! Nous ne précisons pas lesquelles, soyez libre de choisir le chemin de la facilité si vous l’avez identifié :p
Nous demandons au minimum une catapulte gravitationnelle avec Jupiter, mais vous pouvez tenter de reproduire les autres assistances de la mission historique 🙂
4. Interception et capture
Juniors
DeVinci
Historique
Une simple orbite stable autour de Saturne et c’est tout bon ! Ce sera déjà un sacré chemin parcouru :p Et puis, la vue est belle non ?
Un Aerobrake dans l’atmosphère de Saturne devrait vous permettre de collecter un échantillon atmo : ce n’est pas grave si cela ne procure aucun freinage particulier. Puis orbite stable.
A votre arrivée dans le système, plongez dans les anneaux de Saturne si votre angle d’incidence le permet, et formez une orbite très elliptique inclinée de 10 à 20°
5. Exploration du système planétaire
Juniors
DeVinci
Historique
Maintenant que vous êtes sur place, profitons-en : nous vous demandons deux passages à relative basse altitude, autour de deux satellites naturels ! Expliquez rapidement votre choix ^^
Deux sondes scientifiques devront être larguées et mises en orbite autour d’Encelade et Japet, au minimum. Notez-vous des particularités à propos des corps que vous visitez ?
Survol de Titan, Encelade et Japet, exploitant une ou plusieurs assistances gravitationnelles pour les atteindre. Superbe non ? 😀
6. Exploration de Titan
Juniors
DeVinci
Historique
Réussissez un Landing sans la moindre casse au sol de la fameuse Titan ! L’atterrisseur est tout à fait libre, il peut emporter des instruments ou être un simple bloc parachuté.
DragonFly est de la partie ! Il ne s’agit bien sûr que d’une inspiration, nous vous demandons un drone capable de se mouvoir de manière autonome (en énergie) au sol de Titan 🙂
On est sur de la reproduction de la mission Huygens, avec tout ce que cela implique en termes de Conception et de Landing : voyons voir jusqu’où vous irez dans la fidélité moyennant les contraintes !
7. The Grand Final
Juniors
DeVinci
Historique
Etape commune à toutes les catégories : brûler dans l’atmosphère de Saturne ! Et avec panache :p
Etape commune à toutes les catégories : brûler dans l’atmosphère de Saturne ! Et avec panache :p
Etape commune à toutes les catégories : brûler dans l’atmosphère de Saturne ! Et avec panache :p
Il y aura bien sûr des récompenses ! Pour les gagnants, bien sûr, mais pas seulement : nous cherchons à récompenser tous les participants qui nous soumettent un dossier en bonne et due forme. Même si vous rencontrez des difficultés, si vous n’allez pas au bout de la mission, etc, n’hésitez pas à envoyer votre dossier, en précisant les obstacles que vous avez rencontrés, ce que vous avez appris, il y a toujours de la matière pour proposer un document complet et intéressant ^^ Nos finances ne sont pas forcément assurées au moment de la rédaction de cet article mais nous ferons tout pour que chacun puisse recevoir des Goodies pensés et designés par notre staff ! N’hésitez pas à soutenir toute cette organisation en faisant un tour sur notre boutique SpreadShirt « Station KSC », ou en nous faisant un don directement sur Paypal 🙂
Pour conclure cet article qui lance officiellement le déroulement du challenge KSC5 – CassiniTitan, nous tenons à vous rappeler que l’objectif n’est pas tant la compétition envers les autres que le sens du partage et de la communication : nous vous proposons un contexte et un support commun, KSP, c’est l’occasion idéale d’échanger avec les autres membres, qu’ils soient participants à ce challenge ou non, avec le staff, ou même avec des personnes extérieures ! Vous disposez d’un forum regroupant tout plein de catégories de discussions afin d’avoir un cadre de communication aux petits oignons : une section est d’ailleurs dédiée au déroulement des challenges, de quoi retrouver les autres joueurs et s’entraider, ou encore bavarder sur telles ou telles déconvenues / anecdotes. Vous pouvez aussi retrouver la communauté en direct sur notre Discordtrès actif ! Faites vivre nos challenges, appropriez-les-vous, et n’hésitez pas à nous faire savoir si ça vous plaît, en partageant sur les réseaux sociaux 🙂
Et comme d’habitude, pour commenter cet article, cela se passe sur le forum ! Venez nous dire ce que vous pensez de cette nouvelle thématique et de l’organisation que nous vous proposons 😉 Et surtout… Inscrivez-vous au challenge 😀
Alors, vous en pensez quoi ? :p Images et montage : staff KSC ———— Mods visuels et notamment KSRSS ———— Musique : Spiriteaux de Tony Anderson
Il se sera fait attendre, mais il est bien là ! Le Challenge KSC5 – CassiniTitan vous ouvre ses portes, avec un double objectif qui ne vous aura pas échappé au travers du titre et du Teaser : revivez l’une des missions les plus emblématiques de l’exploration spatiale inhabitée, en orbitant Saturne et en foulant le sol de Titan. A une subtilité près, néanmoins : comme pour le Challenge KSC4 – Apollo11, nous vous proposons d’aménager le cahier des charges de la participation DeVinci pour mettre en avant vos talents créatifs et vos astuces d’ingénierie ! La branche « Huygens » de la mission originale se voit donc ainsi remplacée par Dragonfly, le fameux drone en cours de conception à la NASA, qui permettra de re-découvrir la lune Titan avec une mobilité sans pareille. Huygens reste d’actualité pour le cahier des charges Historique et Junior, d’où l’appellation hybride « CassiniTitan » retenue pour ce challenge 🙂
Au menu, c’est donc le système planétaire de Saturne qui sera la cible de vos screenshots, révélant son potentiel grandiose, ses anneaux, ses teintes douces, son héxagone polaire, et bien sûr ses très nombreuses lunes ! Même les tenants de la #TeamJupiter ne sauraient nier le spectacle fabuleux qu’offre la géante gazeuse, accompagnée du satellite naturel Titan qui fera bientôt l’objet d’une nouvelle mission, Dragonfly. Le potentiel en conception de crafts est très fort, tant dans l’exercice de la reproduction historique et fidèle que dans la création pure des DeVinci : lanceurs, satellites, atterrisseurs, drones… Il y a de quoi faire, sans même parler du plan de vol qui réserve des images magnifiques !
Le tout se passe sur le jeu Kerbal Space Program assorti d’une liste de mods obligatoires et / ou autorisés, et vous pourrez mettre en valeur votre participation en élaborant un dossier regroupant tout ce qui peut faire sens avec la mission. Que vous sachiez dessiner, manier les mathématiques, rédiger de beaux poèmes, monter des vidéos originales, maîtriser les exigences et aléas d’un LiveStream, tout est bon pour valoriser votre participation ! Vous retrouverez les détails de la mission dans le prochain article, qui regroupera les objectifs du cahier des charges : un peu de contraintes pour un challenge plus dense 🙂
Gardez bien en tête que tous les niveaux sont les bienvenus, nous apportons notre aide chaque fois que cela est nécessaire et notre système de catégories permet à chacun d’y trouver son compte. Débutants, rejoignez la catégorie Juniors bien spécifique, pour laquelle nous mettons en place de nombreuses aides et suivis personnalisés 😉
Cet article ouvre officiellement les inscriptions, et cela se passe via ce formulaire : INSCRIPTION. Le challenge en lui-même se déroulera du 20/04/2020 au 31/05/2020, largement de quoi mener à bien cette mission et prendre le temps d’échanger avec les autres membres de la communauté : profitez du forum, il est là pour ça, et une section dédiée est déjà en place pour accueillir vos messages liés aux Challenges ! Vous pouvez même dès maintenant nous dire ce que vous pensez du thème KSC5 – CassiniTitan en suivant le lien vers le topic commentaire que vous trouvez en fin de chaque article 😉
Oh, et… Si ce Teaser patiemment monté vous a plu, n’hésitez pas à nous le faire savoir, et le mieux est encore de le partager sur les réseaux !
A très bientôt pour la lecture du cahier des charges ^^ C’est là-bas que se trouvent TOUTES les informations pour vous lancer !
Nous sommes le 24 décembre 2019, réveillon en famille, vous ne verrez cet article que demain pour la plupart d’entre vous, ou les jours qui suivent : vous avez bien raison 🙂 Ce 24, c’est aussi la fin du Calendrier de l’Avent KSC, c’est à dire un challenge d’endurance, pour vous comme pour nous (ce fut dense et pas évident en terme de disponibilité :p), avec pour objectif de nous soumettre un Screenshot sur une thématique donnée, chaque jour. D’ailleurs cette année, pour simplifier les participations, nous vous avions cette fois soumis un calendrier synthétique avec les thématiques en avance. Avec quelques aménagements, c’est sans doute cette structure que nous garderons pour les années suivantes !
Premier jour : Screenshot spécial
Lundi : Lune – Mun
Mardi : Mars – Duna
Mercredi : Mercure – Moho
Jeudi : Jupiter – Jool
Vendredi : Venus – Eve
Samedi : Saturne – Jool
Dimanche : Screenshot spécial
Du 24/12 au 31/12 : Screenshot libre
Merci pour vos participations ! Notre podium a généralement privilégié la composition de l’image, l’esthétique globale, plutôt que le craft ou l’accomplissement dans le jeu, mais nous avons également pu mettre à l’honneur quelques percées d’originalité ou de fun 🙂 Bien sur, les mods qui rendent le jeu plus beau favorisent grandement leurs utilisateurs, et nous ne pouvons lutter contre : nous vous invitons tout au contraire à profiter de ces mods dans la limite de la puissance de votre PC, certains sont très léger par rapport au gain en visuel apporté ! Et bien sur, KSRSS / SSRSS / RSS sont toujours à l’honneur quand il s’agit de montrer les astres de notre système solaire, magnifique, et qui change des corps que nous avons l’habitude de voir dans la plupart de nos parties KSP 😉 Une petite installation dédiée KSRSS est de mise, surtout pour se préparer à chacun de nos Challenges, c’est d’ailleurs l’idée derrière ce Calendrier de l’Avent qui à l’origine un excellent moyen de vous amener à découvrir ce mod et vous promener autour de Mars plutôt que Duna, de surfer sur les anneaux de Saturne, de viser loin avec Neptune, etc.
Il est temps de vous proposer un Best-Of de ces 24 jours, nous n’avons gardé que les premiers parce qu’il serait impossible de rendre honneur à toutes vos participations sans détruire la connexion du plus fibré d’entre vous, mais n’hésitez pas à replonger dans les archives des cet événement, en suivant le Hashtag #TodayOnKSP sur Twitter ! Des miniatures qui sont à découvrir en grand via un clic sur la grille ci-dessous, cela va de soit pour en apprécier la qualité.
Enjoy et… JOYEUX NOEL!
Et comme d’habitude, pour commenter cet article, cela se passe sur le forum 😀
Chaque année depuis la création de KSC, nous vous proposons de participer à un challenge un peu particulier, celui de proposer un Screenshot KSP par jour selon une thématique quotidienne que nous vous soumettons, de sorte à confectionner sur le mois de décembre un Calendrier l’Avent sauce KSP ! Ce court article est là pour vous donner envie et préciser quelques rapides règles 😉
Réglement :
– Notre équipe propose un thème tous les matins sur nos plateformes Twitter/Discord : a vous de jouer pour proposer votre Screenshot KSP !
– Le Screenshot doit être soumis de préférence sur Twitter, avec les Hashtags et mentions suivantes (que vous pouvez copier-coller) : #TodayOnKSP #KSP @KSC_fr
– Il peut également être posté sur notre Discord dans le canal « calendrier-avent » si vous ne disposez pas de Twitter.
– Et aussi sur notre Forum dans le topic dédié, c’est à dire celui dont le lien se trouve juste en bas de cet article, comme à chaque fois ^^
– Pas de Post-Production, autrement que les mods de Shaders qui sont autorisés : en gros, votre Screenshot est brut de capture InGame.
– Tous les mods sont autorisés, toutes les triches également, ce qui compte, c’est l’image finale.
– Un seul et unique Screenshot par personne et par jour !
– Le Screenshot est à envoyé avant 20h le soir même.
– Le Staff délibérera aussi rapidement que possible, en essayant le soir même, avec une sélection de jusqu’à 3 images.
C’est très court, la plupart d’entre vous iront piocher dans des Screenshots existants, mais sachez qu’il n’y a pas plus de contrainte que cela : l’objectif, c’est le screenshot à proprement parlé, par la création que l’on y voit. C’est l’image qui est « jugée », sa composition, sa lumière. Tous les mods sont autorisés, toutes les triches pour vous rendre où bon vous semble dans le système, vous pouvez récupérer le craft d’un autre sur notre Hangar KSP-Fr ou ailleurs, etc.
Faites vous Plaisir, faites nous Plaisir, partagez vos realisations, faites connaitre ce petit challenge annuel autour de vous, et on constituera ensemble la plus belle banque de Screenshots KSP :p D’ailleurs, vous pouvez aller lire cet article portant sur les résultats du calendrier de 2017 pour admirer la créativité et les avoir faire de la communauté, et ce n’est que notre sélection !
On décide qu’un 
Nous le modifions de sorte à simplifier sa Charge Utile et la résumer à un réservoir de carburant dont nous interdisons la consommation : voyez cela comme un bloc de béton inerte dont nous pouvons affiner la masse précisément si nécessaire. Le lanceur est constitué d’un simple étage central propulsé par un LVT-45, et, sur les flancs, nous retrouvons deux boosters à poudre BACC.
La première étape indispensable constitue donc la sauvegarde d’un craft dédié pour chaque TWR testé, à partir de la base commune, en jouant sur la puissance des boosters, comme évoqué. Nous obtenons la liste ci-contre, avec un lanceur par dixième de TWR, de 1.2 à 2.08.
Prenons un exemple ! Le TWR 1.4 nous offre 5 courbes, donc 5 couples de valeurs possibles, les voici :
