woven ether
Howdy folks. I have debugged the issue where my client entities all spawn at (0,0,0) even though they spawn in correct locations on the server. Additionally, I have discovered what appears to be a corrupted archetype handle error and would appreciate another pair of eyes on the call stack.
Will recap since I'm going to try out this "threads" feature on Discord. I asked a moderator about how to make related information on a topic more readable, and am implementing that advice.
For context, I am performing all debugging in-editor, with the main editor window configured as a listen server and a single client. This allows me to use the apostrophe key for Mass debugging, as well as attach the Mass Debugger to the client window. This project is in UE5.6. I have not yet updated to 5.6.1 in the interest of keeping the project stable. There are Mass changes in 5.6.1's changelists, but I do not know enough to tell if they would impact this issue.
I have a Mass project that spawns 10 entities. The data asset config for the entities has a replication trait (from arkena00's minimal replication project) as well as an octree trait (based on the one from Megafunk's Mass Sample). When the octree processors are set to only run on the server, I am able to detect entities at runtime through an octree bounding box check made by the player pawn and issue movement orders to those entities. These movements replicate to clients as expected. All movement orders are issued by the server and replicated out to all clients. This is the expected and desired behavior. I feel it is a nifty little demonstration of Mass interactivity, and it was a great learning experience.
However, clients were not able to detect entities using the octree. This was surprising, since I did not replicate the octree or perform any changes which I felt would interfere with running it on a client. After debugging as mentioned in my earlier post, I enabled the network replication flags in the octree processors. (Megafunk also pushed updates to his octree code that used a much wiser method to add flags. I will explain later how I updated to his new code, this part is about my independent fumbling.) Now that the processors were running, clients could detect entities by clicking on them, just the same as the server. Great progress!
The only visible problem was that all of the entities spawn on clients with a transform of (0,0,0), even though they spawn with the correct transforms on the server. (I am attaching a screenshot of the issue.) I thought this was some kind of initialization error. However, when I tried to issue a movement command from the server, which would be replicated to the clients, the engine crashed. I dug into this. First I disabled the octree trait in the entity config data asset to quickly confirm that the cones spawned properly on client when the octree was not present. Then I performed additional removal tests to determine as best as I could that the issue only happens when octree processors run on the client. (I am attaching a screenshot of the entity config data asset.)
To make sure this was not a problem caused by my amateurish code, I went and pulled the latest versions of the octree files from Megafunk's Git repository. These were:
From commit e6fb86522b9b4c615be61d933808aa34c0370427
\Common\Fragments\MSOctreeFragments.h
\Common\Processors\MSOctreeProcessors.h
\Common\Processors\MSOctreeProcessors.cpp
(I also updated the Mass Sample plugin to use subsystems, as required by one of the earlier commits that impacts the octree system.)
Then I repeated my tests, with the exact same results. (Much heartbreak there, as I was really hoping I had done something dumb that could be easily corrected!)
Inspecting the octree code, I could not understand how it could cause this sort of issue. From what I can tell, whenever the octree accesses the entity transform it does so through a const keyword, which should prevent it from modifying the transforms in any way. Additionally, the octree works on client, since the debug print I have set up returns the ID of the nearest entity clicked. On client, I can click from different sides of the cone stack to confirm there are multiple entities present even though all have the transform (0,0,0).
I do not know what steps to take to debug this code further. I will have to learn more about archetypes and what interactions could affect the entity transforms. I have a gut feeling that the error in placement of these entities is entangled with the crash when the server tries to issue movement orders. Will detail that crash next.
Am attaching the full error log with call stack to this message. The error provided is:
A breakpoint instruction (__debugbreak() statement or a similar call) was executed in UnrealEditor.exe.
C:\Program Files\Epic Games\UE_5.6\Engine\Source\Runtime\MassEntity\Internal\MassArchetypeData.h
Line 510: check(ArchetypeHandle.IsValid());
Again, this crash only occurs when the octree processors run on both client and server and the server issues a movement order. No issues when the octree processors are only on the server, the entities move and replicate just fine. This crash is a breaking error, not a debug ensure that I can continue through in Visual Studio.
I will continue digging into this issue, but would greatly appreciate any advice from wiser heads. If anyone feels that reviewing my project would be a faster way to help than asking me for more information, I can upload it here since the zip file is only 42MB which is within the filesize limit for this Discord server. I have not done so yet since that feels rather like an imposition on others' time and I do not wish to presume.
I would like to get to the bottom of this issue, as combining simple replication for server-driven movement with the ability for a client player to select and view information from entities seems like a really powerful way to use Mass for many different kinds of practical simulations. My hope is that these notes are useful to anyone else in the community who is exploring along similar lines, since I have frequently found the notes of others useful in my learning journey, and also that someone out there might have an idea that will help solve this problem! 🧠
fervent jacinth
This is a lot of text without a crash callstack
Oh, it's at the bottom
Why leave out how FMSUnitFastArrayItem works?
Is that a base setup from Arkena's sample?
Ah yes it is
this is from the entity view bieng constructed
FMassEntityView(const FMassEntityManager& EntityManager, FMassEntityHandle InEntity)
You need to determine if the incoming mass handle is even a valid one locally
not sure how the octrees could affect this but technically they can cause archetype moves
Are you destroying things from the ocrtree processor on the client?
also that mass replication scheme is being deprecated anyways iirc
woven ether
Hi @fervent jacinth , thanks for taking the time to reply. I really appreciate the examples and documentation you put together on Mass. Without that information, I would not have even gotten off the ground on this learning journey.
My delay in replying is because after reading your responses, I decided to remove the octree code completely from the project and implement detection based on a hash grid instead. I tested to confirm this implementation allows both clients and servers to detect entities near a given location, without any of the incorrectly positioned entities or crashes previously described. I confirmed that this is not as optimized a solution as your octrees, but it fits my needs and runs within the performance requirements.
To answer your questions in case the information is of use to others: