swjr-swis

Well, space was after all a russian invention...

A few KSP super-short stories that are guaranteed to make grown kerbals hide under their beds and cry for mommy: "And then Jeb suggested we make an Eve sea-level SSTO..." "Uhm guys, Moho is getting awfully big in that viewport. How's our deceleration dV budget?" Dres, pretty much any day of the year: "H-hello? Is anyone out there? Hello??" "Wheels!"

Nothing weird about it, Intel moved to 64-bit CPUs well before a 64-bit Windows appeared, same as before with the 16-to-32-bit transition and before that for the 8-to-16 one. Every time the explanation was that there was no use case (yet) for 'moar bits', but it would cost more (expensive) RAM and HDD, so let's not do it yet.

In-game, in the graphics settings, you need to have 'fullscreen' disabled as well. Otherwise it will override the popupwindow parameter.

Jool's atmosphere kills anything we could send down into it long before coming anywhere near something solid. Pressure, heat, aggressive chemicals, destructive winds, lightning, radiation... you name it. Not so much a question of whether the craft is destroyed, but which one of those will make it fail first. Maybe one day when the monoliths awake and ignite Jool, fragments of its diamond core get blasted throughout the system and we can finally, in some way, touch Jool's 'surface'.

It's not exposed in-game, but the game does by default make separate backups of the savefile at regular intervals. The lacking part is that you need to go outside the game to revert to one of those backups, by copying it into the main save directory. The settings.cfg file in the main directory of the game has the following entries (that can't be changed from within the game, you have to hand-edit these): AUTOSAVE_INTERVAL = 300 AUTOSAVE_SHORT_INTERVAL = 30 SAVE_BACKUPS = 10 I think the above are not the defaults; I seem to remember the default saving only 5 backups, and the intervals may be different. But it's up to you to edit to your liking. In your save directory, you'll find a 'Backups' directory that contains these regular snapshots of your savefile, named something like 'persistent (2018_10_22_18_22_33).sfs' to show the date and time of the snapshot. Make a copy of your main savefile (persistent.sfs), then copy one of those backups into the main save dir. You don't even need to rename it, once back in the game you can load it from the Esc menu (Load save..).

The adjustment sliders are not the cause. They were added as a workaround due to the wholly unacceptable default behaviour of wheels when the game's wheel system got 'upgraded'. Without those sliders we'd still be completely helpless to wheels acting in whatever random way they feel like. I have no issue with the sliders at all. More control is always better in my book, and it's almost a must-have when building complex, large, or 'weird' craft. I do wish however that they'd figure out how to make wheels and suspension work more or less as expected in the basic vanilla use cases, without having to tweak the sliders all the time.

If we all kept ourselves limited to what is generally considered 'reasonable', we'd never have tried flight, let alone space. Or a game about space. Space. I like space. So much space. Space. Are we in space yet? Spaaace! Space.

The max time value is 2 147 483 647 years, 425 days(*), 5 hours, 59 minutes, 59 seconds (UT = 19760285526235197): One second more (UT = 19760285526235198), and the time becomes negative - probably due to the year being calculated as a signed integer and at that point flipping over (dec 2147483648 = hex 0x80000000): Which the game surprisingly still seems to be ok with for almost an entire year... at which point time stops completely. And the game, I might add: (*: the save screen and MET indicators show days in ordinals, so it's 425 and not 426)

Yes there is: like @PrvDancer85 mentions, you need to add a probe core so it can be controlled when detached. Then once detached, make sure SAS is off and set a trim for the axis you want the spin on. Eg. for a propeller with a probe core in the direction of the shaft, hold Alt-E or Alt-Q for a sustained spin.

You could try to increase the 'explosionPotential' of parts, a stock part cfg variable that governs how powerful the explosion effects are (or were, at least up to 1.3.1). See the video for the difference it makes. https://www.youtube.com/watch?v=Xt_zTvHSBGQ

You need to register an account at https://bugs.kerbalspaceprogram.com/projects/ksp/issues to do that. You can search the issue list to see if anyone else has reported the bug before, and if not, you can create a new one. A more detailed explanation of how to report and what details to add can be found in the bug report thread:

Thanks for checking; at least that rules out a change of the kerbals themselves.

I tried that one before, but I got a server unreachable error. Glad to see it's up somewhere, even if temporary.

I do know that table, but I meant the actual graphical height maps that used to exist online at several locations. Some of them even had overlays with points of interest, which I think included highest and lowest points. Here's a reasonably recent thread offering some screenshots pinpointing a 7540m location on Eve:

I am not a console user, I don't know. Do consoles these days allow access to the game files somehow? If not, then you can't use this workaround. Your only avenue then would be to submit a bug report and see if they decide to fix it - they did just mention they are again looking into another update to the console versions, so now would be the time to create bug reports.

Well, they did remodel the Kerbals for 1.5 - it would not be surprising at all if it turns out the new and improved kerbals have ended up with a different (bigger?) collision mesh than the 'old kerbals. That would explain why they now invisibly hit parts sooner than before.

The part cfg file for the external command seat has a variable that tells it how far in what direction the kerbal is 'ejected' when getting out. Why a kerbal needs to be ejected in any direction at all is a bit of a mystery, but there you have it. You can try tweaking these values until you get a more sensible behaviour for your craft. You can find the part cfg file at <KSP main dir>/GameData/Squad/Parts/Command/externalCommandSeat/externalCommandSeat.cfg. Search for ejectDirection = 0.0, 0.1, 0.1 - those are the values you can play with. Make backups, use ModuleManager, beware of rabid dogs, all usual disclaimers apply.

You are missing my point: There is no reason for them to hold back on giving any kind of statement out of a false fear for either 'raising false hopes' or 'disappointed backlash'... because both of those happen anyway, with every single release and/or feature added, even without multiplayer being in the mix. It's the norm, with every single release - some people get false hopes on what the new release or patch will add, or what the newly announced feature is going to be like, or how well/complete/stable a new stockified mod is going to be, and inevitable when the release drops, some people end up disappointed and become vocal about it. It happens e.v.e.r.y. time. So there is no point in suggesting that they keep quiet about multiplayer specifically to 'avoid' raising hopes or later disappointment... it's gonna happen anyway. By refusing to make any statement at all they are actually perpetuating this cycle for multiplayer specifically: because silence doesn't mean a definitive NO, every announced release people get renewed hopes up and start asking 'please include multiplayer' and then end up disappointed when the new release doesn't include it, with another storm of posts complaining about it. The 'hopes' -false or not- are already there, and will always be there as long as Squad refuses to either do it or put the subject to definitive death by SAYING IT. The disappointment and following moaning when the feature continues to not be included in every next release is a guaranteed result because of that.

Given how there's always 'some of the community' reacting with disappointment to every single patch or release of the game, or new features added, that could hardly be a consideration anymore; they would've stopped development entirely already.

Highest point on Eve according to my notes (in spoiler): I have no screenshot of this though. There used to be an online elevation map around that had the highest/lowest points of each of KSP's stock celestial bodies, but the links I have seem to come up dead.

You are not wrong. Place one or more of the relay dishes (or even deployed direct antennae) inside of a bay or a fairing, and you can have all the signal strength you'll ever need.

Came to this thread to voice my support for mobile land or sea launch platforms. Left disappointed.

Ahh that brings memories of wholesale Y2K conversions from mainframes to open systems. Makes me wonder why it would still be 'insanely expensive', in this day and age of almost limitless options for virtualization. Don't get me wrong: I am not telling modders how to do their checks. I'm just reminding those who still check for buildID.txt that this may be about to no longer be an option. Why would you purposely use a non-mod directory to save mod-specific telemetry? Aside from the general no-no of a plugin contaminating the host software's working directories and ignoring the general consensus -if perhaps not specifically mandated one- of saving mod files in the mod's own directory structure, you are exposing yourself to being 'evicted' by development decisions of the host software. I am generally very much in favour of avoiding breaking workflows, but this one in particular seems to be rather self-invoked.

That really should not be happening, not even in a stock game without autostruts. You mention MJ and FRMS, so you are playing a modded game, correct? If you're not using it yet, perhaps KJR can help.