swjr-swis

Hi all, and @Speeding Mullet in particular. I noticed that the HST refered to for the STS-3 mission has not been updated for 1.2.x, which made me try and see what I could make. I think I achieved a very nice result, owing in part to several things new to 1.2.x. Can you please let me know if the below HST design fulfills the requirements for the STS-3 mission payload? If it is considered appropriate for the challenge, I don't mind it being used until the others are updated. https://kerbalx.com/swjr-swis/HLST-1a Two differences in particular: it weighs less than Alchemist's version; I hope that's not a disqualifier, but if it is, fuel can be added to the tanks to make up for the difference. Also more importantly, I integrated the MMUs in the solar panel assemblies - in other words, the Kerbals ride the panel assemblies themselves, and then EVA out of the seat back to the shuttle. It seemed like a good idea at the time... hopefully it does not violate the spirit of the requirements (2 panels, 2 MMUs). I plan on doing some of the STS challenges; time is a bit limited at the moment though, so it may take a while. Picture album is linked from the craft page, but a few teasers here:

I think the wiki still doesn't reflect some changes made in 1.2.x: 1.2.0: * Now always use g0 = 9.80665 and G (big G) = 6.67408e-11 for gravitational constants. 1.2.1:

...which manifests itself physically with the appearance -and disappearance- of asteroids within its SoI over time.

"Gravitato, ergo sum." Dres does not care what we believe: it dimples spacetime, therefore it is (and the bigger the doubt, the more seriously it exerts its existence).

Lo de analizar terreno: una vez en órbita, click derecho en el Stayputnik y abre el 'KerbNet' (o usa la tecla para encender las luces, lo he añadido ahí también). Eso abre la ventana con una imagen estática del terreno en el momento justo que lo abriste - con el tercero de los botoncitos de la esquina izquierda superior -dos flechitas en círculo- puedes iniciar que se refresque cada tantos segundos. No mencionaste antes que tenía que ser polar... eso necesita unos ajustes. He puesto una versión polar en mi Dropbox, con otro video de demostración. Instrucciones de vuelo son iguales, con estas diferencias: La he orientado hacia el Norte - 5 grados hacia el Este, para correjir la velocidad de rotación del planeta... de esa manera si solo tocas las teclas para bajar/subir la nariz, casi automáticamente la órbita queda perfectamente polar. Le añadí el combustible quitado de la última etapa, y reemplazé las antenas HG-5 por la 16, salvando peso. Esto permite una órbita más facil, aunque saldrá bastante más excentrica - y obviamente no tendrá el mismo alcanze de conexión. Intenta cruzar los 80 grados a 125-130m/s. Notarás que la trajectoria ganará más altitud, con un apoapsis de 100-140km. Apunta a unos 5-10 grados debajo del horizonte para la última etapa, activa a unos 2km de la apoapsis, y cuando el indicador prógrado esté en el horizonte apunta a prógrado hasta que se acabe el combustible. La órbita será fácilmente de 130x330km. La razón de dejar la potencia de la rueda de reacción a 5% es que en la última etapa, al no haber ni SAS ni aletas/viento, no hay nada que frene cualquier rotación que le impartas con los mandos de dirección, y al pesar casi nada es capaz de iniciar una rotación dificil de controlar. Por eso es cuestión de apuntar a base de 2-3 pequeños toquecitos cortos y rapidos de las teclas para ponerla en movimiento, y 1-2 para frenar. Movimientos (muy) lentos te mantienen en control.

No sé que decirte: lo he puesto en órbita una veintena de veces, sin exagerar, para registrarte a detalle las instrucciones de vuelo. Ni una sola vez se me ha descontrolado hasta volcarse; como peor, una de las primeras veces no lo llegué ha alzar suficiente, y después a lo más, un par de veces la periapsis se me quedó un poco baja al experimentar con el ángulo para la última etapa. Por el resto no falló de entrar en órbita. Hasta le quité un poco de combustible a la última etapa para que no se disparara la apoapsis (>300km). De todas maneras decidí intentarlo una vez más y grabartelo - 8 min. de video desde VAB hasta órbita (si te lo bajas se ve mejor que en el Dropbox, 32MiB). Notarás que me olvidé de usar el control fino hasta casi el final - con lo que quiero decir que en serio no entiendo cómo se podría descontrolar tanto y tan rapido como describes...

@marioquartz, el tutorial que mencionas es bastante antiguo, basado en las reglas del juego de hace varias versiones, y las cosas han cambiado bastante desde entonces. Mejor no mirarlo, porque confunde más que ayuda. Algunas pautas: Diseña el cohete de tal manera que el centro de masa quede lo más adelante posible. Fíjate también donde queda cuando los tanques están vacíos. Usa aletas de maniobra, cuanto más al fondo mejor - esto moverá el centro de presión bien debajo del centro de masa, que ayudará a mantener el cohete apuntando en dirección prograda; además ayudan a controlar el cohete. Pero reajusta la fuerza a 40-50% para que no se descontrole al menor toque. Ya que la tienes disponible, usa una rueda de reacción. Con más importancia todavía, reajusta la potencia - 5-10% es más que suficiente. Al no tener el SAS disponible, diseña el cohete -y tu plan de vuelo- de tal manera que el cohete se vuele casi solito, con el mínimo de correcciones de tu parte lo antes posible despues del despegue, para poner el cohete en una trajectoria gravitacional (gravity turn). Cuanto menos tengas que corregir, más estable será el vuelo. Si quieres, como ejemplo o para usarlo tal y como está, he puesto disponible un cohete aquí, usando solo piezas que según tu esquema tienes disponibles. Si lo usas tal y como es, estas con las instruciones de vuelo: prepara el vuelo (recomiendo que te pongas la vista de mapa a tu gusto, y el modo de control fino - caps lock en PC) despega, y permite acelerar a 25m/s empieza a empujar la nariz hacia abajo (con pequeños toques seguidos), intentando que el indicador prógrado cruze los 80 grados cuando alcanzes los 125m/s desde ese momento intenta dejarlo apuntando en prógrado, si puede ser sin más correcciones de vuelo - el cohete sequirá la trajectoria gravitacional por si solito (~55 grados @ 10km, ~35 grados @ 30km, ~30 grados @ 40km) activa las etapas 3 y 2 al vaciarse (resp. a ~10km y ~43km de altura), pero espera con activar la etapa 1 en la vista de mapa, confirma que la apoapsis sea de ~95km (de 70-95km puedes hacer órbita, pero será bastante más excentrica) intenta mantenerte a prógrado hasta superar los 70km abre el compartimento de servicio y desplega las antenas (grupos de acción 9 y 10, o si no los tienes todavía, también están combinados bajo la tecla para desplegar el tren de aterrizaje) apunta a unos 5 grados debajo del horizonte activa la etapa 1 cuando llegues a 2-3km debajo de la apoapsis, cambia a la vista de mapa, e intenta de mantener la apoapsis directamente delante de ti si todo fué bien, al acabarse el combustible estarás en una órbita de 95km - puede ser de hasta 95x125km si de algún modo la periapsis te queda entre 65-70km, aún es posible recuperarte: la fuerza del separador de la última etapa puede subir la periapsis hasta unos 5km - haciendo la separación en apoapsis y apuntando a prógrado.

Autostruts serve their purpose, so I don't want them gone. And I don't mind if they leave it on by default in wheels and legs if that is considered the echnically best choice for the main use cases. But I would like the ability to change the setting, like with every other part. There are circumstances that warrant other choices than 'Heaviest Part', or even to turn it off completely. It should be our choice.

From forum discussions on the matter of drag of stock/mod parts, and from other people's attempts at documenting the undocumented, and from my own experiments from back some time ago trying to make sense of how drag works. Unfortunately off the bat all I can find right now is the knowingly unreliable wiki section of CFG parameters (see in particular the descriptions of maximum_drag and minimum_drag). I've learned that when it comes to drag in KSP, using 'visual dimensions' can be very misleading, so I stopped trusting my eyes on that regard completely: Angled nosecones on radial stacks look (and should be) more aerodynamic than straight cones, but are more draggy instead. 'Aerodynamically' angling solar panels or radiators parallel to a surface that is sloped away from the pure prograde direction actually causes more drag than if you place them in the pure prograde direction, which visually makes them look like open airbrakes... but KSP drag physics minimizes drag in that position. The tail connector visually looks like it should easily be the most aerodynamic nosecone, and it is.... as long as you can make the craft stay perfectly prograde, because even the tiniest (and visually insignificant) deviation quickly transforms it into the most draggy cone of all. Control/lifting surfaces are 'drag-agnostic' in two directions... as long as the surface stays (mostly) parallel to the air-flow, those parts can be rotated with the wide or the narrow end 'into' the wind with absolutely zero effect on drag, despite what your eyes might tell you. Not to mention there are parts that effect their drag away from where you would visually expect it (eg. all 'physicsless' parts, struts and fuel lines, mk1/2/3 cockpits) And perhaps the most obvious example: KSP drag goes through everything, affecting parts that visually and intuitively should be shielded from it. So I've learned to distrust my eyes when it comes to KSP drag. Mine too, generally. Hence why I assumed that like pretty much every other part in KSP, the 16-S would also default to being placed in its most KSP-aerodynamic position. Instead, it defaults to the most un-aerodynamic, and requires an extra rotation step to correct it; not exactly common-sense behaviour.

I deduced this from the part's dragModelType (in DirectAntennas\C16S.cfg) being 'default', which as far as I know means drag is minimal when flying in its default/prograde direction, and increases when the part is angled away from it. By default, the game places the 16-S antenna rods perpendicular to the craft's prograde vector, requiring one to rotate it to make the rods point along the prograde. Hence my assumption. Well, there you go; so it's merely a visual issue and an inconvenience of having to perform an extra action to correct it being placed in the wrong orientation by default. Extra lesson learned: the default orientation of parts apparently has no direct link with the 'prograde' vector of their drag cubes. Good to know, thanks for testing. As far as I know, all other parts that use dragModelType = default are least draggy in their default placement and most draggy in either of the perpendicular rotations. My mistake was assuming consistency. Well, assuming consistency, and distrusting visual clues when it comes to drag. My two mistakes were assuming consistency, distrusting visual clues, and posting about something before exhaustively testing it. My three mistakes were assuming consistency, distrusting visual clues, posting before testing, and an almost fanatical devotion to cfg parameters. Argh. My four mistakes... ... amongst my mistakes were such diverse things as ahh.. let me come back to this in another thread.

Ya, with the introduction of Comms to the game, they changed it so any of the extendable antennae (iow. all of them) will break at almost any viable speeds, leaving only the fixed Communotron 16-S as the single option for science planes. Apparently that wasn't handicap enough, so they also made that one single option (and only that one) non-stackable, which means planes are still screwed for range when playing with some of the harder Comms settings. Adding insult to injury, they then also made the default orientation of that antennae perpendicular to prograde, making it more draggy when placed in its visually most aerodynamic orientation. I got tired of this nonsense pretty quick and edited the cfgs to make the extendable Communotron-16 safe to use again in my career game, like it was before (windResistance = 500 in ModuleDeployableAntenna, default is 1 - kPa dynamic pressure), and the 16-S to be stackable (antennaCombinable = True in ModuleDataTransmitter, default is False). The kPa value can probably be tweaked down to a more 'realistic' breakage point - you need to go close to Mach 3 at sea level to make even 300 kPa - but at this point it had irritated me enough that I didn't care to do anything more than just make it workable again.

I've been puzzling over this one for a bit now. Are you sure you're talking about the same thing OP is? First, I haven't seen that part for... well, a couple of versions now, not sure when it was. The current (1.2.2) part called 'structural pylon' looks like a tweakscaled large version of the small hardpoint. And second... the current part does not need this entire procedure to 'force' it to separate from the main craft... because it does so natively. It separates from the parent part, and stays stuck to the child part. Maybe my lack of sleep over the past days is playing tricks on me, but the trick shown in your link does not seem to work with the current pylon.

I would be happiest with a radial decoupler/separator that leaves no CoM/CoD-affecting residues behind, either on the (formerly) radially attached booster/missile/satellite/mini-plane or the main craft. But adding 'reversed' versions of the current ones that leave the residual structure on the main craft would solve most of my use cases for this. I would very much welcome the option of selecting to which end the small and large hardpoints stick when decoupling - preferably as a toggle instead of duplicating parts, as long as we're in wishful thinking mode (and why not do the same for the radial decouplers too?). Any residual structure of these radial separators (not decouplers) that comes loose of both ends should become negligible debris though, otherwise it becomes a liability in most cases.

Missile clusters and solar glitch vehicles... two of my favourite things.

I've seen that movie. It didn't end well for the poker, the rest of the crew, or the station...

Medio andaluz que soy, admito que de vez en cuando... hay un tanto de exageración en mis diseños.

¿Cuanto combustible quieres subir de una? ¿Qué tal te suena 38000 LF + 46000 Ox? https://kerbalx.com/swjr-swis/500t-LKO-Lifter

Why look for a reason? Whatever the function, that probe looks very... effective. Launch it anyway! Use the full link (the one that includes the image file extension).

We at the FBI do not have a sense of humor we're aware of.

Equally, grappling claws are not docking ports and therefore they do not work like docking ports, full stop. Yes? Oh wait, not exactly. RCS linear ports are not heat shields and therefore they do not work like heatshields, full stop. Actually, depending where you place them... Wheels are not pogo sticks and therefore they do not work like pogo sticks, full st.. ok I couldn't even finish that one without bursting into laughter, sorry. Seriously, the game is full of things that 'should not work like' and yet they do, a good bunch of them very intentionally due to physics engine limitations, workarounds, balancing choices and/or plain arbitrary decisions. For every intently single-purpose item introduced into the game, players have found a myriad of unintended and unimagined uses, and some parts practically only see use in the non-intended ways anymore. Squad has always known this, accepted it, and even applaud and encourage it. It feels very unreasonable to 'chastise' new players for being surprised and miffed at one of these arbitrary choices (and yes I venture to call solid-traversing drag an arbitrary choice because unlike drag, heating is in fact occluded by leading parts, so it would seem there is no inherent problem with simulating occlusion).

A bit of an odd argument. One could just as well legitimately ask why or how a user should expect that building according to known or expected aerodynamic principles would actually have no effect whatsoever on the drag (or in fact make it worse!). That placing parts in ways the in-game physics allow, and in which the game engine does in fact shield them from heating, still exposes them to 'magical' solid-traversing drag anyway. Would it not in fact be more 'surprising' from an in-game physics research point of view to discover experimentally that particles in a rather high density atmosphere are somehow dualistic in nature, both massive and massless in behaviour at the same time? That despite the derived aerodynamic laws, an atmosphere appears to actually behave more like a field than a molecular gas? Conversely, it seems rather odd to me to matter-of-factly term it 'cheating' when after one discovers experimentally that physics allow solid parts to phase through each other and take the same space at the same time, to then ignore that rather paradigm-shifting fact and not make use of it. In the world we call reality, doing such a thing would be termed 'applied physics' and considered brilliant engineering. How many things have we invented and made to work in 'magical' ways after discovering and understanding quantum physics? Are we cheating Real Physics(tm) because we make use of the practical aspects of experimentally derived results even though we can still not entirely explain them theoretically? I feel like I need Mr. Spock here raising his eyebrow. "Fascinating." Humans react so illogical... Like (the surprisingly un-troll-like ) EpicSpaceTroll139 said, you can zoom in all the way into the center of the part the camera is aimed at (right click menu), which allows you to see tanks that are clipped inside others the way you describe. Add a nose cone in front and behind of the clipped RCS tanks to at least minimize the drag incurred at very little added mass. And feel free to make up your own mind about what is or is not 'cheating' in this game, and under what self-imposed circumstances. There is nothing inherently or morally 'wrong' with using what we learn of the in-game physics to our advantage when applicable, or even to compensate for other physics quirks of the kerbal reality.

Just a quick remark: Tchaikovsky = music composer. Tsiolkovsky = rocket scientist.

Hola y bienvenido/a. Un par de cosas a tener en cuenta: El juego deja de simular naves/componentes que se alejan a cierta distancia de la nave enfocada. De hecho, hasta auto-destruye componentes alejados si se encuentran dentro de la atmósfera de Kerbin a menos de 25km de altitud. Está programado para hacer esto para evitar que la simulación se vuelva muy lenta. Desafortunadamente tiene como efecto que es prácticamente imposible el simular componentes reutilizables (como por ejemplo proveyendoles paracaídas). Cualquier componente desacoplado de la nave enfocada, el juego considera como fuera de control y ya no activarán nada que no esté ya activado. En otras palabras: a menos que enfoques en las partes desacopladas, nada cambiará, incluído el activar paracaídas en la próxima fase. Los paracaídas solamente se abrirán si los activastes a lo más tardar en la misma fase que desacopló esas partes. Claro que al enfocar en las partes desacopladas, pierdes control de la nave principal, y puedes quedar demasiado alejado como para enfocarla fácilmente otra vez. Los paracaídas se pueden 'programar' para que no se despleguen directamente al activarlos, sino que esperen a ciertas condiciones predeterminadas: en el menu click derecho notarás que ofrece el cambiar la altitud y la presión atmosférica, además de si requieres que espere a que la velocidad de caída haya frenado hasta que no haya riesgo de destruirse los paracaídas. Todas condiciones tienen que cumplirse para que abran. Por lo general, para aterrizajes a nivel del mar, yo siempre lo pongo a 1000-1500 de altitud y 0.75 de presión. Todo esto dicho, nada de esto salvará los componentes desacoplados si antes de desplegar los paracaídas o de aterrizarlos la nave enfocada se aleja demasiado y el juego los auto-destruye o los 'desactiva'. Por ahora, las únicas alternativas que tenemos son de 1) aceptar que perdemos las piezas desacopladas, 2) diseñar y volar con la intención (y todo el riesgo) de cambiar enfoque a medio vuelo de la nave principal a las partes que queremos salvar y de vuelta, o 3) usar uno de los dos mods especializados que existen para 'simular' el salvar partes reutilizable, cada uno con su propia estrategia:

There is a setting called 'Verbose logging' that can be enabled or disabled, under the 'General' tab of the main settings screen, under System on the right part of the screen. This is what toggles the output.log to be generated. Also, if you added anything in the launch properties of Steam or in the link you use for starting the game, the parameter '-nolog' can inhibit the log from being generated.

I've noticed a tendency of using the tail connector as a nosecone since 1.2pre, because of the 'pointier is less draggy' change made back then. While the drag nrs might seem tempting, I feel the need to point out that this wonderfully low drag is enjoyed only when the connector is flying exactly prograde in the airflow. Due to its length, even the slightest bit of deviation from exact prograde will very rapidly turn this 'perfect' nosecone into the draggiest part on a plane. The farther ahead of CoM it is placed, the more leverage it has, and thus tends to make for a very flip-happy craft. Unfortunately, it also shows that same drag behaviour when placed as a tail cone. Despite it seeming like it should be a very aerodynamic choice both for nose and tail, if the craft using it cannot be kept exactly prograde, it will actually be a very draggy part. The joys of calculating drag through cubes... I wish they had kept the 'B' and 'A' identical regarding drag. In the intended use case of slanting the cones to make the overall craft more aerodynamic, the slanted ones should actually provide a drag benefit, even if when looked at individually they would be more draggy than the non-slanted ones. Now they are un-intuitively always draggier than the straight cones. By letting them have identical drag figures as the straight ones, at least it would've averaged out over different use cases. Thanks for tabulating your test results, @GoSlash27. Well wishes (even if that means less KSP play ).