Messages

Code Select Expand


XML error: Could not find parent node named "MonsterMash_ADSP_SurgeryFleshAnimal" for node "RecipeDef". Full node: <RecipeDef ParentName="MonsterMash_ADSP_SurgeryFleshAnimal" Abstract="True"><defName>MonsterMash_ADSP_InstallBionicAnimalGill</defName>
but I hope you already dealt with it

And those 2 mysterious errors revealing with <success>Normal</success> are still there. It's not good but I don't know what else can be done with them now.

About prefixes: it'll matter only in the case that some other mod will use the same names so their contents will depend on the loading order. It may be both for good (there won't be, for example, several different tentacles that could confuse player which one is for which creature) and for bad (overwritten stats could lead to issues). I think the bad consequences in such situations are more probable and would be harder to fix, while dealing with several similar items won't be hard by patching after revealing this issue. So I'd say the prefixes are more good than bad, though are not really required. But at least I'd suggest you to change existing "MonsterMash_" to "MM_" And if you'll decide to use them you'd better to do it earlier than later so it won't take the extra efforts in the future.

Regarding the guide:
1. It'd be good to add an introduction describing what's the point of all this and why working with "dynamically/conditionally created defs" by XML-only means is not trivial.
2. Mention that this method requires using ModCheck (however I think in most cases the checks could be made without ModCheck, by PatchOperationTest based on some unique def existing in Example Target Mod) and ModCheck.isModLoaded is sometimes used for custom messages.
3. Mention the probability of concurrent execution of checks and/or sequences.
4. Mention that using <success>Normal</success> reveals errors that seem to not be harmful, but maybe someone will have some more info on that.
5. Some more investigation could be made for details about what exact differences in operations prevent them from being used in one sequence ("Do not include multiple types of PatchOperation inside of each PatchOperationSequence." but we saw that sometimes different operations worked fine). And probably this info should be put higher, so it'll explain why the several sequences must be created.
6. Other instruments for working with xpath include plugins for popular text editors such as Notepad++ and SublimeText.

FIXED: It doesn't cause an error when it is left in the definitions, so I don't need that PatchOperationAdd at all.

I was just going to write it But there could be other way: still patching but using UnfinishedAnimalPart from ADS instead of MonsterMash_ADSP_UnfinishedAnimalPart which can be removed (it will be safe as UnfinishedAnimalPart won't be abstract anyway).

The problem isn't that it won't work when A Dog Said is installed, but I need it to work even when A Dog Said ISN'T installed.
This means that I cannot directly reference anything in A Dog Said...

But you'll do it in the patch sequence (as it was) so it'll be used only if ADS is loaded. If not, your MonsterMash_ADSP_ProstheticAnimalCraftBase and MonsterMash_ADSP_BionicAnimalCraftBase will just remain without <unfinishedThingDef> but it won't matter.

Code Select Expand


<li Class="PatchOperationAdd">
<xpath>Defs/RecipeDef[@Name = "MonsterMash_ADSP_ProstheticAnimalCraftBase" or @Name = "MonsterMash_ADSP_BionicAnimalCraftBase"]</xpath>
<value>
<unfinishedThingDef>UnfinishedAnimalPart</unfinishedThingDef>
<recipeUsers>
<li>TableAnimalProsthetics</li>
</recipeUsers>
</value>
</li>


But hopefully it all won't matter if you'll get rid of these bases entirely

FIXED: It doesn't cause an error when it is left in the definitions, so I don't need that PatchOperationAdd at all.

I was just going to write it But there could be other way: still patching but using UnfinishedAnimalPart from ADS instead of MonsterMash_ADSP_UnfinishedAnimalPart which can be removed (it will be safe as UnfinishedAnimalPart won't be abstract anyway).

Ah, I see you haven't copied ADS base (addedPartAnimal) but created your own (MonsterMash_ADSP_addedPartAnimal). It's not that harmful, however I'd still prefer to get rid of it, if it's possible.

Changing <success>Always</success> to <success>Normal</success> still exposes errors:

Code Select Expand


[Monster Mash] Patch operation Verse.PatchOperationSequence(count=8, lastFailedOperation=Verse.PatchOperationSequence(count=2, lastFailedOperation=Verse.PatchOperationAttributeRemove(Defs/HediffDef[defName = "MonsterMash_ADSP_SimpleProstheticTentacleAnimal" or defName = "MonsterMash_ADSP_BionicTentacleAnimal" or defName = "MonsterMash_ADSP_BionicAnimalGill"])(Abstract))) failed
file: D:\Games\RimWorld\Mods\MMWIP2\Patches\ADogSaidExpansionPatch.xml

[Monster Mash] Patch operation Verse.PatchOperationSequence(count=27, lastFailedOperation=Verse.PatchOperationSequence(count=2, lastFailedOperation=ModCheck.FindFile)) failed
file: D:\Games\RimWorld\Mods\MMWIP2\Patches\ADogSaidPatch.xml
as it was, only 1 per file but we can't be sure what exactly causes it.

If I got it right, you may have to change

Code Select Expand


<categories>
<li>Textiles</li>
</categories>


to

Code Select Expand


<categories>
<li>Fabrics</li>
<li>Leathers</li>
</categories>

(or maybe Fabric and Leathery), but I still can't see your recipes ingame on Animal prosthetics table and can't spawn them via dev tools.

You know, this whole thing about "dynamically/conditionally created" defs by playing with their Abstractness was considered just impossible by most (if not all) modders. So it's undiscovered territory and if you'll manage to complete it successfully, it'll be very valuable theoretical result that could introduce new modding technics. That's the other reason to make the final version clear and error-free so other people could use it as an example.

What I have discovered over my examinations is that all of the A Dog Said... compatibility mods used copied versions of the Base definitions from A Dog Said...

Some alphas ago it was necessary to copy bases defs. It was changed in A16 or so, but many people don't bother to change their habits. And other people looking on their mods repeat it. But it's a bad practice and actually leads to problems.

My results still are contradictory. I made a separate files:

• Injuries
• Surgeries
• Prostheses
• BodyParts
• Recipes_AnimalParts
• Recipes_Surgery for recipes with @Name
• Recipes_Surgery for recipes with defName
• Crossreferences

There are cross-referanece errors that I don't look on yet, but the "main" errors like "[Monster Mash] Patch operation Verse.PatchOperationSequence(count=11, lastFailedOperation=Verse.PatchOperationAttributeAdd(/Defs/ThingDef[defName = "MonsterMash_ADSP_SimpleProstheticTentacleAnimal"])(ParentName)) failed" occurs only in 4th, 5th and 7th files. And I'll repeat it, in 3rd file there is

Code Select Expand


<li Class="PatchOperationAttributeSet">
<xpath>/Defs/HediffDef[defName = "MonsterMash_ADSP_BionicAnimalGill"]</xpath>
<attribute>ParentName</attribute>
<value>addedPartAnimal</value>
</li>
which works fine.

The other suspicion that I have is that playing with abstract Hediffs have less "internal obstacles" than with the other def types, but I don't want to believe it.

I'm attaching these files so you can make your own conclusions.

[attachment deleted due to age]

EDIT:

3. But the error message I've got was unexpected: "[Monster Mash] Patch operation Verse.PatchOperationSequence(count=55, lastFailedOperation=Verse.PatchOperationAttributeSet(Defs/HediffDef[defName = "MonsterMash_ADSP_SimpleProstheticTentacleAnimal"])(ParentName)) failed". Though this opration worked perfectly if left alone.

I read something about this the other. It was saying that you need the Parent to be in the same mod as the thing that is using it or you'll get errors, and that the solution is to copy the parent abstracts across.

I have the A Dog Said... compatibility mod the Animal Collab Project. I'll go check how they set it up more precisely, since I may simply be missing something I need.

EDIT 2: The reason why the @ParentName isn't working seems to be because ParentName isn't a true attribute. Rather it seems to be part of the XMLInheritance system, so PatchOperationAttributeSet isn't actually targeting the correct thing.

I'm really not recommend you to copy bases either from Core or from other mods. It can lead to hard-to-track issues in the future. And as the sequence worked fine if left alone, I'm pretty sure this is not the cause. Moreover, I used this way of changing ParentName in some of my patches and it worked fine, too.

I think that the whole patching system is not 100% complete atm and still has some undiscovered issues. Probably the one of them is that in such (unknown exactly) circumstances its error message points to the first PatchOperation in the sequence rather than the one that actually failed. It can be confirmed by changing the order of operations inside the sequence. So I think that we should get rid of any errors even if we can't trust their messages and even if it looks working ingame (otherwise these errors can bite somewhere later).

I'm going to try to divide this patch into several separate files each containing only 1 sequence.

It's possible if you have enough grass Though probably they may eat hay and other things, too, if it's in their allowed area. You can try Smarter Food Selection if you want more control on what your animals (and colonists, and prisoners ) eat (the B18 version is on Steam or Github: https://github.com/Wishmaster01/Smarter.food.selection/releases).

I heard somewhere that the chemicals in their sacs are kept stable only by some processes while they are alive. Whenever they die, these internal reactions become uncontrollable and quickly leading to explosion.

Just put their food in their pen Or make their pen somewhere where they can graze.

Some things that could be helpful (though I'm not completely sure):

1. Looks like using ModCheck.isModLoaded as testing markers is not very reliable. I saw these markers intermixed from different sequences, probably these checks are executed in different threads due to optimization.

2. You may want to use <success>Normal</success> instead of <success>Always</success>, this way you'll get error messages is something fails in the sequences.

3. But the error message I've got was unexpected: "[Monster Mash] Patch operation Verse.PatchOperationSequence(count=55, lastFailedOperation=Verse.PatchOperationAttributeSet(Defs/HediffDef[defName = "MonsterMash_ADSP_SimpleProstheticTentacleAnimal"])(ParentName)) failed". Though this opration worked perfectly if left alone.

4. After some tests I decided that its cause is that the sequence shouldn't contain different defs groups, or maybe it even works per file. So I tried to create separate sequences for HediffDef / ThingDef / RecipeDef. It seemed helpful when I added them 1 by 1 in the empty test file but something become broke again when I tried to apply this method to the whole original file. So I'm still very unsure about it but probably the truth is somewhere nearby.

5. You should be very careful with your recipes as some of them use targeting by defName while other by @Name.

6. And I've commented all ModCheck.FindFile instances so they won't interfere whatever they are.

Edit: 7. When I continued the experiments with commenting the partial sequences, at one stage my screen turned whole black a few seconds after restarting RimWorld (before even the main menu appeared) So be careful not to comment </Operation> when you want to comment only <li> [...] </li> 

I don't know of any mods that use dirt and sand as a separate resource already.

Rainbeau's Fertile Fields

My first attempts to figure the things out led to contradictory results. I'm going to look into it deeper though probably there is something hiding just behind my eyes.

Could it be simple enough that you'll actually consider to implement it?

Well you never know what sticks with you and ends up getting released. I just ride the wave when I see it

I'd really wish to use it, most likely in the form when the player creates some simplified "sketch" with just a few main features that they want and then the game generates a landscape based on it but with some random additions and variations making it more natural-looking

Regarding a server with the map seeds, I'm afraid that it won't be very useful for people using any mods that interfere with terrain generation as the results could be different for them. But on the other hand, using such seeds could be useful even for single players e.g. when they'd want to use some map that they liked after installing some mod that required a new colony.

Anyway, I'll hope you'll enjoy the breeze and tides... wherever they'd lead you

About FindFile, I'd say, if you aren't sure why to use it and how to use it, then you'd better not to use it

Can you upload all the files as they are now? I'd like to see it in the whole.