Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
nope, i'd keep it imo
It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
Offline
It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
I'm talking about the "can't join a room" function, not the "can't get to the room without link/friendlist" function.
suddenly random sig change
Offline
HG wrote:It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
I'm talking about the "can't join a room" function, not the "can't get to the room without link/friendlist" function.
It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
...and join a specific room...
join
Offline
Slabdrill wrote:HG wrote:It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
I'm talking about the "can't join a room" function, not the "can't get to the room without link/friendlist" function.
HG wrote:It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
HG wrote:...and join a specific room...
HG wrote:join
It's there for legacy purposes, as the room property that allows an user to search for and join a specific room is called Visible.
...an user to search for...
search for
suddenly random sig change
Offline
visible does allow the user to search for the world
thx for sig bobithan
Offline
<snip>
It is obvious that you clearly don't know how room properties and room data works in PlayerIO.
The property that allows any type of access to a room in a PlayerIO game is called Visible.
Offline
Slabbrill wrote:<snip>
It is obvious that you clearly don't know how room properties and room data works in PlayerIO.
The property that allows any type of access to a room in a PlayerIO game is called Visible.
right, but why does it have to be consistant with the internal values
suddenly random sig change
Offline
HG wrote:Slabbrill wrote:<snip>
It is obvious that you clearly don't know how room properties and room data works in PlayerIO.
The property that allows any type of access to a room in a PlayerIO game is called Visible.
right, but why does it have to be consistant with the internal values
Because it's a default property that you can't change. It's part of the room functionality.
Trying to create a property that resembles Visible but with a different name just for comfort will make the code a lot more complex.
Offline
I'm not sure how it would be more complex... Just change a couple labels from "visible" to "joinable".
Offline
I'm not sure how it would be more complex... Just change a couple labels from "visible" to "joinable".
That would be inconsistent, and bot creators that want their users to use /visible instead of a wrongly-named command will have to add extra, simply annoying checks.
Offline
You are aware that internally levels that people create are called Rooms, whilst we on the outside see Worlds right? They even changed /roomid to /worldid in the Unity client.
Is it really that hard for you to change /visible to /joinable in your bots?
Slabdrill's suggestion is great because it'll make more sense for new/normal users, which is what EE primarily consists of.
Offline
As I said on my first post, visible is there for legacy purposes. Any legacy feature should stay even if it provides inconsistency with the game-play, when it doesn't for development.
It'd still be nice to have a command that clearly specifies whether users can join, but the name joinable is ugly.
What about /allowjoin, along with /visible, both changing the same property.
And when you try to join a world with the Visible property disabled, you'd get a message like "The world you requested does not allow users to join.".
There can be a client warning when using /visible, that it can be misleading and it'd be better to use /allowjoin if you don't want users to join. This is to encourage users from using the new command, whilst leaving the old command available for those who are used to it.
Offline
You shouldn't really need the old command for any reason though, and /visible should be used for if it's visible in lobby since it makes more sense for visible to be used for if it's visible instead of being enterable.
suddenly random sig change
Offline
I'm all against removal of legacy features. They are there for a reason.
We had the old /setpos command which was deprecated, yet it was always available until a new command implementation left it useless.
Also remember, that /visible toggles any type of world accessibility. /visible false would be like doing /allowjoin false and /hidelobby false together.
Offline
As I said on my first post, visible is there for legacy purposes. Any legacy feature should stay even if it provides inconsistency with the game-play, when it doesn't for development.
Yes, I read what you said but who cares? The same can be said about magic classes. The EE staff keeps that code in the SWF for "legacy" purposes, even though it just is a waste of space. It should be changed so it is not ambiguous.
It'd still be nice to have a command that clearly specifies whether users can join, but the name joinable is ugly.
Nobody cares about what the name is, it just shouldn't be ambiguous like visible.
What about /allowjoin, along with /visible, both changing the same property.
And when you try to join a world with the Visible property disabled, you'd get a message like "The world you requested does not allow users to join.".There can be a client warning when using /visible, that it can be misleading and it'd be better to use /allowjoin if you don't want users to join. This is to encourage users from using the new command, whilst leaving the old command available for those who are used to it.
That makes it much more complex. /visible should be changed to /allowjoin or /joinable, because what we have right now is not easily distinguishable for new players.
<snip>
Also remember, that /visible toggles any type of world accessibility. /visible false would be like doing /allowjoin false and /hidelobby false together.
Obviously, why would it make it not joinable but still be listed it in the lobby?
Offline
HG wrote:What about /allowjoin, along with /visible, both changing the same property.
And when you try to join a world with the Visible property disabled, you'd get a message like "The world you requested does not allow users to join.".
There can be a client warning when using /visible, that it can be misleading and it'd be better to use /allowjoin if you don't want users to join. This is to encourage users from using the new command, whilst leaving the old command available for those who are used to it.That makes it much more complex. /visible should be changed to /allowjoin or /joinable, because what we have right now is not easily distinguishable for new players.
HG wrote:<snip>
Also remember, that /visible toggles any type of world accessibility. /visible false would be like doing /allowjoin false and /hidelobby false together.Obviously, why would it make it not joinable but still be listed it in the lobby?
/visible changes both ability to join and visibility in lobby, whilst /allowjoin would just change ability to join.
Offline
<snip>
/visible changes both ability to join and visibility in lobby, whilst /allowjoin would just change ability to join.
No, /visible would be for the lobby visibility, and /allowjoin would be for allowing users to join.
Offline
HG wrote:<snip>
/visible changes both ability to join and visibility in lobby, whilst /allowjoin would just change ability to join.No, /visible would be for the lobby visibility, and /allowjoin would be for allowing users to join.
I was talking about how the command currently works.
Offline
We do have /hidelobby which came in after /visible making "visible" not make as much sense - I'm down with giving it a new name/alias.
Thank you eleizibeth ^
I stack my signatures rather than delete them so I don't lose them
Offline
I also think this is a very good idea. /visible for the lobby and /joinable for the ability to join a world.
Offline
What about just restore the original /visible functionality and don't touch it anymore? It's messed up thanks to the "Friends Only" world join option.
Offline
No, as the world visibility has nothing to do with whether it is joinable or not.
Offline
On PlayerIO, it does. So it's better to keep compatible terms. Again, it's a legacy feature.
Offline
[ Started around 1714959513.6405 - Generated in 0.058 seconds, 12 queries executed - Memory usage: 1.72 MiB (Peak: 1.97 MiB) ]