Do not emerge blocks in the active_object_send_range_blocks range

[lhofhansl]

See comments on #14148

When I added the extra range to active_object_send_range_blocks a while back the intention was to keep active objects that were already seen on loaded blocks in sight.

When looking at #14148 I noticed that all of these blocks are placed on the emerge queue. This is neither intended nor desired.
In particular it lead to the same blocks being enqueue over and over again if they have not been generated, yet.

Most folks do not set active_object_send_range_blocks and so won't be affected by the problem.

• Goal of the PR
  Do not emerge that only on the active_object_send_range_blocks range. Activate them when existing, ignore them otherwise.

• How does the PR work?
  This these blocks in a separate list. Blocks in the active_block_range are emerged as before, but extra blocks in the active_object_send_range_blocks view cone are only activate when they exists and not emerged otherwise.

• Does it resolve any reported issue?
  No. But it reduces load on the emerge threads and DB if active_object_send_range_blocks is set to larg'ish value.

• Does this relate to a goal in the roadmap?

• If not a bug fix, why is this PR needed? What usecases does it solve?

To do

This PR is Ready for Review.

How to test

Set active_object_send_range_blocks larger than active_block_range. Observe that visible any entities out of active_block_range but sight in closer than active_object_send_range_blocks are still visible (as long as their block is visible).

[sfan5]

Most folks do not set active_object_send_range_blocks and so won't be affected by the problem.

?
It's set by default and higher than active_block_range.

[lhofhansl]

@sfan5 How about this?

[sfan5]

almost, how about this? http://sprunge.us/0FxRyA?diff

The idea is that everything is in blocks_added and extra_blocks only whether it should be emerged or not.

[lhofhansl]

That's not quite right either. When the block is on the added list and the extra list we need to emerge.

The initial logic, while a bit convoluted makes that all pretty clear. I reverted back to that for now.

[lhofhansl]

I think this is as good as it gets, when possible use a standard set operation, use hand-coded loops when multiple actions happen in the loop.
(This can be all done with set operations in this same order, but then you'd 5 loops over the various sets instead of 3.)

[lhofhansl]

Also, we might want to let it generate blocks in the active_block_range. If I were a player I'd want active blocks around present regardless of whether need to be loaded from disk or be generated. I can add that here - a one line change, or in another PR.
(Right now Map::getBlockOrEmerge(...) only enqueues blocks for loading from DB, not for generation.)

[sfan5]

Exhaustively testing would be a waste but I'd do something like this to maybe catch the case where someone messes it up again in the future:

assert(newlist.size() >= extralist.size());
assert(blocks_removed.size() <= m_list.size());
if (!blocks_added.empty())
  assert(newlist.count(*blocks_added.begin()) > 0);
if (!extra_blocks_added.empty()) {
  assert(newlist.count(*extra_blocks_added.begin()) > 0);
  assert(extralist.count(*extra_blocks_added.begin()) > 0);
  assert(blocks_added.count(*extra_blocks_added.begin()) == 0);
}
if (!blocks_removed.empty()) {
  assert(newlist.count(*blocks_removed.begin()) == 0);
  assert(extralist.count(*blocks_removed.begin()) == 0);
  assert(m_list.count(*blocks_removed.begin()) > 0);
}

(should compile to no-op if NDEBUG)

[lhofhansl]

I assume you mean ... count(*....begin() ...

[sfan5]

oh, sure

edit: also added two more

[lhofhansl]

Added the basic sanity checks.