- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 546
- Reaction score
- 7
Trying to get clean bone data in Rust is always a headache thanks to Unity's messy transform hierarchy. Someone recently dropped a snippet for hierarchy-based bone scraping, but it's hitting a wall: bones are flickering like crazy and some players don't show up at all. This usually points to race conditions or incorrect offset handling during physical memory reads.
The Implementation Logic
The approach uses ReadPhysicalRaw to pull trsX (Translation, Rotation, Scale) and parent indices in bulk. It attempts to validate the read with a 3-attempt loop, checking if the hierarchy addresses changed mid-read. While this is better than nothing, flickering in Rust often stems from the game updating the transform buffer while your external is still chewing on the data.
Technical Meat: Transform Traversal Code
Troubleshooting the Flickering
If you are seeing the result showing up as flickering bones, check these common failure points:
Anti-Cheat & Performance Risks
Scraping bones this way is relatively safe from a detection standpoint because you aren't calling engine functions, but constant ReadPhysicalRaw on the hierarchy can be taxing if you don't cache properly. If you're getting manual bans or being flagged for specific patterns, look into how often you refresh the hierarchyAddr.
FAQ
Anyone else dealt with these race conditions in Rust recently?
The Implementation Logic
The approach uses ReadPhysicalRaw to pull trsX (Translation, Rotation, Scale) and parent indices in bulk. It attempts to validate the read with a 3-attempt loop, checking if the hierarchy addresses changed mid-read. While this is better than nothing, flickering in Rust often stems from the game updating the transform buffer while your external is still chewing on the data.
Technical Meat: Transform Traversal Code
Code:
void Getbones(uintptr_t& boneTransforms, std::unordered_map<int, Vector3>& bones)
{
if (!boneTransforms)
return;
struct BoneData
{
int id;
int hierarchyIndex;
uintptr_t hierarchyAddr;
};
std::unordered_map<int, Vector3> resultBones;
std::vector<BoneData> validBones;
std::unordered_map<uintptr_t, int> hierarchyMaxIndex;
const uintptr_t boneListAddress = boneTransforms + 0x28;
constexpr int bone_count = sizeof(bone_list) / sizeof(bone_list[0]);
for (int i = 0; i < bone_count; i++)
{
int boneID = bone_list[i];
uintptr_t boneEntityPtr = process.Read<uintptr_t>(boneListAddress + (boneID * 0x8));
if (!boneEntityPtr)
continue;
uintptr_t trans = process.Read<uintptr_t>(boneEntityPtr + 0x10);
if (!trans)
continue;
TransformInternal::TransformAccess access = process.Read<TransformInternal::TransformAccess>(trans + 0x38);
if (!access.hierarchyAddr || access.index < 0 || access.index >= 4000)
continue;
validBones.push_back({ boneID, access.index, access.hierarchyAddr });
auto it = hierarchyMaxIndex.find(access.hierarchyAddr);
if (it == hierarchyMaxIndex.end())
hierarchyMaxIndex[access.hierarchyAddr] = access.index;
else if (access.index > it->second)
it->second = access.index;
}
if (validBones.empty())
return;
// ... (rest of the hierarchy iteration and quaternion math here) ...
}
Troubleshooting the Flickering
If you are seeing the result showing up as flickering bones, check these common failure points:
- Physical Memory Sync: If you are using DMA or a high-speed external, the localT / parentI double-read check might still be letting dirty data through. Unity's transform buffers are volatile.
- Hierarchy Depth: The safety limit of 120 iterations is standard, but if your index calculation for parent indices is off by even a few bytes, you'll be calculating world positions based on garbage parents.
- Index Bounds: If access.index is returning values outside of your expected buffer size (4000 in this case), the bone simply won't appear.
- TRS Struct Alignment: Ensure your trsX and TransformAccess structures match the current Unity build Rust is running on. A single padding shift will break the math.
You cant view this link please login.
Anti-Cheat & Performance Risks
Scraping bones this way is relatively safe from a detection standpoint because you aren't calling engine functions, but constant ReadPhysicalRaw on the hierarchy can be taxing if you don't cache properly. If you're getting manual bans or being flagged for specific patterns, look into how often you refresh the hierarchyAddr.
FAQ
Usually, it's because the hierarchyAddr for that specific player entity is either null or in a memory region that your driver/process failed to read at that specific millisecond. Check your error codes on the read calls.
Anyone else dealt with these race conditions in Rust recently?