Build Validation

Explicit build validation resolves master/part definitions and calls UWeaponRuntimeBuilder::ValidateBuild. It is separate from request-helper input checks, editor asset validation and runtime equip initialization.

Source: Private/Manager/WeaponRuntimeBuilder.cpp, Private/Components/AC_WeaponNetComp_Build.cpp and Private/Components/AC_WeaponNetComp_Callbacks.cpp.

Validation Sequence

1. Build a master pointer and a part registry from loaded assets.
2. Require a loaded master and initialize available slot tags from its SubSlotSockets.
3. Walk Parts in their stored order, requiring a loaded part and an available installed slot.
4. Check InstalledSlotTag against the part's CompatibleSlot.
5. Reject duplicate parent/socket pairs and accumulate part tags/capabilities.
6. Add each installed part's child slot tags to the available set.
7. Resolve each socket provider and test the part's required/blocked provider tags.
8. Reject capability overlap and missing required installed slot tags.
9. Return Success with bIsValid true.

Matching Rules

Check	Actual rule
Available slot	InstalledSlotTag.MatchesTag(AvailableSlot)
Compatible slot	InstalledSlotTag.MatchesTag(Part.CompatibleSlot)
Provider required tag	ProviderTags.HasTagExact(RequiredTag)
Provider blocked tag	ProviderTags.HasTagExact(BlockedTag)
RequiredParts	Exact membership among installed slot tags
Capability conflict	GrantedCapabilities.HasAny(BlockedCapabilities)
Occupancy	ParentPartID and InstalledSlotName combined as the occupancy key

Slot checks allow hierarchical tags; provider filter checks use exact tags. RequiredParts uses exact installed tags. Do not substitute a tag family for a required exact tag and expect the same result.

Parent Order and Provider Fallback

Parts unlock their child slot tags while the validator walks the array. Put a provider before a child whose slot exists only on that provider. The later parent-compatibility pass first tries ParentPartID, then searches the master and installed parts for a provider of the socket name.

Consequently, validation is not a strict proof that the declared parent exists or that the assembly is an unambiguous acyclic parent graph. Keep correct parent IDs and distinctive socket names, and verify nested parts visually. Installed parts are also indexed by PartID for provider lookup; duplicate uses of the same asset do not create independent provider keys there.

Current Failure Results

ResultType	Trigger
InvalidRoot	No master found among loaded assets
AssetNotFound	Installed part asset missing
InvalidSocket	Installed slot tag not currently available
IncompatibleSlot	Slot tag not compatible with the part
SlotAlreadyOccupied	Duplicate parent/socket occupancy key
IncompatiblePart	Provider missing or provider filter fails
CapabilityConflict	Granted and blocked capability sets overlap
MissingRequiredPart	Required installed slot tag absent
Success	All current checks pass

Other enum values are declared but are not separate branches in this validator. Provider failures use IncompatiblePart with a detailed FailureReason.

Completion and Registry State

The Net component validates its current WorkingBuild after loading its referenced assets. It sets bValidated and bUsable to the result and broadcasts the working-build mutation. Failure is logged and does not emit OnBuildValidatedCallback.

On success, HandleBuildValidated stores the GUID, registers a copy on authority, broadcasts OnBuildValidatedCallback and sends its client RPC in server network modes. Bind the delegate before requesting validation.

Edits do not invalidate old flags, and failed validation does not remove a previously registered snapshot. Revalidate a changed configuration successfully before equipping it. Equip reads the registry; it does not rerun ValidateBuild or check those flags.

Validation also does not guarantee valid meshes, sufficient runtime component capacity, a matching actor family or completed projectile/gameplay behavior. Validate asset content in the editor and test runtime assembly separately.