I'm sorry this one seems to have gotten lost in the queue, despite verification. We'll look into it more this week.

Okay, I have discovered the source of this bug. Very interesting, and it explains why it's evaded my tests.

If an obj or mob is given a large icon while it's in a player's view range, the turf is not being added to the player's internal list of interesting turfs to watch. Interestingly, when they move far enough out of range and back into range again, it updates, and the problem stops happening.

I'm still figuring out a fix, but I have a test case now that's reliably showing the issue.

Huzzah! You can do it Lummox!

Edit: It seems like... if I look at the icon for a good 5 seconds and then go out of sight it doesn't disappear. As if it was given time to load. Odd. If you need a recording, let me know.

This is not the case for me. No matter the length of time spent with the icons original location in view, it still vanishes.

I haven't forgotten about this, but it's a very very non-trivial fix. I know the demand is high, so I'll keep it near the top of my priority list.

Well he clearly stated right above your post that it is a non-trivial fix (which means it isn't difficult) so it is just a matter of getting around to it. He clearly has a priority list because he is busy and has lots of stuff to do.

Just to give you all a window into the process, here's what I ultimately need to do:

1) All objects need a way to produce bound coordinates. These coords will have to be based on a simple setup like topdown with NORTH as the client.dir (though I think the concept would tend to extend well to other dirs and map formats), much like client.bounds is. The bound coords would also have to be animation- and transform-wise; the latter is fairly doable but the former is harder and might need to be done at a later step.

2) A series of quadtrees would be available, one for each Z-level, covering large blocks of turfs. Whenever the visual bounds changed, the object would have to change its position in the quadtree.

3) For completeness, turfs with big icons and anything with an image attached would also have to use the quadtree.

4) The routines that currently scan the client's known map cells for objs and mobs would be altered to use the quadtree instead. Because of some internal stuff, it would probably then be necessary to grab the turfs for these objects and loop through them in a list, and then loop through their contents.

MisterPerson wrote:

Non-trivial means it's difficult. Trivial means would be simple and easy.

And, 'very very non-trivial' means don't hold your breath. Don't give up on it, because I think Lummox likes a challenge, but don't hold your breath ;)

Zagros5000 wrote:

haha whoops accidentally commented on this

Haha whoops accidentally bumped a still current issue

Hahahah whooops (^:

lol yeah :D