dslake
commented
11 years ago For the 1.4.6 version of World Downloader, I've put in a fix for this that tracks entities and their IDs when they pass outside of the default tracking range for the particular entity type. The entities are saved in the chunk data internally but not displayed on the screen in-world until the chunk is saved. If the entity is really removed on the server when it's outside of the tracking range than the player would not know about it anyway since they are too far away and they will be saved with the chunk. If there is a particular server function that relies on removing distant entities then it wouldn't work properly, but this fix is probably a much better default behavior. Entities like paintings, pigs, chests, etc will now be saved no matter how far the player walks away from them as long as they were seen at least once.
The server only send entity updates for entities within a limited range around the player, call the trackedRange. For most entity types, it's as small as 64 squares (4 chunks). Once the entity is farther than its trackedRange from the player, the server sends a packet to the client simply saying that the entity no longer exists. It's impossible for the client to determine if it was destroyed because it was picked up, block smashed, creature died or just passed out of range.
The chunk view distance is typically much larger than any of the entity trackedRange distances. Most servers have a chunk view limit of 10 when entities are limited to 4-6 chunks. By the time a chunk is unloaded due to player movement, all of the entities in that chunk have long been deleted and therefore are not saved.
As an enhancement, find some way of tracking those entities that are removed simply due to range and save them to the chunk when it goes out of range. It may not be possible with the data sent by the server. As a simple example, if a creeper is more than 80 blocks away from the user, the server will remove it from the client. If we 'remember' that the creeper is there, it may not even make sense to save it since its actual position will have moved or the time of day will have changed and it may not be there at all by the time the file is saved.
This is a placeholder to remember this issue and look for a solution. It was originally tracked as issue #7.