home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Enemy Territory + Cube 2 = wOOt?

by ezombie on 01/19/2008 16:25, 258 messages, last message: 04/03/2008 21:39, 195447 views, last view: 09/29/2024 16:26

I made an actual thread for this, since we are still yacking about it. To bring the others up to speed:

"Some of us weirdos have been kicking around the thought of making a community edition of Enemy Territory (the FIRST one). I suggested the Cube 2 engine might be a good base...

This would be a straight port of ETPro gameplay to a standalone open source game, using new 'HD' assets. Nothing too fancy, just better graphics and netcode are what we would be looking for."

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

#124: ..

by ezombie on 01/31/2008 23:02

"What about position checks and clipping in normal multiplayer ?

It could rise the network speed because you only have to send events which are seen by a player. This would also make wall hacks useless."

Well, the server does not even load the map that is currently playing. So it would have to load the map, plus interpret the map somehow. Like they said, this would push it much closer to the client in terms of mem+cpu used.

And as far as implementing a 'view model', I see this brought up all the time in discussion, yet no commercial game uses yet AFAIK (even the spanking new ones). This must mean something... any comment on that eihrul?

reply to this message

#125: Re: anti-cheat

by SheeEttin on 01/31/2008 23:10, refers to #121

Some games take screenshots. I think it's actually PunkBuster that does it.
The screenshots are really low-res (320x240, 16-bit color or lower), so there's not a whole lot of net usage, especially since they're sent infrequently.

The screenshots themselves, however, do not do much in the way of defeating aimbots, etc., as they have to be manually reviewed by an admin, as well as not necessarily showing an actual cheat.

While screenshots are an interesting option, there's too little gain for too much work and/or resource use.

reply to this message

#126: ..

by scasd on 02/01/2008 00:39

There is no need for leaving a corrupted server - you are kicked before you can disconnect :P ok, ok *g* I got disconnect clicked so I have not been banned - but I wondered why all other players are kick-banned after each other.

About that movement hacks: what if a guy moves very fast to an item, picks it up and moves then back to his original position... that would be possible without movement checks easily. In ffa and other modes with items the server sided ammo check would be useless in that case.

@ezombie: A flag that allows the admin to enable server sided clipping could solve the CPU usage problem - I really dont want such code running on non-dedicated LAN servers too by the way... But idiots could hack themselves ammo/health and move like a fly and through walls without that - which wipes out online servers very fast as far as I have seen it.

reply to this message

#127: Re: ..

by JadeMatrix on 02/01/2008 01:26, refers to #127

That's perfectly understandable. No connection is perfect, and even if it was, the server and client aren't. But I think server-side clipping would be a good idea for making sure the players aren't where they shouldn't be or go. Maybe. Hmm, doesn't appear to work for open-air maps... maybe a separate clip-model...

Ok, so in conclusion, the entire concept is still too unfeasable as is. That's why the big games don't us it: too much effort for too little return.

Although I have been thinking about this kind of stuff recently... I'll give the idea some more time to roll around.

reply to this message

#128: Re: anti-cheat

by ezombie on 02/01/2008 03:22, refers to #125

I actually set punkbuster to grab a screenshot randomly from players on our servers, so I could show them on the website.

It doesn't use much bandwidth, true - but unless people have well configured, higher end firewalls (with ACK prioritation) - it kills your ping for the 1-3 seconds that it takes to upload it. Very noticable in game.

reply to this message

#129: ..

by ezombie on 02/01/2008 03:28

I agree about the general concept of server 'sanity checking' for player action. This is a heuristic-based approach and can be quite sexy if done just right.

But make no mistake, it's HARD. It can be difficult to get the thing just sensitive enough kick most cheaters, but not kick really good players.

I have implemented some heuristics for the monitoring of assembly line machinery. It can make your head really hurt at times...

reply to this message

#130: ..

by scasd on 02/01/2008 21:04

the server sided clipping would only cause the server to kick players within solid areas (no physics). To find players who are moving too fast or too hight would perhaps need full physics emulation.

The weapon hits and stuff are not affected. But as you mention this piece of server code - it is also really weak for cheating. I got slapped from somewhere by the way on a server without having a person seen. This also could have been a hacked hit event.

By the way, the server knows 'from' and 'to' values from a shot and can compare them to the other player positions which haven been got from the same client (with the same LAG, ping and stuff --> no sync problem, the server knows where players are). In this case the client will get what it sees because only the shooters position is validated fully and the hit destination is checked to be within a range around the victim. This would also need server sided physics because of the speed of a victim and thus the range where a hit may occur.

So I really dont understand why you complain about your small community and dont invest more in server sided validation because cheater suck - and there are cheater in Sauerbraten. As mentioned above I dont mean client sided hacks like aimbots. I mean things you can identify - flying like a bird or being invisible while damaging others.



@ezombie: The problem with the sensitivity can be solved by rising it. This would not kick all cheater but also guys with too much packet loss - they suck too and can also be kicked for my opinion. The speed may still be raised by hack but only a small amount. Hits can occur also when victims are directly behind small walls while moving. But that are only special cases not worth to create hacks for I think.

reply to this message

#131: Re: ..

by yoopers on 02/01/2008 21:27, refers to #130

To the problems of flying like a bird or being invisible, I offer the following haiku:

Flying through the air?
Stalking opponents unseen?
/kick [cn] resolves all.

(just hoping to introduce the proper level of sarcasm and snarkiness into this discussion ;)

reply to this message

#132: ..

by ezombie on 02/01/2008 22:50

How would we solve these problems 'flying like a bird or being invisible while damaging others'? And what hack would the 'check the shots' protect against?

Since the client is doing the physics, you will definitely need server physics to determine if they are flying, and you will need the map loaded, parsed, and players simulated.

And since it is doing the physics for EVERYONE, this will use more CPU then one client does. And you will end up with the same net performance/server lag as seen in ET or (uggh) ET:QW. See the problem? I agree that cheaters suck, but you are describing a particularly dicey way of implementing server side checking.

The ammo/health thing has been addressed. I'm not sure where the 'invisible' thing is coming from - I suspect abuse of the translucent model control (used to indicate bad connections in game I think). That would be a simple enough server check.

I find that cheaters typically like the challenge (of exploiting) over all else, and as a discussion about Sauer hacks on NixCoder.org pointed out "what's the fun of hacking Sauer? The server doesn't check ANYTHING". So sitting around here arguing about the best way to stop cheaters is something they would love. Heck, they are likely reading/posting about it (if they are bored enough) simply so they *can* have fun hacking Sauer in the future.

Some of us are working on it, but not in the methods you think.

There are many ways to deal with the problem, the best of which is to simply shrug our collective shoulders and have some fun with /kick, /ban (coming to a mod near you), and if all else fails, just move to a new server.

I'm sure those cheaters LOVE playing by themselves.

BTW, last I checked, no one around here was complaining about the size of the community...

reply to this message

#133: ..

by scasd on 02/02/2008 02:10

Yea nice idea - "a one person needs only to vote for a kick ban on a 16 player server" - cool feature ***even more sarcasm*** /kick [cn] does not work every time by the way and when... *phew* the cheater is getting a new IP and a new name just within seconds.

By the way I dont run away from cheater.
I dont care about cheater and I dont would disconnect before the round is ended only because of cheater. Others would do and playing only against cheater is nasty.
I mentioned the possibilities to cheat as a contra versus Sauerbraten as mod base for online mods. Because implementing all that discussed stuff wouldnt be easy.



@ezombie: Are not the clients doing the physics for every player ? What about all the monsters in single player ? My good old 2ghz athlon was enough to simulate them - and Sauerbraten didnt use 100% of it.

The 'shot protect' would check if someone shoots around multiple corners.

Remember the long thread about Sauerbraten rated worst. The community is complaining about others who say Sauerbraten sucks. I didnt read the article but since graphics and speed are nice for my opinion it could only be cheating/bug using and the issue about "nothing against cheats implemented".

I have red some threads about that issue in the last year. There is no important game ladder without an official or unofficial anti cheat tool.

reply to this message

#134: ..

by ezombie on 02/02/2008 03:49

Back on topic - what do you guys think of THESE textures?

http://www.usef-et.org/forum/attachments/test4.jpg

reply to this message

#135: Re: ..

by MovingTarget on 02/02/2008 04:26, refers to #134

Those are nice! The brick may have a little too much specularity, but other than that, kewl!

And that gun skin is pretty nice!

reply to this message

#136: Re: ..

by JadeMatrix on 02/02/2008 07:15, refers to #132

How about having the server compare the client's physics feedback on their 'rendered' players... not all clients can be cheaters.

reply to this message

#137: Re: ..

by JadeMatrix on 02/02/2008 07:17, refers to #136

Damn, just re-read eihrul's post...

Server-side physics calculation is the may to go, i guess.

reply to this message

#138: ..

by ezombie on 02/02/2008 08:32

Well, I'm not holding my breath on that.

But I am going through alot of extra effort so that our 'conversion' can use as much of the new Sauer code in the future as possible. So if that comes about, I'll be happy to capitalize on it.

We are just going to use player authentication to start, and see how it goes. There are other benefits by using central player sign-ons, discouraging cheating is just a happy side effect.

reply to this message

#139: Re: ..

by tentus_ on 02/02/2008 15:28, refers to #134

Nice texturing! I always like seeing a brick that doesn't look flat and washed out ( http://sauerbraten.sourceforge.net/newer/screenshot_463706.jpg ). It's kind of odd actually, brick textures are ridiculously common, but rarely very good.

reply to this message

#140: Re: ..

by SheeEttin on 02/02/2008 16:32, refers to #134

Hmm.
It might just be the screenshot, but I think they have the same problem that AssaultCube's textures have... I can't put my finger on it, but it just seems that there's something fundamentally unrealistic about it. Maybe because they aren't *mapped?

reply to this message

#141: Re: ..

by jbuk2k7s cookie has gone on 02/02/2008 18:32, refers to #134

Nice textures, but the specularity is far too high. Bricks aren't shiny IRL are they?

reply to this message

#142: Re: ..

by tentus_ on 02/02/2008 18:40, refers to #141

Depends. If it's outside then it's fine: even bricks are shiny in a wet area. Inside it's a bit less appropriate, but for a place without a door they can still get damp and therefore shiny.

reply to this message

#143: ..

by ezombie on 02/02/2008 21:01

I am still playing with the pixelparam on the textures. These are actually from the artist 'method', here is how they look when properly setup:

http://www.methodonline.com/temp/meth_test.htm

I just have to import them corrrectly first :D

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
56807733 visitors requested 74729408 pages
page created in 0.071 seconds using 10 queries
hosted by Boost Digital