Jognt

Shoo! You’re on vacation! <3

Derp. My bad too. I somehow didn’t manage to do the 1+1 math on that bug! Glad it works now!

Check your difficulty settings menu for HETTN settings. The default settings for that should properly grandparent orphaned nodes, maybe that got changed on your install?

Log files would be appreciated. I don’t play KSP myself at the moment, but logs contain magic.

Probably one of the new stock boosters from 1.8.1.

You’re welcome. And yeah, this sort of patching is nice in that it keeps the value your modifying centralized. So if you were to want to tweak it you wouldn’t need to alter it in n^x locations. And it can be helpful in that the xmitCheck thing on its own can let you know whether you’ve missed a part somewhere if you run it after your usual stuff. The xmitCheck key won’t exist if everything’s in order. edit: Off of the top of my head I don’t know whether your patching took dmagic’s DMModuleScienceAnimateGeneric into account besides his DMScienceModuleAnimate (?), but since ReStock (afaict) adds nifty animation stuff when it’s present (replacing the stock module with it) it may be something to keep in mind when you’re getting into PBC stuff again. ps. Mad respect for the amount of manual labor that went into making your cfgs with all those manual @PARTs!

Continued and Next are two different KJR versions. Next is the one that is actively developed further, trying to improve things. Continued is the “As is, don’t fix what ain’t broken” version. Both have pros and cons, the con of Next being: new bugs. Someone reported the launch clamp thing this week in the Next thread, which is why I suspect it here.

ReStock just changes models. It doesn’t do kraken stuff. Do you have KJR Next installed by any chance? Because I remember reading about that mod krakening launch clamps.

@PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[?rue],#xmitDataScalar[<1]]]:FOR[meOfcourse] I'll assume the @PART and :HAS bit are self explanatory. Here's what each bit does: ~experimentID[ROC*]: This will exclude the new Breaking Ground experiments which are rerunnable, but should be returned for full science because of gameplay. ~experimentID[surfaceSample]: This will exclude surface samples, for the same reason as the above. #rerunnable[?rue]: What do all the experiments you set xmit to 1 for have in common? Well, they were all rerunnable! The ? is to get both True and true values to work. #xmitDataScalar[<1]: This one is just to be tidy, don't touch stuff that's already at the value we want. Here's the old version I had: // Old version @PART[*]:HAS[@MODULE:HAS[#experimentID[*]&#xmitDataScalar[<1]]]:LAST[JogntsTweaks] { @MODULE:HAS[#experimentID[temperatureScan]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } @MODULE:HAS[#experimentID[barometerScan]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } @MODULE:HAS[#experimentID[seismicScan]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } @MODULE:HAS[#experimentID[gravityScan]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } @MODULE:HAS[#experimentID[atmosphereAnalysis]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } @MODULE:HAS[#experimentID[infraredTelescope]] { %xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$ @xmitDataScalar = 1 } } This worked perfectly fine, but it didn't feel very elegant to do it like this since I'm repeating the @xmitDataScalar bit a lot. So I decided to look for something that these all have in common that other experiments don't have. That something was rerunnable = true! Thus, the conditional I posted earlier was born. This way there is very little to no maintenance needed and it'll work with whatever science MODULE people can come up with that still use the existing experimentID key. Is it really needed? Nah. Does it do the same thing as manually setting the xmit value for US2 parts? Yeah. Is manually setting it quicker/easier? Hell no! Sure, figuring out how to do it cost me more time than manually setting it, but now that I've figured it out I don't have to manually set it anymore, ever. If you're curious about the experiments it touches, I've left my debug bit in there, it's the commented xmitCheck thing. If you uncomment that and run KSP once then you can just do a search in Notepad++ (or your program of choice) for xmitCheck and it'll list the old xmit value, the experimentID for that that experiment, and whether it was rerunnable. (rerunnable was there to make sure I wrote the patch correctly back then)

Actually, the FIRST pass is a seperate pass. The legacy no-specifier-pass happens in between FIRST and BEFORE. There's also LAST, which comes just before FINAL. Agreed with the rest. Adding a z to folder/filenames should be a thing of the past. More about patch ordering: https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering Edit: Reading back my "Actually.." I just realized I'm *that guy* right now. My apologies.

Just in case you missed it, I've been using this patch for a while now. It targets the same experiments you do, but I dug into them to find out what properties make them uniquely targetable with a single patch. @PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[?rue],#xmitDataScalar[<1]]]:FOR[JogntsTweaks] { @MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[True],#xmitDataScalar[<1]] { // %xmitCheck = #$xmitDataScalar$ | $experimentID$ | $../name$ @xmitDataScalar = 1 } } Edit: While we're at it, I also added a change when using ReStock Plus: It moves the miniature RCS thrusters one node earlier so you've atleast got something to work with. // Move the ReStock+ miniature RCS thrusters to Flight Control instead of Advanced Flight Control. @PART[restock-rcs*mini*]:NEEDS[ReStockPlus]:FOR[JogntsTweaks] { @TechRequired = flightControl }

Well the log would tell you that both requirements have their passes fulfilled, which would tell you it got defined somewhere, which would tell you to do a quick search for what patch does its thing in the wrongly defined FOR pass, which would point you right where you'd need to look. It's .. ehhh.. somewhere in this thread I think. I learned this the same way as you did, by asking in this thread why my patch wasn't working. Edit: I've edited the Wiki to add a line about using OR in HAS blocks and hope to god I did it properly.

Aren’t the Argon/Xenon thrusters slightly better when using Argon? That pushed me over the edge to go Argon.

You can’t use OR or | in a HAS block. Though it should work but be limited to only the first entry, in this case: Machinery.

Just to make sure: Are you looking for “KER” or “Kerbal Engineer Redux”?

Thank you very much for all the hard work. Have a great vacation!

Well that answers the question of whether you maintain as many relationships as mods.. Though mods do tend to mind less when you have multiple..

Afaik FAR has a MM value you can add to make it use the mesh shape for the voxels, but for more info you’d have to dig through the FAR thread a bit. Searching in the FAR thread for Airplane Plus should net results as most posts I saw were with that mod.

I hate to say it, but after experiencing JNSQ I have to admit that Size Does Matter. I just can’t go back to stock scale!

There were changes made to the stock trait system around the time Breaking Ground was released. I remember MM throwing warnings about it when I played. Whether it’s related to the error in question: no idea.

!Scatterer_atmosphere,*:FOR[reasons] {} Indexed node deletion with a pass specifier. This should work; This is currently unsupported; It's supported, but your syntax is wrong; Well, actually .. [storyMode.Engage]; Any insight would be appreciated. Asking for a friend.

I'm unsure whether you can combine deletion of a node with both an index and a pass specifier so I'll believe you if you say that that doesn't work; There are several Scatterer_atmosphere nodes, so the usage here would be like trying to modify a part by using %PART:FOR. Which indeed won't work. If the first line (deletion) does not work, you can target each node specifically using @Scatterer_atmosphere:HAS[@Atmo:HAS[#name[Duna]]] and you can specify NEEDS[EnvironmentalVisualEnhancements,JNSQ] and FOR[Ad_Astra] unless you have a specific reason to opt for scattererJNSQAVP Same as above. Your scatterer changes were overwritten by JNSQ's because JNSQ also does their Scatterer patching AFTER[Scatterer]. And since J comes after A, your patch was done first, and theirs second. I saw the LAST[Scatterer] usage and agree that it's a functional compromise because AFTER was taken. Doing zAd_Astra without changing the AFTER pass should have worked too though as that already moves your patch later in the pass. So using LAST with Ad_Astra would also work. The zAd_Astra thing still helps with the pass-specifier-less EVE_TEXTURE_CONFIG, EVE_CLOUDS, and EVE_CITY_LIGHTS since those would again be in the same pass as JNSQ but be alphabetically first. Using FOR[Ad_Astra] would move it to later in the patching routine so you could then ditch the z. And I just realized how far I'm willing to go to drop a z from a name.. I'm not a perfectionist, I swear. Okay maybe a bit, but I'm not a perfect one! Some more information on patch ordering and what happens where: https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering -------------- @EVE_CITY_LIGHTS:LAST[JNSQ] { { OBJECT { body = Kerbin cityLightsMaterial { _CityOverlayDetailScale = 50 _CityOverlayTex { value = JNSQ/JNSQ_Textures/EVE/Textures/CityLights } _CityDarkOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/night } _CityLightOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/day } } } } } This is from the Github currently: One set of curly brackets too many (but you knew that one already ) JNSQ adds these in the legacy pass, so there is no need to go for LAST. I'm also wondering why you're not going for the mod name like FOR[Ad_Astra], unless you want to skip the NEEDS bit in which case AFTER[JNSQ] would still be fine. As it is now the EVE_CITY_LIGHTS node is going to have its original content AND the values you stated in it. Either target all values using @ or % or create a new city lights node after removing the old one. Something like this should work: !EVE_CITY_LIGHTS:NEEDS[EnvironmentalVisualEnhancements,JNSQ]:FOR[Ad_Astra] {} EVE_CITY_LIGHTS:NEEDS[EnvironmentalVisualEnhancements,JNSQ]:FOR[Ad_Astra] { OBJECT { body = Kerbin cityLightsMaterial { _CityOverlayDetailScale = 50 _CityOverlayTex { value = JNSQ/JNSQ_Textures/EVE/Textures/CityLights } _CityDarkOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/night } _CityLightOverlayDetailTex { value = JNSQ/JNSQ_Textures/EVE/Textures/day } } } } The same is true for the other EVE files so I would clean those up ASAP. My apologies for not having a clear answer regarding the indexed and timed operations. I don't have a lot of experience with those (yet). I hope this helps!

It's here! It's finally here! OhMyGod christmas came early!

I've been looking through Ad Astra and I found why you had to rename the folder name to make it work: there are no pass specifiers for its patches which mean they run in the legacy pass. This pass happens before the BEFORE/FOR/AFTER/LAST/FINAL passes. JNSQ also has its EVE patches done in this pass which means alphabetically, Ad was first, and JN came second. It should1 be as easy as specifying a pass for your patches like FOR[Ad_Astra]. Then you can drop the z in zAd_Astra. I also noticed some other quirks like deleting existing nodes to replace them with a copy that has one value changed. Is this intentional or a result of how you initially created the configs? Locally I've made some changes that don't alter the end result but tidy up how it's done a bit. I can PR the ones that are relevant depending on the answer to the above. 1- Terms and Conditions apply

The patches run in ReStock’s FOR MM pass so the easier way is to: +PART[whateverPartYouWant]:BEFORE[ReStock] { @name ^= :$:_Copy } !PART[originalPartModifiedByReStock]:AFTER[ReStock] {} @PART[whateverPartYouWant_Copy]:AFTER[ReStock] { @name ^= :_Copy:: } I probably botched the regex as I’m on mobile and thinking aloud, but this + a personal whitelist for the model/texture should keep working despite updates to ReStock and be portable across installs via a personal tweaks folder. In case I missed something obvious though, feel free to correct me. edit: It’s easier for end-users with no MM experience to do incorrectly though. That I do admit, but that risk is there regardless.