[A17] Miniaturisation Overloaded

[notfood]

I made a big change underneath. CCL requirement is no more. Moving the injection earlier seems to solve the reported issues. Turrets are minified without errors, they shoot after built and minified coolers have a texture. I'd like some feedback. This release adds the contributed files, thanks everyone for their support and contributions.

Release 0.14.2.0

[biship]

I've moved about 50 things so far with 0.14.2.0 and it all seems to work fine.
EDIT: Except for ReDistHeat

[123nick]

T_ExpandedCrops is missing its .xml ending

i was the one who made file and the pull request for it, guess i must've forgotten to add it

[Nerve]

Can you make insect hives moveable? 

[notfood]

BETA

Please test this branch, just donwload as zip. It reduces Miniaturisation footprint to almost nothing. Instead of creating the minified it queues a request for such in behalf of the target. The injection has been moved even earlier where load order matters. So, load after the mods you want to miniaturise. It's also not compatible with old Miniaturisation, old saves beware.

[notfood]

Can you make insect hives moveable?

It doesn't seem possible... I tried and while you can install them, the icon to move them doesn't appear because they aren't of your own faction.

Well, it allows you to move the glow pods.

[notfood]

Perhaps you are interested in this.

Mod Friendly Overrides
^{you dug too deep}

The natural progression of Miniaturisation, this mod allows you to override any field in any def in any mod, in a friendly way. That means the posibility of a mod friendly Combat Realism or the like.

Stand alone it has no objetive on its own as Miniaturisation, this is mostly for modders that want compatibility. I encourage you to make changes to the included Override.Def and cause it to break so I can fix the issues as you report them.

It may be ready for production but I want to test it further, so the attached below is not for any serious play. I warned you.

Download Beta 7

Example OverrideDef.xml

Source is attached for the curious, it's the result of many days of research and several failures. Miniaturisation benefited a lot from it.

[Elysium]

Perhaps you are interested in this.

o_O This looks like an extremely useful utility if it is doing what I think it is doing.  This allows overriding existing data and even adding new data to defs without completely overwriting the def?!

[notfood]

Yes! Saves you from copying the defs. Just alter what you want to alter and stay mod friendly.

[Elysium]

Wow, great job! The potential impact this could have on the entire modding community is pretty substantial if everyone starts to adopt this method.

[notfood]

You would only require the mod as dependency and you write your own Override.Def in xml. No need to implement anything in code.

[Master Bucketsmith]

So MFO could be used to make personalised alterations to other mods?
E.G. I want EPOE, but I want to get rid of vancidium and make it use plasteel instead, without having to copy over the entire mod?
I would only need to write a little bit of code?

[Elysium]

So MFO could be used to make personalised alterations to other mods?
E.G. I want EPOE, but I want to get rid of vancidium and make it use plasteel instead, without having to copy over the entire mod?
I would only need to write a little bit of code?

Not only would you not need to copy the entire mod, but you would only need to alter the section of the recipedef that requires vancidium.  Here is an example ( do note that I have not tested this it is just an example )

Code Select Expand

    <Override.Def Target="MakeAdvancedComponent">
    <ingredients>
      <li>
        <filter>
          <thingDefs>
            <li>Plasteel</li>
          </thingDefs>
        </filter>
        <count>5</count>
      </li>
      <li>
        <filter>
          <thingDefs>
            <li>Component</li>
          </thingDefs>
        </filter>
        <count>1</count>
      </li>
    </ingredients>
    <fixedIngredientFilter>
      <thingDefs>
        <li>Component</li>
        <li>Plasteel</li>
      </thingDefs>
    </fixedIngredientFilter>
    </Override.Def>

Instead of doing:

Code Select Expand

  <RecipeDef>
    <defName>MakeAdvancedComponent</defName>
    <label>make advanced component</label>
    <description>Make an advanced component.</description>
    <jobString>Making advanced component.</jobString>
    <workSpeedStat>SmithingSpeed</workSpeedStat>
    <effectWorking>Cook</effectWorking>
    <soundWorking>Recipe_Machining</soundWorking>
    <workAmount>10000</workAmount>
      <recipeUsers>
         <li>ComponentAssemblyBench</li>
      </recipeUsers>
    <ingredients>
      <li>
        <filter>
          <thingDefs>
            <li>Plasteel</li>
          </thingDefs>
        </filter>
        <count>5</count>
      </li>
      <li>
        <filter>
          <thingDefs>
            <li>Component</li>
          </thingDefs>
        </filter>
        <count>1</count>
      </li>
    </ingredients>
    <fixedIngredientFilter>
      <thingDefs>
        <li>Component</li>
        <li>Plasteel</li>
      </thingDefs>
    </fixedIngredientFilter>
    <products>
      <AdvancedComponents>1</AdvancedComponents>
    </products>
<skillRequirements>
<li>
<skill>Crafting</skill>
<minLevel>10</minLevel>
</li>
</skillRequirements>
    <workSkill>Crafting</workSkill>
    <researchPrerequisite>VancidiumRefineryTech</researchPrerequisite>
  </RecipeDef>

I don't even know if everything there is required, its possible you may even be able to slim it down more, which actually leads me to a couple questions I have for notsure.  In the above example, I assume the count has to be included as it is a subset of <ingredients> correct? 

Also, in the example below, assume that two different mods target the same properties but both are using your mod.  One would have to assume these overrides would not be in the same override.xml

Code Select Expand

    <Override.Def Target="Bed">
    <comps>
      <li Class="CompProperties_AffectedByFacilities">
        <linkableFacilities>
          <li>VitalsMonitor</li>
          <li>Dresser</li>
          <li>EndTable</li>
          <li>EndTableLight</li>
        </linkableFacilities>
      </li>
    </comps>
    </Override.Def>

Code Select Expand

    <Override.Def Target="Bed">
    <comps>
      <li Class="CompProperties_AffectedByFacilities">
        <linkableFacilities>
          <li>VitalsMonitor</li>
          <li>NightLight</li>
        </linkableFacilities>
      </li>
    </comps>
    </Override.Def>

What would happen in this scenario?  Would the end result be VitalsMonitor, Dresser, EndTable, EndTableLight, NightLight all injected into the comps?  If so, is VitalsMonitor even required since it is already defined in the def?  I have to assume it is overwriting the properties in question, and if that is the case I don't think my above example would work unless all of the comps were defined in the same override.

[notfood]

It inserts into the lists if they exist. Only for the lists. In case of the ingredients, you want a replacement. I'll add a keyword to discard any prior set object before trying to insert.

I'm thinking in <fieldname replace>blahblah</fieldname>

[Elysium]

It inserts into the lists if they exist. Only for the lists. In case of the ingredients, you want a replacement. I'll add a keyword to discard any prior set object before trying to insert.

I'm thinking in <fieldname replace>blahblah</fieldname>

So just to be clear here, in the example with the bed, the vitalsmonitor would not be required since it is already added by core, and the two different mods would not overwrite eachothers comps because they were added and not overwritten?