swjr-swis

Basically he constructs a 2nd stack by flipping a stack mounted on the rear node of the engine, and offsetting it to the side, but it has no noticeable benefit. What you're suggesting when you flip the intake on the rear node is exactly the same except for the sideway offset. You're creating a second stack drag wise. Sideways offset does not affect drag. @Val I think we're referring to different things. The case you refer to, building an entire second stack, is a different thing. Your quote is about that one. But as far as I understand it, Yakuzi does in fact show that the single inverted shock intake (and a whole host of other single inverted parts) on the end node of the engine offers a clear benefit over the non inverted one, in the paragraph and chart right before the one you quote: Several cones were rotated 180° along the horizontal plane as previously mentioned by RIC and evaluated as described above. Note: the Inverted variants were constructed from the terminal end of the LV30 engine and subsequently rotated 180° and translated upward as described by drewscriver earlier in this thread. The average maximum height and standard deviation (black error bars) of the various configurations are plotted below: The comment from RIC he refers to is this one: Which is exactly what I meant. And the chart clearly shows a much better performance. Btw, even in the second offset stack a la drewscriver, a 'no noticeable effect' sounds better to me than a clear detrimental effect of attaching anything radially, yes? But although indeed a lot smaller effect in that second chart, it still consistently shows a slightly better result for the inverted one than the regular placed one. So remains the objection of either method being 'exploitative', which will depend on the player and the situation (like challenge rules).

And the Juno comes to the rescue. I love the crap outta that little engine. Good work, Edax. I see that you are now doing the flip pretty much when atmosphere is practically irrelevant, so the control surfaces on the 'back' of the wings acting weird should have no effect, but I am still curious. Can you check and let me know if they act in reverse to the control inputs? I am still wondering if this is a problem I am only experiencing with my own ships.

@Val You're one of the leading experts in this forum on spaceplane design, so I am very reluctant to dispute your words, but since my own experiences do not correlate with what you stated, I decided to put this to experimentation. I designed 3 simple crafts, based on the same basic design. Top to bottom: Advanced Cone 1.25m probe core 1.25m reaction wheels 1.25m battery precooler (20 of 40 units of fuel so it flames out still well within the atmosphere and before heat damage happens) RAPIER set to airbreathing and on manual to avoid it trying to switch 01 - 'my' design: a shock cone on the bottom node, and rotated it 180 degrees to face front, clipped into the rapier, 02 - 'your' design: left rear node empty but added a couple (two) radial ramp intakes in 2x symmetry, 03 - for comparisson, just the basic design without either the shock cone or the ramp intakes. Note that in this test, 'my' configuration is at a distinct disadvantage due to the shock cone weight (0.13t vs 0.025t vs 0.0t). I didn't feel like resolving that by craft file editing, it was just a quick test. Note also that due to the precooler, the RAPIER has 100% air needs met in all three configurations from start to flame out, so any differences are not caused by lack of intake (even though the radial intakes only offer roughly 1/8th the air of the shock cone). I then ran three tests each: throttle to max, SAS on, stage to launch vertically from the pad, and record the max altitude and top speed (F3) as soon as it starts falling back down. Results: 01 - top speed 867m/s ±0m/s, max altitude 37716m ±5m 02 - top speed 870m/s ±0m/s, max altitude 35897m ±3m 03 - top speed 890m/s ±1m/s, max altitude 35648m ±1203m (very twitchy at top speed resulting in large deviations) Both 01 and 02 are very stable and consistent in results and keep to a pure vertical trajectory, so I didn't see the point of running more tests. 03 however got very unstable past Mach 2, enough so that SAS had trouble keeping it steady, ending the acceleration with a random vector about 1-5 degrees off pure vertical. Best result was still lower altitude than 01, and two results even lower than 02. So I am conflicted. At first sight the top speeds seem to somewhat agree with your statements, but keep in mind 01 is pushing 0.1t more weight.. so the radials being more beneficial is even then very debatable. I am very inclined to believe that the differences are more caused by the difference in weight than the difference in drag. It certainly does not seem that a shock cone rotated is 'effectively the drag of 2 stacks in one'; if anything it's a very marginal difference. And it definitely seems better than using the radial intakes. I'm open to hearing the math & physics explanation, but with these results I will be inclined to keep using the rotated shock cone rather than the radials, and leave it open only if all my intake air is already resolved otherwise and I am aiming for absolute max speed at the risk of more instability. I saved screenshots and craft files here, in case anyone else feels like doing a more statistically sound experiment. It's from a pure stock 1.0.5 install, so should be usable by anyone.

Depending on how you feel about clipping (or the kind of challenges you wish to enter) you could also simply mount the LV-N on the back, mount a RAPIER on the open node behind the LV-N, then offset it forwards until the backplane of both are level so neither one will harm the other when firing. That would keep both engine thrusts exactly balanced with CoM. (add a shock cone to the back of the RAPIER to close the last open node, then rotate it to face forward and offset forward to get it out of the exhaust area, and you also have air intake and drag reduction)

S.A.V.E.

En cuanto a variedad de piezas: los mods SpaceY (original, y expanded) de NecroBones siempre me han gustado por añadir más escala. Y una cosa pequeña pero la da algo extra a las naves - mejor alumbramiento con Surface Mounted Lights. Gráficos: he usado una combinación de EVE, Scatterer y Distant Object Enhancement en el pasado (hasta 1.0.4) con resultados bastante espectaculares, pero tienen bastante impacto en el uso de memoria, y me acuerdo que fue complicadillo llegar a una configuración buena. Kerbal Konstructs y KerbinSide me gustan por añadir más edificios y bases en Kerbin. StageRecovery para poder recuperar fondos y no siempre destruir gran parte de las naves que lanzo. Waypoint Manager ofrece mejor manejo de los destinos (o sitios ya visitados), y se puede usar en combinación con KerbinSide para navegar a otras bases. Custom Asteroids porque me gusta controlar la cantidad y el lugar de los asteroides. Facilidades del juego en general: Stock Bug Fix y Stock Plus - resuelve varios problemas que KSP tiene, y añade algunas cositas opcionales. Editor Extensions - facilita el trabajo en el editor. SAVE - un sistema para siempre tener copias de seguridad de tu carrera, ya que KSP sigue siendo KSP.

@Novak En caso que no lo hayas visto: Kerbal R&D se parece bastante a la idea que describes aquí.

Probably best suited for the Lounge section of this forum. But here goes: Kermageddon - Kerbin's Darkest Day will be Kerbals' Finest Hour Michael Bay (I mean, obviously. There'll be lots of explosions.) As an asteroid the size of the Western Desert is discovered barreling down on the planet, kerbal scientists work feverishly against the clock to save themselves from extinction. As the most viable solution depends on a crucial piece of equipment (found laying by the side of the road), they turn to its original inventor, Jebediah 'Bruce' Kerman and his unlikely team of misfits to do what no kerbal has been asked to do before: to prevent a global killer from hitting the planet. Halfway through the mission, Jeb thwarts the implementation of a Secondary Protocol that was intended to blow up the asteroid with the aid of nukes, and with the aid of his team turns the weapons into engines instead, using the thrust to capture the asteroid in an orbit around the planet, making it Kerbin's third moon and calling it Liz, declaring independence from Kerbin because as Val put it, none of them wanted to pay taxes again. Ever.

I do not think engine bells generate any more drag in KSP than if they were simple cylindrical parts; I think it just models the drag of an open top/bottom node. But if it did work as an airscoop: it would complicate the engine design a bit, but why shouldn't it double as a (slightly less efficient than a dedicated) air intake? All it would need is some type of valve system and some extra ducting to channel the air it catches to the jet at the other end. A few questions though, as I am looking at your picture: What kind of maneuver do you pull when you switch from jet to LV-N, presumably still less than halfway through the atmosphere where the jet cuts out? Once switched to LV-N and flying through the upper atmosphere in the other direction: how do you make the control surfaces on the 'back' of the wings (not directly visible but there's a shadow) obey normal controls for pitch and/or roll, instead of reversed? Whenever I've placed them 'backwards' at the front of a wing, they always act in the opposite way than I want them to - and 'invert' doesn't change that. Lastly: why worry about the cone+decoupler on the LV-N 'revoking the SSTO status'... if you have already staged and decoupled other parts (as deduced from the remnant of radial decouplers on the tips of the swept wings)?

@sal_vager I just tested this in a newly started default settings career. At the space center it took 8 days of advancing to the next morning, instead of a day, so maybe the respawn is a bit more random, but eventually the orange suits do come back: I then recreated another default career, made them MiA, let a single day pass, then left the game to main menu and reloaded, and all four were back again. So perhaps the randomness can be avoided by simply reloading the game. In any case, they do come back.

He can't hire, his roster is full (5 of max 5, the 'missing' kerbals are still counted as active). What he needs to do, since the two missing are orange suits, is probably as simple as letting a day pass of in-game time, and those two will magically reappear as available. Or upgrade the astronaut complex if funds and career settings permit to up the max nr of kerbals he can hire.

Like others have said, a GB or two three is pretty easily reached if you start collecting mods on an install. You're good. Now let's talk about the part where you talk about GameData as if you only have a single (as in one. uno. einz) install. You can't possibly be serious about KSP unless you have at least 5 separate GameData folders: a clean version to leave untouched, an unmodded of the latest version, a modded-to-all-heck of the latest version, a test-new-mods-before-adding-them-to-my-current-career-version, one to actually dabble a little into making your own mods/parts, and depending on how truly devoted you are, one or more of the above for every single previous versions of KSP that you still have a live career save in. The modded folders are of course 500-3GB each.

That would be my suggestion too. Don't try to render the net/foil itself with all the ripples and wrinkles - i think that's what shaders are for. In a realistic setting, people or equipment would need to be in the space between the net/foil and the asteroid surface, so it is reasonable to expect some type of framework that holds it 'up' a certain distance off or around the material of the asteroid. That framework can be the vertices of your low polygon model, and the stretched/tensed net or foil would become a pretty reasonable approximation of the faces. Then do the wrinkles and ripples with shaders, and simulate the flexibility with animated textures (if KSP does animated textures.. totally guessing here). Or better yet, stop listening to me trying to sound like I know of 3D modelling, and look for other existing examples. The Scatterer mod does a pretty mean interpretation of wavy open ocean surface, which is a much more flexible type of surface, so a semi-tensed net/foil should be easier/less difficult to do. Probably useful to look into that code for some ideas.

I've yet to see any of the trim controls in KSP actually do anything useful, at least in a pure stock 1.0.5 install which is the first I did any serious attempts at atmospheric flight. I know what they are and what they are supposed to do, I use it in flight sims, and it would be extremely welcome if they actually worked as advertised in KSP too... but I've yet to experience it. It seems like even breathing at one of the trim controls causes unwanted and often very unwelcome roll/yaw/pitch responses, so I've stopped trying to do trim. So. When they finally make trim work the way it is supposed to.. yes, I am all for it being fully rebindable in a joystick-friendly way (leering at my joystick gathering KSP dust in the corner of my desk). Preferably with a toggle to select the input to be read like an axis or like a key/button with the auto-repeat thing, cause I don't know yet which I might like best.

Pds314 was getting lonely on that FAR leaderboard, finally someone to keep him company. That's a fast-looking lil speeder, I like it. Try to balance it so that it is pointing just barely over the horizon, to minimize both water and air drag - it will also keep the skipping to a minimum which keeps it stable and safe for longer. That should enable it to get >200m/s on a FAR install.

Refer to the 'charge' in this table, considering that a proton is composed from 2 Up and one Down quark: https://en.wikipedia.org/wiki/File:Standard_Model_of_Elementary_Particles.svg A longer explanation: https://en.wikipedia.org/wiki/Quark#Electric_charge

@Rodger I tested this. I noticed a slight decrease in RAM usage, but the impact on the fps saw hardly any improvement. At least on this system, it seems that the kerbal animations is what most impacts the fps. Course this is just one system, so would be interesting to see others try out the difference and post their results.

@Bluebottle Not sure what happened for you, but I tested this with every single part that has IVAs in my 1.0.5 mod-test install. EVA, board, EVA, board, transfer, enter a different hatch than the one EVA'd from, etc. Both in prelaunch on the surface and while in Kerbin LKO. I never once got anything but the expected results. This is on a fairly modded install, 41 mods, lots of opportunities for bad interactions to show up, but it all just works. Have you tried again, maybe after reloading, to see if it happens consistently, or maybe just a fluke? I don't consider myself a modder, but since I sort of put this patch out there, I'm willing to take a stab at debugging this if you upload savefile and log of when it happens so I can try catch that Kraken and fry it up for dinner.

The portraits are removed, so the stats won't show either. The test I performed was on an install with DMagic's PortraitStats in it.

Mind over matter.

It needs to be said: Moar wheels!

Kerbals are not made of delicate flesh and bone. They use high powered vehicles almost exclusively for the thrust needed to escape gravity wells, and as a convenient way to keep their snacks from burning up in reentry. As Jeb once put it: "Hatches? We don't need no stinkin' hatches!"

Alternatively: weld your craft into a minimum of parts.

Add a couple of large, filled ore tanks to the wheels subassembly to combat any buoyancy of the craft, and most large craft should be safe (realllly slow, but safe) to drive there over the bottom of the ocean. Might even get some pretty pics out of the trip.

The Jebediah Kerman Way: just launch it as normal from the pad, but with just enough fuel to get it up 1000m, and add some clipped parachutes. Point up and float back down in whatever angle needed to make it come down vertically at the spot you want it displayed. (or be boring and practical and follow the other advice given )