Starwaster

That's a bug and you almost certainly have errors that are being generated. Without logs it's impossible to do anything but guess. But if I had to guess then you don't have something installed correctly or an installed mod is not compatible with the version of KSP you're running or you have a mod conflict.

Nope. It's all stock. It does require the new DLC though or you don't get the spiffy new Future Suit for this to work on.

@severedsolo Ok so about the issue persistentId and things not autoapplying, I've tried to collect some info and make sense of what's going on. Specifically here tracking the journey of part 1599986447 (parachuteSingle) Several persistence files. One before entering the editor, one after exiting the editor and one with the resulting ship sitting on the pad. And a log. zip file at bottom. Ok so what I've noticed is that four times FlightGlobals has tried to change the id of that part but the new id never shows up anywhere. Maybe because it gets changed back by ScrapYard? Also, where exactly is the actual inventory list in the save file? I've been assuming it's PartInventory in the ScrapYard scenario. Part 1599986447 definitely exists there. But in the final persistence file it's also sitting on the launch pad on the top of my capsule. Both the part.persistentId and ModuleSYPartTracker.id = 1599986447. If it's on the vehicle should it actually be in the PartInventory list too? Or am I misinterpreting what that list means? The tracker module still has those id's and the part still has that id but the PAW menu says the part is new. The log after switching to the flight screen has FlightGlobals saying that it changed that part's id to 2003863965 but that number doesn't show up anywhere else ever again. Certainly not in the persistence file. Still not sure what to make of all this except that there's discrepancies with the various ids and where ScrapYard actually thinks they are and says they are. I hope this is of some use and not just rehashing what we already know. Tell me what you think. https://www.dropbox.com/s/2c93oej17xtuasc/ScrapYard-persistence troubleshooting.zip?dl=1

What do you mean exactly? You mean its resources? It loses the resources you add to it? Or what? And unless... what? That's incomplete.

All I can think of when I see this is... "Dad are we hit?!"

Shouldn’t be too hard.

If someone cares to extend it then that can easily be done via Module Manager. Occupations are not hard coded in the mod, I just look at the Kerbal's trait field which is a simple string and I pass that to a function that checks if there is an entry matching that string in the KerbalOccupationColors.cfg Let's say there's a mod that expands the list of occupations to include a NerfHerder. The patch would look like this: (in the code, the occupation string is converted to all lower case so that's what you want to do to the config) BTW, this mod is in the public domain. I so declare that. @KERBAL_OCCUPATION_COLORS { nerfherder { red = 0.5 green = 0.5 blue = 0.5 } }

@Rudolf Meier @Tincan70 Re: Wheel bouncing when KJRN is installed: I'd suggest one of two things, given that ModuleWheelBase forces autostrutting on the wheels. Exempt ModuleWheelBase from being reinforced by KJR Override wheels from autostrutting. It only sets it once, in OnStart(). Override it any time any time after everything has started up in flight scene. (set part.autoStrutMode = Part.AutoStrutMode.Off

Well, it could be un-broken with regards to RO 1.6 - all it takes is a little elbow grease. The parts are all the same, mostly. The worst thing that happened to them is that many of them were renamed. I see a lot of people lamenting that SSTU isn't available any more but none of them want to go and fix the configs. That person could be you if it's something you care about.

It just means that any Kerbals already in existence won't have their occupation colors assigned to them. That's because this mod is event driven; whenever you get a new Applicant an event is fired by the game (onKerbalAdded) with the new applicant being passed in as a parameter. I intercept that and change the Kerbal's suit colors. Those are actually specified on the Kerbal itself. Whenever you right click on the Kerbal the new colors are written over. That way the colors are persistent. That's another reason why this only affects new Kerbals. I could easily step through the entire roster and make all Kerbals comply with the new colors. But then players couldn't modify their colors.

Kerbal Occupation Colors (Requires Breaking Ground DLC) This mod will automatically assign colors to the Breaking Ground Future Suit based on Kerbal occupation. Red for pilots, gold for engineers and blue for scientists. (totally not related to any Star Trek colors ) This mod will not affect your ability to edit your Kerbal's suit colors in the field and those will still be persistent. You can edit the default colors in the KerbalOccupation.cfg file. See the README.MD file for details. Or just have at the cfg file. It's not hard to figure out. It should even work for non-stock occupations if added by any mods. That's not tested as I don't have any such mod installed on my system. Directions When installed, all newly hired Kerbals wearing the Future Suit will have color coded suits according to their occupations. Kerbals already existing in older saved games will retain the colors they had before the mod was installed. Also, by default, KOC does not force Kerbals to wear the Future Suit. These can be changed in the mod's menu settings. (accessed through the stock difficulty menu). In this menu, Kerbals can be required to equip the Future Suit and current hires can have the color coded dress code enforced on them. You can even try to enforce this on Kerbals on assignment but this doesn't always work, especially if you try to do it in the flight scene with those Kerbals loaded, so do it from the Space Center scene instead. Also note that enabling dress code compliance is a toggle which disables itself after it has cycled through your Kerbals. This is so that you can still assign custom colors in the field. (think of the setting as you having sent out a memo to all your employees) Known issues: The first four Kerbals (Jeb, Bill, Bob and Valentina) have the default orange lighting. This is a feature, not a bug. (if it's a big deal I'll look into fixing it but this works by hooking into the event created when new applicants appear and the Fab Four probably get added in some way that doesn't trigger an event) Only new Kerbals will be affected by the mod. If you have a save game with existing Kerbals they will not be modified. This is because the mod works by intercepting the onKerbalAdded event and also so that any player modified Kerbals will retain their colors. (you did know you could edit a Kerbal's color by right clicking on them in the Future Suit, right?) This mod requires the Breaking Ground DLC to work. (if you install it anyway, nothing bad will happen, it just wont do anything since there's no Future Suit) Download here! Or I will type something in Comic Sans! (you are warned) https://github.com/Starwaster/Kerbal-Occupation-Colors/releases/latest License: This mod is released into the Public Domain.

@Jim123 Ok so you used Tidal Stream's branch. I suggest you take it up with him then because it's not a Realism Overhaul issue and nobody here is going to be able to help with it.

Yeah you're going to need a plugin... something that sits on the suit part and when the EVA Kerbal spawns it sets his color according to his occupation. Or.... something that monitors for Kerbals being added to the roster. Actually that's even better. Because although the colors are SET on the suit they are actually permanently stored on the Kerbals themselves in the roster along with their occupation and other attributes... Yeah.... that's pretty easy to code actually. In fact, I just went and coded up the prototype.... all of the Kerbals below had their suit color set automagically as soon as they became Applicants. This isn't ready to release yet as it does NOT work for the first four Kerbals (Jeb and friends) I guess because there is no event generated for them? They aren't added in a way that fires one off.... I'll have to look into that. OR I could leave them as is... being veterans and all maybe they should get a different color. I dunno. Also, I want to make the colors configurable. That will probably be in a config file in the mod's folder. And maybe I'll make a menu for it too... or maybe that will be a later version. https://forum.kerbalspaceprogram.com/index.php?/topic/185931-17-kerbal-occupation-colors-version-10/

Well that's not good then. What branch of Procedural Parts are you using?

What I've found is that if persistentID does not refer to a valid part or if it refers to a different part than what FG was expecting when it checked the persistentID then it will change the persistentID to something else and fire GameEvents.onPartPersistentIdChanged with the parameters being old ID, new ID and vessel ID It would probably be prudent to listen for onPartPersistentIdChanged and change that ID everywhere applicable such as in-stock inventory items. And maybe OhScrap needs a similar check? I don't know? Looking at my current log I see that in the span of less than half an hour worth of play (really just launching a mk1 pod a few times and moving parts out and back in inventory) this has happened 96 times. (I did NOT see this in @gap's log but maybe that's because the damage had already been done in a prior play session; I don't know)

If you want to change the default emissive color for the future suit then this should do it @PART[kerbalEVAFuture|kerbalEVAfemaleFuture] { @MODULE[ModuleColorChanger] { @redColor = 1.0 @greenColor = 0.5176 @blueColor = 0.0 } } What do you mean about 'detecting' kerbal classes? What are you trying to do? You can't target specific Kerbals as they don't really exist until you start a game. Module Manager only affects the part of the game database which has configs in cfg files... (and cannot affect anything after the game has started). If you're wanting to assign specific colors to specific Kerbal classes then no you can't do that. Not without a new custom plugin...

@Jim123 If you're on KSP 1.3.1 then you need to move on to 1.6.1 What you're describing sounds like an issue between KSP 1.3.1 and Procedural Parts. No fix was ever found for the problem as the actual error was occurring in KSP's code. The problem resolved post KSP 1.4 As far as I know it hasn't been reported in any recent versions of KSP

@Shadowmage The three lander pod parts have different mass and cost values when viewed in the inventory list than when actually placed. This is stock + SSTU only. As an example, the LC5 has a listed cost of 6400 and a mass of 3.4 tons. When placed in the VAB its cost is 1320 and its mass is 7.021 The mass discrepancy is undoubtedly because the part has no resources on its prefab: When stripped of its resources (and external tanks removed) its mass becomes the listed value of 3.4 The cost at that point drops to 675. If the containers are configured to remove the resources outright (as opposed to using the sliders in the PAW) then the cost drops even further to 14 funds The LC2 and LC3 behave similarly and if stripped of all the resources and tanks their costs drop to 9 and 14 funds respectively. Here's a log for you if you want it https://www.dropbox.com/s/ovw2dkdalpkvdi6/SSTU-LanderCore_testing-output_log.zip?dl=1

use RP1

It scales the Isp for vacuum and sea level respectively. It scales them by the base Isp for the engine type. Look in RealSettings.cfg under RF_TECHLEVELS -> ENGINETYPE. You probably want type O (Orbital) Now then, strictly speaking, ModuleEngineConfigs is not necessary to make an engine work with RealFuels. It's only necessary if you want multiple configurations for the engine. Different versions using different resources, or different gimbal settings, etc. (note that in the current release gimbal settings in MEC does not work but will be fixed in the next release)

Then go back and read it again. Don’t just glance at it or skim it. If you’re going to report bugs or request support then certain things are going to be expected of you such as logs. The link provided to you explains this and tells you where to find them.

Look at the last part of the config carefully; if you don't want methane being swapped in for the Raptors then delete that part. no_TE_FUel.cfg @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[TE_Fuel],#baseVolume[*]],!MODULE[ModuleFuelTanks]]:NEEDS[RealFuels]:FINAL { MODULE { name = ModuleFuelTanks type = Default baseMass = -1 volume = #$../MODULE[ModuleB9PartSwitch]:HAS[#moduleID[TE_Fuel],#baseVolume[*]]/baseVolume$ @volume *= 5 typeAvailable = Default typeAvailable = ServiceModule typeAvailable = Cryogenic //typeAvailable = SpaceX //typeAvailable = SpaceX.Composite } } @PART[*]:HAS[@MODULE[ModuleB9PartSwitch]:HAS[#moduleID[TE_Fuel],#baseVolume[*]],@MODULE[ModuleFuelTanks]]:NEEDS[RealFuels]:FINAL { !MODULE[ModuleB9PartSwitch]:HAS[#moduleID[TE_Fuel],#baseVolume[*]]{} !MODULE[ModuleB9PartInfo]{} } @PART[TE_BFS_RAPTORSL|TE_BFS_RAPTORVAC|TE_18_BFB_ENGINE_CLUSTER|TE_18_BFS_SL_RAPTOR]:FINAL { @MODULE[ModuleEngines*] { @name = ModuleEnginesRF !PROPELLANT[*],*{} PROPELLANT PROPELLANT { name = LqdMethane ratio = 1 DrawGauge = True } PROPELLANT { name = LqdOxygen ratio = 1.417456617 } } }

I'll try to take a look at it sometime... it's not really something I use anymore. It seems like it's just always had one issue or another

And keep its center of mass low and maybe even think about giving that rover some RCS control...

Did you actually TRY your desired probes with 1.7.2 or did you just assume they wouldn't work? If they are just parts packs then the likelihood of them NOT working is so low as to approach zero percent. Even a lot of plugins will continue to work in spite of compatibility warnings which should really be interpreted as version mismatch warnings since no code can actually detect an 'incompatibility'. All those incompatibility warnings you see are the result of version comparisons. Even Real Fuels for KSP 1.3.1 will work in KSP 1.7.2 though I wouldn't recommend actually doing so when there are newer versions out. (note that when it comes to plugins YMMV considerably. It all depends on whether what changed in the KSP code was actually something that got used and how it got changed) No, there isn't any explicit support for life support in Real Fuels so there's no types of tank settings for it, sorry As for the negative mass issue, I'd need to know more. I assume it was scaling down the engine that did it? Was the engine part an engine only or did it have fuel tanks included on the engine part? Are there other plugins besides RF/TweakScale that can affect the mass of that part?