FlowerChild

In case the developer, or anyone else that might know, is still following this thread: The tree.cfg files you mentioned previously just don't seem to exist in any save directories that I've looked at (yes, they are career saves). Is there some trick to accessing them like a file that needs to be unpacked or what have you? Figuring this bit out would be of great help in developing my own mod. EDIT: NM, doing a little more research, it looks like having Treeloader installed was an unspecified requirement here, as it's what uses tree.cfg files (they aren't stock).

Interesting. Although from what you're describing about the frame delay, one potentially relevant difference between my approach and codepoet's is that I checked for the flag and performed SpawnCrew() within OnUpdate() (which I believe is called on a per frame basis) rather than OnFixedUpdate() (which I believe is being called on a per physics tick update). Hence, I suspect if you're also doing the latter, it might have something to do with why you needed the frame delay, if multiple physics ticks are running per visual frame on your hardware. Anyways, just thought it worth mentioning. I chose to use OnUpdate() given this is a graphics update we're performing here with the portraits, and given the difficulties you mentioned above I thought it might be relevant enough to warrant mentioning.

My pleasure man! You discovering the SpawnCrew() aspect for your update portraits button gave me a big assist as well in pointing me in the right direction, so thank you for that

Yup, that's what we're all talking about, but I think he's referring to what happens when two separate vessels dock in game. It's handled rather differently internally than with just a single vessel (or if you launch the vessel already docked), which I also ran into when working on my fuel pump code. EDIT: Ok, so I just tested it with this docked vessel monstrosity, repeatedly sending Kerbals to and fro to the various types of command pods on the thing, and everything was fine: So yeah, I'd say just delaying the vessel.SpawnCrew() call until the next update works pretty good

Nope, not yet. It's on my todo list In theory though, if it's a problem I suspect that calling SpawnCrew() on the Part.vessel of both the source and destination part of the transfer if they differ may do the trick there.

http://forum.kerbalspaceprogram.com/threads/61632-0-23-Better-Than-Starting-Manned-%28v1-47-Hate-That-Marsupial-Feb-17th%29 My known issues list

@Papa while working on some crew management code of my own this evening, I ran into major problems updating the IVA portraits, and decided to take a peak at your code to see how you might have handled it. Turns out you hadn't found a solution either, HOWEVER, after playing around with multiple approaches and calling way too many random functions with hopeful sounding names, I seem to have come up with a solution based on the approach you use in your "update portraits" button code. Turns out if you just set a flag when you perform a crew transfer, and then call Vessel.SpawnCrew() on the next update after the transfer based on that flag, everything appears to work great. I've run a number of tests with it, and seat.SpawnCrew(), part.SpawnCrew(), or any of the other SpawnCrew() action doesn't appear to be necessary. Just remove from one part, add to another, and Vessel.SpawnCrew() next update. I can only assume that KSP is performing some kind of required maintenance on the crew between frames which only makes the SpawnCrew() call valid on the next update. Anyways, just thought I'd share in case it helps you out and potentially saves you any of the trial and error random-function-until-it-works action I just went through

I'll present a simpler alternative from my own PartModule code as well: protected void RefreshAssociatedWindows() { foreach ( UIPartActionWindow window in FindObjectsOfType( typeof( UIPartActionWindow ) ) ) { if ( window.part == part ) { window.displayDirty = true; } } } It's probably not as fast as that in the post above as it basically scans through every object in the game, but for non performance critical uses (like if you aren't spamming these in flight), that shouldn't make much of a difference and the code is quite straightforward.

Sorry for the necro here, but just wanted to answer my own question above, as I finally figured out the solution and thought it might help others down the road that may comes across this thread. Given the tweakables are just KSPFields, something like the following will serve to disable stock tweakables: tempEngineModule.Fields["thrustPercentage"].guiActiveEditor = false; tempEngineModule.Fields["thrustPercentage"].guiActive = false; So, basically all you need is a reference to the module in question, and off you go. In my case, I've decided to add a separate part module to engines where I want to have the thrust limiter disabled that scans through the other modules present in the part in OnStart(), and sets the thrustPercentage attributes for any ModuleEngines like above. From what I've seen, all KSPFields that Squad uses are public, so it's just a matter of looking at the module in question and figuring out which variable is the internal representation of the field you wish to modify. Anyways, hope that helps someone else out.

Oh, I wasn't asking you to change it man, just considering if/how I could do it myself. I'm currently considering making PreciseNode a recommended mod to go alongside Better Than Starting Manned, so I was pondering the possibility of rolling the save/load functionality into all command pods through ModuleManager and leaving the individual part out of the tech tree. Perfectly happy to do that myself, just wanted to verify that it's possible to do so Very cool mod btw. It definitely adds some much needed refinement to maneuver nodes as they're horribly finicky to manipulate in stock.

No, more what I'm saying is that the saving of nodes is "out of game". In other words, it's not something you'd expect Kerbals to have to build onto their vessels, as the save/load functionality doesn't really exist in their universe, it exists in ours so to speak. It's basically pure UI functionality rather than something you'd expect a part to have to include on a rocket for. I could potentially see having a part if say maneuver nodes were dependent on an in-game flight-computer part or something, with the ability to save them then being an upgrade, but even then, that seems a bit of a stretch. So, for me personally, I'd rather just roll all that functionality into all command pods so that it's always there without the player having to consciously remember to add a part to get it. Oh, that's entirely understandable man. I probably would have done the same myself Awesome! Thanks for the speedy reply

Hehe...I was just wondering the same thing. It's not so much not liking the part, as finding it really odd to have a part which is distinctly in-game, to provide out of game functionality like saving maneuver nodes. One additional question I have with regards to this though is what happens if a vessel winds up with multiple parts that save the nodes (say for example if you assign the module to all command pods through module manager and have a vessel with multiple pods). Does the mod handle this situation or will you wind up with multiple copies of the nodes?

Thanks Faark! Will take a look at the RemoteTech code base then. EDIT: Yup, the following does the trick: [KSPModule( "Life Support" )] class BTSMModuleLifeSupport : PartModule { } Thanks a million man. Would have taken me forever to figure that one out

Minor issue, but has anyone figured out how to set the title for a module in the new extended right-click-to-display part description pane? For example, all my custom modules automagically grab the title from the class name and it results in stuff like this: Now, I'd really prefer not to alter my mod's class naming convention just to alter the string that's displayed as a title, but so far I'm having no luck in changing it through any other method. Also, as a secondary question, does anyone know the format codes to display parts of the GetInfo() string in green or what have you? You'll notice above that "Requires:" is written in the default white, but for all stock parts, it's displayed in green. For the sake of consistency, I'd like to be able to do so as well if possible. EDIT: Figured out the second part. For reference, debug outputting the GetInfo() string for stock modules, gives stuff along these lines: <b><color=#99ff00ff>Requires:</color></b> From which the format codes can be extracted. Still have no clue on the title part though

Dude, you're totally my hero of the hour Thanks a million!

My pleasure man! I hesitate to ask given how much I know you have on your plate, but any chance for a quick patch? Related tech support on this issue for BTSM is becoming quite the headache

Yup, the OnAwake() thing worked perfectly: public override void OnAwake() { base.OnAwake(); if (part && part.Modules != null) { is_engine = (part.Modules.Contains("ModuleEngines") || part.Modules.Contains("ModuleEnginesFX")); is_eva = part.Modules.Contains("KerbalEVA"); if (part.Modules.Contains ("ModuleParachute")) parachute = (ModuleParachute) part.Modules["ModuleParachute"]; if (part.Modules.Contains("RealChuteModule")) { realChute = part.Modules["RealChuteModule"]; rCType = realChute.GetType(); } } } All that's needed is to move the above code from OnStart() over to OnAwake() and everything works great

Yeah, my test worked. What I basically did was add a tracking variable to the aero module, and the following code to the beginning of FixedUpdate(): public void FixedUpdate () { // FCMOD: if ( !bInitialized ) { is_engine = (part.Modules.Contains("ModuleEngines") || part.Modules.Contains("ModuleEnginesFX")); is_eva = part.Modules.Contains("KerbalEVA"); if (part.Modules.Contains ("ModuleParachute")) parachute = (ModuleParachute) part.Modules["ModuleParachute"]; if (part.Modules.Contains("RealChuteModule")) { realChute = part.Modules["RealChuteModule"]; rCType = realChute.GetType(); } bInitialized = true; } Which is basically just a copy of your new init bits from OnStart(). Everything works as it did with the above change. Going to try something a bit cleaner now, like I suspect moving the init over to OnAwake() might do the trick.

Hehe...I think I just reached a similar conclusion right before reading this by reverting various bits of the code. It looks like the is_engine tracking variable is basically failing to initialize at the appropriate time and is basically constantly false. I suspect that may also apply to the other tracking variables being set in OnStart(), but I haven't confirmed that bit. Just about to test a potential solution, and will report back in case it helps you out.

Just a little more info: turns out my hunch appears to have been wrong above. Replacing the function in question with the one from the previous version produces the same behavior. Will continue digging

Yeah same here man. Totally burned tonight, but will be digging into it further tomorrow

@Nathan: It appears that version 4.2 has a problem where the visual heat meter in the staging display for engines no longer relates to the actual heat of the engines, causing them to have a tendency to start taking damage and explode when the meter is only around the halfway point. 4.1 didn't have this issue, and it makes managing the throttle of high heat engines rather difficult It seems similar to some of the problems I encountered that I previously mentioned when I attempted to create a custom engine module child class, so I think some of the new optimized code may be failing to recognize parts as engines in some places. I'll dig a bit into the code and see if I can find what's causing it as I put out a new release of BTSM last night, and it's been causing a great deal of confusion amongst players who also updated to the new DR at the same time. EDIT: One thing that jumps out at me that might have something to do with it is the following change: Old version: [KSPAddon(KSPAddon.Startup.EditorAny, false)] public class FixMaxTemps : MonoBehaviour New version: [KSPAddon(KSPAddon.Startup.MainMenu, false)] // fixed public class FixMaxTemps : MonoBehaviour Just a hunch mind you. Will run further tests and keep digging.

Just one thing to note that I think I've figured out about how DR works: I think a lot of times when it says something is destroyed due to g-forces, heat is actually the problem. My understanding of how the code functions is that when a part overheats, it begins to sustain damage. This lowers the g-force tolerance of the part, along with a few other variables (like how much torque it can withstand on attached nodes). As a result, parts will often display as being destroyed by g-forces due to this lower tolerance, but it was the heat that caused that lower tolerance in the first place. I agree that could definitely be a little clearer though in terms of player feedback, and not saying the Rapier in particular doesn't have issues (which Nathan seems to be on top of), just wanted to point out that when a part is listed as destroyed by g-forces, that isn't necessarily the problem, it's just what finished it off.

This is likely a face-palmingly simple question for more experienced KSP modders, but given I've tried multiple options to no avail, I'd figure I'd ask: Does anyone know how to access the title associated with a part (eg. "Stayputnik") given a part or partModule within code, rather than the class names or what have you? I'm likely missing something obvious, but going over the variables in the Part class and trying out a number of them, I can't seem to find it. EDIT: NM, occurred to me just after I wrote the above that Deadly Reentry was displaying this so I was able to check out its code. For reference in case anyone else has this issue: part.partInfo.title does the trick.

EDIT: NM, combination of user error and me being too tired to recognize it. Please ignore