Reprise du message précédent :
 
 
Pourquoi pas se servir du paramètre velocity plutôt ?  
 
L'idéal ça serait de savoir quelle est la fonction de la vitesse idéale en fonction de l'altitude.  
 

ce mod est en train de me rendre complètement dingue, ce soir je fini à rouler par terre en criant des noms de meubles c'est pas possible autrement  

faut utiliser des putain de POINTS partout sauf que la touche point affiche/masque le navball, et ya pas le bind de cette touche dans les options, putain de merde  

edit, j'ai réussi à freezer le jeu et planter mon pc

bon, kekchose m'échappe.

j'essaye de faire un prog simple pour stabiliser l'altitude, avoir une vspeed = 0 quoi.

le pb que j'ai semble plus venir du mod que de la réflexion (je sais que mon approche est foireuse )

genre je print:

altitude-80  :  ça marche
(altitude-80)/100 : ça marche
throttle : ça marche
throttle-(altitude-80)/100 : console plantée.

je demande rien de sorcier pourtant bordel  

Regarde comment j'ai fait dans mon bout de code.    
Sinon t'attends 21h que je rentre.

je commence à m'en sortir
 
je me tente le programme spaceX déjà

l'impossibilité de rappeler les dernières commandes c'est ignoble quand on fait des essais
 
mais bon, je suis proche de mon objectif

Attends.... T'as regardé ses vidéos ?

On a le droit qu au camion pourri avec la démo

rentré
Creator, je me demandais si tu te paluchais toute les lignes de scripts, ou si tu utilisais des fichiers .txt à mettre dans KSP_win\Plugins\PluginData\Archive
 
Puis switch to archives.  pour ouvrir le dossier
list.  pour voir les programmes dispo
et un run *nom du programme*. pour le lancer.
 
Rassures-moi très vite, bisou, ta grand-mère.

 
Je voulais essayer de maitriser la poussée en fonction du TWR, en prévision d'un programme pour faire du hovering ou une descente contrôlée.
Faudrait que je trouve une fonction simple de la terminale velocity... ou un truc en rapport avec la pression atmo, j'ai pas testé si on pouvait lire la pression avec les capteurs depuis KOS.

ben je faisais toutes les lignes en live dans la commande
 
mais bon entre temps j'ai compris son histoire de switch là, et ça va mieux
 
je suis en train de terminer mon autolander universel
 
en gros un script qui doit poser safe n'importe quoi qui est conçu avec un twr correct.
 
par contre je trouve pas le paramètre gravité, du coup en low grav je sais pas trop à quoi ça va ressembler...

 
Tu peux pas en direct, pour ça que je me demande si on peut l'obtenir via un des capteurs IG.
Semblerait que la commande stage:list donne des résultats, mais j'ai pas testé.

(oké
 
bon mon script marche au poil, manque juste un peu de fuel efficiency mais c'est loin d'être ridicule. Je suis fierté

après moult tests, le script est fin prêt
 
je fais donc un ultime test avec un kerbonaute suicidaire courageux...
 
le truc merde, cratère
 
ça valait le coup de tester
 
j'ai un paramètre "masse" qui merdoie un peu

 
balance ton script

edit: le gear on ne marche pas.

franchement ça marche trop bien
 
juste le direction retrograde qui est mou du bulbe, je sais pas pourquoi

merde j'avais laissé des "altitude" au lieu de alt:radar, du coup dans les montagnes ça marche moins bien

Y'a à qui ont du talent

Sinon à 00h ont aura un ITW de la Squad team avec peu être des exclus ici :
http://www.twitch.tv/pax

La 0.22 va donc s'articuler autour de 3 nouveautés
 
- l'arbre tech
- des modules scientifique
- sub assembly
 
(rajoutant une petite quatrième qui ajoute une fonction pour passer du VAB au hangar avion pour une construction)
 
 


 

 

Peuvent pas nous faire une soute à la B9 pour mettre du tiny dans du normal, et du normal dans du big ?

bon comme je m'y attendais je suis complètement accro à KOS
 
j'adore programmer, j'adore ksp, bingo
 
t'as fait d'autres trucs que ton orbiteur doc? on est que deux à utiliser kos?

putain le forum KSP est bien kerbal, premier post: erreur 500  

 
J'ai rien fait d'autre que les 2 scripts que j'ai linkés, car j'en ai principalement fait samedi, et j'avais encore la version 0.42 qui ne fonctionnaient pas avec les ressrouces...
Et hier j'étais à Paris toute la journée
Là je voudrais essayer un atterrisseur auto, mais le problème est que tu peux pas pointer simplement vers le vecteur prograde ou retrograde par rapport au sol... Peut-être essayer le steering en vecteur pour passer cet écueil.

 
ah bon? je vois pas ce que tu veux dire.

fonctionne, et

également. D'ailleurs je m'en sers pour mon autolander d'exception

Prograde / retrograde c'est dans le référentiel de vitesse orbital. Essaye de faire un décollage avec lock steering to prograde et admire la fusée partir à l'horizontal, protonM-style.
 
Lock direction to up c'est purement vertical, ça ne tient pas compte d'une arrivée inclinée. Ca peut marcher en atmosphère dense (Kerbin / Laythe / Eve), mais sur Duna ou dans le vide c'est crash assuré.

 
d'accord, ça explique pourquoi j'ai une vitesse horizontale à chaque fois au landing.
 
pour le deuxième point, je disais pas que ça pouvait servir pour corriger

Le truc que je vois pour refaire un atterrissage avec un vrai retrograde :
- stocker quelque part la vitesse orbitale induite par la rotation de la planète (un set orbspeed to velocity. ).
- Composer la vitesse réelle à partir de la vitesse hor + vert avec un ( lock truespeed to ( ( verticalspeed * verticalspeed + surfacespeed * surfacespeed) ^ 0.5 ). ).
Utiliser un lock steering to retrograde + V(xx,yy,zz) avec xx yy zz comme valeurs vectorielles.
Après je dis ça, mais la seule composante de vitesse qui ne modifie pas le vecteur prograde orbital c'est la vitesse horizontale...
peut-être qu'un qu'un steering to retrograde + V ( , , )  suffirait...
 
edit : bah non je dis une connerie, si je me déplace à la vitesse orbitale mais dans l'autre sens, le vecteur changer évidemment...
edit 2 : donc partir sur un lock steering to up, et le corriger avec un + V( , , ) qui tient compte des vitesses horizontale et verticale. Sinon du R ( , , ) mais faut convertir en angles avec de la trigo, et y'a pas de fonctions intégrées encore (mais on peut toujours faire avec des approximations..).

Et il fait comment mecjeb pour la fonction "atterrit là "  

ben trigo à fond
 
mais via KOS qui est une vulgarisation du modding si je ne m'abuse, on peut pas encore.
 
après moi j'aime beaucoup ce concept de pondre des programmes hyper crades, et que ça marche

 
J'aime bien l'idée de faire comme mechjeb, mais en codant ce qu'il y a derrière le bouton "go to orbit"

ouais voilà
 
pour moi utiliser mechjeb c'est du cheat, mais le coder soi-même c'est carrément trippant

C'est toi TNCreator sur le topic KSP ?

non, je suis un marchand de vaches sur le marché aux oeufs

 
je voulais dire topic KOS, mais j'ai raison épicétou.

Bon bah ça me semble assez insoluble en l'état.
Déjà bien évidemment, surfacespeed ne renvoie que des valeurs strictement positive. Je m'y attendais.
Verticalspeed peut être positive ou négative. Cool ça.
Par contre Velocity renvoie 3 valeurs (en x y et z quoi) dans le référentiel orbital.
En l'état actuel, sans possibilité de switcher dans le référentiel surface, je vois pas comment faire un lander fiable.

"fiable" peut être remplacé par "très solide"

 
Si ça kill pas la vitesse horizontale je vois pas l'intérêt Sinon c'est juste un auto-throttle asservi à la vitesse verticale.

pour l'instant sur mes essais, ça pose très bien comme ça sur kerbin. Bon reste à corriger les 10 derniers mètres, d'ailleurs je pense péter mon loop pour en refaire un à ce moment là plutôt que chercher la formule magique que spaceX n'a pas encore.
 
de mémoire, la vitesse H est bien existante mais carrément négligeable. Ce soir je peaufine et je raconte

Le problème est que je cherche plutôt quelque chose qui kill la vitesse horizontale même sans atmosphère. Or sur Kerbin, c'est cette dernière qui fait tout le boulot pour annuler cette vitesse horizontale.

je comprend bien c'est pour ça que je vais test sur la mun dès que c'est propre sur kerbin!