swjr-swis

Kaptain's Log hace lo que pides:

If this is true, and not just a weird typo, you need to do yourself a favour and get the latest version. At least you'd be on a supported version then.

Ok, so just an arbitrary change compared to previous versions then. It's your challenge, so you get to set the rules - that's fair. I just thought I had missed something since it came up after there had already been several accepted entries with nukes. So moving forward with the no-nuke rule, two corrections the OP needs: You still have a rocket listed in the Rocket Only category that uses a nuke as last stage (Fauble2000's 27.336% fraction, at the moment in 3rd position, Nerv visible in the last screenshots). It now belongs in the Unlimited category. He still has the valid 1st entry in the rocket-only category, so it should not upset anything. You forgot to mention 'no (...) nerv' in the Rocket Only category description. See below:

While it is true that KSP is mostly CPU bound, an Intel HD integrated GPU has to run very hard to do the graphics, and heats up the CPU at the same time - which already gets taxed with all the physics calculations. On top of that, it uses shared system RAM for video and textures, warming that up as well, and having to share the same bus. The additional heat, in a laptop, will quite quickly force the CPU/GPU to start throttling cores down to manage it. Try to find the detailed settings for power management - the high level default 'performance' setting is no guarantee that you're really getting the best speed out of the system, often in the detailed settings there is still considerable limiting going on. Just be aware that it will lead to higher temps and may thus not really help in the end - you can't completely stop CPU/GPU from throttling. I haven't seen it on Linux, but on Windows the Intel HD graphics driver itself has a set of performance settings as well; see what you can tweak there. Mostly though, I think you'll have to lower your graphics settings considerably, especially the graphic detail and effects. A big gain could come from using whatever tool you can find to force-limit the FPS for this game at a fixed, low value (KSP does not honour its own setting and will race frames at max speed at regular moments in the game); I've found 30 fps to keep fans quiet on some lower spec laptops I've installed KSP on. As said above, use a cooling pad - they do have some effect,but don't expect magic. Make sure there's no dust obstructing fans and air vents. Not sure what else to offer. I would really suggest upgrading to a discrete graphics card, but most laptops don't allow that option.

Were some posts deleted from the thread? I've gone through the whole thread again and I can't see what prompted this change. What is the reasoning... what does this fix?

The Desert Explorer design you have in the SPH in that zipped save also has the forward cargo bay door open to 6%, which would explain that. I think I also found what makes the plane so bouncy on touch down: the front gear appear to be doubled with mirror symmetry, but clipped fully into each other so it appears to be just one. As I can't help myself, I did some tweaking on your plane in the SPH and created an Mk2 version. It resulted in a very nicely controllable craft that lifts off by itself just by applying full throttle, happily cruises at around 500m/s at 9km (oscillating +/- 500m), and lands a lot better and less explosively. It can be flown with SAS off too, with trim/throttle. You can download it from here: Desert Explorer Mk2b Full disclosure of the changes I made compared to your original: Closed the front bay door. Reattached the engines and the main landing gear to the cargo bay instead of the wings. This helps against the flexing and the random collisions when landing. Used the rotate gizmo in absolute mode to align the engines and main/front gear perfectly prograde. They weren't in the original. Swapped the wing position of engines and gears - just seemed more logical. Pulled the two front gear separate from each other. I left the pair instead of just one because I favour using two of the medium gear on Mk3 plane noses - it helps them tolerate heavier loads, and minimizes rolling/veering at take off if the plane decides to 'wheel-barrow' with light loads. Rotated/offset the cockpit ladders to their snap position. Added them to AG0. Added one fine 'tick' of angle of incidence (5 degrees of pitch up compared to the body) to the wings for better lift/drag performance. This also moves the CoL closer behind the CoM. Added one fine tick of dihedral (5 degrees up towards the wing tips) to add some roll stability. With the wings a bit higher, there was room to offset the engines up, bringing the thrust vector closer behind the CoM and granting more ground clearance for rougher landings. Offset the engines forward to bring the CoM closer to the center of the 1.5 cargo bay. Offset the wings backwards to align the CoM even closer to the bay center, and slightly lower to not clip the bay door hinge. Emptied all wing fuel to see how CoM shifted, and adjusted engines and wings in the length direction until the CoM stayed centered in the bay regardless of fuel load. Cargo and fuel load won't matter this way. Replaced the large tail rectangle wing sections by smaller triangle ones, as the big tail was dragging the CoL too far behind. Gave them 5 degrees of incidence and dihedral as well. This adds to the stability, and helps make pitch control more responsive. Re-angled the tail elevators closer to prograde, and disabled yaw/roll - left only pitch control. Added a second set of elevators with deploy direction negated, added both sets to brake action group - they double as airbrakes now, helps with managing approach speed. Moved both sets of ailerons on the wings inward, angled more prograde. Added both sets to AG1 to serve as flaps. Disabled yaw/pitch/roll on the inner aileron pair - too close to the CoM anyway to do any good for pitch, and we have way too much roll control as it is. These are dedicated flaps now. Disabled yaw/pitch on the outer pair, left only roll on, turned down the slider to 33%. They double as flaps too. Disabled pitch/roll on rudder, lowered yaw control to 50%. Added engine thrust reversers to AG2, and toggle on/off on AG3. Goliath thrust reversers are awesome at shortening the braking time. Adjusted ramp and bay door sliders, added them to AG9. Offset inner Jr docking port a bit backwards to create space for a ladder from the cockpit hatch. Added deployed ladder, added beam to visually 'hold' the docking port. Added a second Jr docking port and an octo2 core to the front of the rover. It can redock front and back now, and be remotely controlled to pick up a kerbal. Adjusted rover wheels slightly inward and up to lower CoM (less chance of rolling) and fitting a bit better back into the cargo bay. Added airbrake on the cargo bay floor to serve as a deployable ramp/lift to help the rover redock again. (AG8) Adjust the slider as required for the rover/cargo used. I noticed the Goliaths build up heat and transfer part of it to the cargo bays, wings and main gear after prolonged flight at full throttle, but other than showing a bit of glow nothing became critical. Makes for a nice long-range transport. I had fun with this, both recovering from the initial quicksave and tweaking the plane later. Thanks!

Well, rumour has it there's a couple of mods that come together in one of the back corners of 'The Lounge' and buy up all the ore that miners bring to them, no questions asked. You need a secret handshake and then whisper the code phrase 'Guess Who Will Reply Next'. But be careful, most other mods will frown very sternly at you if you even mention ore trading...

Welcome to the forum. In addition to what James already said, and responding to this question: There are two main ways to 'talk to the developers': By posting in the Technical Support (unmodded) forum here. There is also a forum for modded games, but that will mostly get you help from other mod users; the devs prefer you report problems with a clean install. Through the KSP bug tracker (by creating a 'New Issue' and describing your feedback/bug report). You can find detailed tips of how to best ask for feedback or report problems in the Stock Support & Bug Reporting Guide.

I've seen this happen sometimes as well, and I always launch out of the SPH/VAB. I don't think it's exclusive to launching directly to the runway.

I see from the hangar version of your plane that the rover command seat is facing backwards, to the tail of the plane. So it sounds plausible, BUT: it's not actually the problem of your quicksave. I loaded the quicksave, and indeed the first thing I notice is that controls seem backwards. Second thing I notice is that the plane is rapidly descending, very close to ground, and throttle is zero (!). So I do a frantic recovery by a quick succession of steps: 'Esc' to pause right after load Esc - right-click the cockpit - Esc to pause again Esc - click 'Control From Here' - Esc Esc - throttle to full and PITCH UP PITCH UP to narrowly miss the ground Take a few breaths now While pitching up to recover, I notice the control authority of this plane is ... well, not good. it has trouble pitching and set way too strong for roll, making it almost impossible to keep level. So the next thing I did was change those sliders to get back some control. Now that I was level and somewhat in control again, came the next surprise: I zoomed into the cargo bay and... there is no rover in the bay (*). The bay is entirely empty, other than the one back-facing Jr docking port from the plane itself, which apparently is what the game picks at loading as its control point in your quicksave. In essence, this gives you the exact same symptoms: reversed controls in two axes. This goes for the control surfaces as well, which means very counter-intuitive flying, and as you are flying very close to ground, almost inevitable disaster. I can't even speculate on why opening the ramp automatically returns control to the cockpit, but I can confirm it does. All I can say, report this to the bug tracker, they'll have a heck of a time figuring this one out. Anyway I still wanted to help you, so I made a new named save (download here), where I managed to recover and somehow land safely at the pyramids (again *). I had also changed a lot of things on the plane itself to try keep it from self-destructing: For better control, I redid the sliders on all the control surfaces, turned some off entirely. Especially roll was set to kill. I changed the brake power and friction control settings on the landing gear to help it slow down faster once it touches down. I also enabled some autostruts on the wings and the engines, because at landing, even softly, the flexing kept colliding them with each other and blowing up. The autostruts seem to alleviate that, enough to land safely at least the one time I managed. There is still something very wrong with the landing gear, which makes me suspect you edited the spring/damper sliders way off the defaults: it keeps bouncing even on delicate touchdowns, and it bounces the plane almost to destruction when loading the save - something that seems to be prevented by leaving the ramp open. If you want to see the bounce, load up the 'gearbounce' save. *: the reason I say 'again', and a possible explanation of where the rover went, is that once I managed to land safely at the pyramids, I see the rover parked right by them, with a kerbal in it. Apparently, you had already landed and unloaded the rover, and must've taken off again, before the quicksave. Did you forget you had already landed?

Always. Let me stress this: every. single. time. I cannot ever seem to just launch something without checking for something to tweak. Regardless of how often I used a particular design.

A few helpful options available in the stock game: When you rightclick the probe core, at the bottom of the part action menu you'll see a bar with the amount of Electric Charge, and a small green arrow to its right. If you click the arrow, you are locking that resource to prevent it being used at all. That will allow you to safeguard the tiny amount of EC in a probe core for pure emergencies like this. In the KSP Settings, enable 'Advanced Tweakables' - this can be done in the flight view for an already launched craft. This will add some extra configuration details in the part action menus. One of those extra options is called 'Flow Priority', and shows at the very bottom, with blue minus and plus buttons that edit a value in between. The value is the priority of the resource compared to other parts that have the same, in this case EC. By lowering the priority value to be lower (into negative if needs be) than all other EC-containing parts, you are telling the game to save the EC in the probe core for last.

Personally, I would ask that we please not restrict payloads any further, forcing them to be even more dead weight than they already are. I do realize it's a challenge with a very specific scoring objective, and there's really no substitute for the sheer density of ore tanks in stock, so of course most entries are going to be lobbing up ore. I also get that the competitive pressure is not conducive to greebling up a payload, when there are mass fractions and gravity turns to perfect. All understood and accepted. But the rules already explicitly disallow any kind of ship/transport/lander (no engines!). Let's please not restrict it so far that we can't even lift an independently operating module/station/satellite if we choose to, something that can interact in/from orbit in some other way than just as a collision hazard.

At the top of the Tracking Station window, you see a row of icons. At least one of them is black instead of white. Make them all white (by clicking on the darkened ones), and your base should appear. The icons are filters for the type of things the tracking station will show. They help to unclutter a view with many things in space. Reversely, they also hide things when not selected. And welcome to the KSP forum.

No lo he usado, pero creo que no es así: la gracia del 'mono' es que permite usar los mismos archivos EXE y DLL que en Windows, sin necesidad de compilar nada.

I just now saw this when rechecking the thread: Sorry to disappoint. I think it's even possible to get under 4t. I'm already tantalizingly close with a derivation of the one I posted above (just short 100m/s for a 80x80 orbit, trying to optimize the ascent trajectory now). So let's do this, under 4t "SSTO". I've already been trying with a Panther - .4t less engine mass sounded like a nice advantage, but it flames out at almost 700m/s less and several km lower than the Whiplash, and the additional LF/Ox and tankage to compensate in closed cycle ends up heavier.

¿Te refieres a la version continuada por linuxgurugamer? Porque no veo a nadie mencionar problemas con la última versión (0.0.8), ni aquí en el foro ni en Github. Si es esa versión: el mantenedor es bastante activo en resolver problemas, pero necesita saber de ello. CKAN debería trabajar en Linux/Debian. ¿Has seguido las instruciones del Wiki: https://github.com/KSP-CKAN/CKAN/wiki/Installing-CKAN-on-Debian-Jessie-or-Debian-Stretch ? Nota que requiere instalar 'mono-complete' en vez solo 'mono'. No tengo recomendación, pero si quieres una opción simplificada: IFI-LS.

That message would be a lot clearer with just a few extra words: "... by clicking on it." On the Windows version, it's a left click. And the area to click is sometimes a midge fuzzy: depending on the part, the angle of the camera, and apparently the level of humidity on the dark side of Gilly, you sometimes have to click in thin air. So hover the cursor around the hatch until you see the floating tooltip 'crew hatch' appear. Click immediately - now the context menu appears and you'll see an 'EVA' button to click.

A minimalist entry for this challenge, the Tiny-SSTO-1a. (Full imgur album) Crew: 1. Weight: 4.178t. Cost: 9040 funds. Modifiers: safe, powered landing at KSC runway. Score: 1 * (9040 / 4.178^2) * 10 = 5178.83 points. Craft file: Tiny-SSTO-1a The scoring system seems... weird. I'm sure I got it pretty small and cheap, yet the score seems incredibly low compared to the other entries here. Unless that's the goal for a minimalist entry? Either way, I could easily "game" the scoring by eg. replacing the solar panels by a single RTG, which blows up my score for this exact same craft to 17688.43. Or add a gravioli detector. Also, the powered flight modifier being based on throttle is counter-productive: any minimalist SSTO is going to be so light that at full (or even half!) throttle it's going to burn itself to a crisp. I do like the idea of rewarding flight time, but not based on throttle setting.

I guess the game itself needs to support it. Maybe it'll be done at some point, perhaps benefiting from the code for the consoles. Thanks for the testing anyway; I'm a mouse and keyboard type myself, but with a more functional controller I'm sure there'd be more people interested in trying it.

I've had this happen too on a tiny 0.625m shuttle I built. It's some type of interaction with the landing gear autostruts, and it happens more pronouncedly in tiny craft. My guess: it's because when reloading the craft (focus back or quickload) the gear autostruts try to relink to 'heaviest part' which is no longer the same after you spent a large part of the fuel. The way that autostrut relink works at the moment seems to apply forces already before all the parts are fixed in place, small enough to not be noticeable with large craft, but with tiny craft it's enough to bend the whole setup. Iow: it's a bug in the stock game that happens with tiny craft with landing gear, and if you have a way of reproducing it reliably, please post it in the KSP bug tracker.

I don't use it, but after some fork-tracing I found a recompiled dll for 1.3.1 (on aw1621107's fork): https://github.com/KSP-RO/KSCSwitcher/pull/5/commits/d0038705f026f497038155159f541a1480c71c52 It hasn't been merged though, so use at your own risk. (I think I messed up the above link, this one is where you can download the zip: https://github.com/aw1621107/KSCSwitcher/tree/d0038705f026f497038155159f541a1480c71c52)

Have you tried the Steam Controller config? Supposedly, it can configure any gamepad Windows recognises. Steam->Settings->Controller Check in 'General Controller Settings' that Steam has your controller selected, otherwise select it or add it 'Desktop configuration' to configure it (assuming you avoid Big Picture mode like the plague, like I do) Click any of the controller's sticks/pads to edit their configuration 'Mode Shifting' apparently lets you pick which one of the controller's buttons to use as a modifier Note that I have no actual experience with it, I just remembered seeing that before in the Steam configuration and looked it up just now to describe it here.

I agree that it looks better, as long as it's made clear that the scale is broken, so there is no confusion. An alternative to consider, and perhaps a solution to the 'verticalness' of the graph as well: why not two graphs side by side? One from 0-5 Gm to show Kerbin, Mun, Minmus, maybe a marker for KEO, and the two neighbours Eve and Duna teasing at the upper edge. Then a separate one beside it from 1-150Gm for the planets.

True. Next you're gonna tell me there's weirdos out there that want actual orbital mechanics in their space game, and that entire forums will be filled with discussions about dV, TWR, and rocket equations...