Pager Ban.

ID:260284
 
Dec 21 2006, 8:13 pm
Ok many people really hate this thing about being pager banned from their own game. why do you guys have this... They disrespected the owner and has forced many to close Hubs until they can work their way around this issue. I seriously hope that this issue with the pager ban gets fixed and should not be allowd to useed. Leave the banning from games to the Admin's and Gm's.

- Dark Emrald
Dec 21 2006, 8:30 pm
Two points:

1) If you don't like the calibre of hosts you're getting, you shouldn't distribute your host files to them. It's pretty easy to distribute your hosting files only to those people you trust, so if you aren't taking advantage of those options you can't really blame BYOND when someone abuses the hosting privilege.

2) If a host couldn't protect his own server from people he perceived to be negative against it, no one would ever host a game.
Dec 21 2006, 9:16 pm
In addition to what Gibson said, the owner can easily make pager banning of himself/the staff useless, by the code, it isn't hard to do.
Dec 21 2006, 11:28 pm
i was barely informed of this myself but i dont think this is much of a positive, most of the best games here are no longer hosted and we dont want any more of our quality games to fall under the same category over a small issue like this, it should be fixed because we dont want to lose any more awesome games.
Dec 22 2006, 7:18 am
In response to Feodrich
If the game is that awesome, then the coders should be able to override a single procedure to not let their keys get banned, right?
Dec 24 2006, 4:06 am
 
world/IsBanned(key,address)
  .=..()
  if(.&&key=="Dark Emrald")
    .["Login"]=1
Dec 24 2006, 5:56 am
In response to Crashed
Crashed wrote:
> world/IsBanned(key,address)
>   .=..()
>   if(.&&key=="Dark Emrald")
>     .["Login"]=1
>


Rather, doing it like this: 
world/IsBanned(key)
    var/list/staff_ckeys = list("darkemrald","otherkey")
    if(!(ckey(key) in staff_ckeys)) return ..()

...should be enough.
Dec 24 2006, 6:07 am
In response to Kaioken
I'm pretty sure Crashed was hoping that he would expand on it himself, but since we're going into nitpicking...

That list should be global. As it is, you have the list being created every time world.IsBanned is called, then deleted when it goes out of scope. In popular games, this could take a very small, yet unnoticed toll on the CPU.
Dec 24 2006, 7:06 am
In response to Audeuro
It's a matter of preference. If it's global, it will always remain created, taking "valuable" (well, as valuable as the CPU time lost from creating the list :p) memory up and increasing (!!!) the object count. Actually, the most efficient way would be to get unlazy and not use a list at all (use the || operator).
Dec 24 2006, 3:25 pm
In response to Kaioken
Kaioken wrote:
It's a matter of preference.

No. If the list is temporary, it will take up CPU/RAM creating/deleting the list everytime someone connects. If the list were global, it would only use the amount of CPU nessesary to create it once and the RAM would remain constant.
Lists do not increase the object count; objects do. That sentence was complete BS.
Dec 24 2006, 6:16 pm
In response to Audeuro
Efficiency is not important, remember? Last thing you should worry about. creating a list and deleting it is not tolling the system too badly. <_<
Dec 25 2006, 2:37 am
In response to Android Data
Android Data wrote:
If the list is temporary, it will take up CPU/RAM creating/deleting the list everytime someone connects.

Yes. And after the IsBanned proc is done, it will no longer take up RAM or object count space.

If the list were global, it would only use the amount of CPU nessesary to create it once and the RAM would remain constant.

Yes. But it would take up that RAM all the time, rather than once.

Lists do not increase the object count; objects do. That sentence was complete BS.

ROFLOLMAO! To be honest, I don't know for sure if they do, but YOUR sentence is the mother of all BS. Lists ARE objects!

Kaioken wrote:
It's a matter of preference.

No.

ORLY?

What it boils down to in the end, is 'will you use the list in other procs too'. You'd normally assume that a 'staff list' would be used a few more times, but actually normally, rather than checking the 'key' only, the game should ideally test if that person is a GM/protected via checking in its own GM system, be it by loading his savefile and checking vars, or whatever. My snippet was just for demonstration, and there's not really anything wrong with it. Why the hell you make a big deal out of it is unknown to me, but whatever, hope you had your fun.
Dec 25 2006, 6:06 am
In response to Kaioken
Kaioken wrote:
Android Data wrote:
If the list is temporary, it will take up CPU/RAM creating/deleting the list everytime someone connects.

Yes. And after the IsBanned proc is done, it will no longer take up RAM or object count space.

But it's still using more CPU power everytime it needs to be created. Of course, the RAM required for one global list, and the cpu required to keep making that tiny list are both pretty insignificant and don't matter either way. However, since the staff keys is a list that would probably be accessed outside of world/IsBanned, too, it should probably be a global list.

If the list were global, it would only use the amount of CPU nessesary to create it once and the RAM would remain constant.

Yes. But it would take up that RAM all the time, rather than once.

How long is that? Does that constant RAM really matter?

Lists do not increase the object count; objects do. That sentence was complete BS.

ROFLOLMAO! To be honest, I don't know for sure if they do, but YOUR sentence is the mother of all BS. Lists ARE objects!

No, they're not. Objects are objects. Lists are lists.
Dec 25 2006, 6:35 am
In response to Airjoe
Airjoe wrote:
Kaioken wrote:
Android Data wrote:
If the list is temporary, it will take up CPU/RAM creating/deleting the list everytime someone connects.

Yes. And after the IsBanned proc is done, it will no longer take up RAM or object count space.

bla bla bla bla repeating repeating However, since the staff keys is a list that would probably be accessed outside of world/IsBanned, too, it should probably be a global list.

Maybe, maybe not. Depends how you manage your GM system, if any. Again, I just posted an independent code snippet for demonstration. I still don't get why you guys wanna waste posts about it.


How long is that?

Er. As long as the world is running.
Does that constant RAM really matter?

No.
Does the extra CPU from create-list-on-every-logon really matter?

No, they're not. Objects are objects. Lists are lists.

True. Lists are also however, objects.
Special objects, but objects.

Anyway, whatever, once more, you win and all that shizz, I don't see the need for discussing this and repeating in new posts.
Dec 25 2006, 6:41 am
In response to Kaioken
Kaioken wrote:
Maybe, maybe not. Depends how you manage your GM system, if any. Again, I just posted an independent code snippet for demonstration. I still don't get why you guys wanna waste posts about it.

I hardly find this wasting posts. We're talking design philosophy here.

How long is that?

Er. As long as the world is running.

I had meant the list, sorry.

Does that constant RAM really matter?
No.
Does the extra CPU from create-list-on-every-logon really matter?

Of course not, which I had said above. However, the point still stands that if you have a list of staff, I'm sure you won't only be using it to check if they're banned. Therefore, it should be a global list.


No, they're not. Objects are objects. Lists are lists.

True. Lists are also however, objects.
Special objects, but objects.

The hell is a special object? Lists are lists. Objects are objects.
Dec 25 2006, 6:48 am
In response to Airjoe
Airjoe wrote:
Kaioken wrote:
Maybe, maybe not. Depends how you manage your GM system, if any. Again, I just posted an independent code snippet for demonstration. I still don't get why you guys wanna waste posts about it.

I hardly find this wasting posts. We're talking design philosophy here.

Funny how you didn't comment about the first part of the quote.
It is wasting posts, because if you take a look, we're just repeating ourselves and getting nowhere. Regardless, whichever method you use doesn't really matter.

Of course not, which I had said above. However, the point still stands that if you have a list of staff, I'm sure you won't only be using it to check if they're banned. Therefore, it should be a global list.

The point still stands that you may do it differently in your game. Like checking if the ckey is in a savefile and whatnot.

The hell is a special object? Lists are lists. Objects are objects.

Right. So by that, objects are objects, and mobs are mobs, therefore mobs are not objects.
Dec 25 2006, 9:11 am
In response to Kaioken
This debate is pointless. Isbanned() called infrequently and instantiating a list takes nanoseconds. There is no appreciable time lost in doing so, nor is there appreciable memory lost keeping a single global list versus instantiating it each time. You only need to worry about such small time delays or memory chunks if the proc is called often and/or if the list has multiple instances cluttering memory. If this single list pushes you over the 65525 limit for number of lists, then you need to look elsewhere for a fix.

Also a /list IS a programming object. It has vars and procs.

As Kaioken pointed out early in the thread, the most efficient means would be to forget the list entirely and string together a long if statement with logical ORs (||). The in operator is far slower than a series of ORs and there will be no extra overhead from creating a list. Doing so will shave many nanoseconds off the IsBanned() proc, which I'm sure will be called dozens or maybe even scores of times each hour. Congratulations on your efficiency.
Dec 25 2006, 10:01 am
In response to Shadowdarke
It's about time...
Thank you.