zer0Kerbal Posted July 2, 2019 Share Posted July 2, 2019 (edited) 7 hours ago, Starwaster said: As he said, it allows subdirectories. Most parts if the mod's folders are structured sensibly will have the part in its own properly named folder. So target that folder. Obviously that won't work for mods which force their parts to live all in one folder or groups masses of them into one folder. Normally this (:NEEDS[KAS/Legacy]) would work, except that every update will scrub the directory and am expecting most (like me) to just move the directory somewhere, and probably rename it. So the answer is either :NEEDS[@PART[]) or as I remembered :NEEDS[@MODULE[KASModuleWinch,!KASLinkWinch]] (think that is correct syntax) since KAS changed it's module names for 1.2, then that is a great indicator / method of solving my dilemma elegantly. And with KIS2.0 coming sooner (maybe) rather than later (Breaking Ground seems to have put pressure on @IgorZ) - can expect that this method should also work then for that as well. Quote "ad hoc, ergo promptus hoc." — Bill "okay, whatever that means, whack it again with a hammer, a bigger one this time!" — Jeb Edited July 2, 2019 by zer0Kerbal Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 3, 2019 Share Posted July 3, 2019 4 hours ago, zer0Kerbal said: expecting most (like me) to just move the directory somewhere, and probably rename it. Maybe this is an exception, but many mods will break if you move things around or rename them. Specifically, any parts using MODEL {} will fail to compile. Quote Link to comment Share on other sites More sharing options...
Starwaster Posted July 3, 2019 Share Posted July 3, 2019 Not sure that makes sense... if you are expected to move mod folders around then something is very wrong. You're not going to like this solution but too bad On the tug part you want to do this to: MODULE { name = KASLinkWinch } IT WILL WORK Where by 'work' I mean if the proper version is installed then the you'll have KASLinkWinch installed. If the proper version isn't installed then KSP will silently complain in the log and it will move on without the module. It's about as elegant as Alpo and Velveeta for dinner but it will get the job done. Quote Link to comment Share on other sites More sharing options...
KerbMav Posted July 12, 2019 Share Posted July 12, 2019 Did stuff change? My old tweaks - months, 1y+ old - stopped working (partially). Swapping "biome sensitivity" of EVA and Crew Report does not work anymore. Spoiler // situation bits: // SrfLanded = 1, // SrfSplashed = 2, // FlyingLow = 4, // FlyingHigh = 8, // InSpaceLow = 16, // InSpaceHigh = 32 @EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]] { @baseValue = 8 @scienceCap = 8 @dataScale = 1 @situationMask = 63 @biomeMask = 31 } @EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]] { @baseValue = 5 @scienceCap = 5 @dataScale = 1 @situationMask = 63 @biomeMask = 3 } Changing SAS availability of probe cores to "grow" with TechTree progression - does not work completely. The "Software Update" appears in the TechTree, but does not change even new crafts, not even the text in the VAB. Silly enough, it works in a Sandbox game, but not career. Spoiler @PART[probeCoreSphere]:BEFORE[SASupgrade] { MODULE { name = ModuleSAS } } @PART[*]:HAS[@MODULE[ModuleSAS]]:FOR[SASupgrade] { @MODULE[ModuleSAS] { %SASServiceLevel = 0 %moduleIsEnabled = false %showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = SASupgradeLvl0 description__ = SAS Vers. 1.0 ExclusiveWith__ = SASb //IsAdditiveUpgrade__ = false moduleIsEnabled = true SASServiceLevel = 0 } UPGRADE { name__ = SASupgradeLvl1 description__ = SAS Vers. 1.1 ExclusiveWith__ = SASb //IsAdditiveUpgrade__ = false moduleIsEnabled = true SASServiceLevel = 1 } UPGRADE { name__ = SASupgradeLvl2 description__ = SAS Vers. 1.2 ExclusiveWith__ = SASb //IsAdditiveUpgrade__ = false moduleIsEnabled = true SASServiceLevel = 2 } UPGRADE { name__ = SASupgradeLvl3 description__ = SAS Vers. 1.3 ExclusiveWith__ = SASb //IsAdditiveUpgrade__ = false moduleIsEnabled = true SASServiceLevel = 3 } } } } Spoiler PARTUPGRADE { name = SASupgradeLvl0 partIcon = probeCoreSphere techRequired = electrics entryCost = 1000 cost = 0 title = SAS Software 1.0 description = Installs SAS software Version 1.0 } PARTUPGRADE { name = SASupgradeLvl1 partIcon = probeCoreSphere techRequired = precisionEngineering entryCost = 5000 cost = 0 title = SAS Software Upgrade 1.1 description = Updates SAS software to Version 1.1 } PARTUPGRADE { name = SASupgradeLvl2 partIcon = probeCoreSphere techRequired = unmannedTech entryCost = 10000 cost = 0 title = SAS Software Upgrade 1.2 description = Updates SAS software to Version 1.2 } PARTUPGRADE { name = SASupgradeLvl3 partIcon = probeCoreSphere techRequired = advUnmanned entryCost = 15000 cost = 0 title = SAS Software Upgrade 1.3 description = Updates SAS software to Version 1.3 } Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 12, 2019 Share Posted July 12, 2019 (edited) 50 minutes ago, KerbMav said: Did stuff change? My old tweaks - months, 1y+ old - stopped working (partially). Swapping "biome sensitivity" of EVA and Crew Report does not work anymore. Reveal hidden contents // situation bits: // SrfLanded = 1, // SrfSplashed = 2, // FlyingLow = 4, // FlyingHigh = 8, // InSpaceLow = 16, // InSpaceHigh = 32 @EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]] { @baseValue = 8 @scienceCap = 8 @dataScale = 1 @situationMask = 63 @biomeMask = 31 } @EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]] { @baseValue = 5 @scienceCap = 5 @dataScale = 1 @situationMask = 63 @biomeMask = 3 } There was a change, but it happened quite a while ago (maybe more than a year at this point?). EXPERIMENT_DEFINITION nodes don't have a name value, so @EXPERIMENT_DEFINITION[*] no longer works (you want @EXPERIMENT_DEFINITION:HAS[#id[crewReport]]) Less sure about the 2nd part, I don't think that has anything to do with ModuleManager though. Edited July 12, 2019 by blowfish Quote Link to comment Share on other sites More sharing options...
KerbMav Posted July 12, 2019 Share Posted July 12, 2019 5 minutes ago, blowfish said: There was a change, but it happened quite a while ago (maybe more than a year at this point?). EXPERIMENT_DEFINITION nodes don't have a name value, so @EXPERIMENT_DEFINITION[*] no longer works (you want @EXPERIMENT_DEFINITION:HAS[#id[crewReport]]) Less sure about the 2nd part, I don't think that has anything to do with ModuleManager though. Ah, thanks, will try that. Would it be something similar here? Spoiler @PART[*]:HAS[@MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]] { @MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]] { @xmitDataScalar = 1.0 } } Quote Link to comment Share on other sites More sharing options...
Superfluous J Posted July 12, 2019 Share Posted July 12, 2019 I've poked around through the documentation and many configs and have never seen this, so maybe it's just not possible. but in case I just didn't see it and it IS possible... Is there a way to reference another part's data when changing a part? Let's say, as a random example, I want to set the mass of partA to equal the mass of partB. I don't want to have to re-check partB every KSP update, so I'd like to do something like: @PART[partA] { @mass = PART[partB].mass } Is something like that possible? Quote Link to comment Share on other sites More sharing options...
4x4cheesecake Posted July 12, 2019 Share Posted July 12, 2019 7 minutes ago, 5thHorseman said: Is something like that possible? Yep, by using a variable: //This would return 'RE-M3 "Mainsail" Liquid Engine': @title = #$@PART[liquidEngine1-2]/title$ Take a look here or here for more details Quote Link to comment Share on other sites More sharing options...
Superfluous J Posted July 12, 2019 Share Posted July 12, 2019 8 minutes ago, 4x4cheesecake said: Yep, by using a variable: //This would return 'RE-M3 "Mainsail" Liquid Engine': @title = #$@PART[liquidEngine1-2]/title$ Take a look here or here for more details I'm surprised how close my pseudocode was to the truth . That's rare for me! Thanks! Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 12, 2019 Share Posted July 12, 2019 1 hour ago, KerbMav said: Ah, thanks, will try that. Would it be something similar here? Hide contents @PART[*]:HAS[@MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]]] { @MODULE[*]:HAS[#experimentID[atmosphereAnalysis]|#experimentID[temperatureScan]|#experimentID[gravityScan]|#experimentID[barometerScan]|#experimentID[seismicScan]|#experimentID[scopeScan]] { @xmitDataScalar = 1.0 } } | doesn't work in a HAS block, unfortunately you need a separate patch for each Quote Link to comment Share on other sites More sharing options...
KerbMav Posted July 13, 2019 Share Posted July 13, 2019 8 hours ago, blowfish said: | doesn't work in a HAS block, unfortunately you need a separate patch for each Curious ... it must have worked at some point, because I had to dig deep into my backups before I found a version that handled each experiment seperately. And regarding my other problem - Squad updated the Stayputnik, but kept the older version - so the name of the part changed ... So, catch all version in first line: Spoiler @PART[probeCoreSphere*]:BEFORE[SASupgrade] The localization stuff leads to silly entries in the TechTree (AUTOLOC***), but that doesnt bother me as much. ^^ Thanks again! Quote Link to comment Share on other sites More sharing options...
Starwaster Posted July 14, 2019 Share Posted July 14, 2019 20 hours ago, KerbMav said: Curious ... it must have worked at some point, because I had to dig deep into my backups before I found a version that handled each experiment seperately. It's pretty bizarre considering commas work in HAS blocks as a logical AND You're probably right and it probably did work in the past which means its failure to work now is another regression. Just as it used to be possible to add a field to a node, test for that field in a node and then delete that field from the node in the same patch section as it had been tested for. (now MM gets confused because it no longer knows what order to execute the commands in) Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 14, 2019 Share Posted July 14, 2019 12 hours ago, Starwaster said: It's pretty bizarre considering commas work in HAS blocks as a logical ANDYou're probably right and it probably did work in the past which means its failure to work now is another regression. This never worked to my knowledge. It was not implemented. In fact, you can go look at old versions of the code and confirm that. 12 hours ago, Starwaster said: Just as it used to be possible to add a field to a node, test for that field in a node and then delete that field from the node in the same patch section as it had been tested for. (now MM gets confused because it no longer knows what order to execute the commands in) Could you be more specific? Maybe an example? Quote Link to comment Share on other sites More sharing options...
Nightside Posted July 14, 2019 Share Posted July 14, 2019 I want to prefix the TITLE of fuel tanks with the bulkhead profile, but my script isn't working. Input: @PART[*]:HAS[#category[FuelTank]]:FINAL { @title ^= :^:#$bulkheadProfiles$: } Desired result: title = size0 PB-X150 Xenon Container Ingame/Config Cache: title = #$bulkheadProfiles$PB-X150 Xenon Container Quote Link to comment Share on other sites More sharing options...
Starwaster Posted July 14, 2019 Share Posted July 14, 2019 4 hours ago, blowfish said: This never worked to my knowledge. It was not implemented. In fact, you can go look at old versions of the code and confirm that. Could you be more specific? Maybe an example? I don't need to look at the code to know that it worked for Module Manager 2.0.8. What I can't tell you is when it stopped working. But yes, using | in HAS blocks was a thing once upon a time. As for the latter, Deadly Reentry looks for a flag 'leaveTemp' in the body of all part configs. More properly that flag belongs in ModuleAeroReentry but we look for it in the part itself to make it easier for other modders to opt out. What USED to happen was that in the same patch that we looked for the flag in we would add ModuleAeroReentry with the flag and its associated value (leaveTemp = #$/leaveTemp$) inserted and then the flag would be deleted. That worked up until a few years ago when it stopped after MM updated. I reported it here and was told that there was just no way for Module Manager to know that the flag was being read before its value inserted into the module and I left it at that as it was just easier to leave it in there. (worst that happens is the part compiler complains about an unknown field). But it did used to work. @PART[*]:HAS[#leaveTemp[*],@MODULE[ModuleAeroReentry]]:FINAL { @MODULE[ModuleAeroReentry] { %leaveTemp = #$../leaveTemp$ } !leaveTemp } @PART[*]:HAS[#leaveTemp[*],!MODULE[ModuleAeroReentry]]:FINAL { MODULE { name = ModuleAeroReentry leaveTemp = #$../leaveTemp$ } !leaveTemp } 3 hours ago, Nightside said: I want to prefix the TITLE of fuel tanks with the bulkhead profile, but my script isn't working. Input: @PART[*]:HAS[#category[FuelTank]]:FINAL { @title ^= :^:#$bulkheadProfiles$: } Desired result: title = size0 PB-X150 Xenon Container Ingame/Config Cache: title = #$bulkheadProfiles$PB-X150 Xenon Container Try removing the : at the end of title @title ^= :^:#$bulkheadProfiles$ Also though, the way you have it there there won't be a space between bulkhead profiles and the rest of the title. Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 15, 2019 Share Posted July 15, 2019 4 hours ago, Starwaster said: I don't need to look at the code to know that it worked for Module Manager 2.0.8. What I can't tell you is when it stopped working. But yes, using | in HAS blocks was a thing once upon a time. 2.0.8 is ancient history, like pre-Sarbian ancient history. I checked the code around then and I don't see it looking for | in HAS blocks, but maybe if you say so? That was probably before I was even playing KSP. 5 hours ago, Starwaster said: @PART[*]:HAS[#leaveTemp[*],@MODULE[ModuleAeroReentry]]:FINAL { @MODULE[ModuleAeroReentry] { %leaveTemp = #$../leaveTemp$ } !leaveTemp } The problem here is that when KSP parses nodes, it puts all the nodes in one list and all the values in another list. So ModuleManager has no way of knowing which came first originally. I'm not sure how this could have worked before, and a few years sounds before my time working on ModuleManager, but if you narrow it down to a version update I might be able to look at the code and see. Also it would have to be !leaveTemp = DEL (or some other value that doesn't matter), otherwise KSP doesn't parse it as a value 8 hours ago, Nightside said: @title ^= :^:#$bulkheadProfiles$: Close... @title ^= :^:#$bulkheadProfiles$: As starwaster mentioned you probably want a space before the final : Quote Link to comment Share on other sites More sharing options...
Starwaster Posted July 15, 2019 Share Posted July 15, 2019 (edited) 44 minutes ago, blowfish said: Also it would have to be !leaveTemp = DEL (or some other value that doesn't matter), otherwise KSP doesn't parse it as a value That's because that was the older code (which, yes, !leaveTemp actually worked too, once upon a time) Quote I'm not sure how this could have worked before, and a few years sounds before my time working on ModuleManager, but if you narrow it down to a version update I might be able to look at the code and see. Conditionals are (or were) generic. Anywhere that was doing logic checks the same syntax worked for them all. I have no idea what's happened with the code since then but yes, that worked. Edited July 15, 2019 by Starwaster Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 15, 2019 Share Posted July 15, 2019 56 minutes ago, Starwaster said: That's because that was the older code (which, yes, !leaveTemp actually worked too, once upon a time) I wonder if this was actually a change in KSP's ConfigNode parser... 57 minutes ago, Starwaster said: Conditionals are (or were) generic. Anywhere that was doing logic checks the same syntax worked for them all. I have no idea what's happened with the code since then but yes, that worked. Still very curious how this would have worked. ModuleManager wouldn't have had any way to know to process the node before the value, then or now. Quote Link to comment Share on other sites More sharing options...
Gurki Posted July 17, 2019 Share Posted July 17, 2019 Have you something in the pipe regarding patch that will apply twice when parts are define twice ? kerbalEVA is what I have in mind with Serenity DLC. I didn't see anything related into github issue Quote Link to comment Share on other sites More sharing options...
Starwaster Posted July 17, 2019 Share Posted July 17, 2019 3 minutes ago, Gurki said: Have you something in the pipe regarding patch that will apply twice when parts are define twice ? kerbalEVA is what I have in mind with Serenity DLC. I didn't see anything related into github issue You don't need special handling for that from Module Manager. Serenity defining a part named KerbalEVA is just so they can add the ROC science module to the standard KerbalEVA suit. Remember that stock doesn't use Module Manager so they just define a part that has the same name and the end result is that the new Serenity science module gets added to the KerbalEVA part whenever it gets spawned. I'm not clear on the specific internal workings but that's basically what happens. They also do the same with KerbalEVAVintage So, you yourself don't need to target all parts named KerbalEVA or all parts named KerbalEVAFemale. Just target one of each. In fact if you did try to patch all parts named KerbalEVA it might end up in duplication of whatever you're trying to do. Depends really on what you are trying to do. (in fact I think Deadly Reentry might be doing something like that so I better go make sure it isnt...) In fact just do this: @PART[*]:HAS[@MODULE[KerbalEVA]] { } Quote Link to comment Share on other sites More sharing options...
Gurki Posted July 17, 2019 Share Posted July 17, 2019 (edited) That was more or less something that I did to remove duplicated module added by Kerbalism on kerbalEVA from my setup. Obviously KSP merge parts defined multiple time after MM. I was wondering if doing that merge in MM as some kind of pre-process, applying patches and returning to KSP something that has no duplicated definition is possible. It will avoid accidental duplicates for any parts, but I'm not sure if it worth the effort of implementing it ... Edited July 17, 2019 by Gurki Quote Link to comment Share on other sites More sharing options...
Lisias Posted July 19, 2019 Share Posted July 19, 2019 (edited) On 7/17/2019 at 6:04 PM, Gurki said: I was wondering if doing that merge in MM as some kind of pre-process, applying patches and returning to KSP something that has no duplicated definition is possible. That would need more knowledge than MM has (and need to have). Sometimes such duplication is wanted (as an array of sections), sometimes it's not. We would need to tell MM about it. I have a similar problem on some Sanity Checks for an Add'On of mine. Sometimes a datum can be zero, some other it can not (or KSP capsizes) - so there's no generic rule that can be applied, you need to specialize for each datum. And this can vary module by module. So it appears to me that this task need to be performed by the modules themselves. Edited July 20, 2019 by Lisias Bad grammars. =P Quote Link to comment Share on other sites More sharing options...
Tonas1997 Posted July 21, 2019 Share Posted July 21, 2019 I've recently upgraded to 1.6 from 1.3, and noticed there were some major changes in-between. From what I understand, MM now applies patches "in parallel" as the parts are loaded. So I guess it goes like this: MM for 1.3.1: Load parts (one run through the GameData folder) -----> apply patches -----> Post-patch callbacks (or whatever it is called; another run through GameData) MM for 1.6.1: Load parts/apply patches (one run through the GameData folder) -----> Post-patch callbacks (another run) If I keep a validated cache between KSP startups, will MM do both "loading" runs all the same? I'm asking because, in older versions, reading from the cache significantly decreased load times since it removed one step from the loading process whereas, in the current version, it will be limited by whichever operation concludes last (part loading or patch applying). I'm still assembling a modpack with multiple installs/uninstalls/config changes between play sessions, so I haven't been able to test it yet. TL;DR: will a valid cache allow for MM to jump straight to post-patch callbacks, therefore only running through my modlist once? Or did I get the workings of MM completely wrong? Quote Link to comment Share on other sites More sharing options...
blowfish Posted July 21, 2019 Share Posted July 21, 2019 59 minutes ago, Tonas1997 said: I've recently upgraded to 1.6 from 1.3, and noticed there were some major changes in-between. From what I understand, MM now applies patches "in parallel" as the parts are loaded. So I guess it goes like this: MM for 1.3.1: Load parts (one run through the GameData folder) -----> apply patches -----> Post-patch callbacks (or whatever it is called; another run through GameData) MM for 1.6.1: Load parts/apply patches (one run through the GameData folder) -----> Post-patch callbacks (another run) If I keep a validated cache between KSP startups, will MM do both "loading" runs all the same? I'm asking because, in older versions, reading from the cache significantly decreased load times since it removed one step from the loading process whereas, in the current version, it will be limited by whichever operation concludes last (part loading or patch applying). I'm still assembling a modpack with multiple installs/uninstalls/config changes between play sessions, so I haven't been able to test it yet. TL;DR: will a valid cache allow for MM to jump straight to post-patch callbacks, therefore only running through my modlist once? Or did I get the workings of MM completely wrong? Here was the previous sequence of events KSP loads plugins -> KSP loads textures -> KSP loads models -> ModuleManager applies patches -> ModuleManager runs post patch callbacks -> KSP compiles parts Here is the new sequence -> KSP loads textures -> KSP loads models -> KSP loads plugins -> -> ModuleManager runs post patch callbacks -> KSP compiles parts -> ModuleManager applies patches ----------> There shouldn't be any effect as 99% of mods are concerned. Also note that applying patches is still done one by one, it's just done in the background while KSP is doing unrelated stuff. There shouldn't be any effect as far as the cache is concerned (and changing ModuleManager versions invalidates the cache anyway) Quote Link to comment Share on other sites More sharing options...
Tonas1997 Posted July 23, 2019 Share Posted July 23, 2019 Another question: how do I make it so that this patch @PART[*]:HAS[@MODULE[ModuleEngineConfigs]:HAS[#type[ModuleRCS*]],!MODULE[ModuleRCS*]]:AFTER[RO-RCS] is applied to all BUT parts named xxx and yyy (for instance)? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.