albany_

Hi Merill -- how would you like to handle distribution of your plugin(s) (specifically, PartUpgrade)? I'd like to utilize the plugin for a little part mod I'm working on but I wasn't sure what your desires were in regards to how the plugin should be distributed -- i.e., should the download redirect users to you for downloading the plugin, or should it be bundled with the add-on like ModuleManager? EDIT: Now that I've had some time to play around with the plugin's features I have to say, this is really neat for OCD folks like myself who hate additional parts. The only thing I'm finding myself wanting would be the ability to update the base non-module part cfg elements with research (e.g., name, description, etc). Is this functionality something you'd consider adding?

I'm not sure if this is the correct forum for this question, but it seemed closest related to what I was asking. I have a part that I'd like to be able to "upgrade" as you unlock nodes in the R&D tree. I could simply add in multiple versions of the part that unlock at different nodes, but then you run into linearity issues ("what if I've unlocked this node but not this node?", etc.). Additionally, I'd like to avoid having more than one part in the mix for simplicity's sake. For someone completely unversed in plugin development (or programming in general, really), is there a way of accomplishing what I described? EDIT: I should note, I was inspired by MechJeb's user experience, how MechJeb has a controller that determines what you have researched and unlocks the correct modules accordingly independent of the part itself, but I had a hard time making sense of exactly how this was accomplished from MechJeb's source. EDIT2: Found a possible solution via a post I missed during my searches by Merill.

Ven added some IVA references in the GitHub repo recently -- haven't looked at them in-game yet, but if nothing else they are in the works. EDIT: Just checked latest from GitHub, appear to be a few bugs to iron out before they're ready for use -- launching a craft with a KerbCan was causing the world to disappear, only showing the skybox.

Not sure what proper etiquette is for this situation, but I made a pull request to correct an issue with the KerbCan wherein you can't EVA kerbals in the KerbCan because there's no crew portrait for them (because there's no internals entry in the .cfg). Wasn't sure if this was just an oversight or deliberate, but if it's the former it's there if needed.

Is the revamped "Poodle" engine taller than the stock version? I feel like I had a harder time putting landing struts on the revamped version than I remember having with stock, but I'm also wrong occasionally.

Looks like a standard out of memory crash. You can try converting some of your mod textures to .dds files if you haven't already (quick Google should provide info on how to do that/the benefits of doing so). Be sure to continue disabling temp gauges. Other than that... yeah, out of memory, no magic way around it. I recently returned to KSP after 1.0 and I feel like there's a lot less room for modding purposes now.

Are you volunteering?

It'll work for other science mods. They probably won't have biome-specific results, but they will grant science.

It's a real shame that we stand to lose all of this awesome content from creators who are no longer active in the community.

Does anyone happen to have this that could upload to Curse, or even just share it on Dropbox?

This is amazing. +100