Remapping items issue

I’m changing the crafting requirements of certain blueprints (i.e. reducing pelt requirements for fur armor).

As an example, I created a child of the Metal Hatchet BP, and used the Remap Item field in the PrimalGameData_BP to point from the original to my child.
In the game, the hatchet can’t be crafted at the Smithy anymore, but the Smithy will craft items that I haven’t created child BPs for.

What’s strange is I also modified wood structures like walls/ceiling and those can be crafted in my inventory and they correctly show the resource values I changed.

So it seems that if a modified BP requires a container (Smithy/Fabricator) to craft it, it won’t show up. But if a modified BP can be crafted in the player inventory, it will show up.

I triple checked all my file links and names and everything checks out.

Anyone have a clue what the deal is?

If I understand what has happened correctly, by remapping, you’re replacing the item in question - this you know, but it seems the side effect of this is that by replacing it, it no longer exists in the structures inventory as a valid entry; probably because “Exact Class Match Required” has been enabled in the default(hidden) logic for crafting structures. A very simple, basic way of looking at it.

If you want it to show up again, remap, try the additional structure engrams array to add your replacement back into the structure you took it from?

All of the above is just guesses, really, but some things to consider.

-WM

Yeah that’s pretty much it. Crafting containers don’t seem to care about remaps. But I did more testing and came up with interesting results.

I made a child of PrimalInventoryBP_AnvilBench, changed the Default Inventory Items to point at the children of the items I modified, and remapped the AnvilBench in the PrimalGameData_BP to point at the AnvilBench_CHILD.
As a test I also made children of the Fur Engram BPs (and remapped them) to enable them for crafting in the players inventory without the Smithy.

This gave telling results.

  1. Fur armor isn’t in the AnvilBench Default Inventory Items list. As a result it showed up in the player inventory AND also in the Smithy. The Smithy version had the default pelt values, and the player inventory version had the modified pelt values.

  2. A Metal Hatchet did show up in the Smithy on a live server (it didn’t show in my single player game), but the metal values are default and not what I changed them to.

So…even though I forced the Smithy to look at the child classes like Metal Hatchet, it still points to the default files. As you said, these settings seem to be hidden and can’t be changed in the Dev Kit.

Did you try what I initially suggested?

Your testing is also slightly invalidated, or rather loses some relevance. You changed the parameters compared to what you were initially doing by testing with a remapped and childed crafting structure - as you’ve learned, remapping changes things.

-WM

I’m trying to do that, but no results.

Does the “For Class” field point to the PrimalItemStructure_AnvilBench or the PrimalInventoryBP_AnvilBench?

I tried both and added my Metal Hatchet child in the “Class Additions” field.

No dice. Nothing shows up in the Smithy when testing Play in the editor.

It needs to point to the inventory of the structure.

Are you specifying the PrimalItem file or the BP for the hatchet?

Otherwise the only other suggestion would be to use copy, not a child.

Childing creates more issues than it’s worth, at times.

-WM

The array was pointing to the PrimalItem for the hatchet. The first field was the AnvilBench box file.

I tried doing copies but the mod never uses those over the default files. Do I have to name them uniquely?

I have this same issue… After I tested it, I got a nasty bug and I can no longer use the smithy period now…I didn’t mean to high jack your thread. Just stating, I had the same issue, and did it the same way you did.

Let me know if you found a fix and I will do the same. Thanks.

They should be named uniquely.

EDIT: For that matter, so should Child versions.