Apollo's statement was correct:
We discovered that they, like most objects in the game, de-spawn when you force the game to de-load their origin District.
"De-load their origin District"? Okay... so admittedly the explanation is a bit technical. I went over this in length in my
Modified Gothi Theory. Allow me to try to simplify the explanation. At length.
ODST keeps two districts in memory at once. That's it. You can never have a team spread out over three or more districts, since ODST can't load in more than two at a time. This has consequences on gameplay.
One consequence is player warping in co-op. The one and only reason this happens is because of the two-districts-in-memory-at-once limitation. Just you
try to open up the doors into a third district while your team is simultaneously accessing two others. You'll begin a warp-fest before you even get to the doors into that third district. The SGP tested and reported this behavior
here.
Another consequence is that objects may suddenly and inexplicably disappear when you get to close to district doors.
So why all the fuss about getting close to district doors?
Just like that girl you brought home from the bar for a one-night stand, the game engine wants to make sure it looks pretty for you in the morning. It doesn't want you to see its real face without any makeup on. Since it can only handle showing you two districts at once, it has to scramble to cover up the fact that one of those three districts you tried to access at once is going to suddenly disappear from existence. (After that one-night stand, you're probably feeling like you want to do the same thing!) You may have noticed that you've never looked through district doors to see a vacuum of game geometry; there is always a part of the city to be found when those doors open. This is the sole purpose of the doors: covering up the fact that in many cases there
is a complete lack of city behind them.
To enable the game engine to perform this sleight of hand door game, some clever engineer at Bungie devised a means to mark off zones around the district doors. Enter one of these zones and the game engine knows it has to wake up and re-assess which two districts it is going to allow the player(s) to inhabit at once. If it determines that a district needs to go bye-bye to make room to load another one, then any players in that district are getting warped out and any open district doors into that district are going to shut- even if they were blocked. AND: any objects that originated in that district are also about to make a one-way trip to the great bit bucket in the sky.
That's a lot to happen just because someone got too close to a district door... but that's the facts of life in ODST's Mombasa Streets.
It actually gets more complicated than that- but we're keeping this light. Suffice it to say that there is some additional data manipulation going on behind the scenes that make the bump glitch happen. I have called this "preloading". I only mention this here because it explains the term "preload boundary".
Those zones around the district doors that I mentioned previously have defined lines around them. I call them preload boundaries. Cross the line and you're in the zone- and you can expect all sorts of wacky things to happen if you're not careful. Player warping, data loading, door closings, item spawns and de-spawns. General mayhem.
The moral of the story is that players who are researching the secrets of the city need to respect their boundaries! Ideally, you want to work in one district at a time. Then, move to another district as a group taking care that you force a complete load of that area (another topic). Sometimes, a group needs to work two districts at once (such as when we were shuttling plinths across district lines). This is when you need to be SUPER careful. One step across a preload boundary is like pushing a chaos button if that boundary is linked to a district that wasn't already loaded.
I have created a
map of D06 which shows the preload boundaries. Hopefully this will help people trigger preloads when they want them and avoid preloads when they would be undesirable. All of the other districts behave the same way. Stay away from the district doors and you'll stay away from the preload boundaries.
So about our plinths:
Each plinth is tied to the district it originally spawned in. It can be moved to an adjacent district, but no further. Why? Because any further requires the game engine to unload the district where the plinth spawned. When the district goes away, the plinth goes away.
If we have any hopes of building a Plinthhenge (lol) out of six plinths, then those six plinths need to be located in adjacent districts. Period.
Understanding the details of the game engine behavior is critical because it limits the scope of our research. We can't put a plinth in each hnege location, for example, because this would require the game to load many more districts at once than it can. Likewise, we can't put a player in each henge location at once. This doesn't mean that all of these locations don't play a part in any secret we may uncover- it just means that things may have to be done sequentially, not simultaneously.
Obviously, I am inclined to discuss this at length! :p If you have further questions, I'll try to clarify even further.
