OLD news BUG... "never fixed"...?

Discussion for any ET/ETPro/BayonET bugs or cheats you find...

Moderators: Forum moderators, developers

User avatar
ReyalP
Posts: 1663
Joined: Fri Jul 25, 2003 11:44 am

Post by ReyalP »

LilleBror wrote:Dont kill the messenger, just because he brings bad news.
No, you brought unsubstantiated rumors based on ignorance, as far as I can tell.
Hope i did.
Not in the least. You just managed to waste our time.
send lawyers, guns and money
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

?

taking offence here.

Follow the steps in the second post with a windows xp OS system and you will connect as a lan client.

This is a bug right? Not a tweak setting?

Its cheating on a server that uses punkbuster to force snaps 20, right?
The connected client is runnnig snaps a a function of cl_maxpackets and/or com_maxfps and/or r_displayrefresh if r_swapinterval is used.

If u need demo's, no problem i will be happy to contribute.

Sleeping on it i got one simple idea.

Count sv_fps/snaps sent to clients if its lower than 20 pr second kick, if its higher than 20 kick. (i.e snaps sent to clients must be = 20)

Above can this be done with a lua script?

If I run the game at com_maxfps 100 and cl_maxpackets 100 with r_settings so its fps stable, the game is very responsive.

One could consider having lan-netservers running at sv_fps 100, with apropriate restictions on connection cvars. Snaps 100 at least.
This would be exclusively for clients with a min X mbit connection, that can handle the load.
I know that a 4 Mbit can handle the load, but say a 2 or 1 Mbit or even 512 Kbit may also be able to do the same.
The Necromancer
Posts: 126
Joined: Sat Sep 25, 2004 7:12 am
Contact:

Post by The Necromancer »

Sympathy with everyone who tries to understand your whines.
Hi! I'm a .signature *virus*! Copy me into your ~/.signature to help me spread!
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

The Necromancer:=> ? spam? got something usefull to say?

-just so the post isnt a waist of space.

Please go try the lan expliot, then you might discover something i have overlooked or missed.
Nappy
Posts: 15
Joined: Mon Apr 10, 2006 4:52 pm

Post by Nappy »

LilleBror wrote:?
Follow the steps in the second post with a windows xp OS system and you will connect as a lan client.

This is a bug right? Not a tweak setting?
No it's not a bug. Whether or not you are on a lan is determined by your ip address, subnet mask, and target ip address. The mask is used to find your network address. Please read about it. Networks do not have complex 'oh wait, let me check that' protocols because they require speed.

http://en.wikipedia.org/wiki/Subnetwork

Having established the above, what is the proposed bug? Are you now trying to force a certain cvar value and cannot attain this?
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

Nappy:=> connect over WAN as LAN ... u get that you are not on the same local subnet? right?

If the server tells u that u must use this range of connection cvars over WAN like snaps 20, and you as a WAN client connect as a LAN client, this equals CHEATING, and the fact that you can do it is a bug.

Hence i reported it to the mod makers of ETpro, because it is a bug.

I hope understand now what the bug is.

But go try it urself, so u can se it with your own eyes.
Nappy
Posts: 15
Joined: Mon Apr 10, 2006 4:52 pm

Post by Nappy »

If your IP is 123.234.456.102, server IP is 123.234.456.101, and your subnet mask is anything less than 255.255.255.254, then the address is in your network. It's likely that your modem just adjust your IP to a correct value when sending the data. ISPs generally do not allow you to pick what ever IP you want on God's green earth. And technically, WAN and LAN refer to physical constructs of which your PC is not aware.

Are you claiming that you are not restricted like the other clients? I don't get it. Please put aside network terminology and tell us what advantage you get over other players. Use cvars and numbers. What is wrong with 20 snaps?
Nappy
Posts: 15
Joined: Mon Apr 10, 2006 4:52 pm

Post by Nappy »

Do your ip magic and go to this site to see what your actual IP is. It will not match your arbitrarily chose IP.

http://whatismyipaddress.com/
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

Nappy:=> Try it, when recording a demo you will find out imediatly after you start that the data set is much larger than normal.
Turn on the cg_lagometer and cg_drawfps.
Change around cl_maxpackets and com_maxfps, and watch the top of the graph. You will see that snaps now is bound to the number of packets you send, and not the fixed number that the server specifies from normal WAN clients.
Nappy
Posts: 15
Joined: Mon Apr 10, 2006 4:52 pm

Post by Nappy »

Stop telling people to jump through hoops and clearly explain the problem. Post a measuable result, tell us what you expected the measurable result to be.
Tron
Posts: 22
Joined: Mon Apr 18, 2005 7:30 pm

Post by Tron »

LilleBror wrote: Follow the steps in the second post with a windows xp OS system and you will connect as a lan client.
I tried that but it didn't seem to have an effect. :? Did you mean those steps to be followed independently of what you posted first? Or am I supposed to change my local IP as well? As others mentioned, that wouldn't work because you get one assigned from your ISP.

At least ET was still causing the same up-/download as before (tested on an empty server). Assuming I run at 125 fps/cl_maxpackets 100, it should send 125 packets instead of 62 then, resulting in double the upload? I seem to remember there is an ingame command to see the actual snaps received / packets sent, maybe that would clear things up (is there such a command?).
User avatar
ReyalP
Posts: 1663
Joined: Fri Jul 25, 2003 11:44 am

Post by ReyalP »

LilleBror wrote:?
taking offence here.
You are free to take offense at whatever you want.
Follow the steps in the second post with a windows xp OS system and you will connect as a lan client.

This is a bug right? Not a tweak setting?

Its cheating on a server that uses punkbuster to force snaps 20, right?
The connected client is runnnig snaps a a function of cl_maxpackets and/or com_maxfps and/or r_displayrefresh if r_swapinterval is used.
No. snaps has nothing to do with maxpackets. Punkbuster has nothing to do with snaps, unless the admin sets a restriction. Connecting as a LAN client or not has no effect on snaps either, since snaps is at most sv_fps. This is exactly what I was talking about when I said your posts were full of errors and unsupported speculation.

As I said before, even if you can trick ET into thinking you are on a LAN (which I have not verified) the only effect would be removing the upper limit on maxpackets (and possibly rate if you could trick the server too). This will either flood your own connection (hurting you far more than it hurts everyone else) or cause slightly more traffic to be used with minimal other effects.
If u need demo's, no problem i will be happy to contribute.
Demo of what ? What is the problem you think is caused by this ? So far, you have only given incorrect speculations, without describing any actual, observed problem. Stop speculating and guess, and clearly describe the problem.

edit:
Most quake3 games (including ET prior to 2.60) detected whether you were on a LAN or not purely by comparing the (pre CIDR) network portion of your IP. This lead to many users being incorrectly detected as LAN clients. The only major effect was clients on low bandwidth connections flooding themselves.
send lawyers, guns and money
LilleBror
Posts: 111
Joined: Wed Nov 24, 2004 11:10 pm
Location: Dk

Post by LilleBror »

tron:=> im behind my own router but it shouldnt effect it.

Packets up is the green line at the bottom of the lagometer, and the incomming snaps are at the top.

When connected standart:

The sendt packets are caped by cl_maxpackets.

The recieved packets are caped by snaps.

When connected with the expliot:

The sendt packets are still caped at 100 by cl_maxpackets.*

The recieved packets are now equal to the number of sent packets, not snaps!

* with r_swapinterval 1 and r_displayrefresh 100+ u may be able to send more packets than the cl_maxpackets cap.
I dont have a good CRT monitor that can v-sync over 100 Hz... so i cant test it.

-simple test.
1) start a demo recording.
2) set cg_lagometer 1
3) set cg_drawfps 1
4) set cl_maxpacket 100
5) bind j com_maxfps 43
6) bind k com_maxfps 100
7) press j
8) watch the top og the lagometer graph
9) press k
10) repeat step 7-9

you will see that the top part of the graph will accelerate when u press k, and slow down when u press j.
User avatar
ReyalP
Posts: 1663
Joined: Fri Jul 25, 2003 11:44 am

Post by ReyalP »

LilleBror wrote: Packets up is the green line at the bottom of the lagometer, and the incomming snaps are at the top.
Wrong. See http://wolfwiki.anime.net/index.php/Lagometer
you will see that the top part of the graph will accelerate when u press k, and slow down when u press j.
See above. This has nothing to with the so called exploit.
send lawyers, guns and money
User avatar
zinx
Posts: 267
Joined: Fri Jan 16, 2004 12:37 pm
Location: US
Contact:

Post by zinx »

Just to clarify a few things:

ET Pro's antiwarp already breaks frames up so that there is at least one per server frame. There was a bug in an _older_ version that would not do this if pmove_fixed was on, but that has since been fixed.

ET Pro's antilag is based entirely on what you should have recieved in that server frame. Barring some amazingly stupid bug, it is *PERFECT*, unless *YOUR OWN* connection has packet loss, in which case it may be off depending on how many packets you lost. For any significant difference to happen, ET would already be unplayable for you for other reasons.

Any bug you're seeing with people being unhittable is due to one of two things, and not at all related to antiwarp or antilag.

1) You are imagining it, no problem exists. This is the most likely cause.
2) There may be a problem which spuriously detects 'connection interrupted' status, which due to other circumstances sets the hitbox/collision box to a volumeless point. No such problem has been verified yet.
Zinx Verituse http://zinx.xmms.org/
Locked