Last night we finished a first pass on the documentation for this update, now available on our documentation site! Of particular note: Blueprints v2 Format
Q: Was a time-to-craft feature considered?
A: It is something we discussed, and isn’t necessarily off the table for the future.
Q: Can the old crafting menu be used, particularly for performance reasons?
A: We’re conscious that GUI changes are often unpopular, and have attempted to keep the menu very familiar.
Many aspects of crafting have received performance improvements, but the new default view showing ALL partially craftable recipes may be slower than the old default filtering by category. Enabling “Hide Uncraftable” cuts down on that, but we can investigate further. Any feedback on specific elements of the new crafting menu you dislike or performance issues would be greatly appreciated!
Duping bug:
Thanks for the report! This should be fixed shortly in a patch. Some state wasn’t properly reset when using CTRL to repeat the blueprint.
Vaccine missing:
We checked into this, but it seems to be showing up on our end. We did change the requirements a bit: Crafting Level III and a Chemistry Lab are now required. Is that why it wasn’t showing up?
Q: Why is the “nearby” range hardcoded?
A: Currently, available crafting tags are refreshed per-player in a sphere around them. In a level with potentially hundreds or even thousands of tag providers, a per-player lookup may be more efficient performance-wise than a per-tag-provider lookup. Two examples of alternative approaches allowing a per-tag-provider (workstation) radius would be:
- Large trigger volumes per-tag-provider that monitor for player overlaps. For example, a sphere collider with trigger enabled, allowing a custom radius.
- Passive colliders per-tag-provider that don’t actively monitor for player overlaps, but can be queried by the physics system at the player position. Rather than checking in a sphere around the player, only the player’s position would be tested against these.
However, both of these options add a lot of additional colliders to the scene. It’s a performance trade-off. This was one of the key considerations in removing colliders from structure snapping: it was a performance win removing tens of thousands of colliders from the scene (not to mention the new snapping is more context-sensitive), albeit with more coding needed for new structure sizes or formats.
All this to say, there isn’t necessarily a “best” decision here. Ideally, we might revisit this same trade-off for a system like stealth / mob-perception to allow per-zombie/per-animal detection checks. That currently uses a per-player nearby mobs lookup (similar to nearby tags) as opposed to per-mob nearby targets lookup, but adding per-mob colliders could be a big gameplay improvement.
Q: Can crafting tags be provided by anything other than barricades?
A: Yes! Using the Crafting Tag Provider and Crafting Tag Modifier components, more details in the mod hooks documentation. We might have forgotten to update the Project package with these scripts for the preview branch and will make sure to do that for a patch today.
Edit 2025-05-07: here’s the most recent Project.unitypackage. (not on preview branch yet, unfortunately)
Q: Why not string-based asset identifiers?
A: Named IDs for configuration would be more user-friendly. However, they’re more prone to collisions (similar to legacy IDs) and less resilient to renaming. With -ResaveAssets we’re moving toward automatically commenting asset references in files and (ideally) more user-friendly tooling for configuration.
Q: Is it possible to hide vanilla crafting cateogires?
A: Sort of, indirectly. Categories are populated from the blueprints available in the level, so if the level prevents crafting vanilla blueprints and does not use any vanilla crafting categories then the they will not be shown.
Q: Can a barricade provide multiple crafting tags?
A: Yep!
Q: Can crafting tags be tested with OR / AND logic?
A: Not yet. We’re headed in that direction but no ETA. This was one of the aims of rewriting several systems to support the newer list format:
Previously, AND / OR logic for NPC conditions would’ve looked something like (1 and (2 or 3)) referring to conditions by index. In the future, we’d like to support something like:
[
{
// 1
}
AND
[
{
// 2
}
OR
{
// 3
}
]
]