darthgently

I'm too new to KSP to know the answer to this, but do Tourists, who gain experience, ever become anything other that Tourists? It would be cool if a Tourist spends a lot of time with crew members they begin to get some on-the-job training skills. So they could become apprentice/journeyman/etc/ engineer, scientist, or pilot. And what the heck, senior crew should be able to retire to being a Tourist and watch other people work for awhile, ha! It just seems that if some tourists end up stranded on Duna for 8 years with some crewmembers, they are going to end up nearly fully qualified in about everything required on that craft by the time they get rescued simply by pulling their weight while stranded

Engineer, Scientist, and Pilot level should not be capped. Pilots should be able to eventually become "Commanders" which would give them the ability to have other Kerbals follow them on EVA, on the surface or in space. A high level Pilot Commander should increase all efficiencies on the craft to a modest degree; science labs, mining, repairs, fewer kerbals required to move parts, etc. to reflect the "good leadership -> good teamwork" factor Engineers should gain an increasing ability to scavenge parts to repair other parts without having an explicit parts/repair kit. The presence of high level scientists should expand engineers' ability to do this as high level scientists would act as sounding boards for wild repair ideas. High level Pilots who have achieved "command ability" could also lend a factor as the ability to keep morale up and lead during emergencies improves crew performance overall. The end result being that having each trait represented on craft will not expire upon cracking the tech tree or having probe cores smarter than pilots or having a satellite network that makes crewless probes more prevalent. Maybe...maybe, allow Kerbals to cross-train to other traits, so you could have Scientist/Engineers, Engineer/Pilots etc.

For example, if one has two broken solar panels, an engineer of appropriate level should be able to scavenge one to fix the the other as if the other were a parts kit. The trade off could be that now the other one would require 2 parts kits to get it fully working or something like that (example: Apollo 13 crew). The higher the level of the engineer, the broader the definition of "similar equipment" becomes. For example, a hypothetical 42 star engineer should be able to repair about anything by scavenging almost anything (for example, see Scotty or Jordy in Star Trek). See my upcoming post about removing, or at least extending, level limits on Kerbals, and making each type more valuable later in the game. The more trivial the scavenged equipment, the more you will need of them to scavenge for a repair; like maybe it would take 1 million scavenged struts to repair a nuclear reactor. Of course any working equipment scavenged would become broken. Perhaps tech level, monetary value, and mass of repaired and scavenged equipment could be factored into how much of each would be needed. And of course the level and number of engineers and perhaps scientists present (think about it)

I wonder if the damage could be split into 2 categories at some point. That which can be repaired simply by an engineer with the required level of experience and that which requires a repair kit. In the real world, good techies repair things without new parts, without the "special tools", and using their experience and working out a fix on the fly. Leveling up engineers to be able to repair without a parts kit in certain situations would add grit to the game. It would be even more fun if on occasion, to repair without a parts kit, the player had to select another part on the ship to scavenge to repair the broken part. So they have to decide what they can do without in order to get what they need to work going. And the parts that would qualify as scavengable would be limited of course. A no brainer is that if you have 2 broken reactors a good engineer should be able to get one working between them without a parts kit as the scavenged one is a parts kit in the real world. Anyway, food for thought

For kOS stuff, toggles suck. one needs to be able to see from code what state something is in which the text in the PAW does (ala 'activate', 'deactivate'), but if the text just says 'toggle' it tells the code nothing. So not a big fan of 'toggle' here. There is no reason both 'toggle' and explicit menu options can't coexist as they do for many parts though

I'm logged into the bugtracker site but the way to upvote the issue or your comment is eluding me; how do I do that? I figured it out. Upvoting is on issue only, not on specific comments from what I can see

I don't know anything about it, but google handed me this with a 10 second query. There may be a glitch involved. This thread is a mere 6 mo old, so it still may apply

Kerbals are 2/3 the size of human? That would explain it away so it must be true

Hello, I've been playing with kOS for several months and am wanting to branch out a bit and kRPC has been recommended by some smart guys. I'm running on linux, but could go to windows if required (hopefully not though). I do wonder about the lack of updates since 2018; is it being actively maintained with regards to newer versions? I'm currently running 1.10.1 but am not glued to that. tl;dr questions: Is linux a problem with kRPC? Is kRPC being (or will be soon) actively maintained for current versions of KSP? What is the "best" KSP version for kRPC? Is there Trajectories support? Thanks

Ok, that explains it. The default mod key on linux is right shift, so it is probably when I'm typing cap P in a kOS popup terminal that it is happening. At the time I'm busy typing and because of lag I couldn't figure out what was happening. I'd really like to move my 'mod' key to the unused 'windows' key on my machine but when I've asked how to refer to this key in the KSP settings file I got no response. And I don't know why only some mods seem to listen to the keyboard while I'm typing into a kOS popup terminal while KSP and the vast majority of mods ignore it, but HullCam also triggers on keystrokes in these windows. HullCam is reading the keyboard directly rather than using higher level methods. Maybe SmokeScreen is doing the same. Thanks for the info. Is there a way to change the SmokeScreen hotkey?

What is the hotkey for Smokescreen? I hit it by accident now and then and have no idea how to make the config screen go away. I don't even have a reason to use the config screen in game, is there a way I can disable it?

I don't know what it could be. But I do know that I encounter oddities with PParts on a daily basis and have given up reporting them. Watch your fuel levels in PPart tanks upon loading a craft and on resizing a tank. Often it will not be full any more. Another issue I've been dealing with are SRBs on one of craft that when I load it in the VAB, the nozzles are tiny and the thrust is at a minimum level, but I saved it with huge nozzles and a very high thrust level. I just sigh and bump it back up before launching. Take home message is audit all your PParts prior to launch. I love the mod, but it needs more love than I can give it from out here

Are you in a sandbox or career game? The minimum and maximum dimension of many pparts becomes broader as you advance if in career. If in sandbox there is a setting you need to change to make the entire tree available at the start of the game, iirc.

Or how about something like the hinges, but instead of simple plates, it is two rectangular docking ports hinged together so once they lock they become two docked ports and the code never sees a hinge again

I do now, thanks boss

Me too. I did rig up some MK1 crew cabins with jr docking ports once. I had them on decouplers along side the main body with their docking ports perpendicular to a docking port just above them. I used hyperedit and gravity cheat ad nauseum to tune the decouplers scale, force, and locations until on activating them with the main craft atitude still and in zero g the crew cabins would move up and rotate 90 degrees and the jr docking port's magnetism would pull them in . It was a vanity project and I never used the technique but I did explore avoiding the alligator hinges that seem to be kraken bait for me anyway

Does anyone know how to remove waypoints in the zoom map short of editing files? Sorry if I'm misunderstanding the basis of the waypoints. If they are a feature from outside SCANSat that are just supported in SCANSat then a clue on how to remove them in game would be greatly appreciated

Is xenon supported as a resource in SCANSat? If so, what do I need to do to see it in the resource drop-downs in the maps? If not, is it in the future plans for SCANSat? It just showed up. Not sure I changed anything

Quality is paramount. But the longer it takes the less surprised ppl should be when a competing title comes out that gives KSP 2 a run for its money. Nature abhors a vacuum. You can't get a blue ribbon at the county fair if you arrive the day after the fair closes. I'd be happy if a basic quality skeleton were delivered earlier with more meat added later (but not haphazard, the bones should be designed for the meat and the meat grade A) if only to stave off a big house competitor that starts hiring away your ppl and wooing your customers. Its been know to happen

I completely disagree. Not all skills should be doled out by the game. If a player is good at EVA movement they should *not* be hobbled by the game GUI. I despise hobbling player ability and skill typically in the name of "balance". The challenge should be the rocket science, orbital mechanics, logistics etc. The GUI should not be the challenge. Games should be fun and challenging, not tedious nor the player's "experience manager"

This should be fairly easy mathematically and programatically but would somewhat solve the issues of kerbs not being able to reach handrails and hatches without rotating an entire space station and such. The North Up EVA thing is really silly in my view and the resulting camera gimbal lock is very annoying. Ideally, one should be able to set the kerbal EVA "UP" axis direction to prograde+/-, normal+/-, radial+/- and, *most importantly*, be able to set "up" relative to the nearby vessel main axis (parallel or perpendicular etc), or relative to the current "aim camera" part. That would be noice. When working around a vessel, it would be great to be able to make the nearest part of the vessel "down" really. And magnetic boots. Kerbals are demanding magnetic disco space boots

Background: In 1.10.1 I've occasionally encountered strange behavior in the VAB with SR where I will put on a normal number of chutes onto a stage, SR will report the stage to have a predicted final velocity of 5m/s or so, and I'll move on to putting chutes on another stage. Then, when I revisit the prior stage, even though the number of chutes hasn't changed, nor anything else, SR report that the predicted final velocity has gotten far higher than makes sense. I typically just ignore and the stage does just fine and when recovered the first, more accurate, predicted velocity pretty much matches the actual recover velocity. Currently, the above behavior is far more severe. No matter how many chutes I put on, if I wait long enough in the VAB, SR will decide it isn't enough. And worse, when I launch, no matter how many chutes I put on, the final velocity is always just over the limit. Baffled. I could maybe get more info, but not sure what to get [edit] Factors that may help narrow the problem: I'm using Tweakscale and a failure of SR to track the scaling under all conditions may be involved. But this behavior has definitely occurred when no further rescaling has occurred between SR recalculations. Also, I'm using procedural parts tanks, which I've found have some oddities. For example, I know that proc parts cone shaped tanks report incorrect CoM locations. But I did find their reported mass to be fine for cone shaped tanks.

I uninstalled BE and all my ships won't load now because BE patched all the solar panels so they use the Kopernicus solar panel module instead of the norm. Shouldn't uninstalling, in a sane universe, revert the modules from the ships in current persistent.sfs file? Do I have to edit the sfs and craft files? It seems optimistic for the current mod approach to assume the mod will never, ever, be uninstalled. Installing many mods is like sticking your fingers in a chinese fingercuff: a one-way operation. Not friendly. Any advice appreciated [edit] I jumped the gun, only my new craft files are affected, not ships in game built and launched prior to BE, but still, that is a problem with the mod ecosystem: that removing a mod breaks ships. I've thought before that if every mod had placeholder parts and modules for their own parts and modules that could be left behind on uninstall so the craft files would still load and editing the file would be easy because of easily found strings in the placeholder parts and modules or similar

Since I installed BE 2 days ago my 5 Sentinel sats have found zero new asteroids. They usually find several a day. Is there a setting or something I can look at and fix?

And you have selected version 1.2.7.0 of ModularFlightIntegrator installed via the "Versions" tab? That is the version I have checked and that is the version that your error messages says is missing