Just to chip in on this - we're having this issue too, We're running BYOND 5.0 Public (Version 510.1346) on Linux (64 bit)
Descriptive Problem Summary:
/tg/'s bagil's hub entry is not updating at all because half the game thinks it should be private, and half thinks its should be public.

When you reboot after manually setting dd's privacy to public, it resets back to invisible, but the hub code still thinks it's visible, so it stays on the hub, only it doesn't update. Changes to world.status do not show, only users who were connected before the reboot and are still connected count in the listed player count.

This is still a pain in my ass.

Not being able to control visibility at runtime gets old quickly
In response to MrStonedOne
I moved this to the other thread because it looks pretty strongly to me like they're the same issue.

This is a good new piece of information! I think this might be what I was missing before that explains why I wasn't able to reproduce the issue. Maybe now that I have this information I'll be able to get further with this. I'll throw some time at testing this as soon as I get a good chance.
Reee lummox please fix
This is becoming an issue for me as well, I'd like to hide the server from the hub until it's finished starting up, but changing visibility from 0 to 1 doesn't do anything. 1 to 0 works fine though.

Also on 64-bit Linux.
The solution, if you don't mind storing the hub password in plaintext, is to clear and set the hub password var when you want to enter or leave the hub.

It takes a few minutes to propagate up to the hub, but it works and it's what /tg/ had to start doing.
I've had this problem for years, back in 2013-2014 even. I just gave up and assumed it was on my end.
Necromancy Ahoy.

I'm experiencing this issue but I noticed something with testing:

When setting visibility to 1 or 0 during runtime, Dream Daemon will reflect this in its visibility dropdown list, but the change isn't applied. world.Export() calls don't see the server and it doesn't appear on the hub.

If you click the dropdown list arrow and then click again to close without selecting a specific option (leaving it where it was) it will catch the update (though I'm unsure if not selecting anything causes it to trigger as if you selected whatever it was on before).

The workaround with the hub password is interesting, perhaps a special flag could be used to force the update?

I'm not sure I feel safe with messing around with the hub password tho.
Page: 1 2 3