MapPack distribution:
I would suggest that the Server admins seed a torrent for the latest mappacks.
This could be a private torrent restricted to just registered T2 players.
This way the bandwidth of each server admin would distribute the load of map pack updates.
Each server admin would need to insure that they are seeding the SAME mappack distribution torrent and update as the .
If the current primary source of maps hosted on a web page would establish the "MASTER" torrent it would be a simple matter for those hosting servers to update and re-seed that torrent as it it updated.
Throttling of UL/DL rates for each server admin's ISP is also simple in this manner.
Not to mention that the community of players could also update and seed the same torrent after they DL it.
I am not savvy in scripting T2 but, could it be scripted to launch utorrent, or the local computer's bittorrent client of choice, when:
1) T2 starts (This would look like the original updater from Sierra)
or
2) When joining a server and the map is not present on the local system?
(I am not suggesting that the bittorrent client/server be embedded in the T2 server though. But that is a thought.)
I hate to mention that other game, WoW, but torrent updating seems to work pretty well for them.
Obviously I don't know what's involved in your alternative method for identifying individual humans. We're grateful for any and all anti-asshat measures, but as far as I can tell, based on the information I now have, the only effective strategy to keep our pubs alive is to block, or at least reduce, the issuance of GUIDs to unauthorized, repeat applicants or known troublemakers. As long as players can easily acquire unlimited numbers of GUIDs, we have little or no control over our own servers.
I don't think constriction on GUIDs is particularly effective, but I have a handful of alternative methods.
Firstly, human/computer interaction through keyboards and mice are really distinctive. Especially in game play, I expect that mouse moving methods used by individual players will be rather unique. There are factors such as mouse sensitivity, reaction time, over/under compensation, when in the curve of movement a weapon is fired, how the player moves with the keyboard, jumping patterns, strafing patterns. With the proper metrics for those factors, and a dynamic Bayesian network (or some other form of machine learning system), that data could be used to construct individualized and highly distinctive fingerprints for individual humans.
Secondly, the same concepts can be applied (more easily) to the text input of players. Upon a ban, a chat log database could be analyzed to create a binary categorization to identify that player's typing style. Factors for a system like that include catching common misspelled words, punctuation style, FK grade level, length of sentences, frequencies of words. These sort of classifiers are much more straightforward (and mature) than the one based on mouse/keyboard input, but they are also less concrete.
Third, you could use the crowd of players on a server to form an EigenTrust type system. Presumably admins on a server are trusted to make determinations on who are assholes. If individual players are empowered to "report" assholes, a web-of-trust sort of system could be calculated, and an admin (or AI script on the server) could make educated determinations based on those reports from trustworthy players, and maybe on the classifier mechanisms above to ban players that are disliked or unfavorable by the 'good' players.
The web-of-trust could be extended to the server level, and a system could be put in place to allow servers to exchange classifier model data, as well as aggregated trust values for the players on the server. I think the three ideas listed above, if combined, could effectively solve the problem, regardless of the number of GUIDs/IPs the 'asshole' players use.
I would seek to implement them in reverse order though. EigenTrust is really easy to implement, especially with pre-trusted admins on a server to prevent malicious collectives. The machine learning components will take longer to figure out and implement, but I could see a completely finished system for doing so being operational by May. I am an AI Ph.D. candidate, so I could do this as a research project (especially, since it is my area), and use the game for implementation and data collection.
Real problems demand real solutions. I prefer systems that are really difficult to break; if you want to work with me to produce a real solution, rather than an ineffective stop-gap by GUID constriction, I'd be happy to work with you.
Third, you could use the crowd of players on a server to form an EigenTrust type system. Presumably admins on a server are trusted to make determinations on who are assholes. If individual players are empowered to "report" assholes, a web-of-trust sort of system could be calculated, and an admin (or AI script on the server) could make educated determinations based on those reports from trustworthy players, and maybe on the classifier mechanisms above to ban players that are disliked or unfavorable by the 'good' players.
While this is a good idea in theory it would never be effective on WarLovR's server. No offense to him and he probably knows what I mean by this.
Good luck with the other two ideas, sounds like a fun project.
I don't think constriction on GUIDs is particularly effective, but I have a handful of alternative methods.
Firstly, human/computer interaction through keyboards and mice are really distinctive. Especially in game play, I expect that mouse moving methods used by individual players will be rather unique. There are factors such as mouse sensitivity, reaction time, over/under compensation, when in the curve of movement a weapon is fired, how the player moves with the keyboard, jumping patterns, strafing patterns. With the proper metrics for those factors, and a dynamic Bayesian network (or some other form of machine learning system), that data could be used to construct individualized and highly distinctive fingerprints for individual humans.
Secondly, the same concepts can be applied (more easily) to the text input of players. Upon a ban, a chat log database could be analyzed to create a binary categorization to identify that player's typing style. Factors for a system like that include catching common misspelled words, punctuation style, FK grade level, length of sentences, frequencies of words. These sort of classifiers are much more straightforward (and mature) than the one based on mouse/keyboard input, but they are also less concrete.
Third, you could use the crowd of players on a server to form an EigenTrust type system. Presumably admins on a server are trusted to make determinations on who are assholes. If individual players are empowered to "report" assholes, a web-of-trust sort of system could be calculated, and an admin (or AI script on the server) could make educated determinations based on those reports from trustworthy players, and maybe on the classifier mechanisms above to ban players that are disliked or unfavorable by the 'good' players.
The web-of-trust could be extended to the server level, and a system could be put in place to allow servers to exchange classifier model data, as well as aggregated trust values for the players on the server. I think the three ideas listed above, if combined, could effectively solve the problem, regardless of the number of GUIDs/IPs the 'asshole' players use.
I would seek to implement them in reverse order though. EigenTrust is really easy to implement, especially with pre-trusted admins on a server to prevent malicious collectives. The machine learning components will take longer to figure out and implement, but I could see a completely finished system for doing so being operational by May. I am an AI Ph.D. candidate, so I could do this as a research project (especially, since it is my area), and use the game for implementation and data collection.
Real problems demand real solutions. I prefer systems that are really difficult to break; if you want to work with me to produce a real solution, rather than an ineffective stop-gap by GUID constriction, I'd be happy to work with you.
While this is a good idea in theory it would never be effective on WarLovR's server. No offense to him and he probably knows what I mean by this.
Good luck with the other two ideas, sounds like a fun project.
Actually it would work, there's a big difference between identifying troublemakers and cheaters. Cheaters can be quite low-key, yet generate unusually high points. Assholes are obnoxious, very easy to identify. It's the gentleman cheater that poses a challenge and creates a ruckus in forum threads. Only a few will care about a banned asshole!
Actually it would work, there's a big difference between identifying troublemakers and cheaters. Cheaters can be quite low-key, yet generate unusually high points. Assholes are obnoxious, very easy to identify. It's the gentleman cheater that poses a challenge and creates a ruckus in forum threads. Only a few will care about a banned asshole!
Like I said its a good idea but I've been on the receiving end of vote kicks and a ban from the server in the past when I played under a different account, all of which were supposedly the results of reports from "trust worthy" players and admins. I don't want to knock the idea but I'm sure that some of the more hated/good players (note: I've seen many players vote kick another player just because they play well, and some of the players will vote just because everyone else is doing it too) will be victim to this in the future.
Maybe I'm not fully understanding it but doesn't this just correlate to: more reports of a player being an asshole = a ban? I have noticed that the majority of the server hates at least a handful of players. It just makes me a bit uneasy to see that if enough people dislike someone (for whatever reason, as long as a group of people decide to say a player is acting like an asshole) then they might be banned solely for that reason. I'm probably just making a big deal out of nothing but I can see this option being abused by even trust worthy players/admins if it isnt implemented in a perfect server where no one holds biases or grudges. :simma:
I'll also mention that I want assholes removed from the server too as it distracts from the game play but to me the real assholes are the ones that spend more time accusing other players of cheating and just whining in general rather than just playing the game. I kind of see this idea enabling them to continue to act this way... :mad:
Actually it would work, there's a big difference between identifying troublemakers and cheaters. Cheaters can be quite low-key, yet generate unusually high points. Assholes are obnoxious, very easy to identify. It's the gentleman cheater that poses a challenge and creates a ruckus in forum threads. Only a few will care about a banned asshole!
"High points" and "low-key" do not go hand in hand.
To Thyth: While the whole "player learning" thing is interesting, it has absolute zero chance of being effective. This is where it becomes obvious that you never played in high levels of competition. Not only are there many players with nearly the exact same style, but most good players can completely change their style for any situation. And yes, what I means by "style" does include how they move, how they react, and basically everything else you just named.
It might work on the average noob who plays exactly the same way at all times because he never learned to do anything else, but competitive players have long since evolved past this "single play style" concept.
Do you have Ph.D. in computer science with an emphasis in machine learning? Is that a no? How about you leave what is possible and what isn't possible in that area to someone with experience?
Your hand-waving/bullshit about why it won't work is not sufficient evidence that the idea will not work. I didn't spell out factor measurement in my description. Had I done so, maybe you would have a case, but it's obvious that you have no experience in this area, so you have zero chance of being correct. Come up with an argument that will hold water (i.e. concrete statements), and maybe I'll be interested; otherwise, I think you'll find yourself more at home here.
Like I said its a good idea but I've been on the receiving end of vote kicks and a ban from the server in the past when I played under a different account, all of which were supposedly the results of reports from "trust worthy" players and admins. I don't want to knock the idea but I'm sure that some of the more hated/good players (note: I've seen many players vote kick another player just because they play well, and some of the players will vote just because everyone else is doing it too) will be victim to this in the future.
Maybe I'm not fully understanding it but doesn't this just correlate to: more reports of a player being an asshole = a ban? I have noticed that the majority of the server hates at least a handful of players. It just makes me a bit uneasy to see that if enough people dislike someone (for whatever reason, as long as a group of people decide to say a player is acting like an asshole) then they might be banned solely for that reason. I'm probably just making a big deal out of nothing but I can see this option being abused by even trust worthy players/admins if it isnt implemented in a perfect server where no one holds biases or grudges. :simma:
I'll also mention that I want assholes removed from the server too as it distracts from the game play but to me the real assholes are the ones that spend more time accusing other players of cheating and just whining in general rather than just playing the game. I kind of see this idea enabling them to continue to act this way... :mad:
I think with this rebirth of Tribes2 you should start your own server and run it as you see fit. Clearly you have the skills to run and administrate a server, so you would only be helping keep the T2 community alive. Additionally, you would no longer have to deal with persecution by players or otherwise.
And with this new and better administrated server you can fill it with players who are bound to believe (through your leadership) that your server is better than =Rebles= is, was, or will be.
Do you have Ph.D. in computer science with an emphasis in machine learning? Is that a no? How about you leave what is possible and what isn't possible in that area to someone with experience?
Your hand-waving/bullshit about why it won't work is not sufficient evidence that the idea will not work. I didn't spell out factor measurement in my description. Had I done so, maybe you would have a case, but it's obvious that you have no experience in this area, so you have zero chance of being correct. Come up with an argument that will hold water (i.e. concrete statements), and maybe I'll be interested; otherwise, I think you'll find yourself more at home here.
Ok then, you implement your learning system; I'll teach people how to circumvent it.
I think with this rebirth of Tribes2 you should start your own server and run it as you see fit. Clearly you have the skills to run and administrate a server, so you would only be helping keep the T2 community alive. Additionally, you would no longer have to deal with persecution by players or otherwise.
And with this new and better administrated server you can fill it with players who are bound to believe (through your leadership) that your server is better than =Rebles= is, was, or will be.
I don't see how your post answers anything that was in my post. Jumpo, it's not like I'm pulling all of this out of my ass. It was a situation that I was in - Fact. Is it a situation that happens a lot? Nope. Im just using myself as an example to show that the idea isnt exactly fool proof in its current state. I dont believe I have ever been persecuted by players and Im not trying to protect myself, its just that certain admins (accidentally?) mislead players into believing what they want them to believe without regard to blatant evidence and proof that contradicts them (Im not saying its you ).
The possibility exists and given that many players in the v2 community generally dislike classic players and vice versa I think that hypothetically what I mentioned in my post can very well happen. I cant fully argue this point without seeing it in action and to my knowledge this has never been done before so my experience with the players in the Rebels server is all I can go by. Hey if the idea works, awesome! That means less time whining and more time to play an enjoyable game, I dont see that as a reality though. I'm just arguing it incase there are some other ways to go about handling it. No harm in discussing it, right?
Also, if I were to start my own server it would be Classic, not v2.
you can only fool it for so long before it hunts you down and rapes you (er, so to speak) as very quickly you would run out of ideas... thus it would see a behavioural pattern developing and as was said earlyer in my post, rape you.
I don't see how your post answers anything that was in my post. Jumpo, it's not like I'm pulling all of this out of my ass. It was a situation that I was in - Fact. Is it a situation that happens a lot? Nope. Im just using myself as an example to show that the idea isnt exactly fool proof in its current state. I dont believe I have ever been persecuted by players and Im not trying to protect myself, its just that certain admins (accidentally?) mislead players into believing what they want them to believe without regard to blatant evidence and proof that contradicts them (Im not saying its you ).
The possibility exists and given that many players in the v2 community generally dislike classic players and vice versa I think that hypothetically what I mentioned in my post can very well happen. I cant fully argue this point without seeing it in action and to my knowledge this has never been done before so my experience with the players in the Rebels server is all I can go by. Hey if the idea works, awesome! That means less time whining and more time to play an enjoyable game, I dont see that as a reality though. I'm just arguing it incase there are some other ways to go about handling it. No harm in discussing it, right?
Also, if I were to start my own server it would be Classic, not v2.
It's not up to me to answer your post, It's Thyths idea and I have no idea how he would implement it. Also, I can not explain why it would or would not work, because I can not read his mind.
I'm just offering you a solution. A wonderful solution to all your problems. I bet if I went through posts on v2rebellion, or looked through demos from in the server I could find 10-15 former classic players who say "I only play in Rebels because it is the only server that is populated". Think about that, 10-15 people! That's a descent sized game right there. Clearly there is a niche in the market, and one that you could fill. That's what any good business man would do.
We've discussed the auto-downloading of maps a bit before, and think it would be nice option to have. Once the patch is released there will be an interface supporting the transfers for it to be built upon, and I'd be all for giving it a shot.
An interesting idea that's been mentioned is to put together an entire ingame download center accessable from a tab. The player could be given a variety of sections to choose from, where they can download the maps or textures or scripts they want, and view information on each file.
On joining a server, the game could run the mission through to see if it exists locally, and if not, check if it's available to download from the online repository.
I don't think direct server-to-client transfers would come in to play, but it wouldn't be too far-fetched to have the option for the server to send a mirror address for files only available there. A player could be given a series of preferences to toggle it on and off, allow downloads only from favourited servers and et cetera.
The only real problem is with vl2 files since they'd require a restart of the game to be read inside, but I'm sure if we do get something together we could figure something out.
You know the best way to stop people from hurting your server is to take away their weapons. Just about every exploit can be stopped. The ones that can't be stopped are undetectable anyway, so even if you try to apply the idea of banning the cheaters instead of stopping the cheat, you could be banning an innocent person who is just really good.
Hey thyth Do you have Ph.D. in computer science with an emphasis in machine learning? just wondering
At any rate, to all the naysayers about thyth's incredibly complicated heuristics system, I just wanted to say that I have complete faith in his abilities to pull it off and to do so in a timely fashion. I think his previous work with the new authentication servers speaks to this effect.
I am an AI Ph.D. candidate, so I could do this as a research project (especially, since it is my area), and use the game for implementation and data collection.
I don't really like bringing credentials into the picture, since they often contribute only to an appeal to authority rather than showing genuine ability in an area. This is especially true with paper certifications like A+/CCNA/MS Cert/et cetra; they are largely meaningless in the context of implementing a system as discussed in this thread. I brought that credential up only because a user identification system of heuristics requires some rather complex techniques that are beyond the reach of even most college graduates in computer science.
Regarding map/resource transfers...
I could probably find the volume file loading code and expose a function in the script system to rescan while running. However, there is a potential set of security problems with arbitrary resource downloads from within volume files. Even maps are potentially dangerous, since a map is really just an executable script file. I propose having a centralized repository of verified volume file resources, and servers communicate which of those volume resources are used by the server.
The verification process would simply be determining that the included scripts/maps don't include malicious backdoors/functions, and annotating the types of content included in the volume (maps/terrains/interiors/models/textures/sounds). This information would then be provided to the client so that they can make individualized decisions on whether they want to download the volume. Centralizing it would also remove the necessity to open additional ports on the server for out-of-band transfers, as well as allow all bandwidth on the server to be used for providing gameplay. It also provides some degree of accountability -- if someone continually provides malicious files, we can simply ignore future requests from that person.
Verification can be semi-automated. It's really difficult to include a malicious payload in an image, shape, terrain, interior shape, sound. Maps can be statically analyzed to verify they are not doing anything beyond invoking object construction. Packs containing those sorts of things could be processed automatically. Script analysis can check for potentially dangerous calls (eval, call, collapseEscape, schedule), but automated analysis for "malicious" versus "safe" is intractable, so a human would still need to read a script and make (at least partially subjective) determinations on safety.
In any case... having Ruby in the game enables us to do a lot of really exciting new things.
Real problems demand real solutions. I prefer systems that are really difficult to break; if you want to work with me to produce a real solution, rather than an ineffective stop-gap by GUID constriction, I'd be happy to work with you.
Why not employ GUID constriction in addition to alternative methods? If we have to choose one method, I strongly favor GUID constriction, and I'll give my reasons below. Obviously we'd need your help setting up a separate Rebels authentication server, and I'm not sure we'd ever be able to reciprocate.
I understand you have heavy demands on your time, and can't devote as much as you'd like to all segments of the T2 community.
Tribes 2 GUIDs have always been constricted, first economically and later by a limited supply of keys.
Reasons to implement (actually, continue) GUID constriction:
1. Allows server hosts more control over who plays on their servers and under what conditions.
2. Unique player identifiers could be personal data such as: verifiable name, address, phone number, email, traceable IP, etc, in exchange for 2 or 3 initial GUIDs plus later issuance of a limited number of additional GUIDs. Indexing applicant IPs by metro codes might be an effective IP correlation tool.
3. Identifying problem players and banning their accounts after they have stockpiled GUIDs would be a sisyphean task, e.g.: banning one player requires a sizable expenditure of time and effort by all involved; first we have to build a case against a player unless we're able to catch him red-handed, then I have to execute judgment by editing server files and records, then document the ban and reasons for it, and then find a chance to reset the server to make the ban effective. It often costs us gallons of blood, sweat, and tears to ban one pathetic lowlife, who responds by changing his IP in 30 seconds and returning to the game server in however much time it takes to acquire another GUID. Rinse and repeat, all day, every day, resulting in endless grief and frustration for both players and admins, multiplied by the number of career asshats currently pulling their shift on the server at any given time, until the server folds.
4. I'm concerned that alternative methods 1 and 2 might lag a full server, depending on how data would be harvested.
Sounds like referral codes would be better for your situation. Player A who is 'trusted' can give X referral codes to other players. If Player B, C, D... Z are all really player A sibyls, you can terminate the entire referred tree at Player A, thus terminating A to Z in the process.
If referral codes registration is mandatory to play on your server, that would rather easily control new players. Since all players have cryptographic keypairs under this new authentication system, a referral code "endorsement" can be done cryptographically and securely through an RSA-sign operation.
This would be a nice system to implement in the authentication server as a whole, but I think it would be logistically... very complicated for players who aren't already connected to someone in the group. By the way... Google did this for gmail at first, so they could harvest relationships between the first people that joined while it was in alpha and early beta.
I'd be willing to consider constraining registration through referral if there are some good suggestions on how to deal with getting to critical mass.
I don't see how your post answers anything that was in my post. Jumpo, it's not like I'm pulling all of this out of my ass. It was a situation that I was in - Fact. Is it a situation that happens a lot? Nope. Im just using myself as an example to show that the idea isnt exactly fool proof in its current state. I dont believe I have ever been persecuted by players and Im not trying to protect myself, its just that certain admins (accidentally?) mislead players into believing what they want them to believe without regard to blatant evidence and proof that contradicts them (Im not saying its you ).
The possibility exists and given that many players in the v2 community generally dislike classic players and vice versa I think that hypothetically what I mentioned in my post can very well happen. I cant fully argue this point without seeing it in action and to my knowledge this has never been done before so my experience with the players in the Rebels server is all I can go by. Hey if the idea works, awesome! That means less time whining and more time to play an enjoyable game, I dont see that as a reality though. I'm just arguing it incase there are some other ways to go about handling it. No harm in discussing it, right?
Also, if I were to start my own server it would be Classic, not v2.
Hybrid, your "PALS" started that whole V2 vs Classic bullshit! Your buddy Kryand himself, in this website made his own comments about how he dislikes V2, like anyone here cares about V2 or classic. Dude nobody else cares, it's your buddies that keep this crap going. Everyone else just wants the game fixed so they can get back to doing what they want to do.
Those that play construction will continue to do that and whatever else they are interested in. Those that love base will continue to play base. Those that enjoy v2 will continue, and so on and so on. Some cross mod play will occur; this has always been the case, but this crap with your friends needs to stop. All you/ they are going to do is cause peeps to avoid ya'll like the plague. Their attitude will drive any new bloods away cause they aren't fun to be around; maybe for you, but to the majority they come off like assholes. Noobs will gather where the "FUN and COOL" people are, those that don't carry attitude.
They are giving Classic and competition a bad name!
no, we've all our part to play for screwing t2 over, the way i see it is if you wish to argue go outside, if you wish to play, then come in hang round and have a cold one on the hous (so to speak) the reason i say we have all a part to play in screwing t2 over is that unless we can resolve our differences properly and preferably in a trolless environment, we will tear limbs off each other until we cannot move, and thats bad, REAL BAD, because, and i know for a fact, most new players only feel accepted in a friendly environment, if they hear growling left right and center, they will scatter... and if it carrrys on ive a feeling t2 will scatter too
Some of the map concerns for including malicious code inside a map file are why I think it would be best for an auto-downloader to only download the .ter and .dts files. Most maps don't have anything besides those to make them client-side, though I guess some maps might have some other weird things. Also this isn't even the main problem I had in mind. I think we'd also have to look out for someone trying to greatly lag a server by finding a way to send many download requests for the files at once.
Also, Krash's idea for an in-game "Downloads" tab is probably the best one yet as far as the common client-side map packs go.
Sounds like referral codes would be better for your situation.
If we set up a separate Rebels authentication server we could screen applicants by personal data or a referral code system. However, if I understand correctly how the referrals system works, referring players would be held responsible for a referred player's bad behavior. I'm not sure how many players would be willing to accept that responsibility. Not many, I would guess.
If the download process, whatever form if may take, does not take advantage of a file swarming or bittorrent protocol, I believe you are going to see huge issues.
A single mirror would still have to take the load of an entire download of a mappack to each host requesting the download.
Instead, a torrent will distribute this load amongst all seeders with complete or even partial completed downloads.
And again I mention the throttling and private seed functionality.
So are they making a new Tribes? If they are, I hope there is a construction mod. Or is their a construction mod in Tribes 3?
Also, I got the terrible, terrible c0000005 error. Maybe someone help? =(
Oh, and Tribes 2 servers isn't working at the moment, (or a couple a weeks ago..) is it not updating cause the patch isn't finish or is it something else? The computers that I have
that got Tribes 2 isn't working! Well one works for solo mode and the other doesn't work
entirely. And the servers are shutting down soon. wow. Talk about bad karma. -_-'
l
l
V
REPLAY PLZ!
Hey! Is the severs working for you at the moment? I'm having *sniff* a little problem getting to the Online servers.
The Tribes 2 Online servers are not working right now. Is it the update or something else? Please reply!
The master server has been down since teh beginning of the month.
Thyth is working on a new master server. Read some of this thread and it'll tell you about our temporary fix untill the new system is ready.
The official login and listing servers shut down for good on November 3rd. Other online features, such as the browsers and SierraUp launcher have not been functional for quite a long time.
This thread is discussing a patch we're working on that will allow players to create accounts and log in to the game, and in time bring back other features. Currently, players have to resort to playing in "offline" (Solo/LAN) mode, using listing scripts such as the one you can find in the construct section of the forums.
If you're having problems with unhandled exceptions, feel free to make a new thread with details and we'll help as best we can from the information you've got.
However, if I understand correctly how the referrals system works, referring players would be held responsible for a referred player's bad behavior. I'm not sure how many players would be willing to accept that responsibility. Not many, I would guess.
It is not so much a responsibility for bad behavior as it is a constriction on account generation. If you refer 30 accounts, and 2 or 3 end up being malicious players, I think it is a reasonable conclusion that you are not malicious, and only the 2 or 3 malicious players would be banned. On the other hand, if you refer 300 accounts, and 290 of them are malicious, chances are, you created 290 accounts with referrals to your original, and you+your sub-tree should be banned. This will present a slight problem for the remaining 10 valid users, who will need to acquire new referrals from a more reputable player to get out of the banned subtree.
If the referral tree is viewable by all players (i.e. online), then a user could evaluate a reference before asking for a referral from that reference, and a user could also see what reputation each sub-tree has (assuming servers are willing to share banlists).
I think it would be a lot more difficult to abuse this sort of system, and I doubt it would be any more difficult to implement than a separate registration system. The only logistical concern is reaching critical mass with trusted reference players. Once there is sufficient critical mass, I think it would be easiest to use from the server administration and signup process than anything else.
I'll be thinking about and discussing possible implementation details for a system like that, but keep in mind that this will mean rewriting parts of the authentication server, and it will delay launch to include any sort of registration constriction system.
Instead, a torrent will distribute this load amongst all seeders with complete or even partial completed downloads.
And again I mention the throttling and private seed functionality.
FTP or HTTP doesn't cut it anymore people.
FTP/HTTP doesn't cut it if you have a large swarm of users attempting to access the same resource at once. For high popularity files, where you might have 30,000 concurrent download attempts, a traditional centralized infrastructure would fail.
The largest T2 game servers probably have 100 unique users per day. Most of these users will only need to download resources from the server once. Most of these resources will be small -- really large map packs don't often exceed 100 MB. If 100 users need 100 MB each in a day (i.e. launch day), the HTTP server would expend 10 GB in that day to transfer those resources. I think that is perfectly within the capabilities of a typical HTTP infrastructure.
If you strongly disagree, then feel free to implement bit-torrent, or a similar protocol in Ruby. Since most users are not technically savvy (and the terms 'NAT' and 'port forward' are blasphemous sorcery), I would strongly recommend using NAT traversal techniques, and a STUN server for establishing peer connectivity. If the implementation is up to my standard, I'd be willing to consider including it as part of a later patch version.
Referrals sound interesting, but it seems like it would pretty hard for any genuinely new player to get into the fold. How will reputable players get to know the new player to determine that he's worth referring? If referrals are given out to just anyone, then I think anyone willing to change their IP 50 times and make new accounts would be willing to spend a little bit more time and get easy referrals for all of them. If you can't play on the server without being referred, genuinely new players wouldn't be able to find referrals since most Rebels players refuse to play on any other server. And of course, if non-referred players are allowed any access, malicious people will likely be able to exploit that in some way. On the other hand, this is similar to how Rebels already restricts their forum access, except WarlovR is effectively the only one who can give referrals. Anyway, it'll be fun to see how it's implemented.
As for the map pack downloads, etc. you could always have mirrors. That would lower the theoretical 10 GB to one web server to maybe 2.5 GB over 4 web servers. While torrents are elite and all, it does seem like it would be really complicated and annoying to implement. If it was a matter of simply grabbing an already-made script and setting it up, then maybe it'd be worth it, but I'm sure it wouldn't be anywhere near that simple. I'm sure it would be a lot better for everyone overall if we just stick with HTTP and FTP.
Comments
I would suggest that the Server admins seed a torrent for the latest mappacks.
This could be a private torrent restricted to just registered T2 players.
This way the bandwidth of each server admin would distribute the load of map pack updates.
Each server admin would need to insure that they are seeding the SAME mappack distribution torrent and update as the .
If the current primary source of maps hosted on a web page would establish the "MASTER" torrent it would be a simple matter for those hosting servers to update and re-seed that torrent as it it updated.
Throttling of UL/DL rates for each server admin's ISP is also simple in this manner.
Not to mention that the community of players could also update and seed the same torrent after they DL it.
I am not savvy in scripting T2 but, could it be scripted to launch utorrent, or the local computer's bittorrent client of choice, when:
1) T2 starts (This would look like the original updater from Sierra)
or
2) When joining a server and the map is not present on the local system?
(I am not suggesting that the bittorrent client/server be embedded in the T2 server though. But that is a thought.)
I hate to mention that other game, WoW, but torrent updating seems to work pretty well for them.
Firstly, human/computer interaction through keyboards and mice are really distinctive. Especially in game play, I expect that mouse moving methods used by individual players will be rather unique. There are factors such as mouse sensitivity, reaction time, over/under compensation, when in the curve of movement a weapon is fired, how the player moves with the keyboard, jumping patterns, strafing patterns. With the proper metrics for those factors, and a dynamic Bayesian network (or some other form of machine learning system), that data could be used to construct individualized and highly distinctive fingerprints for individual humans.
Secondly, the same concepts can be applied (more easily) to the text input of players. Upon a ban, a chat log database could be analyzed to create a binary categorization to identify that player's typing style. Factors for a system like that include catching common misspelled words, punctuation style, FK grade level, length of sentences, frequencies of words. These sort of classifiers are much more straightforward (and mature) than the one based on mouse/keyboard input, but they are also less concrete.
Third, you could use the crowd of players on a server to form an EigenTrust type system. Presumably admins on a server are trusted to make determinations on who are assholes. If individual players are empowered to "report" assholes, a web-of-trust sort of system could be calculated, and an admin (or AI script on the server) could make educated determinations based on those reports from trustworthy players, and maybe on the classifier mechanisms above to ban players that are disliked or unfavorable by the 'good' players.
The web-of-trust could be extended to the server level, and a system could be put in place to allow servers to exchange classifier model data, as well as aggregated trust values for the players on the server. I think the three ideas listed above, if combined, could effectively solve the problem, regardless of the number of GUIDs/IPs the 'asshole' players use.
I would seek to implement them in reverse order though. EigenTrust is really easy to implement, especially with pre-trusted admins on a server to prevent malicious collectives. The machine learning components will take longer to figure out and implement, but I could see a completely finished system for doing so being operational by May. I am an AI Ph.D. candidate, so I could do this as a research project (especially, since it is my area), and use the game for implementation and data collection.
Real problems demand real solutions. I prefer systems that are really difficult to break; if you want to work with me to produce a real solution, rather than an ineffective stop-gap by GUID constriction, I'd be happy to work with you.
Good luck with the other two ideas, sounds like a fun project.
Actually it would work, there's a big difference between identifying troublemakers and cheaters. Cheaters can be quite low-key, yet generate unusually high points. Assholes are obnoxious, very easy to identify. It's the gentleman cheater that poses a challenge and creates a ruckus in forum threads. Only a few will care about a banned asshole!
Maybe I'm not fully understanding it but doesn't this just correlate to: more reports of a player being an asshole = a ban? I have noticed that the majority of the server hates at least a handful of players. It just makes me a bit uneasy to see that if enough people dislike someone (for whatever reason, as long as a group of people decide to say a player is acting like an asshole) then they might be banned solely for that reason. I'm probably just making a big deal out of nothing but I can see this option being abused by even trust worthy players/admins if it isnt implemented in a perfect server where no one holds biases or grudges. :simma:
I'll also mention that I want assholes removed from the server too as it distracts from the game play but to me the real assholes are the ones that spend more time accusing other players of cheating and just whining in general rather than just playing the game. I kind of see this idea enabling them to continue to act this way... :mad:
To Thyth: While the whole "player learning" thing is interesting, it has absolute zero chance of being effective. This is where it becomes obvious that you never played in high levels of competition. Not only are there many players with nearly the exact same style, but most good players can completely change their style for any situation. And yes, what I means by "style" does include how they move, how they react, and basically everything else you just named.
It might work on the average noob who plays exactly the same way at all times because he never learned to do anything else, but competitive players have long since evolved past this "single play style" concept.
Your hand-waving/bullshit about why it won't work is not sufficient evidence that the idea will not work. I didn't spell out factor measurement in my description. Had I done so, maybe you would have a case, but it's obvious that you have no experience in this area, so you have zero chance of being correct. Come up with an argument that will hold water (i.e. concrete statements), and maybe I'll be interested; otherwise, I think you'll find yourself more at home here.
I think with this rebirth of Tribes2 you should start your own server and run it as you see fit. Clearly you have the skills to run and administrate a server, so you would only be helping keep the T2 community alive. Additionally, you would no longer have to deal with persecution by players or otherwise.
And with this new and better administrated server you can fill it with players who are bound to believe (through your leadership) that your server is better than =Rebles= is, was, or will be.
Ok then, you implement your learning system; I'll teach people how to circumvent it.
The possibility exists and given that many players in the v2 community generally dislike classic players and vice versa I think that hypothetically what I mentioned in my post can very well happen. I cant fully argue this point without seeing it in action and to my knowledge this has never been done before so my experience with the players in the Rebels server is all I can go by. Hey if the idea works, awesome! That means less time whining and more time to play an enjoyable game, I dont see that as a reality though. I'm just arguing it incase there are some other ways to go about handling it. No harm in discussing it, right?
Also, if I were to start my own server it would be Classic, not v2.
It's not up to me to answer your post, It's Thyths idea and I have no idea how he would implement it. Also, I can not explain why it would or would not work, because I can not read his mind.
I'm just offering you a solution. A wonderful solution to all your problems. I bet if I went through posts on v2rebellion, or looked through demos from in the server I could find 10-15 former classic players who say "I only play in Rebels because it is the only server that is populated". Think about that, 10-15 people! That's a descent sized game right there. Clearly there is a niche in the market, and one that you could fill. That's what any good business man would do.
An interesting idea that's been mentioned is to put together an entire ingame download center accessable from a tab. The player could be given a variety of sections to choose from, where they can download the maps or textures or scripts they want, and view information on each file.
On joining a server, the game could run the mission through to see if it exists locally, and if not, check if it's available to download from the online repository.
I don't think direct server-to-client transfers would come in to play, but it wouldn't be too far-fetched to have the option for the server to send a mirror address for files only available there. A player could be given a series of preferences to toggle it on and off, allow downloads only from favourited servers and et cetera.
The only real problem is with vl2 files since they'd require a restart of the game to be read inside, but I'm sure if we do get something together we could figure something out.
Yeah, that's the whole idea.
At any rate, to all the naysayers about thyth's incredibly complicated heuristics system, I just wanted to say that I have complete faith in his abilities to pull it off and to do so in a timely fashion. I think his previous work with the new authentication servers speaks to this effect.
Regarding map/resource transfers...
I could probably find the volume file loading code and expose a function in the script system to rescan while running. However, there is a potential set of security problems with arbitrary resource downloads from within volume files. Even maps are potentially dangerous, since a map is really just an executable script file. I propose having a centralized repository of verified volume file resources, and servers communicate which of those volume resources are used by the server.
The verification process would simply be determining that the included scripts/maps don't include malicious backdoors/functions, and annotating the types of content included in the volume (maps/terrains/interiors/models/textures/sounds). This information would then be provided to the client so that they can make individualized decisions on whether they want to download the volume. Centralizing it would also remove the necessity to open additional ports on the server for out-of-band transfers, as well as allow all bandwidth on the server to be used for providing gameplay. It also provides some degree of accountability -- if someone continually provides malicious files, we can simply ignore future requests from that person.
Verification can be semi-automated. It's really difficult to include a malicious payload in an image, shape, terrain, interior shape, sound. Maps can be statically analyzed to verify they are not doing anything beyond invoking object construction. Packs containing those sorts of things could be processed automatically. Script analysis can check for potentially dangerous calls (eval, call, collapseEscape, schedule), but automated analysis for "malicious" versus "safe" is intractable, so a human would still need to read a script and make (at least partially subjective) determinations on safety.
In any case... having Ruby in the game enables us to do a lot of really exciting new things.
Why not employ GUID constriction in addition to alternative methods? If we have to choose one method, I strongly favor GUID constriction, and I'll give my reasons below. Obviously we'd need your help setting up a separate Rebels authentication server, and I'm not sure we'd ever be able to reciprocate.
I understand you have heavy demands on your time, and can't devote as much as you'd like to all segments of the T2 community.
Tribes 2 GUIDs have always been constricted, first economically and later by a limited supply of keys.
Reasons to implement (actually, continue) GUID constriction:
1. Allows server hosts more control over who plays on their servers and under what conditions.
2. Unique player identifiers could be personal data such as: verifiable name, address, phone number, email, traceable IP, etc, in exchange for 2 or 3 initial GUIDs plus later issuance of a limited number of additional GUIDs. Indexing applicant IPs by metro codes might be an effective IP correlation tool.
3. Identifying problem players and banning their accounts after they have stockpiled GUIDs would be a sisyphean task, e.g.: banning one player requires a sizable expenditure of time and effort by all involved; first we have to build a case against a player unless we're able to catch him red-handed, then I have to execute judgment by editing server files and records, then document the ban and reasons for it, and then find a chance to reset the server to make the ban effective. It often costs us gallons of blood, sweat, and tears to ban one pathetic lowlife, who responds by changing his IP in 30 seconds and returning to the game server in however much time it takes to acquire another GUID. Rinse and repeat, all day, every day, resulting in endless grief and frustration for both players and admins, multiplied by the number of career asshats currently pulling their shift on the server at any given time, until the server folds.
4. I'm concerned that alternative methods 1 and 2 might lag a full server, depending on how data would be harvested.
If referral codes registration is mandatory to play on your server, that would rather easily control new players. Since all players have cryptographic keypairs under this new authentication system, a referral code "endorsement" can be done cryptographically and securely through an RSA-sign operation.
This would be a nice system to implement in the authentication server as a whole, but I think it would be logistically... very complicated for players who aren't already connected to someone in the group. By the way... Google did this for gmail at first, so they could harvest relationships between the first people that joined while it was in alpha and early beta.
I'd be willing to consider constraining registration through referral if there are some good suggestions on how to deal with getting to critical mass.
Hybrid, your "PALS" started that whole V2 vs Classic bullshit! Your buddy Kryand himself, in this website made his own comments about how he dislikes V2, like anyone here cares about V2 or classic. Dude nobody else cares, it's your buddies that keep this crap going. Everyone else just wants the game fixed so they can get back to doing what they want to do.
Those that play construction will continue to do that and whatever else they are interested in. Those that love base will continue to play base. Those that enjoy v2 will continue, and so on and so on. Some cross mod play will occur; this has always been the case, but this crap with your friends needs to stop. All you/ they are going to do is cause peeps to avoid ya'll like the plague. Their attitude will drive any new bloods away cause they aren't fun to be around; maybe for you, but to the majority they come off like assholes. Noobs will gather where the "FUN and COOL" people are, those that don't carry attitude.
They are giving Classic and competition a bad name!
Also, Krash's idea for an in-game "Downloads" tab is probably the best one yet as far as the common client-side map packs go.
If we set up a separate Rebels authentication server we could screen applicants by personal data or a referral code system. However, if I understand correctly how the referrals system works, referring players would be held responsible for a referred player's bad behavior. I'm not sure how many players would be willing to accept that responsibility. Not many, I would guess.
If the download process, whatever form if may take, does not take advantage of a file swarming or bittorrent protocol, I believe you are going to see huge issues.
A single mirror would still have to take the load of an entire download of a mappack to each host requesting the download.
Instead, a torrent will distribute this load amongst all seeders with complete or even partial completed downloads.
And again I mention the throttling and private seed functionality.
FTP or HTTP doesn't cut it anymore people.
So are they making a new Tribes? If they are, I hope there is a construction mod. Or is their a construction mod in Tribes 3?
Also, I got the terrible, terrible c0000005 error. Maybe someone help? =(
Oh, and Tribes 2 servers isn't working at the moment, (or a couple a weeks ago..) is it not updating cause the patch isn't finish or is it something else? The computers that I have
that got Tribes 2 isn't working! Well one works for solo mode and the other doesn't work
entirely. And the servers are shutting down soon. wow. Talk about bad karma. -_-'
l
l
V
REPLAY PLZ!
Hey! Is the severs working for you at the moment? I'm having *sniff* a little problem getting to the Online servers.
The Tribes 2 Online servers are not working right now. Is it the update or something else? Please reply!
To play "on-line" with others, see this thread.
Thyth is working on a new master server. Read some of this thread and it'll tell you about our temporary fix untill the new system is ready.
This thread is discussing a patch we're working on that will allow players to create accounts and log in to the game, and in time bring back other features. Currently, players have to resort to playing in "offline" (Solo/LAN) mode, using listing scripts such as the one you can find in the construct section of the forums.
If you're having problems with unhandled exceptions, feel free to make a new thread with details and we'll help as best we can from the information you've got.
If the referral tree is viewable by all players (i.e. online), then a user could evaluate a reference before asking for a referral from that reference, and a user could also see what reputation each sub-tree has (assuming servers are willing to share banlists).
I think it would be a lot more difficult to abuse this sort of system, and I doubt it would be any more difficult to implement than a separate registration system. The only logistical concern is reaching critical mass with trusted reference players. Once there is sufficient critical mass, I think it would be easiest to use from the server administration and signup process than anything else.
I'll be thinking about and discussing possible implementation details for a system like that, but keep in mind that this will mean rewriting parts of the authentication server, and it will delay launch to include any sort of registration constriction system.
FTP/HTTP doesn't cut it if you have a large swarm of users attempting to access the same resource at once. For high popularity files, where you might have 30,000 concurrent download attempts, a traditional centralized infrastructure would fail.
The largest T2 game servers probably have 100 unique users per day. Most of these users will only need to download resources from the server once. Most of these resources will be small -- really large map packs don't often exceed 100 MB. If 100 users need 100 MB each in a day (i.e. launch day), the HTTP server would expend 10 GB in that day to transfer those resources. I think that is perfectly within the capabilities of a typical HTTP infrastructure.
If you strongly disagree, then feel free to implement bit-torrent, or a similar protocol in Ruby. Since most users are not technically savvy (and the terms 'NAT' and 'port forward' are blasphemous sorcery), I would strongly recommend using NAT traversal techniques, and a STUN server for establishing peer connectivity. If the implementation is up to my standard, I'd be willing to consider including it as part of a later patch version.
As for the map pack downloads, etc. you could always have mirrors. That would lower the theoretical 10 GB to one web server to maybe 2.5 GB over 4 web servers. While torrents are elite and all, it does seem like it would be really complicated and annoying to implement. If it was a matter of simply grabbing an already-made script and setting it up, then maybe it'd be worth it, but I'm sure it wouldn't be anywhere near that simple. I'm sure it would be a lot better for everyone overall if we just stick with HTTP and FTP.