Ariane 5 passera bientôt la main à l’occasion de la mission Juice. Dites donc, ne serait-ce pas le moment pour un petit défi ?
Vous êtes à la tête du programme KJuice pour la Kerbal National Agency of Kerbin Institute (KNAKI).
Recherche de signes de vie : On pense que Laythe, la lune de Jool, possède un océan qui pourrait abriter la vie. Une sonde pourrait rechercher des signes de vie en examinant la surface de la lune et en échantillonnant son océan.
Étudier la géologie : Les lunes de Jool sont parmi les corps les plus actifs géologiquement dans le système kerbol, avec des caractéristiques comme des volcans actifs et des geysers sur Vall. Une sonde pourrait étudier ces caractéristiques pour en savoir plus sur la géologie des lunes.
Comprendre le système kerbol : L'étude des lunes de Jool peut nous aider à comprendre la formation et l'évolution du système kerbol. On pense que ces lunes se sont formées à partir du même disque de gaz et de poussières qui a formé Jool, elles peuvent donc fournir des indices sur les conditions du système solaire primitif.
Objectifs
Concevez un système d'envoi de sondes génériques pour cartographier les lunes de Jool. Une sonde pour chaque lune et une sonde relais orbitera autour de Jool avec une orbite héliosynchrone (Une orbite polaire est acceptée) pour rester en contact permanent avec Kerbin.
C'est une courte mission, le budget n'est alloué qu'une seule année, les 6 sondes doivent arriver ensemble ou à peu près. La dernière sonde doit avoir quitté le système de Kerbin avant l'arrivée de la première dans le cas d’un envoie dégroupé.
Règles :
- Le ou les lanceurs doivent être entièrement assemblés sur le sol de Kerbin et/ou son orbite. On peut imaginer un immense porte nef comme le lancement groupé et simultané de 6 petites fusées.
- Lorsque la première sonde est capturée par Jool, la dernière doit avoir quitté la zone d'influence de Kerbin.
- Imaginez une stratégie de communication pour conserver le contact avec votre programme.
- (Bonus) Cette mission est à l’honneur d’Ariane, une bonification sera accordée si le visuel du lanceur se rapproche d’une Ariane 5.
- Les 6 sondes doivent obéir aux contraintes au cahier des charges de la KNAKI. À savoir :
Elle est définie comme probe (fonction Rename Vessel dans le jeu)
Elle pèse moins d'une tonne
Elle n'est pas habitée
Elle possède au moins un panneau solaire ou un RTG (Radioisotope Thermoelectric Generator)
Elle possède au moins une batterie, une antenne et un capteur
Vous devez remplir cette mission avec une version stock de KSP 1.12.5 ou KSP 2 pour les plus téméraires. Les DLC ainsi que les mods, autre que les mods graphiques, ne sont pas autorisés afin de maintenir une équité entre tous les participants.
Votre proposition sera disqualifiée si :
- Le prix annoncé ne correspond pas au prix du craft fourni. (KSP 1) - La masse et le deltaV annoncés ne correspondent pas aux valeurs du craft fourni. (KSP 2) - Si vous n'avez pas une prise de vue avec les 6 sondes dans le système Joovien. - Si un membre d'équipage est tué pendant la mission. - Si un mod et/ou des parts modifiées sont utilisés pour l'expédition. - Si les fichiers remis au jury sont manquants, illisibles ou corrompus. - Si vous refusez d'effectuer une démonstration de votre mission au jury dans les 2 semaines après avoir été notifié.
Vous devez transmettre les informations suivantes via google form :
Votre Nom
Votre Email
Le nom de votre programme
Le nom de votre équipe/organisation fictive ou réel
Le coût de votre programme (KSP 1)
Le poids et le DV de votre programme (KSP2)
Narrez vos exploits
- Un résumé de votre aventure sur 5 pages/slides maxi ou vidéo de 15 mins max. Les formats exotiques sont acceptés. Vous pouvez émettre la proposition d’un autre format par email ou sur le canal discord dédié au défi. - Une vue de votre/vos lanceurs sur le pas de tir. - Une capture d'écran de vos 6 sondes autours de leurs astres respectifs dans le système Joovien depuis le centre spatial. - Le .craft (ksp1), le .json (ksp2) de votre (vos) vaisseaux complets, Celui-ci sera testé sur les dernières versions stock de KSP 1 ou 2.
Vous devrez nous fournir les éléments ci-dessus dans un zip par email à l'adresse : contact@kerbalspacechallenge.fr
Garder les sauvegardes des moments clé de votre mission : lancements, captures, injections, finalisations d’orbites. Vous devrez rejouer ces instants en live en cas de victoire.
IMPORTANT
En cas de victoire, vous serez invité à rejouer votre mission lors d'une vidéoconférence avec le jury avant la proclamation officiel de votre victoire et contrôle des différentes éléments constituants votre dossier. Une présentation orale de vos différents choix de conception ainsi que vos méthodes de construction vous seront également demandés. Vous devez, bien sur, utiliser le même craft que le craft soumis. En cas de disqualification, la meilleure proposition suivante sera auditée.
QUESTIONS
Vous trouverez le wiki KSP ici : https://wiki.kerbalspaceprogram.com/ Besoin d’un éclairage sur un point de règle ? Contactez nous sur discord ou par mail : contact@kerbalspacechallenge.fr
Bonjour ! Vous n’avez pas pu rater la sortie de la 1.0 de Juno : New Origins.
Le KSC est une association pour promouvoir le spatial via notamment les jeux d’exploration spatial et Juno coche toutes les cases. Mais Juno qu’est-ce que c’est ? Eh bien, c’est un jeu d’exploration spatial procédural (aussi bien au niveau des moteurs que des réservoirs) qui propose quelques fonctionnalités supplémentaires. Franchement, essayez au moins ! Pour l’occasion, Jundroo a offert 5 clés, merci à eux !
Parlons-en justement du défi ! Votre mission, si vous l’acceptez, est de faire le tour de Droo (la Terre de là-bas) le plus vite possible.
Bien sûr, ce tour doit se faire au niveau de l’équateur. Sinon il n’y a pas plus de limites. Vous voulez faire un avion ? Une fusée ? Une voiture de course ? La dernière proposition n’est pas forcément la meilleure, mais faites ce qu’il vous chante !
Téléchargez la carrière custom (lien) et mettez-la dans C:\Users\USERNAME\AppData\LocalLow\Jundroo\SimpleRockets 2\Career. Ensuite, créez une nouvelle partie carrière en sélectionnant « KSC ». Enfin, validez le contrat, et vous pouvez commencer !
Pour soumettre, envoyez un screen de la fin par le formulaire. Si vous en envoyez plusieurs, la dernière sera prise en compte. Vous avez jusqu’au 24 février pour participer !
Ce nouveau jeu dans la communauté s’accompagne de nouveaux salons dans notre discord ! Venez visiter ou poser vos questions !
Tous les yeux sont tournés vers Artémis, nous ne pouvions laisser passer cet événement sans un petit défi.
Vous êtes à la tête du programme Kartemis.
Ce programme vise au retour des Kerbaunautes sur la Mun. Ce n'est que la première étape d'un programme bien plus ambitieux, celui du premier Kerbal sur Duna. Mais soyons honnête 2 minutes, hormis étancher la soif d'aventure et repousser l'horizon des conquêtes de toute la société Kerbalienne, il n'y a guère de perspectives de retombées financières à un tel programme.
Le président Kerman, à l'initiative du programme, connaît également des problèmes de popularité. Le programme ne saurait justifier des dépenses exubérantes.
Toutefois, la Khine et ses programmes ne cessent de surprendre les autres agences par la vitesse à laquelle ils repoussent les limites entre eux et l'astre d'argent qui éclaire nos nuits et réduit nos chagrins à sa simple évocation. Il y a donc un enjeu de vitesse.
Vous devez atteindre avec 3 Kerbaunautes l'un des 3 Munoliths de la Mun. Voici leurs coordonnées :
9° 49′ 53″ S / 25° 55′ 3″ E 57° 39′ 36″ N / 9° 8′ 32″ E 82° 12′ 22″ S / 102° 55′ 43″ E
Vous devez quitter la sphère d'influence de la Mun en un seul vaisseau. L'équipage doit rejoindre Kerbin en toute sécurité à l'intérieur de modules de commandes ou d'habitations. Les Kerbaunautes ont besoin d'espace pour les longs voyages.
Vous pouvez reconfigurer votre vaisseau tant que les composants sont lancés en un seul lancement. Pas de Gateway pour refaire le plein de votre vaisseau, celle-ci n'a pas encore été inventée.
Il existe 2 challenges. Le programme avec la masse la plus faible gagne. Un autre prix est prévu pour le programme le plus économique. Si le plus léger est également le plus économique. Le second programme le plus économique remportera le prix. En cas d’égalité, c’est l’équipage qui sera rentré le plus rapidement qui raflera la mise.
Vous devez remplir cette mission avec une version stock de KSP 1.12.3. Les DLC ainsi que les mods, autre que les mods graphiques, ne sont pas autorisés afin de maintenir une équité entre tous les participants.
Votre proposition sera disqualifiée si :
- La masse annoncé ne correspond pas à la masse du craft fourni. - Le prix annoncé ne correspond pas au prix du craft fourni. - Si vous n'avez pas de prise de vue avec 3 Kerbals + 1 munolith. - Si vos landers sont inhabités. - Si un membre d'équipage est tué pendant la mission. - Si un membre d'équipage malade ne respecte pas sa période de quarantaine. - Si un mod et/ou des parts modifiées sont utilisé pour l'expédition. - Si les fichiers remis au jury sont manquants, illisibles ou corrompus. - Si vous refusez d'effectuer une démonstration de votre mission au jury dans les 2 semaines après avoir été notifié.
Vous devez transmettre les informations suivantes via google form
- Votre Nom - Votre Email - Le nom de votre programme - Le nom de votre équipe/organisation fictive ou réel - La masse et le total de Δv de votre vaisseau avant lancement - Le coût de votre vaisseau - La date de retour sur le sol de Kerbin - (bonus) Jusqu'à 5.000 signes pour nous relater vos exploits accomplis durant votre aventure
Vous devrez également nous fournir les éléments suivants dans un zip par email à l'adresse : contact@kerbalspacechallenge.fr
- Une capture d'écran de vos 3 Kerbals et de votre Lander et/ou Rover en présence d'un Munolith - Une capture d'écran de votre équipage sur le voyage de retour vers Kerbin - Une capture de votre équipage sain et sauf sur Kerbin en EVA - Le .craft de votre vaisseau complet. Celui-ci sera testé sur la dernière version stock de KSP.
IMPORTANT
En cas de victoire, vous serez invité à rejouer votre mission lors d'une vidéoconférence avec le jury avant la proclamation officiel de votre victoire et contrôle des différentes éléments constituants votre dossier. Une présentation orale de vos différents choix de conception ainsi que vos méthodes de construction vous seront également demandés. Vous devez, bien sur, utiliser le même craft que le craft soumis. En cas de disqualification, la meilleure proposition suivante sera auditée.
QUESTIONS
Vous trouverez le wiki KSP ici : https://wiki.kerbalspaceprogram.com/ Besoin d’un éclairage sur un point de règle ? Contactez nous sur discord ou par mail : contact@kerbalspacechallenge.fr
KSC5 – CassiniTitan, le challenge du confinement ! Un contexte un peu particulier pour tout le monde, et nous espérons avoir pu vous proposer une petite échappatoire, une fenêtre vers l’espace sans même avoir besoin de signer une attestation de sortie 🙂 Tout d’abord, commençons par nos excuses, de ne pas avoir pu vous proposer cet article de résultats plus tôt, nous sommes très (très (très)) en retard par rapport à nos habitudes, et la période n’y est pas pour rien. On pourrait croire que tout bon confiné se retrouve avec davantage de temps qu’avant, et bien cela dépend grandement des profils ! Les interactions avec la communauté et votre soutien permettent néanmoins d’aller toujours plus loin. Merci donc, de votre compréhension et d’être toujours aussi présent pour nos évènements ou plus généralement sur nos réseaux !
Cette fois, il s’agissait de la mission Cassini-Titan, une sorte d’hybride entre la mission historique Cassini-Huygens, l’une des plus marquantes de toute l’histoire du spatial, et Dragonfly, un projet de mission en bonne voie pour faire atterrir un Drone au sol de Titan dans les décennies qui viennent. Nous l’avions introduit avec KSC4 – Apollo, nous tenons à ce que les DeVinci puissent s’exprimer au travers d’un cahier des charges un peu différent, avec des objectifs mêlant innovation, créativité, imagination, et ce retour au sol du plus gros satellite de notre système solaire nous semblait des plus pertinents. Ce serait donc… CassiniTitan, Cassini comme socle commun aux participation puis Huygens d’une part pour les Historiques et Juniors, et Dragonfly d’autre part pour les DeVinci, à destination de Saturne et Titan dans tous les cas. La mission est ambitieuse, c’était même d’un bon cran le challenge le plus complexe que nous vous ayons proposé ! Entre le DeltaV requis pour ce système planétaire externe et lointain, les assistances gravitationnelles, le nombre de choses possibles à réaliser, vous avez eu fort à faire pour vous exprimer et nous montrer votre skill et vos envies !
Ce sont 15 participants qui ont investi de leur temps et nous les félicitons d’emblée : bravo pour vos dossiers, bravo pour vos réalisations dans KSP ! Est-il nécessaire de préciser que la plupart d’entre vous persistent dans la voie vertueuse d’un réel progrès ? Tant sur la forme et le fond de vos documents que sur le jeu, la tendance est à l’attention aux détails, à la justification, à la structure, et puis au fun aussi, bien sûr ! Parlons succinctement de quantité : nous restons dans la droite lignée d’un KSC4 – Apollo, et nous avons pu échanger avec vous au sujet de plusieurs désistements : la difficulté était globalement mise en avant, avec notamment la volonté des participants de terminer correctement leur mission sans passer à côté d’un objectif. C’est bien sur dommage si cela devait bloquer une participation, et nous revenons en détails sur ces éléments dans notre article de mise à disposition des dossiers, filez le lire 🙂
Nous restons néanmoins très heureux d’avoir pu lire ces 14 dossiers et nous vous proposons de passer à la partie que vous attendez tous… Les résultats ! Et comme d’hab, vous le savez d’avance, ça dépote et ce fut, pour plusieurs trios de tête, très serré 😀
Nous vous avions proposé 4 catégories de participation afin de mieux cerner vos objectifs et définir une « dominante à vos dossiers » : 4 Juniors, 3 Historique, 5 DeVinci, 1 Duo ainsi que 1 dossier Alacool remis dans les temps et que nous intégrons avec plaisir à cet article, en la présence de GilFlo à nouveau ! Pour rappel, depuis la clôture du Challenge KSC2-VENERA, nous avons décidé d’inaugurer une nouvelle façon de participer, plus légère, plus simple, pour ceux qui n’ont pas le temps ou l’envie de confectionner un dossier, la catégorie KSP – Alacool ! Elle n’attend que vous, utilisez bien le Forum et nos réseaux pour déposer vos avancements, et pensez au fait que cette catégorie vous permet de participer même après la période du Challenge, les documents de chaque édition restant à disposition sur nos serveurs. Vous êtes bien sûr libre d’utiliser tous les mods que vous souhaitez dans ce contexte !
Et maintenant, place aux participations, dans l’ordre alphabétique pour proposer une certaine neutralité dans la présentation :p
Ha, juste, laissez cette page charger une bonne dizaine de secondes, histoire que les éléments s’alignent bien proprement, mais si vous avez lu jusque là, cela devrait être bon !
Cookie 3149 (Catégorie Junior)
Il n’est pas évident d’apporter un regard complet sur cette participation, nous ne disposons que d’un court document texte qui ne va pas très loin dans la mise en avant des objectifs de la mission. Néanmoins Cookie fait montre d’un humour décapant et absurde sur fond de RP, positionnant le KSC In Real Life à Brax (et pas Léguevin, c’est important). On a malheureusement peu d’autres informations permettant d’étayer le contenu de la partie, en dehors d’un appel à quelques images jointes séparément, dans le dossier.
Ces dernières témoignent d’une conception très kerbalesque et plutôt overkill 😛 Il faut ce qu’il faut ! Les deux rovers (parce que pourquoi pas, pratique en symétrie), sont très jolis et bien équipés, mais leur cinématique de repliement fait clipper énormément de parts, le système Quechua semble compromis 😉 Il ne nous est pas vraiment permis de constater plus que cela, la concrétisation des objectifs ni même de la navigation, dommage. Il ne faut pas hésiter à proposer un album complet et un peu mieux organisé si la partie écrite n’est pas trop ton dada 😉
Peu d’éléments pour juger de cette participation, et Cookie semble avoir manqué de temps pour proposer un réel aperçu de sa mission. Pourtant il y a de la ressource, et nous parions sur une prochaine participation un peu plus complète, propose nous par exemple un album PowerPoint commenté et assorti de ton humour piquant et ça fera le job !
Newka (Catégorie Junior – 3éme)
Le dossier de Newka prend la forme d’un récit. Un récit qui a un goût de trop peu. On oscille entre des difficultés d’écriture qui gênent la lecture de l’aventure et de très belles captures. Il faut reconnaître à Newka un talent certain pour les belles photos. La photo d’Encelade est particulièrement belle et bien légendée avec cet objectif raté qui s’éloigne et ne sera jamais rattrapé.
On notera cette magnifique reconstitution d’une Titan IV. De même, la conception de la sonde Cassini et de son atterrisseur viendront nous titiller la rétine par leur proximité avec les véritables engins. Newka a su bien les mettre en valeur grâce à ses prises de vues. On a une belle prise en compte de la localisation de la mission au sein de l’héliosphère. J’adore l’épilogue malheureux de la mission complètement foiré puisque Cassini n’ira pas finir sa course dans le bon astre.
Des objectifs pas vraiment respectés, c’est ce qui pêche en priorité ! Deux docs un peu courts pour correctement étayer des aspects essentiels, qui manquent vraiment, comme l’atterrissage sur Titan qui n’est pas du tout montré… Les crafts sont très jolis, minimalistes et réalistes. Ils offrent à Newka une jolie 3éme place dans la catégorie Junior.
Fabien Hoffbeck (Catégorie Junior – 2ème)
Fabien Hoffbeck, c’est l’autre nouveau participant à ces challenges, et également en Junior ! Et vous savez ce qu’il a d’autre en commun avec Cilgaviel ? Son dossier, qui est super complet également ! La première partie décrit l’ensemble des parties du craft, avec force détails : c’est un peu trop descriptif, avec toutes les parts essentielles, mais quelques explications sur les raisons de tel ou tel choix viennent donner du relief et de l’importance à ces paragraphes. Il faut davantage insister sur cet aspect 🙂 La seconde partie concerne la réalisation de la mission.
Fabien gère la fougère en matière de navigation ! Il explique avec brio toutes les stratégies mises en place, les erreurs à ne pas commettre, et les astuces pour parvenir à ses fins. Là encore, on est pas tout à fait sur du Juniors ! 😛 La conception prend tout son sens avec une décomposition Saturne / Titan et une séparation qui a lieu avant l’entrée dans le système de la belle aux anneaux pour optimiser les transferts à réaliser, c’est bien vu et bien exécuté, et ce n’est pas le seul exemple en la matière. Dommage pour l’atterrissage de nuit.
Un peu plus de synthèse dans la description des crafts et c’est du tout bon 😉 On aurait également aimé quelques images complémentaires pour apprécier à sa juste valeur cette participation très complète, car c’est une superbe première fois pour Fabien Hoffbeck qui remporte une seconde place bien méritée dans la catégorie Juniors !
Cilgaviel (Catégorie Junior – 1er)
Mais quel dossier ! Cilgaviel propose ici sa première participation à nos challenges, et il le fait BIEN. Le document est super bien structuré (malgré un début… Chelou ? ^^), notamment en présentant les crafts en attaquant de la fin vers le début, comme on le ferait pour la conception d’une mission, pour calibrer chaque étage, chaque objectif, et c’est même l’occasion pour ce joueur de parcourir les étapes du cahier des charges. Que demander de mieux ? Il y a bien sûr beaucoup de fautes, mais nous sommes prévenus et nous admirons l’effort 🙂
Côté KSP, idem, c’est du très propre. Tous les objectifs sont remplis sans doute permis, et la navigation est super maîtrisée. Catégorie Juniors interdite pour tes futures participations, c’est net 😛 Plein de survols astucieux, et on termine avec un Finish en beauté avec plusieurs informations très pertinentes sur la division des anneaux, et sourcé avec ça. Des défauts, hmm… Ne connaît manifestement pas le Gravity Turn ! Et quelques images manquantes pour pleinement tout apprécier. Mais c’est vraiment pour dire.
C’est une superbe première place en catégorie Juniors qui nous permet d’accueillir Cilgaviel dans la famille des participants aux Challenges KSC ! On espère vivement te voir participer à nouveau, ton dossier est remarquable, tant dans le contenu du document que ta partie dans KSP !
Big Universe (Catégorie DeVinci)
La participation de Big Universe est un jeu d’admiration et de frustration ! Commençons par la forme : le document proposé est complet et très détaillé, mais il lance trop de pistes de réflexion qui ne seront véritablement abordées que quelques pages plus tard. Cela manque de structure, et les images sont souvent trop petites, mais c’est un régal de découvrir les nombreux détails et attentions, les explications liées à la conception, les motivations ayant menées à telle ou telle solutions, et ça, c’est un très gros point fort !
Parlons-en, de ces solutions techniques : c’est le tour de force de cette participation, le drone est une petite merveille et l’écosystème qui l’accompagne est très crédible, notamment avec les informations apportées. Une protection thermique à double usage, un drone avec une cinématique intéressante, top ! Mais quel dommage de ne pas pouvoir apprécier tout cela au travers de tous les objectifs du cahier des charges, c’est ce qui coûte ici le plus de « points ». La navigation est également un peu aléatoire, avec des fenêtres très… Curieuses ? ^^
Big Up à Big Universe pour ce drone à géométrie de vol variable, son écosystème bien pensé et ses nombreuses informations qui font sens. On regrette seulement un document un peu confus et l’absence de plusieurs objectifs, il finit au pied du podium, et cela s’est joué à rien pour la troisième place !
Jezz (Catégorie DeVinci)
Le premier mérite du dossier de Jezz est incontestablement l’originalité du support de son livrable. Une petite notice nous invite à configurer notre tableur pour parcourir le dossier sur fichier excel. C’est un point qui aura fait grand débat parmi nous, car selon les tailles d’écran et les versions d’excel, au mieux c’est original, au pire c’est une épreuve de foi. Mais parlons du dossier en lui-même. Jezz va suivre scrupuleusement le cahier des charges. Le tout commence par une phase d’essai/erreur puis méticuleusement traiter chaque objectif de cahier des charges. On est dans l’esprit d’un KSC. On adore. Pas mal de beaux clichés de l’aventure, d’autres sont malheureusement à contre jour.
Félicitations pour les assistances gravitationnelles ! La Lune, Jupiter, quantification du gain, c’est du beau jeu. On a de belles conceptions, beaux crafts à priori, mais difficile à voir. On notera l’attention portée sur la sonde Cassini et le petit Dragonfly. On aurait même aimé en voir un peu plus, c’était tout de même l’objectif de la mission. On se demande, à la lecture, si on est plus proche d’un dossier historique ou d’un De Vinci. On s’attendait peut-être à trouver un peu plus de folie dans un De Vinci.
Bon dossier en soit, à la structure singulière, l’Excel n’étant pas très confortable à parcourir, mais ayant le mérite de bien structurer en fonction du cahier des charges.La synthèse est également au rendez-vous grâce à ce format, une phrase max par image, parfois c’est trop peu mais c’est pas mal en soi. Les images sont belles. On regrette surtout de voir un DeVinci qui mise peu sur l’ingéniosité. Un peu comme… Un Historique ne voulant pas faire de reproduction ! Mais le CdC est en partie bien respecté.C’est un premier dossier, la sonde Cassini est jolie. On aime l’esprit du challenge qu’on cherche à réaliser. Bravo Jezz.
Kilaketia (Catégorie DeVinci – 3éme)
Le challenge de Kilaketia prend la forme d’un récit bien écrit et agréable à lire. Ici, le cahier des charges sera scrupuleusement respecté et servira de fil conducteur au lecteur. Dommage pour les prises de vue très sombres qui ne mettent pas en valeur le travail malin de l’architecte derrière ses œuvres. Si toute la partie narrative de l’aventure captive le voyageur qui sommeille en nous, les sections détaillant les trajectoires et les calculs de DV se transforment vite en « Les Kerbonautes parlent aux Kerbonautes, je vous rends la parole chers Kerbonautes ». Un brin de pédagogie n’aurait pas nuit à l’affaire.
Il y a 2 objets qui frappent le lecteur dans la présentation de Kilaketia, c’est premièrement son impressionnante conception d’un lanceur SpaceX réutilisable. On est fidèle à l’original jusqu’à son utilisation puisque celui-ci regagnera Kerbin et pourra se faire admirer du pâturage au milieu duquel il a fini son court voyage. Cet étage de SpaceX nous apporte une note historique plus que rafraichissante à ce dossier De Vinci.
Le Second coup de cœur, c’est ce design ultra-original de ces drones tricycles. Quand 3 roues suffisent pourquoi rajouter du poids mort !
On aime les aventures « One shot » où l’on doit improviser avec les ressources à notre disposition, ici un fond de cuve de monoprop qui donnera un sacré coup de main à l’alunissage de notre drone. Les crafts sont malins. L’approche est assez empirique dans le charme d’une aventure De Vinci. Kilaketia nous gratifie d’un très bon dossier qui le propulse à la troisième place de la catégorie DeVinci et nous l’en remercions.
Tayronn (Catégorie DeVinci – 2ème)
Ouvrir un dossier de Tayronn, c’est comme fêter Noël en avance. On ne veut surtout pas aller trop vite pour ne pas se gâcher la surprise. Cette fois-ci Tayronn nous offre un diaporama sous PowerPoint avec un accompagnement musical ! Cette présentation est vraiment soignée. On notera une belle maîtrise du support. Les images sont bien cadrées, bien choisies. Les thèmes musicaux sont bien agencés. C’est pédagogique, on comprend où l’on est, ce qui se passe, ce qui va se passer.
Le lanceur est oufissime. Il se pilote comme une vraie navette, c’est-à-dire, un fer à repasser pourvu d’une paire d’ailes. Tout est là. La gestion des axes de poussée des différents moteurs et même le parachute de freinage final. Les crafts sont magnifiques et esthétiques. Mention spéciale à la navette et au drone dédiée à Titan. Les manœuvres sont super claires. Chapeau la triple manœuvre prévisionnelle. L’atterrisseur sur titan bénéficie d’éclairages cyan pour augmenter le contraste avec la surface ocre de l’astre, c’est tellement malin.
Au final, on a une mission lancée depuis une navette, le tout ultra compact et bien foutu (si on oublie le manque de carburant pour la sonde à destination de Japet). On perd l’ambiance Kerbal des dossiers précédents pour un dossier plus pédagogique. J’ai rajouté 1 point pour la panne de carburant, j’adore le côté mission « One Shot ». C’est une brillante médaille d’argent De Vinci pour Tayronn.
Harpercix (Catégorie DeVinci – 1er)
Le dossier d’Harpercix se présente comme une aventure communautaire. C’est drôle, Harpercix possède une imagination débordante et communicative. Le cahier des charges est parfaitement rempli, ceci grâce à une navigation impressionnante. La planification des manœuvres dans le système saturnien est une merveille. Ça en devient frustrant, on aurait aimé voir la visite de chaque lune comme prévu dans le plan initial. Harpercix a renommé les astres pour s’approcher de l’ambiance Kerbal malheureusement cela nous sort un peu de l’aventure car on s’y perd.
Dans ce dossier, tout le monde participe. On a même un jeu fictif réalisé dans le cadre de produit dérivé de la mission, une illustration d’Alex et l’intégration à l’histoire de nombreux participants du challenge. On a même du fan service avec l’utilisation d’un avion qui profitera de l’atmosphère de Titan, remportant un capital sympathie fort auprès de Le_Chimiste. On aura un petit regret pour toutes ces photos sombres qui n’enlèvent rien au dossier technique très riche et un Grand Final au top.
Un très bon dossier, bourré d’humour ! Ça se lit d’une traite comme un roman passionnant. En fait, on a même l’impression que sa mission servait à illustrer son dossier et pas l’inverse. Les crafts sans être exceptionnels sont très bien intégrés et capables de remplir des missions assez polyvalentes. Harpercix coche toutes les cases d’un challenge De Vinci remportant ainsi la première place, haut la main.
Mathieu Prigent (Catégorie Historique – 3éme)
Le dossier de Mathieu Prigent est un diaporama de photos qui ne comporte que très peu de textes. Mais woaw, les prises de vues sont vertigineuses. Il le reconnaît lui-même, ce dossier est parcellaire.
La reconstitution de la sonde est époustouflante et le lanceur est pas mal non plus. Ils font vraiment honneur à la catégorie historique à laquelle il a choisi de souscrire. On a que très peu d’éléments en dehors des screenshots ! Comment vérifier les étapes du cahier des charges ? Quel dommage. On aurait aimé en voir un peu plus d’exploration de Titan et de Saturne.
Une partie KSP avec quelques images et un rapport minimaliste. Ça ne permet malheureusement pas de prendre plus de points. Cher Mathieu nous espérons que nous en verrons plus la prochaine fois car ce petit goût d’inachevé que tu nous laisses est bien amer. La qualité des reproductions offre tout de même une 3e place de la catégorie historique à Mathieu.
Alexandre Belliard (Catégorie Historique – 2ème)
Alexandre propose ici sa première participation aux challenges KSC, et c’est un profil que l’on connait bien pour ses nombreuses réalisations d’avions sur le Discord. Il présente une vidéo accélérée de sa mission avec un peu de montage au départ, qui permet de voir le soin apporté aux Crafts : ils sont détaillés, fidèles, esthétiques, bien joué ! On aurait quand même aimé en voir un peu plus et c’est ce qui nous amène au principal défaut, la difficulté de percevoir quelque chose dans cette vidéo trop accélérée et sans retour au temps réel le temps de montrer des phases essentielles.
On ne profite pas pleinement des atouts de cette participation, et c’est dommage ! C’est aussi ce qui fait que l’on peine à voir la validation de plusieurs objectifs et il semble manquer toute l’exploration du système de Saturne et de Titan. Huygens est pourtant bien présent dans le craft, frustration ! Car il ne fait aucun doute qu’Alexandre maitrise le jeu dans son ensemble, sa navigation est parfois curieuse mais nous avons entre autre le droit à une belle AG à l’aide de Venus, comme en vrai, ainsi que de superbes images à l’arrivée dans le Système de Saturne.
En bref, cette première participation d’Alexandre semble témoigner d’un manque de temps pour parcourir tous les objectifs et proposer un montage un peu plus digeste de sa vidéo. C’est toutefois une Seconde Place en Historique pour récompenser le savoir faire de ce joueur en terme de conception notamment, avec des crafts très soignés et que l’on aimerait pouvoir contempler !
Méduse Spatiale (Catégorie Historique – 1ère)
Attention chef d’œuvre. Ici Méduse spatiale nous livre un dossier en 3 parties. Tout est poussé à fond. On est embarqué dans une vidéo de 14 minutes, super originale avec une parfaite incrustation de la mission dans un journal télé. Puis on découvre les crafts. Les reproductions sont incroyables de fidélité ! Méduse porte très haut les notions de challenge historique. Les prises de vues sont bien cadrées. On a une navigation assez Kerbal avec une arrivée de Huygens un peu rock & roll.
Tous les satellites sont visités, Encelade, Japet, Dioné, Rhéa, Mimas et 5x passages par Titan en prime puis le grand final ! On pensait avoir tout vu, voilà que cette vidéo est accompagnée d’un dossier de conception ultra riche. Méduse nous produit ici un impressionnant travail de recherche historique qu’il exploite à merveille en nous livrant une série de comparatifs entre les réels performances de l’engin et leur traduction dans KSP. Enfin on découvre avec quelle minutie les crafts de Méduse spatiale épousent scrupuleusement les détails des constructions originales.
Méduse Spatiale utilise un nommage assez malin entre Cassini historique et Kassini du challenge, ainsi le lecteur sait toujours de quoi il est question. Finalement, la dernière partie nous fournit un compte rendu détaillé de la mission. On y retrouve la chronologie fine de la mission. On aurait adoré une mise en miroir avec la chronologie réelle. Très humble, Méduse se demande si son dossier est à la hauteur alors que l’on est face d’une pièce monumentale. La première place est amplement mérité, la lecture de ce dossier nous a régalé de bout en bout. Un grand merci pour ce Grand Final !
RPfive05 et Bobix (Catégorie Groupe – 1er)
Rapport exemplaire dans la structure, pas original en soit, mais si bien articulé, Pro, vraiment pro. Sources, références, calendrier, répartition des tâches, chapitrage, pédagogie, calculs à l’avance, automatisation, reproduction quasi-identique (4 AG + survols lunes saturniennes). C’est une participation à 4 mains très bien organisée ! On est gratifié d’un tableau de l’algo de navigation qui n’est pas évident mais c’est probablement le mieux qui puisse être fait et c’est top ! Idem le résumé des trajectoires au sein du système Saturne, bien légendé, ça aide énormément, ça jalonne, et c’est ouf. Le niveau est assez incroyable.
Malgré une réelle volonté d’expliquer les étapes principales des maths, cela reste à priori perfectible : il y a moyen de faire plus simple, plus clair, plus « global ». Peut-être intégrer des gifs KSP / ou autre montrant l’effet de telles ou telles étapes ? Mais c’est du chipotage, mention spéciale au largage, la rentrée atmosphérique de Huygens et le Grand Final.
C’est un dossier stupéfiant en termes de niveau, de sens du détail, de maîtrise. Coup de cœur du jury de façon unanime. Excellente partie sur la programmation kOS, plus pédagogique, car certainement un peu moins complexe ou plus palpable. Bref un dossier absolument génial (surtout si on aime la physique) ! Des calculs et algorithmes bien détaillés permettent de clarifier les passages plus durs. Ajoutez à cela une vidéo très sympa qui permet d’apprécier toute la complexité de la mission, reproduite quasiment à l’identique de la vraie. Certe RPfive et Bobix sont premier de leur catégorie, mais ils obtiennent la meilleure note toutes catégories confondues.
GilFlo (Catégorie Alacool RSS)
Cette fois-ci encore, Giflo nous propose un challenge « alacool » avec son propre cahier des charges. Celui-ci propose d’y ajouter à la mission normale un atterrissage sur Japet. Mieux encore, sa mission sur Titan prévoit un retour des échantillons sur Terre. On conserve le Grand Final. Nous disposons d’une longue liste de spécifications des sondes. Très professionnel, Giflo prévoit la redondance de l’ensemble des systèmes. Et surprise finale, ce dragonfly très malin est en fait un sous-marin qui explore les fonds marins de titan.
La vidéo, on est en mode carrière, on récolte de la science. On est plus dans le let’s play que dans la pédagogie. Les crafts sont beaux et bien pensés. Giflo opte pour un « dragonfly » avec des ailes courtes et un moteur à hélices pour bénéficier de l’atmosphère de Titan. C’est personnel, mais j’aurais préféré une vidéo montée et coupée en vitesse normale plutôt que l’accélération du tout pour ne pas dépasser la durée acceptable. La fin de la mission n’est pas filmée, mais elle est bien documentée avec un compte rendu riche des calculs de fenêtre de tir pour obtenir les meilleures performances de navigation.
Merci Giflo pour cette balade très bucolique avec le drone dans les vallées et les lacs de titan. De plus tout cela est commenté et analysé, on est au top !On aurait adoré une vidéo du lancement ou du retour sur terre des échantillons. Super dossier. Il a été noté pour le fun sur les bases de la catégorie DeVinci comme demandé. Dommage que ce soit un dossier alacool, il aurait pu au moins être sur le podium !
RETOUR GLOBAL SUR LE CHALLENGE
Félicitations à tous pour la qualité des dossiers rendus. Leurs lectures furent incroyables. Beaucoup d’entre vous ont cette capacité à propager de manière contagieuse leur gout de l’aventure et de conquête de nouveaux horizons. La richesse des choix et la diversité des propositions des différents dossiers est une adrénaline dont on se saurait se passer. C’est l’essence du KSC.
Par cet article nous souhaitions leur rendre hommage et nous espérons vous donner envie à notre tour de parcourir leurs exploits, recherche historique et pérégrinations intellectuelles qui leur ont permis d’atteindre leurs objectifs. Nous nous devions, à notre tour, de boucler ce challenge comme il se doit. Nous avons mis le temps, mais il était impensable de ne pas vous rendre un peu de la joie que vous avez su nous procurer.
Comme son auteur, cette conclusion sera courte, je suis moins volubile que notre Guillaume qui nous a fait le dernier plaisir de la rédaction de l’introduction de cet article.
N’hésitez pas à partager une bafouille sur notre forum au post dédié à ce challenge.
Comme annoncé précédemment on reprend du service. Vous sentez ce léger parfum. Oui, ce sont les chaleurs d’été, mais il y a comme une petite fragrance supplémentaire. Oui, vous avez raison, il a comme un petit goût de KSC7.
On peaufine, on bichonne. Nous allons avoir besoin de vous pour les derniers détails.
Nous souhaiterions utiliser les fonctionnalités de “Making History” pour enrichir notre scénario. Nous aimerions donc savoir qui parmi vous l’utilise ? Qui serait prêt à en faire l’acquisition pour jouer ce challenge ? Qui ne veut pas en attendre parler ?
Bonjour et bonne année ! On se retrouve pour un petit article afin de conclure ce calendrier de l’avent, et pourquoi pas avoir quelques stats en bonus 😀 . C’était donc 24 thèmes qu’on a voulus les plus variés possible, aussi bien au sein de ces 24 jours que par rapport aux autres concours de screenshots. On ne pouvait pas passer les classiques qui sont les différents astres, d’ailleurs avez-vous remarqué qu’on a fait le tour du système ? Et oui, tous les astres ont été visités !
Vous avez été nombreux : 22 participants ! Avec en moyenne plus de 8 screens par jour, vous imaginez bien que choisir les gagnants n’était pas facile tous les jours 😛 . On a pu découvrir vos talents de photographe, d’ingénieur et d’installateur de mods !
Décernons nos Kerbals, nos Césars, nos Oscars. Commençons avec ceux qui ont le plus participer : malheureusement il va falloir couper la statuette entre BsamohT et Le-Chimiste qui ont 100 % de participation, suivies de près par Ecaheti. Proxima_b est la personne qui a gagné le plus de points au total. Alexandre A, Rakaton et Ceres sont les plus efficaces en termes de points par screen. Enfin les grands gagnants des médailles sont Proxima_b, Ecaheti et Warp !
Pour conclure, nous allons voir les 4 screens préférés.
Mais juste avant, parlons un peu de la méthode utilisée. Dans un premier temps, nous avons soumis aux votes sur Discord tous les screens ayant atteint le podium. Ensuite nous avons récupéré les 4 premiers pour un sondage Twitter.
Voici les 4 screens préférés dans l’ordre de vote :
Duna par Alexandre A.
Minmus par Rakaron :
Station par Alexandre A. :
Ike par Proxima_b :
Ce n’est que le Top 4 des meilleurs screens, mais il en reste encore beaucoup d’autres à voir sur #KSPAvent ou dans le salon #screen-de-l’avent sur notre discord.
D’ailleurs le gagnant emporte un calendrier des meilleurs screens ! On te recontacte prochainement Alexandre 😉 .
Bravo à tous ! On se retrouve l’année prochaine (ou peut-être avant) !
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 !
Haaa KSP, un jeu où l’on peut construire nos fusées et nos plus belles sondes dans un système solaire fictif. La taille réduite du système de kerbol, qui nous donne un défi adapté à un jeu vidéo grand public, difficile au début, mais vite maîtrisable quand on a compris les bases (ou si on a vu lesSLG de Dakitess !).
Mais attendez… vous en voulez plus ? Vous aussi vous voulez vous attaquer à notre système solaire ? Vous pouvez essayer les challenges KSC, qui se déroulent dans notre système solaire, mais à taille adapté au jeu de base, grâce au super mod KSRSS.
Ha vous en voulez encore plus !? Qu’à cela ne tienne, voici donc le système solaire à sa vraie taille ! Voici le mod Real Solar System, ou RSS ! Mais attention, le défi est de taille. En effet, pour une simple orbite terrestre, vous devrez atteindre une vitesse de presque 7800 m/s, le tout au-dessus des 140 Km d’atmosphère de la Terre.
Si vous n’êtes pas découragé, le spectacle sera à la hauteur de vos accomplissements (et oui, c’est toujours KSP, et garanti sans post processing, ni TUFX! ) :
Alors, ça vous tente ? Vous voulez tenter l’aventure ? Alors c’est parti ! On va commencer par les bases, c’est quoi ce modpack ? Quels mods contient-il ? Après on pourra commencer les explications et tuto, mais commençons par le commencement, vous verrez, il va falloir y aller par étape :p.
Les tutos in-game seront dans un article à part, ici on détaille le modpack et ses caractéristiques en lui-même, sans ouvrir le jeu (mais ça ne saurait tarder !).
I - QUEL DÉFIS ? POUR QUELS TYPES DE JOUEURS ?
Là, si l’article est suffisamment bien fait, l’intro vous a déjà mit la puce à l’oreille, et peut être vous a donné envie de tester l’expérience. Mais vous avez peut-être peur des chiffres annoncés. 7800m/s pour une simple orbite ! C’est énorme ! Et une atmosphère à 140 km, c’est deux fois l’altitude de l’atmosphère dans le jeu de base !
En effet vous l’aurez compris, la difficulté n’est pas du tout la même, mais pas pour autant insurmontable. Il faut en fait se dire qu’on commence un nouveau jeu, il faut tout réapprendre. Ainsi ne vous découragez pas si vous mettez 3, 4, 5, 6 ou même 10 lancements pour mettre en orbite un satellite d’à peine 1t. C’est normal, c’était la même chose lorsque vous avez commencé le jeu de base, vous vous souvenez ?
En changeant l’échelle, tout change. En plus de ça toutes les parts ou presque sont nouvelles, les compatibilités à apprendre, les types de fuels à intégrer. RSS/RO vous fournit l’expérience de simulation la plus poussée possible sur KSP, vous passez d’un coup d’un palier de simulation à un autre.
En un mot comme en cent, pas de panique on va tout vous expliquer !
Quel profil de joueur alors ?
Comme ce que vous avez pu lire juste au dessus, c’est un tout autre jeu, donc rien n’empêche quiconque de tenter l’aventure. En revanche ! Nous vous conseillons fortement de déjà avoir une bonne expérience avec KSP stock et de connaître les notions de bases et les principes essentiels.
À savoir : être capable d’effectuer une mise en orbite efficace et peu coûteuse en DV, savoir gérer son carburant, ses ressources. Tout cela en ne tombant pas dans des fusées de 4000t, mais plutôt des lanceurs équilibrés et optimisés (par exemple, l’asparagus c’est bien mais c’est vite un piège). Il peut aussi être très intéressant de déjà savoir faire un docking, un transfert vers une autre planète et bien sûr d’en revenir.
En soit, prenez ce modpack comme un KSP pour joueurs déjà expérimentés, cherchant un défi supplémentaire. Si vous devez apprendre à effectuer un docking sur RSS/RO et que vous avez déjà du mal à en faire en stock, vous risquez juste de vous décourager.
II - RSS/RO :
LE MODPACK, INSTALLATION ET MODS CONTENUS
A - Conseils d’installation, et CKAN
Tout d’abord, nous devons nous demander comment installer nos mods. Soit vous le faites tout à la main, soit vous l’automatisez.
De là deux solutions s’offrent à vous si vous ne passez pas par les modpacks que l’on vous fournit :
- Soit vous passez par une installation à la main de chaque mod, mais attention à chaque dépendance ! L’avantage étant qu’ici vous êtes sûrs d’où vient l’erreur si ça ne marche pas : vous avez sûrement brûlé une étape ou oublié une dépendance.
Notez d’ailleurs qu’il existe déjà un article sur notre site pour vous aidez à gérer vos gamedata : ici.
- Soit vous installez en utilisant CKAN. CKAN, ou la Comprehensive Kerbal Archive Network, est un installateur de mods. En quelques clics il vous permet d’installer tous les mods que vous voulez en s’occupant d’installer les dépendances, de vous proposer des mods pertinents pour compléter votre modpack etc… Pour un modpack de cette taille, avec autant de dépendances, CKAN est très fortement recommandé !
Retrouvez un tuto sur l’utilisation de CKAN ci-dessous :
Maintenant que vous savez comment installer ces mods, on va voir QUOI installer, et surtout pourquoi. Vous allez voir, il y a énormément de mods. C’est pour cela qu’on vous a expliqué comment marchait CKAN juste ci-dessus, c’est clairement le plus simple dans ce cas présent.
ATTENTION : CET ARTICLE A ETE ECRIT EN SE BASANT SUR LA VERSION 1.8.1 DE KSP, QUI EST, À CE JOUR, LA MEILLEURE POUR CE MODPACK (fin 2020).
B - Le pack RSS et les mods graphiques
Tout d’abord, vous aurez besoin de télécharger le modpack RSS. Nous devons tout de suite vous prévenir que ce modpack est relativement lourd. Si vous n’avez pas un très gros PC, allez y par étape, ne commencez pas tout de suite à installer les textures 16k ou 8k et tous les mods graphiques par exemple, si c’est beau mais que vous êtes à 10 fps, ce ne sera pas marrant pour vous et vous perdrez l’envie de jouer 🙂 .
RSS, donc. Vous avez compris, ce mod sert à modifier la taille du système solaire pour le mettre à échelle 1 (plus ou moins). Ainsi, vous pourrez explorer la Lune, Mars, Jupiter et ses Lunes, comme si vous y étiez !
Notez cependant : comme le jeu ne peut pas incliner les planètes sur leur axe, le mod incline toutes les orbites pour émuler cette inclinaison axiale. Donc oui, le mod prend aussi en compte l'inclinaison des astres sur leurs axe de rotation, à sa façon :p
Rappel : Nous vous conseillons très fortement d'installer ce modpack via CKAN !
Le modpack comprend donc RSS, ses textures et ses dépendances. On va commencer par les dépendances, en suivant l’ordre conseillé sur le topic officiel du mod :
Module Manager (pour les moddeurs, une dépendance) Attention, il ne doit y avoir qu’un module manager dans votre installation ! Si vous en avez déjà un, c’est très bien, n’en ajoutez pas un autre (si vous installez via CKAN, ne vous souciez pas de cette remarque, il le fera pour vous) !
KSCSwitcher (Ajoute des sites de lancement au jeu, quasiment tous ceux que l'on connait IRL en fait)
RSSDateTimeFormatter (adapte le format de date de KSP au vrai format qu’on connait : 1 jour = 24h = une rotation complète de la Terre)
Une fois que vous avez les dépendances de RSS… Il vous faut RSS, ça ce passe ici, sur le github officiel.
Il ne vous manque plus qu’une chose… les textures ! Et oui, c’est là qu’on vous dit de faire attention. Si votre pc est un peu à la traîne, n’allez pas trop haut, surtout que d’autres mods graphiques pourraient corriger ou masquer les textures basses résolution (on en parle juste après). Voici donc les différentes résolutions disponibles, à choisir ici :
Textures 2K (2048) : La plus basse, ça marche, mais on ne garantit pas que ce soit magnifique. Pour les toutes petites configs.
Textures 4k (4096) : La moyenne, ça commence à être un peu mieux, sans demander trop de ressources, ça peut être un bon compromis pour les petites à moyenne configs
Textures 8k (8192) : La haute, il faut commencer à avoir une machine raisonnable,mais ça commence aussi à être très beau !
Textures 16k (16384) : La ultra, à n’installer que si vous le pouvez ! C’est magnifique mais pas pour tout le monde (à titre d’exemple, elle tourne bien sur une config 16go de ram, gtx 1050 et i5 7500 en baissant l’anti-aliasing, c’est pas la plus haute config mais ça commence à monter)
Avec tout ça, normalement, vous aurez déjà l’essentiel et pourrez explorer le système solaire via la tracking station. Pour ce qui est des lancements, il nous faudra le modpack RO et les mods recommandés juste après.
Mais avant cela, voici une liste non exhaustive des mods graphiques les plus sympa à installer sur votre KSP en RSS, pour vous exploser la rétine (notez que, à part RSSVE qui est une config spéciale du mod EVE, tous ces mods sont disponibles sur le jeu de base) !
RSSVE : Ajout de nuages, lumières de villes ou encore aurores boréales aux planètes du système solaire qui en possèdent. C’est peut être rien dit comme ça mais ça change tout.
Scaterrer : Ajout de lens flares (les halos de lumières que vous voyez quand vous regardez le soleil par exemple), et meilleure gestion de la lumière des atmosphères des planètes. Pour la Terre, ça ajoute cet effet bleuté caractéristique qu’on ne retrouve pas sans lui. Au delà de ça, il ajoute même des effets d'éclipses et des effets sur l'eau. Un must have !
Planet Shine : Ce petit mod bien sympathique permet de voir le reflet des belles couleurs des planètes sur vos crafts ! Un ajout de petite taille, qu’on peut passer si on a pas une très bonne config mais qui est très jolie si on peut se le permettre !
Distant Objects Enhancement : Un super petit mod qui vous permet de voir les planètes autours de vous sous forme de petit point lumineux quand vous en êtes éloigné (comme pour de vrai quoi !). Vous pouvez même faire en sorte d'afficher le nom de l’astre lors du survol de la souris. Et ce n’est pas fini ! Vous verrez vos autres crafts, satellites ou stations lorsqu’ils passent au-dessus de vous ! Ils seront très petits, mais le point lumineux sera bien là. Comme on dit, le diable se cache dans les détails :p.
C - Le pack RO
Globalement on parle beaucoup de RSS depuis le début, mais le modpack s’appelle bien RSS/RO. Rapidement, RO pour Realism Overhaul, permet de rendre le jeu réaliste sur le plan du gameplay (les information ci-dessous proviennent du Topic du mod sur le forum officiel KSP) :
- Les moteurs sont adaptés au format RSS (isp, poussée, poids…). Ils sont sujets au ullage (si les ergols ne sont pas tassés au fond de leur réservoir, la combustion peut ne pas démarrer) et ont un nombre d’allumages limités.
- À chaque fois que c’est possible, les parts stock (type pods, réservoirs, etc) sont ramenés à des tailles, poids, etc qui sont plus pertinents et plus vraisemblables.
- Adieu le classique duo liquid fuel/oxidizer. Chaque moteur a maintenant un mélange d'ergols propre : kérosène, hydrogène, méthane... Il va falloir vérifier à deux fois si le carburant transporté est le bon. Et si un moteur n’a pas les bons ergols, il ne s’allume pas.
-Les panneaux solaires, rtg et fuels cells ne sont plus du tout aussi efficaces qu’en stock. Les RCS et les IRW sont aussi beaucoup moins puissants.
Et souvenez-vous bien que les exemples cités au dessus ne sont que des exemples... Ce modpack a pleins de fonctionnalités très très intéressantes pour jouer en RSS, qui le rend quasi indispensable. RO est donc le compagnon parfait de RSS, qui lui se veut réaliste sur la taille du système.
Notons que sans RO, RSS est très difficilement jouable. En effet, bonne chance pour atteindre les 7800m/s nécessaire à l’orbite avec les moteurs et réservoirs ayant des caractéristiques adaptés à notre bon vieux KSP stock.
Rappel : Nous vous conseillons très fortement d'installer ce modpack via CKAN !
Toujours depuis le Topic du mod officiel, voici la liste des mods figurants dans le modpack :
Advanced Jet Engine (un mod qui réadapte les performances des moteurs atmosphériques pour les rendre plus réalistes)
Module Manager (pour les moddeurs, une dépendance) Attention, il ne doit y avoir qu’un module manager dans votre installation ! Si vous en avez déjà un (via le pack RSS par exemple), c’est très bien, n’en ajoutez pas un autre (si vous installez via CKAN, ne vous souciez pas de cette remarque, il le fera pour vous) !
Nous vous invitons à aller voir le topic pour voir tous les mods recommandés ou suggérés, en ce qui nous concerne, voici une petite sélection de 5 mods très fortement recommandés pour jouer en RSS/RO :
MechJeb (au moins pour les informations à l’écran, ou pour vous aider au début)
ROEngines (pour avoir des moteurs historiques faits spécialement pour RO, un indispensable, vraiment !)
Hangar Extender (Pour ne plus avoir de limite de hauteur pour la construction de vos lanceurs… testé et approuvé, c’est essentiel)
Kerbal Alarm Clock(pour vous notifier les fenêtres de tir vers d’autres planètes, vos prochains de noeuds de manoeuvres etc)
Procedural Parts (pour faire des fusées 100% personnalisées, ce mod est quasi indispensable si vous voulez aller plus loin que juste de la recréation de missions historiques)
Et voilà ! Vous possédez maintenant tous les mods dont vous pouvez rêver pour une aventure taille réelle dans l'espace ! Encore une fois, ménagez vos machines, allez y par étapes sur l'installation des mods et faites des backups avant de vous lancer. Vous trouverez peut être ce discours redondant mais il est super important, vraiment ! Quoi qu'il en soit, profitez-en bien... et gardez un oeil sur nos réseaux pour de futurs défis sur le modpack que vous venez d'installer !
III - Conclusion et futurs défis
C'est bien beau, vous me direz, on vous a appris à installer ce superbe modpack mais maintenant, on en fait quoi !? On se sait pas où donner de la tête, par où commencer ni comment ! Pas de panique, on a tout prévu !
En effet, on prévoit de vous sortir des petits défis sur le modpack dans le futur (assez rapidement même), mais aussi des tutos pour que vous sachiez au moins où donner de la tête pendant ces défis. D'ailleurs, n'ayez pas peur de tenter ces défis à peine quelques jours après avoir installer le modpack pour la première fois. La difficulté sera crescendo et le tout premier défis sera donc très simple. En fonction de la date à laquelle vous lisez cette article, vous connaissez peut être déjà son sujet ! Globalement vous aurez le droit à de la recréation de missions comme nos challenges, mais en RSS du coup. Ce qui nous permettra de vous proposer des missions qui n'auraient pas été adapté au format KSRSS (typiquement, toutes les missions en orbite basse terrestre, qui du coup sont beaucoup trop simples dans un système à échelle kerbale). Bien évidemment ces défis auront un statut de second plan à côté de nos challenges officiels, ça ne veut pas dire qu'ils sont moins intéressants, seulement ils n'auront pas la priorité quand on travaillera sur un challenge, et donc leur date de publication sera à adapter en fonction de ces derniers (notez cependant que la personne rédigeant les articles des challenges officiels, Dakitess, n'est pas celle qui rédige les articles pour les défis RSS, on se répartie les tâches, et donc on réduit les délais !).
D'ici là, si vous souhaitez apprendre en regardant les autres jouer vous pouvez passer nous voir lorsque nous sommes en Live sur Twitch, lorsque c'est Alex qui diffuse, ce sera quasiment toujours du RSS/RO. Et, d'expérience, les personnes dans le chat sont souvent pleines de ressources pour nous expliquer certains concepts, et nous aider quand on bloque ! Ha et, si vous ne pouvez pas passer, les rediffusions sont sur notre chaîne YouTube depuis peu, vous n'avez donc aucune excuse pour rater nos diffusions !
D'ici là, continuez de nous suivre, et merci d'avoir lu l'article jusqu'ici, on espère qu'il vous aura aidé ! N'hésitez pas à le partagez, à nous suivre sur Discord, Twitter ou sur notre site, juste ici, et on espère tous qu'on vous reverra dans de futurs défis, voire challenges !
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 🙂
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 :
