ID:137895
 
It would be nice if you could have an option to only allow people on your list to message you...
On 6/16/01 5:47 pm Foomer wrote:
It would be nice if you could have an option to only allow people on your list to message you...

Agreed. We'll be implementing a 'clique' mode that will allow you to have more control over who can page you and view your location.
In response to Tom
On 6/16/01 5:48 pm Tom wrote:
On 6/16/01 5:47 pm Foomer wrote:
It would be nice if you could have an option to only allow people on your list to message you...

Agreed. We'll be implementing a 'clique' mode that will allow you to have more control over who can page you and view your location.

Thank you. Pager spammers are annoying. Excellent responce time BTW :oP
In response to Foomer
On 6/16/01 5:48 pm Foomer wrote:

Thank you. Pager spammers are annoying. Excellent responce time BTW :oP

Note that currently you can ban annoying users by clicking on the 'Ban' button in the pager. They won't be able to see you or page you. Maybe that will help.
In response to Tom
On 6/16/01 5:50 pm Tom wrote:
On 6/16/01 5:48 pm Foomer wrote:

Thank you. Pager spammers are annoying. Excellent responce time BTW :oP

Note that currently you can ban annoying users by clicking on the 'Ban' button in the pager. They won't be able to see you or page you. Maybe that will help.

That doesn't stop them from making new keys every 30 seconds.
In response to Foomer
On 6/16/01 5:56 pm Foomer wrote:

That doesn't stop them from making new keys every 30 seconds.

Geez, that's horrible. What drives these people? Perhaps we need to seriously start considering that key quota idea, perhaps requiring email verification to enforce it.

We'll also be implementing the pager suggestions, not only for this reason, but because they will be useful to encourage private gaming.

Anyone who has input on these ideas is welcome to contribute!
In response to Tom
On 6/16/01 6:28 pm Tom wrote:
On 6/16/01 5:56 pm Foomer wrote:

That doesn't stop them from making new keys every 30 seconds.

Geez, that's horrible. What drives these people? Perhaps we need to seriously start considering that key quota idea, perhaps requiring email verification to enforce it.

We'll also be implementing the pager suggestions, not only for this reason, but because they will be useful to encourage private gaming.

Anyone who has input on these ideas is welcome to contribute!

Yeah, there's a guy hanging around SpaceTug who's fond of playing 4 or 5 different lives during the same game.

Possible solution: Link keys from the same user together somehow (IP? E-mail addy would catch a few, but not all...) so that game designers can track them collectively to prevent people from just swapping keys rapidly.

Another possible solution: Only allow users to swap keys once every half hour or so. This wouldn't completely eliminate key-swapping abuse, but it would cut into it considerably.
In response to Leftley
I think just a short wait before newly regestered keys become available would do it.


Yeah, there's a guy hanging around SpaceTug who's fond of playing 4 or 5 different lives during the same game.

Possible solution: Link keys from the same user together somehow (IP? E-mail addy would catch a few, but not all...) so that game designers can track them collectively to prevent people from just swapping keys rapidly.

Another possible solution: Only allow users to swap keys once every half hour or so. This wouldn't completely eliminate key-swapping abuse, but it would cut into it considerably.
In response to Foomer
On 6/16/01 7:43 pm Foomer wrote:
I think just a short wait before newly regestered keys become available would do it.

Or a combination of that effect coupled with a client-side restriction on keys being made - wait 30 minutes between making your keys. Otherwise, someone could send in a request for around five keys, wait 20 minutes, then start disrupting the world, and 10 minutes later, have five new keys to continue his (or her, however unlikely) terrorism.

Most people only need one key anyway. Duplicate keys are for people sharing the same computer. I think you Dantom guys should make the key-creation process a little more under your control, so you can strip out a bunch of multi-account keys that are cheating the system (whenever you periodically sweep through the index).

So if you were to see

'cool_dude1'
and
'cool_dude2'

You'd know that cool_dude2 belongs to the first owner.

Or, you could require that people enter their demographics, and not allow more than five keys to be made per person (of course, with the privacy statement that your email address won't be shared with anyone, yadda yadda.) Fraudulent usages of keys (i.e. lying about your demographics) could be punishable by law. Now THAT would put an end to it.
In response to Spuzzum
On 6/16/01 9:10 pm Spuzzum wrote:
Most people only need one key anyway.

I agree with this sentiment (and have expressed it myself for sure!) -- except that developers do need multiple keys occasionally to test things.

Though I must say that if I had to sacrifice the occasional use of multiple keys so that spammers have a harder time, it's a sacrifice I can make.
In response to Deadron
I agree with this sentiment (and have expressed it myself for sure!) -- except that developers do need multiple keys occasionally to test things.

Whoops, forgot about that.


Though I must say that if I had to sacrifice the occasional use of multiple keys so that spammers have a harder time, it's a sacrifice I can make.

Well, for one thing, it's getting easier and easier to find a temporary tester for a given game. Just announce it in the hub, and you'll get at least one connectee.
In response to Spuzzum
On 6/16/01 10:46 pm Spuzzum wrote:
I agree with this sentiment (and have expressed it myself for sure!) -- except that developers do need multiple keys occasionally to test things.

Whoops, forgot about that.

There's always the guest key... that covers quite a bit of multiple key testing purposes, although if your game utilizes complicated procedures that involve several players at once it won't help you much.

Though I must say that if I had to sacrifice the occasional use of multiple keys so that spammers have a harder time, it's a sacrifice I can make.

Well, for one thing, it's getting easier and easier to find a temporary tester for a given game. Just announce it in the hub, and you'll get at least one connectee.

Yes, but then you end up with a dozen people wandering in. Good for general playtesting, bad if you're running diagnostic tests on highly specific game elements.
In response to Leftley

Well, for one thing, it's getting easier and easier to find a temporary tester for a given game. Just announce it in the hub, and you'll get at least one connectee.

Yes, but then you end up with a dozen people wandering in. Good for general playtesting, bad if you're running diagnostic tests on highly specific game elements.

Also bad if you want to keep your game secret.

I think just general pager usr-blocking steps would work, since most GameMakers can code in effective ways to eliminate spammers.

I'm still in favor of the oh-so-wonderful mute command that allows them to hear everything they say while they're banished to their private little dungeon...

In response to Foomer
Yes, but then you end up with a dozen people wandering in. Good for general playtesting, bad if you're running diagnostic tests on highly specific game elements.

Also bad if you want to keep your game secret.

Well, this is a little convoluted, but you could probably address these concerns with a few steps:

--During testing, set world.name to "Private testing world" or something similarly generic.

--Hardcode the list of keys you'll accept, and delete any unlisted client as soon as it's created.

--You could also #define a TEST_MODE boolean that would activate or suppress these behaviors automatically. Then to switch to production mode, all you'd have to do is change a 1 to a 0.
In response to Gughunter
On 6/18/01 9:30 am Gughunter wrote:
Yes, but then you end up with a dozen people wandering in. Good for general playtesting, bad if you're running diagnostic tests on highly specific game elements.

Also bad if you want to keep your game secret.

Well, this is a little convoluted, but you could probably address these concerns with a few steps:

--During testing, set world.name to "Private testing world" or something similarly generic.

--Hardcode the list of keys you'll accept, and delete any unlisted client as soon as it's created.

--You could also #define a TEST_MODE boolean that would activate or suppress these behaviors automatically. Then to switch to production mode, all you'd have to do is change a 1 to a 0.

Here is some sample code for this:

client
New()
if (DEVELOPMENT)
if (ckey != "deadron" && \
ckey != "gazoot" && \
ckey != "gughunter")
world << "[key] attempted entry to DragonSnot development copy!"
world.log << "[key] attempted entry to DragonSnot development copy!"
return null
spawn(2)
world << "\red <H2>Running in development mode. Access only available to DDT members.</H2>"


I recommend that you definitely have the big notice that you are running in the special mode, or you'll forget to turn it off.
In response to Gughunter
On 6/18/01 9:30 am Gughunter wrote:
Yes, but then you end up with a dozen people wandering in. Good for general playtesting, bad if you're running diagnostic tests on highly specific game elements.

Also bad if you want to keep your game secret.

Well, this is a little convoluted, but you could probably address these concerns with a few steps:

--During testing, set world.name to "Private testing world" or something similarly generic.

--Hardcode the list of keys you'll accept, and delete any unlisted client as soon as it's created.

--You could also #define a TEST_MODE boolean that would activate or suppress these behaviors automatically. Then to switch to production mode, all you'd have to do is change a 1 to a 0.


If you've got a small, specific list of testers, you might as well just leave the game unlisted and invite them via pager.

Related question--I've asked this before, but don't remember seeing any answer. The reference claims that setting world.hub to -1 runtime will cause a game to stop being listed in the hub. I've never gotten this to work. Is there something else I need to be doing, or is the reference oudated/getting ahead of itself?
In response to Leftley
On 6/18/01 10:56 am Leftley wrote:

Related question--I've asked this before, but don't remember seeing any answer. The reference claims that setting world.hub to -1 runtime will cause a game to stop being listed in the hub. I've never gotten this to work. Is there something else I need to be doing, or is the reference oudated/getting ahead of itself?

Hmm .. that might be outdated since the live listing is now controlled via the client Host... button. Is there a need for this sort of thing?
In response to Tom
Related question--I've asked this before, but don't remember seeing any answer. The reference claims that setting world.hub to -1 runtime will cause a game to stop being listed in the hub. I've never gotten this to work. Is there something else I need to be doing, or is the reference oudated/getting ahead of itself?

Hmm .. that might be outdated since the live listing is now controlled via the client Host... button. Is there a need for this sort of thing?

Yes there is.
In response to Tom
On 6/18/01 12:04 pm Tom wrote:
On 6/18/01 10:56 am Leftley wrote:

Related question--I've asked this before, but don't remember seeing any answer. The reference claims that setting world.hub to -1 runtime will cause a game to stop being listed in the hub. I've never gotten this to work. Is there something else I need to be doing, or is the reference oudated/getting ahead of itself?

Hmm .. that might be outdated since the live listing is now controlled via the client Host... button. Is there a need for this sort of thing?

Well, the hub variable wouldn't need that functionality, except that I can't seem to be able to turn listing off using the Host... button. Every time I go to edit the host options, regardless of whether it's currently listed or unlisted, the check box to list it is off. And once I have listed it, it stays listed regardless of what state the check box is in when I edit my hosting options. I'm perfectly fine with random people coming into public tests--otherwise, they wouldn't be that public. But my modem is woefully inadequate for hosting, and new people coming in and downloading resources when I'm already at capacity only aggravates the problem.

Alternately, if BYOND's network code was capable of compressing all the data involved in a complex, active multiplayer action game into a couple of bits, transmitting it, and then decompressing it without any loss of data or significant use of CPU, that'd solve my problem too.
In response to Leftley
On 6/18/01 1:43 pm Leftley wrote:

Well, the hub variable wouldn't need that functionality, except that I can't seem to be able to turn listing off using the Host... button. Every time I go to edit the host options, regardless of whether it's currently listed or unlisted, the check box to list it is off. And once I have listed it, it stays listed regardless of what state the check box is in when I edit my hosting options.

Strange. I just did a simple test, and while I did see the problem with the "announce" checkbox always starting in the "off" position (will fix), whenever I edited the setting the Live! hub appeared to reflect the state correctly. For instance, I ran a test world and used "Host.." to announce it. It appeared in the hub. I then clicked "Edit..." and turned off the hosting and the listing disappeared. You are not seeing this behavior?
Page: 1 2