[B18-1.0] Monster Mash (v4.0.4) (Changed Frameworks and Dependancies)

[wwWraith]

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> 

[ilikegoodfood]

I suppose it's time to resume my own experimentation.

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

I recently changed all of the @Names from the defs to defNames, excluding the three surgery Bases. At the time I sent it to you, I hadn't gone through and changed them all over yet in ADogSaidPatch.xml
Be careful with changing them back though, as three of them (MonsterMash_ADSP_TentacleBaseAnimal, MonsterMash_ADSP_SimpleTentacleBaseAnimal and BionicTentacleBaseAnimal) are supposed to be using @NAme, not defName.

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.

EDIT: Yeah. I see that two of the message for my own patches are displayed out of order. The RangedAnimalFramework message cuts in-between the two cephalopod messages. Very odd.
Side Note: None of my spellcheckers, not in Notepad++, not in Chrome, seem to recognize cephalopod. I wouldn't have expected that...

4.

At what point did it break?

So be careful not to comment </Operation> when you want to comment only <li> [...] </li> 

Must say that I actually expected some sort of hanging issue if the file didn't have the closing sequence.

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.

[ilikegoodfood]

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.

Well, this seems to confirm my suspicion, although what they've done is super simple, just a duplicate of the various A Dog Said surgeries. They do, however, have all of the required parents copied into their own patch. I'm working on that now.

EDIT:
Also, I think the reason why all of the patches use the <success>Always</success> is because the errors that the Patch sequence claims are happening, aren't actually stopping it from working.
I just got an error saying that the PatchOperationAdd for the MonsterMash_ADSP_SimpleProstheticTentacleAnimal failed, yet the Hediff is available in game, none-abstract and with all components working.

[wwWraith]

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.

[ilikegoodfood]

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...
Furthermore, I have found that changing the way that I define the abstracts and patch them afterwords works.

I am currently overhauling the entire system to match, nearly finished, and everything works so far, both in Vanilla and in A Dog Said...

Once I have everything working, I will try and modify it to use the A Dog Said Bases directly. If that works I will re-define that system, but if it doesn't I will know why.

EDIT: I've also decreased the patching loading time by a perceptible amount by applying additional optimizations.

EDIT 2:
The fragments of information that you have provided and the tests that you did have been invaluable in this process. There is no way on earth that I would have managed to do what I am doing now without your insights and help.

Thank you wwWraith.

[wwWraith]

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]

[ilikegoodfood]

There are cross-referanece errors that I don't look on yet

That is because of the order that the Patch operations are done.
Until the defs are patched, they don't properly exist and therefore the cross-references fail.
To solve that, you need to remove the cross-references from the defs and patch them in LAST. The only way that I can find to control the order of patches is within the save file. Different files appear to be patched concurrently, which is why we see the odd custom message order.

Also, you were right that each PathOperationSequence should only contain one type of patch operation. This can easily be done by putting them in sub-sequences.
The xml file's primary PathOperationSequence then becomes a sequence of PathOperationSequence s, and everything works.

I am re-uploading the Monster Mash (WIP).zip now, so that you can see what I have changed, which is pretty much everything.
Since I have changed the very last section, I am now getting errors in the error log, but that seems to be a specific issue with one of the operations.

Once I solve this last bug, I will attempt to remove the duplicate bases, as per your recommendation, but for now, I have everything except for the very last few bits working.

EDIT: There's a bug with the Devilstrand referance as well in Recipes_AnimalParts.xml
They should instead read DevilstrandCloth. I have fixed it my end but not yet in the upload.

Also, there is an issue with the Textiles filter, but I'll look into that shortly.

EDIT 2: I think I know where the final errors are and how to fix them, but have to stop for lunch. Just give me some time and I will send you what I have either when it fails and is beyond my knowledge, or when it works.
Since I'm making very regular edits, your files that I just sent you are already several bug-fixes old.

[wwWraith]

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.

[ilikegoodfood]

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.

I am entirely aware of that.

I realized that, if the Abstract tag could be manipulated freely, the xpath patches provide all of the required tools needed to do it, provided they work consistently and as expected, so I set about trying to solve the problem.
No points for guessing that I took Chemistry, Engineering, Mathematics and Physics for my A-Levels.

I'm also well aware that most people have been running update scripts on their mod-files without wanting to spend the time and effort to examine the possibility of new possibilities.
Since I don't have previous version to update from, spending the extra time now to achieve the impossible simply makes sense to me.

EDIT: I finally found the specific bug I was looking for. I had written "Path" instead of "Patch" [Facepalm]

So, only one small error left.
In this recipe, it uses any textile, but there is a cross referencing issue with it, probably the fixedIngrediantFilter. Do you know what should go in there instead?

Almost got it. Just need to set the correct name for devilstrand now.

[ilikegoodfood]

And here is the new Monster Mash (WIP).zip!

I haven't run detailed tests on it in game yet, but there are no errors on loading it with A Dog Said... installed and without it.

It is still using copied over versions of the A Dog Said... base definitions. That is the next step, which, because I need to patch-out many cross-references in order to prevent loading errors, both from the defs being none-existent in Vanilla, and from patching operation order when the patch is processing, may be rather more complex than you think. I need to take a half-hour break.

Enjoy!

EDIT: The probable solution would be to use patching to copy them over automatically, a several step operation, remove the cross references from the auto-copied versions, perform all of the other patches and then add them back in, much as I have done now.

[ilikegoodfood]

In-game testing has revealed three errors.

One of them has been fixed. I had accidentally assigned all three HediffDefs to output the same prosthetic organ. I'll post the correction at the end of the document for you...

The other two are slightly more interesting:
The following PatchOperationAdd and the ModCheck.isModLoaded after it are both failing silently:

Code Select Expand

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

<li Class="ModCheck.isModLoaded">
<modName>A Dog Said...</modName>
<yourMod>Monster Mash</yourMod>
<customMessageSuccess>Monster Mash :: Cephalopod prosthetics completed.</customMessageSuccess>
</li>

Also, the InstallSimpleProstheticTentacleAnimal and InstallBionicTentacleAnimal aren't showing up on the LandKraken's health tab even when the colonists have the items available. - FIXED

I'm investigating them both.

And here is the correction I mentioned above (paste it over the corresponding section):

Code Select Expand

<!-- ===== Implementing out-of-order Cross References ===== -->

<li Class="PatchOperationSequence">
<success>Always</success>
<operations>
<li Class="PatchOperationAdd">
<xpath>Defs/HediffDef[defName = "MonsterMash_ADSP_SimpleProstheticTentacleAnimal"]</xpath>
<value>
<spawnThingOnRemoved>MonsterMash_ADSP_SimpleProstheticTentacleAnimal</spawnThingOnRemoved>
</value>
</li>

<li Class="PatchOperationAdd">
<xpath>Defs/HediffDef[defName = "MonsterMash_ADSP_BionicTentacleAnimal"]</xpath>
<value>
<spawnThingOnRemoved>MonsterMash_ADSP_BionicTentacleAnimal</spawnThingOnRemoved>
</value>
</li>

<li Class="PatchOperationAdd">
<xpath>Defs/HediffDef[defName = "MonsterMash_ADSP_BionicAnimalGill"]</xpath>
<value>
<spawnThingOnRemoved>MonsterMash_ADSP_BionicAnimalGill</spawnThingOnRemoved>
</value>
</li>

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

<li Class="ModCheck.isModLoaded">
<modName>A Dog Said...</modName>
<yourMod>Monster Mash</yourMod>
<customMessageSuccess>Monster Mash :: Cephalopod prosthetics completed.</customMessageSuccess>
</li>
</operations>
</li>

[wwWraith]

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.

[ilikegoodfood]

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.

Oh dear, I fixed that one within seconds of asking and forgot to mark it as solved.
So far I am back down to only a single bug to fix before being able to experimenting with removing the copied parents.

The following PatchOperationAdd and the ModCheck.isModLoaded after it are both failing silently:

Code Select Expand

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

<li Class="ModCheck.isModLoaded">
<modName>A Dog Said...</modName>
<yourMod>Monster Mash</yourMod>
<customMessageSuccess>Monster Mash :: Cephalopod prosthetics completed.</customMessageSuccess>
</li>

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

EDIT 3: Now on to inheritance tests.
I have disabled A Dog Said... and I will change things over to use the A Dog Said... bases and check to see if it throws up errors in Vanilla, one base at a time.
For each base that doesn't error when referenced without the mod being installed, I will then test it in the patch operation.
If it still doesn't error, then I'll remove my own version.

EDIT 4: Despite it being for an abstract, I immediately received "Could Not Find Parent Node named..." errors on all modified items.
I am now going to remove the ParentName entirely and attempt to add them via the ADogSaidExpansionPatch.xml instead.

[wwWraith]

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).

[ilikegoodfood]

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...

Testing is under way and will take some time.

EDIT: Removing the ParentName entirely from the HeddiffDefs and then re-adding them during the patch worked without error. I'm now going to be working my way through the rest of the files testing them one-by-one to see which bases I can reference directly and which ones, if any, I need to keep the duplicates of.