07 Nov, 2008, Banner wrote in the 1st comment:
Votes: 0
Codebase: Modified SWR 1.0 FUSS

Original topic: http://www.smaugmuds.org/index.php?a=top...

I have an account system that basically puts all alts from one player into an account where they can be accessed. I need to make it save some data from each account so I can use it and view it later. I'm thinking it needs to save the data much like skills.dat, but I'm not quite sure how to do that. What I want to do at the moment is make it so that each IP can only create one account. I created the below function, but found that it will only use information from currently logged in accounts. I want to be able to make a command to list all accounts and hosts, as well as perform duty properly that the below function was intended for. Any help would be appreciated.

bool check_multi_account( DESCRIPTOR_DATA * d )
ACCOUNT_DATA *account;
int accnum;

for( account = first_account, accnum = 1; account; account = account->next, accnum++ )
if( !account->host )
return FALSE;

if( !str_cmp( account->host, d->host ))
return TRUE;
return FALSE;
07 Nov, 2008, David Haley wrote in the 2nd comment:
Votes: 0
I mentioned this over there, but I'll say it again here because I feel pretty strongly about the basic premise here… I don't want anybody thinking that this is something you can assume to be true especially when using it to enforce strict policy.

On SmaugMUDs, I said:
I cannot bring myself to help you on this issue because the idea that one IP == one person is wrong on so many levels that I can't possibly endorse anything that makes that assumption. :thinking:
07 Nov, 2008, Runter wrote in the 3rd comment:
Votes: 0
It sounds like you're wanting to do a few things that you should find pretty easy.

A. Maintain a list of ips (or host)
B. Check newly made accounts against said list of IPs.

So you'll have to figure out what is acceptable for what you're doing to meet those needs.
You could save those in some type of flat file, not associated with anything, and load them like you do area files into a linked list.
Refreshing your saved file each time a new account is successfully made. (Or possible deleted.)

Needless to say that's not going to be the most efficient way to handle the problem. Especially if you end up with thousands of accounts.
07 Nov, 2008, Kayle wrote in the 4th comment:
Votes: 0
Not repeating myself, nor quoting it. You'll have to read my response on Smaugmuds.
07 Nov, 2008, Runter wrote in the 5th comment:
Votes: 0
*shrug* I don't see anything wrong with him having a policy that makes people email and talk to a staff member face to face if their account's ip happens to be the same as someone else with an account already made. I'm sure he already knows he can possibly lose a player who just doesn't want to go to the trouble. It's his mud–Let him run it the way he wants.
07 Nov, 2008, David Haley wrote in the 6th comment:
Votes: 0
I don't really care how he runs his particular MUD nor am I trying to change his mind. But given that I think that this is a very dangerous assumption to make, I won't help or endorse it, and I will warn other people against making it. :smile:
07 Nov, 2008, Runter wrote in the 7th comment:
Votes: 0
Well, I will help and endorse it. So if someone needs help doing something that David won't help you with or endorse, just come to me.

edit: In fact, if you don't manage to get this working in the next day or two I'll put out a simple snippet for diku based muds to do it.
07 Nov, 2008, David Haley wrote in the 8th comment:
Votes: 0
As a final word on that note, thinking that IP addresses can be reliably tied to individuals is wrong. If you want to think it anyway, that's up to you and your problem. Runter will help you shoot yourself in the foot. :smile:

EDIT: Runter, sometimes your sarcasm is so dripping that it's hard to know what degree to take your comments at.
07 Nov, 2008, Runter wrote in the 9th comment:
Votes: 0
I'm not being sarcastic. I think it's legitimate if he wants to inconvenience people who happen to have the same IP by making them email in to get their account started.

Otherwise people just trample on his policy of 1 account. Yeah, they could get around it and make an account. Yeah, they might legitimately not be the same person just because the IP is the same.
07 Nov, 2008, quixadhal wrote in the 10th comment:
Votes: 0
Just make it CLEAR, from the start, during character creation, that this is what will happen. I don't care how a particular admin wants to impose restrictions on their game. I do care if they mistakenly believe an IP address is unique to a computer, because that's wrong, and becomes more wrong every day as more and more organizations use NAT to cut back on costs (why register multiple domains if you don't really need all those externally visible).

Personally, I'd probably just require email and/or talking to an admin from a chat channel that's accessible during login for EVERY account, not just the second from each IP. There are people who work (or go to school) and could abuse the system by using multiple IP addresses from the same machine anyways. It works both ways.
07 Nov, 2008, Banner wrote in the 11th comment:
Votes: 0
I understand that several different people could originate from one IP address. I also understand that the possibility of this happening on my small MUD is unlikely, and in the event that it does, a simple message telling people to email me to get a new account created is a simple solution. Either way, it's my MUD and I'm doing it this way, and I will do it with or without your help, so any input would be greatly appreciated in order to reduce the time I need to spend on it.

Edit: Its the same theory as multiplaying. It may be acceptable on medieval MUDs, but on SWRs, its not. Players drop items or credits for new characters they create and pick it up, or power level an alt. It's an RP enforced MUD, and we don't allow that. You need to speak with an administrator and verify that you are two separate people that originate from one IP, and this has happened several times and all parties involved were happy and excited about speaking with an Admin and getting multiplay rights. The same theory exists here.
07 Nov, 2008, Runter wrote in the 12th comment:
Votes: 0
I've never bought into the "they'll find a way" argument.

It's like gun control. (One of the few things I take a liberal stand on.)

Countries that have gun control have far less fatalities from shootings per capa than those without it. (Yes, they'll find a way. But in that case around 1000% more find a way when it's freely available.)
07 Nov, 2008, Banner wrote in the 13th comment:
Votes: 0
Runter said:
I've never bought into the "they'll find a way" argument.

It's like gun control. (One of the few things I take a liberal stand on.)

Countries that have gun control have far less fatalities from shootings per capa than those without it. (Yes, they'll find a way. But in that case around 1000% more find a way when it's freely available.)

Is this in response to my post? I don't understand what you're saying.
07 Nov, 2008, David Haley wrote in the 14th comment:
Votes: 0
He's arguing with Quix's statements about people being able to abuse the system.
07 Nov, 2008, Omega wrote in the 15th comment:
Votes: 0
My mud has a system like this, and a rule attached to it, its how I delt with the perverbial multipul accounts/connections.

Plain and simple, you are allowed 1 account, if you are caught with more then 1, both of your accounts (and all players associated) are infact destroyed. It works great because people don't want to risk getting caught and losing all their characters.. I just don't delete the ones in question ya know.

Also, to make an account there is email verification, only 1 email can be verified, so false emails makes your characters cap at level 5. Simple annoying things, and if the email does exist, and they verified, then they have to be caught the good old fashioned way.

Which is watch the socket connections: case and point, a player says he'll be back, asks another character to hold an item for him, and then he logs off, and in with another account (good ole ip watching/channel watching) and catch's the act take-place, then they are in violation, and simple as pie, both accounts get destroy'd.

Anyways, the reason I wrote this response to this thread was to show that writing crazy detection systems that are in-accurate and problematic at best, when you can just have a rule and truly ENFORCE it. If you cannot enforce your rules, my suggestion is don't have rules.

Like PK on a non-pk mud, if your coder cannot code-enforce it, and your imm's can't enforce the rule, then get rid of it.

Thats my speal.
07 Nov, 2008, quixadhal wrote in the 16th comment:
Votes: 0
Banner said:
I understand that several different people could originate from one IP address. I also understand that the possibility of this happening on my small MUD is unlikely

As you say, it's your game… I'm not trying to change your mind, just trying to be sure you understand what you're actually implementing.

Back when I was in school (where a good chunk of your target audience comes from, even today), there were a couple of groups of MUD players who tended to all join a given game at once, as a team. So, it's not as unlikely as you might think, if said group is behind a NAT firewall.

If I were at my old job, it would be trivial for me to multiplay around your system, as I'd just run two or three VM linux machines on my desktop, each of which would get a full IP address, and away I'd go. I suspect some schools also hand out full IP addresses via DHCP to anything that pops up.

An IP address is only a routable ethernet device, nothing more or less. In an ideal world, I'd require players log in via SSH and use public-key pairs instead of username/passwords. That way, I can hand out or revoke them as I see fit, and only one connection can be active for a given key pair. Alas, even moving away from TELNET seems like moving a mountain with a teaspoon. :)

That said, you might want to use the actual IP address rather than "host" for this purpose. It is more reliable, since some hosts won't have reverse lookups available.

As for the code you provided, I think you want to do
if( !account->host )

As it stands, if ANY account has a NULL host entry, it will return FALSE, even if one further down the list would have revealed a TRUE.
07 Nov, 2008, Noplex wrote in the 17th comment:
Votes: 0
Why don't you just have a command that reports all the accounts that have connected from said address and then you can manually verify by asking the person questions? What about if someone decides to connect from a wireless access point at a college (or for that matter, anywhere)?
07 Nov, 2008, David Haley wrote in the 18th comment:
Votes: 0
Manual verification is far superior, w.r.t. accuracy and dealing with problems as they actually come up, to trying to enforce this automatically, because pretty much any automatic enforcement will be broken.
07 Nov, 2008, elanthis wrote in the 19th comment:
Votes: 0
On a slight tangent, an approach that a friend of mine (who runs graphical MMOs – Freshards and RO servers and the like) prefers to help curb cheating and rule breaking is to require an invitation to join the game. When someone is caught cheating, not only does the cheater get banned, but the person who invited him gets a penalty as well. It stops random lamers from joining up and makes sure that people don't just invite a bunch of lamer friends as well.

You'd probably want to supplement it with an open invitation system at first. E.g. something like "the next 50 people to sign up get in without invitation" a couple times per year. Or possibly offer free invitations to any active member of your favorite MUD site(s). Something like how Gmail used to be when it was still requiring invites.

Back on topic, making new players ask for permission to play just isn't a keen idea. You do NOT want to annoy legitimate users with any kind of identity verification. It's easy to think that a player will see no problem in sending a quick email or something to verify that they're a different person, but in reality what happens is that people just go "this is bull****" and go play a different game. New players are the ones who aren't sure if they want to play. You need to hook them, and that means getting them into the with the absolute least amount of pain as possible.

I also question the usefulness of banning multi-playing. You can instead just make multi-playing ineffective and disadvantageous. There are ways of handling equipment and loot that makes mule and auctioneer characters useless, for example. Then, at the end of the day, if a single player makes two complete and legitimate characters and chooses to party together with both of them, who's he hurting? At absolute worst he's robbing himself of the social interaction of the MUD, but he'd probably just be soloing a single character if he couldn't multi-play. If you have a lot of players who are multi-playing when you don't want them to, the real problem may be that your MUD's design making partying annoying and that your staff are attracting a different kind of player than what you had intended, and perhaps you should look into the deeper issues of your game atmosphere. Perhaps you're attracting too many obnoxious players, or too many PKers, or too few socialites. Perhaps your partying mechanics and dungeon/area design provide little benefit to having multiple people who can simultaneously act and react with human intelligence. Maybe your loot distribution system makes it difficult to advance with other party members (.e.g., if the Wizard keeps getting good drops that the Ranger wants, with no recourse available other than hoping for good will from the lucky Wizard).
08 Nov, 2008, Banner wrote in the 20th comment:
Votes: 0
All right. I managed to get the accounts to save and load to a file called accounts.dat (as far as I can tell). I created an account and quit. Rebooted and logged back in. It recognizes the account name, but then it gets down to check the account password and somehow forgets the account data.



In CON_GET_NAME, it recognizes my account exists and asks for my password, but when I put in my password, gdb crashes with a seg fault and says the data doesn't exist.

GDB output:

How do I make it recognize account throughout the whole structure, or is it getting purged somewhere or something?