ID:133201
 
Could world/IsBanned() be changed so it's always called for a logging-in player? Currently it isn't called when the host logs in, which is inconvenient as it makes it more annoying to test-run IsBanned() overrides (it even often confuses newbies into thinking their code doesn't work, when it normally would) and that functionality could also be useful for cases like preventing players (including the host) from multi-keying through IsBanned().

Also, (if and) while you're going about implementing that, you could also spice up world/IsBanned() a bit. I leave you the thinking.
Yeah well, I do have some things in mind. :P
  • Maybe it could include additional useful info in its arguments that is unavailable in the phase of IsBanned()-callage, such as the connecting player's BYOND version (this would alternatively let you if the player connected from telnet), gender, OS, and maybe as a complement or shout-off to control_freak, if that player is using a custom (or altered) interface of the world (this is already available in the mentioned var, but you could for example discriminate and do this dynamically in this way, by allowing 'kool' people like staff and the owner custom skins but not the other players), and maybe even if that player is using some altered snazzy DMS scripts or something, or a DMS script from the BYOND site (ok, I ran out of things to list).

    This would conveniently grant you the ability to, for example, quickly ban all females, or all *nix users. xD Joking of course... so maybe it wouldn't be as useful for rational people (other than the byond_version), but for the sake of completion perhaps? (but one may still do want to ban all neuters, for instance)
  • Could the result of IsBanned() be somehow forwarded on to client/New() if the player is granted connection, so it can be known without calling IsBanned() again? I cite this from the Reference as the clarification:

    [...] Tom was banned through some other means, and he has been allowed to login, even though he is banned. (Code in client/New() might then check IsBanned() and somehow limit his activities in the game.)

    This is potentially a pretty good idea, but you can't actually do this without manually re-calling IsBanned() with the right arguments for the player (which is kinda silly), or other methods consisting of more-roundabout-than-it-should-be silliness. If possible, client/New() should have an argument that is in practice what IsBanned() returned for that player (which could be a list with a bunch of info, or just a value like 0). Or if this is tricky for some reason, then at least a flag that is set to one value if the "Login" = 1 parameter was set (to allow a banned player to login), and to another if it was set because of a pager-ban, for completeness.


Thank you for reading kind sir, and have a great day.

Disclaimer: I wrote this up at 4 AM. This is without sleeping of course, since I'm a kool guy.
Since we're posting IsBanned() feature requests; I'll re-post the one I suggested a few months ago:

6. A parameter in IsBanned() or in its returned params that stops it from logging when a player is denied access. IsBanned is more efficient to use than Login() since it prevents the downloading of resources, mob creation, etc. But, the spam it creates in the log file gets ridiculous.
In my opinion, modifying world/IsBanned() has become useless. In fact, I'd rather have it phased out, as it's becoming useless with the new DreamDaemon banning, and I'd like to see regular pager bans not affecting games I might host.

All the features you two requested can already be done, if you just override client/New() and write your own IsBanned() proc. Just put it at the client-level like so:

client
New()
if(IsBanned(1)) del src
. = ..()
Del()
if(IsBanned()) return
. = ..()
proc
IsBanned(verbose = 0)
... //check if the user was banned
if(. && verbose) //user is banned and verbose mode is on
... //use whatever means to show a message here; could be an alert box, could be a skin window


I've found that a system such as above will work as expected, whilst world/IsBanned() has it's share of glitches; things like you said, such as the host being skipped.
In response to Falacy
Falacy wrote:
IsBanned is more efficient to use than Login() since it prevents the downloading of resources, mob creation, etc.

This is correct, but it'd be better to override client/New() anyway: mob creation hasn't taken place yet by the time this proc is called, and resource downloading will only just have been started. A disconnect caused by a ban would stop the download anyway.
In response to Android Data
Android Data wrote:
In my opinion, modifying world/IsBanned() has become useless. In fact, I'd rather have it phased out, as it's becoming useless with the new DreamDaemon banning, and I'd like to see regular pager bans not affecting games I might host.

All the features you two requested can already be done,

But the features we requested were to make modifications to world/IsBanned(). :P

if you just override client/New() and write your own IsBanned() proc. Just put it at the client-level like so:

Which is clearly different, and pretty superfluous to say as it's not saying anything new. Of course someone making such a request will prefer to use the built-in world proc instead, tailor-made for this, if you will. =P

<small>> I've found that a system such as above will work as expected,

Yeah, we'd have a problem if regular DM code arbitrarily didn't work as expected. :P</small>

whilst world/IsBanned() has it's share of glitches;

Hm, really? What glitches? And if they exist, why didn't you simply report them?

things like you said, such as the host being skipped.

That's only a single thing, and as its likely intended not a glitch.
In response to Kaioken
Kaioken wrote:
But the features we requested were to make modifications to world/IsBanned(). :P

No, the features you requested were things like the ability to check the BYOND version, which is already available.

Which is clearly different, and pretty superfluous to say as it's not saying anything new. Of course someone making such a request will prefer to use the built-in world proc instead, tailor-made for this, if you will. =P

The world/IsBanned() proc was tailor-made with only one purpose in mind: to allow the developer to allow or reject those banned through the pager to connect to their game(s).

Hm, really? What glitches? And if they exist, why didn't you simply report them?

By "glitch" I mean "missing features".

That's only a single thing, and as its likely intended not a glitch.

Intended, but a glitch, given what world/IsBanned() currently seems used for.

End conclusion is this: Modifying world/IsBanned() would be a waste of time, as it makes much more sense to check for bans in client/New(). Instead, it might be better to allow developers to give more control over resources and how they are downloaded, as that will at least have more than one purpose.
In response to Android Data
Android Data wrote:
The world/IsBanned() proc was tailor-made with only one purpose in mind: to allow the developer to allow or reject those banned through the pager to connect to their game(s).

I'm actually pretty certain that it was to stop people who are banned from coming onto the game in a very fast manner, saving resources and the like. If you can stop someone coming in before they come in and have their client object created, only to be deleted, wouldn't you?

That pager-ban bypass thing was most likely just a perk for completeness.
In response to Android Data
Android Data wrote:
No, the features you requested were things like the ability to check the BYOND version, which is already available.

Not in IsBanned(). I suppose you'd opt for removing the key and address arguments from it as well? But then again, you're not using this proc, so you could - it's not my problem, though.

The world/IsBanned() proc was tailor-made with only one purpose in mind: to allow the developer to allow or reject those banned through the pager to connect to their game(s).

Oh, Really? What's even the sense in rejecting players pager-banned again, seeing as that's done anyway? You can blatantly ignore its name, but the proc was made for conveniently checking for & banning people by using its return value, before they ever actually 'log into' the game and begin downloading resources and creating clients. Of course, nobody has to use it; but you shouldn't attempt to have others not use it. Removing it would be a rather odd matter, seeing as features actually obsolete or old with a newer equivalent stay anyway, even if they're being 'phased out' for a year or three. :P

Intended, but a glitch

Okay.

End conclusion is this: Modifying world/IsBanned() would be a waste of time, as it makes much more sense to check for bans in client/New().

Hey, fine; you can have whatever opinion you want.
Better resource control is, of course, a whole separate feature in its own right.