Corax

(Emphasis mine) That is if "only" is to be read as "exclusively", but having a separate key to take high-res and standard screenshots is actually very useful. One can only guess why Squad didn't go all the way when they integrated that functionality. Also, the "burst" function is nice to have, although this can be approximated with window manager scripting tools. Here's hoping to this mod getting another lease of life, it still has its place in the modern day and age of non-beta KSP 1.x

I just wanted to let you know the keybinds are not working, even if there aren't any conflicting mods using those same keys. Understood. Would it help, or does it even make sense, for me to try and remove one shader at a time to isolate the one that causes the pink textures, even if it breaks the overall effects? I don't know a bit about shaders, so that would be my only route of locating the culprit.

Same results with 0.014_Experimental, and 0.0151, with or without anisotropic filtering, both with vanilla KSP_linux-1.0.2 x86_64 without any other mods. ]Also with no conflicting mods, I'm still unable to open the GUI with Alt-F10/11, nor MOD-F10/11 (Alt is usually remapped to RShift on Linux). That's with 0.014_Experimental as well as 0.015. And with 0.014, I couldn't for the life of me find the [Kerbin]Settings.txt, so I copied them over from my default KSP install after the first run of tests. 0.015 does have the config directory though.

Was just about to edit my previous post... right now, in the flight scene the altimeter, the staging indicator, and the g-force meter needle turned pink. I think it happened when I toggled the UI off and back on again for screenshots reloaded the flight. And another confirmation, this time for Sput42's observation. Alt-F10 conflicts with Contract Configurator, while Alt-F11 opens the ModuleManager UI. Luckily there's the possibility to edit the config files directly.

Much appreciated. Maybe I should emphasize more that so far, the only pink texture has been the loading animation (spinning planets).

Confirming pywicket's report. I'm running KSP x86_64 on Gentoo GNU/Linux, and neither the replacement nor the latest fix helped. Sorry, but pink textures are still a thing.

A simple fix for this "issue" would be to add more mass to the top of the rocket to make it nose-heavy, as strange as that may seem. You want to shift the center of mass in front of the center of pressure so the airflow helps to stabilize instead of acting to flip the rocket. <Stine, The Handbook of Model Rocketry 6th ed., Wiley, 1994>

Awesome first post. Welcome!

I think that's just asking for trouble. Why not use Squad's persistence mechanics? That way reverting flights, recovering from backups, and interaction with other mods is guaranteed. Other than that, sounds really ambitious - and not in a bad way.

Is KSP working for you on a plain unmodded install? You can find the logs here (might want to read that whole post):

ftfy

How is this progressing? If there's still any doubt about using HTTPS for the forums, gives a good explanation why encrypting everything really matters and how to implement it.

Do you plan on adding the queue concept to R&D as well? It feels kind of cheap compared to the VAB/SPH. I'd love to see my research queue up as well, and to have the ability to prioritize between my different research departments...

Thanks for your answer and happy to hear your point of view. Considering aborted rollouts, I'd lean towards requiring the same duration that has passed so far for the vehicle to be rolled back again. Maybe even add another fixed amount of time for bringing the crawler to a halt and starting again in reverse - a penalty for not going through with the rollout, if you will. Allow rollout of the new vehicle only after the rollback is complete, as there is only one crawlerway and one launchpad. That said, if it doesn't complicate things too much, providing for multiple crawlerways and pads might be sensible, who knows what the future (or Kerbinside) might bring...

Apparently the original intention of my post dropped under the radar after that edit... That of course depends on what else there is currently to do in the game. If there are other vehicles or colonies, that's the perfect time to do maintenance or go into "story mode". I don't see it as anything different than waiting for the ship to build, or tech to unlock. For me, having to wait for the next launch to roll out would mostly help to increase immersion, just the same as it is now with KCT, or even with stock KSP - nobody would wait a year in RL for their ship to arrive at Duna, but if there are missions going on in parallel, the game feels more immersive and less "warpy". So yes, I might Warp to Complete, but I'd still feel there was more going on at the KSC. If you simply replace refurbishment time after with roll-out time before, I don't think that would be worth the effort of even considering. However, if whenever a vehicle is to be launched, there was a portion of what is currently "refurbishment time" scheduled before the vehicle is out on the pad ready to launch to simulate roll-out, and the other portion post-launch before the next vehicle can be scheduled for launch to simulate pad refurbishment, I'd see that as a definitive improvement to the mod. If there were a config file setting or GUI option, the split could be adjusted to whatever preferences each individual player has - all before, all after, or some mixture of both. Regarding KCT lite, basically what Hyomoto said I wonder if it's worth the effort. You seem to say it would be simple to do as it would basically be stripping down the current project, but then you'd have to maintain two separate mods. It really depends on how large a user base there is for a light version. I think in FAR's case, there's a lot more complexity that warrants a light version; with KCT, the time might be better spent on the "work flow" which seems to be what puts off those potential "light" users (whom I don't agree with, I think the mod is fine functionally as well as usability-wise)

The way I understand them, that's the idea behind using KSP's ConfigNodes. Everything is stored in the persistence.sfs and quicksave.sfs by KSP API methods, and whenever a game is saved, loaded, or reverted, KSP itself takes care of the actual loading/saving. That way nothing can get out of sync, at least not because of multiple save files and non-concurrent access methods.

Sounds like a good thing to do in any case. I have also cross-posted to Final Frontier, so Nereid should be aware of the issue as well.

I didn't see this brought up in the thread, so I copy a post from over at Kerbal Construction Time: I ran into that same issue recently and suspect the problem is on FF's end, since it uses a separate save file instead of using KSP's integrated save mechanism. If anything, FF needs to modify the way it keeps track of its information. Is migrating halloffame.ksp to KSP's ConfigNode mechanism planned? If not, would you consider going that route? It would certainly improve reverting, loading older save files, and general compatibility with other mods that modify in-game time in one way or another.

Regarding reconditioning/rollout time, would it be worth a consideration to split it into a period before/after launch, say 25% rollout time before, 75% launchpad reconditioning time after launch, and possibly an option to configure the split percentage? That way everybody could be satisfied with a simple config modification. EDIT: I ran into that same issue recently and suspect the problem is on FF's end, since it uses a separate save file instead of using KSP's integrated save mechanism. If anything, FF needs to modify the way it keeps track of its information.

https://github.com/KospY/KAS/blob/master/LICENSE.md

I wonder how the planned upgrade to vBulletin 5.x is coming along... it's been a while since it has last been mentioned.

Let's see... orbital velocity at 450 km as per your example, assumed circular orbit: vo=sqrt(G·M/r) = sqrt(µ/r) where r = rEarth+450km = 6378km+450km=6828km vo=sqrt(398600/6828)=7.64km·s-1 So in the worst case scenario of a head-on collision, the impact velocity would be twice that, or roughly 15km/s (note: kilometres per second, not metres). For a collision with a vessel that's still suborbital, anything less than that.

I see. Thank you for reminding Squad to follow their own rules

Inside. tenchars

This bug is only present in the 64bit version because there Unity tries to reference a 32bit code path, meaning this bug does not affect the 32bit version, hence no need for a fix, and no need to be sorry