Vaisseau tout-en-un Aller-retour Laythe/Kerbin

[Dakitess]

Yexank, la valeur de boost reste assez commerciale, attention ^^ Elle répond même à quelques règles de mise en condition parfois difficile à atteindre.

D'autre part, cette valeur boost sera d'autant plus importante que la valeur de base est élevée On offre pas 3.9 GHz à un proco cadencé à 2.3 GHz nominal.

[yexank]

Si on ne peux pas, c'est avant tout une limite du moteur physique... la gestion des collisions entre pièces étant en temps réel, accélérer le temps détruirais forcement la fusée.

[Dakitess]

Pas vraiment de raison que ça ne génère une explosion non, je trouve. Suffirait d'une simple accélération comme le warp classique, qui se découple de la gestion physique et devient purement visuelle. La consommation du carbu peut même se suivre par extrapolation perte de masse quoi.

Du coup, arrêt du warp proche de la fin d'injection et on retourne a l'État physique. Ça me semble pas si complexe perso...

[yexank]

fait l’expérience, tu met une grosse fusée sur le pas de tir, accroché à des bras de maintient, tu crée un stage avec une broutille, exemple un parachute, et tu l'active afin de déclencher la physique de ta fusée. Ensuite, tu passe en warp à grosse vitesse, et là tu te rend compte que la simple rotation de la planète suffit à tordre complétement ta fusée, et à la faire exploser... alors imagine avec l’accélération d'un moteur.

[Dakitess]

Je sais bien, c'est pour ça que je dis qu'ils peuvent parfaitement implémenter un warp équivalent à l'existant, un warp visuel qui décroche de la simu physique, en prenant compte de l'état du module : carbu, profil de consommation, perte de masse en conséquence... Et l'utilisateur reprend le pas sur le mode classique à la fin, en finalisant son injection avec ses nouvelles caractéristiques : nouvelles réserves de carbu, nouvelle masse, etc etc.

Ca ne me semble vraiment pas compliqué à implémenter... Tout comme la gestion des vaisseaux en approches, qui n'ont pas foncièrement de raison d'être chargé de fond en comble. Un docking devrait pouvoir se faire avec un visuel parfait sans réactualisation des parts du vaisseau visé ! Ca allégerait considérablement les manœuvres complexes...

Tu vas me dire, comment gérer l'impact avec l'élément visé ? En simplifiant considérablement. Par exemple, une hit box commune à tous les éléments d'un bloc, chaque bloc étant délimité par les liaisons souples de types Dock et éventuellement découpleur. Après tout, c'est cohérent, les pièces sortie de conception sont bien intègre, seuls les liaisons à détacher sont délicates à mettre en oeuvre. Fin bon voilà quoi, un machin segmenté en 20 hitbox et quelques liaison docks au comportement toujours disponible, ça me semble devoir être une évidence de développement qui tarde à se montrer, que ce soit dans les faits, ou en projet.

[yexank]

En fait tu dit de faire comme font 90% des jeux, c'est a dire créer des ensemble de pièces quand tu les relis, sauf que c'est difficile a faire avec le moteur de jeu de KSP, qui a choisis une approche complétement différente, et qui simule chaque pièce indépendant. Faire ce que tu dit avec un moteur de jeu "classique" c'est assez simple, mais le faire dans KSP impose de complétement réécrire le moteur physique du jeu, et même en faire tourner deux en même temps... et là c'est difficile.

[Spacex]

Il faut juste que KSP gère mieux le multi coeur ou la CG et c'est réglé. Bon facile à dire
On est HS sinon non ?

[Dakitess]

Yep, suis passé dans les recommandation 0.22 moi