steddyj

@JadeOfMaar I've finally had the chance to circle back to this. The issue isn't that something has renamed ModuleEnginesFX, and it looks like you addressed that anyway since your patch looks for ModuleEngines*. Here's the MM cache from the failing part: UrlConfig { parentUrl = Bluedog_DB/Parts/Engines/bluedog_NERVA_II.cfg PART { name = bluedog_NERVA_II module = Part author = Zorg rescaleFactor = 1 node_stack_top = 0.0, 3.57987, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -3.69958, 0.0, 0.0, -1.0, 0.0, 2 TechRequired = nuclearPropulsion entryCost = 45000 cost = 15000 category = Propulsion subcategory = 0 title = LVN-2 "Redwood" Nuclear Engine [R] manufacturer = Bluedog Design Bureau description = Built around an incredibly powerful reactor, this nuclear engine emphasises thrust to enable demanding crewed interplanetary missions. <br><#fc5a50>RR Reducing Agent NTR.</color>\n<#00CE03>B9PartSwitch - This part has selectabale engine configs via the part action window. Some configs may be unlocked via upgrades.</color> attachRules = 1,0,1,1,1 mass = 3.5 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 18 breakingForce = 300 breakingTorque = 300 maxTemp = 2500 bulkheadProfiles = size1p2 stagingIcon = LIQUID_ENGINE stageOffset = 1 childStageOffset = 1 tags = nuclear nuke STNP NTR thermal LH2 Cryo NERV NERVA II 2 Phoebus cck-rr RRNF = Joined skinMassPerArea = 1 emissiveConstant = 0.8 heatConductivity = 0.03 skinInternalConductionMult = 4 MODEL { model = Bluedog_DB/Parts/Engines/bluedog_NERVA_II } MODULE { name = ModuleEnginesFX thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 222.2 powerEffectName = running_engine engineID = LH2 heatProduction = 1425.02143422222 exhaustDamageMultiplier = 4040.3398 partThermalMass = 70 exhaustDamageMaxRange = 14.9063744753713 exhaustDamageFalloffPower = 2 exhaustDamageMaxMutliplier = 0.125 PROPELLANT { name = LqdHydrogen ratio = 1 DrawGauge = True resourceFlowMode = STAGE_PRIORITY_FLOW } atmosphereCurve { key = 0 824 key = 1 49.44 key = 12 0.001 } } MODULE { name = ModuleB9PartSwitch switcherDescription = Engine Config switcherDescriptionPlural = Engine Configs moduleID = engineSwitch uiGroupName = partSwitch uiGroupDisplayName = Part Switch SUBTYPE { name = NERVA_II_70 title = NERVA II - 1970s descriptionDetail = <b>Thrust:</b> 13 kN ASL / 222.2 kN Vac.\n<b>Isp:</b> 50 s ASL / 825 s Vac. } SUBTYPE { name = NERVA_II_80 title = NERVA II - 1980s descriptionSummary = A 25% improvement to reactor output results in significant thrust and Isp uplift. descriptionDetail = <b>Thrust:</b> 17 kN ASL / 278 kN Vac.\n<b>Isp:</b> 52 s ASL / 850 s Vac. MODULE { IDENTIFIER { name = ModuleEnginesFX engineID = NERVA_II } DATA { maxThrust = 278 atmosphereCurve { key = 0 850 key = 1 250 key = 12 0.001 } } } } } MODULE { ... [There is more but I think everything relevant is above] This engine has an upgraded variant with B9PartSwitch. The error is because it can't find its unique engineID which was defined in the parent part before RRNF overwrite the module. it looks like RRNF doesn't have any way to catch an engine variant when it's rewriting ModuleEnginesFX. I'm not sure how commonly this might happen, perhaps without warning because another engine might be using a standard fuel type. I did modify the type to LH2 which resolved one of the two errors, but it still chokes on the cloned Oxidizing engine because it's expecting LqdCO2. I'm not sure how to address this other than to nuke out the upgrade option altogether, or to split it into its own part.

@JadeOfMaar Can you be more specific as to what I'm looking for in the MM cache, since it will be so obvious? As stated above my cache was cleared before building the test environment which throws the first two errors. I haven't done a full reinstall on the live game yet but even if I do it still doesn't resolve that pair of issues on the Nerva II that only arises when I have Nuclear Family installed. edit: I circled back to this when I realized you said MM, I repeated MM, and yet my brain was still thinking CKAN. Now I'm following you more clearly but I'm even less clear what we're looking at.

@JadeOfMaar Yeah, I'm expecting it to be something like that. Which is why I'm testing with BlueDog, because both it and RR explicitly mentioned support for each other in their forum posts. At least I thought they both did, but looking now your post only mentions them for Hypergolics and they don't seem to mention you at all so I think I was more relying on a third mod that recommended running them together. RealFuels is not the issue in this case, it's not in either install. I've also searched through both installs and there is no reference to ModuleEnginesRF at all in my test build. My live build has it referenced in StageRecovery's DLL and a compatibility patch in Planetary Bases. Here's what's in the testbench. My cache was cleared and this was installed today with the latest CKAN has to offer (which may be out of date, which is what brings me here): Yet I still get these errors, only when I have RRNF in the mix. Which looked a lot like what you pointed to as issues with SystemHeat earlier. Especially when you look at the run from my live game which is tripping mostly on the Reducing Agent engine duplicates that RR makes, but not apparently the originals. I think I DID have problems on the originals before, because I was seeing the original followed immediately by the -rr earlier in my investigation, perhaps before I had 2.0.7.1 installed. I'm definitely still getting the errors below:

So I've been tracing this issue I've been seeing through most of this morning and it's lead me right here. I believe I'm seeing more issues with RR and SystemHeat, this time in the Nuclear Family. The below log segment is from my test install that only has BluedogDB and its dependencies (which include SystemHeat) and RR with RR Nuclear Family. It accompanies the same B9 popup error on load that others have posted. [LOG 13:34:00.614] PartLoader: Compiling Part 'Bluedog_DB/Parts/Engines/bluedog_NERVA_II/bluedog_NERVA_II' [WRN 13:34:00.616] PartLoader Warning: Variable RRNF not found in Part [LOG 13:34:00.625] PartLoader: Part 'Bluedog_DB/Parts/Engines/bluedog_NERVA_II/bluedog_NERVA_II' has no database record. Creating. [LOG 13:34:00.625] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 13:34:00.629] DragCubeSystem: Creating drag cubes for part 'bluedog.NERVA.II' [WRN 13:34:00.646] Warning on PartSubtype NERVA_II_80 on module ModuleB9PartSwitch (moduleID='engineSwitch') on part bluedog.NERVA.II: Could not find matching module [EXC 13:34:00.652] Exception: Could not find matching module B9PartSwitch.ModuleMatcher.FindModule (Part part) (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.ModuleModifierInfo+<CreatePartModifiers>d__10.MoveNext () (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.PartSubtype.Setup (B9PartSwitch.ModuleB9PartSwitch parent, System.Boolean displayWarnings) (at <a3c2951fc74e4639820ef37d2d29f386>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) B9PartSwitch.PartSubtype:Setup(ModuleB9PartSwitch, Boolean) B9PartSwitch.ModuleB9PartSwitch:InitializeSubtypes(Boolean) B9PartSwitch.ModuleB9PartSwitch:GetInfo() PartLoader:CompilePartInfo(AvailablePart, Part) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [WRN 13:34:00.659] DontDestroyOnLoad only works for root GameObjects or components on root GameObjects. [LOG 13:34:00.666] PartLoader: Compiling Part 'Bluedog_DB/Parts/Engines/bluedog_NERVA_II/bluedog_NERVA_II-rr' [WRN 13:34:00.669] PartLoader Warning: Variable RRNF not found in Part [LOG 13:34:00.677] PartLoader: Part 'Bluedog_DB/Parts/Engines/bluedog_NERVA_II/bluedog_NERVA_II-rr' has no database record. Creating. [LOG 13:34:00.677] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes. [LOG 13:34:00.681] DragCubeSystem: Creating drag cubes for part 'bluedog.NERVA.II-rr' [WRN 13:34:00.701] Warning on PartSubtype NERVA_II_80 on module ModuleB9PartSwitch (moduleID='engineSwitch') on part bluedog.NERVA.II-rr: Could not find matching module [EXC 13:34:00.701] Exception: Could not find matching module B9PartSwitch.ModuleMatcher.FindModule (Part part) (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.ModuleModifierInfo+<CreatePartModifiers>d__10.MoveNext () (at <a3c2951fc74e4639820ef37d2d29f386>:0) B9PartSwitch.PartSubtype.Setup (B9PartSwitch.ModuleB9PartSwitch parent, System.Boolean displayWarnings) (at <a3c2951fc74e4639820ef37d2d29f386>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) B9PartSwitch.PartSubtype:Setup(ModuleB9PartSwitch, Boolean) B9PartSwitch.ModuleB9PartSwitch:InitializeSubtypes(Boolean) B9PartSwitch.ModuleB9PartSwitch:GetInfo() PartLoader:CompilePartInfo(AvailablePart, Part) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) I would post the popup but I can't seem to insert an imgur link for some reason. Worthwhile of note is that these are the only two errors that I'm getting with BDB and RR (Nuclear Family), but in my Live game I get a long list of errors with what I now realize is many different mod packages and I had assumed everything was from Bluedog since that's such a big package. They seem to be mostly on the duplicate -rr items that get made for the reducing agent engines. I can provide the full log file from my live game if you want, but its heavily modded so it's a pretty extensive file. Whatever's going on here I think you need to be able to address it procedurally rather than addressing individual modpacks.

@Untoldwind I just noticed that CKAN somehow seems to have 0.5.8.4 as 0.5.9.4, so it did not pick up the update you made the other day (0.5.8.5) as the latest release. It doesn't seem to have indexed it at all, the versions tab show 0.5.8.4 released 4/15/2024 4:03pm and 0.5.9.4 released 2 minutes later. ... and sorry to ping you then ask this question, but the making sure I had done my homework on the question I had led me to discovering that release mismatch. Am I correct in assuming there's no current way to use debug lines in the VAB? It seems to me that there's nothing stopping it, other than it requires a GlobalPosition and GlobalVector. I want to indicate Forward/Right/Up from my command module using the Vec3 relative_position, but I can't find anything to use as a reference to get a valid TransformFrame. I'm assuming that I need an existing Global type to get the TransframeForm from, am I incorrect here?

Hey guys, I use Custom Barn Kit to make a few changes to the KSC, including allowing a much higher contract limit. It's actually unlimited at L3, which I currently have the upgrade for. However I'm still artificially limited to just a few depending on the difficulty level. I'm pretty sure it's Contract Configurator which is adding this limit. I saw some posts back in 2016 for this feature to be configurable and/or disabled in settings, however I don't see any way to do that. The only thing I've found so far is that the limits were raised. I just don't want to have a limit on the number of open contracts I keep. Just not the way I want to play my game. Is there a way to change this that I haven't found, or is this a brick wall?

@Tyko (and everyone): @Tidal Stream is not expected to make any permanent fix for this or any other issues. He mentioned a few weeks ago that he is no longer playing KSP nor is he actively maintaining this mod. He might push a new release if someone submits a pull request, but he's either not chiming in here because either this isn't (as of yet) a permanent fix or he's no longer following the forum. All in all, this mod needs a new maintainer. @ozraven - I would venture that the new bug may be caused by the chunk of code you removed earlier to fix the issue with the tanks remaining in the menu. I frankly didn't look that closely at that part as I was focused more on the node issue, is that what you've added back (in whole or part) in this new patch? As to your earlier comment I do understand the tolerance, just not why it's looking at that coordinate at all. Why would a top/bottom node be +/-.5 on Y, and apparently ONLY on Y because the actions taken if true is to offset X and Z by the same? Also, why is it important to have all of those coordinates offset?

Yeah.... I looked at your diff file and... yes. This is a hack. I mean this with no disrespect, just a caution to anyone who may not be willing or able to look at the diff file to see what you did. For the layman, there's a seatbelt in the Procedural Parts car that was getting stuck. So Ozraven took it out. 100% guarantee of no problem. (100% guarantee is void if vehicle is involved in an accident.) In fairness this is exactly what he said he did, but I'm fond of colorful metaphors that people seem to find relatable. Also in fairness, this seatbelt may do nothing more than keep your big gulp firmly in the cupholder, I don't know. To get a bit more nerdy about the issue if (Mathf.Abs(Mathf.Abs(position.y) - 0.5f) < 1e-5f) So my C# is very rusty and I haven't done any Unity programming at all. If I'm reading this correctly : We're working on an attachment node (if I understand correctly what an Attachment object is) This returns true of the Absolute value of (The absolute value of ( attachment node's position on the y axis) - .5 ) is less than .00005). the only way for this to return true is if position.y = [+/-.49995-.50005]. This jives with the preceding comment, "This is easy, just get the UV and location correctly and force an update. as the position might be after some rotation and translation, it might not be exactly +/- 0.5" So the math is just to give some wiggle room, we're looking to see if the y offset of the attachment node is pretty close to .5 or -.5. I just don't understand why this position needs to be close to +/-.5. It looks like if the condition is true it positions the node to the top or bottom, otherwise it's attached to the side. I *think* the intention here is to sort between a node on the top/bottom versus a node on the side of a part. However, I don't know of any procedural parts that have side nodes, nor do I understand why this breaks after 1.7.0. Were nodes changed in 1.7.1? Why is this looking at the y offset of the node, and then adjusting the X and Z offsets by .5? When and why is AddAttachmentNormalized called?

Rightclick somewhere out of the display to close the menu, then open it again. You should find just the last tank set on it. This is not an issue with PP as far as I can tell, it's a graphical glitch with the tank switch module. It updates the menu with the new tank set but doesn't clear off the old one.

Honestly the bug is so prolific that it would take longer to create and upload a craft file than to just type out the replication steps. Launch game in 1.7.1+. Open Sandbox, VAB. Select HECS as root probe. Add procedural liquid tank. Adjust length (diam does not always cause the issue). Exit VAB, save changes. Open VAB. Lift procedural tank off probe core, note the misposition of nodes, and how it will only seem to surface attach now. There may or may not be a visible gap when the craft reloads. Sometimes it seems the node is placed outside of the part's mesh, but most often (at least when following the above) it was shooting the nodes out to the edge of the top/bottom faces. If you have Node Helper installed on your game (https://github.com/linuxgurugamer/NodeHelper) you can look at the nodes and see the reason that you can't connect to them is that they've rotated their orientation as well as shifting to the edge of the part. They point towards the center of the face, so it surface attaches before you can connect to another node.

Yup, this appears to work when resizing. The misplaced node issue on reload is still there in 1.7.2, but again that existed before you did anything. I did notice that it did change the behavior of that issue slightly, however. Previously when you reloaded the craft and the nodes were shifted, both went to the same side of the part. With your latest update they go to opposite ends. Likely nothing, but curious. I should probably also mention that I hadn't purposely replicated the re-root issue that you were attempting to fix. However it does occur to me that this is exactly the cause of the crash I had a few days ago which led me to a complete redesign of some small comms probes I was building. That said I did just test re-rooting to a part surface attached to a procedural tank and can confirm that works correctly as well.

My apologies if this has been mentioned before, but I couldn't find any reference by searching any way I could find to reference this with the existing forum tools. Am I going crazy or is the % key missing from the keycodes list? This key may be referred to as percent, mod, modulus, grapes, or sometimes double-oh-seven, and yes I'm trying to index some search terms here, especially since you cannot search for '%' Oh, someone might refer to it as shift-5 or shift-five. So yeah, am I blind or crazy? I mean, AltGr is there. Raise your hand if you have AltGr on your keyboard. I'm blind, right? Someones going to post a screenshot with the very obvious key highlighted, and I'm gonna feel pretty dumb.

If you're testing in 1.6.1, that may be why you don't see either issue. The Node issue appears in 1.7.1 and 1.7.2, but rarely if ever in 1.7.0 and earlier. I've not personally tested earlier versions, but I've heard mentions that it has come up in previous versions, but 1.7.1 broke it entirely. I listed replication steps in this post above. The issue I reported to you was also tested in 1.7.2, I did not try any earlier versions so it may not appear in 1.6.1. To reiterate, what I'm seeing is if you attach a procedural part - a liquid tank, for instance - to any other part. Then change the dimensions of that part. The part stays physically in the same position, its center of mass relative to its parent part. If you reduce the length, you will see a gap form between it and its parent. If you increase the length, it swallows the parent. This can be fixed if you detach the part and reattach, however the normal and expected behavior is that the part updates and moves its attached points as necessary.

@whale_2 I checked to see if your update would fix the node issue that myself and several others reported. Unfortunately it does not. In my testing I also found an additional bug that your version seems to introduce. If you modify the dimensions of a part, the position of the part remains the same relative to its center point. The nodes do update, if you detach and reattach the part it snaps to the right position. But if you'll need to do this any time you change any of the values. Any chance you could take a poke at this, and perhaps the other node issue? @russ0133 that looks like the same issue the rest of us are experiencing. If you detach that floating tank you will likely find the attachment node is on the edge of the tank rather than in the center, and that it wont connect to anything. The node is actually pointed in the wrong direction. Roll back to 1.7.0 or stop using procedural parts until a fix is posted.

Gotcha. I thought that might be the case, which is why I tagged you in my comment. Thanks for taking the time to reply.