swamp_ig

There's a structural part in the structural tab.

After looking at what K3|Chris was asking - I felt it would be good if you could use NEEDS and BEFORE / AFTER for mods that don't specify much in the way of MM code. To enable that here's release 2.1.4. This will scan the subdirs under GameData, and enable them for NEEDS checking. Edit: To clarify - if you have a mod installed under GameData in a directory called MyMod, then you can use :NEEDS[MyMod] for any config that you want to be dependent on that mod being present.

Get it here Changes: Improvements to heat-shields - proper scaling Compatibility with procedural fairings I've also done some work on RealFuels, have submitted a patch to RFS and am awaiting their release. In the mean time if you'd like to use real fuels, try downloading this patch and installing it over a Real Fuels 5.3. Details of my changes to RF are here

Here's a new version of MM: The only real change since 2.1.2 is that I've dialed-down some of the backups. You'll only get a backup created if there's some major change, mostly only when you delete or add new mods. These times include: A part is deleted that is used in a craft or vessel in flight A part contains a module that has been deleted (module config will be backed up in the part) A new module is added to a part. A module is re-added to a part after being backed up. You won't get backups when: The order of modules changes (this used to result in broken saves) Modules are added to parts using AddModule in the VAB or in flight The upshot: It's now safe to add and remove mods. Most of the time it won't mess up your save games. This is of course best-effort, and mod coders will have to handle having their mods being removed and then added back again later, but it's a lot better than before. If you delete a mod you may end up getting new backups every time you load the game. This will occur if you delete a mod and have a quicksave with vessels that have modified parts in them. If you look in the saves_backup dir, there's subdirs for every backup with date and timestamps, and you can have a look a the logs to see what's going on. The thing to do is that if you delete a mod, go through your existing saves and load them up, and do a quicksave to overwrite the existing quicksave. You can always restore from the backup in the future if you want to.

For the section where you want the mod: MODULE:NEEDS[someMod] { ... } or: key:NEEDS[someMod] = value Similarly for !SomeMod if you want it if the mod isn't there. You'll need 2.1.3.

Ok will have a look (had to get home) Edit: Confirmed this is a problem. Will update PP to latest KSPAPIExtensions...

I think best to show it. No option to turn it off. Really it does no harm, but can potentially cause trouble if it's not there (you don't know when things don't work)

If you install the 3.01 Pfarings plus latest PP, then you shouldn't need to delete any DLLs. In fact if you do it won't work. That was a temporary problem which is now fixed.

Ok... SO PF 3.01 + PP you DON'T need to delete any DLLs. In fact you shouldn't. If you install both out-of-the-box and it still isn't working do let me know.

Ok as of the 3.01 release of proc farings, each mod has its own version of KSPAPIExtensions. Leave them all as they are, no need for deleting anything.

I note that the ^ is currently not used for any function. Can we assign it to FOR THE POWER since that would make sense. It would have the power to do whatever you want! Examples: ^PART[myEngine] { } Takes an engine and makes it a POWER engine. Able to launch megatons to orbit in a single stage. Can push planets to alternate orbits. Change the axial tilt of the Sun! ^JEB {} Takes Jeb and makes him into POWER JEB! Gives him super-powers. Leap the VAB in a single bound, the power to do a interstellar ballistic re-entry to kerbin surface... y'know... power! I can think of myriad other uses for this operator.

I can confirm that there is an issue with KSPAPIAddons. If you delete one of the copies it will work. Problem fixed, but will need an update of the DLL.

If that doesn't do the trick, try this: @PART[*]:HAS[@MODULE[FNModuleResourceExtraction]] { @MODULE[FNModuleResourceExtractor]:HAS[#resourceName[Lithium]] { @extractionRateLandPerTon = 0.0008826 @extractionRateOceanPerTon = 0.0008826 } } Note that the name is in its own bracket.

The other place to look for changelog is on the github releases page

Strictly speaking, the old MM was the one that broke things, or it was a KSP bug that broke things, or something... Being a parser and in quite broad use, it's impossible for me to test every config with the new code, and it does mess around with save games, so I can't absolutely guarantee that this won't cause your five month old multiple-launch space station to either explode obviously, or malfunction in some subtle way that you won't even notice until you try and launch the mission to Jool. Having said that, I have done a fair bit of testing and it seems to work for me. This release is really aimed at fixing things, including any breaking that was done by previous versions of MM. So in answer to your question - use the new version. It should be safe, and future-compatible, and backwards compatible, and even will handle things that KSP just doesn't handle properly. I just don't know for sure that it's not going to break things in some subtle, hard to detect way until people start trying it out, but I really expect this to solve vastly more issues than it ever creates.

Confirmed! Fixed in the post.

There's a changelog here: https://github.com/Swamp-Ig/ProceduralParts/blob/master/ChangeLog.txt I'll link to it in the OP.

Did you actually change the texture at all? or just write a config for it? If so you could just reference the texture, rather than copy it. I can't see why squad would take issue with that.

Can I just say - Awesome!

A primer on how KSP configures itself KSP uses ConfigNodes extensively for all aspects of configuration. The main way in which modders interact with these is in the configuration of parts. There's a fair bit of documentation about this elsewhere, but for the purposes of this document I'll define a few things: // This is a top level node. Note the name with curly brackets afterwards. PART { // This is the name value. It's just a standard name/value pair, but any of these named 'name' // is treated a bit special by MM name = myPart // This is another value. Note name = value . You can't have a name without a value, // but you can have a value without a name (treated as the empty string for name ) module = Part // This is a node named 'MODULE'. It's a collection of further values and modules MODULE { name = ModuleEngines } } // This is a patch. Note the prefix - this will be one of '@' for edit, '+' or '$' for copy, // '-' or '!' for delete, '%' for replace. A patch takes some pre-existing top level node, and modifies it @PART[myPart] { // Edit the value with name 'module' @module = PartEnhanced // Delete all 'MODULE' nodes. -MODULE,* { } } Mod dependency checking You can now put a NEEDS section on any section of your file. This isn't just MM patches, it can be literally anywhere - on values, on nodes, on patches, wherever you like. (this enhanced behaviour is new) An example: PART:NEEDS[RealFuels|ModularFuelSystem] { name = myPartName description:NEEDS[RealFuels] = This part is used in real fuels description:NEEDS[ModularFuelSystem] = This part is used in modular fuel system } So what this means is the part will only be defined if RealFuels OR ModularFuelSystem is present. There's two alternatives for the description field, based on what's present. This is handy if you're a mod developer and you want to create parts that vary a bit depending on what's installed. The stuff within the needs section is based on either: A plugin .dll with the same name (not including dotted extensions) so you'd always get ModuleManager. A FOR[blah] defined would allow NEEDS[blah] The old , listed operator is still supported, and is treated as an alias for & (AND). If you combine several | and &, eg NEEDS[Mod1|Mod2&Mod3|Mod4] this is treated as ( Mod1 OR Mod2 ) AND ( Mod3 OR Mod4 ). I won't be implementing brackets, it would make the parser far too complicated. There's always a way to represent what you want in this form, although it might need a few repeated terms, but I'm not sure I can truly see much of a use case for anything super complex. In the below stuff, I've not put in the NEEDS section for clarity, however you can use it wherever you like. Operators available in patches - and their ordering The general form of a patch for values is: <Op><Name-With-Wildcards>(,<index>)? So breaking this down: <Op> : One of: nothing for insert, '@' for edit, '+' or '$' for copy, '-' or '!' for delete, '%' for replace. <Name-With-Wildcards> : The name of the value you'll be messing with. Wildcards are not always available for every Op. (,<index>)? : Optional index. Again, not available with every option. Not that these indexes are with respect to all name matches not the total index in the node. I will support negative indexes for running backwards through the list soon. Also * is not yet supported. Wildcards include ? for any character, and * for any number of chars. Note that only alphanumeric chars are allowed in value names for patches. If you have spaces or any other char, use a ? to match it. The general form for nodes is: <Op><NodeType>([<NodeNameWithWildcards>])?(:HAS[<has block>])?(,<index-or-*>)? <Op> : Operator, as above <NodeType> : typically MODULE or something like it. Wildcards not allowed (I can't imagine you'd need them) ([<NodeNameWithWildcards>])? : This is a wildcard match for the name = <name> value within the node. Optional. (:HAS[<has block>])? : Optional has block. You can't (currently) use indexes with HAS. This has been described previously. If this is present then all matches will be matched, there's no indexing available currently. (,<index-or-*>)? : Index to select particular match zero based. 0 is the first node, -1 is last node. Values 'off the end' will match the end, so large positive matches the end and large negative matches the beginning. Again this matches against everything the wildcard selects in order. * here will match everything. Insert Insert is the default operator - it's what you get if you don't specify anything. You can now specify the index at which you'd like to insert your bit of config, otherwise it defaults to the end of the list Example: @PART[partName] { node_stack_atend = 0.0, 7.21461, 0.0, 0.0, 1.0, 0.0 node_stack_atstart,0 =0.0, -7.21461, 0.0, 0.0, -1.0, 0.0 MODULE,0 { name = ModuleSomething } } This will add an extra value called node_stack_atend at the end of the list, another value node_stack_atstart at the start, and insert a new module first in the list. Obviously wildcards, * indexes, and other stuff isn't available. Just the value or node name. Edit - @ Edits the node or value in place. The order will not change (new since 2.0.9 ish). For nodes, all options are available to select the node, including indexes, * index, HAS, and wildcards in the name. If there are multiple matches and the index is not supplied, this will default editing all matches. Example @MMTEST[nodeEdit] { // edit by name, will select the first one if multiple nodes with same name @MODULE[module2] { ... } // edit by index - will edit the second module (0 based indexing ) @MODULE,1 { ... } // edit by name and index - will edit the second module with name=module2 @MODULE[module2],1 { ... } // edit by wildcard and index - will edit the sixth module with name ending with 2. If there's no fifth, edit the last one defined @MODULE[*2],5 { ... } // edit by wildcard and index - edit the last module with three letter name starting with c @MODULE[c??],-1 { ... } } For values you additionally have the option of a replacement based on the existing node value, including standard arithmetic operators plus regular expressions for strings. Note: if no index is specified, only the first match will be edited. Once ,* is implemented, then this behaviour should really change to all matches by default, so maybe would be a good idea for patch maintainers to move to using ,0 explicitly. Example: @PART[somePart1] { // Unindexed - edits the first @name = somePart2 // Arithmetic - add 5 and multiply by 20. Unindexed so edits the first one. @numeric += 5 @numeric *= 20 // Regexp expression. Replaces any instance of "tw" with "mo", so would turn "twotwo" into "moomoo" // Note also the index. @multiVal,1 ^= :tw:mo: } For regexp, the first character in the list is used as the separator. You can use whatever you like, but : is often a good choice. Obviously ensure that this isn't present in the regexp expression. Please note I will not support questions about regexps on this thread! I assume if you want to use this feature you're well versed with how regexps work, including the various variants. Please refer to the .net documentaton and/or copious other documentation available on the Internet. Anyhow, here's some useful regexps: ":$: Some Extra Stuff:" $ matches the end of the string, so this is an easy way to add suffixes. ":^: Preamble :" Similar to above. ^ matches the start of a string ":^.*$: Preamble $0 Some extra stuff:" Combining the above. ^.*$ matches the entire input, and $0 will stick it in in the output. Delete - ! or - Delete a node or value. The order of everything afterwards will obviously drop back one step. For nodes, all options are available to select the node, including indexes, * index, HAS, and wildcards in the name. If there are multiple matches and the index is not supplied, this will default to again to all nodes. For values, again all options available. If no index is specified then all matching values are deleted - This differs in behaviour to edit. I will likely change edit to doing this in the future. Example: @PART[nodeDelete] { // Delete the first copy -MODULE[module2] {} // Indexed delete -MODULE,2 { } // Indexed delete from end -MODULE,-2 { } // Indexed delete off end -MODULE,9999 { } @MODULE[module1] { // Unindexed (remove all) -multiVal = dummy // Indexed -multiVal2,0 = dummy // Wildcard -num*ic = dummy } } Note that you still need to use { and } for nodes, and a dummy value for values. If you don't do this then the parser doesn't know what it's dealing with. Copy - + or $ Copy behaves identically to Edit, however rather than editing the node or value it copies it. It will always put the copy at the end of the list. Note that for parts, you must always give a new name or it's a bit pointless: +PART[myPartName] { @name = myNewPartCopy } Replace - % This will edit the value it it exists, otherwise it will create a new value as though this was an insert. For existing nodes this will be identical to edit if the node exists, otherwise it will create an empty node, named as per the node name, and run it through the patch. Obviously because of the insert part, wildcards aren't allowed because the result wouldn't make sense. (although this is not flagged as an error in the current build for nodes) For values this is identical to doing a delete and then an insert. Wildcards and indexes are not supported. The delete will delete all matches. This command has quite limited functionality, but it's there. Test cases / examples I've created some automated test cases for this build, they're here. These also double as good examples of how it works. Later on I'll put up another post targeted really towards modders, so they can get the most out of dynamic module adding and removing, but that will do for now.

Ok, so here's to put some words behind what the 'messing up saves' is all about. The Problem Spaceship parts are built up of multiple modules in KSP. Each module is a unit of functionality - for example an engine has a module to manage thrusting and using fuel, one to manage generation of power, and another to throw off the engine fairing when it's stack attached. The way to add functionality to different parts is to add new modules that do whatever it is you're trying to do - so real fuels for example will add its own engine logic to all engines in the game, and some other engine modifying mod may well do the same. When you load up or save a part, each module gets saved to the save file (that's a .craft for the VAB, and an .sft file for launched ships) in a particular order. This order is expected to remain constant forever by KSP. If you add a module to this list, then not only will that module not reload from the save file, but all the modules after it won't load up correctly either. Not only does it break existing saves, but it breaks them in a way that if you load up the ship, realize you've stuffed up, and then try and reinstall or uninstall the mod you were using, the save is broken permanently and can't be repaired (unless you happened to keep your own backup). Because the whole purpose of MM is to mess with existing parts, any mod that adds its own module through MM will potentially mess up the save games, which isn't ideal. Obviously this is a bug in KSP, and really would ideally get fixed, but we won't get into that . The Fix MM now contains code to stop this problem from happening. What happens is that after you load up KSP, but before it gets a chance to break all your save games, MM runs through all the existing save files and reorders the modules within them to match whatever order they've been set up as in memory (post MM usual editing steps). This will prevent the issue from happening completely, so you can add mods and remove them at any time, safe in the knowledge that you won't be breaking the save games. Whenever it does this, MM will store a backup of the .craft or .sfs file that has been touched, along with a log of what it has done to the part. This is saved in the root of your KSP install, under saves_backup/YYYYMMDD-HHMMSS/ (dates and times as of the time of loading KSP). It's pretty aggressive about creating this backup at the moment, but we may be able to back-off on some of the backing up for changes that just reorder things rather than removing stuff in the future. This backup is also created whenever you have a missing part on a ship. Normally KSP would just destroy the ship and it would be gone forever, so that is handy too. Another feature of this is that if you ever uninstall a mod that adds modules to parts, the save fixer will store the saved state from that module with the part. If you decide you want to reinstall the mod again, the backup of the config will be restored automatically. This is handy if say you're a mod developer and you like to swap real fuels in and out. The other problem Because the old version of MM didn't have this behaviour, it's possible that there might be a bit of weirdness when you first load up your saves. Because there's a huge number of mods out there, we can't possibly test everything. This phase of experimental release is really about seeing what happens. This functionality is really here to stay, and will be an important feature of MM ongoing. Please let me know if you have any issues.

This is indeed implemented, but only for dependencies (NEEDS) You can use either , (comma) or & for and, and | for or. Note that & has lower precedence, so: Mod1|Mod2&Mod3|Mod4 => ( Mod1 OR Mod2) AND ( Mod3 OR Mod4 )

Don't rush out and get 2.1.1 because I've done a fair few improvements and bug fixes for: Release 2.1.2 This has some major new features that you'll never want to be without . I'll post something more detailed up tomorrow after I've slept. I'd appreciate anyone willing to take it for a spin and see how badly it crashes how amazingly well it works. WARNING This version will mess with your save files - that's saved craft and save games. It does take backups of everything that it touches, but you might be well advised to keep your own backup too.

Might need to take that up with the author of that mod Oh... I'd meant to put in an upper limit. In terms of adding weight - the weight of the actual decoupling mechanism is negligible in stock, and really would be too in real life. I agree there should be some trade-off however. Will have a think about it.

If you don't like it you can always edit the config to tweak it to what you would like.