I propose the addition of a flag to either the Account information or in the individual character info.
LogStatus := hidden/visible (0/1) Default would be visible (1)
This flag would prevent their name from being returned in the EnumerateOnlineCharacters (EOC) function. It could be a new member or even a CProp if the EOC function can read CProps from the core. I would rather it be a member due to Propedit being a way for unauthorized staff to gain access to the flag. This flag should also prevent the sending of logon and logoff messages as well. In otherwords, any account or character that has this flag set would be totally invisible while logging in, during and logging off the server.
My argument for this feature is it would allow us shard owners the ability to hide oureselves from people without the need to add command level checks to scripts which use the EOC function. This is particularly aimed at the shard owner and/or extremely trusted Admins in order to supervise the staff.
Adding a OnlineStatus flag to EnumerateOnlineCharacters
Come on Maud! It easy to say "Just script it". People coukd have scripted around a lot of things that were added to core. For example the addition of a realm member to the reference returned by the Target function could have been scripted around but that feature was added. The increment operators "x += y" and "x -= y" were really unnecesary since we could have easily done the same using "x := x + y" and x := x - y". It is just as easy and quite simpler to script those increments using pre 97 operators than it is to script a check into each EOC call.
The arguement against scriting it is that every new script that uses the EOC function where a supervising staff member is to remain hidden has to do this check. My thoughts were it would be easier to do it in core.
Oh and FYI I did script round it already. Because I had to since there was no feature like this. Just like I script the increments since I am not using 97 core and just like I scripted around the referemce returned by the Target function before that was added.
The arguement against scriting it is that every new script that uses the EOC function where a supervising staff member is to remain hidden has to do this check. My thoughts were it would be easier to do it in core.
Oh and FYI I did script round it already. Because I had to since there was no feature like this. Just like I script the increments since I am not using 97 core and just like I scripted around the referemce returned by the Target function before that was added.
Target realm is passed by the client to the server in the packet, so it's logical to add it (and by the way, what you scripter is conceptually different from the target().realm since target().realm cannot be trusted while your scripted realm can be trusted)
Increment operators are handy shortcuts in the language which are used in most programming languages
They are all things which are obviously useful to everyone and, more important, universal
What you are asking is something who is useful only to some scritper and completely useless for others, such as me. In my shard the visibility is a much more complex matter than just a yes/no flag, and I'm sure many other wouldn't use it because they need something different. And since both what I need and what you need can be easily (yes, easily, don't tell me this is something complex) scripted, I honestly can't see no use for its addition in the core. Add this one day, add that the other day, the core becomes a collection of features for specific shards or for a group of shards. Should you ask for something which makes possible something otherwise impossible I'd vote yes. Should you ask for something which makes better something I'd vote yes. Should you ask something which makes easy something truly complex to script, I could consinder I'd vote yes. But this time, I vote no
For what my vote is worth, of course...
Increment operators are handy shortcuts in the language which are used in most programming languages
They are all things which are obviously useful to everyone and, more important, universal
What you are asking is something who is useful only to some scritper and completely useless for others, such as me. In my shard the visibility is a much more complex matter than just a yes/no flag, and I'm sure many other wouldn't use it because they need something different. And since both what I need and what you need can be easily (yes, easily, don't tell me this is something complex) scripted, I honestly can't see no use for its addition in the core. Add this one day, add that the other day, the core becomes a collection of features for specific shards or for a group of shards. Should you ask for something which makes possible something otherwise impossible I'd vote yes. Should you ask for something which makes better something I'd vote yes. Should you ask something which makes easy something truly complex to script, I could consinder I'd vote yes. But this time, I vote no
For what my vote is worth, of course...Yes. I agree that the increment operators are shortcuts as are many of the features we see added to POL, not all, not even most but may are shortcuts. My suggestion is also a shortcut and it would benefit more than just me. I am sure there are quite a few shard operators that would take advantage of this if it were available. Plus you can't be sure that your scripts wouldn't have used something like this if it had been in POL already. Just as now people will be using the new increment features when before they did it the old way. No one can predict who will use a feature until it's there to use.
As far as the increments are concerned, even you know it takes less code to script an increment the old way than it does to script an EOC check for hidden staff. So once again I see this as a shortcut.
As far as the increments are concerned, even you know it takes less code to script an increment the old way than it does to script an EOC check for hidden staff. So once again I see this as a shortcut.
Following this logic the devs should code anything suggested in this boards... And vital fixes and much more needed improvements would never be coded. I'm sorry, but someone (not me, I'm just giving my opinion) has to pretend he can predict who will use a feature before implementing it, and thanx god someone did it in the past years, otherwise POL would be an almost unusable emulatorYukiko wrote:No one can predict who will use a feature until it's there to use.
If it is so "heavily used", why not use an Include with something like "EnumerateOnlinePlayers()" function, so that it checks "acceptable" lists etc so you don't have to have the "checks" in every script, but rather just use an include? 
I really dislike this one for some reason. No clue why, I just do
I really dislike this one for some reason. No clue why, I just do
-
Marilla
It's been a while for me, but here goes!
I don't like this one
I think the main reason is that in this case, it's very, very easy to script it (in fact, it sounds like the proposed system would make things MORE complex - not less), and there would further be no measurable performance improvement, or simplification of code as a result.
I don't like this one
I think the main reason is that in this case, it's very, very easy to script it (in fact, it sounds like the proposed system would make things MORE complex - not less), and there would further be no measurable performance improvement, or simplification of code as a result.
-
Marilla
Actually, I'm pretty sure I would never use a feature as you've described it. A scripted solution could be much more robust, and much simpler, to boot.Yukiko wrote:Plus you can't be sure that your scripts wouldn't have used something like this if it had been in POL already.
For example; What do you do when you WANT your staff members to see you online, too? Your system provides no way to handle that. How about implementing different levels of visibility based on the .cmdlevel of the player? Your system also does not handle that. In fact, your system doesn't allow you to see yourself as online. Considering the various uses of EOC, that could cause some big problems.
But the fact is, POL already has built-in the features to do basically what you want, but in a much more robust way: Simply have the scripts that list players check the .concealed property, and display people only when they are .concealed at or below the querying player's .cmdlevel. For a WWW script, simply code in that no one with .concealed == 5 is listed, if that's what you want to do.
Implementation of that sort of thing would really be a lot easier than the specific, separate, manual configuration required to set players to visible or not, according to your system. This, instead, uses an already-existing member which semantics are pretty much meant exactly for this type of situation: controlling who can 'see' someone else.