TranceaddicT

@SpannerMonkey(smce) Thanks for the info. I thought it might work in light of InfernalRobotic's sliding thingys. Drat.

@severedsolo Nice work! I'll be adding this to my list of realism-ish must-haves. With regards to the destruction effect, would a damage model be out of the question? A micrometeoroid impact is more likely to result in damage than destruction. It could be interesting if you tied impact to ...

First thing is to make sure you're running the latest version of CKAN . https://github.com/KSP-CKAN/CKAN/releases There is a new functionality, as of 3.0.1, that will allow you to import a previously downloaded mod with the correct modname . If I remember correctly it's with the F10 key.

I've taken the CommTech EXP-VR-2T antenna from RemoteTech and repurposed it via an MMconfg to act as an extender. Things went well and I've duplicated the part and given it an attachnode at the top. Here it is attached to a probecore with a RA-2 Relay Antenna attached. Unfortunately, when I extend the part this happens: Is there anyone savvy in the ways of fixing it so the attachment node (and attached part) extend WITH the animation? Here's the code for the MMconfig: // ********************************************************************************** // *** File: AS_Antenna_Extender.cfg // *** Author: TranceaddicT // *** Contributors: // *** Description: Repurposing an animated antenna as a structural extender // *** License: CC BY-NC-SA 4.0 // ********************************************************************************** +PART[RTLongAntenna3]:NEEDS[RemoteTech]:FINAL { %name = deviceExtender %author = TranceaddicT !mesh = DELETE MODEL { model = RemoteTech/Parts/LongAntenna3/model } // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision %attachRules = 1,1,1,1,1 // node rules: x, y, z, angx, angy, angz, size %node_stack_top = 0.0, 0.15, 0.0, 0.0, 1.0, 0.0, 0 %TechRequired = Start %category = Structural %title = UL-101 Radial Extender %manufacturer = Unlimited, Ltd. %description = A plesant discovery after an engineer glued a pencil to the end of a CommTech EXP-VR-2T and started poking the Mission Controller from across the room. %tags = build connect construct extend structur support !MODULE[ModuleRTAntenna] {} !MODULE[ModuleSPUPassive] {} MODULE { name = TweakScale type = free } @MODULE[ModuleAnimateGeneric] { %actionGUIName = Toggle %allowManualControl = true %actionAvailable = true %eventAvailableFlight = true %eventAvailableEditor = true %eventAvailableEVA = true %evaDistance = 5 } }

Thanks guys. Color me blnde ... err, blond ... err, blonde.

The best and most valuable thing you can do is to learn to use ModuleManager. It will simplify this process, reduce clutter and save on storage space. So, it looks like you are trying to replicate Parts/Structural/structuralMicronode/structuralMicronode.cfg Install ModuleManager. Open any text editor and past this" +PART[structuralMiniNode]:FINAL { %name = structuralMicroNode.cfg %author = Daveroski %title = My Micronode %description = A pint-sized Structural Micronode %rescaleFactor = 0.5 } +PART, creates a new part based on the [partName] :FINAL, make MM run this config after all others %, edits a value if it exists or creates a new value Note the rescaleFactor. Here, I'm assuming you are trying to make a smaller node Create a directory in your GameData folder called My_MMConfigs Save this as Filename: structuralMiniNode.cfg Now, you have a 202byte file instead of a 95.6kB folder. Result: Stock Structural Node on the bottom and the new Node on top. ModuleManager wiki: https://github.com/sarbian/ModuleManager/wiki

Then there is this at the bottom of the OP: Changes : - merged with my wildcard extension - add a "~" operator to check for missing properties - let you use wildcard search in other part than the name of the part - let you patch other things than PART (this was working with MM but not with MMExt) - handle badly formatted cfg file better - include Majiir workaround for KSPAddon bug - a bit more verbose and all log line start with [ModuleManager] to make search easier - you can have multiple MM dll installed in the root of gamedata, only the newest will run - a special tag allow excluding MM from processing a folder - % operator for value and node that edit if the value/node is present and add it its not - $ operator that duplicate it (It does not work for a root node, ie a PART) - @NODENAME,2 {} let you select the third node of that name. Be careful when you delete or add a node as the index will change. Todo : - re-apply patch when you reload the database from the debug menu. It's quite a useful feature but won't change much for mod use. No promise for this. I had something working but it failed at the second reload. KSP code makes this quite hard. I may take the easy way out and just add a button. Then there is this: - a special tag allow excluding MM from processing a folder I would love to know more about.

So, I can't believe I'm saying this but, is there a setting I'm not aware of that let's us purchase individual parts instead of glomming them all at once when researched in RnD? I was watching a video of a KSPer playing an noticed that he did not have all the parts in a node available. How does this happen? For me, when I go to RnD and click on an unresearched node I get a blue bar with the science symbol indicating I need to spend X science point. When I do that ALL the parts are, thereafter, "owned". This player has a green bar with the funds symbol and has purchased individual parts marked "owned" while others remain and require funds to purchase. My RnD His RnD

KSP 1.3.1 Scale v2.3.7.0 = True It starts here: [LOG 19:41:30.473] TweakScale::PrefabDryCostWriter: Start [ERR 19:41:30.474] [TweakScale] Exception on writeDryCost: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.WriteDryCost () [0x00000] in <filename unknown>:0 [LOG 19:41:30.474] [TweakScale] part=kerbalEVA () [ERR 19:41:30.474] [TweakScale] Exception on writeDryCost: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.WriteDryCost () [0x00000] in <filename unknown>:0 and runs for another 2420 lines.

Go here. https://github.com/sarbian/ModuleManager/wiki

Right! That got it!!! Now, if I can just figure out why RESOURCE[ElectricCharge] is getting taken away by the new config ... EDIT: YEAH! Got that one figure!

I've looked around but I am unable to find an example of multi-type configurations. Just trying to logic it out, would this work? @PART[FASA_Gemini_Lander_LFT] { MODULE { name = ModuleFuelTanks type = Default, ServiceModule volume = 255 } } Or, can you point me to an existing config?

For those fixing the MMConfigs before the ModAuthor gets to them.. remove the second condition statement that references the mod for the file you are fixing. In this case, since this is a MMConfig by SETI, removing the :FOR conditional is the correct fix.

So, I'm wondering if it is possible to do this to a new game ... @SCENARIO[ScenarioNewGameIntro] { %kscComplete = True %editorComplete = True %tsComplete = True }

So I"m wondering if, during the starup phase of KSP (i.e. before you're in the game), this is normal: [LOG 16:02:05.796] [TweakScale] part=OSE.WorkshopAiCore (Workshop AI Core) [ERR 16:02:05.796] [TweakScale] Exception on writeDryCost: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.WriteDryCost () [0x00000] in <filename unknown>:0 About half of my log file is this stuff, even before I begin playing.

Wasn't there a time when we could switch tank types in the VAB? The reason I ask is that I'm trying to use FASA_Gemini_Lander_LFT as a pressurized tank. I know that %type = ServiceModule creates the "pressurized" tank and allows it to use UDMF/IRFNA. Unfortunately, for my situation, to accomplish this requires SaveFile editing. Is that still around? Or, am I missing something?

You could also go through the files and remove any extraneous :FOR[SETIrebalance] directive. Example: In the file : /GameData/SETIrebalance/MM-PartModding/SETI-PartMod-VenStockRevamp.cfg Change: @PART[KerbCan]:NEEDS[VenStockRevamp]:AFTER[VenStockRevamp]:FOR[SETIrebalance] To: @PART[KerbCan]:NEEDS[VenStockRevamp]:AFTER[VenStockRevamp] Make sure you ONLY REMOVE the extraneous directives. If the patch contains somthing like: @PART[asasmodule1-2]:FOR[SETIrebalance] or @PART[K2Pod]:NEEDS[JFJohnny5]:FOR[SETIrebalance] leave these :FOR directives in place. @Yemo I've already gone through all my files and done the above. If you have a git repo I can help.

You don't even need to revert. The errors are still there, merely suppressed because MM is now revealing them. You will still get the same results. Either wait for Yemo to update or edit the files and remove the offending code. Personally, I'd say just wait.

@AngrybobH, no need to thank me. I know how to spot errors and I know enough to get myself into MMHell ... just not out.

Thank you. I've been conflating NEEDS/FOR for a long time. Wow, that just makes things so much better.

@AngrybobH It's probably the combination of the multiple directives. Use only one. Look for this error: "[ModuleManager] Error - more than one pass specifier on a node"

Those [ModuleManager] Error entries are related to the update of MM. They were there before but have now been exposed by the update. The respective mods need to modify their configuration files.

That's not my understanding from the wiki. I thought :FOR is a part of the ordering pass (1st - no directive (aka LEGACY), 2nd - FIRST, 3rd - BEFORE/FOR/AFTER, 4th FINAL) in which MMConfigs are applied. To my understanding, using the :FOR directive means that a patch is applied IF the mod exists. This: +PART[MyPart] { name = MyNewPart } creates a new part called MyNewPart from MyPart all the time. Adding the :FOR directive like this: +PART[MyPart]:FOR[SomeMod] creates the part MyNewPart from MyPart ONLY if SomeMod is installed because otherwise, the patch will error and no new part is created. Am I off?

On a related topic ... If I create MyGreatMod, is there a valid reason I would need to include the :FOR[MyGreatMod] directive in the configuration file I provide?? Shouldn't :FOR only be used by other mods with configs calling GreatMod?

Thank you for that. Just a note for everyone who might use it, that command doesn't just generate a dump file; it will actually run KSP. (humorous sidenote: I now know my system can run simultaneous KSP instances.)