connections

by t1W3r1z on 02/20/2004 14:28, 21 messages, last message: 03/10/2004 11:22, 2777 views, last view: 05/04/2024 12:46

what connction is the best to play cube?
IMHO you can get even good results with 56k-lat:200!

   Board Index   

#2: Heheh

by Pxtl on 03/02/2004 23:28

That's because Cube does one thing that no other game does - it trusts you not to cheat. In other games, lag is handled by letting the server handle aiming. You fire, that tells the server you fired, then the server handles the projectile and tells you how it went.

In Cube, you fire, your comoputer checks if you hit the guy, then tells the server that you hit him. The server mostly just handles relaying player locations around and little "I hit that guy" messages. Rockets fired by other players are strictly graphical - whether or not they hit you probably has already been decided before you see them.

There is only two real catches. A) this means that lag is as much an advantage as a weakness, as you can't dodge a lagged player as well. Second, if somebody ever decides to cheat, then aimbots will look positively pathetic compared to the mayhem they'll be able to do.

reply to this message

#3: ..

by para on 03/03/2004 01:31

cheating, inevitibly, will become a problem as cube grows (i assume it's growing anyway). it's a double edge sword; the bigger and better, the more fun and people... and the more cheating. i don't think Wouter (and any other developers that may be involved) wish to spend their time combating cheating. Wouter has proven his concept with an ultra fast, efficient engine that's fun and flexible. i'd think that implimenting security would add a lot of "dead weight" to the game. still, in the long run, the hand may be forced if it comes to that. look at the crap the HL/CS community went through (and still is). it's a constant battle.

reply to this message

#4: I have an Idea...

by e:n:i:g:m:a on 03/03/2004 19:16

What the program could do is check a MD5 sum with the connecting users's client program. Then, it would be able to tell if the client had been modified b/c the MD5 sum would come back wrong.


In fact...

Every time you release a version of Cube or Sauerbraten, release an ENCRYPTED MD5 sum string with it in a text file.

Then, the server would decript the MD5, and check it with the client software trying to connect. If the MD5 fails, then you know that that client either has a different version, or is a cheater.

That way, if the client, or server software is modified, it won't work online

reply to this message

#5: ..

by e:n:i:g:m:a on 03/03/2004 19:17

After writing that, I might actually post it on the most wanted features thread.

reply to this message

#6: .....

by Drakker_ on 03/03/2004 19:47

The someone will try to compile it themselves with every optimisations for their weird/new/special processor and wont be able to play online.

reply to this message

#7: Re: .....

by fsmunoz on 03/03/2004 21:41, refers to #6

Indeed. There are many possibilities if one considers that only the official binaries can be used; the present one (different protocol) is even enough for most purposed. More can be done with MD5 sums, GPG signatures, etc.

What I have been trying to think is of a way to enforce the legitimacy of the client *even* is it was compiled from source. To be honest I haven't reached any valid conclusion. Every scheme that comes to mind is defeated by the fact that you could modify the source.

reply to this message

#8: Re: I have an Idea...

by hungerburg on 03/03/2004 23:42, refers to #4

windows media player used this scheme for its "digital rights management"; the client ID was buried in 10+ binary files: dlls etc. despite that efforts, it was cracked in less than 2 weeks then (not by searching!)

industry is trying to put the key in a chip now, cf. http://www.trustedcomputing.org/

reply to this message

#9: Re: I have an Idea...

by e:n:i:g:m:a on 03/04/2004 01:24, refers to #8

drakker:
What you could do is make separate builds for the major processors: i386, IA-64, AMD-64, etc. And then distribute the MD5 Sums (double-encrypted server-side) for all the released clients.

hungerburg:
The way the MD5's would work, is the server compares it's MD5 text file for the appropriate Client Software with a MD5 sum from the Client's software, that way users couldn't modify their own MD5 to cheat.

And, that way you check the md5, if it doesn't match up you get kicked. If it does, then you're in.

fsmunoz:
As far as "compiled from source," you could just release the actual source code, because if they modified it, it would show up in the MD5.

reply to this message

#10: Well, then there's linux

by e:n:i:g:m:a on 03/04/2004 01:25

Well, then there's linux, what you could do is have a separate piece of software that changes for the separate distro's, and then have the meat of the client the same, i guess. (heh, I love windows and linux!!)

reply to this message

#11: ..

by Drakker_ on 03/04/2004 01:37

I think the best remedy to cheating is education.

For now, a big part, if not the majority, of Cube players are linux users, so there's little to worry about cheating anyway.

reply to this message

#12: Re: ..

by fsmunoz on 03/04/2004 10:19, refers to #11

Yes, that's true, it's all pretty academic right now. The comunity is small and doesn't have a cheating tradition :)

As for the source code: I know that it's possible to verify with MD5, etc. Was I was refering to was a possible way to make compiled from source versions of Cube still rely on a anti-cheat scheme, as too allow self-compiled binary to join the public servers. It's easy to rely on MD5 or other checksumming mechanisms when you only want to validate a specific version of a binary, but this is not possible with a compiled from source one.

reply to this message

#13: Forced player authentication system? -i don't like it but-

by D.plomat on 03/04/2004 11:57

It's the one that adds the less bloat in the client game code.

The player must create an account on the masterserver. This procedure takes 2-3 minutes(checking back of the sent e-mail). Not too annoying but having to create a new e-mail plus new account for each new game would refrain some. (of course not the script wizards nor the pathological cameleons that always have 15 differents active e-mails...) Eventually a vote system with report of abuses or similar...

Heard that they use this in americas army, i don't know if this is efficient as i never played a game on it nor talked with players?

At least this solution adds very few bloat in the client game, formerly just only a login screen (maybe a little bit more in the server, for validating logins on the masterserver, and even more on the masterserver by adding the accounts database, account creation page (or maybe just use the account of the forum as login, a game password is sent to the mail specified)

reply to this message

#14: ..

by e:n:i:g:m:a on 03/04/2004 18:21

That might work, but you can still create a new account and a new email to cheat again, and people cna kick others for no good reason.

As far as validating from a source-compiled version, there have got to be similar things that each linux distro have in common, i mean, doesn't a program compile the same on a mandrake or redhat system, as long as the kernel version is the same?? (ps: I'm just using mandy and RH as examples)

reply to this message

#15: Oh yeah...

by e:n:i:g:m:a on 03/04/2004 18:21

and I HATE registering my e-mail address for stuff.

reply to this message

#16: Re: ..

by D.plomat on 03/04/2004 21:03, refers to #14

not the kernel, but also compiler version, and the compiler's default build options.

And there is a huge amount of different combinations of them in the wild...

Also if it's source build, one can make a valid build, then a modified build that uses parts of the valid build to authenticate.

reply to this message

#17: ..

by e:n:i:g:m:a on 03/06/2004 21:04

OK, That makes sense...

But I don't see what you mean about using parts of the valid build to authenticate:

If you simply check a md5 string against the client (have the server tempoarily download the software off the client's computer) then I don't see why you would have to worry about modifications that use parts of a valid build to authengicate.

You could even set it up so that they only have to do this once:

You connect to a server and it validates your client in the above way, and then issues you a security certificate, so-to-speak. Then, it would only have to look at the certificate anc compare it to the MD5 string for the client, and the modified date of the client. Of course this file would be heavily encrypted.

reply to this message

#18: Cheating can be handled

by Lethedethius on 03/07/2004 05:47

Cheating in cube can be handled a number of ways, I know in Half Life they have some type of cheat stopper program that checks if you cheat, it relays the information to the server and allows you in :)

reply to this message

#19: Re: Cheating can be handled

by para on 03/07/2004 06:42, refers to #18

... and HL/CS is still pleaged (?) by cheaters.

reply to this message

#20: punkbuster

by Drakker_ on 03/08/2004 03:37

Punkbuster isnt worth the trouble for the legitimate players.

reply to this message

#21: Even if Cube executable is unhackable

by Pxtl on 03/10/2004 11:22

There's still the issue of your GL drivers. It would probably be trivial to make a custom GL driver that would allow you to shoot through walls, what with Cube using GL functions for distance checks.

reply to this message

   Board Index