JPLRepo

What upgrade to increment on? - Not sure what you mean. Do you mean how it decides what costs to increment? If the upgrades are not exclusive then whatever upgrades you have unlocked are applied one by one to the part base cost field. If you have multiple upgrade nodes that unlock in different parts of the tech tree on the same part then you can just use the IsAdditiveUpgrade__ = true and costAdd field. It will still work the same even if the first node unlocked has a costAdd field. I'm not sure if that answers your question? Some other things that got left out of my original post are: UPGRADE nodes on PartModules can also include: IsExclusiveUpgrade__ = true - this works opposite to IsAdditiveUpgrade__ = true and will wipe out any other unlocked upgrades for that PartModule/Part. description__ = <text> - description text that will appear in the Show Part Upgrades window and tech tree. ExclusiveWith__ = <text> - can be used to group exclusive upgrades on a PartModule. So I could have say 3 UPGRADE nodes on an engine module to progressively upgrade it's thrust that can be made exclusive of each other using this field. Independant of say another group of UPGRADE nodes on the same engine module to progressively upgrade the atmosphereCurve of the engine. For examples take a look at the part configs and upgrade configs in the Revamped Parts pack.

I think I know what is going on here. Can you change your vessel's type from Plane to Ship and confirm the issue goes away? (You can change your vessel type in Map View by clicking the info button on the right side then double clicking the vessels name).

Can you try with V0.1.9.0? oh. only if you have updated to KSP1.2. Sorry missed this. I just noticed this as well. Looking into it.

I've already applied that fix. Are you having an issue?

Vessel.maxControlLevel is exactly that. It enables you to restrict the Maximum control level for the vessel. It sounds like you want to actually set the control level to a specific value though? Can I ask why? ..and yes. The control level is set by first checking the Commnet control level is the vessel has a connection and then the maximum value of all the parts on the vessel. Which will always probably be the part with ModuleCommand on it. In theory I believe you can override this though using the interface you mention.

Ok, what's happening here is you are confusing "IsAdditiveUpgrade__" with what is applied to a field. "IsAdditiveUpgrade__" does not mean overwrite the previous value of a field. If set to true, It means Add this UPGRADE node to Previous UPGRADE nodes. If set to false, It means Delete previous UPGRADE nodes and apply this UPGRADE node. This is relevant if say you want to change different fields in different upgrades (Tech nodes). So I could say change the maxTemp at a level 1 tech node. At a level 2 tech node I might want to also change maximum_drag, but STILL apply the level 1 MaxTemp change in which case I set IsAdditiveUpgrade__ = true. If on the other hand I didn't want the level 1 maxTemp change when the level 2 upgrade is unlocked/purchased then I would set IsAdditiveUpgrade__ = false in the level 2 UPGRADE node. Hope that clarifies how this field works? As for the cost and mass fields. They are additive to the BASE (original) part cost and mass field. So let's say my base part cost is 1000 and mass is 1. If I want my cost to be 2000 and mass 0.9 at the first tech node UPGRADE I would specify mass = -0.1 and cost = 1000 in a PartStatsUpgradeModule Upgrade node for that tech level. If say I want it to be 2500 and mass 0.8 at a second tech node UPGRADE I would specify it differently depending on whether I want this second upgrade to be additive to the first or not. But in both cases whatever I specify IS added to the BASE fields for the part. @PART[enginex] { MODULE { name = PartStatsUpgradeModule showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = Enginex-GenRocketry-Thrust techRequired__ = generalRocketry IsAdditiveUpgrade__ = false PartStats { maxTemp = 2500 cost = 1000 mass = -0.1 } } UPGRADE { name__ = Enginex-engineering101-Thrust techRequired__ = engineering101 IsAdditiveUpgrade__ = false PartStats { cost = 1500 mass = -0.2 } } } } } PARTUPGRADE { name = Enginex-GenRocketry-Thrust partIcon = liquidEngine2 techRequired = generalRocketry entryCost = 10000 cost = 2000 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = Enginex Thrust Upgrade basicInfo = The Enginex upgrade certifies that the engine will consistently deliver Turbopump enhancements and other detail improvements lead to lower temperatures. advances in alloys have lowered it's weight. manufacturer = Kerbodyne description = The Enginex engine now has a max temp of 2500 and weight of 0.9t. } PARTUPGRADE { name = Enginex-engineering101-Thrust partIcon = liquidEngine2 techRequired = engineering101 entryCost = 10000 cost = 1800 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = Enginex Thrust Upgrade basicInfo = Further advances in weight reduction have reduced weight to 0.7t but it has lost it's temperature improvements. manufacturer = Kerbodyne description = The Enginex engine weighs 0.7t. } So if in my second UPGRADE I specified IsAdditiveUpgrade__ = false then I would specify mass = -0.2 and cost = 1500 in that node. If in my second UPGRADE I have specified IsAdditiveUpgrade__ = true (for reasons specified above) then it would depend on whether the first UPGRADE node also has mass and cost values specified. If it does not include mass and cost then I specify mass = -0.2 and cost = 1500 (and these are applied to the base fields). If my first upgrade does have mass = -0.1 and cost = 1000 then I need to specify the massAdd and costAdd fields instead. So it would be massAdd = -0.1 and costAdd = 500. @PART[enginex] { MODULE { name = PartStatsUpgradeModule showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = Enginex-GenRocketry-Thrust techRequired__ = generalRocketry IsAdditiveUpgrade__ = true PartStats { cost = 1000 mass = -0.1 } } UPGRADE { name__ = Enginex-engineering101-Thrust techRequired__ = engineering101 IsAdditiveUpgrade__ = true PartStats { costAdd = 500 massAdd = -0.1 } } } } } PARTUPGRADE { name = Enginex-GenRocketry-Thrust partIcon = liquidEngine2 techRequired = generalRocketry entryCost = 10000 cost = 2000 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = Enginex Thrust Upgrade basicInfo = Advances in alloys have lowered it's weight. manufacturer = Kerbodyne description = The Enginex engine now has a weight of 0.9t. } PARTUPGRADE { name = Enginex-engineering101-Thrust partIcon = liquidEngine2 techRequired = engineering101 entryCost = 10000 cost = 1800 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = Enginex Thrust Upgrade basicInfo = Further advances in weight reduction have reduced weight to 0.7t but it has lost it's temperature improvements. manufacturer = Kerbodyne description = The Enginex engine weighs 0.8t. } Now that is to get the correct amount deducted for your part. This is not what is displayed in RnD and in the editor. For that you need to specify a PARTUPGRADE node. What you specify in the PARTUPGRADE cost field is what is shown to the user. So for each PartStatusUpgradeModule you need to specify a matching PARTUPGRADE. Hope that helps to explain it. If not shoot me a reply here.

It's because of the shape I think. You might have to break it up and make simple copies of the whole mesh in parts. Or just use primitives in Unity.

As there seems to be a lot of people desperately waiting for this mod for KSP 1.2 I've done a Development Build. The Dev build is available ONLY on GitHub at this location: https://github.com/JPLRepo/ResearchBodies/releases/tag/V1.9-Develop Warning: Although this functions and I have done individual component testing, I have not done full game play testing in KSP 1.2. So use at your own risk. Back up your save files! But I'd appreciate feedback, bugs, etc. ChangeLog: V1.9.0-Develop (10-23-2016) == DEVELOPMENT BUILD *Fixed typo in locales for Characteristics and Orbit in UI. *Added Observatory SpaceCenter Facility. Yes - this Facility acts exactly like a stock one. It has TWO upgrade levels that provide different features, functions and contracts for Finding an Researching celestial bodies. *New Game and Settings for this mod are now accessed via the Stock Difficulty Settings for new game and existing game. This is by no means a completed version for Release V1.9. It currently has a placeholder Facility UI for the new Observatory. To Do before Full release: A stock-a-like Observatory UI screen. Contracts and long-term observation tasks for the Observatory. EDIT: forgot to mention. Code is in develop branch on GitHub. License for new Observatory code components is All Rights Reserved. Other parts of original code, etc are MIT and models are CC-BY-NC-SA 4.0 License details are included in the Zip file.

Please take it down. If you wish to fork and release a deritive version please let me know. The problems this will cause is when people use this and encounter errors they are going to come here with bugs that I am not going to support and will create more hassle for me.

Yes that is how it is meant to work. There is no bug. Decouplers will only detach a part attached by a node. AS for KIS/KAS - can't answer that. That's a question for those mods.

Lots of your mods are not updated for KSP 1.2.

Do you mean like this? If you attach a part to a docking node via it's attach point/node (the green circle) then you can decouple the part - as in the first node in this pic under the command pod can detach the yellow RCS tank below it. If you attach a part radially to a docking node (not by it's attach point) as the bottom tank is then you cannot decouple it.

Well no one is going to be able to provide you with any assistance unless you supply some logs.

There is a bug/typo in the config file for the US Waste Wedge which means it does not complete loading correctly and does not function as a waste storage part. See this post.

Yep, that's a problem with that config file which is part of Universal Storage mod. It's not a TAC LS issue. The problem is the line in bold below. Remove it and it works. I've reported this as a bug on the Universal Storage mod thread.

It's what @Vjrcr said. By the looks of your screenshot you are missing a transform to tell the engine module where to apply thrust and effects. Aka thrustTransform. Go here and watch the engine setup tutorial videos and other links on engines.

V0.1.9.0 published. This fixes an issue where part triggers (like ladders, hatches, internal cameras) where causing JSIATP to think the part had something in front of it and was turning off the transparency feature when it shouldn't have been.

It's documented here Any questions fire away. if the goal is to have a Modlet to change the upgrade setting for sandbox that is a very simple thing. I can knock one up if there's enough demand for it.

I'll see what I can do. If you don't want to use the hexcans just delete the folder: <KSPdirectory>\GameData\ThunderAerospace\TacLifeSupportHexCans EDIT: https://github.com/KSP-RO/TacLifeSupport/issues/53

Do you mean if you disable TAC LS for a save game you want the parts to also be disabled (not visible) in that save game? That can be done.

Agree. Seems MM is working as designed. If you don't want to apply to those parts, exclude them.

Update regarding KSP 1.2: I am working on an update. Have worked through most of the parts and made adjustments. I still have to re-balance and fix the Ranger and Lander.

Thanks for putting all that effort in. Really appreciated. https://github.com/JPLRepo/AmpYear/issues/51

start here

You have version 1.4 of AmpYear installed. Try the latest 1.4.1. Also, I noticed the log in your previous post contains multiple Module Manager installations as well.