No effect from world.visibility changes

ID:650759
 
Apr 9 2012, 4:50 pm
BYOND Version:493
Operating System:Linux
Web Browser:Firefox 12.0
Applies to:Dream Daemon
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
This could be connected with this bug report, but a few test runs seems to back up my initial belief, so I decided to file it separately.

Once you compile a world with world/visibility = 0, changes to world.visibility at runtime appear to have no actual effect on whether the world appears on the hub entry or not. This is counter to the opposite scenario, where world/visibility = 1 and toggling it to 0 does in fact cause the world to become invisible.

This bug appears to be common to all hub entries, as it happens on my test hub entry as well as the Chatters hub entry, and it dates back to at least before 493.

A modified version of my previous demonstration with the same hub entry will be sufficient. I'll post it again for clarity:

world/hub = "Audeuro.TestHub"
world/visibility = 0

mob/verb/ToggleVisibility()
        var/old_visibility = world.visibility
        var/new_visibility = !old_visibility
        world.visibility = new_visibility

        world << "Visibility toggled from [old_visibility] to [new_visibility]"


Using this snippet with that hub entry, I've been unable to get my world to become visible once it's been set to world/visibility = 0 at compile-time.
Apr 10 2012, 10:01 am
I thought of a possible way to fix this, but my tests failed. Ultimately part of the problem comes from the way the clients get updated on visibility changes, and the whole thing boils down to the fact that our hub reporting could stand to be simplified. Since I don't see changing world.visibility via code as a very common situation, I think it makes sense to defer this one.
Apr 10 2012, 10:01 am
Lummox JR changed status to 'Deferred'
Apr 10 2012, 10:33 am
That makes sense as a whole, but I guess I'm not really understanding this part:

... comes from the way the clients get updated on visibility changes ...

Shouldn't this bug also manifest itself then when world/visibility is set to 1 at compile-time, toggled to 0 at runtime and kept there for an extended period of time, then toggled back to 1, or is it (the compiled-in visibility flag) treated completely differently internally and that's why the part I left out of the context says 'partly due to [the above]'?
Apr 10 2012, 11:39 am
Changing the value at runtime does not presently send an update to the clients--but I found that updating the clients didn't really help, either, and in my tests I was seeing even worse behavior (worlds not becoming invisible again) as a result. From what I can see the world itself is updating the hub just fine in any case, it's the way the clients are reporting that seems to be problematic. As I said, our hub reporting could stand to be simplified.
Apr 10 2012, 12:00 pm
Ah, fair enough. I'll go for the alternate approach of turning visibility off where it makes sense, then, as that does work to the extent that I need it to, at least. Thanks.