swjr-swis

As part of creating a submission for a challenge that mandated using low heat-tolerance Mk1 parts, I found that placing a linear RCS port in front of an Mk1 cockpit allowed me to push it harder through the sky before it would explode from heating. So I would say that it still works, at least for heating, not sure about drag.

Here's an MM script that enables this functionality on the stock ports, showing that it already exists in the game: We really just need a way of accessing/changing this in-game.

Some versions ago, Squad already build in the possibility to do this into the docking module code. It can be enabled and configured for the stock ports through an MM script. What the stock ports are missing is tweakables to access these configuration options in-game. (and let the discussion begin regarding basic vs advanced or editor vs in-flight).

Is there a reason we are being so secretive about the 'guy' and his thread, that we don't mention either his name nor the specific thread this is all refering to?

Instant flash back to those side-scrolling 'lander' and cave-exploring type of games from the ole 8/16 bit era, navigating our tiny ships without hitting the walls (too hard). Sigh. Fine. I'm off to dust off and hook up my C-64 again...

@saik0 was/is the maintainer of the site, at least until some time 2015, according to this thread: But has shown no forum activity since 2015. Also, April 2015 the site was down for a bit too, and then came back. I did find a full download of (a version of) the maps here, and a set of biome maps for Kerbin/Mun/Minmus here. I think they are pretty much guaranteed to be out of date though, and the 1.2 pre-release dev notes mention numerous updates to biomes that will definitely not be in there.

Rambling's fine , as long as you understand I am not complaining about the F3 screen; it is what it is. I was just providing a quick reality check showing that there is no point to expect the numbers on that screen to be 100% accurate or anything but purely indicative.

Link corrected, thanks for spotting that. The fairings in 1.2 can do this: they are very heat resistant and they can pack something heavy out at the tip on a interstaging node.

@IronCretin, an entry for the current top of the board: JupitersBolt, pure stock, 1.2.0p, 43x Juno, 801m/s record speed. Talk about diminishing returns! I may be able to squeeze a bit more out of it, I packed way more fuel than it needed for the suicide record run; but for now it serves for a first spot. Craft file: https://kerbalx.com/swjr-swis/JupitersBolt Pics:

You can get 1.2pre from the KSp store as well, not just Steam: The aero physics in 1.2pre have been altered a bit. I haven't seen details, but one comment from Squad said something about pointy things having less drag and blunt things getting more.

Ok, an entry fully my own, the AltJet-0g: 15 engines (the old max. 14x RAPIERs, 1 Juno for the alternator) 232627m altitude reached - 232627 points 2 pilots and 4 passengers - 40 points All kerbals survived - no deduction All parts survived - no deduction Total: 232667 points Craft file: https://kerbalx.com/swjr-swis/AltJet-0g Imgur album: http://imgur.com/a/Ww8rt

It's the Greys again...

I would be in support of such a thing. I have left a few missions behind on old saves due to the time required to sit through even a max time warp making it take more time than I had available. The game can already calculate the on-rails trajectories and even show how much time it will take to get to a certain point in the orbit (maneuver nodes do this). So the code could simply assume its projection accurate and simply skip all craft ahead x time on their respective projected orbits even correcting across any SoI changes. Of course if any of the craft have a projected periapsis too near a planetary body before the chosen time, there should be a message and it should disallow, just like the existing time warp slows or stops when that happens. Even if we accept that such a time skip would come with some inevitable loss of accuracy compared to regular time warp, it could be an acceptable trade off in some circumstances (and would make testing and 'simulating' certain interplanetary missions a lot easier/less off-putting).

As a quick illustration: take the Wobbly Strutter test craft I posted earlier in this thread and get it into its maximum wobble by releasing the center docking port autostruts, and waiting a bit. Then while swinging, autostrut the center docking ports to 'root'. Unless you are extremely lucky, you will notice they end up frozen/locked at some distorted angle, wherever the ore modules were in their swing as the autostrut code engaged. This same thing happens, in less but sometimes more exagerated ways whenever a docking/staging/part explosion event happens, as the autostruts are all reconnected at such moments.

Here's a video of a V1 replica I built back in 1.0.5, complete with launch ramp, with the Old Airfield as target. It was designed to not need any input from me other than setting the required fuel amount, and then staging it for launch. It's not valid as an entry under your rules because although it was designed to fly without input, I did leave the reaction wheels on and allowed SAS stability to adjust the control surfaces (which in my opinion is a more accurate representation of the V1, since it did have working control surfaces and gyros, it was more like a drone/cruise missile than a fixed fin ballistic missile like your rules propose). In the video I was still fine-tuning the fuel amount, so you will see exactly one user input after launch: cutting the power at (almost) the right moment to initiate the dive to the target, because I noticed I had still left a bit too much fuel in it. The tanks included in the ramp allowed to fine-tune the fuel by transfer before launch, and then the V1 would initiate the dive automatically by virtue of its fuel running out at the right moment. The control surface movement you see is not user input, it's the SAS stability helplessly trying to prevent the stall, stalling anyway due to no propulsion, and then settling into a dive angle. All I was doing at the time was moving the camera view around. Then the 1.1 release happened and killed the wheels allowing the rocket to slide properly over the launch ramp. I may revisit it again once 1.2 is released.

Not true: If your ship/station is under some torque due to flight stresses or flexing/moving, and you perform a staging or a docking, or a part explodes somewhere on the craft - in short, any event that makes the part tree redo itself- the autostruts will at times manage to relock your craft with parts in am exageratedly flexed or dislodged position. This problem becomes worse as you add more autostruts. Also, the setting of where they attach to can worsen a construct, if one picks poorly. Using them more than sparingly and without thought is a sure recipe for trouble.

This basically. Launch a vessel, immediately hit F3: 175m/s speeds reached, 10m covered/traveled, etc, and your vessel hasn't even had the time to let physics kick in yet. If you're in the habit of taking screenshots of top speeds, altitude, distances etc (for challenges or for testing) you'll constantly spot differences between what your in-flight screenshots prove you did and what the F3 screen of the same flight reports. Treat that screen as purely indicative, no more.

You know what, never mind. I said I didn't want to continue this.

Agreed. I don't understand why we are not allowed to control the wheel autostrutting the same way as the other parts. There's plenty of cases where 'heaviest' is really not the option you want. And of course the off option to make our own suspensions and constructs.

"This game-enhancing feature I rarely use must be invisible at all times to everyone because my playing style in particular demands it!" Reads the same to me. As for universe altering: that is a core mechanic of the game, because of it being a game to begin with. Think about it: you literally do it ALL. THE. TIME, no matter how hard you try to play 'realistically': You start a new game: you select a few dozen universe altering parameters that will define basic things about how your game is going to work. You build a ship: you select, levitate, lego-click and reposition parts weighing tonnes to assemble a ship. You launch: ship gets materialized on the runway or launch pad. You EVA or transfer: kerbals magically teleport from one spot to another, phasing through solid walls if need be. You switch from orbit view to the space center: you just magically transferred your consciousness to another place millions of km away (or switched your telepathic control to another kerbal, pick your poison). You use time warp: ...seriously, you use time warp. You repair a wheel: wheel with completely shredded rubber instantly gets rematerialized. You land with an open chute: poof it disappears from existence the moment you touch down. Repack it: poof the chute is completely reset and ready in the blink of an eye. You take one step within 200m of another vessel: it suddenly becomes affected by the laws of physics, which it wasn't just one step ago. Why do we accept all these mindbogglingly unrealistic things as normal? Because in most cases they help keep the game pleasant rather than tedious or frustrating to play. It's pretty arbitrary to then go and pick any particular feature, that adds some quality of life to the game for at least some people, and argue that that one thing, of all things, clearly needs to be hidden several more clicks away in a Alt-F12 cheat menu, because that one crosses our personal line. I do agree with you about some way to reduce the tweakables, because there are a lot now and we each have a set that our particular style of play requires to be most handily available. Hence my feedback report to ask Squad to allow us to configure this ourselves. Beyond that though, I will continue to disagree that your or anyone else's personal preference and convenience has some type of overruling 'rightness' over mine, by virtue of 'realism' in a cartoonized game. I really don't want to continue this argument. Text sounds too harsh too fast, and it being just a game, I don't want either of us to be negatively affected over what is and should be simply a pass time.

EVA is not a fast action, it takes time. A station can have shaken apart in the 30 secs it takes to EVA and maneuver a kerbal to the location, let alone go through whatever steps we come up with as an appropriately realistic representation of 'manually' strutting things. Which let's be honest here, in the end will still be a matter of getting your kerbal within a magic distance for a magic floating rightclick menu button to appear (that only we see, not the kerbal). So we replace one game magic by an entirely different game magic, except now it is more elaborate and takes more time to achieve, allowing the shaky wobbly physics enough time to get some swing into the station, leaving us to try attach 'real' struts on a dancing target or watch parts destructively swung away into a new orbit. I'll take the less time-consuming and frustrating autostruts any day over that, and quite gladly call it a much more realistic experience - that docking ports, just like in real life, actually achieve a sound mechanical connection automatically all by themselves as part of the hard dock clamping, without need for EVA or manual intervention.

I did a few things, mainly to improve the survivability and then to improve performance a bit: Added two pairs of the smallest elevons, front and back - increased lift for the landing, and more effective pitch authority. This made the biggest difference in survivability. Changed the two existing elevons on the wings to only act for roll. Their arm was too short to be of much effect for pitch, so at full deflection they were causing a lot of drag for hardly any pitch authority, especially when at speed - decreased drag. Angled the front set of wing sections by 2 degrees up - increased angle of incidence permits the body to stay closer to prograde, decreasing drag (Mk2 parts do add body lift, but at the expense of a good bit of drag, so it still pays to minimize angle of attack). Widened the rear landing gear - increased stability at touch down. Increased the damper on all gear by .15 - reduce the bouncing at touch down. Corrected the angle of all gear to be exactly 0 degrees horizontally (the editor still places the LY-10 at 5 degrees up angle when you 'zero' it, even in absolute mode) - reduces drag. Re-angled the rudder to be at 0 degrees and offset it lower - more or less same visual effect your design went for, but at 0 angle it removes the sneak pitch and reduces roll when yawing. I wondered how long it'd take for you to show up.

Yes. Once you enable autostrut on the docking port, when docking, it automatically reconnects all autostruts. The way the game re-roots things when you connect vessels almost guarantees that 'grandparent' or 'root' are in the station, so it ends up rigidizing your docked connection. There is unfortunately little direct control on what exact part autostruts will attach to, as obviously both 'root' and 'grandparent' are completely relative terms and may change with each docking event. The only sure thing I can think of is to make sure that your station packs a very heavy part specifically for that purpose (say, a large ore tank filled with ore), and then set autostruts on docking craft to the default of 'heaviest'.

There's is really no mystery. The Whiplash you use as engine starts accelerating hardest at lower altitudes, earlier, and then even at 90 degrees spends slightly more time (seconds, but still significant) at high speeds plowing through the still thick atmosphere. The RAPIER Gaarst uses starts accelerating hardest a few km higher, later, and then accelerates faster, so it has both less thick atmosphere to burn through at top speeds *and* spends less time cutting through it. In his plane, the cone and the cockpit get heat bars to the very limit, and any angling away from exactly 90 degrees, prolonging the time in the atmosphere even a few seconds, is enough to make it explode. That is exactly what yours does: spend a few more seconds in the atmosphere, by starting early and cutting through it slower. That tiny bit of difference makes all the difference between just barely surviving or exploding.

I reworked that craft a little, and made it so it practically glides in for a landing and has less bouncing at touch down. Landed it safely and easily 3 out of 3 attempts. On top it also managed to get a slightly higher altitude the third attempt (205056m). Nice little craft. (If this makes it to the board, credit to Gaarst, it's his design). Retouched craft file: https://www.dropbox.com/s/c50ohvkzjf452te/Banana.craft?dl=0