swjr-swis

I have no objection to clipping. I tend to go for a specific look first, making it functional later - which regularly involves a fair amount of clipping. In KSP we get no option to weld or custom-design parts to take advantage of all the nooks and crannies that are usually available in a real craft after the outer shell has been decided on, so I see part clipping as the KSP equivalent. I do have some reservations about fuel-in-fuel, but even that I feel justified to use at times. Eg. when using Mk3 cargo bays as fuel+service bays, I have no qualms about heavily clipping two 2.5m tanks into each other in the bay, because the stock tank sizes for Mk3 parts make no sense - just compare with 3.75m tanks to see what I mean, or place a single 2.5m tank in an Mk3 cargo bay and see how there is easily at least as much volume still left empty all around it. Then there is my Hangar 51: the craft collected there have unknown alien origin and seem intent on violating physical laws as we understand them. Some of those craft may well employ pocket singularities to store Neutronium or Strange Matter as sources of energy for their engines... we just don't know.

Not to dispute the good looks,but erhm... Goliath? Been a while since I last used one, but they must've seriously shrunk in the meantime. Seeing as it''s about the same diameter as the Stayputnik, and those wings are actually FAT-455 tail fins.... I would say it's an mk0 LF tank with a Juno (smallest vs. biggest jet). Welcome to KSP, and the forum.

Radially: a small hardpoint or a Jr docking port with crossfeed disabled can be attached radially anywhere you wish at minimal mass penalty; slap a toroidal or an Oscar-B on it, and the fuel cell on the tank. This is the easiest because you don't even need to worry about disrupting other fuel flow on the craft. Bonus: you get to decouple the tank & fuel cell if you ever expend the dedicated fuel. Stacked inline: TR-18A - FL-T100 - TR-18A (or TR-2V - Oscar-B - TR-2V for 0.625m), fuel cells on the tank, disable crossfeed and staging on the decouplers, bypass the section with fuel lines as necessary to enable unhindered fuel flow between the rest of the craft. The TR-18As can be offset into the tank without looking bad, so it only adds a few parts and just the length of the one tank to the craft.

Maybe one (in the Real Universe) does not, but the game (in the Kerbal Universe) does. EC is treated exactly as every other resource (including solid fuel, which I now noticed I also forgot). One does not 'simply jettison' anything in a micro-gravity environment, but there hasn't been much outcry over why mining vessels don't fly off Gilly after instantaneously emptying highly massive excess ore; I wonder if we could run some nrs on the potential TWR of that ore jet. And if we are really worrying about conservation laws, having a few piddly electrons disappear without trace is several orders of magnitude lower on the violation scale than having tonnes of massive ore vanish into thin air, I would say. Anyway, the question I set out to respond was whether the Jettison button could be made to appear and work for, and I quote, "everything". The answer is yes. That's all.

A few suggestions, not mutually exclusive, for placement: Probably the most obvious/visible to find: behind 'Upload Craft' on the roll-down tab at the top center bar, it could say '(or use the KX Mod)' which links to the mod download page (https://kerbalx.com/mod). Or at least include it somewhere on the tab that rolls down. Somewhere in the page footer. Either in the vertical space between 'Suggestions and Feedback' and 'SpaceDock|CKAN Mod Manager', or added to that last one as 'KX Mod|SpaceDock|CKAN Mod Manager'. A small link somewhere at the top of the Mods page (https://kerbalx.com/mods), since someone that knows of the mod and comes looking specifically might see the huge 'Mods' in that top right corner and immediately consider it relevant and click on it. Definitely somewhere on the About page (https://kerbalx.com/about). It mentions CKAN, it even mentions and links the now rather obsolete Part Mapper... it definitely should mention and link the KX Mod. On craft pages, in the sliding tab that open after clicking 'Download', the second line says 'use the KX mod to fetch it when you're in KSP spacecenter view'. Make the 'KX mod' in that line a link to the download page. Not sure if this line shows for anyone that hasn't yet installed the mod and set themselves for deferred downloads. On that same Download tab, where it says 'turn on|off deferred downloads', you could add a '?' at the end that pops up a little window explaining what deferred downloads are and how they depend on the KX Mod - link). Like you already have to explain 'the slidery thing next to the download link' On the Dev Blog page (https://kerbalx.com/dev_blog), add a block at the top with the others, maybe between 'Want to suggest something?' and 'Found a bug?', that gives the download link and explains how to report bugs with the mod (the other one is just for the website, maybe should be edited to specify that too). The Statistics page (https://kerbalx.com/statistics) should start showing how many mods have been uploaded (and downloaded!) through the KX Mod. Not on the site itself, but really needs it as well: the OP of this very thread. It needs a link at the top, and a mention in the description. (Feel free to read 'preferably' and 'could' where I said 'definitely' and 'should' in my initial enthusiasm... after all, I'm not the one having to do the work. )

This is the part that does it. Should be easy to add for MM users. MODULE { name = ModuleFuelJettison } A quick test with cloned parts shows it works for any tanks containing Ore, Liquid Fuel, Oxidizer, Monopropellant, Xenon Gas, Ablator (heatshields), and even Electric Charge (batteries). All of them, when the above text is added, show the 'Jetisson Tank Contents' button, which when clicked empties the container. (I just realized I forgot to test 'Intake Air' and 'EVA Propellant' as well, but there's no reason to assume they'd be any different, although intake air would need to be set back to 'visible' in the resource.cfg to see it.) Obligatory pics-or-it-didn't-happen:

Beautiful, both the design and the mission execution.

Ok, thanks for the feedback. I worked a bit more on this (was not happy with the relatively tiny antennae either), so I removed the MMUs from the solar panel assemblies, and made separate ones. Working on a shuttle to use, I overkilled it with the main engines: in the test runs with a 41t payload, they took care of all maneuvres and still had fuel left after landing with the payload still aboard. I could add some extra engines for the visuals and call it 'OMS', but it would be rather pointless add-on mass. Would it invalidate a mission if the OMS goes completely unused? Also, does the OMS have to use other fuel than the main engines (iow, would I also need to add some tanks of something other than LFO)? The HLST-1c hits that target almost dead-on (5.513t), if you don't count the separate MMUs (puts it at 7.53t). That's with the LFO tanks completely empty (since it has no use for fuel); up to 12t can be added in fuel alone without needing any other changes, if one wishes to lug a heavier telescope.

I often employ the radial out setting of SAS to keep the reentering spaceplane on maximum drag in the highest layers of the atmosphere. Just keep in mind: if your spaceplane in low fuel circumstances doesn't tend to point prograde by itself, you need to know to pitch down before the drag gets too high. An additional tip, to help with the structural integrity: If you have the advanced settings on, a rightclick on parts will show setting 'Autostrut: Disabled'. Click on it to toggle to other options that will reinforce your craft. It may also help you need much less external struts, which would improve the aesthetic and the aerodynamics of your craft.

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.