Jump to content

Extension for ModuleManager with wildcard and conditional - v0.2 - 24 july 2013


sarbian

Recommended Posts

Does anyone have a cfg file with all stock parts in it and would like to share it?

Planning on building my own tech tree and some other stuff.

Yes, just asking because I am lazy, but asking almost never hurts. :)

What's wrong with the file that Kaa posted just a few posts back?

Actually I should probably ask what you wanted added to the stock parts.... you didn't say precisely.

Link to comment
Share on other sites

Maybe my question was badly worded.

I meant a cfg file for MM with all stock parts listed, so that this lazy player would just have to add/change the tech tree entries for each part.

If someone already has such a file, I would not have to open every part.cfg to note down the names.

Link to comment
Share on other sites

Maybe my question was badly worded.

I meant a cfg file for MM with all stock parts listed, so that this lazy player would just have to add/change the tech tree entries for each part.

If someone already has such a file, I would not have to open every part.cfg to note down the names.

I see. Ok, sorry but not me.

If you have Notepad++ there's a way to do it that will simplify your task. (this assumes Windows. If you're using a Mac or Linux I'm not sure how you'd do it) (also, this will work in Windows 7. Can't vouch for other versions)

First, navigate to the Squad folder in Gamedata.

Second, do a search for part.cfg

Third, in the search results list select all results and open them all in Notepad++ (either by right clicking and selecting from the context menu or because you've previously associated *.cfg with Notepad++)

Fourth, Ctrl+F and search for name =

Make sure that you select the option to search all open documents.

The results will appear below. You can select them all from the results window and copy.

So, you still have to do some work at this but you can automate it quite a bit.

Link to comment
Share on other sites

Bug report time. I've been noticing for awhile that it's possible with MMSarbianExt.dll to apply code to unintended nodes. I've been playing with it on and off trying to isolate under what conditions this is possible and it's pretty easy to do.

When constructing conditionals, the first part of the conditional is ignored.


@FOOBARBAZ[rt*]
{
@MODULE[ModuleGenerator]
{
@OUTPUT_RESOURCE
{
@rate = 69105.0
}
}
}

Is functionally identical to


@PART[rt*]
{
@MODULE[ModuleGenerator]
{
@OUTPUT_RESOURCE
{
@rate = 69105.0
}
}
}

Both will result in the RTG having a power output of 69,105 energy units per second. The other half of this though is that ANYTHING matched on by the conditionals in the bracket will have the specified code applied to it. The following would match on every single node, not just parts but internals, resources, props, doesn't matter.


@FOOBARBAZ[*]
{
// Insert whatever here. Doesn't matter.
}

Poorly constructed conditionals can do this too. The intent in the following is to add MechJeb ONLY to probe cores. However the space after the comma confuses the plugin and it will add MechJeb to EVERYTHING. Fuel tanks, engines, girders, it doesn't matter. It's getting MechJeb added to it. In fact it doesn't even have to be a PART. If it's got a config node it's getting a MechJeb tacked on. (internals, props, you name it)

This isn't even really poorly constructed, it just has a space in it. It SHOULD be able to recover from that.


@PART[*]:HAS[@MODULE[ModuleCommand], #vesselType[Probe]]
{
MODULE
{
name = MechJebCore
}
}

Link to comment
Share on other sites

Sorry for double posting but I also wanted to post a request for an addition to the plugin that I think would be of benefit. I've already tried adding it in and the code is pretty simple and seems to work without unintended side effects.

I've been feeling the need more and more for a conditional that checks for the absence of a given property, the same as we can check for missing modules.

First, the code: (added towards the end of CheckCondition() right before the final 'else' that returns false


else if (conds[0] == '~')
{
if (!(node.HasValue(type)))

return CheckCondition(node, remainCond);
else
return false;
}

This will allow the use of config files that (for example) check for missing 'RequiredTech' properties that are necessary for a part to show up in Career Mode


// This will add any part to career mode that is missing because it has no TechRequired set.
// More creative use of conditionals will allow you to place them in more appropriate spots instead of just dumping them all in one place like I did here.
// The #module[Part] conditional is required to ensure that we're only adding to parts.
@PART[*]:HAS[~TechRequired[],#module[Part]]
{
TechRequired = advRocketry
entryCost = 1000
}

A lot of stock parts are missing breakingForce and breakingTorque properties which makes them more fragile than they should be and these parts will be the first to break when physics goes haywire. Enabling people to check for missing properties will allow the use of the following code to help guard against unnecessary breakage.


@PART[*]:HAS[#module[Part],~breakingForce[]]
{
breakingForce = 1000
}
@PART[*]:HAS[#module[Part],~breakingTorque[]]
{
breakingTorque = 1000
}

Link to comment
Share on other sites

Is it possible to edit to a part that has any resource, but not if the only resource is the one specified? For instance, I want to add a PartModule to any part that has resources unless the only resource is ElectricCharge.

Edited by regex
Link to comment
Share on other sites

Is it possible to edit to a part that has any resource, but not if the only resource is the one specified? For instance, I want to add a PartModule to any part that has resources unless the only resource is ElectricCharge.

Hmmmm. Try this:


@PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]]
{
// Your stuff here.
}

No spaces at all in the first line, exactly as I have it. Unless the no-space thing also got fixed in Sarbian's update this morning...? in any case you should grab that update.

Link to comment
Share on other sites

Hmmmm. Try this:


@PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]]
{
// Your stuff here.
}

I thought it might be something along those lines. I had the !RESOURCE after the RESOURCE[*] and thought that might end up parsing as "Any part with a resource unless there is ElectricCharge".

Thanks, I'll give that a try.

Link to comment
Share on other sites

I thought it might be something along those lines. I had the !RESOURCE after the RESOURCE[*] and thought that might end up parsing as "Any part with a resource unless there is ElectricCharge".

Thanks, I'll give that a try.

I don't think the actual order matters... not when you have them separated by commas like that, it only cares that all conditions are true. There is another way where instead of separated they use nested :HAS[] constructs so that you can check if specific nodes contain other nodes or properties. One thing you can't do though is target individual nodes in the the PART node. Like if there are multiple ModuleAnimationGeneric modules, you can't target a specific one. That's as much a limitation of ModuleManager itself, or maybe even stock KSP.

Link to comment
Share on other sites

I don't think the actual order matters... not when you have them separated by commas like that, it only cares that all conditions are true. There is another way where instead of separated they use nested :HAS[] constructs so that you can check if specific nodes contain other nodes or properties. One thing you can't do though is target individual nodes in the the PART node. Like if there are multiple ModuleAnimationGeneric modules, you can't target a specific one. That's as much a limitation of ModuleManager itself, or maybe even stock KSP.

It's not a big deal now that I think about it, I can always have the PartModule self-unload if the only resource available is ElectricCharge. The important thing is that this extension just saved me a ton of programming time. All I have to do now is write PartModules; it's genious.

Link to comment
Share on other sites

It's not a big deal now that I think about it, I can always have the PartModule self-unload if the only resource available is ElectricCharge. The important thing is that this extension just saved me a ton of programming time. All I have to do now is write PartModules; it's genious.

Has it? I just gave those conditionals a try just as I showed you but they don't seem to be working after all. I think Sarbian's praise might have been premature. :(

Though it really seems like it should work... just in case I tried reversing the order but no dice. Have you gotten it to work?

Link to comment
Share on other sites

Though it really seems like it should work... just in case I tried reversing the order but no dice. Have you gotten it to work?

I'm at work right now and when I get home there's a child to tend to, so it's going to be a good seven~eight hours before I can test stuff. :) I'm just asking questions and day-dreaming.

Link to comment
Share on other sites

I'm at work right now and when I get home there's a child to tend to, so it's going to be a good seven~eight hours before I can test stuff. :) I'm just asking questions and day-dreaming.

Well fortunately for you, I'm like a Rottweiler or a Pitbull when it comes to bugs, even if they aren't my own. Sarbian's initial instincts were correct, he would have been right to say it wouldn't work. I had another look at the code and wildcard matching only happens once for the initial node (@PART[*]) (which is just intended behavior, not a bug :()

Technically it could be done for each of the conditions that appears after, but that might be detrimental to start-up times. Or it might not make much difference at all; wildcard matching does use Regex (ha ha) which is pretty fast.

Edited by Starwaster
Link to comment
Share on other sites

What a dev I am, I don't even know how my code works :P

I could do that, I can see the use now and I doubt it would slow thing much. All MM + MM Ext code run even before KSP display anything.

Link to comment
Share on other sites

What a dev I am, I don't even know how my code works :P

I could do that, I can see the use now and I doubt it would slow thing much. All MM + MM Ext code run even before KSP display anything.

Wildcard matching all the way down would definitely be cool!

Link to comment
Share on other sites

I added it to MM 1.4.1. I am not sure I all add it to MMExt since it require copying most of MM code in MMExt ...

Edit : No, It was not that hard with some coffee. uploaded a newer version with more wildcard search.

Edited by sarbian
Link to comment
Share on other sites

Sarbian, your module manager conflicts with RemoteTech2, found this out last night, was a bit of a headache. I love your MM because it let engineering redux for all pods work.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...