Archive for the ‘Les Mods KSP !’ Category

OptiGT : A la recherche du Gravity Turn parfait ! (Partie 1)

jeudi, juillet 22nd, 2021

Hello !

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 :

Abaque Opti GT

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 !

Posted in Les Mods KSP ! | No Comments »

KSRSS : Présentation, installation

lundi, avril 20th, 2020

Présentation

Vous vous demandez sûrement, puisque vous vous retrouvez sur cet article, ce qu’est Kerbin Size Real Solar System. Commençons donc depuis le début : c’est un mod, et plus précisément, un mod qui vise à remplacer l’intégralité du système stellaire par un autre, et pas n’importe lequel : celui de la vraie vie, à une échelle 1/10, c’est à dire à l’échelle de base des planètes que l’on a l’habitude de voir sur KSP, en stock. Contrairement à son grand frère RSS, donc, KSRSS est fait pour être joué et jouable avec les pièces de base du jeu et des DLC. C’est donc une voie médiane entre le réalisme extrêmement poussé de RSS et le côté arcade du jeu purement stock. Au delà de cette pure et simple mise à l’échelle de RSS, c’est aussi un revamp de l’intégralité des terrains des planètes, passant par des textures totalement customisées et exclusives, des reliefs améliorés et bien plus encore.

KSRSS est également accompagné d’un second mod frère, KSRSS Visual Enhancements. Ce dernier, comme son nom l’indique, est un mod visant à largement améliorer l’aspect visuel de KSRSS au delà du simple terrain. Il ajoute de nombreux effets atmosphériques, tels que des nuages sur la Terre et Venus, des geysers sur Encelade et Europe, des volcans lumineux sur Io, des tempêtes de poussière sur Mars… 

À ces deux mods peut également être ajouté KK-KSRSS, pour KerbalKonstruct-KSRSS. Ce mod permet la compatibilité avec de nombreux autres mods ajoutant des launchpads et installations, permettant notamment de profiter d’un KSC plus fourni en installations, et de nombreux site de lancements alternatifs disponibles ailleurs sur le globe, comme à Kourou ou à Baïkounour.

Installation

L’installation peut vous paraître un poil ardue, mais ne vous enfuyez pas tout de suite ! Ce petit guide devrait éclaircir bien des choses. Avant d’entrer dans la procédure d’installation en elle-même, il vous faut comprendre une chose particulièrement importante : l’installation de KSRSS + VE est modulable. Vous aurez à de nombreux endroits à choisir différentes résolutions de textures, ou différentes versions du mod. Bien que cela complexifie le processus d’installation, cela vous permettra d’adapter KSRSS à votre matériel informatique, et d’éviter ainsi de vous retrouver avec un jeu extrêmement laggy.

1. Prérequis 

Tout d’abord, veillez à avoir une installation propre, neuve, de KSP en 1.8.1, sortie du dossier Steam. Vous ne savez pas comment faire ? Rien de plus simple, nous vous renvoyons à ce tutoriel qui vous expliquera comment faire. Une fois cela fait, veillez bien à supprimer le fichier « settings.cfg » qui se trouve à la base de l’arborescence de votre jeu, là où se trouve l’exécutable du jeu (cf screen ci-contre).

Enfin, si vous ne savez pas installer de mods, prenez le temps de lire ce tutoriel, qui vous expliquera tout clairement et vous simplifiera la vie. Il serait bien maladroit de se lancer dans l’installation de KSRSS sans savoir installer de mods.

 

 

 

 

 

 

2. KSRSS 

Il va s’agir désormais ici d’installer le cœur du mod : KSRSS. Ce mod et ses dépendances permettront d’intégrer au jeu les planètes du système solaire. Vous aurez ici le choix entre différentes résolutions de textures, veillez bien à prendre celles adapter à votre configuration matérielle.

      1. Installer Kopernicus
      2. Installer KSRSS
      3. Installer KSRSS-Textures. Vous aurez ici le choix entre 3 résolutions différentes : 4k, 8k et 16k. Plus la résolution est élevée, plus cela consommera de RAM. Nous vous déconseillons de prendre la version 16k si vous avez moins de 8GB de RAM.
      4. Lancez le jeu, allez dans les réglages, catégorie « Graphisme », et configurez les détails du terrain à « KSRSS ». (cf screen ci-dessous)
      5. Configurez la qualité shader de terrain au maximum. (cf screen ci-dessous)
      6. Activez, si vous le souhaitez, la dispersion de terrain. (cf screen ci-dessous)

3. KSRSSVE

Bien que KSRSSVE ne soit pas formellement nécessaire, nous vous conseillons fortement de l’installer, puisque KSRSS n’a pas été pensé pour être joué sans l’une ou l’autre des deux versions de KSRSSVE. En effet, ce dernier se découple sous deux versions : Lite et High. Comme leurs noms l’indiquent, l’une est spécialement conçue pour être légère et optimisée sur les petites configurations, tandis que l’autre est plus lourde et optimisée pour les grosses configurations. Ainsi, si votre processeur est inférieur ou égal à un Intel i3 >3GhZ et que vous n’avez qu’une carte graphique intégrée à celui-ci, nous vous conseillons la version Lite. Si vous êtes au dessus et que vous possédez une carte graphique équivalente ou supérieure à une Nvdia GTX 1050 >2GB VRAM, la version High s’offre à vous !

3a. KSRSSVE Lite

      1. Installer EVE
      2. Installer KSRSSVE. Vous aurez ici le choix entre deux versions : choisissez « Lite », bien évidemment !
      3. Installer KSRSSVE-Textures. Vous aurez ici le choix entre deux résolutions : LR & HR. Puisque vous êtes sur la version Lite, nous vous conseillons de prendre la version « LR », qui consiste à avoir des textures de nuages en 8K.

3b. KSRSSVE High

      1. Installer EVE
      2. Installer Scatterer
      3. Installer KSRSSVE. Vous aurez ici le choix entre deux versions : choisissez « High », bien évidemment !
      4. Installer KSRSSVE-Textures. Vous aurez ici le choix entre deux résolutions : LR & HR. Ici, libre à vous de choisir ce que vous souhaitez. Les textures en HR consistent en des textures de nuages en 32k, tandis que les textures en LR ne sont qu’en 8K. Si vous avez une grosse carte graphique, foncez sur les texture en HR !

3. KK-KSRSS

 

NB : KK-KSRSS ne sera mis à jour que pour la version finale (1.0) du mod. Il n’est actuellement PAS à jour pour la dernière version de KSRSS et ne le sera pas dans les prochaines versions.

Support, Changelog, Roadmap

En cas de soucis, de bugs, de questions, ou n’importe quoi d’autres, nous assurons un support sur Discord : rejoignez-nous à cette adresse.

1. Changelog 0.6

Reliefs & colors :
– New heightmap for Enceladus, Mercury
– New colormap for Enceladus
– New reliefs for Venus
– Improve reliefs for Moon
– Improve Florida
Ground textures :
– New Steep texture for Venus
– New Ground texture for Moon
Bugfixes :
– Fix MaxZoom for Ryugu, Halley, Chouri
– Fix ScaledSpace -> PQS transitions for Ryugu, Halley, Chouri
– Scatters no longer in water.
– Fix Saturn rings
– Fix rim for Titan, Saturn, Jupiter
– Fix offset of Normal/Heightmap for Moon
Scatterer :
– New config for Mars
EVE :
– Fix DetailDist for Earth clouds
New bodies :
– Add Mimas, Thethys, Dione, Rhea, Iapetus
– Realistic heightmap for Mimas, Thethys, Dione, Rhea, Iapetus
Gameplay :
– Add support for localization (thanks to @Rezzagoan)
– Add french translation (thanks to @Rezzagoan)
– New launchsite at Kourou and Baikounour
– Fix warpzone for Titan

2. Roadmap

Pour les prochaines mises à jour, nous souhaitons ajouter les corps encore manquants, que ce soit les lunes joviennes, neptunienes ou uranienes. Au delà de ce simple ajout de mod, voici une liste non exhaustive de ce que nous souhaitons faire à l’avenir :

  • Refaire la majeure partie des configurations scatterer
  • Ajouter de nombreux scatters custom
  • Améliorer les colormaps pour de meilleures vues orbitales
  • Améliorer les reliefs de certains corps
  • Avoir une texture de terrain par corps
  • Rendre KSRSS compatible avec différents mods (Principia, etc…)
  • Créer un installateur pour rendre l’installation plus simple

Conclusion

Nous remercions l’équipe du KSC de nous offrir un espace où présenter notre mod, et espérons que cette présentation et ce guide d’installation vous auront été utiles. N’hésitez pas à nous contacter à la moindre question ou suggestion.

KSRSS-Team.

Posted in Les Mods KSP ! | 1 Comment »

[KSP Mods] TweakScale !

lundi, décembre 25th, 2017

TweakScale est un formidable mod vous permettant d’ajuster à la volée une grande partie des Parts de KSP, sans en introduire de nouvelles. Ça va trop vite ? Reprenons dans l’ordre 😉

Dans KSP, vous êtes par défaut limités à quelque centaines de Parts disponibles, et que vous pouvez assembler à votre guise pour façonner vos créations. C’est généralement très suffisant, et c’est même un défi pour beaucoup de joueurs que de s’en tenir à ces quelques Parts qui font toute l’identité du jeu, et qui ont été imaginées par les développeurs, en étant cohérentes les unes avec les autres. D’autres joueurs préfèrent utiliser des mods qui introduisent des packs de Parts, permettant d’avoir de nouveaux réservoirs, avec des diamètres plus imposants ou plus petits, des propulseurs qui vont avec, etc : mais que faire pour concevoir une petite sonde avec un petit générateur radio-isotopique et de tout petits panneaux ? Télécharger un mod juste pour ça, avec les risques et galères de mises à jour ? Avec un design pas du tout raccord avec le reste du jeu ? Et s’il n’existait même pas, ce mod ?

C’est là qu’intervient TweakScale  qui, comme son nom l’indique, va permettre d’ajuster l’échelle des Parts du jeu, de manière totalement libre, pour obtenir les composants de la tailles de votre choix, avec précision. Et le plus fort, c’est que les caractéristiques de ces Parts vont automatiquement être mises à jour pour correspondre au nouveau volume que vous avez défini ! Ben oui, autant cela est simple avec les réservoirs, dont la masse (et la capacité !) augmente au cube de la modification d’échelle, autant cela peut être plus délicat pour les propulseurs, les panneaux solaires, les antennes, les… Nous allons le voir avec bien plus de précision par la suite, mais sachez que l’algorithme en place permet une très bonne évaluation des paramètres d’une Part, de sa masse à sa « capacité principale » (fuel, électricité, portance, puissance…) en passant par le prix ou encore la résistance, c’est vraiment formidable et on dispose d’un mod dont on peut avoir confiance en matière d’équilibrage, ce qui est une donnée essentielle.

Certains pourront arguer que ce mod va un peu à l’encontre de l’idée de base de KSP : IRL, quand on joue aux Lego, on ne peut pas augmenter ou diminuer certains éléments et l’on compose avec ce que l’on a, un avis légitime que plusieurs joueurs du staff de KSC partagent. Heureusement, nos tests en matière d’équilibrage révèlent une superbe réflexion sur le Scaling des Parts et de leurs paramètres, et nous sommes persuadés que la plupart d’entre vous franchiront le pas : après tout, c’est optionnel, c’est simplement la possibilité lorsque vous êtes coincés dans le miniaturisme, de pouvoir réduire la taille de quelques Parts indispensables, pour aboutir à quelque chose de réaliste, soigné, et réfléchi : que du bon 🙂

Un avertissement néanmoins : vous ne pourrez pas partager vos créations ayant subi une transformation d’échelle via TweakScale avec des installations qui en sont dépourvues, même si cela ne concerne qu’une seule Part. Faites donc attention, si vous avez l’habitude de partager vos crafts, d’évaluer si cela vaut le coup, ou tout simplement d’avertir les joueurs que TweakScale est requis ^^ 

Et pour l’installer, c’est comme d’habitude, on télécharge, on décompresse, on copie-colle le contenu du GameData dans le GameData de votre installation KSP !

Allez, quelques exemples de ce que permet TweakScale et de ses impacts ? Vous allez voir, c’est réfléchi 🙂

Posted in Les Mods KSP ! | 3 Comments »

[KSP Mods] Deadly Reentry !

jeudi, décembre 21st, 2017

​

Ce court article va se focaliser sur le mod Deadly Reentry, en présentant son intérêt et les modifications qu’il induit, puis en proposant un petit guide d’installation rapide : un nouveau mod qui ne devrait pas quitter vos installation de sitôt !

DR est un must-have pour beaucoup de joueurs qui recherchent du réalisme. Ce mod permet en effet de rendre plus crédibles les réentrées atmosphériques, du point de vue de la résistance thermique de vos modules, en agissant sur le modèle de la diffusion / dissipation de la chaleur et sur l’ajustement de plusieurs paramètres et valeurs. Exposé à de trop fortes températures, vos boucliers (car vous en aurez besoin !) commenceront à fondre voir à prendre feu, menaçant l’intégrité des équipement qui se trouvent derrière… Vous comprenez pourquoi ce mod nous semble tout indiqué pour le Challenge KSC2 – VENERA ! C’est l’occasion ou jamais de le découvrir par la pratique, ensemble 🙂

Ce mod n’implique aucun autre changement, de sorte que vos habitudes ne devraient pas trop être chamboulées : pas de modification du modèle aéro notamment. Il fixe simplement des contraintes un peu plus réalistes, du côté de la résistances des parts à la chaleur et des risques associés à une réentrée trop brutale. Il va falloir apprendre à trouver le bon angle, la bonne altitude, surtout quand on vient d’une trajectoire interplanétaire ! 😀 On est à peu près sur que ça va vous plaire, ça ajoute une petite tension très appréciable pendant cette phase critique d’une mission spatiale, qui semble un peu trop simple dans le jeu de base.

Point de vue installation, c’est tout bête et dans la plus droite lignée du mode opératoire habituel :

  • Téléchargement de l’archive
  • Décompression
  • Copier-coller de l’ensemble du contenu du dossier GameData vers le GameData de votre installation KSP
  • C’est tout, enjoy ^^

N’hésitez pas pour toute question relative à l’installation ou à l’utilisation de ce mod, vous trouverez de nombreux conseils auprès des joueurs habituées, via le forum ou sur notre Discord ^^

Pour commenter cet article, cela se passe dans le forum, comme d’habitude 🙂

[KSP Mods] Deadly Reentry !

Posted in Les Mods KSP ! | 3 Comments »

[KSP Mods] Présentation et installation de SSRSS !

vendredi, décembre 15th, 2017

Un rappel usuel d’entrée de jeu : comme rappelé plus loin dans ce document, ce tutoriel a été écrit pour KSP 1.3.1, et les choses sont parfois amenées à changer, surtout pour des mods comme celui-ci qui en intègre plusieurs autres : en fonction de votre version de jeu, les mises à jour et compatibilités peuvent poser problème, et il va de soir que la page officielle de SSRSS fait foi ! Toutefois, soyez assuré que nous testons régulièrement la méthodologie de ce guide qui est la plus générique possible, et que nous cherchons à le maintenir à jour : si vous rencontrez des problèmes, posez vos questions dans le forum en suivant le lien en fin d’article !

Le système stellaire du jeu par défaut, dont l’étoile porte le nom de « Kerbol », est plus petit que le notre d’un facteur 1/10 environ : cette différence d’échelle remonte à longtemps, et résulte de plusieurs problématiques techniques mais également de considérations purement Gameplay : ce facteur de réduction permet des mises en orbite de moins de 5 minutes, en lieu et places de longues 20min de surveillance active si Kerbin était à l’échelle de la Terre.

Toutefois, de nombreux joueurs à la recherche de réalisme ont choisi d’utiliser un mod d’ampleur : Real Solar System. Ce dernier permet de jouer à KSP dans notre système solaire, fidèlement reproduit en matière d’astres, d’inclinaisons, et bien sur de tailles. Cela permet la reproduction de missions historiques dans les moindre détails, des modules aux trajectoires en passant par les temps de transfert.

Partant de ce plaisir d’évoluer dans notre système IRL, de fouler le sol de « Mars » plutôt que « Duna », de visiter les nombreuses lunes de Jupiter, de redécouvrir soi-même le sol de la Lune, des modders ont proposé un intermédiaire bienvenu : SSRSS, dont l’acronyme signifie Stock Size Real Solar System. Les moins anglophobes l’auront compris, ce mod permet aux joueurs de disposer du système solaire, mais à l’échelle du jeu par défaut : la terre est ramenée à la taille de Kerbin, et les autres astres et distances suivent en conséquence.

C’est là le moyen de se faire plaisir tout en conservant les parts Vanilla du jeu, sans devoir ajouter de nombreux packs de mods nécessaires à la bonne expérience de RSS, sans réapprendre les bases difficilement acquises sur un KSP classique. Ce sont ces avantages que nous vous proposons de découvrir dès maintenant, car l’ensemble de nos challenges se baseront sur une installation SSRSS !

Vous allez donc pouvoir suivre ci-dessous la procédure d’installation, pour que chacun parvienne à la même chose, sans doute possible. N’hésitez pas à poser vos questions sur le forum en suivant le lien habituel tout en bas de cet article, nous y répondrons rapidement pour palier toute problématique 😉 La démarche reste sensiblement la même, au fil des versions de KSP et des mises à jour du mod, mais quelques petits changement peuvent apparaître : si c’est le cas, n’hésitez pas à nous en faire part, pour qui nous puissions continuellement faire vivre cet article ! Dans tous les cas, c’est la page officielle du mod qui fait foi, bien sur. Allez, vous allez voir, c’est plutôt simple, SSRSS est une compilation de mods interdépendants, qu’il convient simplement d’installer pas à pas, dans le bon ordre.

Oh, et… Est-il nécessaire de le rappeler ? Ce genre de mod ne s’installe que sur un dossier KSP PARFAITEMENT clean, stock, vanilla : utilisez le mot que vous voulez, mais il est capital que vous partiez d’une installation KSP vierge de tout mods. Vous savez comment faire, n’est ce pas ? Sinon, direction ce mini-tuto, vous en avez pour quelques minutes à peine :p​

Dans un premier temps, on se rend sur la page officielle du mod, et comme pour 99% des cas cela nous mène sur le forum de KSP où beaucoup de choses se passent, point de vue communauté. Sur cette page plutôt austère, vous retrouverez le petit guide d’installation ci-contre, et c’est ce que nous allons nous attacher à décrire dans ce petit tuto, pour les plus anglophobes d’entre vous et pour éclaircir quelques zones d’ombres potentielles 😉
Ce petit guide liste les étapes dans l’ordre qu’il importe de respecter, traduisons le rapidement  avec quelques corrections : comme bien souvent, la « normalisation » des consignes n’est pas le fort des moddeurs ^^ On leur pardonne sans mal face à l’étendu de leur travail.

  1. Télécharger et installer Kopernicus
  2. Télécharger et installer RSS (Uniquement le dossier RealSolarSystem !)
  3. Télécharger et installer les textures RSS
  4. Télécharger et installer Sigma Dimensions
  5. Télécharger et installer le dossier SSRSS
  6. Télécharger et installer Kronometer si vous souhaitez que les journées durent 24h
Vous l’aurez remarqué, la logique est toujours la même, d’abord télécharger puis installer… Qui a dit que ça allait de soit ? :p Cela étant, on peut se simplifier la vie en commençant par tout télécharger proprement, dans un premier temps, et l’installation se fera ensuite. Ça évite de jongler entre les multiples onglets internet, les archives, les dossiers… Faites nous confiance, c’est plus simple 🙂 Il n’y a donc qu’à suivre les liens qui précèdent, un par un. La plupart (tous, en fait) redirigent vers Github, interface qui ne donne pas spécialement envie, avec plusieurs liens. C’est bien simple, choisissez toujours le premier, au format .zip !
Une subtilité pendant vos téléchargements, à la 3ème étape : plusieurs qualités de textures RSS sont disponibles. Plus les valeurs sont élevées, plus il vous faudra une configuration musclée pour faire tourner le jeu équipé de ce mod. Il convient donc de faire le bon choix, l’élément le plus limitant ici sera votre carte graphique ! Difficile de vous donner des standards, mais un PC fixe Gamer (équivalent NVidia 1050 et plus) devrait faire tourner sans trop de souci la version la plus élevée. Concernant le pack de textures le plus faible (2048.zip), il n’est pas très exigeant : si votre PC portable un peu vieillissant fait déjà tourner KSP correctement, cela ne devrait pas l’handicaper plus que cela ! La version intermédiaire sera à destination de… Tout ceux qui se trouvent entre ces deux extrêmes :p
Une fois tout cela téléchargé, vous devriez vous retrouver avec 6 archives, c’est à dire 6 dossiers compressés. Vous pouvez utiliser Winrar, ou simplement utiliser l’utilitaire intégré à Windows 10 pour ceux qui en disposent, pour décompresser tout cela en 6 dossiers distincts. Pour l’instant, c’est aussi simple que cela, mais c’est une étape à ne pas négliger ! Comme ça nous auront une base d’installation bien claire pour la suite : 6 mods = 6 dossiers décompressés.
  Hé bien c’est parti, on reprend l’ordre d’installation ci-dessus, et on ajoute les mods de manière tout à fait classique, copier-coller du contenu du GameData de chaque mods vers le dossier GameData de votre KSP ! Pour le premier, Kopernicus, vous devez donc copier-coller 2 dossiers et deux fichiers, prenez bien l’ensemble du contenu du GameData. Comme évoqué précédemment, certains moddeurs sont un peu à la peine en terme de normalisation… Et c’est justement le cas du second à installer, RSS… Pas de GameData. Pas grave, cette fois vous copier-coller le dossier « RealSolarSystem ». Rien à signaler pour les textures RSS, qui correspondent au dossier 2048, 4096 ou 8192, selon la configuration que vous avez choisi : contenu du GameData. Idem pour Sigma Dimensions, SSRSS et Kronometer, qui sont dans les règles ! Si tout s’est bien passé, vous devriez terminer avec un GameData côté KSP qui ressemble à l’image ci-contre. D’éventuelles mises à jour d’un ou plusieurs mods peuvent légèrement différer, bien sur, mais ça reste peu probable pour ces mods presque « institutionnels », qui ont cette structure depuis longtemps déjà 😉 
Il est temps de tester tout cela, lancez KSP comme vous le faites d’habitudes, via KSP_X64.exe, patientez quelques dizaines de secondes le temps que les patchs prennent effet sur le jeu, pendant le chargement, et contemplez le continent sud-américain apparaître, en lieu et place de la planète fictive Kerbin ! Si vous avez cela, c’est que l’installation de SSRSS et de toutes ses dépendances s’est bien passée, et qu’il est temps de renommer ce dossier KSP d’une manière pratique et intelligible, pour ne pas vous tromper. Quelque chose comme… KSP 1.3.1 SSRSS par exemple, pour l’actuelle version du jeu ? 😉 

Bien sur, si vous rencontrez un souci, le plus sage est de reprendre à zéro en supprimant tous les dossiers dans votre installation KSP, à l’exception de « SQUAD », bien sur. A partir de là vous pouvez retenter votre chance, patiemment et avec rigueur ! A nouveau, si vous constater une différence entre ce guide et celui publié sur la page officiel du mod, c’est certainement que ce dernier a été modifié et est plus à jour : il faudra donc le suivre, les changements seront certainement mineurs, et si possible nous tenir au courant pour que nous puissions mettre à jour ce petit guide. 

Et comme toujours, pensez à rejoindre le topic ci-dessous pour commenter cet article et poser vos questions !

https://kerbalspacechallenge.fr/forums/topic/mods-ksp-presentation-et-installation-de-ssrss/

 

Posted in Les Mods KSP ! | 3 Comments »