BV did you frack with my callsigns?

[Cadillac]

QUOTE (Puggle @ Nov 8 2007, 10:52 AM) Neither is Bacon...

BTW - Is there a way to delete ASGS nicks and/or rename hiders - ie not those listed as the main account?

ROFL /laugh.gif" style="vertical-align:middle" emoid=":lol:" border="0" alt="laugh.gif" />

[Tallon]

QUOTE (Adaven @ Nov 8 2007, 12:28 PM) Was it the Scruffy Red Monkey incident?

Nope. Scruffy Red Monkey happened long before that. That was around the time Pook disabled callsigns starting with _. I wonder if I can still log in as SRM_Tallon?

[Your_Persona]

QUOTE (Orion @ Nov 8 2007, 11:49 AM) Someone's callsign (the string of characters itself) shouldn't be linked to their identity - that's what the IP/harddrive serial/whatever else ASGS uses to identify someone is for. ASGS should not be in place to prevent people from using different names, it should be in place to prevent individuals who are banned from playing and to disallow people from modifying gameplay changing files.

I agree.

I would be interested in knowing how you think call signs should be handled and accounted for though.

[takingarms1]

I always thought the 3 callsigns thing was a bit onerous as a restriction, as was the no deleting and no changing callsigns restriction. I guess there's that much annoyance at hiders? I suppose they do allow people to stack with impunity, but surely once ranking gets ironed out this will be less of a problem?

[Orion]

QUOTE (Your_Persona @ Nov 13 2007, 11:52 PM) I agree.

I would be interested in knowing how you think call signs should be handled and accounted for though.

Store individuals in the 'Idents' table:
ID|LastIP|BanTime|Misc Computer Information ASGS Uses|

Store callsigns in the 'Callsigns' table:
ID|Idents.Id(ForeignKey)|Username|Passwordhash|Email|LastLogin|Misc Info about user|

Store individuals records in 'Records' table: <- Track what hardware components or IP an ident may have swapped out in the past?
ID|Idents.Id(ForeignKey)|PastPartType(harddrive, IP, or w/e ASGS uses)|

Store Stats in 'Stats' table:
ID|Callsigns.ID(ForeignKey)|Kills|Ejects|KillsPerGame|Etc

Keep in mind SQL is optimized for tables with lots of rows and very few columns.

[Evincar]

i think this is basically how it works, however there should be a trigger that checks if more than 3 callsigns with the same ID are present on the callsigns table, then return the primary callsign, if given the case

so the only thing impeding fact would be the trigger/procedure that checks the number of callsigns associated with an account

edit: i somehow wrote something really impossible to understand

[Orion]

QUOTE (Evincar @ Nov 14 2007, 10:21 AM) i think this is basically how it works, however there should be a trigger that checks if more than 3 callsigns with the same ID are present on the callsigns table, then return the primary callsign, if given the case

so the only thing impeding fact would be the trigger/procedure that checks the number of callsigns associated with an account

edit: i somehow wrote something really impossible to understand

What? I'm saying you shouldn't place an artificial limit on the # of callsigns you have.. and why would you use a trigger for that? You missed the point completely evincar.

[Viscur]

MMph, id be more inclined to store the user id/pw in the idents table, and anytime someone uses a callsign, you just join the 2. Otherwise, youll end up storing the same info in the callsigns table over n over again anytime someone creates a new callsign. Either that, or im misinterpreting your deffinition of "ident" and "callsign". This is why data dictionaries are useful!

Yea, i think id prefer to store all the individual info in the ident table, and then just store callsigns up in dat dar callsigns listing. The way people work around here, your going to have a huge number of rows in there with repeating info otherwise. Just make up a callsign row, use the ident id as your fk and call it good.

[Bard]

You're actually advocating that we have NO limit on hidernicks?

Even if you link accounts (for banning purposes) and keep stats tied based on ASGS identifier, it would still be abused in ridiculous ways.

It'd also make boots completely worthless. Boots have less impact on members of squads because you can play around with your callsign a tiny bit more than your average new registration, but squads tend to police that themselves.

Orion, show me a commander who's been playing for at least a year who wants to boot several dozen callsigns in a row because a player can keep re-joining anonymously. I doubt you can; It's hard enough to find someone who's been playing that long who will command a pickup game anyway, getting one who will take endless teeming streams of anonymous hiders is even more unlikely.

It sucks to not be able to play a game without people gunning for you, but you get three nicks. If you give away who you are, that's pretty much your fault. Stop hanging out on TS with you hider, stop telling other people who you are, and stop assuming noone will eventually figure it out.

Your best defense, if you REALLY want to hide, is all about you. There are a FEW people who have leaderboard issues with regards to their hiders, but that's hardly the whole population.

Grow up, deal with the consequences, and accept that you don't have any anonymity over the internet, especially in a "small" community like this one.

Thank you, drive through.

[Orion]

QUOTE (Viscur @ Nov 14 2007, 11:42 PM) MMph, id be more inclined to store the user id/pw in the idents table, and anytime someone uses a callsign, you just join the 2. Otherwise, youll end up storing the same info in the callsigns table over n over again anytime someone creates a new callsign. Either that, or im misinterpreting your deffinition of "ident" and "callsign". This is why data dictionaries are useful!

Yea, i think id prefer to store all the individual info in the ident table, and then just store callsigns up in dat dar callsigns listing. The way people work around here, your going to have a huge number of rows in there with repeating info otherwise. Just make up a callsign row, use the ident id as your fk and call it good.

No, what I'm saying is each individual person gets 1 row in the ident table, and however many rows in the 'callsign' table. Combining the two would mean either A) they're limited to 1 callsign, or you have duplicate Ident information. When you want to find which callsigns all have the same identity you just go 'select username from callsign where identId = x', then you could probably limit to unique email addresses - or 2 callsigns per email address or something.

Bard, in just about any other online community/game on the planet, someone has the freedom to make a new nickname or account. There is no actual good reason to NOT have this functionality. "What if you boot someone and they come back?" What the hell kind of problem is that? That's just a made up issue. I don't recall ever having a problem with that back in the days when there was no authentication at all - it was the hacking that was the problem.