swjr-swis

Hola Novak. Me gusta tu nave. Espero ver La Niña y La Santa María también. La he subido a órbita sin ningún problema al primer intento, pero no me da tiempo ya de hacer más. Unas sugerencias, ya que preguntas: Con simplemente colocándole unos conos aerodinámicos pequeños al reves de los RAPIER, le puedes añadir aerodinámica, lo que resulta en un tanto más de dV. No hace falta siquiera de moverlos porque no se calentarán en esa posición. Me gusta el esconder los strut y tubos por razón de estética, pero ten en cuenta que en cuanto a aerodinámica no hace diferencia alguna: la resistencia la añaden a la parte primera a la que conectan, no importa donde. Los disipadores pasivos que has usado solo tienen efecto en piezas de no más de dos separadas de donde los conectas. En este caso, casi no tienen efecto en los LV-N o el taladro, y solo parcialmente en el refinador, que son las piezas que más necesitan el control térmico. La batería se queda corta al enviar todos los datos de los experimentos a la vez - en especial el experimento gravimétrico se carga casi toda la batería todo solito. Vendría bién añadir. A la rueda delantera le falta permitirle girar, para poder cambiar direción en el suelo. Las de atrás necesitan alzarles la potencia de frenaje. Hablando de frenar: no tiene mucho para frenar en el aire, se le podría añadir un par de AIRBRAKE en el dorsal para atterizaje y para reentradas. El LV-N de la izquierda tiene una conexión rara con el cono 'shock' de la derecha. Cuando quitas el LV-N, se lleva también el cono. Lo note porque al subir a órbita noté que ese cono se recalentaba, pero el del otro lado no. Lo corregí quitando ese LV-N y poniendo uno nuevo, y reponiendo en simétrico el otro cono. Asunto de gusto: No tiene opciones de conectarse en órbita. No le vendría mal un puerto, y algo de RCS para controlar los encuentros. Si alzas las ruedas traseras un tanto hacia 'dentro' del tanque con el 'offset', el resultado es que se remontará en vuelo por sí solita por el ángulo positivo que le añade. Los dos conos shock no dan suficiente aire para permitir que los RAPIER se revolucionen al máximo antes de empezar el despegue. Desde KSC no importa porque es una pista larga, pero despegar con poca carrerilla en terreno más accidentado se hará dificil. Costará dV, pero considera añadir más aire de alguna manera. Un detalle: la manera como has colocado las piezas alrededor del refinador dejan el peso un tanto asimétrico. En maniobras con poco empuje esto se notará en un tanto de desviación. No creo que sea muy problemático, pero se puede evitar dividiendo las piezas con la simetría del peso en mira. Tienes una nave bastante guapa ya para empezar. Miraré con interés como progresa. Saludos!

The stuff I can build with it. The stuff others can build with it. The way I learn how to use something in a whole different way, almost every single time I play (or read the forum).

I love testing the limits of impractical designs in KSP. To me, it's one of the things I enjoy, almost every time I play. If it was down to just making what is practical, efficient and economical IRL, it'd be a very boring simulation that I would've stop using a long time ago. The way I see it, KSP gives me a set of laws and constraints that are valid for that one environment only. Period. Any extrapolation of it to any real or imaginary other environment, whether it be Real Life, or some other simulator annex game, or even another KSP install but with a different version or mod set, I consider pretty pointless. Sure, I love that it teaches me basic things that I could encounter in other places, like Real Life. But I try to never make the mistake of expecting things to work the same way. 1) because there's a limitation to the accuracy of the simulation, both due to complexity and to explicit choice of the devs. 2) because I don't have unlimited access to funds, materials, technology or timewarp that would allow me to do the same things IRL. Reversely, what would be the point of spending time in a simulation where I can't do anything more or different than what I can already do? I want to test the impractical, improbable, and impossible. Coincidentally, I'm having great difficulty with my attempt at getting a stock Enterprise to fly controllably in KSP. In this case, KSP limits me more than what Real Life would allow.

@michelcolman I tested this because I haven't seen this happen. It's not the reaction wheels, it's the CH-J3 avionics hub. Small truss, Z-200 battery and small inline reaction wheel on the launchpad, wheel torque enabled. All by themselves, even at top warp, EC remains at 200 units, which is what I would expect with the reaction wheel being idle. Same as 1, but now with Mk1 command pod on top. No change in result, the EC remains at 250 units even at top warp. Enabling SAS makes no difference (the reaction wheels remain idle since there's no any rotations to counter). Same as 2, but now with SAS enabled and click on hold normal to keep the wheels 'running'. The ship topples over and settles in a jittery balance, and the battery starts draining. However, as soon as I initiate warp the wheels go idle, and the draining stops, even at top warp. Same as 2, but with CH-J3 hub on top. By default no drain at all, but as soon as you engage SAS there is a drain, even though reaction wheels of pod and the separate one are 'idle'. Rightclicked pod and separate wheel to disable torque on both - still a drain. Drain keeps going even through warp. Rightclick on CH-J3 and toggle SAS off (which really means disabling the CH-J3): drain stops. The CH-J3, when enabled, will drain EC even through warp. This is to be expected and is consistent with the probe cores which also drain EC through warp. One could make an argument that command pods really should drain EC as well, even with their reaction wheels disabled - life support if nothing else needs EC. But that's for another thread.

@crashsolo36 Don't get your panties in a bunch. It's a game. I don't view challenges as competitions, I participate just to learn new build tricks and as a challenge to myself and the craft I build. I am neither accusing you of anything nor trying to steal your spot on this leaderboard (in fact @Pds314 feel free to retract my entry to keep the peace, I'm perfectly fine participating and sharing my success/failure without getting on the board at all). I simply asked a sincere question, because I would love to have a boat that remains stable on the water at 155-165m/s in stock: it has the potential of making some of the survey contracts a lot easier if I can replicate the technique in an exploration/science boat. So I have a genuine interest in figuring out how this works. Btw: I think you need to explicitly allow people to access that file. I get a permission denied when I click on the link. Again, I'm really interested in testing your design, because there's a lot of variables to the design (exact placement of the elevons and winglets, angles, dis/allowing pitch or roll control, etc) that I could easily have just off that prevent mine from working. If anything, it says more about my lousy skills in the KSP editor than about your ship.

No se si todavía buscas esto, pero algunas alternativas: Telemachus crea un mini-servidor por el cual se pueden ver datos de telemetría fuera del KSP, a través de un navegador externo (por fin algún uso para la segunda pantalla o el tablet). De momento no está marcado como compatible con 1.0.5 todavía, pero parece trabajar. Graphotron añade ventanillas dentro del juego mismo con los datos de telemetría grabados.

1. I like the idea, an 'AutoFixer' part that simulates the ability to self-repair. Like a packaged mini-robot arm dedicated to self-maintenance. Yes, please. Even if there is no visual animation to it at all (to save on complexity/effort making the part); just something that allows the rightclick menu options that an EVA engineer gives, within a certain range of the part - enough for a reasonably-sized rover. The part could be unlocked in the higher tiers of R&D automation and be fairly expensive, as a more sustainable contingency mitigation than simple redundancy of parts. 2. A bit further along the line, personally I would like Kerbal Krash to be relevant to this too, or any mod that adds damage generation/repair of some kind. Ideally 'repairable damage' should be a standardized attribute that can be handled by a ModuleRepair() for example, which would by default be part of both the engineer Kerbals and the AutoFixer part, and make the damage/repair system available to (other) modders.

Well, I gave it another 10 attempts, since you put it almost as a challenge. But no dice, I'll admit defeat. You're all free to try and claim the time if you manage, the craft is available, some of you look to be better pilots than I am. She may not be practical, but she's fun to fly. I managed twice to repeat the reverse landing just meters to the side of the runway, but then it took too long to roll onto it to make it valid; I keep underestimating how hard she can bank. The others I fumbled the controls one way or another, resulting in various degrees of destruction - least bad result of those was just one landing gear poofed (even though the rules don't state zero damage, I took it as implicit that the craft has to stay whole. Still wasn't a better time though so either way.). I know it can be done and the bloopers video shows it, 'just' a matter of letting her swing a tad wider, end up retrograde closer to the runway, and cutting thrust just before velocity is zeroed out (17-18m/s retro will still let her glide). With crazy amounts of lift and a pretty sturdy undercarriage, you can practically ignore the altitude and just concentrate on ending the turn in a stable retrograde and let her drop.

A better pilot than me should be able to do that, yes. Or if I could reliably use my joystick with KSP. That was in fact what I tried to do in the first attempts... as theoretically it would've been the fastest solution (you only asked for the heading to be 270... not the direction of flight at the time). But on keyboard and mouse I get confused in the controls as soon as she's reversing.

A faster entry to this challenge from the outerworldly Kreblons. Their pure stock Bird of Prey made the towerbuzz in 23s between engine start and zero forward velocity on the ground (0:15 - 0:47 video time). The entry video: https://www.dropbox.com/s/sinxfovl160so1m/KreblonBirdofPrey-towerbuzz-entry.mp4?dl=0 The bloopers (and some examples of what this bird can do): https://www.dropbox.com/s/llpjnt4xwcyqmis/KreblonBirdofPrey-towerbuzz-bloopers.mp4?dl=0 The craft: Bird of Prey original, and towerbuzz adaptation (drogues added).

Valentina felt that small and biplanes are both underrepresented in challenges, so here's an entry from her pure stock tiny biplane: https://www.dropbox.com/s/1owrjjkoe5t001h/Valentina-Towerbuzz-attempt4.mp4?dl=0 https://www.dropbox.com/s/grg3xr7tatrjesh/Valentina-Towerbuzz-attempt4.mp4?dl=0 (I don't have a youtube account so an MP4 file is all I can provide.) Not in danger of beating any records, but at least there's a biplane entry too now. A previous attempt, with some explosions. Watch her really buzz that tower, but fumble up the landing - only to retake into the air after stopping to redo it with half her wings gone and do a perfect landing that time... and in both cases only afterwards realizing she didn't use the chute. (already have the recording, might as well get some entertainment out of it.) https://www.dropbox.com/s/ctw7bgh7tidsaa0/Valentina-Towerbuzz-attempt3.mp4?dl=0 https://www.dropbox.com/s/bvcnsnzo9xucuo3/Valentina-Towerbuzz-attempt3.mp4?dl=0 Craft file: Tiny Biplane 3c (towerbuzz version) (I was already rigging up a version with sepratrons for accelerating and breaking, but I see @Darren9 ninja'd me on that idea.)

@Mr Shifty Any chance of adding Ike to the table? Never mind, I just figured out why it's omitted. Funny my brain noticed Ike, but not Gilly 'missing'.

I'll have a think or two on suggestions and scenarios. One of my first thoughts, that as good as it sounds is likely not practical to include: media releases of the competitor's launches including pictures (could quickly spiral the MBs of the mod, plus the work of taking all those pics), or even short clips (even worse in MBs and workload. Are there even any hooks in KSP to play AVIs or animated GIFs?).

Very interesting, missed it before but I'm definitely following it now.

I only ever look at the gimbals when a craft is clearly uncontrollable due to it, which is not often, not even when I use vectors (and despite some pretty out there designs). And even then I tend to just disable it completely rather than tweak it. I'd say about 95% of my engines stay on defaults, <5% get their gimbal disabled completely, <0.1% their gimbal gets tweaked to a lower but non-zero value.

I'm not too sure about playing separate careers/contracts against myself. But I would not be opposed to a space race element, having an AI entity across Kerbin pushing my career to match or beat their achievements, while bound to the same starting set of rules. Would be fun if it also included saving some of their stranded Kerbals sometimes (or having to eat my pride and call them in for assistance, mutter). Bonus points if end game is something like cooperating for a joint KSS, Duna base, or Jool system stations. I'd install that mod. Hint hint.

Turboload! Ah the memories. <tweaks tape head alignment and rewinds> A flag (and agency) I have been using for my modded games... still hasn't been deployed in 1.0.5:

Agreed that it's the worst possible combination, and that it would be very welcome to have rotation persist through warp. But only if they also make SAS continue to keep attitude through warp at the same time, please. Right now having it stop all rotation is the next best thing (or least worst thing), as it at least makes things somewhat predictable. Having rotation work but not SAS through time warp would create a nightmare of having to check all craft in orbit after every warp, to ensure they did not end up with their panels oriented all wrong.

You can't IVA, because the cfg removes the internals. But you can still EVA: click on the hatches, the EVA button will be there.

@Jimbodiah Rocket in my Pocket already gave you a link to a ready-made Module Manager cfg file that does disable the animated portraits altogether. No static images though.

Oh the irony: the ex planet cost us our planet x...

Be thankful: you might've spent those hours mining ice in Osmon instead...

That makes two of us.

First: agreed that Squad already has their hands full. No criticism here on that. I'm only passionate about this because it would improve the design process so much. But: I am inclined to disagree that this is either tricky to design or massive to code. There is already code to calculate and show drag vectors on all separate parts, fully coded in the game: the flight scene F12 aerodynamics display. Currently that display shows a vector per part, and perhaps in the flight scene it's maybe too much of a calculation impact (or it's done on purpose to give us a more detailed view of drag), but would it not be as 'simple' as combining those separate vectors into one, with code very similar if not identical to that used to combine the lift and thrust vectors of multiple parts into a single CoL/CoT? In the VAB/SPH that exact same code could be reused for this purpose. The only thing missing there is a vector for the velocity through the air. Obviously there won't be a 'live' velocity, but all it needs is to add an UI element for the player to create an artificial velocity. The UI for this can reuse elements already coded in the game as well: an extra button showing a combination/derivative of the rotate/offset gizmos would in my opinion be very intuitive/fitting with the rest of the interface. For example, add only the 'up/forward' arrow of the offset gizmo to the circles of the rotate gizmo, and call it the 'drag gizmo'. Click and drag the arrow shorter or longer to set a high/lower artificial velocity, click and drag the circles to rotate the direction in any of the planes, and you got your vector. The aero display code can use that artificial velocity vector to draw the CoD. Since in the editor it's purely informative, the calculation doesn't need to be continuous (just recalculate when the drag gizmo is used), so performance impact could be almost negligible. To keep it as minimal work as possible and really just reuse existing code, I'd already be happy if all the first iteration did was show the exact same thing as the F12 aero display in the flight scene. Not as quick and easy to understand as a single ball marker like the CoT/CoL, but it would be something, whereas now we have nothing but our gut feeling and trial and error to go on. Am I way off that all these elements are essentially already in the game?

Or it could be prophetic, and millennia from now a copy of that cfg will be on display in the Alpha Centauri Museum of Propulsion as an example of the first discovery of neutrinos-to-quark-paste-cycle engine...