banimod / etpro / ettv forums

In windows change the lan setting so the IP abc.def.ghi.xxx is the same as the server that u wish 2 play on. ie...

server IP 123.234.456.101 set �check� use automated script in lan settings and type in an IP number that is identical to the first 9 numbers.

Exsample...

UR puter IP 123 .234.456.102

ur now on LAN over the internet... and the antilag cant handle it.

Droping cl_maxpackets to 15 means u only get 15 snaps... i ran into this flaw 2 weeks ago,,,,

LAN ::::> cl_maxpackets/com_maxfps = snaps

u can get more udated or less...

Runnnig cl_maxpackets and com_maxfps at diffent set values u can either hit well or be very hard 2 hit....

Not tested with scripts or other connection cvars...

But the antilag should realy be overhauled...
...or a autokick ping > 5 msec cutoff if �LAN� is detected...

The worst �part� is that its a common known �tweak� <- cheat.... IMHO since the antilag position the others target �u� at is wrong....

You post is completely incoherent. Please try again.

I'm having a very hard time translating what you're saying in to English, but if I'm understanding correctly your problem is with the rate limiting being removed if you appear to be on the same LAN. This is an engine issue, and can not be fixed in ET Pro.

I don't know where or why antilag would enter the picture - Antilag does not care or check to see if anyone's on a LAN. For that matter, it also doesn't check your ping, bandwidth, number of moles, or whether you've gone through puberty yet.

If you can't present your problem explained in English, I can't help you any further than that.

step 1. lookup IP of server that whant to play on like on splatterladder.

step 2. hold mouse over the icon "internet explorer" click rmb - select properties

step 3. hold mouse over "connection's" click lmb

step 4. click lmb on "Lan-configuration"

step 5. click lmb and mark off the second box "use script for automatic configuration.

step 6. type in IP that u looked up.

step 7. click lmb "OK"

step 8. click lmb "OK"

ur good 2 go connect ingame or via "splatter ladder" fuction to the server.

now u get within lan connection so that u send a packet and receve a packet.

limit is 15-100 there is still a cap? com_maxfps 0 and com_maxfps 100 will only send 100 packets and get 100 updates "snaps"...
somehow cl_maxpackets and or rate is still in effect...

try it...

p.s my version of XP is in danish so the "names/tags" may not match word 4 word...

try "difffent" connection settings ... and scripts/binds +vsrt

pmove_fixed is a nice place 2 start..

"imorzilla effect" gets realy strong when ping is around 70+ -100--
or running modem settings
cl_maxpackets 15 and low pping 20-30+


This is an engine issue, and can not be fixed in ET Pro---?
Why not?

-Add a ingame option so that clinets can force lan over the internet.
-Recalibrate the antilag for high ping lan connections
-Kick funktion or a delay fuction concering changes form lan-internet server-client connection, and all connection cvars just to be sure that rapid change expliots will not fuction.

i dont code c++ so its a shot in the dark...

LilleBror wrote: pmove_fixed is a nice place 2 start.. :)

"imorzilla effect" gets realy strong when ping is around 70+ -100--
or running modem settings
cl_maxpackets 15 and low pping 20-30+


This is an engine issue, and can not be fixed in ET Pro---?
Why not?

-Add a ingame option so that clinets can force lan over the internet.
-Recalibrate the antilag for high ping lan connections
-Kick funktion or a delay fuction concering changes form lan-internet server-client connection, and all connection cvars just to be sure that rapid change expliots will not fuction.

i dont code c++ so its a shot in the dark...

Antiwarp is supposed to take care of most of the connection issues.

Antilag does not work how you think it does. It is not based on ping, and does not alter how others are able to hit you. It only alters how you are able to hit others.

There may be an issue with the bounding box getting set very small with poor connections (like ones that would happen when your upstream/downstream is saturated because no rate limiting is happening), but I've not had time to look in to that.

pmove_fixed has nothing to do with it.

zinx wrote: There may be an issue with the bounding box getting set very small with poor connections (like ones that would happen when your upstream/downstream is saturated because no rate limiting is happening), but I've not had time to look in to that.

Is bounding box = hitbox? And would that mean that you might actually be able to reproduce or confirm the alleged unhittability of the infamous "Polish laggers" that's talked about for ages? Or did I misunderstand that?

1: Antiwarp is supposed to take care of most of the connection issues?
-vs exploiters... i strongly recommend tightning the skrews harder.

2:It only alters how you are able to hit others?
-and? im saying that is broken vs. higher ping lan connected clients,,,

3:hitboxes that get smaller... ?
-no idea... but in it self this is a big problem. Priorty action! ASAP fix!

pmove_fixed... well... soory not taking ur word on that one...

lan-lan running at the same fps.. -no problem i would think...

lan-internet running at diffent fps and ping -problem's!...

very sure... experiance from running a server with pmove_fixed clamped two one value only... game engine wise i cant prove anything..

LilleBror wrote:1: Antiwarp is supposed to take care of most of the connection issues?
-vs exploiters... i strongly recommend tightning the skrews harder.

They can't be tightened any further. They're already 100% perfect, except for the case where people freeze for a moment in the air. And that can only be fixed by extrapolating positions.

LilleBror wrote:2:It only alters how you are able to hit others?
-and? im saying that is broken vs. higher ping lan connected clients,,,

Your own connection determines how well you hit other people, not theirs. Shooting a low ping player is exactly like shooting a high ping player.

LilleBror wrote:3:hitboxes that get smaller... ?
-no idea... but in it self this is a big problem. Priorty action! ASAP fix!

I have not even verified this yet. It is just a guess at something that could cause the possibly imaginary problems that people are having. I have other things to do at the moment.

LilleBror wrote:pmove_fixed... well... soory not taking ur word on that one...

lan-lan running at the same fps.. -no problem i would think...

lan-internet running at diffent fps and ping -problem's!...

very sure... experiance from running a server with pmove_fixed clamped two one value only... game engine wise i cant prove anything..

pmove_fixed only breaks long frames up in to shorter ones - ones that are much shorter than the server frames. Server frames are what movements are sampled at for the purpose of hit detection. Antiwarp ensures the frame lengths are suitable for hit detection.

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

Jidoka

First there is a problem.

Engine wise i cant point here---->here is the proof.

From what im reading from replies its old news.

What i would like i perfect hit detection, or alternativly the best hitprediction possible favoring client that send and recieve packets timely.

-you are saying no change--- live with it as it is...

antiwarp: They can't be tightened any further- yes it can min fps 20 --similar to g_maxwarp from etpub set 1 for starters... multi hitbox hitscan ie. if u lagg u are hitable on 1,2,..x more stored positions at the same time.

antilag: then add extra methods of antilag. say 12 more selectable methods... and or a direct time interpolation/extrapolation that can be set at least +/- somthing like a 100 ms time range.

pmove: yes getting a snap consisting from a lan client delivering 5 packets at alternating pmove_fixed-unfixed translation into a 50ms normal internet snap causes problems... "if im understanding u right."

You should really stop guessing about stuff you don't understand and then claiming it is a problem.

If you have proof hit detection breaks under certain conditions, please do so.

LilleBror wrote:http://en.wikipedia.org/wiki/Jidoka

http://en.wikipedia.org/wiki/Moron_%28psychology%29

SCNR.

ReyalP:=>"If you have proof hit detection breaks under certain conditions, please do so.."

i wrote i did not have a smoking gun.

"Engine wise i cant point here---->here is the proof."

a statement like...

If you have proof hit detection dosnt breaks under any conditions, please do so.

would not help the etpro team...

im pointing out as an user of ur created product, there is a problem, experiance derived form connecting as a lan client over the internet...
"other are now missing me at point blank"

The why,how and where were i point the finger is related to the experiance i have had with running servers with 1 value for all connection cvars.

...guessing Yes...

...But its based on trial and error...

It dosnt realy help evolution of finding and fixing problems, if the end users have to prove exsistance, dosnt unsatifactionary gaming experiance count at all?

If nothing is implement or investigated unless the "users" prove it, you should realy consider sharing the Etpro code.

You seem to believe there is an problem. Hopefully, this is for some reason beyond incorrect speculation about how the game works. If so, describe that reason. If not, stop wasting our time.

If you can convince ET that it is on a LAN by some trick, it may send more packets than it would otherwise (1 per client frame rather than a max of 100). Aside from possibly flooding your own connection, and thus making it harder for you to play, that shouldn't have much effect.

The rest of your posts, as far as I can interpret them, are so full of false assumptions that they are completely useless to us.

Your random speculations don't help us find the problem. Please just describe the alleged problem, without guessing about the internals that you clearly don't understand. And FFS, all the weird punctuation makes your posts really hard to read.

Dont kill the messenger, just because he brings bad news.

Just trying to help.

Hope i did.

Later.

You need to:
1. Post the results that are wrong
2. Clearly describe the environment in which those results are produced
3. Post what you expected those results to be

Someone else will will do one of the following:
1. Investigate because there seems to be a problem
2. Ask for more information
3. Explain why you expectations are incorrect